Есть одна ошибка, которая убивает внедрение 1С:ERP ещё до того, как вы успеете открыть первый справочник.
Ошибка звучит невинно:
«Давайте быстрее к процессам и настройкам. Директивы и “бумаги” потом разберём».
А потом начинается вечная карусель:
- «вчера договорились так, сегодня — иначе»;
- «почему вы сделали не так, как я хотел?»;
- «а мы это вообще не обсуждали»;
- «срочно переделайте — у нас поменялась политика».
И в какой-то момент команда понимает, что внедряет не систему, а коллекцию постоянно меняющихся ожиданий.
Эту проблему решает один простой, но железный артефакт.
Вопрос подписчика
Зачем на старте ещё какие-то “директивные документы”? У нас есть договор/ТЗ/письмо руководителя. Давайте быстрее к процессам и настройкам.
Суть проблемы
Внедрение 1С:ERP всегда проходит через конфликт интересов.
Производство хочет «чтобы не мешали выпуску». Склад хочет «чтобы было быстро». Финансы хотят «чтобы цифры сходились». Коммерция хочет «чтобы клиент не ждал». ИТ хочет «чтобы всё было типовым и поддерживаемым». Руководитель хочет «чтобы было управляемо». Собственник хочет «чтобы предприятие стало сильнее».
Если правила игры не зафиксированы, проект неизбежно живёт в режиме:
- «у каждого своя правда»;
- «мы думали, что это важно, а оказалось — нет»;
- «переделаем задним числом»;
- «сначала настроим, потом решим, как считать».
И это бьёт по всему:
- процессы начинают расползаться;
- НСИ не собирается (потому что непонятно, какие аналитики обязательны);
- миграция превращается в пожар;
- KPI и финпоказатели становятся спором, а не цифрой.
Нужна “конституция проекта” — один документ, который делает проект жёстким и воспроизводимым.
Артефакты статьи
В этой статье — один артефакт:
Артефакт №1 — «Протокол обработки директивных документов».
Что такое артефакт №1 (определение)
Протокол обработки директивных документов — это зафиксированный документ проекта, который:
- собирает все директивы (решения собственника/руководства, письма, протоколы, приказы, ограничения, ключевые требования);
- переводит их в проектные правила (что обязательно / что запрещено / что критично);
- задаёт границы периметра (что в волне 1, что позже, что вне проекта);
- формирует критерии успеха (что будет считаться “внедрили”);
- вводит режим управления изменениями (как меняются директивы и кто имеет право менять).
Короткая формула:
Артефакт №1 — это конституция проекта 1С:ERP.
Без неё вы строите систему в песке.
Что именно входит в протокол (простая структура)
Чтобы артефакт работал, он должен быть не «письмом на две страницы», а документом, где директивы становятся управляемыми.
1) Реестр директивных документов
Список источников: дата, кто инициатор, статус, ссылка/вложение.
2) Извлечённые директивы (по пунктам)
Только “как есть”. Без интерпретаций. Это важно: интерпретации будут позже — в требованиях.
3) Перевод директив в проектные требования
Удобный формат — три уровня:
- MUST (обязательно);
- SHOULD (желательно);
- MUST NOT (запрещено).
4) Ограничения и допущения
Сроки, ресурсы, уровень детализации, требования к безопасности/ЭДО/интеграциям.
5) Периметр и волны
Что делаем в волне 1, что удерживаем в архитектуре «на потом» (будущий реестр заглушек).
6) Критерии успеха
Не «всё будет хорошо», а 5–10 конкретных признаков: что будет считаться результатом.
7) Правила изменения директив
Кто может инициировать изменение, кто утверждает, как фиксируется (обязательно письменно) и как оно отражается в требованиях, модели процессов, плане-графике и смете.
Как артефакт №1 прошивает слои TOGAF/ArchiMate
Эта часть — короткая, без академизма.
Если вы хотите проект, который живёт по архитектурной логике (TOGAF) и не смешивает слои (ArchiMate), то артефакт №1 должен ответить на вопросы на каждом уровне:
- Бизнес‑слой: какие цели и процессы являются критичными.
- Данные/НСИ: какие аналитики обязаны стать «правдой» (иначе финрезультат и KPI превращаются в гадание).
- Приложения 1С:ERP: какие прикладные контуры обязательны в волне 1.
- Техслой: какие интеграции/ЭДО/режимы эксплуатации обязательны.
- Управленческий слой: какие показатели, KPI и финрезультаты нужны — и что будет считаться успехом.
Суть: директива — это не “желание руководителя”. Это входной сигнал, который должен превратиться в правила и критерии на всех слоях.
Цепочка «Артефакт 1 → следующий этап»
Вот почему артефакт №1 нельзя откладывать «на потом».
- Арт.1 → Арт.2–4 (интервью и вопросники): чтобы обследование шло в правильном направлении.
- Арт.1 → Арт.5–6 (транскрипции/требования): чтобы требования были не пересказом, а фиксацией обязательного.
- Арт.1 → Арт.7–8 (модель процессов/заглушки): чтобы волна 1 была управляемой, а не «всё и сразу».
- Арт.1 → Арт.20–23 (доработки/карта сервисов): чтобы решения по разработке принимались по правилам, а не по эмоциям.
- Арт.1 → Арт.24–26 (итог проектирования/план/смета): директивы превращаются в календарь и бюджет.
- Арт.1 → Арт.32–38 (регламенты миграции): чтобы переходный период жил по правилам.
- Арт.1 → Арт.45 (приказ точки перехода): чтобы запуск был легальным и управляемым.
Хороший сценарий
- Директивы собраны и переведены в правила.
- У проекта появляется “конституция”.
- Спорные моменты решаются ссылкой на протокол, а не «кто громче сказал».
- Объём управляется через волны и заглушки.
- Сроки и бюджет становятся реальными.
- Миграция и запуск перестают быть хаосом.
Плохой сценарий (если «не делать артефакт №1»)
- Директивы существуют «в голове».
- Каждую неделю меняются цели и периметр.
- Требования расползаются.
- Настройки и доработки делаются “на вкус”, потом переписываются.
- К миграции приходят без правил — начинается пожар.
- KPI и финрезультат становятся спором.
И самое неприятное: виноватых не найти. Потому что нигде не было зафиксировано «как договорились».
Итог простыми словами
Артефакт №1 нужен не ради отчёта.
Он нужен, чтобы внедрение 1С:ERP перестало быть разговором и стало инженерной сборкой.
Если у проекта нет “конституции”, то в какой-то момент вы поймёте, что внедряете не ERP, а бесконечный поток изменяющихся пожеланий.
Мини‑чеклист для заказчика
Если вы — со стороны заказчика и хотите, чтобы проект не поплыл, попросите у проектной команды:
- Реестр директив (с источниками и датами).
- Список извлечённых директив “как есть” (без интерпретаций).
- Перевод директив в MUST/SHOULD/MUST NOT.
- Периметр и волны + правило “как меняем периметр”.
- Критерии успеха (5–10 пунктов).
- Один ответственный за изменения директив (кто утверждает финально).
Что дальше
В следующей статье разбираем Артефакты 2–4 — стратегические интервью, предварительную архитектуру АСУП и адаптированные вопросники.
Там покажу, как из «директив» делается управляемое обследование, а не разговор «обо всём сразу».