Что делают:

Ставят задачу «внедрить ERP» (например, 1С:ERP).

Как должно быть:

Цель — конкретный бизнес-результат: ускорить оборачиваемость склада, сократить закрытие месяца, повысить прозрачность финансов.

Без измеримых метрик проекта не существует.

Подробнее (что именно ломается):

Когда «внедрить ERP» становится целью, проект превращается в набор задач “настроить/перенести/обучить” без ответа на вопрос “зачем”. В итоге система может быть запущена, но бизнес ничего не почувствует: сроки растянутся, бюджеты вырастут, а итог будет звучать как “ну… стало чуть удобнее”.

Как сделать правильно на практике:

• Формулируйте цель в формате: метрика → базовое значение → целевое значение → срок.
• Привязывайте метрики к владельцам процессов: склад, финансы, продажи, закупки.
• Фиксируйте 5–10 KPI проекта и отслеживайте их на каждом статусе.

Примеры измеримых целей:

• “Сократить закрытие месяца с 12 до 5 рабочих дней за 4 месяца после запуска.”
• “Повысить точность складских остатков до 98% за 2 месяца.”
• “Снизить долю ручных корректировок себестоимости на 60% за квартал.”

Что делают:

Ответственность размыта между подразделениями и подрядчиком.

Как должно быть:

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

Подробнее (почему это критично):

ERP-проект — это постоянно возникающие развилки: что считать “истиной” (цены, остатки, правила учета), какие процессы “обязательные”, какие можно упростить, где допускаются исключения. Если нет одного владельца результата, каждое решение превращается в круг согласований, а подрядчик оказывается в позиции “мы ждем”.

Как должен выглядеть владелец результата:

• Имеет полномочия “решать”, а не “носить на согласование”.
• Управляет приоритетами (что делаем сейчас, что переносим).
• Защищает KPI проекта и может требовать дисциплину выполнения правил.

Практический признак, что владельца нет:

• На совещаниях много “мы подумаем” и “надо согласовать”.
• Дедлайны сдвигаются из-за решений, а не из-за разработки.
• Бизнес-подразделения “не считают проект своим”.

Что делают:

Назначают ответственным ИТ или техподдержку без вовлечения бизнеса.

Как должно быть:

Проектом управляет бизнес-руководитель (операционный или финансовый директор).

Ключевые пользователи участвуют в проекте постоянно.

Подробнее (где возникает провал):

ИТ может качественно настроить систему, интеграции, серверы, права — но не может заменить владельцев процессов. ERP меняет “как мы работаем”: кто вводит данные, кто подтверждает, кто несет ответственность, какие правила обязательны. Это зона бизнеса, не техподдержки.

Как выстроить роль ИТ правильно:

• ИТ отвечает за инфраструктуру, интеграции, безопасность, производительность, эксплуатацию.
• Бизнес отвечает за регламенты, правила учета, мастер-данные, дисциплину внесения информации.
• Ключевые пользователи — не “по возможности”, а по плану (регулярные сессии + тестирование сценариев).

Сильная практика:

Назначить “процессных владельцев” по направлениям (склад, закупки, продажи, финансы) и закрепить ответственность за результат в KPI.

Что делают:

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

Как должно быть:

Сначала — упрощение и выравнивание процессов.

Потом — автоматизация.

ERP усиливает логику, но не создаёт её.

Подробнее (почему “как сейчас” — ловушка):

Если в компании много исключений, обходных схем, ручных “костылей”, то попытка перенести это в ERP приводит к взрывному росту сложности: правила становятся нечитаемыми, обучение невозможным, отчеты противоречивыми.

Как правильно:

• Описать “как должно быть” (целевой процесс), а не “как есть”.
• Ввести минимальный набор обязательных правил (например: единый справочник номенклатуры, единые статусы документов, единая схема согласования).
• Ограничить исключения и формализовать их (чтобы это было не “устно”, а “вот правило”).

Практический фильтр:

Если процесс невозможно объяснить новичку за 10–15 минут — автоматизировать рано.

Что делают:

Переносят данные «как есть»: дубли, ошибки, некорректные остатки.

Как должно быть:

Подготовка и очистка данных — обязательный этап.

Иначе отчёты не вызывают доверия с первого дня.

Подробнее (что происходит после запуска):

Если на старте в системе “грязные” данные, пользователи перестают верить отчетам и возвращаются в Excel. А дальше запускается цепочка: правки вручную → расхождения → конфликт между подразделениями → “ERP виновата”.

Что обязательно чистить до миграции:

• Контрагенты (дубли, ИНН/регистрационные данные, договоры, условия оплат).
• Номенклатура (единицы, характеристики, штрихкоды, группы, аналоги).
• Остатки (складские, взаиморасчеты, себестоимость/партии).
• НСИ для аналитик (проекты/направления, статьи затрат, ЦФО, склады).

Практика “быстрый контроль качества”:

Сделайте контрольный отчет “до/после” по ключевым остаткам и расхождениям + отдельный список дублей и спорных записей, за которые назначены ответственные.

Что делают:

Рассчитывают, что ERP автоматически наведёт порядок.

