Около года назад мы начали миграцию с системы Jira, которая использовалась для управления задачами, на российскую платформу Kaiten. Проект миграции – весьма амбициозный, ведь всего в системе у нас работают около 7 500 пользователей с огромным количеством сложных процессов. В рамках миграции нам необходимо было перевести все производственные процессы из одной системы в другую, и это требует очевидно много усилий от всех участников проекта.

Мы накопили серьёзный опыт и хотим им поделиться с вами. Меня зовут Роман Кузнецов, я отвечал за этот проект в X5 Tech, поэтому знаю в нём каждую мелочь – расскажу обо всём по порядку.

А что случилось?

Как и ряд других западных вендоров, некоторое время назад разработчик системы Jira заявил, что не будет продолжать взаимодействие с заказчиками на российском рынке. На тот момент у нас была закуплена и внедрена on-premise версия этой системы, которую мы использовали уже около трёх лет.

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

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

• Мы перестали получать обновления для Jira, а это значит, с течением времени мы всё больше будем подвержены проблемам получения новых функций.

Мы не могли не отреагировать на появившиеся риски, не могли продолжать работу в становящейся небезопасной и нестабильной системе, поэтому стали выбирать альтернативы по замещению этого решения. Так и начался наш путь от Jira к Kaiten.

Как мы использовали Jira в Х5

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

Второй важный процесс, за который отвечала Jira, – это управление портфелем инициатив. Когда какой-то внутренний заказчик хочет произвести изменения в IT и ему необходимо привлечь разные центры компетенций. Это может быть на этапе исследования самой инициативы, на этапе её анализа, оценки её выполнения, последующей приёмки в поддержку и закрытия. Весь этот жизненный цикл задачи также был прогружен в Jira.

Кроме того, наряду с другими информационными системами из Jira снимались данные по определённым отчётам, которые требуются для разных внутренних направлений, обеспечивающих функционирование всей организации в целом.

Для общей картины мы исследовали все процессы в Jira и вот, что у нас получилось:

Что мы искали

Когда мы поняли, что Jira придётся менять, мы определились с базовым набором требований к новому решению. И, конечно, изначально было понятно, что у него должен быть российский разработчик – иначе рано или поздно мы могли вновь оказаться перед необходимостью миграции. В общем, менять шило на мыло мы не стали – пошли изучать отечественный рынок.

Также мы решили, что нам нужны:

• возможность устанавливать информационную систему на свои сервера, то есть наличие on-premise-версии программного обеспечения;

• наличие опыта эксплуатации и отзывов об использовании;

• функциональные возможности, которыми не обладала Jira и которых нам в ней, как мы поняли, не хватало (например, возможность блокировки задач);

• соответствие определённым требованиям к инфобезопасности, возможности интеграции в наш IT-ландшафт;

• адекватную стоимость решения.

Изучив представленные на рынке решения (их на самом деле было не так и мало, как нам казалось), мы пришли к выводу, что имеет смысл более пристально изучать только Kaiten. Да, вот так сразу мы отмели остальные – ещё на этапе предварительного изучения. Почему не подошли остальные, рассказывать не буду – за это время у них вышли новые версии и наши претензии вполне могут оказаться необоснованными.

Пилот

На упомянутые выше обсуждения и поиск ушло примерно два месяца. А затем стартовал пилот. Для него мы отобрали примерно полтора десятка команд (из 250 имеющихся), которые, по нашему мнению, имели возможность и компетенции для опытной эксплуатации нового решения без, как говорится, отрыва от производства.

А сам пилот длился целых 9 месяцев – вот такой символичный срок.

• В первую очередь, мы проверяли возможность применения Kaiten как основной системы ведения задач для команд производства.

• Вторая часть задач пилотирования – это установка, настройка и понимание того, насколько вообще в нашем ландшафте эта система может жить.

• И, конечно, функционально-нагрузочное тестирование.

А теперь правки, господа!

По выходу из пилота мы поняли, что для полноценного внедрения нам нужны доработки Kaiten.

По настройкам ролей – не хватало возможности отдельно включить права на перемещение, удаление, создание и комментирование карточек.

Модуль автоматизации позволяет без привлечения каких-либо разработчиков самостоятельно создать автоматизированные процессы, которые работают так, что при определённых действиях происходят определённые события. Мы в ходе пилота поняли, что некоторых сценариев в этих автоматизациях нам не хватает. Например, действий при блокировке карточек, передачи в дочерние карточки пользовательских полей из родительских, действия по перемещению дочерних карточек в определённый путь.

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

