Анализ AS-IS в ERP: как выявить риски финансового контура до сбоя системы

На практике анализ AS-IS в ERP-проекте нужен не для того, чтобы «аккуратно описать текущий ландшафт». Его задача — показать, где финансовый контур уже теряет управляемость и в каких местах система даст сбой при росте нагрузки, изменении процессов или попытке навести порядок в управленческом и регламентированном учёте.

Ключевая ошибка на этом этапе — собирать красивые схемы без фиксации точек разрушения. В результате компания получает не архитектурную диагностику, а презентацию. Если этого нет — система развалится не в момент рисования схем, а в момент закрытия месяца, консолидации, аудита или масштабирования бизнеса.

Цель

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

Что делает архитектор ERP на практике

Архитектор ERP смотрит на AS-IS не как аналитик описания процессов, а как инженер риска. Его интересует не только маршрут документа или набора данных, а то, где возникает необратимая потеря целостности, кто владеет данными, где появляются ручные обходы и какие решения уже сейчас формируют будущую стоимость изменений.

1. Определяет, где реально рождаются деньги и обязательства
   • точки продаж: POS, e-commerce, CRM, заказы, отгрузки;
   • формирование себестоимости: производство, закупки, склад, распределение затрат;
   • платёжный контур: заявки, казначейство, банк, эквайринг, взаиморасчёты.
2. Выявляет, где ломается целостность данных
   • дубли справочников и рассинхрон нормативно-справочной информации;
   • Excel-агрегация как скрытая «теневая ERP»;
   • ручные корректировки без прозрачного основания и владельца;
   • разные цифры в управленческом, бухгалтерском и операционном контуре.
3. Проверяет интеграционные ловушки
   • синхронные вызовы в критичных цепочках;
   • отсутствие идемпотентности (idempotency — защита от повторной обработки одного и того же события);
   • обмены без владельца, SLA и понятной ответственности;
   • нет мониторинга, повторной доставки, трассировки ошибок и контроля очередей.
4. Фиксирует реальные точки принятия решений
   • кто может менять правила расчёта;
   • кто разрешает ручные обходы;
   • кто отвечает за качество мастер-данных;
   • кто фактически владеет интеграцией, а не только «поддерживает» её.
5. Оценивает последствия второго и третьего порядка
   • сегодня ручная корректировка ускоряет закрытие месяца;
   • завтра она убивает доверие к отчётности;
   • послезавтра компания начинает принимать финансовые решения по цифрам, происхождение которых уже никто не может объяснить.

Артефакты этапа

• Архитектурная карта AS-IS на уровне C4 Level 1–2: системы, контейнеры, ключевые связи, владельцы контуров.
• Реестр интеграций: источник, приёмник, тип обмена, критичность, частота, способ контроля, владелец.
• Карта точек потери целостности: где данные дублируются, переписываются, агрегируются вручную или расходятся между системами.
• Топ-10 рисков закрытия месяца: с оценкой вероятности, влияния и стоимости сбоя.
• Матрица владения данными: кто отвечает за создание, изменение, качество и использование ключевых сущностей.

Критерий успеха

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

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

Риски и типовые ошибки

• Подмена диагностики интервьюированием. Люди описывают «как должно быть», а не «как реально работает».
• Фокус только на системах, а не на данных. В ERP ломается не интерфейс схемы, а доверие к цифрам.
• Игнорирование Excel и ручных операций. Именно там часто живёт фактическая логика бизнеса.
• Отсутствие оценки хрупкости интеграций. Формально обмен есть, но восстановить его после сбоя никто быстро не сможет.
• Попытка сделать полное описание всего. Это затягивает этап и убивает его смысл. Архитектору нужен не энциклопедический каталог, а карта критических зависимостей.

Ключевая мысль: анализ AS-IS в ERP — это не описание текущего состояния, а карта будущих аварий, финансовых искажений и стоимости изменений.

Анализ на альтернативные маршруты и варианты

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