Почему цифровизация промышленного предприятия не решает проблему, а создаёт её видимость

О чём этот текст

Это не справочник по системам. Определения ERP, MES, APS, WMS и прочих аббревиатур есть в Википедии, в материалах вендоров и в учебниках. Их много, и они друг другу противоречат.

Этот текст — о том, что происходит между системами: где заканчивается одна и начинается другая, где они пересекаются, где дублируют друг друга, и где остаётся зона, за которую не отвечает никто.

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

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

Из этого следуют три тезиса, которые этот текст разворачивает:

1. Единый источник правды — иллюзия. В каждом стыке источников минимум два, и они расходятся.
2. Полная цифровизация — иллюзия. У неё нет конечного состояния. Каждая новая система добавляет новые стыки.
3. Интеграция — маскировка, а не решение. Она синхронизирует данные, но не отвечает на вопрос, кто главный.

SAP, 1С, любая другая ERP — это системы того же класса. Они не устраняют пересечения. Они добавляют к ним ещё одно.

Чего здесь не будет: предложения «правильной» архитектуры, единой модели, замены всех систем одной. Такого предложения у меня для вас нет.

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

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

Как читать

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

• Что заявлено. Как система себя описывает.
• Где пересекается. С кем и в чём.
• Что остаётся неопределённым. Зона, за которую никто не отвечает.
• Вопросы. Что стоит уточнить, прежде чем принимать решения.

Читать можно с любого кластера. Если вы новичок — начните с первого. Если вы уже потратили деньги на ERP и не получили результата — начните со сводной таблицы и раздела «Три иллюзии».

Часть I. Три иллюзии

Иллюзия единого источника правды

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

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

Заказ в ERP — это учётная единица. Заказ в MES — это производственное задание. Заказ в APS — это элемент расписания. Заказ в CRM — это обещание клиенту. Это не один и тот же объект, и никакая система не сделает его одним. Можно синхронизировать данные, но нельзя устранить различие ролей.

«Единый источник правды» — это лозунг, за которым стоит предположение, что объект существует независимо от систем. Но в классическом ландшафте объект конституируется системой, которая на него смотрит. Номенклатура в PLM — это не то же самое, что номенклатура в ERP. Сотрудник в HRM — не то же самое, что сотрудник в WFM. Контрагент в CRM — не то же самое, что контрагент в SRM.

Это не проблема, которую можно решить. Это фундаментальное свойство функциональной классификации систем.

Иллюзия полной цифровизации

«У вас всё не цифровизировано» — это утверждение предполагает, что существует состояние «всё цифровизировано». Его нет.

Цифровизация — это не конечное состояние, а процесс. Каждая новая система добавляет новые стыки, новые пересечения, новые зоны неопределённости. Чем больше систем, тем больше стыков. Чем больше стыков, тем больше мест, где данные расходятся.

Это не значит, что цифровизация не нужна. Это значит, что она не имеет конца. И если продавать её как путь к конечному состоянию — вы продаёте иллюзию. Каждый новый проект цифровизации увеличивает сложность ландшафта, а не уменьшает её.

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

Иллюзия интеграции

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

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

Классический пример: компания покупает MDM, чтобы «навести порядок в мастер-данных». Через некоторое время MDM становится ещё одним источником, который расходится с исходными системами. Компания покупает ещё один MDM. И так далее.

Часть II. Атлас 22 стыков

22 кластера ниже — рабочая карта, а не классификация. Она собрана из практики и из описаний систем, а не из формального стандарта; границы кластеров подвижны, и в вашем контуре часть из них может выглядеть иначе. Карта нужна, чтобы выбрать два-три стыка для проверки, а не чтобы «закрыть» все 22.

Границы уровней в производственном контуре опираются на ISA-95 (IEC 62264) — стандарт, который задаёт иерархию уровней 0–4 и словарь интеграции ERP–MES. Для инженерных данных о жизненном цикле изделия и актива существует ISO 15926: он описывает онтологию оборудования, состава и свойств. Ни один из этих стандартов не отвечает на вопрос «кто владелец стыка» — они задают словарь, а не мандат.

Производственный контур

Домены: Production Planning, Production Execution, Supply Chain Planning, Quality.

Кластер 1. ERP ↔ MES ↔ APS

