ЭТАП 3. ERP и финансы: архитектура бюджетирования и казначейства (3–6 месяцев)

Цель

Убрать Excel из роли «центрального мозга» и закрепить единую финансовую модель принятия решений внутри ERP.

Если этого не сделать — система превращается в витрину, а не в систему управления.

---

Что на практике происходит (и где ошибка)

Компании почти всегда делают одно и то же:

• ERP = учёт факта
• Excel = планирование и контроль
• BI = «красивые отчёты»

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

Следствие 2-го порядка:

• решения принимаются вне системы
• ERP становится «обязательной бюрократией»
• бюджет перестаёт быть инструментом управления

---

Архитектурные вопросы (на которые нельзя не ответить)

1. Где живёт БДР и ДДС

Варианты:

• ERP → единый источник истины
• BI → только визуализация
• Excel → запрещён как источник решений

Если БДР/ДДС живут вне ERP →
вы теряете управляемость денежного потока

---

2. Что такое план / лимит / факт

На практике это часто смешано — и это разрушает систему.

Разделение должно быть жёстким:

• План — намерение (budget)
• Лимит — разрешение (control)
• Факт — событие (execution)

Если лимит = план →
контроль фиктивный

---

3. Где допустим гибрид ERP + BI

Допустимо:

• аналитика
• drill-down
• прогнозы

Недопустимо:

• ввод данных
• принятие решений
• фиксация лимитов

Если BI начинает влиять на управление →
у вас появляется второй «мозг» системы

---

Проектные решения (ядро этапа)

Контур согласования платежей

Цель:
связать бюджет → лимит → платёж

Что должно быть:

• платёж без лимита невозможен
• согласование встроено в процесс, а не отдельно
• маршрут согласования зависит от типа затрат

Артефакты:

• модель маршрутов согласования
• матрица лимитов
• правила блокировок

Критерий успеха:
невозможно провести платёж вне бюджета

Риски:

• «временные обходы» → становятся постоянными
• ручные согласования в почте

---

Асинхронность банковских интеграций

Реальность:
банк = внешняя система с задержками и сбоями

Архитектурное решение:

• события вместо синхронных вызовов
• статусная модель платежа
• идемпотентность (idempotency — защита от повторов)

Артефакты:

• state machine платежа
• SLA на обработку

Критерий успеха:
система выдерживает сбои банка без потери контроля

Риски:

• двойные платежи
• потерянные статусы

---

Очереди, ретраи, контроль дублей

Это не «техническая деталь», а финансовый риск

Что должно быть:

• очередь отправки платежей
• retry с контролем попыток
• дедупликация по бизнес-ключу

Артефакты:

• схема очередей
• политика retry
• алгоритм дедупликации

Критерий успеха:
ни один платёж не теряется и не дублируется

---

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

Не рисует схемы.

Он:

• запрещает Excel как источник решений
• вводит понятие лимита как механизма контроля
• связывает бюджет с операциями
• определяет SLA финансовых операций
• ставит границы между ERP и BI

Если этого нет —
архитектор превращается в «консультанта без власти»

---

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

Задай 5 вопросов:

1. Можно ли провести платёж вне бюджета?
2. Где фактически живёт БДР — в ERP или Excel?
3. Есть ли единое определение «лимита»?
4. Что произойдёт при сбое банка?
5. Есть ли дубли платежей в истории?

Если хотя бы 2 ответа «плохо» →
финансовая архитектура уже нестабильна

---

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

Этот подход не подходит:

• стартапам (слишком тяжело)
• малому бизнесу (избыточная сложность)
• компаниям без дисциплины процессов

Trade-off:

• контроль ↑
• скорость ↓

Но:

если у вас обороты и сложные потоки →
без этого контроль иллюзия

---

Результаты этапа

• Архитектура бюджетирования
• Архитектура казначейства
• Реестр критичных операций (SLA)
• Модель контроля лимитов
• Контур платежей