Найти в Дзене

План управления проектом по PMBOK

Скажу прямо: если вы хоть раз участвовали во внедрении ERP-системы, то уже понимаете, зачем нужен план управления проектом. А если ещё нет — лучше подготовиться заранее. Такие проекты редко идут гладко. Масштаб, участники, интересы, бюджет, сроки — всё это легко превращается в клубок. И вот тут как раз нужен не красивый документ ради галочки, а реальный рабочий инструмент. Об этом и поговорим. PMBOK (Project Management Body of Knowledge) — это не столько методология, сколько свод знаний. В нём описано, как грамотно управлять проектами: от инициации до закрытия. В основе — пять групп процессов (инициация, планирование, исполнение, мониторинг и завершение) и десять областей знаний (управление содержанием, сроками, стоимостью, качеством и т.д.). План управления проектом — это ключевой артефакт. По сути, он объединяет все частные планы: по срокам, бюджету, коммуникациям, рискам и так далее. PMBOK прямо говорит — это не один документ, а совокупность планов. Но на практике часто делают едины
Оглавление
План управления проектом по PMBOK
План управления проектом по PMBOK

Скажу прямо: если вы хоть раз участвовали во внедрении ERP-системы, то уже понимаете, зачем нужен план управления проектом. А если ещё нет — лучше подготовиться заранее. Такие проекты редко идут гладко. Масштаб, участники, интересы, бюджет, сроки — всё это легко превращается в клубок. И вот тут как раз нужен не красивый документ ради галочки, а реальный рабочий инструмент. Об этом и поговорим.

Что такое план управления проектом по версии PMBOK

PMBOK (Project Management Body of Knowledge) — это не столько методология, сколько свод знаний. В нём описано, как грамотно управлять проектами: от инициации до закрытия. В основе — пять групп процессов (инициация, планирование, исполнение, мониторинг и завершение) и десять областей знаний (управление содержанием, сроками, стоимостью, качеством и т.д.).

План управления проектом — это ключевой артефакт. По сути, он объединяет все частные планы: по срокам, бюджету, коммуникациям, рискам и так далее. PMBOK прямо говорит — это не один документ, а совокупность планов. Но на практике часто делают единый файл, где структурированно описываются все аспекты управления проектом.

Что входит в план: неформальный чек-лист

Чтобы не уйти в академические формулировки, перечислю просто и по делу. В нормальном плане управления проектом должны быть следующие разделы:

  1. Цели и критерии успеха. Что считаем завершением проекта и как поймём, что он удался.
  2. Область охвата (scope). Что именно входит в проект, а что — нет. Очень важно для ERP.
  3. Структура работ (WBS). Декомпозиция задач по уровням.
  4. Календарный план. Кто, когда и что делает. Желательно с буферами.
  5. Оценка ресурсов и бюджета. Сколько людей, какие роли, сколько стоит.
  6. Управление рисками. Что может пойти не так и что тогда делаем.
  7. План коммуникаций. Кто с кем общается, как часто, в каком формате.
  8. Контроль изменений. Как фиксировать и одобрять любые отклонения от плана.
  9. Контроль качества. Как и по каким критериям проверяем результат.
  10. План закупок и внешних подрядчиков. Особенно актуально, если в проекте участвует интегратор.
  11. Методы контроля и отчётности. Как проверяем ход проекта.

Применение на практике: ERP как тест на зрелость

План — это только начало. На ERP-проектах всё сильно усложняется. Во-первых, они идут долго: от 6 месяцев до 2 лет. Во-вторых, вовлечено много сторон: заказчик, подрядчик, пользователи, ИТ, бухгалтерия, HR и т.д. У всех свои интересы и ожидания. Без плана начнётся бесконечное перетягивание одеяла.

Вот типичный кейс. Проект по внедрению 1С:ERP в холдинге. На старте — общее понимание: «хотим автоматизировать и стандартизировать процессы». Но как только начинаются детали, выясняется:

  • у бухгалтерии — одно видение
  • у ИТ — другое
  • у собственника — третье
  • у подрядчика — вообще своё