Что заявлено. ERP — учётная система предприятия, «единый источник правды» по финансам, закупкам, продажам, остаткам и производственному планированию. MES — управление производством на уровне цеха: задания, подтверждения, состояние оборудования. APS — перспективное планирование с оптимизацией и учётом ограничений.

Где пересекается. Все три претендуют на: построение производственного плана, учёт доступности ресурсов, отслеживание выполнения, расчёт потребности в материалах, определение сроков, приоритизацию заказов. План живёт в трёх местах одновременно: ERP («официальный»), APS («оптимальный»), MES («фактический»).

Что остаётся неопределённым. Где источник правды по плану. Кто отвечает за перепланирование при отклонении. Где граница между «планом» и «расписанием». Что считается «одним и тем же» заказом в трёх системах.

Вопросы.

1. В какой системе принимается решение о перепланировании и кто его владелец?
2. Как соотносятся идентификаторы заказов в ERP, APS и MES?
3. Что происходит, если MES изменил последовательность операций — обновляется ли APS и ERP?
4. Где хранится история планов и можно ли восстановить, что было запланировано на конкретную дату?

Кластер 2. S&OP ↔ MRP ↔ APS ↔ MPS

Что заявлено. S&OP — согласование спроса и предложения на горизонте месяцев. MRP — расчёт потребности в материалах. MPS — основное расписание производства. APS — оптимизация с учётом ограничений. Четыре системы, которые часто заявляются как «разные уровни одного процесса».

Где пересекается. Все четыре работают с одним и тем же: спрос, предложение, ресурсы, сроки. S&OP даёт агрегированный план, MRP разворачивает его в потребность, MPS фиксирует, APS оптимизирует. На практике границы размыты: MRP в ERP может делать то, что заявлено для APS; APS может закрывать горизонт S&OP.

Что остаётся неопределённым. Кто владелец горизонта. Что считается «согласованным» планом. Как соотносятся временные корзины (buckets) в разных системах. Где заканчивается планирование и начинается исполнение.

Вопросы.

1. На каком горизонте принимает решение каждая система и кто утверждает план?
2. Как соотносятся временные корзины в S&OP, MRP, MPS и APS?
3. Что происходит при конфликте планов — кто разрешает?
4. Кто отвечает за консистентность между уровнями?

Кластер 3. MES ↔ SCADA ↔ PLC ↔ IIoT

Что заявлено. PLC — управление оборудованием. SCADA — диспетчеризация и визуализация. MES — управление производством. IIoT — сбор и анализ данных с оборудования. Четыре уровня автоматизации, которые в классической модели автоматизации (стандарт ISA-95) идут снизу вверх.

Где пересекается. Все четыре собирают данные с оборудования. PLC управляет, SCADA визуализирует, MES интерпретирует, IIoT анализирует. Границы между уровнями на практике размыты: современный MES может брать данные напрямую с PLC, минуя SCADA; IIoT-платформа может дублировать функции MES.

Что остаётся неопределённым. Где источник правды по состоянию оборудования. Кто владелец исторических данных. Что считается «одним и тем же» событием на разных уровнях. Как соотносятся временные метки.

Вопросы.

1. Где хранится историческая телеметрия и кто её владелец?
2. Как соотносятся события на уровнях PLC, SCADA, MES и IIoT?
3. Кто отвечает за синхронизацию времени между уровнями?
4. Что происходит при конфликте данных — например, PLC показывает одно, MES другое?

Кластер 4. QMS ↔ MES ↔ LIMS

Что заявлено. QMS — управление качеством: процедуры, проверки, несоответствия, CAPA (корректирующие и предупреждающие действия). MES — производственный учёт: параметры процессов, прослеживаемость. LIMS — лабораторная информационная система: пробы, анализы, результаты.

Где пересекается. Все три работают с измерениями, допусками, отклонениями, прослеживаемостью. MES собирает данные с оборудования, LIMS — из лаборатории, QMS — управляет процедурами и регистрирует несоответствия. Одно отклонение может быть зафиксировано в трёх местах по-разному.

Что остаётся неопределённым. Где фиксируется отклонение. Кто инициирует корректирующее действие. Где хранится полная история качества. Что считается «одним и тем же» несоответствием.

Вопросы.

1. Где фиксируется отклонение и кто его регистрирует?
2. Как соотносятся измерения в MES, LIMS и QMS?
3. Кто владелец прослеживаемости — MES, QMS или ERP?
4. Кто инициирует CAPA и как оно связано с производственным заданием?

