Что такое «ИТ-слой процесса» и как он «женит» разные системы

ИТ-слой процесса – это не «ещё одна программа». Это прослойка, которая заставляет несколько разных систем работать как один процесс: одинаково понимать статус задачи, данные, правила и события.

Если по-простому: CRM, ERP, ТОиР, склад, документооборот – это «органы». А ИТ-слой процесса – это нервная система: кто кому что сказал, когда, по какому правилу, и как это отразилось на статусе работы. И в большинстве случаев сейчас это люди.

Чтобы «поженить» разное ПО на этом уровне, нужны 4 вещи:

1. Единая модель событий процесса
Например: «сделка создана», «договор подписан», «вагон назначен», «ремонт начат/окончен», «счёт выставлен/оплачен».
Смысл: системы разные, но события процесса общие.

2. Контракты данных
Не «перекинем файлик», а стабильные структуры: идентификаторы, справочники, статусы, атрибуты.
Смысл: чтобы не было 5-ти разных «клиентов» и 7-и разных «статусов» в каждой системе.

3. Оркестрация
Это ответ, кто где главный. Например, где-то главный CRM (продажи), где-то ERP (учёт), где-то ТОиР-SaaS.
Смысл: у каждого шага есть «источник истины», иначе начинается бардак синхронизации.

4. Интеграция через API/шины/очереди событий
Для тех, кто не из IT: вы (человек) взаимодействуете с тем или иным ПО через его интерфейс. Программы так могут, но это им не удобно. Для них существует другой тип взаимодействия – интерфейсы «программа-программа». Технически это делается через API или брокер сообщений (шину).
Смысл: процесс не должен падать, если одна система «чихнула».

Итог: ИТ-слой процесса – это правила + события + контракты + оркестрация, которые превращают зоопарк систем в единый поток с измеримым SLA и статусами.

Пара нетривиальных выводов:
1. Если вы покупаете ПО без официальных документированных интеграционных интерфейсов (API/Events/Connectors), вы покупаете технологический долг – устаревший продукт, который трудно встроить в современную архитектуру без «шаманства и плясок с бубном» (читай – много денег).

2. Если вы IT-компания и ваш продукт нельзя встроить в внешнюю оркестрацию и событийный контур, то он не соответствует текущей «гигиене» рынка, а ваше отставание – примерно 3-5 лет от текущей потребности, вне зависимости от длины списка фич.

На чем строить «ИТ-слой процесса»
Это обычно 4 класса продуктов:

• iPaaS (Integration Platform as a Service) – чтобы быстро соединять приложения и данные, управлять интеграциями и API. Это «трубы» и трансформаторы данных. Бери, если есть задача «поженить» более 3-4 систем. Пример.

• Process Orchestration / BPM – чтобы управлять именно процессом, людьми, решениями, сервисами и API как одним потоком. Это «диспетчер процесса» и его «карта прохождения». Бери, если нужен управляемый процесс «от начала до конца» с этапами, правилами, ролями, SLA, эскалациями и видимостью статусов. Пример.

• Workflow orchestration – если хочешь надёжную оркестрацию длинных бизнес-транзакций. Это «движки гарантированного исполнения», реализуемые, как правило, в коде (увы). Бери, если процессы длинные, с ожиданиями и повторами, и важна надёжность исполнения без ручного «дожима». Пример.

• Плюс часто рядом живёт Event Streaming / Kafka-платформа – когда интеграции строятся на событиях («договор подписан», «инвойс оплачен» и т.п.) и нужна шина и коннекторы. Это «нервная система» – события летят всем, кто должен реагировать. Добавляй, если нужен событийный контур: много подписчиков, реактивность, масштаб, слабая связанность и журнал событий. Пример.

Можно ли объединить что-то с чем-то из этого списка? Да, можно – такие системы сейчас начинают выходить на рынок. Это отдельная тема, и к ней мы еще обязательно вернемся. Особенно в контексте ИИ.

Итого: «ИТ-слой процесса» на практике – это комбинация интеграций (iPaaS/API), оркестрации (BPM/Workflow) и иногда событийная шина. И если ваш ИТ-директор на это скажет, что «для такой схемы нам нужно много людей и денег», то не пора ли опять вернутся к теме аутсорсинга или просто расстаться со старыми калошами? Ведь чувак не в теме 😉

Хороший вам выходных!

#автоматизация #производительностьтруда