Привет, Хабр!
Сегодня хочу поделиться мыслями о том, почему внедрение ИТ‑систем — это не всегда про цифровизацию, и как это изменить. Тема навеяна недавним разговором со знакомым CIO.
Удивительно, но факт: часто в компаниях с очень развитым ИТ‑ландшафтом все равно все продолжают делать всё вручную. ИТ‑команда как не в себя пишет километры кода, лишь бы как‑то заставить системы работать вместе.
Кто‑то строит интеграции «точка‑точка», кто‑то пускает данные через брокера, кто‑то пытается приручить опенсорс. А некоторые уже перешли на готовые интеграционные платформы (ESB). Поговорим о каждом подходе к интеграции систем, чтобы наконец уйти от «ручников» к реальной цифровизации, где ИТ‑ландшафт работает на компанию, а не компания — на ИТ‑ландшафт.
Почему разрозненность ИТ‑систем умножает все усилия по цифровой трансформации на ноль
По работе я часто общаюсь с ИТ‑директорами и директорами по цифровой трансформации. Вижу, как в их управлении оказываются десятки информационных систем, а беклог задач по автоматизации бизнес‑процессов растёт быстрее, чем их успевают решать. Они внедряют современную российскую ERP, обновляют CRM, подключают интернет‑магазин, логистические платформы и внешние сервисы для работы с госорганами — и искренне ждут, что это ускорит работу, освободит от рутины, позволит добиваться больших результатов меньшими ресурсами.
Но проходит время — и картина меняется. Сотрудники тратят часы на ручной перенос данных между системами. Менеджеры отдела продаж жалуются, что заказы «теряются» на стыке интернет‑магазина и склада. Финансовый департамент не может получить консолидированную отчётность в реальном времени, а директор по производству регулярно сообщает, что данные из разных систем и датчиков расходятся.
Факт, от капитана очевидность, с которым сложно поспорить: ИТ‑системы должны обмениваться данными без участия человека. Иначе зачем вообще цифровая трансформация?
И каждый раз, когда я вижу, что компания решает эту проблему по классике — нанимает разработчиков и начинает накидывать интеграции «точка‑точка», — у меня дергается глаз. Потому что я знаю, чем это кончится.
«Спагетти» из интеграций, в которых никто не разберётся
Пока в организации до 5 систем — всё работает и все счастливы. Но как только их становится сильно больше и что‑то ломается (а это неизбежно случается при первом же обновлении любой из систем), начинается хаос.
Интеграция А и Б написана одним разработчиком, Б и В — другим. Где упали данные? Какой сервис не ответил? Кто виноват? Найти проблему можно только методом перебора. Команда теряет время, а бизнес — деньги.
В итоге ведущий разработчик тратит дни (а то и недели), чтобы понять, почему вдруг перестали ходить заказы из магазина на склад. И всё это время бизнес‑процессы стоят. Менеджеры по‑старинке руками ищут и актуализируют данные, директор по производству мысленно прощается с годовой премией.
А когда все починили, еще несколько лет команда может продолжать пилить точечные интеграции. Пока в какой‑то момент не оказывается, что просто сменить или обновить одну систему уже невозможно — на неё завязаны десятки самописных связок. Всё — конечная — выходим...
Только в этот момент в большинстве случаев начинаются поиски альтернативного решения.
Как объяснить бизнесу, что ESB — не «айтишная блажь», а экономия бюджета?
Как правило, в этот момент в компании впервые звучит предложение внедрить шину данных (ESB, корпоративная сервисная шина, интеграционная платформа — называться может по‑разному).
Возможно, и вы уже пробовали зайти в кабинет к финансовому директору с предложением: «Давайте купим интеграционную платформу». И в ответ слышали: «А что это даст? Вот CRM повышает конверсию, 1С — сдаёт налоговую отчётность, MES — следит за производством. А ESB нам зачем? Команда и так справляется, к чему лишние траты?»
Знакомо? Я сам не раз сидел в таких переговорных. И знаю, что если ответить «ESB нужен для интеграции ИТ‑систем», — это звучит как роскошь, когда бюджет и так сжат до предела.
Вот — цифры из реального кейса, которые обычно помогают договориться с финансистами:
«Газпром‑Медиа Холдинг» построил единую экосистему управления данными на базе нашей интеграционной платформы «Интегра». До внедрения у них было больше 25 информационных систем, соединённых точечными связками. Каждая новая интеграция — недели разработки, ручной труд, постоянные сбои.
Что получили после внедрения:
● Срок создания типового маршрута сократился с пяти дней до одного рабочего дня — ускорение в 3–5 раз.
● Стоимость одной интеграции снизилась более чем в 4 раза.
● Автоматизировано более 100 уникальных сценариев обмена данными.
● Доступность сервисов и мониторинга — 96%.
● Первая очередь запущена за три месяца, включая опытно‑промышленную эксплуатацию.
● Команда перестала быть пожарной бригадой — ИТ‑актив холдинга стал технологическим акселератором бизнеса.
И что ещё важно: крупный медиахолдинг с жёсткими требованиями к безопасности и нагрузкам получил такой результат за три месяца.
А может, обойдёмся брокером или опенсорсом?
Я слышу этот вопрос постоянно. «Зачем платить, если есть Kafka, RabbitMQ или опенсорс‑шина?»
Брокер — это, по сути, просто труба. Крутая, надёжная, быстрая. Но она не знает, что за данные вы в неё кидаете, и ей плевать, доберутся ли они до получателя в нужном формате. Она не умеет трансформировать форматы, маршрутизировать по содержимому, обрабатывать ошибки бизнес‑логики.
Где они хороши: когда вам нужно просто и быстро переслать сообщение из одного сервиса в другой, без лишней логики. Логи, метрики, события, очереди задач — здесь брокер вне конкуренции.
Но есть тонкий момент: брокер не знает, в каком формате лежат данные в вашей CRM и что ожидает получить ERP. И главное — он не контролирует, что происходит с данными после того, как отправил их получателю.
Представьте: складская система упала на обновлении. Брокер честно отправил заказ, получил ошибку и… что с ним делать? Повторить? Когда? А если повторять бесконечно, очередь забьется. А если не повторять — заказ потеряется. Брокер перекладывает эту логику на вас. В результате вместо полной автоматизации вы пишете дополнительный слой кода. Получается как на картинке: труба, а рядом куча «спагетти» из кода.
Опенсорс‑платформы — это свобода, но с нюансами. Да, есть сильные команды, которые берут Apache Camel или WSO2 и дорабатывают. Но по факту получается, что «бесплатно» — только на входе. Посчитайте, сколько времени ваша команда потратит на изучение чужой архитектуры, отладку непонятных ошибок. В пересчёте на зарплаты это часто выше лицензии на готовое решение.
При этом есть моменты, которые важно учитывать:
Безопасность. Большинство опенсорс‑решений развиваются западными сообществами. Если у вас объекты КИИ или требования по импортозамещению — это прямой риск. Нельзя гарантировать отсутствие закладок или критических уязвимостей. Проверять десятки тысяч строк кода? Дорого и долго.
Поддержка. Вы остаетесь один на один с кодом. Да, есть комьюнити, но ответят вам «по мере возможности», а не по SLA. А в условиях, когда западные вендоры ушли с рынка, рассчитывать на своевременные обновления не приходится.
В итоге получается, что «бесплатно» — только на входе. Посчитайте, сколько времени ваша команда потратит на то, чтобы разобраться в чужой архитектуре, подкрутить ее под свои процессы, отладить непонятные ошибки. Если пересчитать эти часы в зарплаты, цифра может оказаться выше, чем лицензия на готовое решение.
Я видел много компаний, которые пытались сэкономить: брали брокера, писали свои скрипты, собирали опенсорс. Сначала всё работало. Но проходил год‑полтора, и они упирались в ту же стену: сотни связок, ни одной документированной схемы, каждый новый сервис — боль, поддержка отнимает 80% времени. И все они — с разной скоростью, через разное количество граблей — приходили к одному выводу: пора перестать множить хаос и начать управлять ландшафтом.
Что в итоге?
Если у вас 2–3 системы и они почти не меняются — может, вариант с точка‑точкой, сойдет. При сравнительно простом обмене данными подойдет брокер. Когда вы готовы разбираться в чужом коде, поддерживать его самостоятельно и вас не смущают вопросы безопасности, можно взять опенсорс.
Но если вы хотите реальной цифровизации, где процессы автоматизированы, а данные между системами обмениваются самостоятельно без ручного внесения и ошибок, планируете развиваться, подключать новые сервисы и не хотите через два года переписывать всё с нуля — лучше заложить фундамент сразу. Тут однозначно подойдет ESB.
