Метод формирования ресурсного плана в проектах внедрения ERP-систем на основе бенчмаркинга и оценщика

Подробности

Опубликовано: 01.07.2018 16:54

Автор: Степанов Дмитрий Юрьевич

Просмотров: 3086

Аннотация: в статье рассматривается способ построения ресурсного плана для проектов внедрения ERP-систем, отличающийся простотой использования и быстротой получения результатов, что позволяет гибко эмулировать различные ситуации. Метод ориентирован на проекты имплементации корпоративных систем, содержанием которых служит программная доработка решения. Функционирование метода предполагает применение механизма оценщика, представляющего собой экспертную оценку трудозатрат подготовки и разработки программ по паре параметров «тип – сложность». Далее применяется бенчмаркинг, задающий продолжительность фаз проекта в процентном выражении. Используя рассчитанные трудозатраты, определяющие этапы проектирования и реализации, а также результаты бенчмаркинга, ведется расчет сроков всех фаз. Применение принципа пирамиды, позволяет распределить трудозатраты для оставшихся этапов проекта, принимая во внимание такие вехи, как: анализ, интеграционное тестирование и переход.
Скачать: PDF (статья).
Ключевые слова: ресурсный план, ресурсное планирование проекта, планирование ресурсов проекта, управление ресурсами проекта, оценка трудозатрат, трудоемкость работ, оценка проекта, RICEF, человеко-день, иерархическая структура работ, метод критического пути, метод критической цепи, свод знаний по управлению проектами, сроки ERP-проекта, бенчмаркинг, формирование команды проекта, человеческие ресурсы проекта, трудовые ресурсы.

Введение

Если вы недавно решили для себя, что карьера консультанта по внедрению ERP-систем, не важно Российского, немецкого или американского производства, именно то, что вам нужно, может сложиться ошибочное мнение, что лишь ваши технические навыки играют роль и вы непременно должны уметь программировать. Это далеко не так. Несмотря на то, что имплементация корпоративных информационных систем действительно представляется нетривиальной задачей, началу проекта предшествует достаточно большой объем работ, имеющий косвенное отношение к технике. Можно сказать, что с точки зрения проектного менеджмента старт проекта внедрения системы ERP, это чуть ли не завершающий и весьма прогнозируемый шаг. Типовой проект имплементации корпоративной системы включает этапы анализа, проектирования, разработки, тестирования, перехода, а также поддержки программного решения [1]. Однако новички по незнанию упускают тот факт, что этапу анализа проекта предшествуют активности по формированию технического задания, обосновывающего необходимость внедрения ERP-системы, а также ключевые требования, предъявляемые к ней. Далее следуют задачи формирования технико-коммерческого предложения, объясняющего, как требования будут реализовываться, из каких этапов будет состоять проект, каковы продолжительности этапов и число необходимых человеческих ресурсов [2]. В случае успешных продаж заключается контракт на имплементацию системы ERP, после чего идут как раз те шесть этапов проекта, о которых рассказано выше.

Ключевым вопросом подготовки технико-коммерческого предложения является составление ресурсного плана проекта, задающего требуемое количество человеческих ресурсов. Объем человеческих ресурсов тесно связан со сроками проекта, а также составом ожидаемых работ, что можно задать следующей упрощенной формулой:

СрокиПроекта = СуммарныйОбъемВыполняемыхРабот / ЧислоЧеловеческихРесурсов.           (1)