Материальные потоки

Домены: Inventory & WMS, Logistics & TMS, Supply Chain Planning, Procurement.

Кластер 5. ERP ↔ WMS

Что заявлено. ERP — учёт остатков, себестоимость, движение материалов. WMS — управление складскими операциями: приёмка, размещение, отбор, упаковка, отгрузка, инвентаризация.

Где пересекается. Обе ведут остатки, движения, топологию склада, партионный и серийный учёт, правила FIFO/FEFO (first in, first out / first expired, first out), инвентаризацию. ERP хранит «финансовый» остаток, WMS — «физический». Они регулярно расходятся.

Что остаётся неопределённым. Где источник правды по остатку. Кто владелец топологии склада. Что считается «одним и тем же» движением. Кто отвечает за расхождение.

Вопросы.

1. Как часто сверяются остатки ERP и WMS и кто отвечает за расхождение?
2. Кто владелец топологии склада — ERP или WMS?
3. Как маппятся движения: одна операция WMS — одна проводка ERP?
4. Что происходит при инвентаризации: кто инициирует, кто подтверждает?

Кластер 6. WMS ↔ TMS ↔ ERP

Что заявлено. WMS — склад. TMS — транспорт. ERP — учёт. Три системы, которые обслуживают движение груза от поставщика до клиента.

Где пересекается. Все три работают с грузом, маршрутом, временем, стоимостью. WMS знает, что лежит на складе. TMS знает, что едет. ERP знает, что учтено. Одна и та же отгрузка может иметь три разных идентификатора и три разных статуса.

Что остаётся неопределённым. Где источник правды по грузу. Кто владелец маршрута. Что считается «одной и той же» отгрузкой. Как соотносятся статусы.

Вопросы.

1. Как соотносятся отгрузки в WMS, TMS и ERP?
2. Кто владелец маршрута и кто его меняет?
3. Где хранится история перемещений груза?
4. Кто отвечает за расхождение статусов?

Кластер 7. Demand ↔ Inventory ↔ Logistics

Что заявлено. Demand Planning — прогноз спроса. Inventory Management — управление запасами. Logistics — физическое перемещение. Три системы, которые должны работать согласованно.

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

Что остаётся неопределённым. Кто владелец целевого запаса. Где источник правды по доступности. Как соотносятся прогноз и факт. Кто отвечает за разрыв между спросом и предложением.

Вопросы.

1. Кто владелец целевого запаса — Demand, Inventory или Finance?
2. Как соотносятся прогноз спроса и фактическое потребление?
3. Кто отвечает за разрыв между спросом и предложением?
4. Как проверяется согласованность между тремя системами?

Данные и документы

Домены: PLM, MDM, ECM, NPI/R&D, Asset Management.

Кластер 8. PLM ↔ MDM

Что заявлено. PLM — управление жизненным циклом продукта: документация, состав изделия, изменения, версии. MDM — управление мастер-данными: единый справочник номенклатуры, контрагентов, подразделений.

Где пересекается. Обе претендуют на номенклатуру, состав изделия, версионность, классификацию, атрибуты. PLM управляет инженерными данными, MDM — «корпоративными». Номенклатура заводится в PLM, «передаётся» в MDM, расходится по ERP, MES, WMS.

Что остаётся неопределённым. Где источник правды по номенклатуре. Что считается «одной и той же» позицией. Кто владелец классификатора. Как соотносятся версии.

Вопросы.

1. Где заводится номенклатура и кто утверждает её создание?
2. Как соотносятся инженерная и учётная позиции?
3. Кто владелец классификатора и как он меняется?
4. Что происходит при изменении номенклатуры во всех системах-потребителях?

Кластер 9. ECM ↔ PLM / ERP / BPM

Что заявлено. ECM — управление корпоративным контентом: документы, папки, версии, права. PLM, ERP, BPM — системы, которые генерируют и потребляют документы.

Где пересекается. Документ может жить в ECM, но быть привязан к объекту в PLM, к заказу в ERP, к процессу в BPM. Один и тот же документ может быть заведён в нескольких местах с разными версиями.

Что остаётся неопределённым. Где источник правды по документу. Кто владелец версии. Как соотносятся права доступа. Что считается «одним и тем же» документом.

