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

5 в 1: как умножение систем усугубляет хаос

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

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

Кроме того, для поддержки этого разнородного набора систем расширяется штат ИТ-специалистов, что закономерно ведет к росту совокупных затрат на владение. Апофеозом ситуации становится появление собственных разработок, когда компании, не найдя готового решения, начинают создавать «костыли» для недостающей функциональности. Эти самописные системы часто не имеют внятных API и лишь усугубляют и без того сложную картину.

Яркий пример — история с BI-системами после ухода с рынка западных решений. Крупные заказчики в процессе выбора нового вендора и внедрения сталкивались с ограниченными возможностями системы. Недостающие модули — например, для ETL (Extract, Transform, Load) — «достраивались» дополнительными слоями на базе open source, других продуктов или самописных решений. Через год выходила новая версия основного BI-продукта с долгожданной функциональностью, и начинался мучительный и затратный процесс переноса данных и логики. В итоге круг замыкается, а количество систем продолжает расти.

Миф о всесильности API. Когда интерфейсы не спасают

Первая реакция ИТ-руководителя на проблему разрозненности систем закономерна: «Есть API? Давайте свяжем через них». Наличие программного интерфейса, безусловно, решает множество задач. Но это не панацея, особенно в условиях современного российского ИТ-ландшафта.

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

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

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

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

Ключ к упорядоченной цифровой экосистеме не в увеличении интеграций, а в качестве данных

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

Так возникает потребность в Master Data Management (MDM) — управлении мастер-данными. Ключевой момент: MDM — это в первую очередь не система, а управленческий подход, методология создания «единого источника правды». Его нельзя просто купить и установить. Успешное внедрение требует зрелости процессов, четких регламентов и подготовленных специалистов.

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

Правильно выстроенная MDM-система выполняет роль «главного архивариуса». Она создает и поддерживает «золотые записи» по ключевым бизнес-сущностям: клиенты, продукты, контракты, сотрудники. Ее задача — очистить, унифицировать и обогатить данные, установив для всей организации единый стандарт описания. Так формируется тот самый надежный «единый источник правды».

Интеграционная шина как «кровеносная система» цифрового организма

Когда в центре ИТ-ландшафта появляется «единый источник правды» в лице MDM, наступает время обеспечить упорядоченное движение качественных данных. Для этого существует несколько технологий — от брокеров сообщений до более сложных платформ. Одним из ключевых решений для построения управляемой экосистемы является корпоративная сервисная шина (ESB). Она действует как «кровеносная система» цифровой экосистемы. 

Например, для выполнения бизнес-процесса по начислению зарплаты производственному персоналу нужны данные из разных систем: табели — из MES (системы управления производством), коэффициенты — из HRM (системы управления человеческими ресурсами), а ставки, например, — из ERP. Интеграционная шина должна собрать все эти данные, сконвертировать их в единый формат, трансформировать и доставить в соответствии с четкими правилами по назначению, предположим, в 1С.

Ее ключевая задача — автоматически и, по возможности, в реальном времени доставлять «золотые записи» из MDM во все системы организации (и забирать из них обновления). Шина, или более продвинутая ее версия, — интеграционная платформа — превращает разрозненные ручейки данных в управляемые потоки, работающие по единым, централизованным правилам, что минимизирует ошибки и обеспечивает сквозную трассировку.

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

От Excel-табличек к управляемой экосистеме

Теория становится убедительнее, когда подкреплена практикой. Рассмотрим два кейса, основанных на реальном опыте.

Кейс 1. Как крупный холдинг строил архитектуру данных с нуля

В этой истории крупная холдинговая структура исторически управляла своими ключевыми активами с помощью… множества разрозненных Excel-таблиц. Данные дублировались, версии путались, консолидированный отчет требовал недели ручной работы. Ситуация усугубилась после присоединения новых активов и ужесточения требований регуляторов по отчетности. Холдинг сначала внедрил интеграционную шину, чтобы как-то автоматизировать обмен между разными юрлицами и их системами (своими 1С, базами данных и теми самыми Excel-файлами). Это дало временное облегчение, но не решило проблему качества данных. Следующим шагом стал проект по внедрению MDM для создания единого реестра файловых активов. Подход «сначала шина, потом MDM» сработал, но был сопряжен с высокими издержками внедрения.

Кейс 2. Правильный старт для нового направления бизнеса

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

От путаницы к стратегическому преимуществу

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

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

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

Источник: IT World.

Больше новостей читайте в телеграм-канале SAPLAND: Новости экосистемы.