К моменту прихода Ли Якокки (легенда менеджмента производства авто, создатель Форд Мустанг) Крайслер находилась на грани банкротства. Чтобы не потерять бизнес Якока закрывал убыточные заводы, продавал непрофильные активы, изменил отношения с поставщиками, сконцентрировал все усилия на создании новой линейки автомобилей - K-Car и другие. Принятые меры позволили оживить бренд, погасить долги и начать рост бизнеса.
По сути неудачный ERP - проект, сродни обанкротившемуся бизнесу. Если посмотреть общепринятую в экспертной среде оценку успешности внедрения ERP систем в России, то ситуация выглядит следующим образом:
Полностью успешные проекты (в срок, в бюджет, с полным функционалом): менее 20-30%.
Проекты, завершенные с компромиссом (превышен бюджет и/или сроки, урезан функционал): 40-50%.
Проблемные или провальные проекты (остановлены, не используются, привели к серьезным убыткам): около 20-30%.
Более 10 лет занимаюсь внедрением сложных проектов ERP. Решил поделиться своим мнением и сделать ряд небольших статей, как не попасть в последнюю группу и минимизировать компромисс во второй группе (в том числе, как “довести важные детали до сознания” ТОПов. Рассчитываю на широкий круг читателей: бизнес-аналитиков, ИТ-специалистов, т.к. в большинстве корпораций в том или ином виде внедряются ERP – системы, но в первую очередь материал будет полезен руководителям проектов.
Дисклеймер. В контексте статей под «проектом» будет пониматься:
- деятельность по внедрению изменений, которые влияют на значительное число сотрудников организации;
- команда проекта состоит из кроссфункциональных специалистов: бизнес, методологи, ИТ-специалисты, пользователи общим числом в диапазоне 30 – 70 человек;
- есть объективный deadline (внешние по отношению к проекту обстоятельства, которые определяют одну или несколько ключевых вех проекта).
Постройка моста
Начну с определения объема начальной фазы (волны) проекта (объем важен и в контексте всего проекта, но в отношении начальной фазы это в разы труднее).
Основная дилемма в том, что с одной стороны, внедрение ERP- системы предполагает внедрение связанных едиными аналитическими разрезами, данными и контролями бизнес-процессы. С другой стороны, чем больше блоков втиснуто в начальную фазу, тем выше риск неуспеха проекта.
Как правило команда внедрения и Заказчик оценивают реализацию функциональной части (сразу планируют строить «дом»), планируя «перешагнуть» из текущего состояния в активную функциональную фазу за «пару недель» после старта (рис 1а). Сложность начальной фазы в том, что между стартом и продуктивной работой по внедрению бизнес-процессов, которую ждет заказчик, лежит «пропасть». Её (пропасть) - не «перешагнуть» и не «перепрыгнуть» (рис 1б).
Ниже типичный список задач, которые обычно недооценивают, но они отнимут существенную часть ресурсов команды:
организация коммуникаций внутри команды\рабочей группы
обеспечение проекта необходимыми ресурсами
организация процесса поставки результата
организация доступов\рабочих сред тестирования\разработки\продуктива
организация инфраструктуры (сервера, бэкапы, сетевое взаимодействие и т.д.)
организация поддержки пользователей
Выше обозначен внушительный список задач (рюкзак с образа на рис 1а, которые сильно усложняет задачу перепрыгнуть), при этом, пока нет ни одной задачи, ради которой, собственно, затевался проект! Это пропасть, которая отделяет команду проекта от начала «постройки» ЕРП (рис 1б)
Поэтому очень важно на этом этапе минимизировать функциональный объем, чтобы выделить ресурс на «постройку моста» (рис 3), но при этом обязательно должна быть реальная бизнес польза от фазы (MVP). Важно учитывать, что функциональный объем будет влиять на все аспекты проекта: организационную структуру, коммуникации, риски.
По моему опыту для внедрения большинства бизнес-процессов может потребоваться несколько волн с общей длительностью 1- 3 года. Попытка все приурочить к одному «большому запуску» приводит к невозможности «переварить» такой объем -> переработкам и стрессу - > выгоранию-> снижению продуктивности? поиску дополнительных ресурсов, что еще больше усложняет проект и отодвигает сроки его реализации. В итоге за те же сроки внедряется сильно меньший объем за больший бюджет\ресурсы.
Место руководителя проекта в организационной структуре проекта
Управляющая вертикаль проекта -- второй важный фактор, влияющий на результат. С одной стороны, ERP внедряются в основном в вертикально интегрированных организациях, т.е. сложившейся иерархией принятия решений. С другой стороны, полностью продублировать организационную структуру в проекте не получается, поэтому в проекте создается новая структура управления, с использованием матричного принципа (подчинение сотрудников разных департаментов\отделов другому руководителю).
Указанное противоречие приводит к созданию расширенной управленческой команды, чтобы формально включить в проект ТОП-руководителей всех департаментов, сотрудники которых участвуют в проекте, при этом могут образовываться параллельные «вертикали» управления проектом: Кураторы от спонсора, проектный офис т.п. Такой подход приводит к затягиванию сроков принятия решений и снижению их качества. Поясню, сроки затягиваются из-за большого числа согласовантов, качество решений снижается из-за искажения информации при передачи (см. рис 3) и поиска компромисса между различными стейкхолдерами, у которых разная степень ответственности за успех проекта. В таких условиях важно выделить и наделить полномочиями управленческую вертикаль проекта, которая действительно несет ответственность за результат проекта.
Ярким примером таких проблем в мировом масштабе может служить Apple c 1985 по 1997 г., компания потеряла существенную долю рынка (с 16% до 3%) и была на грани банкротства. Основная причина: отсутствие четкой стратегии и избыточная бюрократия (15+ уровней согласования на продукт). В этот момент вернули Джобса, который существенно сократил число продуктов и все важные решения замкнул на себя.
Чем меньше звеньев в этой цепи, тем быстрее реакция меньше искажение информации.
Оптимальная вертикаль управления, представлена на рисунке 4, когда структура управления проектом совпадает с реальной организационной структурой организации в рамках автоматизируемой Бизнес-единицы: CEO – спонсор, CEO-1 – Заказчик, CEO-2 – Руководитель проекта (далее - РП), и Заказчик или РП выполняют роль Директора проекта. Отмечу, что ключевое отличие Директора проекта от РП в том, что директор управляет проектом и отвечает за его результат, РП – отвечает за организацию работ и координацию участников проекта. В таком случае информация ходит максимально быстро и без искажений.
Часто бывает, что роль Директора проекта выполняет отдельный сотрудник (рис 5). Такая конструкция может быть действенной, если соблюдается 2 фактора: у Директора проекта выделено время на погружение в контекст проекта и есть опыт внедрения ERP. Но даже в этом случае возможна задержка в решениях\информации, т.к. в бизнес- решения принимает Заказчик, тот кто отвечает за автоматизируемый бизнес-процесс. (Например, только Финансовый директор может принять решение списать всю дебиторскую задолженность менее Х руб., чтобы не тратить ресурсы проекта на ввод таких остатков). При эскалациях запрос на решение должен идти на один уровень выше, т.е. от РП – Директору проекта, а от него на Заказчика и в обратном направлении.
Таким образом каждое дополнительное звено управления удлиняет и искажает цепочку принятия решения, что повышает риски попасть в 3-ю категорию (провальных) проектов.
Как правило, выбор руководителя проекта происходит по взаимному согласию. Именно на этом этапе необходимо обсудить с Заказчиком\Спонсором проекта цели проекта, деление целей на фазы, организационную структуру, связанные бизнес ограничения и ожидания.
Если договорится не удается и вы уверены в том, что объем сильно завышен, лучше отказаться от лидерства такого проекта.
Резюме
На начальной стадии проекта необходимо реализовать MVP (специально выделяю Minimum) и заложить ресурсы на инфраструктуру и создание команды. Должна быть вертикаль управления проектом с минимальным количеством участников, которые несут реальную ответственность за результат проекта.