Управление проектом внедрения ERP-системы

Подробности

Опубликовано: 31.03.2023 10:25

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

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

Аннотация: в статье приводятся критичные активности, релевантные проектам внедрения ERP-систем, но не описанные в PMBoK. Отмечена необходимость регулярных встреч с руководителем проекта заказчика. Подчеркнута важность единого места хранения проектных документов, а также раннего предоставления доступа к информационным системам заказчика. Упоминается регламент подготовки протоколов встреч и перенос задач в централизованный список поручений. Для своевременной доставки проекта в срок задаются критерии завершения этапов, подчеркивается необходимость проведения установочных встреч. Описывается важность планирования и трекинга проектных задач, а также регулярных статус созвонов с управляющим комитетом.
Скачать: PDF (статья), PDF (выпуск №21).
Ключевые слова: project manager, RACI матрица, руководитель проекта, kick-off, PDCA-цикл, PMO, стандарт PMBoK, PMBoK управление проектами, свод знаний по управлению проектами, Project management body of knowledge, PMI стандарт управление проектами, PMI PMBoK.

Введение

Наличие всевозможных методологий по управлению проектами внедрения ERP-систем может запутать новичка [1-3]. Ведь проекты внедрения могут вестись согласно каскадной однопроходной модели или многопроходным, к которым относят итерационную и спиралевидные модели [4]. В первом случае говорят о применении PMBoK [1], во втором Agile направленных подходов [2], к примеру: Scrum, Kanban и др. Несмотря на информационный хайп и сложность внедрения корпоративных систем в подавляющем большинстве применяются каскадные способы имплементации. Поэтому понимание сути и особенностей применения PMBoK становится критичным.

Свод знаний по управлению проектами (PMBoK) дает базис понимания того, как управлять любым проектом, в том числе в области ИТ. Поэтому содержательная часть заполняется активностями и задачами, специфичными для корпоративных информационных систем [5]. Достаточно часто руководителями проектов внедрения информационных систем являются выходцы из функциональных консультантов. Последнее не исключает и обратную ситуацию, когда проектный менеджер есть лицо далекое от ERP-систем. Проходя через множество проектов имплементации, консультант обретает те необходимые знания, которые позволяют понять структуру и организацию проекта, однако дефициты в понимании проектного управления все равно могут остаться.

Основная цель статьи состоит в том, чтобы погрузить человека, вышедшего из среды функциональных консультантов ERP, в повестку управления проектами для обеспечения эффективного и качественного решения проектных задач. В рамках этой работы попытаемся ответить на все те критичные вопросы, которые часто остаются вне зоны охвата PMBoK. И начнем мы, пожалуй, с самого главного: кто есть и чем должен заниматься менеджер проекта со стороны подрядчика.

1. Подготовка проекта внедрения ERP-систем

Руководитель проекта (PM, Project Manager) – это лицо, обеспечивающее выполнение проекта в заданные и заранее определенные сроки, объемы и денежные затраты [1]. Входными данными, задающими эти параметры, служат такие основополагающие документы как: план-график проекта, ресурсный план и содержание проекта, представленное RACI-матрицей. Указанные документы не исчерпывают весь объем документации, однако являются ключевыми [6]. Так, план-график проекта очерчивает сроки проекта, этапы выполняемых работ и ключевые задачи. Изначально план готовится на верхнем уровне представления, позже детализируется по мере прохождения стадий. Ресурсный план является производной от плана-графика проекта, иногда и наоборот, показывая при этом весь объем человеческих ресурсов, вовлеченных в проект в указанные сроки и с заданным процентом доступности [7]. И, наконец, RACI-матрица, задающая выходные документы и ключевые наборы задач, выполняемые как исполнителем, так и подрядчиком. Указанные три документа, следуя формуле из [1], имеют закономерность:

Сроки = Содержание / Число человеческих ресурсов,                         (1)

или

План-график = RACI матрица / Ресурсный план.                             (2)

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