Вопросы.

1. Где хранится оригинал документа и где — копии?
2. Кто владелец версии и как она обновляется?
3. Как соотносятся права доступа в ECM и в системах-потребителях?
4. Что происходит при расхождении версий?

Кластер 10. MDM как сквозной слой

Что заявлено. MDM — единый источник правды по мастер-данным для всех систем. Заявлена как решение проблемы расхождений.

Где пересекается. MDM пересекается со всеми: ERP, MES, WMS, TMS, PLM, CRM, SRM, WFM, EAM, BI. Он должен быть источником правды по номенклатуре, контрагентам, сотрудникам, оборудованию, классификаторам. На практике MDM часто становится ещё одним местом, где данные расходятся с исходными системами.

Что остаётся неопределённым. Какие данные считаются «мастер-данными», а какие — операционными. Кто владелец каждого домена данных. Как обрабатываются конфликты. Как обеспечивается синхронизация.

Вопросы.

1. Какие домены данных входят в MDM, а какие остаются в исходных системах?
2. Кто владелец каждого домена?
3. Как разрешаются конфликты между MDM и исходной системой?
4. Как проверяется, что MDM действительно является источником правды?

Люди

Домены: WFM/HR, Governance.

Кластер 11. WFM ↔ HRM

Что заявлено. HRM — управление персоналом: кадровый учёт, найм, обучение, оценка, зарплата. WFM — управление рабочим временем: планирование смен, распределение задач, учёт времени, трудовое законодательство.

Где пересекается. Обе работают с сотрудниками, квалификациями, доступностью, трудовыми ограничениями, фактическим временем. HRM хранит кадровые данные, WFM планирует смены. Расхождение — постоянное.

Что остаётся неопределённым. Где источник правды по сотруднику. Где хранятся квалификации. Кто отвечает за соблюдение трудовых ограничений. Что считается «одним и тем же» временем.

Вопросы.

1. Где заводится сотрудник и кто отвечает за актуальность данных?
2. Где хранятся квалификации и кто их подтверждает?
3. Кто отвечает за соблюдение трудовых ограничений при планировании?
4. Как сверяется фактическое время между HRM, WFM и производственным учётом?

Кластер 12. HRM ↔ оценка / обучение / психология

Что заявлено. HRM — кадровый учёт. Оценка — performance review, 360, Gallup. Обучение — LMS. Психология — тесты, профили, assessment.

Где пересекается. Все четыре работают с сотрудником, его компетенциями, результатами, развитием. Оценка влияет на обучение, обучение — на квалификацию, квалификация — на доступность в WFM, доступность — на планирование. Цепочка редко замкнута.

Что остаётся неопределённым. Где источник правды по компетенциям. Кто владелец оценки. Как соотносятся результаты тестов и кадровые решения. Что считается «одним и тем же» профилем.

Вопросы.

1. Где хранятся компетенции — в HRM, LMS, WFM или отдельной системе?
2. Кто владелец оценки и как она влияет на кадровые решения?
3. Как соотносятся результаты тестов и квалификации в WFM?
4. Что происходит при расхождении оценок из разных источников?

Контрагенты и сервис

Домены: Demand & Sales, Procurement, Service.

Кластер 13. CRM ↔ SRM

Что заявлено. CRM — управление отношениями с клиентами. SRM — управление отношениями с поставщиками.

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

Что остаётся неопределённым. Где источник правды по контрагенту. Что считается «одним и тем же» контрагентом. Кто владелец истории взаимодействия. Как соотносятся договоры.

Вопросы.

1. Где заводится контрагент и кто отвечает за его актуальность?
2. Как обрабатывается ситуация «клиент и поставщик одновременно»?
3. Кто владелец истории взаимодействия?
4. Как соотносятся договоры в CRM, SRM и ERP?

Кластер 14. Service ↔ CRM ↔ FSM

Что заявлено. Service — управление сервисом: SLA, гарантия, сервисные контракты. CRM — отношения с клиентами. FSM — управление выездным обслуживанием: заявки, наряды, диспетчеризация.

Где пересекается. Все три работают с клиентом, его оборудованием, историей обслуживания, SLA. Service определяет обязательства, CRM ведёт историю, FSM выполняет работы. Один и тот же инцидент может быть зафиксирован в трёх местах.

