Управление ERP-проектами: PMBOK или ГОСТ?

Введение

Причина, по которой я решил написать эту статью, следующая: в последнее время в ходе различных обсуждений проблем управления проектами, как вживую, так и в интернете, я часто сталкиваюсь со скептическими оценками методологии PMI (Project Management Institute, USA). Например, от коллег, получивших опыт работы в советских проектных институтах, слышу следующее мнение: «Все это уже давно описано ГОСТами, все это известно с давних пор, мы управляли проектами без всяких PMI…». Или такое мнение «PMI не учитывает специфику (государства, отрасли, менталитета и тому подобное)». Я с этим не согласен. В моей практике использование инструментария, описанного в PMBOK, дало неплохой результат. Как в части управляемости проектов, так и в части результативности.

Я не буду пытаться в этой статье подробно анализировать PMBOK. Просто я предлагаю вашему вниманию свое видение использования методологии управления проектами, описанной в PMBOK (PMI-стандарт). Надеюсь, кому-то это будет интересно и полезно, у кого-то возникнет желание поспорить. Главная задача этой статьи ― инициировать дискуссию между профессионалами в области проектного менеджмента, в процессе которой можно будет обменяться знаниями, полученными опытным путем в сфере управления проектами.

Применение стандартов и методологий управления проектами я буду рассматривать применительно к проектам создания ERP-систем на предприятиях, то есть в знакомой мне сфере.

Методология управления проектом: ГОСТ и PMBOK

PMBOK

На мой взгляд, PMBOK представляет собой что-то вроде ящика с инструментами (области знаний) с инструкцией по их применению, и также инструкцию по применению всего комплекта инструментов (процессы). Как и любой набор, он несколько избыточен, при этом часть инструментов хотелось бы усилить. Но с его помощью можно управлять проектами. Главное достоинство PMBOK состоит в том, что в нем все процедуры управления проектом показаны в динамике, прослеживается связь между компонентами методологии, процессы разложены по времени.

Недостаток ― это далеко не инструкция и не технологические карты, и просто так взять и применять по очереди главы PMBOK невозможно. Особенно без опыта управления проектами. Что опять же подтверждает аналогию с набором инструментов.

Государственные стандарты РФ (ГОСТ)

Под воздействием мнений коллег, являющихся любителями ГОСТов, я еще раз просмотрел эти документы.

Я изучил следующие стандарты:

ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению»;

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;

ИСО 10006 «Руководящие указания по обеспечению качества руководства проектами»;

Мой вывод: в основном в этих документах представлены требования к форме и содержанию проектных документов, к составу и последовательности проектных работ. В силу того, что почти все эти документы разработаны до 1990 года (во времена «исторического материализма»), кроме ИСО 10006, применение их требует некоторой адаптации. В общем, если продолжать аналогию с инструментами ― это набор измерительных приборов. Без них нельзя, но инструменты они не заменят. Связь между процессами, способы достижения проектных результатов, методики в ГОСТы не вошли.

Особняком стоит сравнительно новый ИСО 10006. Это методология, которую можно пытаться применять для управления проектами. Но, на мой взгляд, документ менее стройный, чем PMBOK. Процессы переплетены с областями знаний, связь между процессами не всегда четко прослеживается, многие требования носят общий характер. Например: «Чтобы обеспечить запланированные связи между процессами разработки проекта, должно быть организовано управляемое взаимодействие между разработчиками проекта. Управление взаимодействием должно обеспечиваться разработанными документированными процедурами, проведением совместных совещаний разработчиков различных разделов проекта, решением противоречий, вызванных неисполнением разработчиками обязательств друг перед другом или проблем, возникших при изменениях проекта, использованием анализа выполненных работ по проекту с оценкой развития и степени риска с тем, чтобы в итоге дать общую оценку состояния выполнения проекта и наметить план оставшейся работы по проектированию (см. приложение В). Промежуточные оценки проекта должны также определить возможные потенциальные проблемы взаимодействия. Следует отметить, что должно быть уделено особое внимание взаимодействию и координированию действий при проектировании процессов, заключающих в себе большую степень риска». (Раздел 5.3.2. «Управление взаимодействием»).

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

Чем пользоваться?

Для себя я решил, что моя «настольная книга» по управлению проектами ― это PMBOK. И в случае возникновения вопросов, на которые нет ответа в корпоративных методиках управления проектами или в методиках вендоров (об этих методиках чуть ниже), я всегда заглядываю в PMBOK. Ну а ГОСТы я использую для уточнения проверки содержания проектных документов. Хотя в основном Заказчики ERP-проектов склоняются к использованию методологий управления проектами от вендоров (под давлением этих же вендоров).

