Наталья Самсонова
Старший системный аналитик
Привет, Хабр! Я Наталья Самсонова, фулстек-аналитик в ГК «Юзтех». Последнее время работаю пресейл-аналитиком в продуктовой команде. Несколько десятков встреч с клиентами в этом качестве позволили мне заметить значительную разницу в целеполагании заказчиков в проектах заказной и продуктовой разработки. О чем конкретно речь и почему это важно при выборе интеграционной платформы — рассказываю в статье.
В современном динамичном мире интеграционные процессы являются фактором устойчивости бизнеса. В этой ситуации наиболее важными параметрами становятся скорость поступления данных, качество, совместимость с данными систем-получателей.
Каждое такое свойство приносит либо рост доходов компании, либо, наоборот, упущенную выгоду, так как именно на данных (как исходных, так и агрегированных) формируется мнение о текущем состоянии дел в организации, принимаются стратегические и тактические решения.
Компании проходят закономерный путь: начинают с точечных интеграций, переходят на брокеры сообщений, а в сложном ИТ-ландшафте приходят к необходимости интеграционной платформы. Но ключевой вопрос часто остаётся за кадром: как определить, что этот момент настал?
Иногда на пресейл-встречах сами заказчики интересуются у нас: как понять, что наши текущие решения исчерпали себя и пора выходить на новый уровень – использование платформы, как основы построения корпоративной экосистемы управления данными?
Находясь на этапе поиска нового продукта, технические специалисты изучают его устройство, часто не имея чёткого понимания, какую именно проблему он должен решить. Погрузившись в технические детали, теряется видение общей картины. Парадокс в том, что вместо анализа целевых бизнес-показателей обсуждение уходит в архитектурные дебри. А правильно ли оценивать, что находится «под капотом», не зная, какой маршрут предстоит преодолеть?
В этой статье мы решили подробно поговорить о возможных подходах к оценке сценариев и метрик, на которые опираемся при измерении динамики процесса, а, следовательно, и эффективности выбора интеграционной платформы.
I. Диагноз перед лечением: зачем нужны два состояния и две группы метрик
Если организация планирует изменения или нововведения, то, как правило, знает какие именно параметры не удовлетворяют в настоящее время, а также понимает их текущее и целевое значение.
Фиксация двух состояний – начального и целевого – это важный аспект подготовки проекта. Здесь можно провести бытовую аналогию. Например, если человек заболел и у него высокая температура, то он знает до какого точно уровня она должна снизиться, чтобы ему снова стало комфортно.
Так и в любом бизнесе. Если интеграционные задачи не решаются в «фоновом» режиме, а регулярно попадают в повестку операционных дел — значит есть проблемные зоны. А узнаем об этом по тому, что конкретные показатели не соответствуют общему темпу движения бизнеса. Некоторые примеры таких ситуаций:
На момент принятия решения нет достаточных данных, так как не завершилась обработка; не успели запросить или передать сведения и т.д.;
При сборе сведений возникают конфликты данных вследствие их несовместимости, дублирования, ошибок ручного ввода, различных форматов ввода/вывода и пр.;
Для анализа состояния требуются новые (дополнительные) метрики, которые могут быть сгенерированы лишь интеграцией систем, но это занимает значительное время и сдерживает развитие организации.
Бизнес испытывает регулярные проблемы и это становится первопричиной постановки задачи на поиск интеграционной платформы. Соответственно, и конечный результат реализации проекта по его внедрению будет измеряться по бизнес-метрикам, которые побудили к его инициации, а также степенью удовлетворенности бизнеса состоянием корпоративных данных:
Если исходно были высокие затраты на интеграцию, то в целевом состоянии должно быть заметно снижение ТСО.
Вместо длительного времени вывода новых продуктов – получили ускорение time-to-market (TTM).
Регулярные ошибки данных сокращены за счёт внедрения механизмов управления данными и интеграционной прозрачности.
Ручные процессы автоматизированы и операционные задачи решаются эффективнее.
Такая трансформация позволит ощутить бизнесу существенные изменения. А дата-стратегия, построенная на четких критериях – объективно измерить эффективность выполненных действий.
Однако оценку интеграционных и Data Management платформ невозможно проводить только по бизнес-метрикам. Такие показатели лишь отвечают на вопрос: «Зачем?», но не объясняют: «Как?». Для этого используют технические метрики, которые трансформируют бизнес-требования в системные. Например, из бизнес-метрики «доля решений, принимаемых на основе данных» могут следовать техметрики: «скорость обработки запросов», «процент заполненности дата-каталога» и другие, с учетом общего контекста задачи. Так формируется техническое задание на поставку необходимого программного продукта.
В жизненном цикле эволюции экосистемы данных бизнес и технические метрики выполняют разные функции – задают различные ориентиры движения, и обращаются к ним на различных этапах развития. А динамика изменения значений: от начального к целевому – служит главным индикатором оценки текущего состояния и его соответствия ожидаемым результатам.
II. Бизнес-метрики – смысловой ориентир интеграционной платформы
Цифровизация — главный базис роста компании. Но чем активнее он идёт, тем острее становится следующее противоречие. С одной стороны, появляются десятки или сотни новых автоматизированных процессов, каждый из которых генерирует свои данные. При этом ИТ-задачи становятся более сложными, комплексными и масштабными. С другой стороны, бизнес ожидает от ИТ гибкости, скорости и простоты, а возникают многомерные и запутанные схемы взаимодействия.
Данные из разных систем и доменных областей начинают дублироваться, противоречить друг другу (из-за различной природы их происхождения), становятся несовместимыми или начинают обладать иными свойствами, которые препятствуют их совместной обработке для представления бизнесу в требуемом виде.
В то же время бизнес-требования прямо противоположны: нужны инструменты для повышения гибкости бизнеса, возможности открывать новые каналы продаж, создавать новые продукты, расширять партнерскую сеть. Такие инструменты должны содействовать повышению конверсии и качества клиентского опыта за счет «золотой записи» о клиенте, продукте, контрагенте.
Таким образом, выбор платформы — это выбор механизма достижения конкретных бизнес-результатов. Рассмотрим наиболее распространенные метрики:
1. Ускорение скорости вывода на рынок (Time-to-Market): скорость интеграции — это скорость бизнеса
Если интеграция систем, например, для подключения нового партнера занимает полгода (а на практике так и бывает), идея теряет актуальность ещё до реализации. Целевое значение скорости должно измеряться в днях или неделях (для сложных потоков). Т.е. за такой период бизнес-идея должна трансформироваться в работающий процесс. Low-code подход и готовые коннекторы — это не просто фича, а способ напрямую влиять на выручку.
#кейсы_ЮЗБАС Запуск интеграционной платформы для крупного ритейлера. Из-за реорганизации юрлица компании нужно было с нуля выстроить обмен данными между SAP, BI и складами. Вместо месяцев ручной настройки скриптов, продуктивная среда на ЮЗБАС была развернута всего за 3 недели. Более 10 критичных потоков данных заработали в срок, обеспечив непрерывность бизнеса в момент перехода на новую инфраструктуру. |
2. Снижение совокупной стоимости владения (Total Cost of Ownership, далее ССВ): скрытые издержки — источник реальной экономии
Владение ИТ-ландшафтом не должно быть золотой клеткой. Разрозненные инструменты, дорогие разработчики под каждую задачу, сложность поддержки и мониторинга, отсутствие сквозной аналитики и документации — всё это скрытые издержки.
Факторы, которые могут влиять на снижение ССВ:
Низкокодовость (No/Low сode) - позволяет привлекать к разработке интеграций бизнес-аналитиков и снижает зависимость от узких (и дорогих) разработчиков.
Единая платформа как альтернатива «зоопарка» инструментов - оптимизирует затраты на обучение, поддержку и лицензирование.
Прозрачность и модульность архитектуры – обеспечивают предсказуемость расходов на масштабирование и развитие.
При этом важно учитывать не только прямые лицензионные затраты, но и экономику изменений. Стоимость доработки, цена интеграционного простоя, нагрузка на ключевых специалистов и время реакции на бизнес-запросы формируют совокупную стоимость владения. В ряде случаев именно cost of change становится главным аргументом в пользу перехода на платформенное решение. Поэтому оценка должна учитывать горизонт планирования 3–5 лет, а не только бюджет первого года.
#кейсы_ЮЗБАС Лучше всего эффект иллюстрирует пример агропромышленного холдинга. До проекта интеграция на устаревшей системе и «лоскутных» скриптах требовала постоянного ручного сопровождения и не масштабировалась. Переход на единую платформу ЮЗБАС позволил: Снизить затраты на интеграцию на 30%. Ускорить работу семи «медленных» систем в десятки раз, убрав узкие места. Передать управление 80 потоками внутренней команде, полностью исключив зависимость от подрядчиков. |
3. Возможность отслеживания данных: среда для доверия и compliance
Когда из разных систем приходят «похожие, но разные» данные, возникает вопрос: каким источникам верить? Бизнес-решения, принятые на основе недостоверных данных — это прямая финансовая или репутационная угроза.
Развивая продукт как датацентричную платформу, управление данными (Data Governance) модуль выполняет особое назначение:
Прослеживаемость (Data Lineage): возможность просмотра откуда данные пришли, как преобразовывались и кто их менял на пути к получателю.
Качество и единые правила: установление бизнес-правил, стандартизации и обогащения данных.
Безопасность и соответствие регуляторным требованиям: контроль доступа, маскирование и аудит всех операций с данными.
Проще говоря, управление данными (DG) превращает данные из источника проблем в актив, которому можно доверять. Это прямая метрика снижения рисков и стоимости комплаенса.
#кейсы_ЮЗБАС Проблема доверия к данным остро стоит в отраслях со сложной цепочкой поставок. Например, нефтегазовая корпорация столкнулась с фрагментацией данных от датчиков скважин до систем дистрибуции, что мешало оперативному контролю и увеличивало риски. Внедрение USEBUS с модулями Data Governance обеспечило полную прослеживаемость (data lineage) каждого показателя. Результат: риски утечек и потерь данных снизились на 40%, а скорость анализа информации для принятия решений выросла на 50%. |
4. Создание единой версии правды: управление основными данными (MDM) как каталог данных
Как повысить конверсию, если один клиент в разных системах записан по-разному. В системе управления взаимоотношениями с клиентами (CRM) — «ООО “Вектор”», в 1С — «Вектор, ООО», а в службе доставки — «Vector LLC»? Маркетинг, финансы и логистика видят разных клиентов вместо одного.
Модуль управления основными данными (MDM) создаёт и поддерживает те самые «золотые записи» — единые, очищенные и актуальные профили ключевых сущностей (клиентов, товаров, контрагентов). Это прямая основа для:
Повышения конверсии кросс-продаж и качества клиентского сервиса.
Сокращения ошибок в логистике и финансах.
Получения точной аналитики.
#кейсы_ЮЗБАС Классическая проблема разночтений в данных критична для ритейла и дистрибуции. В кейсе розничной сети электроники (SAP, 1С, MDM) платформа USEBUS не только обеспечила бесшовный обмен, но и стала основой для консолидации данных в «золотую запись». Благодаря гарантированной доставке и синхронизации информации о товарах и ценах в реальном времени (с нагрузкой до 2,5 млн транзакций в сутки), компания получила единый и достоверный источник данных для аналитики продаж и управления ассортиментом. |
5. Расширяемость, как страховка инвестиций
Бизнес-задачи, которые будут актуальны через год, сегодня могут быть неизвестны. Платформа, которую нельзя гибко доработать, — это тупик. Расширяемость через low-code, API-фабрику и модульность — это стратегическое требование к платформе. Это страховка того, что ваши вложения в платформу будут защищены, а ИТ-ландшафт сможет адаптироваться к любым изменениям на рынке.
#кейсы_ЮЗБАС Платформа должна расти вместе с бизнесом. Пример сервиса такси это подтверждает. Изначально требовалось соединить GPS, платежные шлюзы и CRM. Благодаря модульной архитектуре USEBUS на Kubernetes, по мере роста компания смогла легко подключать новые источники (например, данные из соцсетей для персонализации) и интегрировать ML-модели для прогноза спроса. Сейчас система стабильно обрабатывает пиковые нагрузки в часы пик — до 250 запросов в секунду и 2 млн транзакций в сутки — без потери производительности и простоев. |
Существуют и другие популярные бизнес-метрики, которые в общем виде представлены тремя группами (экономические метрики, метрики качества, операционные метрики) на рисунке ниже.
Подытоживая вышесказанное, при выборе платформы первоочередным вопросом видится: какую бизнес-ценность должна обеспечить планируемая новация.
III. Технические метрики: как платформа обеспечивает бизнес-цели
Рассмотрев какими категориями мыслит бизнес, попробуем трансформировать эти ожидания в технические параметры, которые определяют требования к интеграционной платформе.
В общем виде техническую оценку продукта можно выполнять по восьми укрупненным группам показателей, краткая характеристика каждой представлена на схеме ниже.
Архитектура
Технологии
Производительность
Безопасность и соответствие
Интеграционные возможности
Управление и мониторинг
User Experience
Лицензирование и бизнес-параметры
Здесь использован подход, изложенный в исследовании «ESB: Круг Громова-2025»
Ниже разберем каждую из них, указав их непосредственное влияние на жизнедеятельность организации. Это может облегчить постановку задач ИТ-подразделению со стороны бизнеса.
1. Архитектурные показатели раскрывают устройство (состав) платформы. Объясняют каким образом компоненты взаимодействуют между собой. Данная группа показателей характеризует уровень надежности системы, способности к гибкому масштабированию при росте бизнеса. Так, наличие в составе продукта open source-компонентов может свидетельствовать об использовании широко распространённых и проверенных технологий. Однако сделаем оговорку: при условии их поддержки и корректной сборки вендором. При этом ценность части продукта собственной разработки вендора, как правило, отвечает актуальным вызовам локального рынка, а также обеспечивает надежную поддержку и сопровождение продукта в целом с необходимым уровнем SLA.
2. Технологические параметры создают условия, в которых предполагается работа пользователя платформы. Одновременно с этим, предъявляя ему необходимые квалификационные требования. Такие условия распространяются на операции, связанные с проектированием и созданием интеграций, тестированием и отладкой, выполнением импорта/экспорта, миграции потоков между средами и т.д. Также относятся к технологическим показателям: требования к инфраструктуре для развертывания самой платформы, поддерживаемые варианты (on-premises, облако, гибрид) и способы (в т.ч. автоматизированные) размещения и обновления, характеристики сайзинга и системного ПО. Указанная группа отвечает перед бизнесом за скорость изменений и стоимость владения продуктом. Иными словами, если основной болью организации являются долгие и дорогие доработки, то основное внимание при выборе платформы рекомендуется уделять технологической оценке.
3. Показатели производительности – это уровень гарантии, что бизнес «не ляжет» в самый неподходящий момент. Когда идут высокие нагрузки на бизнес-процессы (пик продаж, период отчетности, сдача проекта и т.д) важно, чтобы платформа располагала достаточным спектром функций масштабируемости и отказоустойчивости. Но даже если сбой произошел, то как поведет себя система в этом случае? Возможно ли ожидать автоматического восстановления ее работоспособности; надежны ли функции резервного копирования данных; механизмы синхронизации и пр.? Непрерывность ключевых операций, отсутствие простоев, предсказуемое масштабирование – вот главный бизнес-эффект, в который трансформируются метрики производительности.
4. Показатели безопасности и соответствия свидетельствуют о качестве управления рисками и доверием к бизнесу. Кто и в каком виде имеет доступ к данным? Какие действия может совершать? Каким образом осуществляется передача и обработка данных, с точки зрения верификации допустимости операций, контроля происхождения данных, исходных и обработанных значений? – Ответы на эти и подобные вопросы определяют защитный контур ИТ-ландшафта организации. Изучая продуктовые показатели безопасности и соответствия, можно в достаточной мере оценить риски возможных утечек информации или нежелательного проникновения в контур, что, в свою очередь, может повлечь репутационный и финансовый ущерб компании.
5. Метрики интеграционных возможностей показывают насколько просто платформа соединяет все необходимые системы и сервисы между собой, образуя единое цифровое пространство организации. Для этого исследуют, какие в платформе реализованы механизмы публикации и управления API (API Management). API — это стандартизированные интерфейсы, через которые системы обмениваются данными. Такие способы обеспечивают контроль доступа, нагрузки и использования данных, отслеживания ошибок и производительности при их передаче, безопасности изменения версий API и предоставления ее документации. Промышленные интеграционные платформы предоставляют набор готовых адаптеров и коннекторов к популярным информационным системам (например, 1С, SAP и др.) и базам данных, а также поддержку стандартных протоколов обмена. Достаточность комплектации поставки, ее соответствие корпоративному ИТ-ландшафту позволит обеспечить подключение необходимых систем без кастомизированной разработки «с нуля» и в кратчайшие сроки. Так, посредством интеграционных возможностей платформы компания получает ускорение запуска новых продуктов, снижение затрат на интеграцию и минимизацию операционных сбоев при обмене данными. Любая новая интеграция из традиционного барьера развития трансформируется в фактор стремительного роста бизнеса.
6. Средства управления и мониторинга обеспечивают возможность отслеживания состояния интеграций, поиска ошибок, понимания причин сбоев, а также контроля нагрузки на систему. Такие инструменты являются отличительными особенностями среднего слоя в сравнении с другими способами интеграции, в частности «точка-точка». А при наличии соответствующих аналитических или AI/ML-инструментов мониторинг может дополняться предиктивными сценариями. Анализируя последовательность логов, модель «догадывается» о приближающемся инциденте и уведомляет об этом администратора. Однако даже в минимальной комплектации средства мониторинга за работой системы обеспечивают бизнесу снижение операционных рисков через контролируемость операций и стабильность сервисов.
7. User Experience метрики показывают насколько быстро внутренняя команда сможет освоить и начать эффективно взаимодействовать с платформой. Для этого интерфейс системы должен быть понятным и удобным, а логика настроек и сценариев простой, без лишних переходов и условий. При таких возможностях пользователи быстро обучаются и легче принимают нововведения. Интуитивно понятный интерфейс и линейные сценарии использования (use cases) снижают число ошибок, которые часто возникают на начальном этапе из-за человеческого фактора при высоком пороге входа. Также уменьшаются расходы на обучение персонала и в целом – на внедрение системы. Реализация в платформе low/no-code подхода позволяет бизнесу снизить зависимость от дорогих разработчиков или иных «особых» специалистов (например, обладающих уникальными историческими знаниями о потоках корпоративных данных), а, следовательно, и снять остроту кадрового дефицита.
8. Лицензирование и бизнес-параметры. При выборе интеграционной платформы важное значение имеют стоимостные характеристики. Для начала необходимо определиться с ценообразованием и лицензионной моделью. Т.е. от чего зависит цена продукта и как она может изменяться при росте потребностей бизнеса. При этом важно понимать в какой комплектации поставляется ПО за указанную цену. Например, все ли необходимые адаптеры или функциональные модули будут доступны «из коробки». Следующей важной составляющей является стоимость и условия обновления ПО, часто разделяемые на мажорные и минорные. Также к стоимости владения продуктом относятся и условия оказания различных сервисных услуг, включая услуги техподдержки (с дифференцированными уровнями SLA), консалтинга и обучения. К оценке экосистемы продукта рекомендуется подходить комплексно. С одной стороны, важно обратить внимание на активности вендора (вебинары, конференции, комьюнити и пр.) и прозрачность дорожной карты (Road Map) платформы. С другой стороны - на наличие партнерской сети, а также присутствия в ней крупных российских интеграторов, что в совокупности обеспечит стабильность эксплуатации на долгосрочную перспективу. Все три составляющие позволяют прогнозировать бюджет на несколько лет вперед, оценивать реальную стоимость владения, а не только цену первоначальной покупки.
IV. Заключение
В статье мы не коснулись темы организационной составляющей, но заметим, что в каждом проекте важно определить модель управления платформой. Будет ли создан централизованный центр компетенций (CoE) или ответственность распределится между доменными командами? От выбранной модели зависят скорость изменений, уровень стандартизации и управляемость архитектуры. Для максимального эффекта процесс поиска платформы должен быть дополнен необходимой организационной настройкой.
Впрочем, организационная модель — это следующий шаг. А начинаем мы, как было представлено в статье, с другого. В практике команды ЮЗБАС любое внедрение предваряет глубокое погружение в задачи заказчика: мы проводим аудит текущего ИТ-ландшафта, обсуждаем бизнес-цели и реальные проблемы, которые нужно решить. И только после этого, опираясь на согласованные метрики, помогаем настроить платформу таким образом, чтобы максимально точно соответствовать целевой картине.
Ведь какой бы совершенной ни была платформа, конечный результат определяют люди и процессы, выстроенные вокруг неё. Только связав воедино бизнес-цели, технические метрики и организационную модель, можно превратить интеграционную платформу из инструмента в настоящий актив компании.
