Юлий Минькин
С ERP проектами сейчас происходит ровно то же самое, что и со многими модными инструментами: все слышали, все вроде бы понимают, как это должно работать, но когда доходит до реального внедрения — начинаются странные паузы. И в какой-то момент выясняется простая вещь: внедрять нечего.
Не потому что система плохая. Не потому что подрядчик слабый. А потому что требований нет.
Проблема, о которой не принято говорить
О требованиях обычно говорят как о чем-то само собой разумеющемся. Предполагается, что бизнес и так знает, что ему нужно. Что процессы описаны, цели понятны, ограничения зафиксированы.
На практике все иначе.
В проектах часто встречается ситуация, когда на старте есть только общее ожидание: «хотим ERP», «нужно автоматизировать», «надо навести порядок». Звучит уверенно. Но за этими формулировками нет конкретики.
- Нет методологии.
- Нет описанных процессов.
- Нет зафиксированных ролей.
- Нет понимания, какие задачи система должна решать в первую очередь.
И это не мелкая недоработка. Это точка, в которой проект уже начинает терять устойчивость.
Почему отсутствие требований — критическая ошибка
Когда требований нет, команда оказывается в ситуации, где любое решение становится предположением. А предположения в проекте — это всегда риск. В итоге происходит следующее:
- разработчики делают «как понимают»
- заказчик оценивает «как чувствует»
- сроки начинают плыть
- бюджет перестает быть ориентиром
И самое неприятное — невозможно объективно сказать, что сделано правильно, а что нет. Нет базы для оценки. Если требования не сформированы, проект фактически лишается предмета внедрения.
То есть команда может работать, тратить время, обсуждать решения — но двигаться не к результату, а в сторону.
Почему требования не формируются
Причина здесь не в лени и не в отсутствии компетенций. Чаще всего проблема глубже.
Бизнес живет в операционной реальности. Процессы выполняются «по привычке», решения принимаются ситуативно. Когда просят описать, как все устроено, возникает ступор.
Потому что:
- часть процессов никогда не была формализована
- многие решения держатся на конкретных людях
- есть внутренние противоречия, которые никто не хочет фиксировать
Добавляется еще один фактор — ожидание, что подрядчик «сам разберется». Что он придет, задаст правильные вопросы и соберет требования.
Частично это возможно. Но только частично.
Иллюзия старта проекта
Очень часто проект формально стартует, но по факту не начинается.
Подписан договор. Сформирована команда. Проведены установочные встречи.
И в какой-то момент наступает тишина. Потому что внедрять нечего.
Нет согласованных требований. Нет зафиксированного объема. Нет понимания, что является результатом. Проект не падает резко. Он замирает.
Что происходит дальше
Дальше обычно есть два сценария.
Первый — попытка двигаться без требований. Начинается разработка «по ходу». Возникает постоянный поток изменений, переделок, уточнений. Команда устает, заказчик разочаровывается.
Второй — проект ставится на паузу. Формулируется это аккуратно: «нужно доработать требования», «вернемся позже», «сейчас не время».
Но по сути это означает одно — на старте была пропущена ключевая стадия.
Почему требования — это не формальность
Требования — это не документы ради документов.
Это:
- способ договориться о результате
- инструмент управления ожиданиями
- основа для планирования
Без этого ERP превращается в набор функций без смысла.
Система может быть настроена, модули могут быть внедрены, но бизнес не получает ценности.
Что действительно важно
Самый важный момент здесь в том, что требования нельзя «дописать потом».
Это не этап, который можно пропустить и вернуться к нему позже без потерь.
Если на старте нет ясности, проект уже работает с искаженной логикой.
Поэтому ключевая задача — не просто «собрать требования», а сделать это честно:
- зафиксировать реальные процессы, а не желаемые
- выявить противоречия
- определить приоритеты
Это требует времени. Это требует вовлеченности бизнеса. Это требует готовности разбираться.
Но без этого внедрение превращается в движение без направления.
Итог
Основная проблема ERP-проектов действительно не в плохих требованиях.
Проблема в их отсутствии.
И пока это не признается на старте, проект будет либо бесконечно переделываться, либо в какой-то момент остановится. Потому что нельзя внедрить то, что не определено.
=====================================================
Больше полезных материалов, разборов и практики по ERP и управлению проектами — в нашем Telegram-канале. Подписывайтесь, там регулярно делимся тем, что реально работает.
Комплексная автоматизация бизнеса под ключ. Покажем, как система закроет именно ваши задачи и где можно получить быстрый эффект. Запросить консультацию → erp.lab@1cbit.ru