Были и другие пожелания по доработке – всего несколько десятков. Передав наши пожелания разработчику и получив от него план реализации, мы начали процесс внедрения. За 2023 год было выпущены десятки изменений, запланированные для целей миграции. Безусловно, такой отклик разработчиков на конкретные замечания и достаточно оперативное внедрение обновлений очень важен для entreprise-системы.

Обучение и старт миграции

Оказалось, что у Kaiten очень низкий порог входа. Он интуитивно понятен с точки зрения применения функций. Поэтому на выходе из пилота у нас уже было порядка 300 сотрудников в системе, и не было нужды в группе поддержки, которая бы осуществляла сопровождение новых пользователей.

И здесь, на этапе начала «переезда», вскрылся ещё один колоссальный плюс нового решения: в Kaiten очень удобный механизм импорта из Jira. На мой взгляд, он вообще один из удобнейших среди всех, которые я знал на текущий момент.

Процессы, миграция

Итак, набив шишки и наступив несколько раз на грабли в рамках пилота, мы начали полномасштабную миграцию 7 500 пользователей. Скажу честно, это было непросто, но интересно.

Переезд процессов потребовал дополнительного изучения требований участников и владельцев этих процессов, чтобы далее спроектировать и реализовать их в Kaiten. Тут надо сказать, что в Jira не все процессы были реализованы гладко, так что мы учли предыдущие ошибки, чтобы не тянуть в новую систему старые косяки.

Здесь требуется небольшое погружение в специфику. В Kaiten нет привычных workflow, как это было в Jira; каждый процесс в Kaiten – это отдельная доска. Соответственно, мы делали прототип доски – один или несколько в зависимости от требований со стороны владельца процесса, а дальше проводили настройки вместе с теми пожеланиями, которые нам формулировали. Из-за большого количества взаимодействий по ходу разработки в каждом отдельном процессе было выделено множество этапов и ограничений, которые требовалось соблюсти.

Например, так выглядит визуализация процесса архитектуры решений:

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

Так выглядит декомпозиция инициативы с привлечением разных центров компетенций на разных досках. Стрелочками указаны связи между карточкой инициативы на доске «Входящие инициативы» с карточками на других досках. Текущий статус каждой задачи отображён в колонке.

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

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

Что изменилось?

• Зоны ответственности стали более понятными за счёт разграничения процессов.

• Стала более прозрачной работа в каждом направлении за счёт визуализации самих процессов и работы с блокировками.

• Иерархия взаимодействия между процессами стала более упорядоченной, обогащённой необходимой информацией согласно требованиям процессов за счёт визуализации связей.

Маршрутизация

Ввиду того, что разные компетенции работают на разных пространствах со своими требованиями, нужно было придумать механизм их взаимодействия. И для привлечения той или иной компетенции к выполнению инициативы мы создали маршрутизацию взаимосвязанных задач. Таким образом, у нас в Kaiten налажена работа целого ряда маршрутизаторов – их в системе около 25.

При создании таких карточек для привлечения других компетенций действуют определённые правила. Заполняя карточку, пользователь выбирает, куда она должна быть направлена для выполнения работы. Исходя из указанных вводных, дочерняя карточка будет автоматически перенесена на целевую доску исполнителя, а связи между карточками позволяют выстроить дерево вложенных карточек.

Так мы настраивали каждый маршрутизатор

Например, руководитель проекта хочет привлечь архитектора/аналитика. Он создаёт на доске-маршрутизаторе дочернюю задачу к своей карточке проекта и заполняет необходимые поля, после чего автоматизация отправляет карточку на пространство архитектора в правильную доску и дорожку, а далее другая автоматизация назначает нужно архитектора исполнителем.

Каждая доска на изображении – это доска маршрутизатор:

Также на пространствах настроены дополнительные автоматизации и ограничения. Например, архитектор в ходе своей работы должен привлечь к согласованию специалиста департамента информационной безопасности (ДИБ). Для этого сделана автоматизация по созданию дочерней карточки на доске в пространстве ДИБ при перемещении карточки архитектора в определённую колонку. И дополнительно сделан запрет на дальнейшее движение карточек архитектуры без согласования ДИБ через модуль ограничений.

Если в поле “Получено согласование ДИБ” стоит “нет”, то карточку переместить дальше нельзя.

