Приключения на пути автоматизации торгово-логистических процессов «КОМОС ГРУПП» – увлекательные и не очень

Читать кейс проекта

Продолжаем цикл статей об особенностях мультипроектной работы на примере цифровой трансформации агрохолдинга «КОМОС ГРУПП», реализуемой при поддержке РФРИТ.

В прошлой статье Александр Пискарев – ИТ директор «КОМОС ГРУПП» выделил 5 ключевых особенностей управления «упряжкой» подрядчиков.

Компания Константа и проект внедрения «1С: УТ» в этом портфеле проектов был одним из шести параллельно внедряемых систем. Если смотреть на задачу внедрения системы управления торговлей с точки зрения самой предметной области, то она может и не выглядит сильно уникальной. Но учитывая, что она внедрялась в торгово-сбытовом подразделении крупного холдинга, и там каждая из 13 функциональных областей проекта была сама минипроектом – восприятие уникальности и масштаба проекта меняется.

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

ОЧЕНЬ ШИРОКИЙ, НО ПРИБЛИЗИТЕЛЬНЫЙ ИТ ЛАНДШАФТ

ИТ ландшафт, с которым торговая система должна взаимодействовать, на начальном этапе составлял 32 системы. В их числе «1С:ERP», «1С:УХ», несколько WMS-систем, система транспортной логистики, три системы документооборота и набор технических систем. Кроме того, что состав ИТ систем был широкий, он был еще и неточный. Нам приходилось существовать в динамически меняющемся ИТ ландшафте. За время проекта часть соседних систем поменялись, часть – отмерло.

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

Как решали:

• Интеграционный архитектор

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

• ИТ консалтинг, оптимизация ИТ ландшафта

На входе в проект весь этот ИТ ландшафт был проанализирован и оптимизирован с интеграционной точки зрения.

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

• IMS система

Мы начинали работу по описанию требований к интеграционным потокам с google-табличек: выписывали потоки, разбивали до объектов, потом детализировали до структуры данных. В какой-то момент мы поняли, что для 30+ систем это уже что-то невообразимое. И наш интеграционный архитектор озадачился вопросом написания системы – отдельной конфигурации Integration management studio. Это выделенная специализированная система, которая позволяет управлять интеграционными требованиями. Без этого инструмента, мне кажется, мы бы не вывезли этот проект в части интеграций.

КОНКУРЕНЦИЯ ЗА ВРЕМЯ И ИНТЕРЕСЫ БИЗНЕС-ЗАКАЗЧИКОВ С СОСЕДЯМИ-ПОДРЯДЧИКАМИ

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

Но любопытнее была конкуренция за интересы. История с гибким ландшафтом несет в себе соблазн сдвигания границ. Пример: «А давайте определенные признаки НСИ по заказу номенклатуры вести не в MDM, а в «1С:УТ» или в CRM». А они параллельно внедряются.

Как решали:

• Калибровка и отладка подходов к принятию решений

С каждым подрядчиком для каждой ситуации надо было откалибровать систему принятия решений. Были выстроены определенные ритуалы и мы просто садились и договаривались, а не замалчивали проблемы и не «заметали мусор под ковер».

• Управление отношениями и ожиданиями

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

• Система ритуалов проекта

Регулярно раз в неделю проводили оперативку с бизнесом (со всеми ключевыми бизнес-заказчиками), на которой обсуждали статус и все проблемы. Отсюда дальше планировали рабочие встречи. Это было очень сложно. Иногда получалось, что время у всех нужных людей находилось не на этой, не на следующей, а еще через неделю.

КРИТИЧНЫЕ ДЛЯ БИЗНЕСА LEGACY-СИСТЕМЫ С НЕДОСТУПНЫМИ ИЛИ ПОТЕРЯННЫМИ КОМПЕТЕНЦИЯМИ

Одна из основных legacy-систем – это Аксапта (та, с которой КОМОС уходил). Всего в проекте таких было три. Потерянные компетенции заключаются в том, что система есть, но как она работает – не знает ни бизнес, ни ИТ. Это очень «увлекательное» приключение – разбираться, а как нам с этими системами интегрироваться. Как технически, так и методологически. Существует сквозной процесс между системами, и он должен корректно отрабатывать в обе стороны.

Как решали?

• Индивидуальные «команды инвалидов», обеспечивающие минимальный уровень методологии

Если нет методологической экспертизы, собираем по кусочкам. Пример: на стыке с Аксаптой для решения интеграционных задач нам надо было решить определенные методологические вопросы. Собирали специалиста Аксапты, бизнес-пользователя, который с этим процессом взаимодействует, технического специалиста с нашей стороны и сидели думали.

• Смирение и принятие возможного темпа

Хотелось бы быстрее, но нет.

ТРЕБОВАНИЯ ОБЕСПЕЧИТЬ ЦЕЛОСТНУЮ ПРОИЗВОДИТЕЛЬНОСТЬ ДО ЗАПУСКА СИСТЕМЫ

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

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

Как решали?

• Согласование ключевых (чувствительных для бизнеса) операций

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

• Создание стенда мониторинга с генерацией целевой нагрузки

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

• Поэтапный запуск системы с мониторингом допустимой производительности

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

НЕПРЕРЫВНАЯ БОРЬБА ЗА СОХРАНЕНИЕ ГРАНИЦ ПРОЕКТА

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

Как решали?

• Аргументированный отказ от требований, которые можно запускать после общего запуска

Те задачи, которые в проект не входили и которые можно было не делать, просто вычеркивались.

• Расширение границ дополнитеьными задачами, которые невозможно не делать (ФГИС Зерно, УКЭП с МЧД, ЧЗ)

ПОДВЕДЕМ ИТОГ

Выученные уроки:

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

Читать кейс проекта