С чего следует начать работу по проекту, если вы являетесь PM-ом со стороны исполнителя? Самое важное – это наладить коммуникацию с руководителем проекта от заказчика. Эффективное взаимодействие двух руководителей является залогом успешного запуска ERP-проекта, ведь впереди огромное число задач, выполняемых как заказчиком, так и исполнителем, множество рисков, проблем, непредвиденных ситуаций и др. Опыт показывает, что если между ними устанавливается уважительные взаимоотношения, базирующиеся на совместном желании все сделать в срок и возможности искать компромиссы и обходные пути, то информационная система запустится гораздо легче. Поэтому для начала договоритесь о регулярных встречах или созвонах не реже 3-5 раз в неделю, где будут обсуждаться насущные вопросы.

Стартовыми пунктами для проработки совместно с PM-ом заказчика являются: обеспечение хранения проектных документов, предоставление доступа к информационным системам заказчика (если таковые имеются), регламент подготовки протоколов рабочих встреч и ведение списка поручений. Во всех ERP-проектах готовится множество документов, для хранения которых чаще всего используется совместная веб-платформа, например, SharePoint, Teams и др. Это обеспечивает единое место хранение информации. Структура папок, создаваемых на веб-платформе, обычно соответствует фазам проекта [7]:

• анализ;
• проектирование;
• реализация;
• тестирование;
• переход;
• поддержка продуктивного запуска,

а также ключевым задачам:

• управление проектом (PMO);
• миграция.

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

• комментарий;
• поручение (включая ответственного и сроки выполнения),

где первая категория описывает принятое решение или критичный результат, не требующие дальнейших действий, вторая – конкретную задачу, которую должен выполнить ответственный. Итоги включаются в финальный протокол встречи, готовящийся исполнителем в формате электронного письма или отдельного DOC-файла. Вести протокол в DOC-файле целесообразно лишь в том случае, если вы ожидаете серию его правок и согласований. Как часть регламента по протоколированию встреч можно отметить время, после истечения которого протокол обязательно должен быть отправлен заказчику, как правило, это 8 рабочих часов, а также необходимость переноса всех поручений из протокола в единый список поручений и задач. Рекомендацией может служить то, что в тексте протокола важно указывать срок, до которого вы ожидаете получить возможные правки и замечания к нему от участников встречи.

2. Содержание проекта внедрения ERP систем

Теперь перейдем непосредственно к содержанию проекта. Основные проектные задачи, содержащиеся в RACI-матрице, соответствуют названиям папок из вышеупомянутой структуры, создаваемой на общедоступной веб-платформе. Что нужно сделать, чтобы сотрудники и исполнителя, и заказчика понимали их одинаково? Правильно, устраивать регулярные встречи, где будут объясняться все тонкости выполняемых задач. Их часто называют Kick-off собрания, организуемые перед стартом ключевых активностей. Для них готовятся мультимедийные презентации, описывающие предлагаемый исполнителем подход к выполнению работ. Руководителям проекта нужно заранее согласовать и следовать такому способу доведения информации до всех участников проекта. Типовой проект внедрения ERP-системы включает шесть фаз имплементации. Для официального согласования завершения каждого из этапов, нужно задать четкие критерии, которые должны быть выполнены и исполнителем, и заказчиком.

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

• список работ;
• плановые даты начала и завершения;
• фактические даты начала и завершения;
• плановый и фактический %-ы выполненных работ;
• ответственный;
• статус,