Как легко увидеть из (1), составление ресурсного плана следует вести согласованно с содержанием проекта, ведь изменение любого из них приводит к корректировки продолжительности. Возникает вопрос, а как же строить ресурсный план? Если обратиться к руководству по управлению проектами PMBoK [3], то можно узнать о методах критического пути и цепи, позволяющих строить логическую структуру выполняемых работ, определять их продолжительность, присваивать работам человеческие ресурсы и задавать буферы. По существу, описывается расчет объема работ «снизу вверх», где итоговое значение представляется суммой множества отдельных подзадач. Зная продолжительность и объем работ в (1), определяется необходимое число ресурсов, после чего проводится их выравнивание и сглаживание по проектным фазам. Оба метода хороши и не требуют глубоких технических знаний, однако они весьма трудозатраты и уж точно не гибкие. В работе [4], посвященной Agile-планированию проектов, говорится о том, что созданный план проекта не представляет собой большой ценности, ценность состоит в его ежедневной адаптации под сложившиеся реалии. С этим утверждением нельзя не согласиться: метод должен выполнять расчеты быстро, чтобы обеспечить моделирование множества возможных ситуаций. Невзирая на то, что способы, описанные как в [3], так и прочих схожих по содержанию источниках [5-7], задают общее понимание механизма построения ресурсного плана, на практике их применение весьма трудоемко и проблематично. Цель работы состоит в предложении более быстрых методов формирования ресурсного плана для ERP-проектов. Для реализации указанной цели будут рассмотрены следующие задачи:

• обзор механизма оценки трудозатрат разработок;
• бенчмаркинг этапов проекта внедрения ERP-системы;
• быстрое построение ресурсного плана ERP-проекта.

1. Оценка трудозатрат разработок

Обратимся к формуле (1), из которой легко сделать вывод о том, что для нахождения числа человеческих ресурсов, необходимо знать сроки проекта и объем выполняемых работ. Перефразируем, для формирования ресурсного плана требуется вычислить продолжительность, а также трудозатраты каждого из этапов проекта. Много раньше проекта внедрения ERP-системы заказчик предоставляет потенциальному исполнителю исходное техническое задание, в котором задан перечень начальных пользовательских требований, предъявляемых к будущей информационной системе. Для подготовки предварительного плана ERP-проекта каждое из требований анализируется экспертами исполнителя и относится либо к категории Fit, либо Gap [8]. Требования из Fit области, считаются уже реализованными по умолчанию в базовом ERP-комплекте и не требуют дополнительных действий, Gap – сигнал о необходимости доработки или кастомизации информационной системы.

Рис. 1. Пример фрагмента оценщика разработок

Далее для каждого Gap-требования определяется тип разработки, а также сложность. Задание типов раз-работки подразумевает применение RICEF классификации, где: R – разработки вида отчет (Report), I – интерфейс (Interface), С – программа обработки данных (Conversion), E – расширение стандартного функционала (Enhancement) и F – печатная форма (Form). Сложность характеризуется такими значениями, как: низкая, сред-няя, высокая, критическая [9]. Таким образом, каждому требованию из области функционального дефицита устанавливается соответствие двух параметров «тип разработки – сложность». Для всех возможных значений этих пар компания исполнителя имеет заданные экспертным путем значения трудозатрат, необходимых для подготовки проектной документации и выполнения разработок. Матрица, ставящая соответствие типу разработки и сложности плановые значения трудозатрат подготовки технической документации, а также реализации программной разработки, называют оценщиком (рис. 1).

2. Бенчмаркинг этапов проекта внедрения ERP-систем

Применение оценщика позволяет рассчитать объем работ на этапах проектирования и реализации. Однако их продолжительность по-прежнему остается неизвестной. Рассмотрим более детально все этапы проекта. Распространенной точкой зрения является то, что сумма фаз проектирования и разработки составляет не менее 50% от продолжительности всего ERP-проекта. Причем в оценку не включается этап поддержки, так как его длительность является согласованной с заказчиком константной величиной. Тогда применяя механизм бенчмаркинга, можно рассчитать длительность всех этапов проекта в процентном выражении (рис. 2).

Рис. 2. Бенчмаркинг этапов внедрения ERP-системы в процентном выражении, а также примерная продолжительность фаз типового проекта

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

3. Построение ресурсного плана

Зная трудозатраты, а также предварительные длительности этапов ERP-проекта, возможно предложить алгоритм построения ресурсного плана. Для наглядности воспользуемся вычисленными с помощью оценщика трудозатратами этапов проектирования и разработок, равными 113 и 163 человеко-дням соответственно. Тогда процедура построения плана будет выглядеть следующим образом:

