По данным Gartner, более 55% крупных ERP-проектов выходят за рамки бюджета или сроков, а каждый пятый полностью проваливается. Эти цифры не изменились за последние 15 лет — несмотря на совершенствование технологий, облачные решения и agile-методологии. Причина всегда одна: технология покупается до того, как понятен процесс.
Технология не компенсирует отсутствие процесса
Распространённая иллюзия: если купить достаточно мощную ERP-систему, она сама по себе «наведёт порядок» в операционной деятельности. Это фундаментально ошибочное представление. ERP — это инструмент для выполнения процессов, а не для их создания.
Если процесс закупки в компании не описан, непонятно, кто за что отвечает, и каждый менеджер делает это по-своему — ERP просто сделает этот хаос быстрее и дороже. Система не заменяет управленческое решение: она его автоматизирует.
Это не значит, что нужно достичь идеальной эффективности до начала автоматизации. Но базовая архитектура процессов — чёткие роли, понятные шаги, определённые результаты каждого этапа — должна существовать до того, как начнётся любая техническая работа.
Что такое архитектура процессов и зачем она нужна
Архитектура процессов — это не BPMN-диаграммы ради диаграмм. Это структура ответов на три вопроса: что происходит (шаги), кто отвечает (роли), что является результатом каждого шага (артефакты). Без этих ответов любая техническая спецификация будет неполной.
На практике архитектура процессов выглядит как набор документов: регламентов для критических процессов, матрицы ответственности (RACI), SLA между отделами. Это не бюрократия — это язык, на котором бизнес может говорить с IT-командой.
Компании, у которых есть задокументированные процессы до начала ERP-проекта, в среднем завершают внедрение на 40% быстрее и укладываются в бюджет вдвое чаще. Это не корреляция — это причинно-следственная связь.
Как выглядит провальное внедрение изнутри
Типичный сценарий: компания подписывает контракт с интегратором, начинается сбор требований. Встречи длятся неделями — потому что каждый отдел рассказывает о своём процессе по-своему, и никто не знает, какая версия правильная. Итоговое техническое задание — компромисс между противоречивыми требованиями.
Разработка начинается на нечётком фундаменте. В процессе выясняется, что реальный процесс отличается от задокументированного. Система переделывается. Бюджет выходит за рамки. Сроки срываются. После запуска система используется не полностью — потому что людям непонятно, как она вписывается в их реальную работу.
Всё это — симптомы одного: отсутствия процессной архитектуры до начала технического проектирования.
Практический подход: что сделать перед стартом ERP-проекта
Шаг первый: идентифицируйте пять-семь ключевых процессов, которые ERP должна охватить. Не все — только критичные для операционной эффективности. Закупка, производство, склад, продажи, финансовое закрытие.
Шаг второй: для каждого процесса опишите AS-IS — как он происходит сейчас, со всеми отклонениями и исключениями. Затем TO-BE — как он должен происходить после автоматизации. Разница между AS-IS и TO-BE — это и есть объём изменений, которым нужно управлять.
Шаг третий: утвердите TO-BE на уровне руководства до начала любой технической работы. Это критично — потому что все последующие технические решения будут приниматься на основе этих утверждённых процессов. Изменение процесса после начала разработки — самая дорогая операция в ERP-проекте.
Корпоративные системы терпят неудачу не из-за плохой технологии. Они терпят неудачу, потому что организация пытается купить порядок вместо того, чтобы его выстроить. ERP — мощный инструмент, но только в руках компании, которая знает, что хочет автоматизировать. Архитектура процессов — это не предпроектная формальность. Это фундамент, без которого любая технология превращается в дорогую проблему.
Связанные услуги