позволяющие оценивать скорость, объем и сроки выполняемых задач, выявлять и в последующим обрабатывать план-фактные отклонения. Что делать в случае, если возникают препятствия в реализации работ в заявленный срок? В первую очередь данную ситуацию необходимо ежедневно контролировать и прикладывать все усилия, чтобы исключить задержек. Во-вторых, заводится, поддерживается и обновляется на ежедневной основе реестр рисков. Его ведение сводится к следующему: любое события, влияющее на сроки и объём проекта фиксируется и оценивается по 2-м параметрам, обычно имеющими диапазон значений от 1 до 10: вероятность и критичность. В виду того, что рисков достаточно много, фиксируется значение ранга риска (произведение вероятности на критичность), по достижении которого риск берется в обработку. Обычно значение ранга устанавливается более 64. Для каждого риска, ранг которого превосходит фиксированный, предлагаются корректирующие действия: сокращение, исключение, передача. В-третьих, если риск не удалось предупредить, он превращается в проблему, о которой потребуется доложить руководству. Здесь также хочется отметить, что один из основных способов ускорения работ – это их ежедневный трекинг с сотрудниками. Мероприятие, к сожалению, весьма трудозатратное, однако, позволяет им ощутить свою ответственность.

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

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

Заключение

Суммируя результаты работы, хочется отметить следующее. Без сомнения, PMBoK и его российские аналоги (ISO серии 21, ГОСТы Р 54, 56 и 58 [9-17]) дают большой объем информации, позволяющей организовывать и выполнять любой проект. ERP-проекты имеют свою специфику, обусловленную теорией корпоративных систем. Важным пунктами для проработки в контексте управления ERP-проектами являются:

• регулярные встречи/созвоны с руководителем проекта от заказчика;
• обеспечение единого места хранения проектных документов;
• предоставление доступа к информационным системам заказчика;
• порядок подготовки протоколов рабочих встреч;
• ведение списка поручений/задач;
• задание критериев для принятия решения о завершении этапов работ;
• Kick-off собрания перед стартом ключевых проектных активностей;
• планирование и ежедневный трекинг проектных задач;
• определение состава участников управляющего комитета, а также проведение встреч с ними. 

Литература 

1. Ширенбек Х., Листер М., Кирмсе Ш. Руководство к своду знаний по управлению проектами. Руководство PMBoK. Шестое издание. – М.: Олимп-Бизнес, 2019. – 974 с.
2. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. – 448 c.
3. Hinde David, PRINCE2 – Study Guide. Sybex, 2017. – 352 p.
4. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
5. Степанов Д.Ю. Теория корпоративных информационных систем и ее уточнение // Корпоративные информационные системы. – 2022. – №4 (20) – С. 7-16. – URL: https://corpinfosys.ru/archive/issue-20/205-2022-20-theorycis.
6. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62. – URL: https://stepanovd.com/science/29-article-2014-1-docflows.
7. Першин Д.С. Формирование ресурсного плана в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №3 (19) – С. 38-44. – URL: https://corpinfosys.ru/archive/issue-19/203-2022-19-erpresourceplan.
8. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238. – URL: https://stepanovd.com/science/31-article-2015-2-erpthpr.
9. ГОСТ Р ИСО 21500-2014. Руководство по проектному менеджменту.
10. ГОСТ Р ИСО 21504-2016. Управление проектами, программами и портфелем проектов. Руководство по управлению портфелем проектов.
11. ГОСТ Р 56715.1-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения.
12. ГОСТ Р 56715.2-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель.
13. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.
14. ГОСТ Р 54870-2011. Проектный менеджмент. Требования к управлению портфелем проектов.
15. ГОСТ Р 54871-2011. Проектный менеджмент. Требования к управлению про-граммой.
16. ГОСТ Р 58184. Система менеджмента проектной деятельности. Основные положения.
17. ГОСТ Р 58305. Система менеджмента проектной деятельности. Проектный офис.

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

Степанов Д.Ю. Управление проектом внедрения ERP-системы // Корпоративные информационные системы. – 2023. – №1 (21). – С. 18-25. – URL: https://corpinfosys.ru/archive/issue-21/216-2023-21-projectmanagementerp.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

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

1. Постоянные и переменные затраты на внедрение и поддержку ERP-систем;
2. Управление проектом внедрения ERP-системы;
3. Разработка типовой структуры КИС в муниципальном управлении;
4. Обзор российского ПО класса MES, ERP2 и BI (часть 2);
5. Методология управления проектами PRINCE2.