Введение в управление проектами внедрения ERP-систем

Глава 3. Как внедрять ERP-систему

3.1. Технологии управления проектами

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

Другое дело, какую методологию выбрать, как все распланировать, оценить, соблюдать и контролировать выполнение работ, минимизировать различные риски и проблемы?

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

Технологии и стандарты управления проектами можно разделить на три условные категории:

- Гибкие (Agile), такие как Scrum, Kanban, Extreme programming. Представляют собой:

  • Семейство «гибких» подходов к разработке программного обеспечения. Такие подходы иногда называют фреймворками или agile-методологиями.
  • Манифест: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
  • Бюджет всего проекта заранее неизвестен, есть примерные оценки, работа по факту (time in material).

- Классические, такие как ISO 21500, ГОСТ 34, PMBOK. Представляют собой:

  • Каскадные, или «водопадные», модели (waterfall model) – поток из последовательности этапов/фаз работ над проектом.
  • Подробное планирование и проектирование до начала работ (самой разработки), подробное документирование всех стадий проекта и взаимодействия участников.
  • Бюджет заранее известен и часто фиксирован (fix price).

- Когда нет методологии:

  • Основная идея: «Зачем какие-то методологии и управление, просто сделайте/сделаем, что просим/просите».
  • Может трактоваться как подвид гибких технологий, но это не так.
  • Сама методика не формализована либо имеет атрибуты, например, классических подходов. Все равно используется какой-то план дел в голове, так как нужно же как-то к графику оплат по договору привязывать какие-то работы.
  • На практике встречается в небольших командах из 1–2 специалистов и в краткосрочных работах.
  • На выходе нет никаких проектных документов (т. к. и проекта же нет, просто какие-то услуги за какое-то время). Все на вербальной коммуникации, квалификации конкретного специалиста и проверке результата его работ.
  • Управления рисками нет (а сами риски есть), сроки и объем работ проконтролировать сложно. Типичная итерация: «Готово?» – «Да, почти» – «Когда будет?» – «На следующей неделе», – и так каждую неделю. Понять, где мы сегодня, практически нельзя – точнее, можно, но для этого нужно на этот «непроект» применить какую-то методологию и формально описать, что было нужно сделать, что уже сделано, что осталось, какие трудозатраты и ресурсы.
  • ERP-системы так внедрять настоятельно не рекомендуется. Почему – станет понятно из последующих глав, из перечня того, что нужно учитывать. Эта категория выделена не просто так, а исходя из суровой реальности: такой подход встречается на практике. Рассматривать детально эту категорию, очевидно, не будем. Такого просто не должно быть.
Показать оглавление

Комментариев: 0

Оставить комментарий