Управление проектами: статьи

Похожая история и в 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. Казалось все очевидно ― но я встречал и другие мнения.