Однажды я работала с компанией, у которой было пять справочников контрагентов - в общей СЭД, в юридической СЭД, в 1С Бухгалтерия, в CRM; а у службы безопасности — вообще экселевская табличка.

И во всех справочниках было ИП Дар.

Только правда о нём была разной.

В юридической СЭД — куча претензий от них и к ним. В бухгалтерии — не закрытые счета. В общей СЭД — переписка. В CRM — с ними упорно выходили на новые сделки. А в экселевской табличке службы безопасности они числились неблагонадёжными. Один контрагент. Пять разных правд. И ни одна не знает о других.

Управленческая сторона: почему так происходит.

Это не «халатность». Это архитектура.

Когда в компании каждый отдел ведёт свой справочник в своей ИС, возникает пять последствий.

1. Нет единого источника правды. Если его нет — каждая система не видит другую. Юристы видят договоры и претензии. Бухгалтерия - долги. CRM - «перспективного клиента». Служба безопасности - «неблагонадёжного».

2. Каждый отдел действует в своих интересах. Юристы не хотят жить в судах. Бухгалтерия не хочет новых долгов. CRM не хочет терять клиента. СБ не хочет риска. Но никто не видит друг друга. Каждый делает правильно в своей зоне — и вредит целому. В Systems Thinking это «оптимизация частей при деградации целого». Каждый отдел работает правильно. Система в целом — теряет деньги.

3. Служба безопасности — вне процесса. Экселевская табличка — это не «инструмент». Это признак того, что безопасность не встроена в процесс. Она реагирует постфактум — когда сделка уже заключена.

4.Ответственность размыта. Когда покупатель не может оплатить то, что купил, юристы говорят: «Мы договор проверяли», безопасность: «Мы их в табличке отметили», CRM: «Мы не знали, что они неблагонадёжные». Каждый сделал своё. Система потеряла деньги.

5. Нет владельца процесса (в BPM это Process Owner). Того, кто отвечает за результат, а не за функцию. Если его нет — никто не отвечает за целое. Каждый — за свою часть.

Техническая сторона: как это выглядит в системах - В каждой ИС — свой справочник. Даже если названия совпадают — реквизиты могут не совпадать. - Нет интеграции. Системы не обмениваются данными/ обмениваются частично. В результате — в одной ИС контрагент активен, в другой — заблокирован, в третьей — удалён. - Нет проверки при создании сделки. В CRM создаётся сделка — и никто не проверяет контрагента. Нет триггера: «если контрагент в чёрном списке — стоп». Нет интеграции с юр СЭД: «если по контрагенту есть претензии — предупредить». Нет проверки СБ до выхода на сделку. - Нет единой модели данных. В Data Governance это Master Data Management (MDM), управление мастер-данными. Единый справочник контрагентов — это MDM. Если его нет — данные расходятся. - Нет аудита. Кто изменил справочник? На основании чего внесены изменения? Когда? Если нет — никто не знает и ни за что не отвечает.

Что нужно сделать

Управленчески. - Назначить владельца процесса «Работа с контрагентом». Чтобы он отвечал за результат, а не за функцию; видел все системы и принимал решение. Я таким была в трубном холдинге. - Встроить службу безопасности в процесс. Как этап проверки — до выхода на сделку. - Создать единые правила. Для всех звеньев процесса. - Определить метрики. Не «количество сделок», а «количество сделок без потерь». Не «скорость закрытия», а «закрыта ли сделка без рисков». - Обучить людей. Не работе в одной ИС, а работе в процессе целиком.

Технически. - Создать единый справочник контрагентов. Все ИС работают с ним. - Интегрировать ИС. Через API. Или через шину данных. Или через MDM-платформу. Цель — все системы видят одного контрагента одинаково. - Встроить проверку в бизнес-процесс. При создании сделки — автопроверка: есть ли претензии и долги. Если есть — стоп или эскалация. - Автоматизировать службу безопасности. Не табличка. А модуль, который интегрирован в CRM и срабатывает автоматически. - Вести аудит справочника. Кто, когда, на каком основании что изменил. Это защищает от злоупотреблений и помогает разбираться в инцидентах.

#управление_ИС #BPM #ProcessOwner #экспертизаБорисовской