Так что не «PMBOK или ГОСТы», а «PMBOK и ГОСТы», и PMBOK на первом месте. Повторю, это мое мнение.

Применение PMBOK для ИТ-проектов

Особенности ERP-проектов

Не буду претендовать на полный анализ особенностей ERP-проектов. Об этом много написано. Хочу только отметить, что такие проекты обычно являются высокорисковыми, вероятность изменений параметров таких проектов высокая, технологии реализации таких проектов еще сыроваты (в силу «молодости» ERP-систем, например, по сравнению со строительством).

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

Методологии вендоров: ASAP, AIM и другие

Для реализации проектов создания ERP-систем ведущие производители соответствующего программного обеспечения (вендоры) создали свои методологии. Кратко рассмотрим их на примерах крупнейших вендоров ― SAP и Oracle.

Oracle в обязательном порядке в своих проектах использует методологию управления проектами Project Management Method (PJM) и технологическую методологию развертывания программных приложений Application Implementation Method (AIM). Обе методологии хорошо интегрированы, подробно описаны все действия и документы, четко указаны фазы проекта, связи между действиями, событиями и документами. При этом PJM практически полностью соответствует методологиям управления проектами PMI. На мой взгляд, Oracle создал одну из лучших методологий реализации проектов создания ERP-систем.

Похожая история и в SAP. Методология Accelerated SAP (ASAP) также дает полное описание необходимых действий и документов, сочетая в себе технологическую и управленческую части, при этом управленческая часть ― практически один в один PMBOK, что представители SAP и не скрывают. ASAP недавно трансформировался в решение Solution Manager (SM), сочетающее в себе методологию и программный инструментарий. Но суть от этого не изменилась. Правда, в реальных проектах SM пока мало используется. Мне тоже не довелось его применить на практике.

У остальных вендоров ситуация похожая. И в основном в методологию внедрения закладываются принципы методологии управления проектами PMI. Отличаются методологии степенью проработки. И чем надежнее система, чем проще ее внедрять ― тем менее проработанная методология внедрения этой системы.

Минус подобных технологий ― естественная избыточность предлагаемых документов. Для себя всегда нужно выбрать необходимый минимум документов и разрабатывать только их. Так же методологии вендоров, в отличие от стандартов PMI, не соответствуют или частично соответствуют нашим ГОСТам. И так как, с одной стороны, использование методологий внедрения вендоров необходимо при внедрении их систем, а с другой стороны, если Заказчик требует ведения проекта по ГОСТу, эти методологии не обеспечивают необходимые документы и действия, приходится добавлять методологии вендоров своими приложениями.

Поэтому многие компании, специализирующиеся на реализации проектов создания ERP-систем, создают свои методологии внедрения таких систем. Но, по моему опыту, в основу таких методологий берутся методологии вендора, стандарты PMI, к которым добавляется описание отечественных специфик и требований ГОСТов (последнее не всегда). Например, пресловутая опытная эксплуатация ERP-системы, отсутствующая в методологии вендоров, но обязательная с точки зрения ГОСТов и обычно входящая как этап (фаза) в большинство отечественных ERP-проектов.

Что же можно взять из PMBOK?

Что же точно нужно использовать из арсенала PMBOK? И при этом не тратить много времени на ненужные процессы и документы.

На мой взгляд, в проектах создания ERP-систем, в силу их специфики, обязательно применение следующих областей знаний, описанных в PMBOK:

· Управление интеграцией проекта (обязательно нужно разработать стартовый комплект документов проекта, а именно: устав проекта, предварительное описание содержания проекта, план управления проектом);

· Управление содержанием проекта (обязательно нужно создать иерархическую структуру работ (ИСР) проекта);

· Управление сроками проекта (весь раздел крайне полезен);

· Управление стоимость проекта (полезен метод освоенного объема);

· Управление человеческими ресурсами проекта (полезны диаграмма потребности в ресурсах и матрица ответственности);

· Управление коммуникациями проекта (полезен план управления коммуникациями);

· Управление рисками проекта (весь раздел крайне полезен).

Что касается оставшихся областей знаний, то «Управление качеством проекта» обычно используется специализированное. В PMBOK ― в основном общие рекомендации. А «Управление поставками проекта» ― практически в ERP-проектах не используется.

Конечно, эти инструменты нужно применять правильно, помня о цикле «plan-do-check-act», используя свой опыт, сверяясь с требованиями Заказчика и так далее. Но стартовать, опираясь на PMBOK ― можно.

