От пилота до 300+ лицензий: как АСГ строит свои приложения на API Кайтена

Когда зарубежный вендор уходит с рынка, у крупной компании есть два сценария: найти максимально похожий инструмент и работать как раньше — или пересобрать процессы под новую систему. «Алкогольная сибирская группа» пошла по второму пути.

Спустя три года таск-трекер перестал быть просто местом для задач. Сейчас это управленческий контур, где в одном пространстве живут задачи, планерки, производственные метрики и часть бизнес-процессов, а недостающие сценарии команда дописывает сама — через API.

О том, как компания выстроила иерархию доступов на 300+ сотрудников, сократила планерки и достроила Кайтен собственными приложениями, рассказал Михаил Козлов, ИТ-директор «Алкогольной сибирской группы».

Чем занимается «Алкогольная сибирская группа»

АСГ — крупный российский производитель алкогольной продукции с широким портфелем брендов. Проекты и задачи распределены между командами, которые работают в совершенно разной логике: производство, ИТ, маркетинг и другие направления.

Для такой структуры характерна одна и та же управленческая проблема. У каждой функции свой темп и свои процессы, но руководству нужна общая картина: что происходит в проектах, кто за что отвечает, где возникают отклонения. Без единой системы эта картина собирается вручную — и почти всегда с опозданием.

Поэтому вопрос выбора таск-трекера здесь был не про удобство отдельных команд, а про управляемость компании целиком.

Как замена таск-трекера стала срочной задачей

До 2022 года команда вела задачи в продуктах Microsoft. После ухода вендора из России понадобился новый инструмент — такой, который сохранит управляемость и не усложнит процессы. Требование звучит просто, но на практике именно оно отсеивает большую часть решений: система с избыточным функционалом требует долгого внедрения, а слишком простая не выдерживает масштаб.

Компания рассматривала и российские, и зарубежные варианты. На тот момент ни один не закрывал базовые требования целиком.

Почему в итоге выбрали Кайтен

Решение сложилось из трех аргументов:

• Понятный интерфейс. Для компании такого размера это не про эстетику, а про нагрузку на внутреннюю поддержку: чем меньше вопросов вызывает система, тем меньше заявок приходит в ИТ.
• Простой онбординг. Сотрудники должны включаться в работу сразу, а не ждать месяцы внедрения.
• Достаточный функционал даже на бесплатном тарифе. В нужных команде сценариях он перекрывал возможности MS Planner.

Старт был осторожным. В 2022 году команда запустила пилот на бесплатной версии: проверяла гипотезы и собирала обратную связь от бизнеса. Когда стало понятно, что инструмент прижился, компания перешла на полноценную on-premise-установку. Сейчас в системе больше 300 лицензий, и масштабирование продолжается.

Как устроена иерархия доступов на 300+ сотрудников

Первым делом в компании настроили иерархию доступов. В АСГ несколько уровней команд, и каждому сотруднику важно видеть ровно тот срез информации, который соответствует его роли: руководству — общую картину и статусы, командам — детали работы внутри своего контура.

Показательная деталь: логика настройки оказалась достаточно прозрачной, чтобы команды разобрались сами — без инструкций и отдельного онбординга. Первыми доступы настроили коллеги из HR, а затем передали опыт остальным подразделениям.

Структуру ИТ-дирекции, например, разделили на три уровня:

• Стратегический — для ключевых сотрудников, 13 человек.
• Уровень поддержки — промежуточный слой для координации, участников примерно вдвое больше.
• Линейный — пространства команд-исполнителей.

На практике это работает так: руководитель формулирует задачу на верхнем уровне и назначает ответственного. Ответственный забирает ее в свое пространство, дробит на подзадачи и распределяет по исполнителям. Наверх поднимаются только его обновления — без внутренней переписки команды и промежуточных деталей.

Такая схема закрыла сразу две задачи:

• Доступы больше не настраиваются вручную под каждого сотрудника — достаточно добавить человека в нужную группу пользователей.
• Каждый видит тот объем информации, который нужен ему для работы. Для компании это еще и вопрос безопасности: чувствительные данные не расходятся по подразделениям просто потому, что кому-то один раз выдали лишний доступ.

Как планерки перестали быть сбором статусов

В отрасли много регулярных встреч, и проблема была не в их количестве. Большая часть времени уходила на пересказ статусов, которые руководители в идеале должны знать заранее.

Команда собрала под планерки отдельную доску и разделила ее на три зоны:

• в центре — операционные вопросы, которые разбирают вместе;
• справа — индивидуальные задачи, их оставляют для встреч 1:1;
• слева — BI-дашборды с ключевыми показателями.

Отдельно ввели ротацию ведущего — ее настраивают прямо в трекере. Каждый месяц встречу фасилитирует один из участников: фиксирует решения, следит за карточками с истекшим сроком, поднимает открытые вопросы. Задачи при необходимости перетекают из формата 1:1 в общее обсуждение и обратно.

Результат — встречи стали короче и предметнее. Апдейты по задачам приходят в Телеграм или на почту еще до планерки, поэтому время на встрече уходит на решения, а не на сбор информации.

Как BI-дашборды попали прямо на карточки

На планерках разбирают не только задачи сотрудников, но и производственные показатели: как заказы идут относительно плана и прогноза, где появляются отклонения, какую нагрузку это даст в ближайшие недели.

Раньше доступ к дашбордам был завязан на электронную почту — цифры искали в письмах. На созвонах о них вспоминали уже по ходу обсуждения и тратили время на поиск.

Логика решения такая: показатели должны быть там же, где команда принимает решения, без переключения между экранами. Поэтому компания настроила публикацию дашбордов прямо в Кайтене — они появляются на фасадах карточек в виде картинок.