Что остаётся неопределённым. Где источник правды по клиентскому оборудованию. Кто владелец истории обслуживания. Как соотносятся SLA и фактические сроки. Что считается «одним и тем же» обращением.

Вопросы.

1. Где хранится история обслуживания клиентского оборудования?
2. Кто владелец SLA и как проверяется его соблюдение?
3. Как соотносятся заявки в CRM, Service и FSM?
4. Кто отвечает за эскалацию?

Активы и проекты

Домены: Asset Management, Maintenance, Projects, PLM, NPI/R&D.

Кластер 15. EAM ↔ ТОиР

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

Где пересекается. Это часто одна и та же система под разными названиями. Если это две системы — они пересекаются по справочнику оборудования, истории обслуживания, заявкам, нарядам, регламентам, запчастям, стоимости.

Что остаётся неопределённым. Где источник правды по оборудованию. Кто владелец истории обслуживания. Где хранятся регламенты. Как соотносятся заявки и наряды.

Вопросы.

1. Где заводится оборудование и кто отвечает за актуальность?
2. Где хранится история обслуживания?
3. Как соотносятся заявки, наряды и работы в EAM, ТОиР и ERP?
4. Кто владелец регламентов обслуживания?

Кластер 16. PPM ↔ PLM ↔ NPI

Что заявлено. PPM — управление проектами и портфелем: WBS, вехи, ресурсы, бюджет. PLM — управление жизненным циклом продукта. NPI — процесс вывода нового продукта на рынок.

Где пересекается. Все три работают с продуктом, его разработкой, сроками, ресурсами, изменениями. PLM ведёт инженерные данные, PPM — проект, NPI — процесс. Один и тот же этап может быть зафиксирован в трёх местах.

Что остаётся неопределённым. Где источник правды по проекту. Кто владелец вехи. Как соотносятся изменения в PLM и в PPM. Что считается «одним и тем же» этапом.

Вопросы.

1. Где источник правды по проекту — PPM, PLM или NPI?
2. Как соотносятся вехи в PPM и stage-gates в NPI?
3. Кто владелец изменений и как они отражаются в проекте?
4. Как соотносятся ресурсы проекта и ресурсы производства?

Финансы, стратегия, governance

Домены: Finance, Strategy, Governance, Risk.

Кластер 17. FP&A ↔ ERP ↔ BI

Что заявлено. FP&A — финансовое планирование и анализ: бюджеты, прогнозы, сценарии. ERP — учёт факта. BI — отчётность и анализ.

Где пересекается. Все три работают с одними и теми же показателями: выручка, затраты, маржа, cash flow. ERP хранит факт, FP&A строит план и прогноз, BI показывает и то, и другое. Один показатель считается в трёх местах по-разному.

Что остаётся неопределённым. Где источник правды по показателю. Кто владелец методологии расчёта. Что считается «одним и тем же» показателем. Как обеспечивается согласованность.

Вопросы.

1. Где источник правды по каждому ключевому показателю?
2. Кто владелец методологии расчёта?
3. Как соотносятся отчёты в ERP, FP&A и BI?
4. Что происходит при расхождении?

Кластер 18. Strategy ↔ Governance ↔ Risk

Что заявлено. Strategy — цели, KPI, инициативы, стратегические карты. Governance — решения, политики, роли, делегирование. Risk — идентификация, оценка, управление рисками.

Где пересекается. Все три работают с целями, решениями, ограничениями. Strategy определяет цели, Governance принимает решения, Risk оценивает угрозы. Одна и та же цель может быть зафиксирована в трёх системах, а решение — потеряться между ними.

Что остаётся неопределённым. Где источник правды по цели. Кто владелец решения. Как соотносятся KPI и риск-метрики. Что считается «одним и тем же» решением.

Вопросы.

1. Где хранятся цели и кто отвечает за их актуальность?
2. Как соотносятся решения в Governance и инициативы в Strategy?
3. Кто владелец риск-регистра и как он связан со стратегией?
4. Как проверяется, что решения соответствуют стратегии?

Процессы и коммуникации

Домены: BPM, ECM, Governance, Communication.

Кластер 19. BPM ↔ Workflow в ERP

Что заявлено. BPM — управление бизнес-процессами: моделирование, исполнение, мониторинг. Workflow в ERP — встроенный механизм маршрутизации задач внутри учётной системы.

