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

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

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

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

Главная проблема в том, что к таким проектам часто применяют инструменты, которые хорошо работают в классических ERP-внедрениях. Но в проектах ESB, MDM и BI эти инструменты могут давать сбой.

Почему ERP и технологические проекты нельзя вести одинаково

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

Технологический проект — другое.

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

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

Где живут технологические проекты в ИТ-архитектуре

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

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

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

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

Почему связанность делает интеграцию сложной

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

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

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

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

MDM говорит: этот контрагент — один и тот же во всех системах. BI показывает результат этой сложной связанности в аналитике.

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

Гремлины технологических проектов

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

В технологических проектах есть свои гремлины.

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

Эти гремлины молчат в начале проекта и появляются в самый неподходящий момент. Обычно — перед сроком сдачи.

Как ломаются классические методы на практике

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

Ошибка 1. Считать закрытые задачи работающим результатом

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

В технологических проектах все устроено иначе.

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

Типовая ситуация: компания меняет одну учетную систему на другую, а интеграционную шину включает в общий график как вспомогательный модуль. Формально все выглядит логично: есть команда основной системы, есть команда интеграции, есть общий план и контрольные точки.

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

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

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

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

Ошибка 2. Считать команды автономными, если системы зависимы

Вторая ошибка — считать, что автономность команд автоматически означает автономность систем.

В классическом плане это выглядит логично: одна команда отвечает за учетную систему, другая — за интеграцию, третья — за аналитику. У каждой свой участок, свои задачи, свои встречи по статусу. Синхронизация происходит на контрольных точках.

Но в проектах ESB, MDM и BI системы связаны сильнее, чем это видно в плане.

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

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

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

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

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

Ошибка 3. Планировать новую технологию как полностью предсказуемую

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

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

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

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

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

К чему мы пришли

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

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

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

Как фазовый подход работает в BI-проектах

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

Поэтому в таких проектах важна фазовость.

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

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

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

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

Какие показатели нужны технологическим проектам

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

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

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

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

Главный вывод

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

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

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

Главная мысль простая: технологическим проектом нельзя управлять так, будто это еще один модуль ERP. Если работа идет между системами, в данных, связях и скрытых зависимостях, то и управление должно быть другим.