Конечно, хорошо, если корпоративная методология управления проектами вобрала в себя все лучшее из PMBOK, методологий вендоров и ГОСТов. Но это не всегда так. Поэтому периодически нужно обращаться «к истокам». И первый из них ― PMBOK.

ERP-проекты: применяем PMBOK. А как в других отраслях?

Применение PMBOK является практически обязательным в ERP-проектах. По моим наблюдениям, методологию управления проектами PMI использует большинство моих коллег. Распространение этой методологии серьезно повышает значимость сертификата PMP, как доказательства того, что сертифицированный специалист знает PMBOK. Казалось все очевидно ― но я встречал и другие мнения.

Поэтому мне интересно, как используют стандарты PMI менеджеры проектом в других отраслях. И используют ли? Что могут сказать противники стандартов PMI?

Надеюсь, в дискуссии мы сможем это обсудить.

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
CIO, Санкт-Петербург

автор по забывчивости (не хочется верить, что по незнанию) не упомянул НТК Совнет, да и другие известные документы.PMBoK - это не методология.В общем, очень слабо, похоже на обзор журналиста-универсала.

Юрий Максименко Юрий Максименко CIO, Украина

Много лет разрабатываю на заказ (и одну на продажу) программы, которые подходят под определение [B]Система планирования ресурсов предприятия[/B]. То бишь ERP. И всегда одно и то же: [B]сценарий меняется по ходу пьесы[/B]. Заказчик вдруг осознаёт, что он на самом деле хочет не совсем того, что заказал. У меня за много лет сложилось ощущение, что иначе быть не может. Терзался сомнениями, пока не вычитал у Фредерика Брукса:[I]«Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумываются над задачей настолько детально, как это нужно указать в спецификации...Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют» [/I](Фредерик Брукс «Мифический человеко-месяц, или как создаются программные системы», глава 16). Поэтому жду от стандарта учёта этого факта. Укажите мне такой стандарт -- я с радостью на него перейду. А то что я в самом деле...Но если стандарт считает, что получится с первого раза -- это, на мой взгляд, провал планирования. А ведь [B]fail to plan = plan to fail[/B].

Менеджер, Москва
Автор ссылается на AIM
Oracle в обязательном порядке в своих проектах использует методологию управления проектами Project Management Method (PJM) и технологическую методологию развертывания программных приложений Application Implementation Method (AIM).
В этой методологии описаны шаги и требования к документам которые надо заполнять на каждом из шагов. ГОСТы рассматриваю как дополнительный набор требований к документам, и возможно дополнительные шаги.При этом для внутренних нужд логично использовать документы в стиле PMBook, а для внешних - в стиле ГОСТ.Чем-то похоже на финансовую отчетность и бухгалтерскую. Финансовая нужна для понимания что происходит в компании, а бухгалтерская для обязательной отчетности. Понятно что они связаны, но это конечно же не одно и то же.
Партнер, Москва
Юрий Максименко пишет:Поэтому жду от стандарта учёта этого факта. Укажите мне такой стандарт -- я с радостью на него перейду. А то что я в самом деле...
Юрий, познакомьтесь с методикой XP: Extreme Programming. Там давно уже все есть - подробнее тут не буду, а то все узнают :))) А у Дуга ДеКарло есть известная книга Extreme Project Management - ее я сам не изучал, но подозреваю, что основные идеи близки к XP. На самом деле сформулированные Вам проблемы имеют хотя и изящное, но в общем вполне себе реализуемое решение...Захотите пообщаться - пишите в личку.
Консультант, Москва

Не очень понятно, Олег, почему Вы сравниваете ГОСТ и PMBoK - это 'немного' разные вещи. ГОСТы, регламентирующие состав, содержание и правила оформления документации - это вообще отдельная сфера проекта. Важная, нужная - но другая. Но не методология или стандарт [B]управления [/B]проектом.Отмечу, кстати, что я привык пользоваться ГОСТ 34.601 и 34.602. И никоим образом не соглашусь, что их время прошло - напротив, сколько работал, всё больше убеждался в их логичности и полезности.34.601 очень хорошо описывает состав работ - и мой личный опыт мне говорит, что отклонение от этой структуры подчас больно ударяет на поздних этапах. 34.602 прекрасно структурирует ТЗ.Корректней было бы сравнивать 34.х с методологиями типа RUP.Что же касается проектного управления, то его, как такового, в ГОСТах не было, да и быть, наверное, не могло. Ну какие 'риски проекта' при плановой социалистической экономике? ;)Но с другой стороны, PMBoK не даёт чёткой последовательности работ по созданию АСУ (т.е., извините, 'внедрения ERP' :) ). Т.е. вообще последовательности не даёт - не для того он. Вы верно подметили, что это 'ящик с инструментами и инструкцией, как ими пользоваться'. Это удобный инструмент именно для [B]управления проектом[/B] (не хочу пускаться в дискуссию, что лучше - по PMI или по IPMA/Совнет: это отдельная тема).И кто тогда мешает по ГОСТ 34.601 определить состав работ, написать ТЗ по 34.602, а с помощью инструментов PMBoK перевести это в вид [B]проекта[/B] и [B]управлять им[/B]. Так что рановато Вы ГОСТы в утиль списываете :)

