Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: Accelerated SAP, Microsoft Dynamics Sure Steps или Oracle Unified Method. Прикладная методология, предлагаемая по умолчанию вендором программного продукта, детализирует одну из трех классических моделей имплементации: каскадную, итерационную или спиралевидную. Помимо этого существуют определенные правила по управлению проектами вне зависимости от его содержания, которые называют PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами) [1].
PMBoK подразумевает выделение в проекте ряда ключевых параметров, каждый из которых необходимо планировать, выполнять и осуществлять его мониторинг. Любые отклонения параметров от плановых значений требуют корректировочного действия. Свод знаний разработан американским институтом PMI и имеет длительную историю. На начало 2022 года в русскоязычной литературе доступна PMBoK шестой версии, а в англоязычной – седьмой. Каждая версия PMBoK дополняется новыми подходами, так ранее широкой огласке получили механизмы искусственного интеллекта в управлении проектами, сейчас же активно обсуждается применение принципов гибкой разработки Agile.
Для прочтения книга PMBoK весьма сложна. Определенно знакомство со сводом знаний необходимо начинать, предварительно реализовав хотя бы один проект, в противном случае вы не поймете посыл книжки. В контексте данной статьи, мы ограничимся рассмотрением ERP-проектов. Использование PMBoK в проектах имплементации корпоративных информационных систем выглядит выигрышным, по крайней мере, это позволяет структурировать характеристики проекта и вести их непрерывный контроль. Существенным упущением PMBoK является отсутствие рекомендаций по способам обработки отклонений, что противоречит циклу Деминга [2]. Вполне возможно, это было сделано сознательно, так как невозможно предложить универсальные механизмы для всех предметных областей проектов.
Цель статьи состоит в рассмотрении способов и методов обработки отклонений в проектах внедрения ERP-систем, что позволит реализовывать программное решение в установленный срок и с заданным качеством. Достижение цели потребует проработки следующих задач:
обзор PMBoK с точки зрения ведения ERP-проектов;
рассмотрение параметров PMBoK, релевантных обработке отклонений;
анализ способов и методов обработки отклонений в ERP-проектах.
1. PMBoK в проектах внедрения ERP-систем
Внедрение ERP-систем включает в себя большое число задач, относящихся к приложениям, данным, технике, бизнес-процессам, изменениям и непосредственно управлению проектом [3]. Первые пять активностей определяют содержание проекта, а последняя используется для управления этим содержанием. Для того, чтобы качественно управлять проектом, PMBoK регламентирует выделение десяти параметров контроля, приведенных ниже (рис. 3.1):
интеграция;
ресурсы;
содержание;
сроки;
стоимость;
заинтересованные стороны;
коммуникации;
качество;
риски;
поставки.
Параметр интеграции необходим для задания целей и задач, ограничения объема, указания последовательности, продолжительности и состава фаз проекта, что документируется в уставе проекта. Здесь же обсуждается порядок отслеживания работ, обработки изменений в содержании проекта, а также перехода между этапами и завершения проекта. Следуя названию, параметр обеспечивает взаимодействие всех проектных задач.
Следующие четыре параметра тесно взаимосвязаны между собой: содержание, ресурсы, сроки и стоимость проекта. Мы уже упомянули в начале раздела, что включает в себя содержание ERP-проекта. Обычно рамки проекта ограничивают сроками, поэтому, чтобы реализовать проект вовремя, выполняется оценка и последующий набор необходимого числа человеческих ресурсов. Умножая человеческие ресурсы на ставку сотрудников и добавляя %-погрешности, получаем предварительный бюджет проекта.
Эффективное управление проектом подразумевает выстраивание нужных коммуникаций со всеми вовлеченными участниками. Для этого PMBoK специфицирует параметры, определяющие заинтересованные стороны и коммуникации с ними. Для каждого участника определяется степень его влияния и заинтересованности, в зависимости от которых, задается регулярность, состав и продолжительность встреч. Таким образом, решается задача поддержания информированности сотрудников о прогрессе проекта.
Если часть содержания передается для выполнения внешнему субподрядчику, то последующая работа с ним контролируется через параметр поставок. Контроль качества выполняемых работ в контексте ERP-систем чаще всего подразумевает дополнительные активности по проверке и согласованию всех проектных документов. В рамках финального параметра проекта ведется идентификация, качественная и количественная оценка негативных рисков.
2. Параметры контроля ERP-проектов
Философия PMBoK строится на цикле Деминга или, как его часто называют, PDCA-цикле. Суть цикла расшифровывается из названия: P – планировать (Plan), D – выполнять (Do), С – контролировать (Control) и A – корректировать (Act). Таким образом активности для каждого параметра проекта сперва планируются, затем исполняются и лишь в конце корректируются при наличии план-фактных отклонений.
Для последующего анализа способов обработки отклонений, еще раз подробнее посмотрим на все параметры ERP-проекта, за исключением интеграции, так как он является объединяющим. Во внимание будем принимать лишь те из них, которые существенно влияют на ход выполнения проекта и являются контрактными обязательствами исполнителя перед заказчиком.
Параметр поставок подразумевает заключение договора между исполнителем и субподрядчиком. Тогда обработка отклонений является фактически ответственностью внешнего контрагента, но не исполнителя. Параметры проекта, определяющие заинтересованные стороны, коммуникации между ними, качество и риски не фигурируют в контракте. Обработка возникших в них отклонений ведется в рабочем порядке и не является из ряда вон выходящим событием.
Переходим к взаимосвязанной четверке «содержание-сроки-ресурсы-стоимость». Важно отметить, что содержание, сроки и стоимость являются неотъемлемой частью договора с заказчиком и обязательны к исполнению, в то время как ресурсы чаще всего в нем не фигурируют, поэтому подбор и найм сотрудников является сугубо личным делом стороны исполнителя. Ограничимся проработкой последних четырех параметров ERP-проекта.
3. Обработка отклонений в проектах внедрения ERP-систем
Анализ способов, позволяющих обрабатывать отклонения ключевой четверки ERP-проекта «содержание-сроки-ресурсы-стоимость», начнем с введения формул, показывающих логическую взаимосвязь между ними. Это даст четкое понимание того, каким образом можно влиять на ход проекта:
Срок = Трудозатраты содержания / (Кол-во ресурсов х Коэф.Доступности), (4.1a)
Стоимость = Срок х Кол-во ресурсов х Ставка х (100% + %-погрешности), (4.1б)
где Коэф.Доступности задает доступность сотрудников в виду занятости непроектными активностями, обычно коэффициент не превышает значений 0.8-0.9, а %-погрешности определяет резервную надбавку для стоимости в виду рисков и неопределенностей, чаще всего, следуя принципу Парето, погрешность задается равной 20%.
Самой распространенной ситуацией на проекте является увеличение содержания проекта, т.е. объема выполняемых работ. Здесь не имеет значения, какой вид договора заключен с заказчиком: фиксированной цены или «Время-материалы». Доступные следующие способы реагирования:
вынесение дополнительных работ во внешний подпроект;
добавление к текущему проекту при незначительных объемах допработ.
Обычно в рамках параметра интеграции проговаривается и документируется подход по управлению изменениями объема проекта, где четко прописан порядок действий, в случае новых или кардинального изменения ранее зафиксированных требований. Следуя этому подходу, новые требования группируются и реализуются как независимый подпроект (запрос на изменение) силами отдельно выделенных людей. Если произошли незначительные изменения требований и суммарные усилия, необходимые для их реализации, не превосходит заданной величины, например, 5 человеко-дней, чаще всего они включаются в объем проекта без формирования запроса на изменения. Аналогичным образом поступают, если содержание меняется по вине исполнителя.
Изменение содержания проекта неминуемо приводит к необходимости привлечения дополнительных человеческих ресурсов. Рассмотрим методы, позволяющие увеличить ресурсы проекта:
использование дополнительных ресурсов, не учтенных в исходном бюджете;
перераспределение ресурсов, доступных на текущем проекте;
повышение мотивации сотрудников.
Если %-погрешности не задавался, то на проект выводятся дополнительные люди, что приводит к внеплановому увеличению бюджета. Тем самым, проект становится инвестиционным. Такое часто бывает, если изначально была поставлена задача продажи проекта любой ценой. Альтернативная опция состоит в перераспределении имеющихся ресурсов на проекте, допустим, когда участники разделены на команды, загруженные неравномерно. И, наконец, вынужденная мера, когда не сработали первые два способа: переработки, работа в выходные и праздничные дни, что часто называют мотивацией сотрудников.
Изменение сроков проекта – это крайняя мера, так как обычно они обсуждаются до начала проекта и фиксируются в договоре с заказчиком. Здесь следует выделить две возможные причины их изменения: по запросу заказчика или по вине исполнителя. Достаточно часто возникает необходимость изменения даты продуктивного запуска, а, следовательно, и завершения проекта на несколько месяцев, из-за бизнес необходимости, снижения непредвиденных негативных рисков или изменения законодательства. В подобных случаях согласуется запрос на изменение, в контексте которого вся проектная команда продлевается на дополнительный интервал времени. Если же, ощущается необходимость изменения сроков по вине исполнителя, дабы исключить несоблюдение контрактных условий, предлагаются лишь два сценария, следуя логики (4.1а):
сокращение содержания;
увеличение числа человеческих ресурсов,
что подробно описано несколькими абзацами выше.
Согласно формуле (4.1б), увеличение бюджета проекта происходит преимущественно по причине привлечения большего числа сотрудников, чем ожидалось изначально. Доступен лишь один способ исключения или, правильнее сказать, нивелирования этой ситуации: изначальное завышение стоимости за счет высокого %-погрешности ...
Литературный источник:
Першин Д.С. Управление отклонениями в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2019. – №1 (5) – С. 45-52. – URL: https://corpinfosys.ru/archive/issue-5/136-2019-5-pmbokdeviations.
