Управление в темноте: почему проекты ESB, MDM и BI нельзя вести как классическое внедрение ERP

У нас был проект, о котором мы внутри команды до сих пор говорим: «тот самый».

Отклонение от плановых часов у нас составило больше чем в два раза. Не 20%, не 50% — почти в два раза. При этом были и процессы, и метрики, и статус-встречи, и опытная команда. Но в один момент все это просто не сработало к дате, когда мы ждали результата.

Сегодня я хочу поговорить про особые технологические проекты и про то, почему иногда управление ими идет в темноте. Для нас технологические проекты — это интеграционные шины, корпоративные хранилища данных, MDM-системы, BI-системы, системы управления мастер-данными. То есть все то, что встраивается в ИТ-ландшафт заказчика и связывает системы между собой.

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

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

Вот фундамент, заложили коммуникации, вот стены, вот крыша. Прогресс очевиден заказчику. Он приезжает каждую неделю и видит прогресс, как растет наш дом и даже район рядом с ним.

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

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

Есть схема, которую предлагает аналитическая компания Gartner: стратегия управления приложениями. Суть простая: все приложения можно разделить на три слоя в зависимости от скорости изменений и роли в бизнесе.

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

Наши проекты — это инфраструктура данных, которая заставляет разные слои работать вместе. MDM находится на стыке первого и второго слоя. Такая система создает золотую запись, чтобы системы учета не противоречили друг другу. BI пронизывает все три слоя. Снизу это может быть стандартная отчетность, операционная аналитика, которой мы пользуемся каждый день. В середине — специфичные дашборды для стратегических решений. Наверху — предиктивная аналитика и новые сценарии работы с данными. А ESB — это не слой сам по себе. Это инфраструктура между слоями. Интеграционная шина — это те самые дороги и трубопроводы нашего города.

Приведу пример. Банк хочет запустить чат-бота в Telegram. Срок жизни гипотезы — один месяц. Задача простая: дать клиенту возможность проверить остаток по счету. Если бот идет напрямую в ERP, одна небольшая гипотеза становится риском для ядра учетной системы.

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

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

По поводу связанности поделюсь своей находкой. Не так давно я нашел в электронной библиотеке книгу Грегора Хопа, известного системного архитектора, одного из авторов книги «Шаблоны интеграции корпоративных приложений».Он описал теорию семи типов связанности между системами. Это те самые невидимые нити, которые делают интеграцию сложной.

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

MDM говорит нам: контрагент такой-то — это одно и то же во всех системах. Мы понимаем, как с ним работать. BI уже дает визуальную составляющую этой сложной связанности. Все эти системы работают с невидимым слоем: с семантическими несоответствиями и скрытыми зависимостями. Именно поэтому прогресс так трудно показать, когда работа происходит там, где заказчик не видит привычного ему визуала.

У Грегора Хопа есть еще одна концепция. Он назвал ее гремлинной трансформацией. Такие маленькие невидимые вредители появляются в каждой серьезной интеграции корпоративных приложений.

Немного истории. Нефтяной кризис 1973 года положил конец эпохе американских больших маслкаров. Производители начали строить компактные экономичные автомобили. Но все, что они умели, — это строить большие машины. Компания AMC решила задачу просто и быстро. Так на свет появился AMC Gremlin. Машина снаружи выглядела компактной, но под ее огромным капотом помещался пятилитровый двигатель V8. Это был не компактный автомобиль, а большой автомобиль с укороченным задним кузовом. Немцы из Volkswagen в тот момент показали компактный автомобиль на новой платформе. Volkswagen Golf 1974 года стал одной из самых долгоживущих моделей в истории именно потому, что команда начала с чистого листа.

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

Что мы получаем? Мусор на входе — мусор на выходе.

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

Теперь как это все выглядит на практике. Я хочу поговорить о трех методах, которые мы привычно применяли на ERP-проектах, а потом перенесли на технологические проекты.

Начнем с практических кейсов.

Крупная аналитическая компания, наш клиент. Стояла задача просто заменить старый Oracle на 1С:ЗУП. У проекта был свой руководитель со стороны заказчика. Представление было простое: меняем одну систему учета, старую, на новую. Был выбран классический подход — водопад (сначала проектирование, потом разработка и запуск).

Наша роль — отдельная команда во главе с техлидом. Нужно было связать новую ЗУП с остальным ИТ-ландшафтом через корпоративную шину данных. Архитектурно Oracle выступал промежуточным слоем для упрощения интеграционных потоков и загрузки данных. Через него мы обменивались с другими источниками и системами.

Казалось, в такой структуре никаких подводных камней нет. И все приняли это видение. У нас была красивая иерархическая структура работ, диаграмма Ганта, единый график для всех команд. Мы разбили спринты для разработчиков.

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

В плане эта зависимость не учитывалась.

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

Главный руководитель проекта смотрит в отчет и говорит: коллеги из интеграции, у вас закрыто 60% задач. Давайте на следующей неделе покажем заказчику, как данные идут из Oracle в ЗУП. А заказчик на статусе видел только структуру JSON-пакетов из источника в редакторе. Классический план проекта не видел текущей связанности.

Весь этот процесс не был рассчитан на работу между слоями и описание промежуточного результата для интеграционного решения. Для ЗУП промежуточный результат был зафиксирован сразу. Для интеграционного решения — нет. Таким образом, у нас сломался первый метод — оценка прогресса.

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

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

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

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

Первый проект на новой отечественной платформе в связке ESB плюс MDM. Мы давно работали с вендором, знали его текущие продукты, прошли обучение, сертификацию. Были тесты в песочнице.

А практика, как обычно, преподнесла сюрпризы. К нам обратился клиент из ритейла по внедрению этой платформы в свой ИТ-ландшафт. Было несколько источников: учет остатков в разных 1С, загрузка из файлов, обмен с мобильными приложениями. Все это приводило к хаосу в структуре хранения золотой записи, в операциях на уровне менеджеров и клиентского сервиса, в обработке заказов.

Если вспоминать слои Gartner, это третий слой — слой инноваций. Новая платформа, первый опыт, высокая неопределенность. После этого решение должно было спуститься на второй слой.

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

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

Дальше одна проблема тянула за собой другую. В ERP-проекте, если сравнивать, ошибка в блоке зарплаты не обязательно ломает закупки. А здесь один баг в формате данных мог повлиять на бизнес-логику, синхронизацию и обмен в целом. Это была не линейная цепочка, а паутина зависимостей.

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

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

Только итерации здесь не произвольные спринты, а четко определенные фазы с конкретными критериями готовности.

Покажу, как это работает на практике. Мы внедряли у себя 1С:Аналитику, BI-систему и корпоративное хранилище данных. Мы были и заказчиком, и исполнителем. Проект начинался как задача первого слоя: консолидация данных в единую точку для получения быстрой сводной информации.

Что было дано?

Десятки разных систем: 1С, ЗУП, документооборот, другие системы, Bitrix, внешние HR-системы, Google-таблицы.Формирование одного отчета, например БДР, занимало от трех до пяти часов. На выходе мы должны были получить быстрые дашборды.

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

Мы бы действительно увязли, но мы пошли по фазам. На первой фазе не стали строить тяжелое хранилище. Приняли временное решение: за пару недель проверить, можем ли мы вообще забрать данные из ERP, из других систем и свести их вместе. Поняли, что да, можем. Но тут же появилась зависимость.

После этих проектов мы пересмотрели не только подход к планированию, но и сами метрики.

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

Похожие наблюдения из практики проектного управления я собираю в канале «Своя дистанция | Дмитрий Рыбаков» — @Rybakov_IT_Project.