Если заранее не зафиксировать, что именно входит в объём проекта, как принимаются изменения и по каким метрикам оценивается прогресс — всё рассыплется. А рассыпается, как правило, после третьего месяца.

Если хотите разобраться, как действительно работает план управления проектом на практике, а не в теории — посмотрите программу курса «Школа руководителя проекта». Там вы найдёте и WBS, и риск-реестры, и методы коммуникации, адаптированные под ERP. Подробнее на сайте.

Как сделать план живым документом

Есть одна распространённая ошибка: сделали план в начале и забыли. Проект идёт, реальность меняется, но план — нет. В итоге в критический момент все хватаются за голову: где сроки, кто ответственный, почему никто не знал?

Чтобы этого не случилось:

  • Пересматривайте план минимум раз в месяц. Особенно разделы по рискам, срокам и коммуникациям.
  • Обновляйте WBS и календарь. Пусть команда видит, что происходит не только на словах.
  • Вносите изменения формально. Даже если проект внутренний и никто не требует официального документооборота — фиксируйте, что и почему меняется.

Кто отвечает за план

Формально — руководитель проекта. Но в реальности — все ключевые участники. Хороший план нельзя написать в одиночку. Нужно:

  • собрать входные данные от заказчика;
  • обсудить реалистичность сроков с командой;
  • получить от интегратора информацию о трудозатратах;
  • согласовать с бизнесом приоритеты.

Отдельное внимание — вовлечённости. Если план сделан только для руководства и команда его не видела, он не работает. В ERP-проектах критично, чтобы ключевые исполнители понимали, откуда берутся сроки и объём работ. Тогда снижается сопротивление и повышается точность оценок.

Инструменты: чем и как фиксировать

Можно использовать:

  • MS Project или аналог. Подходит для детального планирования и отслеживания зависимостей.
  • Excel. Универсален, но требует дисциплины.
  • Jira, Trello, Notion. Хорошо работают в гибридных командах.
  • 1С:PM или 1С:СППР, если речь о проектах внутри 1С-экосистемы.

Важно не столько, с помощью какого инструмента сделан план, сколько то, как с ним работают. Идеальный вариант — это тот, который доступен команде, легко обновляется и позволяет быстро получить нужную информацию.

Типичные ошибки

На практике я встречал несколько повторяющихся провалов:

  1. План создают, когда всё уже запущено. Это как писать инструкцию, когда машина уже едет.
  2. Игнорируют раздел про управление изменениями. А потом удивляются, почему объём растёт, а срок — нет.
  3. Команда не читает план. Особенно плохо, если там же определены роли и ответственность.
  4. Ставят абстрактные цели. «Оптимизировать учёт» — не цель. «Внедрить единый план счетов до 1 октября» — уже лучше.
  5. Путают график с планом. Гант — это только часть. Без остальных разделов он не спасёт.

Что меняется с опытом

Чем больше ERP-проектов проходит команда, тем чётче становится одно: проект не спасти героизмом. Только плановая работа. Хаос нельзя победить энтузиазмом, он побеждается структурой. План помогает не только управлять задачами, но и управлять ожиданиями. Особенно руководства.\

С опытом приходит привычка начинать не с обсуждения «какой у нас продукт», а с вопроса «какой у нас план и кто за что отвечает». Когда в проекте это правило соблюдается — процент успешных внедрений резко растёт.

Итог

План управления проектом — это не формальность, не красивая обёртка и не бюрократия ради отчёта. Это главный инструмент выживания в ERP-проектах. Особенно если проект крупный, срок длинный, а людей много. Хороший план не гарантирует успех, но точно снижает риск провала. Он даёт опору в моменты, когда всё начинает сыпаться. А это в ERP происходит почти всегда. Так что лучше подготовиться.

И ещё. План — это не про то, чтобы «всё предусмотреть». Это про то, чтобы быстро понять, что идёт не так, и договориться, что делаем дальше. Именно поэтому он работает.

Понравилась статья?

Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.

Больше интересных тем — на нашем ✈️ Telegram-канале.

Подробнее о наших курсах — на сайте