Почему проваливаются внедрения ERP: 7 признаков и как их проверить 

Провал внедрения почти никогда не выглядит как катастрофа. Он выглядит как проект, который просто идет дольше, чем планировали. Потом еще немного дольше. Потом руководитель обнаруживает, что оплачено две трети бюджета, а склад по-прежнему работает в старой системе.

Все признаки ниже видны без экспертизы и проверяются вашими силами. Если совпадает три и больше — проект болен, и лечить его надо сейчас, пока сдвиг измеряется неделями.

Признак 1. Техническое задание подрядчик пишет сам себе

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

Как проверить за день. Возьмите любой раздел ТЗ и дайте прочитать сотруднику, который выполняет этот процесс руками. Задайте один вопрос: «здесь описано то, что ты делаешь?». Ответ «я не понял, что тут написано» — это тоже ответ, причем плохой.

Отдельно проверьте, есть ли в документе исключения. Любой реальный процесс на три четверти состоит из них: поставка пришла с недостачей, клиент вернул половину партии, счет выставлен на одно юрлицо, а оплата пришла с другого. Техническое задание, в котором описан только гладкий ход событий, гарантирует, что систему придется дорабатывать сразу после запуска, и эти доработки будут считаться изменением объема работ, то есть вашими деньгами.

Признак 2. За два месяца не было ни одного показа на ваших данных

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

Как проверить за день. Попросите показать текущее состояние завтра, без подготовки, на вашей копии данных. Реакция скажет больше, чем любой отчет. Команда, у которой работа идет, показывает промежуточный результат спокойно. Команда, у которой не идет, начинает объяснять, почему сейчас неудачный момент.

Признак 3. Ответы команды расходятся

Самая недооцененная диагностика. Задайте одни и те же три вопроса руководителю проекта со стороны подрядчика, аналитику и разработчику по отдельности, лучше не в один день.

• Какой этап идет сейчас и когда он закрывается?
• Что мешает больше всего?
• Что делает наша сторона неправильно?

Здоровый проект дает три сходящихся ответа с разной степенью детализации. Больной — три разных проекта. Особенно показателен третий вопрос: если никто из команды не может назвать ни одной претензии к заказчику, значит обратной связи в проекте нет вообще, и проблемы копятся молча.

Четвертый вопрос задавайте только руководителю проекта и только наедине: «что мы должны сделать, чтобы вы работали быстрее?». Внятный ответ означает, что человек держит проект в голове. Ответ вида «все нормально, просто нужно немного времени» означает, что не держит.

Признак 4. Оплачено больше, чем работает

Финансовый признак, который считается за полчаса. Возьмите долю оплаченного бюджета и долю процессов, которые реально переехали в новую систему. Если оплачено две трети, а работает один блок из четырех, дальше будет хуже: оставшейся трети бюджета не хватит на три оставшихся блока.

Считать надо честно. Работающим считается процесс, который сотрудники ведут в новой системе ежедневно и без параллельного дубля в старой. Настроенный, но не используемый функционал в этот расчет не входит, каким бы готовым он ни выглядел на демонстрации.

Здесь же смотрите на структуру платежей. Если оплата привязана к календарю, а не к результату, вы финансируете время команды подрядчика вне зависимости от того, что она произвела. Как должна быть устроена привязка оплаты к этапам, разобрано в разборе сметы.

Признак 5. Правки идут в типовую конфигурацию

Технический признак с долгими последствиями. Когда конфигурацию снимают с поддержки ради доработок, каждое обновление превращается в ручную сборку, а любой следующий подрядчик закладывает в оценку месяц на разбор чужого кода.

Как проверить за день. Спросите прямо: снята ли конфигурация с поддержки и что вынесено в расширения. Ответ «мы сделали как удобнее» означает «снята». Механику и последствия разбираем в статье про расширения.

Признак 6. Данные никто не готовил

Проект идет, а справочник номенклатуры в том же виде, в каком был год назад: дубли не размечены, единицы измерения разные, ответственного нет. Это значит, что этап переноса, который выглядит далеким, гарантированно добавит к сроку месяц-полтора в самой неудобной точке.

Как проверить за день. Выгрузите номенклатуру и посчитайте две цифры: сколько всего позиций и сколько из них двигалось за последний год. Если живых меньше трети, а разметка дублей не начиналась, у вас нет плана по данным. Что с этим делать, разобрано в статье про перенос.

Признак 7. Команда подрядчика сменилась дважды

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

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

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

Сводка: семь проверок за один день

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

Что произойдет, если ничего не делать

Буксующие проекты деградируют предсказуемо, и стадии стоит знать заранее, чтобы понимать, где вы находитесь.

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

Стадия вторая: появляется параллельная жизнь. Пользователи, устав ждать, наращивают костыли в старой системе и в таблицах. Здесь проект получает второго врага: даже когда новая система заработает, отказаться от привычных костылей будет тяжело.

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