Разграничение доступа

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

Например, заказчик может привлечь архитектора к своей инициативе. Он создаёт дочернюю карточку для архитектора на маршрутизаторе и заполняет параметры, после этого карточка будет автоматически перемещена в другое пространство – пространство архитекторов, на доску определённого специалиста. А заказчику доступна возможность просматривать и комментировать, но нет возможности редактировать, перемещать, архивировать. Важно отметить, что доступ на чтение и комментирование реализован для всех участников нашего большого сквозного процесса изменений. Все видят всё.

Для того, чтобы всё это было возможно, по нашей просьбе Kaiten доработал административный модуль управления пользователями. Мы при этом особое внимание уделили именно разграничению прав пользователей на осуществление тех или иных действий. Это привело к тому, что появилось больше ролевых моделей.

Настройки модуля ролей

Отчётность

В каждую карточку мы закладываем определённые атрибуты, чтобы можно было автоматизированно собирать отчётность. Она нужна и для контроля процесса работы, и для аудита. Данные в карточках формируются по определённым периодам и автоматически собираются в виде отчётов.

Как пример сбора метрик к сквозному процессу – мы смотрим на скорость реализации и пропускную способность, блокерам по всем инициативам, и, конечно, анализируем и оптимизируем, но это тема для другой статьи. А также мы формируем отчётность по производственным затратам в разрезе каждой информационной системы по всем этапам. Например, по отчётности можно узнать, какое количество человек в определённом месяце было привлечено к работе по каким компетенциям. 

Учитывая, что в процессах разработки работает порядка 7 500 человек, можно представить себе объёмы этих данных и ценность автоматизации процессов подготовки и сбора отчётности.

Кроме того, в Kaiten предусмотрены отчёты, направленные на различные метрики по времени и по разрезам выполнения работ. Поэтому во многом мы используем стандартные механизмы Kaiten для оценки и анализа своих рабочих процессов. Но есть и нестандартные, связанные с выгрузкой карточек из представлений и построением на этой основе графиков и прочего визуала.

Интеграции Kaiten

Любая система в enterprise не живёт в «вакууме», поэтому без интеграций никуда. Мы сделали все интеграции без обращения к разработчику Kaiten – использовали стандартный механизм API. Приведу несколько примеров ниже.

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

В X5 внедрена система MFSM, которая обеспечивает работу службы поддержки. В ней ведётся обработка обращений от пользователей информационных систем.

 Всего имеются три линии службы поддержки:

• колл-центр – регистрация обращений;

• специалисты второй линии поддержки – решение несложных обращений;

• специалисты третьей линии поддержки – решение сложных обращений или устранение дефектов в информационной системе. Чаще всего команды третьей линии поддержки работают не в MFSM, а в Kaiten.

Ранее в Jira был реализован механизм привлечения специалистов третьей линии поддержки. В процессе миграции мы перевели процесс взаимодействия между этими линиями в Kaiten, сделав там подобную интеграцию в виде таких же карточек. Это работает согласно принципу, в котором карточки попадают на определённую доску в соответствии с направлением, где обрабатывается та или иная задача.

Второй пример: синхронизация справочников из сторонних систем с Kaiten.

Настроили интеграцию со справочниками CMDB. Это база данных, в которой, кроме всего прочего, содержится перечень информационных систем и сервисов. В результате справочники из CMDB автоматически загружаются в пользовательские поля в Kaiten. 

Мы пошли дальше и настроили автоматизацию, которая создаёт доски для команд информационных систем и отдельную маршрутизацию по этим доскам. 

Например, если руководителю проекта требуется передать задачу в команду разработки по определённой информационной системе, то он указывает нужный параметр в пользовательском поле с перечнем информационных систем. А дальше карточка сама «отправляется» на соответствующую доску. Всего уже таким образом у нас создано более 800 (!!!) досок.

Пилоты для каждой команды для выстраивания единого процесса взаимодействия в Kaiten

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

То есть при пилоте мы погружали в Kaiten конкретный процесс конкретной команды (или нескольких команд) и смотрели, как это работает. При необходимости «рихтовали» и «дорабатывали напильником». Руководствуясь обратной связью от команды, мы постоянно меняли инструкции по работе, сам процесс настройки Kaiten, договорённости между коллегами. 

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

Нашей основной задачей при миграции было налаживание взаимодействия без слома общего подхода, который был выстроен ранее в компании. Мы с этим справились)