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

Подробности
Опубликовано: 20.07.2022 09:00
Автор: Першин Дмитрий Сергеевич
Просмотров: 1359
Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье уточняется метод построения ресурсного плана для проектов внедрения ERP-систем на основе бенчмаркинга этапов и оценщика разработок. Детализируется механизм оценки продолжительности этапов проектирования и реализации при формировании плана. Рассматривается быстрый способ построения ресурсного плана в высокорискованных проектах, а также уточняется алгоритм оптимизации плана для сокращения затрат.
Скачать: PDF (статья), PDF (выпуск №19).
Ключевые слова: ресурсный план проекта, составление план графика реализации проекта, план график реализации проекта, календарно ресурсный план, ресурсный план ERP, метод критического пути проекта, метод критической цепи в управлении проектами, бенчмаркинг информационных систем, управление человеческими ресурсами проекта, планирование человеческих ресурсов проекта, человеческие ресурсы проекта.

Введение

Согласно своду по управлению знаниями 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. Варианты задания продолжительности этапа проектирования:
а) наихудший сценарий; б) наилучший случай; в) наиболее реалистичный способ

2. Формирование ресурсного плана для высокорискованных проектов

Предварительный ресурсный план можно построить уже при наличии информации о Fit/Gap-анализе. Для этого достаточно продублировать все человеческие ресурсы, найденные для этапов проектирования и реализации, на оставшуюся календарную сетку (рис. 2).

Построение ресурсного плана для высокорискованных проектов без оптимизации

Рис. 2. Построение ресурсного плана для высокорискованных проектов без оптимизации

Однако, при этом мы увеличиваем степень хаотичности плана, что следует из определения информационной энтропии [4]. Действительно, если задать энтропию Н для состояния М неоптимизированного ресурсного плана, то:

Н(М) = log(K),                                                    (2)

где К – суммарное число рабочих недель. В случае М', когда К>К', H(M) >= H(M'). Тем самым мера хаотичности неоптимизированного ресурсного плана всегда выше по сравнению с его оптимизированной версией. Возникает вопрос: где разумнее всего остановиться в вопросе оптимизации? По существу, мы должны найти баланс между двумя состояниями проекта: хаотичность и рискованность. То есть решается классическая задача АРИЗ [5]: численность проектной команды должна быть одновременно большой для сглаживания проектных рисков и небольшой для обеспечения должного уровня управляемости.

3. Оптимизация ресурсного плана

Специфика проектов внедрения ERP-систем практически никак не накладывает ограничения и не приводит к изменениям в каскадной модели имплементирования. Напротив, многопроходные модели требуют существенного адаптирования. Для этого дифференцируем активности ERP-систем на проекты внедрения с «нуля» и тиражирования, а также развития уже имплементированных программных решений. Начнем рассмотрение с последних, так как гибкие подходы сейчас в большей степени используются для них.

ЧислоФунРесурсТекущЭтапа=ОкрДоЦел(ЧислоФунРесурс(Этап проектирования)/2),    (3)

в то время, как количество ресурсов на этапе проектирования ищется, исходя из логики, описанной в п.1, что так же релевантно для фазы реализации. Сокращение числа разработчиков ведется схожим образом, однако для расчета (3) применяется фаза реализации, позволяющая сократить ресурсы этапов приемочного теста, перехода и поддержки. Отличие в логике вычисления ресурсов консультантов и разработчиков на этапе приемочного тестирования объясняется тем, что программисты к этому моменту времени уже завершают все свои ключевые задачи, в то время как консультанты поддерживают испытания и готовятся к предстоящему переходу (рис. 3).

Оптимизированный ресурсный план

Рис. 3. Оптимизированный ресурсный план

Введенная логика позволяет оптимизировать численный состав команды на величину 10-15% от исходного расчета. Следовательно, если построить гистограмму ресурсов проекта и ее геометрическая форма напоминает прямоугольник, мы имеем дело с хаотично системой, заточенной под высокорискованные проекты. Если же форма напоминает треугольник, ромб или другие неправильные фигуры, то речь идет о проектах с оптимизированными ресурсами.

Заключение

Подытоживая результаты работы, хочется отметить самое важное. Развивая метод быстрого построения ресурсного плана на основе бенчмаркинга и оценщика разработок, следует обратить особое внимание на логику определения продолжительностей этапов проектирования и реализации: по возможности устанавливать их сроки более длительными, что позволит снизить риски отставания от план-графика. Для построения ресурсного плана для высокорискованных и сложных ERP-проектов не требует оптимизации, поэтому достаточно рассчитать человеческие ресурсы на фазах проектирования и разработки, далее дублировать их на все остальные этапы, сохраняя исходный численный состав. Менее сложные ERP-проекты и проекты, требующие максимального сокращения затрат, подразумевают оптимизацию ресурсного плана. В качестве верхней оценки количества ресурсов выступают расчеты, аналогичные высокорискованным проектам п.2, а нижней – логика, данная в п.3 настоящей работы. Финальный план в этом случает строится, исходя из рисков и варьирования между нижней и верхней оценками.

Литература

  1. Степанов Д.Ю. Метод формирования ресурсного плана в проектах внедрения ERP-систем на основе бенчмаркинга и оценщика // Высокопроизводительные вычислительные системы и технологии. – 2022. – т. 6, № 1. – c.161-165.
  2. Ширенбек Х., Листер М., Кирмсе Ш. Руководство к своду знаний по управлению проектами. Руководство PMBoK. Шестое издание. – М.: Олимп-Бизнес, 2019. – 974 с.
  3. Stepanov D.Yu. Novel planning technique for ERP-systems implementation projects // Communications in Computer and Information Science, vol. 1733. Springer, Cham. https://doi.org/10.1007/978-3-031-23744-7_9.
  4. Шеннон К.Э. Работы по теории информации и кибернетике. – М.: издательство иностранной литературы, 1963. – 829 с.
  5. Першин Д.C. Методы решения творческих задач в проектах внедрения корпоративных информационных систем // Корпоративные информационные системы. – 2018. – №4 – С. 33-43. – URL: https://corpinfosys.ru/archive/issue-4/129-2018-4-methods.

Выходные данные статьи

Першин Д.С. Формирование ресурсного плана в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №3 (19) – С. 38-44. – URL: https://corpinfosys.ru/archive/issue-19/203-2022-19-erpresourceplan.

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

Об авторе

Першин Дмитрий Сергеевич Першин Дмитрий Сергеевич – инженер по технической поддержке корпоративных информационных систем. Принимал участие в проектах по развертыванию и поддержке информационных систем в крупных ИТ-компаниях как государственных, так и коммерческих. Имеет более чем 10-и летний опыт работы с ITSM системами и системами виртуализации. Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №19

  1. Единый налоговый платеж и единый налоговый счет в 2023 году;
  2. Учет договоров с использованием HoneyCode (часть 2);
  3. Контроль качества внедрения и внедренных ERP-систем;
  4. Гибридные методы внедрения корпоративных ERP-систем;
  5. Формирование ресурсного плана в проектах внедрения ERP-систем.