Как должно быть:

ERP — инструмент исполнения правил, а не замена управлению и дисциплине.

Подробнее (главная иллюзия):

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

Как “включается” ERP на самом деле:

• Регламенты (кто и когда вводит, кто подтверждает, кто отвечает).
• Контрольные точки (закрытие периодов, контроль отрицательных остатков, контроль себестоимости).
• Полномочия и ограничения (права доступа, запреты на “обходные” операции).

Простой принцип:

Сначала правила — потом автоматизация их исполнения.

Что делают:

Массово дорабатывают систему под старые схемы работы.

Как должно быть:

Использовать стандартные отраслевые механизмы на 70–80%.

Процессы адаптируются под лучшие практики ERP.

Подробнее (почему “доработаем всё” опасно):

Гиперкастомизация быстро превращает проект в разработку “самописной системы на базе ERP”. Риски: рост сроков, зависимость от конкретных разработчиков, сложные обновления, повышенная стоимость сопровождения.

Где доработки оправданы:

• Законодательные или отраслевые требования, которые нельзя покрыть типовым функционалом.
• Критические конкурентные процессы, дающие бизнес-эффект (и это доказано цифрами).
• Интеграции и автоматизация “стыков” между системами.

Контрольный вопрос перед каждой доработкой:

“Мы делаем это потому что надо для результата, или потому что так привыкли?”

Что делают:

Проводят одно вводное обучение и считают тему закрытой.

Как должно быть:

Обучение по ролям и сценариям работы: до запуска, в пилоте, после старта.

Подробнее (почему “один тренинг” не работает):

ERP — это не “новая кнопка”, а новая логика действий. Люди запоминают не интерфейс, а сценарии: “как оформить приход”, “как провести инвентаризацию”, “как закрыть месяц”, “что делать при возврате”.

Как сделать обучение рабочим:

• Обучение по ролям: кладовщик, бухгалтер, закупщик, менеджер продаж, финансовый контролер.
• Обучение по сценариям, а не по меню.
• Короткие инструкции + видео/скриншоты + база вопросов.
• “Суперпользователи” внутри компании, которые помогают после запуска.

Практика для снижения ошибок:

Первые недели — ежедневные разборы типовых ошибок и корректировка инструкций “по живым кейсам”.

Что делают:

Считают проект завершённым в день запуска.

Как должно быть:

Первые 6–12 месяцев — контроль фактического использования, достижения KPI и корректировки процессов.

Подробнее (что реально происходит после запуска):

Запуск — это старт реальной эксплуатации, а не финал. В первые месяцы всплывают “узкие места”: где не хватает данных, где пользователи обходят правила, где регламенты не выдерживают нагрузку.

Что должно быть в постпроектном контроле:

• Отслеживание KPI (те самые измеримые метрики из пункта 1).
• Контроль качества ввода (ошибки, непроведенные документы, ручные корректировки).
• Контроль дисциплины процессов (сроки ввода, закрытие периодов).
• План улучшений (не “пожары”, а управляемый backlog).

Хорошая практика:

Еженедельный операционный контроль + ежемесячный управленческий комитет по KPI.

Что делают:

Выбирают самое дешёвое предложение.

Как должно быть:

Оценка по трём критериям: опыт в отрасли, методология, состав команды.

Дешёвое внедрение почти всегда обходится дороже.

Подробнее (почему “дешево” часто становится “дорого”):

Самая частая причина перерасхода — не ставка подрядчика, а ошибки планирования и методологии: слабый анализ, отсутствие контроля изменений, плохая работа с данными, отсутствие управленческого контура, недостаточная вовлеченность пользователей.

Как оценивать подрядчика здраво:

• Опыт в вашей отрасли и похожих масштабах (не “внедряли ERP”, а “внедряли в похожем бизнесе”).
• Методология (как ведут обследование, проектирование, тестирование, запуск, поддержку).
• Команда (кто именно будет работать: аналитики, архитектор, руководитель проекта).

Практическая проверка:

Попросить показать пример артефактов: план работ, протоколы решений, матрицу ролей, подход к миграции данных, пример сценариев тестирования.

Цели → Владелец → Процессы → Данные → Система → Обучение → Контроль

Расшифровка логики (чтобы можно было “пощупать”):

• Цели — конкретные цифры и сроки.
• Владелец — человек, который отвечает за результат и решения.
• Процессы — упрощены, выровнены, понятны, без бесконечных исключений.
• Данные — очищены, проверены, назначены ответственные.
• Система — автоматизирует правила, а не заменяет управление.
• Обучение — по ролям и сценариям, с поддержкой после запуска.
• Контроль — 6–12 месяцев удержания дисциплины и KPI.

«У нас особый бизнес, стандартные подходы не подойдут»

Как смотреть на это трезво:

Особенность бизнеса обычно действительно есть — но она редко требует “особой ERP”. Чаще она требует ясных правил, прозрачных данных и дисциплины исполнения. Стандартные механизмы закрывают основу, а “особенности” должны быть точечными, оправданными и измеримыми.

Чем сложнее бизнес, тем опаснее начинать не с управления, а сразу с системы.