Управление 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
Комментарии
Аналитик, Москва
Олегу благодарен за интересную постановку вопроса. Лично я не совсем согласен с определением сыроватости проектов, связанных с ERP, но не мог не заметить и чёткое позиционирование их высокорискованности. Цитата :
Хочу только отметить, что такие проекты обычно являются высокорисковыми, вероятность изменений параметров таких проектов высокая, технологии реализации таких проектов еще сыроваты (в силу «молодости» ERP-систем, например, по сравнению со строительством).
Но боже мой! Я сто лет в ИТ отрасли и сто лет идут эти разговоры. Самое удивительное, что ни применение государственных стандартов, ни использование методик США не приводят к высокой результативности внедрения информационных систем. Благодарен Олегу за понимание высокорискованности ИТ проектов. Может быть хоть это поможет понять нам, что и заказчик 'не тот', и система 'не та', и программисты, как всегда, виновны...
Аналитик, Москва
Полностью согласен с Борисом Зверевым что PMBoK и ГОСТы - это вообще 'две большие разницы' и их сравнение некорректно, т.к. их цели различны. В принципе PMBoK наверное стоит использовать как источник идей для разработки системы управления проектом, руководствоваться этой методологией наверное не слишком целесообразно. Как и ГОСТы, впрочем.А собственные стандарты разрабатывать уже под цели конкретного проекта/ предприятия....
«Все это уже давно описано ГОСТами, все это известно с давних пор, мы управляли проектами без всяких PMI…»
Безусловно управляют, и иногда даже успешно. Однако оценить качество данного управления и иметь перед собой полную картину проекта без наличия единого стандарта весьма тяжело.... Так что во внедрении методологий эти самые руководители и не заинтересованы. Кроме того, в проектах, реализуемых в проектных институтах очень часто упускаются целые области управления проектом и фактически это управление переходит в управление содержанием продукта, а о стоимости и сроках имеется лишь поверхностное представление.
«PMI не учитывает специфику (государства, отрасли, менталитета и тому подобное)»
PMI как раз пытается перестроить специфику (государства, отрасли, менталитета и тому подобное) на путь более эффективного управления. Условно говоря, расширяет модель мышления руководителя проекта. Зачастую формальные методы управления в тех же проектных институтах считаются чем-то оторванным от реальности и всякие модели управления просто не учитываются. и очень зря, имхо...
Консультант, Москва
Евгений Гринь пишет:В принципе PMBoK наверное стоит использовать как источник идей для разработки системы управления проектом, руководствоваться этой методологией наверное не слишком целесообразно. Как и ГОСТы, впрочем. А собственные стандарты разрабатывать уже под цели конкретного проекта/ предприятия....
Отчасти соглашусь.Мне кажется, собственные стандарты разрабатывать нужно далеко не всегда, особенно в сферах, где уже накоплен богатый опыт ([I]Best practice[/I], как теперь модно говорить иностранными терминами), и не просто накоплен - но и методически обработан и структурирован, т.е. доведён до уровня методологии. Как в известной армейской поговорке про устав караульной службы - каждая строчка в нём написана чьей-то кровью. Если область новая - да, можно пытаться делать какую-то методическую основу, и даже возводить её в ранг стандарта. Но во многих вопросах это уже сделано, кто-то уже на грабли понаступал, и озвучил, где грабли лежат.Скажем, зачем в нерелятивистской механике пересматривать известные нам со школьной скамьи законы, открытые в прошлые века? Пока нужная нам область укладывается в базовые постулаты модели - не нужно изобретать велосипед. Вот если вышла за рамки, а там пусто - давайте изобретать. Но часто оказывается, что и/или не вышла, и/или велосипедов уже целый парк - просто посмотреть надо внимательно :)Более того, главная беда любого проекта, на мой взгляд - несоблюдение основной схемы: 'планируй, как делать - делай, как планировал', причём в двух аспектах. Первый - неграмотное планирование (sic! в большинстве случаев 'невозможность предусмотреть' - всего лишь попытка перенести ответственность за свою некомпетентность на 'действие внешних факторов'). Простительно для первого-второго-третьего случая. Потом опыт приходит, и даже без формальной методологии, 'на кончиках пальцев' начинаешь делать, как надо. Хорошо, если есть возможность учиться на чужих ошибках. Хуже (больней, хотя и эффективней :)) - когда на своих.Второй аспект - несоблюдение планов. Что в них толку, если не следуешь им. Хотя, чья бы корова мычала - сам иногда, 'в интересах дела', отступаю от планов, 'идя навстречу' (по принципу: не пойдёшь навстречу - потеряешь проект). И ведь знаешь заранее, что сюда вляпаешься - а в 'планирование рисков' включить боязно: клиент не поймёт (чаще всего - по срокам). Вот так, наверно, появилась шутка про то, что 'срок, назначенный программистом, нужно умножать на число, лежащее в интервале от [I]е[/I] до [I]Пи[/I]'
Нач. отдела, зам. руководителя, Украина
Борис Зверев пишет: в 'планирование рисков' включить боязно: клиент не поймёт (чаще всего - по срокам).
Отчасти из-за этого и большая часть проблем при внедрении масштабных и многоцелевых проектов вроде ERP. Минусы и риски на предварительных этапах обычно прорабатывают неглубоко и однобоко. Со стороны заказчиков 'производственники' не знают или не до конца понимают специфику разработки, а 'айтишники' внедрением крупных систем пытаются повысить свою значимость и редко показывают свой скептицизм. Разработчики со своей стороны не хотят потерять проект. В результате все не довольны. Это вовсе не вопрос методологии или ГОСТов. Хотя некоторые мечтатели и думают, что правильная методология может помочь, и ломают копья, которая правильная. Забавно, но именно в этом причина популярности экстремального программирования - разрешение противоречий, неучтенные риски и изменения требований становятся частью рабочего процесса. Но я пока не видела ни одного заказчика-'производственника', который бы с ходу подписался на такое.
Юрий Максименко Юрий Максименко CIO, Украина
Наталия Кочубей пишет:Хотя некоторые мечтатели и думают, что правильная методология может помочь, и ломают копья, которая правильная.
Я -- один из таких мечтателей. Я мечтаю, что однажды смогу строить отношения с заказчиком на основе регламента, имеющего статус стандарта. Но все предлагаемые стандарты меня искренне изумляют. Мне представляется ([I]с этого места можно смеяться![/I]), что если я на основе своего опыта напишу стандарт взаимодействия заказчика и разработчика -- он будет прогрессивней тех, что сейчас предлагаются разработчикам.
CIO, Санкт-Петербург
Автор правильно пишет:
Oracle в обязательном порядке в своих проектах использует [B]методологию управления проектами Project Management Method [/B](PJM) и т[B]ехнологическую методологию развертывания программных приложений Application Implementation Method (AIM).[/B] Обе методологии хорошо интегрированы, подробно описаны все действия и документы, четко указаны фазы проекта, связи между действиями, событиями и документами. При этом PJM практически полностью соответствует методологиям управления проектами PMI.
А потом Олег Кашуба перепутал все на свете. 8)
На мой взгляд, Oracle создал одну из лучших методологий реализации проектов [B]создания[/B]? ERP-систем.
При чем тут управление проектами и методология внедрения?!!! Это [B]разные[/B] области знания. Статья написана человеком, который далек от реалий внедрения ERP систем. Низачёт.
Консультант, Москва

