Управление 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
Комментарии
IT-менеджер, Москва
Елена Кудрявцева пишет: А чем ''договоры в консалтинге'' отличаются от других договоров? Любые договоры должны соответствовать требованиям действующего законодательства, а оно не запрещает заключать доп_соглашения к любым договорам...
Ну что касается Гражданского кодекса, то ничем. Там в целом все правила оговорены. Речь немного о другом была. Консалтинговые проекты отличаются от остальных. В одной из тем писал, что некоторые их и проектами не считают в силу того, что они и правда очень смахивают на инновационную деятельность. Ну вот сами смотрите, по формальной части проекта Вы обязаны сделать некоторые вещи за вполне определенные деньги, но есть нюанс, при выполнении работ Вы сталкиваетесь с тем, что либо Вы закладываете некоторые дополнительные возможности (даже концептуально) в итоговый продукт, либо клиент в дальнейшем попадает на серьезные расходы для того, чтобы решить эти вопросы иными средствами. Что тут правильно? С одной стороны нужно бороться за бюджет, с другой... для клиента вопрос сложный, и далеко не каждый там с решением этой задачи справится. Был свидетелем одного интересного момента из этой ''оперы'', да на тот момент бюджет выдержали.... правда в ближайшем будущем заплатят существенно больше. Но это выбор клиента. И еще вопрос про ''гибкость'' бюджета, любая такая ''гибкость'' для клиента выглядит, как попытка раскрутить его необоснованно на деньги со стороны консалтинга. Отсюда и особенность договорной деятельности.... дальше, возможно, по-другому думать буду, но сейчас есть четкое понимание, что сам договор должен быть максимальной ''рамкой'', детали в дополнительных документах, которые дополнительными соглашениями не являются, но их роль, скажем так, выполняют. Это очень не простой вопрос для Российской практики, да на Западе вроде как его решили... но тут пока нет. Даже на понятийном уровне. Не верите? Попробуйте ''закинуть удочку'' по типу надо решить задачку и предложите консалтинговым компаниям дать предложения в виде близком к тому договору, который потом будет... прочитаете много, но оно будет ну очень похожее по содержанию.
Системный аналитик, Москва
Максим Артамохин пишет: Ну вот сами смотрите, по формальной части проекта Вы обязаны сделать некоторые вещи за вполне определенные деньги, но есть нюанс, при выполнении работ Вы сталкиваетесь с тем, что либо Вы закладываете некоторые дополнительные возможности (даже концептуально) в итоговый продукт, либо клиент в дальнейшем попадает на серьезные расходы для того, чтобы решить эти вопросы иными средствами. Что тут правильно? С одной стороны нужно бороться за бюджет, с другой... для клиента вопрос сложный, и далеко не каждый там с решением этой задачи справится. Был свидетелем одного интересного момента из этой ''оперы'', да на тот момент бюджет выдержали.... правда в ближайшем будущем заплатят существенно больше. Но это выбор клиента.
Не совсем понятен вопрос ''Что тут правильно?'' имхо, здесь две РАЗНЫХ ситуации 1) выдерживаем бюджет и ''отгружаем'' продукцию, соответствующую первоначально оговоренной стоимости 2) отгружеам ''доп_возможности'', но за доп_деньги Почему-то когда речь идет о замене материала в строительном контракте, клиент относится с пониманием. А когда проект интеллектуальный, вопрос становится для клиента сложным... Как считаете, Максим, это российская или международная особенность бизнеса?
Системный аналитик, Москва
Максим Артамохин пишет: И еще вопрос про ''гибкость'' бюджета, любая такая ''гибкость'' для клиента выглядит, как попытка раскрутить его необоснованно на деньги со стороны консалтинга.
Не так прост наш клиент, как пытается притвориться. Не может он не понимать, что доп_ работа стОит доп_денег. Кстати, гибкость не всегда в сторону увеличения. Считаете, если исполнитель предложит сократить бюджет, поскольку обошелся малой кровью, клиент будет сопротивляться?
Системный аналитик, Москва
Максим Артамохин пишет: 1) Отсюда и особенность договорной деятельности.... дальше, возможно, по-другому думать буду, но сейчас есть четкое понимание, что сам договор должен быть максимальной ''рамкой'', детали в дополнительных документах, которые дополнительными соглашениями не являются, но их роль, скажем так, выполняют. 2) Это очень не простой вопрос для Российской практики, да на Западе вроде как его решили... но тут пока нет. Даже на понятийном уровне. Не верите? Попробуйте ''закинуть удочку'' по типу надо решить задачку и предложите консалтинговым компаниям дать предложения в виде близком к тому договору, который потом будет... прочитаете много, но оно будет ну очень похожее по содержанию.
1) не спорю про рамочный характер договора и про необходимость неких доп_соглашений к нему вопрос скорее технический думаю, девелоперы имеют подобный опыт ведь строительство бизнес-центра и разработка и/или внедрение ERP так похожи 2) да и вообще на Западе порядка больше (: неоспоримо, что консультанты пришлют похожие ответы на практическую задачу похожие отсутствием конкретики
IT-менеджер, Москва
Елена Кудрявцева пишет: ведь строительство бизнес-центра и разработка и/или внедрение ERP так похожи
Извините... бред полный, ну я же писал выше... про то, что ERP-шные проекты некоторые и проектам не относят... более того в дополнение скажу, что они в чем-то правы.
Елена Кудрявцева пишет: да и вообще на Западе порядка больше (: неоспоримо, что консультанты пришлют похожие ответы на практическую задачу похожие отсутствием конкретики
Опять же... бред. Прошу не обижаться. Единственное в чем соглашусь, это по поводу порядка, но там, пардон, к изменениям не меньше года готовятся, а тут это делают по месту и сразу. Ну если, конечно, вообще собираются что-то делать.
IT-менеджер, Москва
Елена Кудрявцева пишет: неоспоримо, что консультанты пришлют похожие ответы на практическую задачу похожие отсутствием конкретики
Специально выделил. Работайте с профессиональными консультантами, а не со всеми подряд, название компании не всегда критерий. Вопрос сам решится.
Системный аналитик, Москва
Максим Артамохин пишет: 1)
Цитата Елена Кудрявцева пишет: ведь строительство бизнес-центра и разработка и/или внедрение ERP так похожи
Извините... бред полный, ну я же писал выше... про то, что ERP-шные проекты некоторые и проектам не относят... более того в дополнение скажу, что они в чем-то правы. 2)
Цитата Елена Кудрявцева пишет: да и вообще на Западе порядка больше (: неоспоримо, что консультанты пришлют похожие ответы на практическую задачу похожие отсутствием конкретики
Опять же... бред. Прошу не обижаться. Единственное в чем соглашусь, это по поводу порядка, но там, пардон, к изменениям не меньше года готовятся, а тут это делают по месту и сразу. Ну если, конечно, вообще собираются что-то делать.
Максим, никто и не обижается (: можно было не извиняться просто формулировать можно и помягче (''полный бред'' это слишком по отношению к моим измышлениям) там более, что 1) ИТшные и строительные проекты похожи даже профессионалов называют одинаково ''архитекторы'', ''девелоперы'' вот только менеджеров зовут по-разному: менеджер проекта vs прораб 2) а здесь я даже противоречия не уловила, на Западе действительно порядка больше, просто позволю добавить, что ''тут это делают по месту и сразу'' потому, что результат нужен ВЧЕРА
Системный аналитик, Москва
Михаил Кузнецов пишет: Статья к сожалению не открывается, а дискуссию прочитал с интересом. Вопрос следующий - почему на этапе формализации задачи уважаемые PM так мучаются с заказчиком, вместо того чтобы использовать бизнес-аналитиков с технологиями описания моделей бизнеса типа IDEF0 или eEPC (Aris). Неужели все дело в нежелани делится бюджетом?
Михаил, это концептуальная проблема! Чтобы ''использовать бизнес-аналитиков'', нужно иметь договор (поверхностное 2-недельное обследование на ERP-проекте это несерьезно). А чтобы иметь договор, нужно знать результат работы бизнес-аналитиков. Один из вариантов = отдельный договор на обследование, но я такое в практике встречала редко
IT-менеджер, Москва
Елена Кудрявцева пишет: 1) ИТшные и строительные проекты похожи даже профессионалов называют одинаково ''архитекторы'', ''девелоперы'' вот только менеджеров зовут по-разному: менеджер проекта vs прораб
Елена, если где-то чуть жестко выразился... ну уж как умею :) Есть такая особенность, знаю о ней.. исправлять не буду :) Она хоть и шокирует людей иногда, но тем не менее кучу рисков убирает. Что касается остального... можно долго писать и объяснять... не хочу, вот не потому, что чего-то не знаю, или что типа крутым себя считаю, или что-то еще.... но набьете шишек - поймете о чем я писал, или не поймете, что уже диагнозом будет. Видел, описанные Вами подходы в жизни. Причем довольно крупные интеграторы это юзают.... только вот... процент РЕАЛЬНО успешных внедрений при таком подходе крайне низок. Подумайте почему. Еще раз уточню для понимания... РЕАЛЬНО успешных внедрений, а не внедрений с победными реляциями :)
Knowledge manager, Украина

