Глава 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-системы так внедрять настоятельно не рекомендуется. Почему – станет понятно из последующих глав, из перечня того, что нужно учитывать. Эта категория выделена не просто так, а исходя из суровой реальности: такой подход встречается на практике. Рассматривать детально эту категорию, очевидно, не будем. Такого просто не должно быть.
