Почти пятнадцать лет проекты в КРОК вели в Clarity, и за это время компания ее переросла. Нужна была замена, и сложность заключалась в роли этой системы. Она стоит в середине цепочки, по которой данные о проектах уходят в таск-систему и корпоративную отчетность, так что менять ее пришлось прямо внутри работающего процесса.
Привет, Хабр! Я Марина Конова, ИТ-директор КРОК. Расскажу, как мы больше года вели проекты в двух системах параллельно и переводили их в Directum Projects. Сначала перенесли 5253 действующие активности, теперь переносим архив из 28 тысяч. В феврале пришлось на месяц остановить миграцию из-за ошибок в списаниях времени. Как мы избавились от двойного планирования и что в Directum доработали под свои процессы – под катом. Со схемами интеграций, трудозатратами на обновление платформы и разбором ошибок, которые вылезли только на боевых данных.
Почему пришлось менять систему
Начну с предыстории. Много лет мы вели проекты в Clarity, зарубежной информационной системе управления проектами (ИСУП). От вендорской поддержки мы в свое время отказались и сопровождали систему сами. Тем временем компания росла, и требования к управлению проектами менялись: нам нужно было централизованно вести портфель и видеть его в разрезе подразделений. Развивать под это большую и тяжелую Clarity своими силами становилось все дороже, да и работать она со временем стала медленнее. Поэтому в конце 2023 года мы начали искать ИСУП, которая позволяла бы вести централизованное календарное планирование и легко встраивалась в наш ИТ-ландшафт.
Сразу отвечу на вопрос, который напрашивается. Зачем отдельная ИСУП, если в компании уже есть таск-система? В ней наши команды ведут повседневные задачи, но вести календарные планы с нужной нам детализацией она не позволяет. Поэтому в ИСУП мы строим календарный план и управляем проектом в целом, а в таск-системе идет работа по задачам.
Теперь подробнее о цепочке, в середине которой стоит ИСУП. Главная единица учета у нас называется активностью, и она проходит через несколько систем. Согласование запуска проекта происходит в BPM-системе, оттуда активность попадает в ИСУП, затем в таск-систему, а данные о ходе проекта уходят в корпоративную отчетность. Еще ИСУП обменивается данными с финансовой и кадровой системами.
Так что нам предстояло не поставить новую систему и перенести в нее данные, а вынуть одно звено из работающего процесса и поставить на его место другое. Поэтому основные усилия ушли на встраивание в ландшафт.
Выбор и пилот: 6,8 балла из 10
В первой половине 2024 года мы собрали требования, посмотрели около 50 подобных решений и сравнили их в том числе с вариантом написать систему самим. Про выбор есть отдельная статья, поэтому скажу коротко. В Directum Projects большая часть нужного нам есть в коробке, включая календарно-сетевое планирование и работу с документами. Систему можно развернуть на собственных серверах и дорабатывать своими силами.
Еще на этапе выбора мы проверили систему нагрузочным тестом: календарный план на 20 тысяч строк она выдержала. В конце 2024 года показали ее первой пилотной группе. Группа была небольшая и работала на тестовых стендах, где еще не было интеграций. Мы провели восемь демо и два обучения, и пользователи поставили системе 6,8 балла из 10. Оценка невысокая, но основные замечания были не к самой системе, а к тому, что она ни с чем не связана. Мы собрали все комментарии в реестр и дальше сверяли с ним свои планы.
Больше всего участникам пилотной группы не хватало данных из финансовой системы. В Clarity такой интеграции не было, системы жили отдельно друг от друга. Мы и сами с самого начала предполагали, что она понадобится, и пилот это подтвердил. Пользователи описали, какие данные и в каком виде хотят видеть, и мы сделали интеграцию практически с нуля. О ней расскажу ниже.
Были замечания и к интерфейсу. По ним мы перенастроили карточки активности и ресурса, списки и представления. А еще пилот показал, что коробочный модуль учета времени не подходит под наши сценарии списания времени трудозатрат на проекты. Своя система учета у нас уже была, поэтому от модуля мы отказались.
Время сотрудники списывают в нашей собственной системе или в таск-системе. Раньше эта система была, по сути, интерфейсом к Clarity, поэтому вместе с ИСУП ее пришлось перевнедрить. Сделали это не сразу, а в апреле 2026 года, когда закончили первую часть миграции. Теперь данные о списаниях попадают в Directum Projects.
Новую общую оценку мы пока не собирали.Отдельные доработки оцениваем по ходу и по каждой спрашиваем пользователей, решила ли она их задачу.
Что взяли из коробки и что доработали
Почти без изменений мы используем коробочное календарное планирование и хранение проектных документов. В планирование добавили несколько полей для данных из финансовой системы и выгрузку плана в формате MS Project, а в работе с документами слегка адаптировали базовые сценарии.
Остальное пришлось дорабатывать под то, как у нас устроен учет. Данные о сотрудниках приходят из кадровой системы, и в карточке сотрудника не хватало нужных нам полей: ресурсного менеджера, тимлида и внутреннего идентификатора. С нормами рабочего времени пришлось повозиться больше. Коробочный календарь рабочего времени мы заметно переделали в части логики: как он заполняется и как хранит данные. Еще добавили формы, чтобы норму сотрудника можно было поменять вручную.
Похожая история была с данными из старой системы. Сущности Clarity не совпадали с коробочными один в один, и часть полей нам тоже пришлось добавить. Но переносить все подряд мы не стали. Еще до внедрения, когда прорабатывали встраивание в ландшафт, аналитики прошли по каждому атрибуту каждой сущности. В итоге мы отказались от 15–20% полей как от устаревших.
Платформа Directum RX позволяет кастомизировать систему на трех уровнях, и мы пользуемся всеми:
Настройка без кода. Ее делают команда поддержки и аналитики прямо в системе. Так меняются ролевая модель, карточки, представления и бизнес-процессы.
Low-code силами разработчиков. Разработчик добавляет элементы на карточку и привязывает к ним логику в коде, расширяет или переопределяет методы платформы. Этим уровнем мы пользуемся чаще всего.
Полноценная разработка. К ней переходим, когда возможностей low-code не хватает.
Код мы дорабатываем в Directum Studio, среде разработки от вендора. Ее возможностей нам хватает: в ней мы ведем и low-code, и полноценную разработку.
Запросы на доработки приходят к аналитикам от пользователей и владельцев процессов. Если задачу можно закрыть настройкой, аналитик делает ее сам, и это заметно быстрее, чем цикл с разработкой.
Ролевая модель
Ролевую модель мы собрали из коробочных ролей и того, что было в старой системе. Доступ к активности определяется проектной ролью, которую менеджер назначает сотруднику при добавлении в команду. Команда управления может менять в активности почти все. Администраторы проекта работают с задачами и календарным планом, но состав команды менять не могут. Остальные участники только списывают время.
Мы сами сделали синхронизацию проектных ролей с коробочными, которые отвечают за доступ к модулям и связаны с лицензиями. Остальное в ролевой модели можно менять настройкой.
Интеграции: все через шину
ИСУП почти не общается с другими системами напрямую, все обмены идут через корпоративную шину, как того требует наша архитектура. В нашем проекте это оказалось очень кстати, но об этом чуть позже.
Часть данных синхронизируется онлайн. Когда сущность меняется в мастер-системе, например обновляется активность, событие рассылается всем подписанным системам. Остальное передается точечно, конкретной системе, по запросу или по триггеру.
Старт проекта ИСУП получает из BPM-системы. Кадровая система передает справочники должностей, подразделений и сотрудников, а также отпуска и больничные, а в ответ узнает, в каких проектах занят сотрудник. В корпоративную отчетность уходят активности, задачи, списания и связанные справочники.
Финансовая система
Из финансовой системы в ИСУП приходит структура этапов активности, зафиксированная на старте. По ней Directum Projects автоматически строит предварительный календарный план, а менеджер его детализирует.
Обмен работает и в обратную сторону. Если менеджер меняет в плане сами этапы ( например, переименовывает, сдвигает даты, добавляет новый или удаляет старый), финансовая система узнает об этом автоматически, как только план сохранен. Остальные правки в плане туда не уходят.
Эта интеграция далась нам тяжелее остальных, причем больше всего времени ушло не на разработку. Мы долго согласовывали с фокус-группой процессы и подгоняли их под возможности коробки. Не раз выяснялось, что платформа работает иначе, чем мы закладывали, и решение приходилось переделывать, поэтому заходов понадобилось несколько.
Таск-система
Если менеджеру нужно вести работу по задачам в таск-системе, он ставит на задаче в ИСУП признак интеграции. Дальше команда работает и списывает время там, а эти списания сразу попадают в ИСУП. Одни менеджеры привязывают весь проект к одной задаче плана, другие разносят работы по нескольким. Закрыть задачу в ИСУП, пока у нее есть открытые связанные задачи в таск-системе, не получится: статус откатится назад, а пользователь получит уведомление на почту.
Собственная система учета времени работает через интеграционные методы ИСУП. Сотрудник открывает ее, и она запрашивает у ИСУП его списания за выбранный период и доступные задачи. Когда он сохраняет изменения, они тем же путем уходят обратно.
Мастер-системой по списаниям при этом считается ИСУП, в ней сходятся данные о трудозатратах всей компании. За расхождениями с таск-системой следит корпоративная отчетность: она получает данные из обеих систем и сравнивает их. Если что-то не сошлось, в поддержку падает заявка, и списания синхронизируют повторно.
Отказываться от таск-системы мы не планируем. В Directum Projects есть свой модуль для гибкой работы, но наши команды давно привыкли к своему инструменту, и менять его мы не видим смысла.
Две системы параллельно
Вторую половину 2024 года мы проектировали и разрабатывали, а в феврале 2025-го запустили опытную эксплуатацию в боевой среде. Заходили несколькими волнами и каждую группу пользователей сначала обучали.
Переводить всех пользователей и все проекты разом мы не стали. В Clarity лежали данные за много лет, а механизма миграции у нас еще не было. Отчетность ежедневно забирает данные из всех связанных систем, и любая ошибка при одномоментном переносе сразу отразилась бы в отчетах. К тому же постепенный переход оставлял возможность вернуться назад, если с новой системой что-то пойдет не так. Поэтому Directum Projects мы запустили рядом с Clarity и переводили проекты в него по частям.
В опытной эксплуатации в новой системе заводили только активности, которые стартовали с нуля. Начали примерно с десяти и постепенно наращивали объем. Все, что уже шло, продолжало жить в Clarity, пока мы не дошли до миграции.
Как шина развела потоки
Здесь как раз пригодилось то, что все интеграции идут через шину. В Clarity и в Directum Projects мы добавили активности новый признак «ведется в Projects», а на шине завели оркестратор с таблицей, где хранятся коды таких активностей. По этой таблице шина и решала, куда отправлять данные. Допустим, у активности обновилась стадия. Если кода активности в таблице нет, обновление уходит в Clarity, если есть, то в Directum Projects.
С исходящей синхронизацией так же. По активности, которая ведется в новой системе, обмен с Clarity перекрыт, и наоборот.
Теперь о том, как активности попадали в таблицу. В фокус-группу мы набирали людей открыто и прямо говорили, что именно их опыт определит, какой будет новая система. Подключиться можно было двумя способами: целиком, со всеми своими новыми активностями, или только с некоторыми. Оркестратор сначала смотрел на менеджера. Если тот подписан целиком, активность уходила в новую систему, а ее код добавлялся в таблицу. Если нет, проверялся список отдельных активностей.
Поначалу признак мы ставили вручную, точечно по тем активностям, которые переводили. Потом доработали интеграцию, и активность, созданная в Directum Projects, стала попадать в оркестратор автоматически. При миграции признак тоже ставится сам, как только перенос завершился успешно.
Между собой две ИСУП активностями не обменивались вообще. Каждая обновляла только свои, поэтому конфликтов, когда один объект правят в двух местах, у нас не было. Единственное, что передавалось из одной системы в другую, это нормы сотрудников. Их по-прежнему вели в Clarity и оттуда отправляли в новую систему, чтобы данные не расходились. В апреле 2026 года управление нормами и ресурсами заработало в Directum Projects, и эту связку мы отключили.
Доработки затронули только шину и корпоративную отчетность. Отчетности нужно было собирать данные из двух ИСУП и не задваивать их. Для BPM, таск-системы и остальных участников цепочки ничего не поменялось, их мы начали дорабатывать позже, когда уже развивали Directum Projects.
Миграция
С ноября 2025 года все новые активности заводятся уже только в Directum Projects. Тогда же мы начали точечно переносить активности менеджеров, которые хотели перейти быстрее. За массовую миграцию взялись в конце декабря.
Сначала переносили то, что нужно менеджерам в работе: все открытые активности и закрытые, по которым были списания за 2024–2025 годы. Всего 5253 активности. Они переезжали целиком, с планами, задачами и командой, и каждую сверяли аналитики. Перед миграцией они выгружали данные из отчетности, а на следующий день смотрели, что было и что стало.
Шло это неровно. С середины ноября до конца декабря мы миграцию обкатывали и переносили в среднем по четыре активности за день. В январе темп вырос до 24 активностей за день миграции. В феврале мы остановились совсем, потому что сверка показала ошибки. И только в марте и апреле вышли на 230 активностей в день.
Сверка нужна была не для галочки. Тестовый стенд не может повторить все, что накопилось в боевой системе за годы работы, и все ошибки, о которых расскажу ниже, проявились только на реальных данных.
Проблемы были связаны со списаниями. На первых же переносах сверка показала, что Clarity обнуляет все списания в табеле сотрудника, а не только по той активности, которую мы переносим. Чтобы не задваивать данные в отчетности, при миграции мы сначала обнуляли списания в Clarity, а потом создавали их в Directum Projects. Поправили это быстро и ничего не потеряли.
Вторая проблема вылезла, когда выросли объемы переноса. В активностях, которые мигрировали одновременно, были заняты одни и те же люди. А Clarity не умеет вносить несколько изменений в один табель за раз и на каждую корректировку создает новую версию табеля. Часть списаний при переносе не доходила до новой системы. Пришлось придумывать алгоритм, который находит такие случаи, и восстанавливать их в Directum Projects запросами и руками.
Еще одно расхождение нашлось на стыке с соседней системой. После переноса в BPM оставалась ссылка на задачу в Clarity, и отчетность на следующий день считала распределение по направлениям неверно. Сверка поймала и это, ссылки перенастроили.
К апрелю 2026 года с этой частью закончили. С этого месяца в Clarity не ведется ни один проект, а списание времени там заблокировано.
Потом дошли руки до архива. Это 28 тысяч активностей, которые давно закрыты. Менеджеры в них не заглядывают, а вот отчетность по ним строится, так что перенести нужно в любой случае. С конца августа 2026 года переносим, но в урезанном виде: только саму активность и проектную команду, без планов с задачами и без списаний. Для этого миграцию пришлось доработать. Каждый день консультант поддержки согласовывает список и запускает перенос. Сейчас осталось около 20 тысяч.
Пользователей это никак не затрагивает. Доступа в Clarity у них нет уже полгода, и за это время никто не пришел с просьбой показать старый проект, который еще не переехал. Если придет, выдадим временный доступ.
Clarity сейчас живет только ради отчетности по старым активностям. Закончим с архивом, отключим ее от интеграций, и как приложение она работать перестанет.
Эксплуатация: релизы и обновления платформы
У каждого нашего разработчика КРОК есть виртуальная машина с полным стендом Directum и средой разработки. Общих стендов три: тестовый, предрелизный и боевой. Еще два выделены под отдельные задачи: на одном мы проверяем обновления платформы, на другом тестируем крупные доработки, которые выкатываются одним большим пакетом. База данных у системы PostgreSQL, для очередей сообщений используется RabbitMQ.
Готовая доработка сначала попадает на тестовый стенд и проходит функциональное тестирование. Если она затрагивает обмен с другими системами, следом идет интеграционное. Затем то же самое повторяется на предрелизном стенде, и только после этого обновляется боевой. Выкатываемся обычно по пятницам, иногда несколько раз за спринт.
Обновление версии платформы устроено иначе и идет заметно тяжелее обычного релиза. Сейчас мы проходим его в третий раз, переходим на версию 26.2.
Мы получаем у вендора дистрибутив новой версии, и разработчики адаптируют наши доработки, чтобы версия вообще развернулась на стенде обновлений. Затем тестировщики проводят регрессионное тестирование, а аналитики разбирают, что изменилось в коробке и как это ложится на наши процессы. Каждую новую функцию мы либо берем и адаптируем под нее процесс, либо скрываем и отключаем. После доработок и повторного тестирования новая версия объединяется с текущими задачами на тестовом стенде, проходит предрелизный и попадает на боевой.
Весь цикл занимает до двух месяцев, а по трудозатратам прошлое обновление обошлось примерно в 100 человеко-часов. Сколько выйдет в следующий раз, зависит от того, что поменял вендор. Последняя версия, например, затронула много методов платформы, которые мы переопределяли, и работы было больше обычного. Тестировщики за это время несколько раз проходят практически полный цикл регрессионного тестирования.
Это долго, и можно было бы уложиться быстрее, если отложить остальные задачи. Но мы этого не делаем. Обновление идет на отдельном стенде, работа над текущими задачами не останавливается, а пользователи ни разу не пострадали от новой версии платформы.
Что изменилось и что бы сделали иначе
Мы ушли с системы, которая перестала успевать за компанией. Но для менеджеров проектов главное изменение в другом.
В Clarity у нас не было полноценного календарного планирования. Менеджеры заводили в активности 10–15 задач, и нужны они были только для того, чтобы команде было куда списывать время. Настоящие планы с иерархией и связями вели отдельно, в MS Project. Получалась двойная работа. К тому же у руководства не было места, где можно посмотреть все планы сразу.
Теперь план ведется в Directum Projects с самого начала. Среднее число задач в нем выросло несильно, до 18–20, но среднее тут мало что показывает: одним проектам хватает десятка задач, другим нужно гораздо больше. Показательнее другое. За последние три недели планы обновляли 600 раз, то есть с ними работают, а не заводят для галочки. Если план нужно показать человеку без доступа в систему, он выгружается в формате MS Project одной кнопкой, и вести второй план отдельно больше не нужно.
С отчетами тоже стало проще. В самой Clarity их не было, и состояние проекта можно было посмотреть только в корпоративной отчетности, которая обновляется раз в сутки. Теперь отчеты по проекту строятся прямо в ИСУП. А пилотная группа менеджеров пробует ИИ-аналитику: мы даем модели данные по проектам и готовые промпты с метриками и типовыми шагами менеджера, и она подсвечивает риски и пробелы в плане. Это пока пилот.
Что бы мы сделали иначе, если бы начинали сейчас? С первого дня вели бы реестр особенностей платформы. Часть из них видна сразу, в интерфейсе, а другая обнаруживается только на этапе разработки. Например, в плане проекта нельзя по условию заблокировать отдельные поля от редактирования. Мы узнали об этом, когда делали обмен с финансовой системой, и в итоге при сохранении плана у нас срабатывает много проверок. Или интерфейс: глубоко его перестроить нельзя, и некоторые сценарии выглядят не так, как мы рисовали вначале.
Само по себе это нормально, у любой платформы свои правила. Но о некоторых из них мы узнавали поздно, и часть задач приходилось перепроектировать, а цикл разработки по ним начинался заново. Если бы каждую такую особенность мы сразу записывали в общий реестр, лишних заходов было бы меньше.
Проект еще не закончен. До конца года мы переносим архив и после этого выключим Clarity. Если вы проходите через похожую замену или только готовитесь к ней, пишите в комментариях. Расскажу подробнее про шину, сверку при миграции и обновления платформы.