Внедрение 1С ERP часто проваливается не из-за технологий, а из-за отсутствия архитектурной модели. В этой статье разберу дорожную карту работы архитектора: от анализа AS-IS до запуска финансового контура.
Архитектор ERP и его дорожная карта — это не про диаграммы и не про выбор системы. Это про то, выживет ли финансовый контур компании через 2–3 года.
Большинство проектов ERP ломаются не из-за технологий, а из-за отсутствия архитектурного управления. Ниже — практическая дорожная карта архитектора ERP на горизонте 12–24 месяца.
Что делает архитектор ERP на практике
Архитектор ERP:
- задаёт границы системы и ответственности
- определяет источники истины данных
- проектирует интеграции и каноническую модель
- управляет техническим долгом и TCO (total cost of ownership — совокупная стоимость владения)
Главная ошибка — воспринимать архитектора ERP как «старшего разработчика». Это приводит к разрушению архитектуры уже на этапе внедрения.
Дорожная карта архитектора ERP: этапы внедрения и управления
Горизонт: 12–24 месяца
Роль архитектора — не делать всё, а правильно задать рамки, в которых другие не сломают систему.
ЭТАП 0. Архитектор ERP: фиксация мандата (0–1 месяц)
Цель
Закрепить архитектурную власть и правила принятия решений. Без этого дорожная карта архитектора ERP превращается в формальность, а система — в набор несвязанных решений.
Что делает архитектор ERP
- Фиксирует владельцев данных:
- кто отвечает за корректность финансовых данных (P&L, ДДС);
- кто является источником истины (source of truth).
- Определяет контур принятия решений:
- кто принимает архитектурные решения;
- кто влияет, но не решает;
- кто несёт ответственность за последствия.
- Задаёт границы системы:
- ERP ≠ вся IT-архитектура компании;
- Excel ≠ источник истины;
- «временно» допустимо только с датой отключения.
- Фиксирует правила игры:
- архитектор не отвечает за сроки разработки;
- но имеет право вето на архитектурно опасные решения;
- любое отклонение от архитектуры — осознанный долг.
Артефакты (что должно появиться)
- Документ: Архитектурный мандат
- RACI-модель (кто отвечает / принимает решения)
- Список запрещённых практик
- Реестр допущений и временных решений
Критерий успеха этапа
Если возникает конфликт между сроками и архитектурой — решение не принимается без участия архитектора ERP.
Если архитектор не может остановить плохое решение — он не архитектор, а консультант.
⚠️ Риск: если этот этап пропущен — архитектор ERP превращается в «умного разработчика с мнением», а дорожная карта перестаёт работать.
Этап 1. Анализ AS-IS при внедрении 1С ERP: как найти риски архитектуры
Цель
Не «описать», а выявить точки разрушения финансового контура.
Фокус архитектора
- Где реально рождаются деньги
- продажи (POS, e-commerce),
- себестоимость,
- платежи.
- Где ломается целостность
- дубли справочников,
- Excel-агрегация,
- ручные корректировки.
- Интеграционные ловушки
- синхронные вызовы,
- отсутствие идемпотентности,
- «обмены без хозяина».
Результаты
- Архитектурная карта AS-IS (C4 Level 1–2)
- Реестр интеграций + оценка хрупкости
- Топ-10 рисков закрытия месяца
👉 Ключевая мысль: AS-IS — это карта будущих аварий, а не «как сейчас работает».
ЭТАП 2. Архитектура ERP: проектирование целевой модели (2–4 месяца)
Цель
Сделать ERP ядром, а не «ещё одной системой».
Ключевые архитектурные решения
- Где ведётся:
- управленческий учёт,
- бухгалтерский,
- налоговый.
- Допустимы ли:
- временные расхождения,
- постфактум корректировки.
- Модель себестоимости:
- серийка,
- гарантии,
- возвраты.
Что фиксирует архитектор
- Канонические справочники
- Канонические финансовые регистры
- Правила закрытия периода (что блокируется, что нет)
Результаты
- TO-BE архитектура 1С:ERP
- ADR по ключевым решениям (учёт, себестоимость, финансы)
- Архитектурные принципы (10–15 штук)
⚠️ Риск: если не зафиксировать сейчас — потом «бизнес попросит исключение», и система развалится.
ЭТАП 3. ERP и финансы: архитектура бюджетирования и казначейства (3–6 месяцев)
Цель
Исключить Excel как «мозг компании».
Архитектурные вопросы
- Где живёт БДР / ДДС?
- Что является:
- планом,
- лимитом,
- фактом?
- Где допустим гибрид (ERP + BI), а где — нет?
Проектные решения
- Контур согласования платежей
- Асинхронность банковских интеграций
- Очереди, ретраи, контроль дублей
Результаты
- Архитектура бюджетирования
- Архитектура казначейства
- Реестр критичных операций (SLA)
ЭТАП 4. ERP архитектор: архитектура интеграций (4–8 месяцев)
Цель
Подготовить ландшафт к росту, не переписывая ERP.
Принципы
- ERP не знает о реализации внешних систем
- Только:
- события,
- контракты,
- версии.
- Идемпотентность — обязательна
Что решает архитектор
- Где:
- онлайн,
- асинхрон,
- пакет.
- Нужна ли ESB (чаще — нет, чем да)
- Каноническая модель данных
Результаты
- Реестр интеграций v2
- Контракты данных
- Правила подключения новых систем
ЭТАП 5. Масштабирование ERP системы и эксплуатационная модель (6–12 месяцев)
Цель
Сделать систему предсказуемой в эксплуатации.
Фокус
- Рост:
- магазинов,
- SKU,
- пиковых нагрузок.
- Разделение:
- оперативный контур,
- аналитика / BI.
- Запрет тяжёлых отчётов в ERP.
Результаты
- Нагрузочная модель
- SLA на закрытие периода
- Правила реагирования на инциденты
ЭТАП 6. Эволюция ERP: TCO и архитектурные решения
Цель
Не «красиво», а выживаемо через 3–5 лет.
Архитектор оценивает
- Стоимость изменений
- Рынок специалистов
- Bus-factor
- Технический долг
Результаты
- Карта архитектурных долгов
- План эволюции (ERP → WMS → BI → MDM)
Альтернативный взгляд на работу архитектора ERP
Когда roadmap упрощают:
- бизнес маленький,
- один склад,
- нет e-commerce,
- горизонт 1–2 года.
👉 Тогда:
- бюджетирование можно оставить гибридным,
- BI отложить,
- интеграции упростить.
⚠️ Но: это осознанный долг, а не «так получилось».
Другие альтернативы
Возможные ошибки логики:
- Бизнес не готов быть владельцем данных → архитектура останется формальностью.
- ERP переоценена → реальная ценность в BI и процессах.
- Слишком ранняя фиксация правил задушит развитие.
Как проверить:
- задать бизнесу вопрос:
«Кто владеет цифрами P&L и отвечает за их корректность?» - измерить долю Excel в управленческих решениях
- проверить, кто реально решает архитектурные конфликты
+ There are no comments
Add yours