Позволю себе несколько отступить от течения.
Впервые столкнулся с ГОСТ по проектированию АСУТП в 1984 году. Тогда он был еще 24.хх.
Произошло это в процессе разработки системы сменно-суточного планирования для механо-сборочного цеха.
Вызвано было разночтениями в командАХ разработчиков, поскольку разработка велась совместными группами из институтов РАЗНЫХ министерств (ну заставили, куда ж денешься).
Я участвовал со стороны Заказчика.
Огромную роль играло то, что почти все участники учились в одних ВУЗах, или на родственных факультетах (всё это было в одном городе). Т.е. общение наше НЕ НАЧАЛОСЬ с работы в этом проекте и НЕ ОГРАНИЧИВАЛОСЬ работой в этом проекте. В результате в течение 6 месяцев было подготовлено и подписано всеми участниками ТЗ, удовлетворяющее требованиям ГОСТ.
Столь пространное описание я привел только с одной целью. Для понимания заключения. ВСЁ ПОЛУЧИЛОСЬ. Так, как хотел Заказчик.
В конце 80-х попалась на глаза статья, в которой аналитики объясняли провал своих прогнозов начала 80-х, относительно широкого распостранения ГПС (вследствие повышения тиражируемости и соответствующего снижения стоимости проектов). Не произошло это предполагаемое снижение стоимости в связи с тем, что подобные проекты оказалось невозможно тиражировать. И каждый проект оказывался уникальным.
Дальнейший опыт, уже в построении учетных систем, подтвердил одну часть подхода. Не по ГОСТу - плохо. Вторую часть (по ГОСТу - хорошо) - подтвердить вряд ли удастся.
Прежде всего, по ГОСТу - дорого. Нужны умные и на долгое время. Из этого вытекает ужасная химера под названием ''Особенности национального проектирования''. Начиная работать над проектом я обязательно напишу ТЗ. Для себя. И даже технический проект подготовлю. Вот только Заказчику я его показывать не собираюсь. Причина - банальна. Платить за бумагу он не собирается. А после написания ХОРОШЕГО ТЗ - я становлюсь ненужным (за оговариваемую плату). Поэтому Заказчику будут представлены ''Основные направления'' с конкретизацией (по возможности) затрат на техническое обеспечение, рекомендуемая организационная структура и некоторые аспекты реализации обратных связей (в одних операциях организуем невозможность ошибки, в других - жестокие материальные санкции). Такой подход устраивает и меня и Заказчика. ТЗ он всё равно не поймет (да и понимать не захочет), а его затраты в общих чертах - понятны. Дальнейшая работа будет проходить ПОСТЕПЕННО. По мере реализации последовательности процессов. Как правило, всё начинается с наведения элементарного порядка (приказы по документообороту и по распределению функций и ответственности). Это уже дает видимую эффективность в виде наглядного показа пригодности того или иного исполнителя и определения, чего хотелось бы от него получить. Это первая маленькая победа (если удается) повышает уровень доверия ко мне, как к консультанту (я сам ничего не делаю, только готовлю проекты приказов) и дает возможность определить следующую глубину, на которую Заказчик готов ''нырнуть''. Таким образом МЫ ВМЕСТЕ С ЗАКАЗЧИКОМ доходим до ''рабочей'' глубины. Он готов на эту глубину ''нырять'', я готов обеспечить его жизнедеятельность на этой глубине. Поэтому дать определение успешности или неуспешности проекта весьма затруднительно. Я еще ни разу не дошел до той глубины, на которой побывал в середине 80-х, а Заказчику туда и не хочется.
Утверждать могу только одно (но уверенно). Набор функций и процедур, при всей их похожести у каждого Заказчика - разный. Там попался феноменальный (и не ворующий) начальник производства, там - ФинДир - родственник и т.п.
Н Е Т И Р А Ж И Р У Е Т С Я .......

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
4
Михаил Лурье
Если задача ставится не решить конкретный вопрос, на что нацелены адвокаты, а создать прецедент,...
Все дискуссии
HR-новости
Каждый второй россиянин готов уволиться из-за токсичного руководства

Токсичный руководитель – вторая основная причина для увольнения россиян.