вообще-то в России разрабатывается ГОСТ, который должен снять вопрос 'PMBoK или ГОСТ'. Проекты показывали московскому отделению PMI...что-то движется, но сроков я не знаю.'методология внедрения ERP или PMBok'? Часто 'методология' (как и старые ГОСТы) содержит набор документов и регламент документооборота. Нужно выбрать из этого 'богатства' необходимый минимум - без этого проект не сдать. Грубо говоря, методология (или старый ГОСТ) - regulatory, а PMBoK - standard. Но вот полагаться на 100% (мягко говоря) на методологию я бы не советовал. Нужно знать и методологию и общие стандарты управления проектами. При этом понятно, что общий стандарт не содержит всех шаблонов документов для внедрения ERP.Риски компенсировать удавалось только за счет увеличения бюджета и резервов в расписании. Причем очень серьезного увеличения, которое очень тяжело обосновать до начала работ

CIO, Украина

Принципиальное отличие ГОСТов от PMBOK в том, что ГОСТы (в свое время) выполняли не только рекомендательную и методическую функции, а были обязательными к применению в проектах (в них так и писалось - несоблюдение ГОСТа преследуется по закону). Только таким образом удалось достигнуть высочайшей степени унификации методов разработки и проектной документации, сопровождавшей сотни тысяч проектов АСУ (ERP), которые выполнялись различными коллективами, в разных отраслях, на разной ВТ, на разных языках программирования и СУБД с начала 70-х годов прошлого века (это к вопросу о 'молодости' ERP).Ещё одно важное отличие ГОСТов от PMBOK:PMBOK определяет универсальную методологию управления ЛЮБЫМИ проектами как в ИТ, так и в области строительства, медицины, торговли и т.п. Упомянутые же автором ГОСТы 34-й и 19-й серии 'заточены' именно на большие автоматизированные информационные системы - на их РАЗРАБОТКУ, внедрение и сопровождение. И ничего более совершенного пока не придумано.Так что в ERP-проектах время ГОСТов НЕ ПРОШЛО! (Дай им Бог долгих лет жизни).Если же речь идет только о внедрении 'готовых' ERP-систем от SAP, Oracle, Microsoft etc, то 'вендорские' методики безусловно полезны, хотя внедренцы теряют универсальность и им приходится переучиваться при смене вендора.

