ЭТАП 2. Архитектура ERP: проектирование целевой модели (2–4 месяца)

На этом этапе архитектура ERP перестаёт быть набором пожеланий и становится моделью будущей системы. Ключевая задача — не просто нарисовать TO-BE, а определить, где именно живёт истина по финансам, учёту, себестоимости и закрытию периода. Если этого не сделать сейчас, дальше проект будет идти через исключения, компромиссы и ручные обходы.

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

Цель

Сделать ERP ядром целевой модели управления, а не ещё одной системой рядом с Excel, локальными базами и ручными корректировками.

Итог этапа — не «согласованная схема», а набор решений, после которых становится понятно:

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

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

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

В первую очередь фиксируются ключевые архитектурные решения.

• Где ведётся учёт: управленческий, бухгалтерский, налоговый — в одной системе, в нескольких контурах или в гибридной схеме.
• Что считается источником истины: ERP, специализированная система, мастер-данные, интеграционная шина или утверждённый регламент сверки.
• Допустимы ли временные расхождения: между оперативным и бухгалтерским контуром, между фактом и закрытием, между отгрузкой и финансовым отражением.
• Разрешены ли постфактум-корректировки: кем, в какие сроки, по каким основаниям, с какими следами в системе.
• Как считается себестоимость: серийное производство, заказы, полуфабрикаты, возвраты, гарантийные затраты, распределяемые косвенные расходы.
• Как устроено закрытие периода: что блокируется технически, что допускается организационно, а что вообще не должно быть возможно.

Ключевая мысль здесь простая: если в целевой модели ERP не определены правила исключений, то исключения и станут реальной архитектурой системы.

Что фиксирует архитектор ERP в целевой модели

Архитектор должен зафиксировать не только схему процессов, но и набор архитектурных артефактов, без которых проектирование целевой модели ERP остаётся декларацией.

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

Если этого нет — система развалится не сразу, а через накопление локальных отклонений. Сначала появятся «временные» обходы, потом Excel-сверки, потом спор о правильных цифрах, а затем недоверие к самой ERP как к управленческому инструменту.

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

• TO-BE архитектура ERP с границами систем, ролями контуров и потоками данных.
• ADR (Architecture Decision Records) по ключевым решениям: учёт, себестоимость, интеграции, мастер-данные, закрытие периода.
• Архитектурные принципы — 10–15 правил, которые ограничивают хаотичное развитие системы.
• Матрица источников истины по основным объектам данных.
• Модель исключений — какие отклонения допустимы, кем утверждаются и как контролируются.
• Схема финансового контура — от первичных операций до итоговых регистров и отчётности.

Это уже не просто документы для согласования. Это инструменты, через которые можно останавливать разрушительные решения в ходе проекта.

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

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

• Для каждого ключевого объекта данных определён единственный источник истины.
• Для каждого вида учёта зафиксировано место ведения и правила консолидации.
• Для спорных решений оформлены ADR, а не устные договорённости.
• Понятно, какие исключения допустимы, а какие запрещены принципиально.
• Есть правила закрытия периода, которые можно реализовать в системе, а не только описать словами.
• Можно объяснить, как формируется каждая критичная цифра в отчётности.

Критерий успеха в сильной формулировке: после этапа проектирования целевой модели ERP нельзя без последствий «протащить» локальное исключение как будто это мелочь.

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

• Не зафиксированы канонические данные. В результате один и тот же объект живёт в нескольких версиях и начинает разрушать аналитику.
• Смешаны архитектура и организационные компромиссы. Тогда временная договорённость превращается в постоянную техническую обязанность системы.
• Себестоимость обсуждается слишком поздно. Это одна из самых дорогих ошибок: потом придётся переделывать проводки, регистры, аналитику и интеграции.
• Нет модели исключений. Бизнес начинает просить частные обходы, и каждый такой обход ослабляет весь контур контроля.
• Правила закрытия периода не поддержаны технически. Тогда регламент есть, но реально он не работает.
• Слишком рано уходят в детали реализации. Команда спорит о документах и формах, когда ещё не решено, где вообще живёт финансовая истина.

Последствия 2–3 порядка здесь особенно опасны: сначала растёт число ручных корректировок, затем появляется параллельный учёт, потом падает доверие к отчётности, а после этого ERP перестаёт быть управленческой платформой и превращается в транзакционный архив.

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

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

• разводит по уровням: где бизнес-требование, где ограничение учёта, где реальная архитектурная развилка;
• фиксирует решения письменно, чтобы потом не спорить о том, «что имелось в виду»;
• проверяет, что исключения не ломают базовую модель данных;
• защищает принципы целевой модели ERP от локального давления подразделений;
• связывает процессы, данные, учёт и техническую реализуемость в одну конструкцию.

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

Как проверить и диагностировать слабую целевую модель ERP

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

• Можно ли однозначно ответить, где живёт истина по номенклатуре, договорам, статьям затрат и финансовым аналитикам?
• Можно ли объяснить, как одна операция проходит через оперативный, бухгалтерский и управленческий контур?
• Понятно ли, какие данные можно изменить задним числом и кто имеет на это право?
• Есть ли документированные решения по себестоимости, возвратам, гарантиям, распределению косвенных затрат?
• Есть ли правило, которое запрещает отдельным системам писать в ERP напрямую в обход утверждённой модели?

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

Альтернативный взгляд: где это не работает

Есть соблазн считать, что глубокое проектирование целевой модели ERP нужно всегда. Это не совсем так.

Такой подход может быть избыточен, если:

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

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

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

⚠️ Ключевой риск: если не зафиксировать архитектурные решения сейчас, потом бизнес начнёт просить исключения. Каждое такое исключение будет выглядеть небольшим, но в сумме именно они и разрушат систему.

Что если я заблуждаюсь?

Возможно, в вашей ситуации проблема не в слабом проектировании целевой модели ERP, а в том, что организация пока не готова к единому ядру и объективно нуждается в переходной архитектуре. Тогда вопрос не в том, чтобы «дожать идеальную модель», а в том, чтобы честно описать временную схему, срок её жизни и условия выхода из неё. Ошибка не в компромиссе как таковом. Ошибка — в неявном компромиссе, который потом выдают за полноценную архитектуру.

Проверочные вопросы для читателя

• Можете ли вы без споров назвать источник истины по ключевым финансовым и мастер-данным?
• Есть ли у вас зафиксированные ADR по самым дорогим решениям: учёт, себестоимость, закрытие периода, интеграции?
• Понимаете ли вы, какие «временные исключения» уже сейчас подтачивают вашу будущую архитектуру ERP?