Где пересекается. Обе управляют процессами и задачами. BPM претендует на сквозные процессы через системы, workflow в ERP — на процессы внутри ERP. Один и тот же процесс может быть описан дважды и исполняться в двух местах.

Что остаётся неопределённым. Где источник правды по процессу. Кто владелец задачи. Что считается «одним и тем же» процессом. Как соотносятся статусы.

Вопросы.

1. Где описываются сквозные процессы и кто их владелец?
2. Как соотносятся задачи в BPM и в ERP?
3. Кто отвечает за синхронизацию статусов?
4. Что происходит при изменении процесса — как обновляются обе системы?

Кластер 20. Коммуникации ↔ CRM / Service / BPM

Что заявлено. Коммуникации — email, чат, ВКС, VoIP, push, доска. CRM, Service, BPM — системы, в контексте которых происходят коммуникации.

Где пересекается. Коммуникация всегда происходит в контексте объекта: клиента, заявки, процесса. CRM хранит историю общения с клиентом, Service — с заявкой, BPM — с процессом. Один и тот же диалог может быть зафиксирован в трёх местах или не зафиксирован нигде.

Что остаётся неопределённым. Где источник правды по коммуникации. Кто владелец треда. Как соотносятся каналы. Что считается «одним и тем же» обращением.

Вопросы.

1. Где хранится полная история коммуникации с клиентом?
2. Как соотносятся треды в разных системах?
3. Кто владелец коммуникации — CRM, Service или BPM?
4. Что происходит при расхождении версий диалога?

Специфические домены

Домены: Energy, EHS.

Кластер 21. Energy ↔ ERP / MES / BI

Что заявлено. Energy Management — управление энергопотреблением: потребление, спрос, тарифы, выбросы. ERP — учёт затрат на энергию. MES — производственный учёт. BI — отчётность.

Где пересекается. Все четыре работают с потреблением, затратами, выбросами. Energy Management измеряет, MES связывает с производством, ERP учитывает, BI показывает. Один и тот же киловатт-час может быть учтён в четырёх местах по-разному.

Что остаётся неопределённым. Где источник правды по потреблению. Кто владелец тарифа. Как соотносятся производственные и энергетические данные. Что считается «одним и тем же» выбросом.

Вопросы.

1. Где хранятся первичные данные по потреблению?
2. Как соотносятся потребление и производственные показатели?
3. Кто владелец тарифов и как они обновляются?
4. Как проверяется соответствие данным регулятора?

Кластер 22. EHS ↔ QMS ↔ MES

Что заявлено. EHS — безопасность, охрана труда, окружающая среда: инциденты, аудиты, разрешения, выбросы. QMS — качество. MES — производство.

Где пересекается. Все три работают с инцидентами, отклонениями, разрешениями, обучением. EHS фиксирует инцидент, QMS — несоответствие, MES — отклонение процесса. Одно событие может быть зарегистрировано в трёх местах с разными последствиями.

Что остаётся неопределённым. Где источник правды по инциденту. Кто владелец расследования. Как соотносятся несоответствие и инцидент. Что считается «одним и тем же» событием.

Вопросы.

1. Где фиксируется инцидент и кто его регистрирует?
2. Как соотносятся несоответствия в QMS и инциденты в EHS?
3. Кто владелец расследования и как оно связано с производством?
4. Как проверяется соблюдение регуляторных требований?

Сводная таблица пересечений

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

Закономерность. В каждом кластере есть пересечение. В каждом кластере источник правды либо не определён, либо расходится. В каждом кластере владелец стыка не назначен. Это свойство подхода.

SAP и 1С — системы того же класса

Это не критика SAP и не критика 1С. Это утверждение о классе.

SAP, 1С, Oracle, Microsoft Dynamics — иллюстративные примеры этого класса в рамках данного текста, не рейтинг и не сравнительная оценка продуктов. Любая другая ERP работает в той же парадигме: функциональная классификация, единый источник правды, интеграция как решение стыков. Такие системы добавляют ещё один узел в ту же сеть пересечений.

Когда компания заменяет одну ERP на другую — она не устраняет пересечения. Она создаёт новые. Новая ERP пересекается с MES, WMS, TMS, PLM, MDM — так же, как пересекалась старая. Меняются названия, интерфейсы, вендоры. Структура пересечений остаётся той же.