IT-менеджер, Москва
[b]Борис Зверев,[/b] Борис, я и хотел в статье показать, что ГОСТы и стандарты PMI дополняют друг друга.Ну а для информационных систем в этом случае есть ещё методологии вендоров, и менеджер проектов должен уметь пользоваться всеми этими инструментами. Видимо, не довёл в статье мысль до конца, но зато это удалось Вам.Что касается
Цесельский Игорь пишет:НТК Совнет, да и другие известные документы
то я не увидел огромной разницы между PMI и IPMA/Совнет, разве что разная процедура сдачи сертификационного экзамена.Но если судить по методологиям SAP и Oracle, то в ИТ побеждает PMI. Может я ошибаюсь, но впечатление у меня такое.
Цесельский Игорь пишет:похоже на обзор журналиста-универсала
Никогда не умел писать сочинения, популярные статьи и т.п., поэтому это для меня комплимент. Спасибо.
Директор по развитию, Украина

Добрый день, уважаемые господа!Тема для меня весьма интересна, поэтому решил присоединиться. Я проектный менеджер в области инвестиционно-строительных проектов и, конечно же, постоянно использовал PMBOK в своей работе. Однако в силу определенных обстоятельств сейчас я 1-й заместитель директора проектного института, занимаюсь внедрением методологии проектного менеджмента в этом институте, и поэтому меня очень интересует опыт использования PMBOK именно в работе организации, основным продуктом которой является проектная документация.Коллеги, имеющие опыт в этом отзовитесь!!

IT-менеджер, Москва
Юрий Максименко пишет:Поэтому жду от стандарта учёта этого факта. Укажите мне такой стандарт -- я с радостью на него перейду. А то что я в самом деле...
Да есть это в PMBOK, только не выделено в раздел, есть во всех разделах. Коррекция целей проекта по мере его исполнения - неизбежна как смерть. По моему опыту - важно, чтобы процедура управления изменениями обязательно была прописана в Регламенте управления проектом (или Уставе проекта, как он у вас называется) и подписана заказчиком. И не лениться писать им официальные извещения и вовлекать заказчика в принятие решений по изменениям как можно раньше. Сумейте это обозначить заранее в рисках и согласовать с заказчиком примерный порядок реагирования. Под подпись или протокол. Это не только хорошая сковородка под любимый орган ПМов (__*__), это реально помогает и вам и заказчику. Не ругаться при наступлении события риска 'кто виноват', а сразу переходить к реагированию. И деньги дополнительные даются гораздо легче и сроки переносятся для учета изменений или отказываются от неважных требований, чтобы выкроить ресурсы.
Юрий Максименко Юрий Максименко CIO, Украина
Андрей Куницын пишет:Юрий, познакомьтесь с методикой XP: Extreme Programming. Там давно уже все есть - подробнее тут не буду, а то все узнаю
Это та методика, клторую Фоулер сочинил? Попробую перечитать ещё раз. Не помню, чтоб там оговаривалось построение отношений с заказчиком. Но возможо, просто забыл.
Андрей Куницын пишет:На самом деле сформулированные Вам проблемы имеют хотя и изящное, но в общем вполне себе реализуемое решение...
Имеют. Даже я умею их решать. Но не могу обосновать свой подход стандартом.
Андрей Куницын пишет:Захотите пообщаться - пишите в личку.
Меня на самом деле мучают другие вопросы. Не знаю, есть ли у меня право грузить Вас ими. Наберусь нахальства -- задам парочку вопросов.
Юрий Максименко Юрий Максименко CIO, Украина
Петр Александров пишет: Да есть это в PMBOK, только не выделено в раздел, есть во всех разделах.
А, так вот почему я не заметил этого при первом чтении. Попробую вчитаться.
Петр Александров пишет:По моему опыту - важно, чтобы процедура управления изменениями обязательно была прописана в Регламенте управления проектом (или Уставе проекта, как он у вас называется) и подписана заказчиком.
О том и речь, что этот регламент мне приходится самому сочинять. С каждым разом получается всё умнее и умнее :)Но хотелось что-то продуманное взять за основу.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

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