Технически это выглядит так. Дашборды собираются в Excel: часть метрик считается формулами, часть подтягивается из хранилища данных. В отдельной вкладке указано, какой фрагмент публиковать и в какую карточку.

Дальше по расписанию робот проходит по этим файлам, забирает нужный фрагмент и через API добавляет его в Кайтен. В интерфейсе это выглядит как обычное обновление: картинка приходит комментарием от имени робота и становится обложкой карточки. Рядом появляется ссылка на источник, чтобы при необходимости провалиться в детали.

На выходе — компактная картинка с индикаторами: зеленый означает, что все идет по плану, красный сигнализирует об отклонениях, желтый просит перепроверить данные.

Такой формат экономит не столько минуты, сколько внимание. Чтобы понять, какие задачи обсуждать в первую очередь, не нужно открывать отчеты и разбираться в цифрах — достаточно взгляда на индикаторы.

Что компания достроила поверх Кайтена через API

Здесь начинается та часть, ради которой в АСГ изначально выбирали открытую платформу. Когда базовые процессы уже живут в трекере, следующий шаг — закрыть сценарии, для которых коробочного функционала не хватает.

Сейчас у команды три таких проекта: два готовятся к запуску, третий пока остается на уровне концепции.

1. HR-приложение для найма и онбординга

Раньше отследить, на каком этапе находится кандидат или новый сотрудник, было почти невозможно: все хранилось в переписке, а статусы собирали вручную.

Команда сделала собственное решение, где Кайтен работает как фронтенд. Анкета заполняется прямо внутри карточки, приложение само отслеживает переходы между этапами и назначает ответственного HR-менеджера — тот получает уведомление с конкретной задачей. Например, провести check-in через месяц после выхода сотрудника.

Доска кандидатов показывает весь путь: от первого контакта до окончания испытательного срока. Перемещение карточки по доске автоматически запускает нужную цепочку операций.

Внутри карточек работает плагин Кайтена: он добавляет кнопки для доступа к анкете, данные заполняются и редактируются прямо там.

Заполненные данные визуализируются в карточке таблицей. Точно так же туда попадают результаты опроса на базе Яндекс Форм.

Архитектурно решение устроено так:

• все сервисы читают из Kafka;
• взаимодействие идет через события, сервисы слабо связаны между собой;
• изменения вносятся через API Кайтена;
• часть данных и логов пишется в PostgreSQL;
• асинхронные и отложенные задачи выполняет Airflow.

Релиз запланирован на ближайшее время.

2. Автоматизация NPD-проектов

Второе приложение команда делает для управления выводом новых продуктов — New Product Development. Типовой проект уже собран: задачи, связи между ними, сроки и таблица контактов, кому что назначать. Работа идет в нескольких досках — шаблонных и рабочих.

Сценарий выглядит так:

1. NPD-менеджер заходит на доску «NPD Project».
2. Создает титульную карточку проекта: название, тип NPD, участников из списка ответственных, метки — категорию и размер проекта.
3. Переводит карточку из очереди в колонку «В работе».
4. Дальше система разворачивает проект сама: создает все задачи из шаблона, размещает их в пространстве «Задачи по проекту NPD», выстраивает связи «родительская — дочерняя», переводит первую задачу в работу, назначает ответственных и рассылает уведомления. Сдвиг срока одной задачи каскадно двигает сроки последующих.
5. Когда закрыты все пункты чек-листа, задача уходит в «Готово», а следующая по связи автоматически переходит в работу.

По сути NPD-менеджер заполняет только титульную карточку — структуру проекта система собирает самостоятельно.

Схема работы решения:

• события идут по цепочке Kaiten → Go → Kafka → сервисы;
• все сервисы читают из Kafka и общаются через события;
• оркестрацию берет на себя workflow-engine, остальное — узкие сервисы;
• изменения вносятся через API Кайтена;
• состояние и отчетность хранятся в PostgreSQL;
• Redis используется только как технический слой: идемпотентность, блокировки, кэш;
• архитектура рассчитана на горизонтальное масштабирование — можно поднимать несколько инстансов сервисов.

Проект на финальной стадии доработки, запуск запланирован на лето.

3. Почтовая интеграция для тендеров

Третий сценарий пока остается концепцией — интеграция с почтой через поле карточки «email-комментарий». Идея простая: достаточно добавить уникальный адрес в цепочку писем по тендеру, и вся переписка будет собираться в одной карточке, а отвечать можно прямо из трекера. К этой задаче команда планирует вернуться позже.

Что из опыта АСГ можно забрать себе

Пять выводов, которые компания сформулировала за три года работы в системе.

• Начинайте с малого — даже с бесплатного тарифа. Пилот, обратная связь от бизнеса и только потом полноценная установка. Так гипотезы проверяются на реальных задачах, а не на бумаге.
• Не унифицируйте доступы там, где это неудобно. Три уровня иерархии закрыли сразу две задачи: безопасность данных и экономию времени на администрировании.
• Переводите планерки из режима сбора статусов в режим принятия решений. Если статус известен заранее, встреча становится короче и содержательнее. Доска с дашбордами слева и задачами в центре — простое решение, которое работает.
• Автоматизируйте не ради автоматизации. Каждая надстройка в АСГ появлялась как ответ на конкретный запрос бизнеса, а не из желания усложнить систему.
• Смотрите на API как на страховку от потолка. Закрытая система упирается в свои ограничения раньше, чем компания успевает вырасти. Открытая дает возможность строить дальше — и именно этот критерий в АСГ считают ключевым при выборе платформы.

Развитие системы в компании продолжается: два приложения готовятся к релизу, а число подключенных команд постепенно растет.