Стадия четвертая: смена подрядчика. Новый исполнитель закладывает от месяца на разбор чужого кода и почти всегда предлагает часть работ переделать. Бюджет проекта растет в полтора-два раза, срок — на квартал минимум.

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

Отдельно стоит сказать про репутационную сторону внутри компании. К третьей стадии в организации формируется устойчивое мнение, что новая система — это провал, и оно переживет любую техническую победу. Люди, которых полгода кормили обещаниями, встретят работающий функционал недоверием, а обучение придется вести против уже сложившегося отношения. Поэтому лечить проект дешевле не только в деньгах, но и в готовности сотрудников им пользоваться.

Разговор, который спасает проект

Прежде чем менять подрядчика, имеет смысл провести одну встречу, которую почему-то почти никогда не проводят. Формат жесткий, зато работает.

Участники: владелец проекта с вашей стороны, руководитель проекта со стороны подрядчика, по одному человеку от каждой команды, кто реально делает работу. Никаких продавцов и никаких юристов.

Повестка из четырех пунктов. Первое: каждая сторона называет три вещи, которые мешают ей больше всего, причем начинать должна ваша сторона со своих собственных проблем. Второе: составляется общий список решений, которые зависли, с именами и датами. Третье: определяется один ближайший результат, который можно показать через две недели на реальных данных. Четвертое: назначается формат еженедельной сверки.

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

Три признака, которые провалом не являются

Симметричная часть, иначе получится инструкция по травле подрядчика.

Сдвиг срока на две-три недели. Нормальная амплитуда для проекта длиной в год, особенно если сдвиг объяснен и виден заранее.

Много замечаний на опытной эксплуатации. Это признак того, что систему наконец начали смотреть всерьез. Тревожно, когда замечаний нет.

Подрядчик спорит и говорит «нет». Исполнитель, который соглашается на все, просто копит проблемы к финалу. Как выглядит нормальная процедура спора при приемке, описано в статье про критерии приемки.

Что делать, если совпало три и больше

Порядок действий, проверенный логикой. Эмоции тут плохой советчик.

1. Остановите оплату следующего этапа. Ровно следующего, без разрыва договора и без обвинений. Это переводит разговор из плоскости обещаний в плоскость фактов.
2. Запросите текущее состояние письменно: что сделано, что в работе, что не начиналось, какие решения ждут вашей стороны.
3. Сверьте с тем, что видите сами по семи признакам выше.
4. Проведите разговор без юристов. Большинство буксующих проектов лечится сменой режима работы, а не сменой подрядчика: назначенный владелец процесса и еженедельный показ на реальных данных вытаскивают проект в половине случаев.
5. Если картина не сходится — берите второе мнение. Дальше про то, как оно устроено.

Как устроен аудит внедрения

Экспресс-разбор занимает неделю и стоит 180 000 – 350 000 ₽. Внутри: чтение проектных документов, разговоры с обеими сторонами по отдельности, осмотр системы и конфигурации, оценка реального состояния против заявленного. На выходе — заключение, где написано, что происходит, сколько стоит доведение до конца и какие есть варианты.

Полный аудит — 350 000 – 700 000 ₽ и две-три недели: сюда добавляется разбор качества доработок, схемы данных и архитектуры обменов. Отдельно существует техаудит производительности за 250 000 – 500 000 ₽, если основная жалоба звучит как «все тормозит».

Важная часть, которую стоит проговорить заранее: аудит регулярно заканчивается выводом, что подрядчик работает нормально, а причина стоящего проекта на стороне заказчика — нет владельца, нет решений, нет людей на данные. Без готовности услышать такой ответ второе мнение покупать бессмысленно.

Когда аудит не нужен

Проект идет меньше двух месяцев. На старте всегда выглядит хаотично. Дайте команде закрыть первый этап.

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

Проблема названа и признана обеими сторонами. Если все и так знают, что месяц ждали решения по складским процессам, платить за подтверждение этого не надо. Надо принять решение.

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

Чек-лист на семь проверок

1. ТЗ прочитано тем, кто будет работать в системе.
2. Показ на реальных данных был за последние четыре недели.
3. Три сотрудника подрядчика описывают состояние проекта одинаково.
4. Доля оплаченного соответствует доле работающего.
5. Известно, снята ли конфигурация с поддержки.
6. По справочникам есть план и ответственный.
7. Ключевые роли в команде подрядчика не менялись дважды.

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

И последнее, о чем стоит помнить, перебирая признаки. Провал внедрения почти никогда не имеет одной причины и одного виновника. Обычно это цепочка: продали срок, который нельзя выдержать, приняли ТЗ, которое никто не читал, не назначили владельца процесса, отложили работу с данными. Каждое звено по отдельности выглядит мелочью, вместе они дают проект, который идет второй год.

Хорошая новость в том, что цепочка рвется в любом месте. Назначенный владелец с полномочиями, показ на реальных данных каждые две недели и письменная фиксация решений вытаскивают большинство буксующих проектов без смены подрядчика и без судов. Это дешевле любого другого сценария и почти всегда быстрее.