2 июня 2014 г.
Когда в товарищах согласья нет,На лад их дело не пойдет,
И выйдет из него не дело, только мука.
(И.А. Крылов)
Продолжаем анализировать причины затягивания сроков при реализации крупных ERP-проектов. В статьях «По щучьему велению, или Как сократить сроки внедренческих проектов» и «Внешние факторы. Ошибки вида “замахнуться на неподъемное”» были рассмотрены такие отрицательно влияющие на проект факторы, как недостаток коммуникации между участниками проекта, а также постоянно меняющиеся внешние условия.
Однако в жизни гораздо больше факторов, которые могут существенным образом изменить первоначальные планы и сроки реализации ИТ-проектов. Сам по себе проект подразумевает набор усилий проектной команды для достижения определенного результата. В теории, если в проектной команде два человека, то они всегда (или почти всегда) смогут договориться и им руководство не нужно. Но крупный ИТ-проект, к сожалению, столь малыми ресурсами не выполнить. Как только число участников проектов увеличивается, без менеджеров уже практически не обойтись. Поговорим о структурах управления проектами.
Если взглянуть на рынок внедрений ERP-систем в начале 2000-х, то становится очевидным, что многие крупные компании словно копировали друг у друга подход к автоматизации. Его в последнее время так и называют «колодезным», по аналогии с набором колодцев.
Чем характеризуется такая аналогия? Колодцы самодостаточны, равно как и внедряемые на тот момент системы. Бухгалтерия, техническое обслуживание и ремонты, имущественный учет и т.д. Почему делали именно так? Вы можете ответить: «Надо же с чего-то начинать. Если взяться за все разом, уйдет много времени. Проект рискует устареть еще до начала реализации». Хорошо, принимается. Но только ли дело в желании ограничить «необъятное»?
Заказчики. «Колодезный» подход позволял минимизировать «главных» заказчиков. При автоматизации четких отдельных бизнес-процессов всегда можно было «вычленить» ответственного. В бухгалтерии ответственный главный бухгалтер, в производстве - главный инженер… Есть конкретный человек, уполномоченный принимать решение о том, «как надо сделать». Он представляет и олицетворяет, с одной стороны, подчиненную функциональную область, а, с другой, определяет «успешность» проекта.
Но время идет, и эпоха внедрения базовых процессов ведения хозяйственной деятельности подходит к концу. Практически все операции как основных, так и вспомогательных направлений уже автоматизированы. Но при этом имеется значительный потенциал повышения общей эффективности процессов за счет организации взаимодействия подразделений. В связи с этим сейчас востребованы решения, направленные на оптимизацию комплексных бизнес-процессов, охватывающих деятельность сразу несколько крупных подразделений.
Например, автоматизация учета рабочего времени сотрудников, занятых на производстве. Тут возникает несколько ответственных: и HR, и главный инженер, и бухгалтер, и финансист. Сказать, кто однозначно «главный», не получится. Так как речь идет об учете рабочего времени, то нужно взаимодействие с HR. В то же время уточнение и разнесение временных затрат по «направлениям» - задача производства.
Как раз на «стыках» и возникают конфликты и споры, которые усложняют ведение проекта, увеличивая сроки его реализации.
Как, например, в данном случае вести учет рабочего времени при фактической частичной загрузке персонала?
«Работник или работает или нет (болеет, в отпуске и т.д.), поэтому нужно вести учет по восемь часов в день минус отсутствие», – утверждает HR.
«То, что он где-то «прохлаждается» – не моя забота. Мне важно, сколько он на вверенном направлении отработал по факту. Поэтому если он отработал четыре часа в день, пусть так и фиксируется2, - спорит производственник.
Каждый прав по-своему. И никто, как правило, не хочет идти на уступки. Пока будут спорить, много воды утечет (т.е. времени). При этом всегда сохраняется риск, что ожидаемого консенсуса стороны так и не достигнут.
Что же делать? Если уже «случилось», то нужно предлагать варианты, мирить стороны между собой. То есть выводить проект в позитивное русло. Но «болезнь легче предупредить, чем лечить»… Как предотвратить такую ситуацию? Если «замыкать» все вопросы на генеральном директоре, то у него элементарно не хватит на все времени. Конечно, можно волевым решением назначить кого-то главным, но каким образом, к примеру, производство будет принимать решение за бухгалтерию? Получаются все те же «семь нянек».
Какие же меры предпринять? Во-первых, стоит со всей ответственностью отнестись к обычно небольшому по длительности первому этапу проекта (как правило, он называется «инициация», «запуск проекта» и т.п.). Обычно в рамках данного этапа разрабатывается и утверждается Устав, содержащий описание основных участников проекта, их сферы ответственности, порядок эскалации вопросов и споров. Стоит отнестись к этому серьезно. Заказчику со своей стороны логично делегировать полноту власти (в том числе, ответственность и за сроки проекта, и за бюджет, и за результаты) на проекте одному ответственному лицу.
Во-вторых, перед запуском проекта заказчику нужно самому себе честно ответить на вопросы типа:
- все ли методологические вопросы уже решены?
- не нужно ли включить в проект не только консультантов, которые настроят ИТ-систему, но и тех, кто осуществит методологическую поддержку всего процесса для сглаживания «острых углов»? При этом нужно понимать, что методология – процесс и длительный (надо помирить между собой несколько функциональных направлений), и дорогостоящий (потому как эффективно работает один подход – исполнителю предложить как, а заказчику подумать, устраивает ли такое решение и дать замечания).
Общий совет всем сторонам проекта – всегда ищите компромисс. Плохой мир во всех случаях лучше хорошей войны.
Источник: Андрей Шоханов, советник руководителя дирекции по работе с предприятиями нефтяной и энергетической отрасли, ЗАО «ЛАНИТ»