IT-менеджер, Москва

Вообще, на самом деле, самый основной вопрос заключается в определении цели. Что господа ИТ-шники мы делаем: ERP внедряем или бизнес автоматизируем? Это основное.Если бизнес автоматизируем, тогда выбираем те инструменты, которые позволяют это делать, если ERP внедряем, тогда вот все вышеописанное.То, что проделал автор статьи заслуживает уважения, он элементарно 'собрал в кучу' тот инструментарий, которые есть и попытался проанализировать 'похожести' и 'полезности'. Удивлен, что большинство читателей так и не сообразили, что он элементарно с названием статьи не очень правильно определился, по тексту не о сравнении ГОСТ и PMBOK идет, а рассматриваются разные комбинации методологий внедрения и управления проектами, и демонстрируется их похожесть.Похожесть действительно есть и ее можно назвать просто 'каскадный метод создания системы'.Однако, правда жизни в том, что этот метод очень эффективен на стабильных структурах, именно по этому крупные компании и используют часто ГОСТ при разработке/внедрении продуктов и систем. Другое дело, что не все компании крупные и стабильные.Кстати, выше обсуждались Oracle PJM и AIM, а ведь там есть еще и ABF. То есть более правильно комбинация PJM и ABF. Рекомендую посмотреть... если в Вашем случае речь идет об автоматизации бизнеса, а не о решении конкретной инженерной задачи.

CIO, Санкт-Петербург
Максим Артамохин пишет:То, что проделал автор статьи заслуживает уважения, он элементарно 'собрал в кучу' тот инструментарий, которые есть и попытался проанализировать 'похожести' и 'полезности'. Удивлен, что большинство читателей так и не сообразили
Максим, судя по Вашему комментарию Вы тоже не сообразили, что автор хотел сказать. Как впрочем и остальные, в том числе и я 8)
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Треть профессионалов не доверяют своему руководству

Специалисты меньше, чем руководители и директора, склонны к доверию.

Зарплатные ожидания IT-специалистов превышают возможности работодателей в 1,5-2 раза

Общий рост зарплат в IT-сфере за первые 9 месяцев 2023 года составил 15-20%.

Россияне стали меньше тревожиться из-за работы

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

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

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