Это не значит, что SAP или 1С плохие. Это значит, что они не решают проблему класса. Они — представители класса. Проблема не в том, что SAP недостаточно хорош. Проблема в том, что класс, к которому он принадлежит, не имеет ответа на вопросы, которые сам порождает.

«Купите SAP — и всё будет едино» — это то же самое, что «купите 1С — и всё будет едино». Обещание единого источника правды не выполняется ни одной из них, потому что оно невыполнимо в рамках подхода. Не потому, что вендоры плохие, а потому, что объект, о котором идёт речь, не существует как единый в функционально классифицированном ландшафте.

Открытые вопросы

Онтологические

Вопросы о том, что здесь считается одним и тем же.

1. Что считается «одним и тем же» заказом в ERP, APS и MES?
2. Что считается «одним и тем же» планом в S&OP, MRP, MPS и APS?
3. Что считается «одним и тем же» событием на уровнях PLC, SCADA, MES и IIoT?
4. Что считается «одним и тем же» отклонением в MES, LIMS и QMS?
5. Что считается «одним и тем же» остатком в ERP и WMS?
6. Что считается «одной и той же» отгрузкой в WMS, TMS и ERP?
7. Что считается «одной и той же» доступностью в Demand, Inventory и Logistics?
8. Что считается «одной и той же» номенклатурой в PLM, MDM и ERP?
9. Что считается «одним и тем же» документом в ECM и системах-потребителях?
10. Какие данные считаются мастер-данными, а какие операционными?
11. Что считается «одним и тем же» сотрудником в HRM, WFM и производственном учёте?
12. Что считается «одним и тем же» профилем компетенций?
13. Что считается «одним и тем же» контрагентом в CRM, SRM и ERP?
14. Что считается «одним и тем же» обращением в CRM, Service и FSM?
15. Что считается «одним и тем же» оборудованием в EAM, ТОиР и ERP?
16. Что считается «одним и тем же» этапом в PPM, PLM и NPI?
17. Что считается «одним и тем же» показателем в ERP, FP&A и BI?
18. Что считается «одним и тем же» решением в Strategy, Governance и Risk?
19. Что считается «одним и тем же» процессом в BPM и workflow в ERP?
20. Что считается «одним и тем же» диалогом в CRM, Service и BPM?
21. Что считается «одним и тем же» потреблением в Energy, MES и ERP?
22. Что считается «одним и тем же» инцидентом в EHS, QMS и MES?

Организационные

Вопросы о том, кто владеет стыком.

1. Кто отвечает за синхронизацию планов между ERP, APS и MES?
2. Кто владелец горизонта планирования в S&OP, MRP, MPS и APS?
3. Кто отвечает за синхронизацию времени между уровнями автоматизации?
4. Кто владелец прослеживаемости — MES, QMS или ERP?
5. Кто отвечает за расхождение остатков между ERP и WMS?
6. Кто владелец маршрута и статуса отгрузки?
7. Кто владелец целевого запаса?
8. Кто владелец номенклатуры — PLM, MDM или ERP?
9. Кто владелец документа и его версии?
10. Кто владелец каждого домена мастер-данных?
11. Кто отвечает за соблюдение трудовых ограничений?
12. Кто владелец компетенций и оценки?
13. Кто владелец истории взаимодействия с контрагентом?
14. Кто владелец SLA и истории обслуживания?
15. Кто владелец регламентов обслуживания?
16. Кто владелец проекта и его вех?
17. Кто владелец методологии расчёта показателей?
18. Кто владелец целей, решений и риск-регистра?
19. Кто владелец сквозного процесса?
20. Кто владелец коммуникации с клиентом?
21. Кто владелец тарифов и данных по потреблению?
22. Кто владелец расследования инцидента?

Эволюционные

Вопросы о том, что произойдёт при изменении.

1. Что произойдёт при добавлении новой системы — IIoT-платформы, предиктивной аналитики, цифрового двойника?
2. Что произойдёт при смене вендора одной из систем?
3. Что произойдёт при изменении организационной структуры?
4. Что произойдёт при изменении требований регулятора?
5. Что произойдёт при масштабировании — новое предприятие, новый продукт, новый рынок?
6. Что произойдёт при слиянии или поглощении?
7. Что произойдёт, если одна из систем перестанет поддерживаться?
8. Что произойдёт при переходе на новую версию ERP или MES?
9. Что произойдёт при изменении модели данных?
10. Что произойдёт при изменении бизнес-модели?

