Экспертиза затянувшегося ERP-проекта отвечает на три вопроса: что именно задерживает проект, кто может это устранить и что делать дальше — продолжать по уточнённому плану, сократить ближайший этап или менять исполнителя. Проверяют четыре области: постановку задачи, данные, участие самого предприятия и работу подрядчика. Результат — заключение с фактами и вариантами решения, а не новый список взаимных претензий.
Признаки знакомы многим руководителям. Этапы сдвигаются уже не первый раз. Акты подписаны, а работать в системе пока нельзя. Пользователи ведут учёт параллельно в таблицах. Подрядчик говорит о неготовых данных и меняющихся требованиях, подразделения — о неудобной системе и ошибках. Бюджет дополнительных работ растёт, а дата запуска остаётся прогнозом.
Материал написан с позиции руководителя ERP-проекта на стороне заказчика: в этой роли приходится одновременно держать архитектуру учёта, требования подразделений и работу нескольких исполнителей.
Почему внедрение ERP затягивается?
Каждая сторона обычно права в своей части. Подрядчик действительно не может закончить настройку производства, если не утверждена модель учёта и не готов справочник номенклатуры. Подразделения действительно получают неудобные документы, если их сценарии работы никто не описал. Руководство действительно видит рост затрат, потому что каждое уточнение оформляется как дополнительная работа.
Поэтому вопрос «кто виноват» мало помогает. Полезнее понять, какое условие сейчас мешает следующему шагу проекта, кто может его обеспечить и сколько это займёт. Пока это не установлено, любая мера — смена подрядчика, усиление контроля, новый план — остаётся предположением.
Четыре области проверки
| Область | Типичные признаки | Что проверить |
|---|---|---|
| Постановка | Требования перечисляют функции, а не рабочие ситуации; каждая демонстрация рождает новые пожелания | Есть ли описанные сценарии и критерии приёмки этапов; кто и как утверждает изменения требований |
| Данные | Перенос остатков и справочников повторяется; в системе дубли и ручные исправления | Кто владеет справочниками, по каким правилам они ведутся, готова ли проверка перенесённых данных |
| Участие предприятия | Решения по спорным вопросам ждут неделями; ключевые специалисты заняты текущей работой | Есть ли владелец проекта с полномочиями, журнал открытых вопросов, время специалистов на проект |
| Исполнение | Повторные ошибки, доработки без описания, зависимость от одного программиста подрядчика | Качество выполненных работ, документация, соответствие доработок требованиям, состав команды |
Проверка опирается на документы проекта, а не на рассказы сторон: протоколы, журнал вопросов и изменений, акты, переписку, настройки и доработки в самой системе. Отдельно смотрят, как пользователи фактически работают: где они обходят систему и почему.
Как отделить работу подрядчика от решений заказчика
Самый чувствительный вопрос экспертизы — граница ответственности. Помогает простой приём: для каждой задержки восстановить, чего не хватало для следующего шага и кто должен был это обеспечить.
Если подрядчик ждал утверждения модели учёта три недели, а решение зависело от двух руководителей предприятия, задержка лежит на стороне заказчика, даже если в отчётах она выглядит как отставание исполнителя. Если же доработку переделывали несколько раз из-за ошибок, а требования к ней не менялись, это вопрос к качеству исполнения.
Часто картина смешанная. Тогда заключение должно показать обе части без смягчений: какие решения предприятию нужно принять и в какой срок, и какие обязательства подрядчика выполнены не полностью.
Учебный пример: этап запасов и производства
Учебный пример. Ситуация создана для объяснения метода и не описывает конкретное предприятие.
На производственном предприятии этап «запасы и производство» сдвигали дважды. Подрядчик ссылается на неготовый справочник номенклатуры, производство — на неудобные документы выпуска, финансовая служба не доверяет остаткам.
Проверка показывает три связанных обстоятельства. Справочник номенклатуры ведут два подразделения без общих правил, поэтому при каждом переносе появляются дубли. Сценарий выпуска продукции так и не согласовали: подрядчик настроил вариант, который показался ему типовым. Часть доработок выполнена по устным просьбам пользователей, без описания и приёмки.
Решения следуют из найденного: назначить владельца справочника и правила его ведения, утвердить два-три сценария выпуска и принять этап на них, остановить новые доработки до приёмки базового сценария. Смена подрядчика в этом случае не решила бы проблему: новые специалисты столкнулись бы с теми же неутверждёнными сценариями и данными.
Что должно быть в заключении экспертизы ERP-проекта?
- Состояние проекта: что фактически работает, что принято формально, что не начато.
- Причины задержек по четырём областям — с указанием, на чём основан каждый вывод.
- Решения, которые должно принять предприятие, с ответственными и сроками.
- Оценка работы подрядчика: что выполнено качественно, что требует исправления.
- Варианты продолжения с последствиями для сроков, затрат и рисков.
- Критерии приёмки ближайшего этапа на рабочих сценариях.
Заключение пишется так, чтобы его можно было обсуждать и с собственником, и с подрядчиком. Это не обвинительный документ, а основа для управленческого решения.
Три решения после экспертизы
Продолжить с текущим исполнителем по уточнённому плану. Подходит, когда основные причины на стороне постановки и решений заказчика, а подрядчик работает качественно. План меняется: ближайший этап привязывается к утверждённым сценариям и критериям приёмки.
Сократить ближайший этап. Подходит, когда проект пытается запустить слишком много одновременно. Выбирают участок, который можно довести до работающего состояния, и переносят остальное. Это снижает риск, но требует честно объяснить подразделениям, что их задачи переносятся.
Сменить исполнителя. Оправдано, когда экспертиза подтвердила системные проблемы качества или компетенции, которые не исправляются. Нужно заранее оценить цену перехода: передачу доработок и документации, время на погружение новой команды, риск потерять уже настроенное.
Как не допустить повторения
Причины затягивания обычно закладываются в начале проекта. Помогают несколько правил: каждый этап принимается на описанных рабочих сценариях, а не по актам; у проекта есть владелец со стороны предприятия с полномочиями и временем; спорные вопросы и изменения требований фиксируются в журнале с ответственным и сроком; справочники и данные имеют владельцев до начала переноса.
Как подготовить сценарии и границы проекта до выбора системы, разобрано в материале «Что руководителю нужно решить до выбора ERP, MES или WMS». Как устроена работа на стороне предприятия — на странице «Решения на 1С».