Введение
Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.
В данной работе мы выполним анализ примеров построения ресурсного плана в проектах внедрения ERP-систем, что позволит планировать человеческие ресурсы более точно и обеспечит более эффективное и качественное имплементирование программной системы. Для начала более подробно разберемся, как взаимосвязаны между собой три плана: проекта, ресурсный и затрат. Обычно план проекта ведется в разрезе задач, далее на него налагается ресурсный план, показывающий, какое число человеческих ресурсов требуется для выполнения активностей. Зная число и квалификацию ресурсов, а также их ставки, возможно рассчитать план по затратам. Таким образом все три плана связаны между собой и изменение одного из них непременно приводит к обновлению других. Наконец, построив ресурсный план, мы фактически формируем планы проекта и затрат.
Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].
1. Подбор продолжительности этапов внедрения в ресурсном плане
Если рассмотреть все этапы внедрения ERP-систем, то можно с лёгкостью заметить, что они все зависят от результатов анализа требований и проведения Fit/Gap-анализа. Так этапы проектирования и реализации чувствительны к числу документов функциональных спецификаций и настроек, а фаза анализа определяется числом требований, все последующие этапы имеют схожую зависимость. Таким образом, предлагаемый способ построения ресурсного плана [3] имеет место быть.
Теперь давайте проанализируем построение части ресурсного плана, стартующего с этапа проектирования. Несмотря на то, что фаза дизайна обычно длится от 1-3 месяца, существует большое число вариаций построения ресурсного плана для этого этапа за счет изменения параметра продолжительности (рис. 1). Вопрос, какую продолжительность этапа можно считать оптимальной? В работе [3] на этот вопрос нет ответа. С учетом рисков проекта, состоящих в том, что объем работ только увеличивается, а не наоборот, продолжительности этапов должны быть максимально длительными. Объяснение здесь весьма простое, зная зависимость срока этапа от объема работ:
Срок = Объём работ / Число человеческих ресурсов, (1)
очевидно, чем больше ресурсов, выделено на проект, тем более короткие сроки выполнения работ ожидаются. Ключевое слово «ожидается», ведь на практике, чем больше людей, тем больше неразбериха, плюс нужен дополнительный человек, кто будет управлять остальными. Поэтому, если сравнивать:
- объем работ в 5 человеко-дней, выполняемый 5-ю ресурсами за 1 день;
- и то же содержание работ, но продолжительностью 5 дней с 1-м единственным ресурсом,
второй вариант кажется предпочтительным, так как при его использовании, в случае затягивании сроков, возможно заблаговременно и безболезненно привлечь дополнительные ресурсы, в отличие от первого случая, где сроки минимальны, а число ресурсов и так завышено.
Рис. 1. Варианты задания продолжительности этапа проектирования: а) наихудший сценарий; б) наилучший случай; в) наиболее реалистичный способ
Полный текст статьи: https://corpinfosys.ru/archive/2022/issue-19/203-2022-19-erpresourceplan