Проверочные вопросы

Их можно задать вендору, интегратору или собственному ИТ-отделу. Ответы покажут, насколько зрело в компании понимание стыков.

1. Где источник правды по каждому ключевому объекту?
2. Кто владелец стыка между системами?
3. Что происходит при расхождении данных?
4. Как соотносятся идентификаторы в разных системах?
5. Где хранится история изменений?
6. Кто принимает решение о перепланировании / переклассификации / корректировке?
7. Что произойдёт при добавлении новой системы?
8. Что произойдёт при смене вендора?
9. Как проверяется согласованность данных между системами?
10. Кто отвечает за то, что данные в системах согласованы?
11. Как часто проводится сверка и кто её инициирует?
12. Как обрабатывается конфликт между системами?
13. Где документированы стыки?
14. Кто отвечает за маппинг идентификаторов?
15. Как проверяется, что мастер-данные действительно мастер?

Если на большинство вопросов нет внятного ответа — это не значит, что компания плохая. Это значит, что классический ландшафт не предполагает таких ответов. Он предполагает, что каждая система — «лучшая в своём классе», а стыки — «проблема интеграции».

Мини-кейсы

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

ERP ↔ WMS: остаток, которого нет

Физический остаток в WMS и «финансовый» в ERP расходятся на 3–5%. Раз в месяц кладовщики и финансы закрывают расхождение вручную: два человека по три дня. Замороженный капитал в «потерянном» запасе — порядка 10–15 млн рублей. Компания покупает ещё один интеграционный слой, и расхождение становится реже, но не исчезает: у остатка по-прежнему два владельца. Решение, которое меняет картину, — назначить владельца остатка и правило приоритета при расхождении, а интеграцию оставить транспортом, а не арбитром.

MES ↔ APS: план, который не исполняется

APS пересчитывает расписание каждую ночь, MES исполняет то, что было загружено днём раньше. На стыке теряется 5–7% заказов по сроку: план «оптимален», факт — нет. Причина не в качестве алгоритма, а в отсутствии владельца перепланирования и единого идентификатора заказа. Пока заказ в APS и MES — разные сущности, любое изменение плана создаёт новую зону расхождения.

PLM ↔ MDM: номенклатура, которая размножается

PLM заводит инженерную позицию, MDM — учётную, ERP — закупочную. Дубли достигают 8–10% номенклатуры, и заказ материала уходит не на ту позицию. Стоимость ошибки не в самой номенклатуре, а в остановке: одна неверная позиция может стоить смены. Решение — правило заведения и владелец классификатора, а не очередная синхронизация справочников.

Протокол диагностики

1. Выберите два-три стыка, критичных для вашего контура. Не начинайте с полного атласа.
2. Для каждого выпишите объект: заказ, партия, остаток, номенклатура, инцидент.
3. Перечислите системы и их роли в этом объекте: где он создаётся, где меняется, где хранится история.
4. Ответьте на три вопроса: где источник правды, кто владелец стыка, что происходит при расхождении.
5. Проверьте идентификаторы и время: совпадают ли ключи, в каком часовом поясе фиксируются события.
6. Зафиксируйте решение и дату пересмотра. Стык без владельца и даты — это не проблема, а отложенное решение.
7. Не начинайте с покупки системы. Сначала ответы на вопросы выше; система — только если ответы показали, что без неё нельзя.

Заключение

Классический ландшафт промышленного ИТ устроен так, что:

• каждая система заявляет себя как «лучшая в своём классе»;
• границы между классами размыты;
• пересечения не документированы;
• источник правды по сквозным объектам не определён;
• владелец стыка не назначен.

Это не ошибка конкретной компании. Это свойство подхода, в котором системы классифицируются по функциям, а не по объектам, которыми они управляют.

Классический подход к цифровизации устроен так, что проблема не решается, а перекладывается. Каждая новая система — это новая зона неопределённости, новый стык, новый вопрос без ответа. SAP, 1С, любая другая ERP — это системы того же класса. Они не устраняют пересечения. Они добавляют к ним ещё одно.

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

Источники

• ISA-95 / IEC 62264. Enterprise-control system integration.
• ISO 15926. Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities.