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