Российский project management: разница в подходах Дмитрий Иванов, cio-world.ru
01.03.2010
Опубликовано 01.03.2010
Солопов Павел
Дмитрий Иванов,
заместитель руководителя SAP-департамента компании «НОРБИТ»
Иногда приходится слышать, что проекты в России реализуются вопреки всему. Мнение такое возникло не на пустом месте, однако я бы не стал сводить все к пресловутой «российской специфике». По оценкам Standish Group, касающимся именно мирового опыта, в 2000 году менее 1/3 ИТ-проектов можно было признать успешными, а 23% проектов провалились, т.е. не были вообще доведены до конца. По результатам исследования Robbins-Gioia, проведенного в 2001 г. в США, из заказчиков, внедрявших ERP-системы, 51% признали внедрения неуспешными. Причем даже у тех заказчиков, которые использовали систему управления проектами, 36% внедрений оказались неуспешными.
В более ранних западных исследованиях на ту же тему доля неуспешных внедрений, особенно в части ERP-систем, как правило, еще выше. И несмотря на тенденцию к росту доли успешных проектов на западе за последние 10 лет ситуация не улучшилась кардинально. Так что проблемы с управлением проектами – не только российская, но и общемировая беда. Особенно это касается сложных и длительных ИТ-проектов, таких как внедрение ERP-систем.
Можно с достаточной уверенностью утверждать, что в каждом российском проекте внедрения ERP встречаются те или иные ошибки, связанные с управлением проектами. Есть и проекты, которые являются настоящим кладезем таких ошибок.
Не берусь судить о зарубежном опыте, касающемся ведения проектов западными компаниями для клиентов, находящихся за рубежом. Но можно попробовать сформулировать ключевые различия подходов к реализации проектов, возникающие на территории России. Сравним «российскую» практику, когда российская консалтинговая компания проводит проект внедрения ERP-системы для российской же компании-заказчика и «зарубежную», когда проект внедрения осуществляется российским представительством крупной международной консалтинговой группы и выявим ряд различий:
- Подход к оценке проекта. Западные компании уделяют большее внимание оценкам проекта, в первую очередь, оценке рисков, применяя для этого формализованные методики, в том числе количественные методики оценки рисков и сложности проекта. Российские компании выполняют оценки преимущественно экспертным методом. К тому же российские компании по сравнению с крупными международными имеют меньшую базу выполненных аналогичных проектов, которые могли бы использоваться как база для оценки. Но это следствие не «российской специфики», а меньших размеров компании и меньшей продолжительности работы на рынке внедрения ERP-систем по сравнению с такими международными гигантами как IBM, Accenture, Bearing Point, SAP Consulting и т.п. Неточные оценки проекта со стороны подрядчика очень часто ведут к неправильным шагам в организации управления проектами. Кроме того, имеет место и практика сознательного занижения перед заказчиком оценки стоимости, сроков и рисков проекта с целью продать проект/выиграть тендер у конкурентов и т.п.
- Подход к условиям контракта. Западные компании, как правило, осторожнее и внимательнее подходят к условиям контракта с заказчиком, а также активнее отстаивают менее рискованные для себя условия. В частности, принята практика, когда для высокорискованных проектов иностранные консалтинговые компании используют подход Time&Materials. Вызвано это и более качественной оценкой рисков, и наличием развитой юридической экспертизой, и масштабами крупных западных компаний, которые благоприятствуют продавливанию собственных типовых контрактов, включающих весьма жесткие требования к участию в проекте заказчика. Западные компании стараются неукоснительно соблюдать такие правила, как максимально четко оговаривать функциональный объем проекта в контракте, а также включать в состав контракта документ, четко регламентирующий организацию проекта и процедуры управления (устав проекта или определение проекта).
- Квалификация руководителей проектов. Как правило, западные компании уделяют больше внимания уровню квалификации руководителей проектов, причем для них более характерно понимание, что руководитель проекта должен быть в первую очередь специалистом в управлении проектами, и лишь во вторую – специалистом по внедряемой системе. В крупных проектах западные компании не практикуют для руководителя проекта совмещение собственно управления проектом и работы архитектора либо функционального консультанта, в российских – это весьма распространенная практика. Т.е. западные компании в большей мере понимают важность роли руководителя проекта в успешности данного проекта.
- Внимание к начальным фазам проекта. Западные компании менее подвержены подходу «главное – ввязаться в проект, а там на ходу разберемся». Практика показывает, что основные причины, ведущие к проблемам на проекте или даже к его остановке, закладываются уже на этапе продажи проекта либо на его начальных стадиях. Западные компании более тщательно и педантично относятся к организационным работам начальной фазы проекта, в то время как многие российские пытаются эти работы минимизировать, рассчитывая в результате сделать заказчику более выгодное по стоимости и срокам предложение.
- Управление изменениями. Как правило, западным консалтинговым компаниям удается лучше наладить процедуры управления изменениями на своих проектах, что благоприятно сказывается на соблюдении сроков и бюджетов проекта. Вероятность того, что проект увязнет в реализации многочисленных и порой противоречивых «хотелок» заказчика, в этом случае снижается.
- Формальные и неформальные коммуникации в проекте. По моим наблюдениям, российские компании, реализующие проекты внедрения ERP для российских заказчиков, более склонны выстраивать схему коммуникаций внутри проекта с помощью неформальных коммуникаций, т.е. фактически – в обход процедур устава проекта. Пока проект идет хорошо, широкое использование неформальных коммуникаций является скорее плюсом, но при первых же затруднениях такая схема приводит к разногласиям и конфликтам между заказчиком и исполнителем.
Различия эти вовсе не всегда явные, поскольку российские консалтинговые компании в своем развитии не стоят на месте, перенимая передовые практики и приглашая на работу специалистов с «западным» опытом. Со своей стороны и западные консалтинговые компании, работающие в России, комплектуют свой штат преимущественно за счет российских специалистов и в ряде случаев принимают «правила игры», диктуемые российскими заказчиками.
При этом Практически все методологии и стандарты управления проектами внедрения ERP-систем, с которыми мне приходилось сталкиваться на практике, являются в том или ином роде производными от PMBOK. ITIL используется чаще всего в части ITSM (Управление предоставлением ИТ-сервисом) при определении стандартов сопровождения эксплуатации ERP-систем. Применение стандартов ITIL способно ускорить развитие рынка аутсорсинга услуг по сопровождению эксплуатации информационных систем.
И ITIL, и PMBOK, и всякие прочие такого рода стандарты являются фактически сборниками рекомендаций и «лучших практик». Как прямо указано во введении к Руководству PMBOK, “Хорошая практика не означает, что описываемые знания должны всегда одинаковым образом применяться во всех проектах; возможность их применения для каждого конкретного проекта определяется командой управления проектом”. Соответственно, для того чтобы лучшие практики были применимы и полезны в конкретном проекте независимо от страны, где данный проект реализуется, необходимо соблюдение следующих условий:
- должны использоваться только те практики, затраты на использование которых будут оправданы, т.е. будут меньше затрат, которые могут возникнуть при пренебрежении данными лучшими практиками;
- должны использоваться только те практики, которые реально будут исполняться в ходе проекта как со стороны подрядчика, так и со стороны заказчика.
В российской практике идея стандартизации проектных этапов давно воплощена. ГОСТ 34, принятый еще 20 лет назад, содержит описания всех стадий создания информационных систем и требования к данным стадиям, включая требования к проектной документации и основные положения методологии выполнения проекта.
Состав проектных этапов, определяемый ГОСТ 34, предназначен в первую очередь для проектов по созданию ИС «с нуля». Для проектов внедрения ERP-систем на уже существующей платформе состав этапов и требования ГОСТ 34 представляются уже избыточными, но могут применяться выборочно.
Для проектов по внедрению ERP-систем SAP существуют специальные методологии ASAP и ASAP Focus (методология ускоренного внедрения преднастроенных решений SAP Business All-in-One), адаптированные под специфику внедрения ERP-систем на готовой платформе и широко применяемые на практике, в т.ч. в России.
В нашей практике государственные заказчики, а также ряд крупных промышленных заказчиков, «выросших» из крупных государственных предприятий, в части содержания этапов, состава проектной документации, требований к документации, базировались на требованиях ГОСТ 34. Проекты же с прочими заказчиками основываются на ASAP и, в меньшей мере, на ASAP Focus.
Сравнивать ASAP и ГОСТ 34 по принципу «что лучше», считаю, стоит в каждом конкретном случае для каждого конкретного заказчика. При этом следует учитывать следующие факторы:
- наличие у заказчика опыта реализации проектов по тому или иному стандарту, наличие специалистов по управлению проектами, владеющих соответственно ГОСТ 34 или ASAP (этот фактор, пожалуй, важнейший, т.к. взаимопонимание заказчика и подрядчика в части ожиданий и требований является важнейшим фактором успешности проектов внедрения ERP-систем в России в настоящее время);
- требования заказчика к промежуточным результатам проекта;
- требования заказчика к срокам проекта (сжатые сроки, желаемые заказчиком, являются серьезным препятствием для реализации ряда предусмотренных ГОСТ 34 этапов);
- уровень ИТ-экспертизы заказчика.
В таких сложных проектах, как проекты внедрения ERP-систем, роль заказчика всегда значительна, и можно утверждать, что ответственность за результат проекта лежит на заказчике ничуть не меньше, чем на подрядчиках. А на рынке средних и мелких заказчиков, где существует тенденция к увеличению внедрений на основе всякого рода «коробочных», преднастроенных решений, «лучших практик» и т.п., роль и ответственность заказчика дополнительно возрастают. Фактически, участие заказчика в проекте внедрения ERP-системы начинает играть бОльшую роль в успехе проекта, чем участие подрядчиков.
Поэтому заказчик просто должен быть способен оценивать эффективность управления проектами и обязан принимать активнейшее участие в построении системы управления проектами совместно с подрядчиками. Попытки переложить управление проектом и ответственность целиком на подрядчика обходятся заказчикам дорого – в лучшем случае это срыв сроков и значительные дополнительные затраты, в худшем – провал проекта. Я не видел успешных для заказчика проектов, где заказчик перекладывал управление проектом целиком на подрядчика. А вот для подрядчика проекты такого рода могут быть и «успешными»: в ряде случаев заказчик, лишенный реальных рычагов управления эффективностью проекта, превращается в «испытательный полигон» и «дойную корову» для подрядчика.
В заключении приведу примеры наиболее типичных ошибок в области управления проектами, с которыми приходилось встречаться в своей практике:
- Ошибочные оценки проекта.
- Заключение договора с заказчиком на условиях фиксированной стоимости при недостаточно четком ограничении функционального объема проекта и областей вне рамок проекта.
- Привязка функционального объема проекта к техническим требованиям заказчика, выраженным исключительно в терминах бизнеса.
- Плохо организованное взаимодействие с субподрядчиками.
- Отсутствие реального спонсора проекта, недостаточная поддержка проекта высшим руководством заказчика.
- Отсутствие выделенного в проект на 100% руководителя проекта.
- Недостаточные полномочия руководителя проекта.
- Низкое вовлечение в проект ключевых бизнес-пользователей со стороны заказчика.
- Низкая мотивация проектной команды на успех проекта, соблюдение сроков и бюджета (в большей степени относится к команде заказчика).
- Неспособность заказчика выполнять свою часть работ в проекте.
- Недостаток квалифицированного персонала в проекте, в первую очередь – со стороны заказчика.
- Неработающие процедуры управления рисками и изменениями.
- Неготовность команды заказчика самостоятельно поддерживать систему, и как следствие – незаинтересованность команды заказчика в скорейшем продуктивном старте, т.е. соблюдении сроков проекта.
- Неспособность подрядчика определять ожидания заказчика и управлять ими.
- Незапланированный уход ключевых участников проекта как со стороны заказчика, так и со стороны подрядчика.
- Начало последующей фазы проекта до завершения предыдущей фазы.
- Отказ от формальных процедур управления проектом в пользу неформальных коммуникаций.
- Ошибочное предположения, что новые продукты будут успешно работать в новой среде.
Статья опубликована на CIO
Все права сохранены
Возврат к списку