• зададим предполагаемую продолжительность этапа проектирования, принимая во внимание данные рис. 2. Наложим на календарную сетку трудозатраты функциональных консультантов. Если сумма трудозатрат превосходит длительность фазы, добавим дополнительный человеческий ресурс. Так как подбор числа ресурсов зависит от продолжительности этапа, руководствуемся правилом, что количество человеческих ресурсов должно быть минимальным. Подбирая оптимальное соотношение длительности фазы и распределения ресурсов, находим их итоговые значения;
• определив длительность этапа проектирования, равного в нашем примере 36 рабочим дням, ведется расчет срока всего проекта, применяя процентное соотношение из результатов бенчмаркинга (рис. 2);
• нахождение числа разработчиков ведется аналогично процедуре, описанной на шаге 1, с тем лишь исключением, что сроки этапа реализации уже заданы на шаге 2;
• распределим найденное число консультантов и разработчиков по оставшимся фазам проекта, исключая этап анализа для вторых. Таким образом получаем предварительный ресурсный план, содержащий итоговый объем работ в 1038 человеко-дней (рис. 3).

Рис. 3. Пример построения предварительного ресурсного плана

Пример плана на рис. 3 кажется избыточным, в частности: участие не всех функциональных консультантов и разработчиков необходимо на всех этапах проекта. Воспользуемся утверждением, говорящим о том, что максимальное число ресурсов требуется на самых критичных этапах проекта. Для нас это фазы проектирования, разработки и тестирования. Предложим формулу (2):

, (2)

которая позволит сократить количество человек в функциональных группах, принимая во внимание число задействованных ресурсов предыдущего или последующего этапов. Оценка носит эмпирический характер, опираясь на такие активности проекта, как: анализ, интеграционное тестирование и подготовка к использованию нового решения. Применим (2) для уточнения числа консультантов на этапе анализа относительно фазы проектирования, а также поддержки относительно перехода. Выполним это же упражнение для разработчиков на фазах приемочного тестирования, перехода и поддержки относительно этапа реализации. Как результат объем трудозатрат сократился на 15% и составил 887 человеко-дней (рис. 4).

Рис. 4. Пример финального ресурсного плана

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

Заключение

В статье предлагается способ, позволяющий выполнять быстрое построение ресурсного плана ERP-проекта, используя в качестве входных параметров плановые трудозатраты для подготовки документации на этапе дизайна, а также разработки фазы реализации. Метод обеспечивает создание плана человеческих ресурсов от даты начала проекта. Для формирования плана от даты завершения проекта, необходимо сокращать длительность этапа проектирования и увеличивать число его человеческих ресурсов. При этом стоит принимать во внимание, чем короче продолжительность фазы, тем выше риск неуспеха выполнения задач, не взирая на увеличенное количество ресурсов [10]. Дальнейшее развитие метода состоит в уточнении алгоритма сокращения ресурсов (2), а также во включении в объем проекта активностей, не относящихся к проектированию и разработке. 

Список литературы

1. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238.
2. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. 164 с.
3. Ширенбек Х., Листер М., Кирмсе Ш. Руководство к своду знаний по управлению проектами. Руководство PMBoK. Шестое издание. – М.: Олимп-Бизнес, 2019. 726 с.
4. Кон М. Agile: оценка и планирование проектов. М.: Альпина Паблишер, 2019. 418 с.
5. Полковников А.В., Дубовик М.Ф. Управление проектами. Полный курс MBA. М.: Олимп-бизнес, 2018. 552 с.
6. Хелдман К. Управление проектами. Быстрый старт. М.: ДМК-Пресс, 2017. 460 с.
7. Цителадзе Д.Д. Управление проектами. М.: Инфра-М, 2022, 361 с.
8. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
9. Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. – 2019. – №3(7). – c.29-52.
10. Лодон Дж., Лодон К. Управление информационными системами. / Пер. с англ. под ред. Трутнева Д.Р. - СПб.: Питер, 2005. – 912 с.

Выходные данные

Степанов Д.Ю. Метод формирования ресурсного плана в проектах внедрения ERP-систем на основе бенчмаркинга и оценщика // Высокопроизводительные вычислительные системы и технологии. – 2022. – Т.4, № 1. – c.1-6. – URL: http://stepanovd.com/science/article/135-2022-1-resourceplan.