Создание плана развертывания решения EPM
Эта статья является частью нашей коллекции "Из окопов". В ней описывается создание плана развертывания корпоративного управления проектами (EPM). Данный документ, предназначенный для организаций среднего размера (несколько сотен пользователей EPM), содержит сведения об этапах развертывания, сроках выполнения этапов и основных задачах плана развертывания. Кроме того, в документе приведены факторы, которые могут повлиять на сроки выполнения каждого этапа.
Чтобы скачать Word версию этой статьи, см. статью Создание плана развертывания EPM.
Дополнительные статьи см. в технических документах "Из окопов".
Создание плана развертывания решения EPM
"Можете ли вы помочь нам установить систему EPM и запустить ее в течение нескольких дней?" — один из самых распространенных запросов, которые получают фирмы по развертыванию EPM. И независимо от размера организации, короткий ответ, к сожалению, "Нет". Проблема не в технологии; Это ряд вопросов политики, процессов, процедур и практики, которые могут привести к далеко идущим организационным изменениям.
Давайте посмотрим, что должен включать план развертывания EPM и как можно создать собственный. Я определил основные моменты и даже поставил в расчетное время для того, сколько времени может занять каждый этап в организации среднего размера с несколькими сотнями пользователей системы EPM. Прежде чем каждый раз отклонять оценку как слишком короткую или слишком длинную, подумайте о том, что необходимо сделать в конкретной организации, чтобы выполнить этот раздел. Продолжительность не является оценками работы, это календарные оценки, поэтому имейте в виду, сколько времени требуется для получения определенных типов людей, собранных для того типа работы, который вам понадобится.
1. Создание команды по развертыванию системы EPM
Если у нас нет команды по проекту, то наш проект не зайдет далеко. Несколько человек должны быть собраны, чтобы вывести этот проект с этапа идеи до производства. Имея в виду уже общий план, необходимо думать о людях, которые будут работать с проектом до тех пор, как пару лет.
Основные шаги на этом первом этапе:
Определение ключевых заинтересованных лиц
До начала проекта часто есть один ключевой заинтересованный сторон. Как правило, это кто-то на уровне исполнительной власти, который чувствует боль от того, что не имеет такого рода системы. Это отличное начало, но этого не будет почти достаточно, чтобы привести такой проект к реализации. Определение бизнес-владельца системы имеет решающее значение для успешного развертывания EPM и должно быть выполнено почти немедленно. Владельцем бизнеса будет человек, который использует преимущества завершенной системы и видит ценность в прохождении того, что потребуется для ее завершения. Также может быть один или несколько исполнительных спонсоров. Исполнительными спонсорами могут быть сотрудники уровня управления, которые в некоторой степени используются для конечных результатов, но они также могут быть людьми, которые будут работать над проектом до его завершения, а затем двигаться дальше, не инвестируя в окончательную работу среды EPM. Вы можете жить без исполнительного спонсора. Вы не можете жить без владельца бизнеса.
Определение внутренних ресурсов экспертных знаний
Определив, кто является владельцем бизнеса и, возможно, исполнительными спонсорами, команда проекта должна определить, какие внутренние знания необходимы и доступны для продвижения проекта вперед. Часто мы обнаруживаем отсутствие опыта в конкретной технологии, такой как текущая версия программного обеспечения EPM, но это не единственный необходимый нам опыт. Важное значение будут иметь внутренние знания о процессах, практиках, процедурах, ролях и обязанностях организации, а также о том, где могут находиться данные для управления процессом.
Привлечение внешних экспертов (при необходимости)
Часто определяется, что в команде проектов есть пробел в знаниях или навыках, чтобы перейти от управления проектами, не относящихся к предприятиям, к управлению корпоративными проектами. Если это так, то нет замены для поиска кого-то с ноу-хау. В какой бы степени внутренние ресурсы не были доступны, они должны быть задействованы извне. Эти люди могут быть привлечены в рамках контракта на консалтинг или аутсорсинг или наняты для долгосрочного использования в среде, которую они помогут развивать. Обучение такому опыту изнутри редко бывает успешным. Наиболее распространенной проблемой, которую мы видим в этой области, является выяснение того, что внутренние ресурсы были возложены на ответственность, но не обладают знаниями или имеют только ограниченные знания. "Я использовал программное обеспечение EPM один раз, и теперь меня просят развернуть его", крик мы слышим слишком часто.
Размер вашей команды будет зависеть от того, насколько широко область в конечном итоге станет проект. Нередки случаи, когда некоторые люди с проектом в течение нескольких месяцев заменяются другими по мере изменения проекта. Авторитет группы и поддержка руководства также имеют решающее значение для установления в настоящее время.
О, и я должен это сказать? Рассматривайте этот проект как проект! Удивительно, как бы это ни звучало, развертывания EPM являются наиболее вероятным проектом в организации, который будет развернут без каких-либо элементов, которые вы бы вложили в любой другой план развертывания (что-то о детях обувщика, идущих босиком). Таким образом, сделайте график проекта, бюджет, устав, выделите достаточный объем ресурсов и т. д.
Время для выполнения этой задачи: четыре недели.
2. Определение бизнес-целей
Хорошо, у нас есть команда вместе. Пора приступить к работе! Теперь нам нужно определить область проекта, разбить этот область на этапы, если он большой, а затем создать план работы.
Вот что нам нужно сделать на этом этапе:
Семинары для руководителей и заинтересованных лиц
Нет никакого способа обойти это. Вся цель создания среды EPM заключается в том, чтобы позволить руководству и конечным пользователям принимать бизнес-решения. Таким образом, соответствующий руководящий персонал должен будет потратить некоторое время в начале процесса, чтобы помочь определить, какие решения будут приниматься с помощью системы. Я уже писал о том, как проводить такие семинары в прошлом (см . статью Как покупатель решений: технический документ), но то, как они делают, менее важно, чем то, что они сделаны.
Это возможность для команды развертывания получить две другие очень, очень важные вещи, пока они имеют внимание руководства. Во-первых, приверженность руководства процессу, усилия и конечные выгоды. Во-вторых (и гораздо более важно), управляемые ожидания управления. Наиболее распространенное ожидание руководства заключается в том, что это может быть достигнуто в течение нескольких дней или нескольких коротких недель. Когда они понимают влияние того, что происходит, поддержка управления может испаряется. Лучше, чтобы это произошло немедленно, чем начать работу с тем, что не может быть доставлено с недостаточным временем или ресурсами.
Результаты этих семинаров (да, это может занять несколько) будут бизнес-цели, которые будут составлять область и в конечном итоге определять график.
Определение влияния роли управления
После согласования бизнес-целей руководством необходимо будет провести одно или два заседания, на которых будет определяться влияние на роли и обязанности руководства. Распространенный пример часто появляется с планированием емкости ресурсов. В высокотехнологичных фирмах планирование ресурсов почти всегда является запросом управления системой EPM, но кто должен получить полномочия в этом процессе для распределения ресурсов, управления конфликтами и определения приоритетов работы людей в разных отделах? На этом этапе вы не сможете решить эти проблемы, так как у вас нет определенного процесса, но определение того, кто будет затронут в наборе руководителей, важно здесь, чтобы вы могли вернуться к кругу, чтобы включить их в процесс, когда придет время.
Определение приоритетов бизнес-целей и создание главного плана развертывания
Почти наверняка план должен разбиться на этапы. Практически при каждом развертывании EPM желание управления преимуществами, которые должна предоставить система EPM, огромны. Определение приоритетов в отношении того, какие цели следует искать в первую очередь, является важным элементом успеха на данном этапе. Получите первые две или, возможно, три цели, поставленные в фазу, и подтолкнуть все остальное вниз по течению. Каждый этап должен предоставлять рабочую рабочую среду EPM, которая сама по себе ценна.
Установка вех и метрик
Мы руководители проектов, не так ли?! Давайте получим некоторые вехи в нашем проекте и зафиксируем некоторые измеримые метрики. При развертывании любой корпоративной системы важной частью процесса является обеспечение ее постоянного выполнения.
Мы должны иметь достаточно информации сейчас, чтобы разработать наш общий график с подробными сведениями для первого этапа.
Время для этой работы: четыре недели
Этап 1
Для каждого этапа будут выполняться некоторые задачи, которые необходимо повторить. Шаги 3–9 являются частью одного этапа.
3. Процессы инвентаризации
Прежде чем приблизиться к инструментам, необходимо определить, какие процессы в конечном итоге необходимо автоматизировать на этом этапе.
Какие процессы существуют и могут быть приняты?
Для начала мы рассмотрим, какие процессы, методики и процедуры уже существуют в организации для бизнес-целей, определенных на этом этапе, и определим, какие из них можно внедрить в новой среде EPM. Существует двустороннее преимущество поиска существующих процессов, которые могут быть адаптированы практически без работы. Во-первых, они уже созданы и известны пользователям. Во-вторых, их принятие делает другом человека, который их создал. Теперь их можно назвать экспертами по предмету в этом процессе, что упрощает развертывание.
Какие процессы необходимо спроектировать
Мы никогда не найдем все необходимые процессы, методики и процедуры, но нам нужно определить, чего не хватает. Это может быть сложнее, чем найти уже существующие процессы. Вы ищете то, чего там нет, и это принимает опытный глаз.
Семинары по обработке доски
Для тех процессов, для которых требуется адаптировать работу, или для процессов, которые необходимо создать с нуля, вам потребуется провести несколько семинаров с доской. Прогулка по процессу и все его последствия лучше всего сделать с людьми, которые будут жить его, как только это будет сделано. Задокументируйте все.
Устранение затронутых ролей управления
Помните, когда мы определили, какие руководители или руководители могут быть причастны к изменениям, которые произойдут? Пора перезвонить. Для любого из новых процессов, влияющих на роли, полномочия, иерархию или существующие обязанности, необходимо организовать собрания для их разрешения.
Конечным результатом этого является проект руководства по процессу.
Время выполнения упражнения по процессам: четыре недели.
4. Внедрение, адаптация и проектирование процессов
Проверка, адаптация и принятие разработанных процессов
Не все будут участвовать в каждом упражнении, которое было выполнено в последнем наборе задач. Таким образом, важно, чтобы проект нового руководства по процессу был опубликован для заинтересованных лиц, руководителей и затронутых сторон. В этом руководстве довольно часто проходит несколько проверок и даже для дополнительных семинаров, которые должны быть запланированы для устранения конфликтов в процессах.
Результатом этого является завершенный и принятый документ процесса. Не обманывайте себя, "принятый" аспект может занять несколько раундов и даже потребовать вмешательства руководителей с самого высокого уровня, прежде чем он будет завершен, но без принятого процесса автоматизировать нечего. Хорошая новость заключается в том, что даже если процесс развертывания остановился здесь, это уже имеет большое значение. Неизбежно, что те, кто работает в этих процессах внутри себя, видят в своей организации вещи, которые они никогда не рассматривали. Они будут более эффективными, в результате чего начинается почти сразу.
Время выполнения руководства по завершению процесса: восемь недель
5. Оценка и выбор средств EPM
Подготовка документов с инструкциями по проблеме для поставщиков
Если вы читали другие статьи, которые я сделал, вы знаете, что я твердо верю в то, чтобы дать потенциальным поставщикам описание ваших проблем EPM и позволить им рассказать вам, как они будут их решать. В конце концов, они говорят, что они в бизнесе решений? Отлично, пусть они разрабатывают свое решение. Это немного сложнее, чем создать электронную таблицу со всеми нужными функциями, но это важно.
Запрашивать ответы поставщика
Никогда не делайте одного. Возможно, вы уже знаете, кто ваш предпочтительный поставщик, но даже если вы считаете, что это правильный, получите что-то для сравнения с. Ни один из двух поставщиков не будет пытаться решить вашу проблему таким же образом, поэтому будьте готовы быть удивлены и держать открытым умом.
Короткий список
Даже если вы ищете один продукт, но несколько реализаторов, получите доступ к тому, с кем вы хотели бы встретиться лично.
Презентации поставщиков и разработчиков
Ах, демонстрационный день. Есть много вещей, которые имеют значение, чтобы иметь от просмотра на демонстрацию, но попасть в вспышку это не один из них. Демонстрации продаж тщательно организованы всеми поставщиками. Если вы особенно рады представлению, отчету или панели мониторинга, спросите, в частности, "Сколько времени потребуется для разработки этого точного представления?"
Выбор и приобретение инструментов
Ладно, пора сделать крупную покупку. Я знаю, вы думали, что это было отправной точкой, еще в начале этой статьи. Ну, не беспокойтесь. Мы, наконец, здесь. Сделайте свой выбор системы EPM и получите этот заказ на покупку на своем пути!
Конечным результатом этого этапа является блестящий новый продукт EPM, сидящий на вашем столе.
Время выполнения этого этапа: восемь недель.
6. Проектирование и настройка службы автоматизации
Применение конструктора процесса к выбранному средству EPM
Теперь, когда мы знаем, что это за средство, можно приступить к созданию системных проектных документов, которые начинаются с документа процесса и заканчиваются функциональными спецификациями. Вероятно, нам потребуется установить экземпляр разработки новой системы EPM, чтобы мы могли протестировать или проверить определенные условия проектирования. Впервые на борту требуется системный эксперт по настройке фактической системы.
Разработка и внедрение стандартов
Существует множество стандартов, которые необходимо будет установить. Каждый из этих стандартов влияет на архитектуру и проектирование системы. Например, календарь часто упускается из виду. Будет ли у нас один календарь или несколько? Будут ли у нас календари ресурсов? Кто будет иметь полномочия, чтобы изменить их? Знаем ли мы влияние на расписание и ход выполнения изменения календаря ресурсов? И так далее... Ниже приведены некоторые элементы нашей системы EPM, для которых потребуются стандарты:
Календари
Соглашения об именовании
Иерархия ресурсов
Стандарты загрузки ресурсов для проектных и непроектных работ
Тарифы и стандарты затрат
Роли и обязанности.
Структуры утверждения
Иерархии проектов и задач
WBS и другие структуры кодирования
Управление документами
Шаблоны коммуникации
Шаблоны проектов
Нам также потребуется другой дизайн и даже возможное кодирование для элементов, которые вышли из наших бизнес-целей этапа 1. Некоторые из элементов, которые, возможно, необходимо рассмотреть:
Разработка и реализация пользовательского кода
Проектирование и реализация панели мониторинга
Проектирование и создание ссылок на внешние системы
Проектирование и создание рабочего процесса
Проектирование и реализация отчетов
Разработка и создание обучения средств EPM
Проверка оформления со всеми затронутыми сторонами
Результатом является инструмент EPM, который готов быть вывезен для поездки. Он должен иметь всю конфигурацию, необходимую для перемещения в рабочую среду.
Время, необходимое для этого этапа, может сильно отличаться в зависимости от того, сколько пользовательских работ требовалось, но мы скажем, двенадцать недель, учитывая, что мы ограничились первым этапом.
7. Пилотное средство EPM
Теперь, когда наша система готова к работе, мы должны определить пилотную группу и заставить ее работать над ней.
Этап 1. Установка, настройка и перенос данных
Нам потребуется установить только что настроенную систему в пилотном экземпляре (а не в экземпляре разработки). Мы будем продолжать использовать его для будущих этапов и в качестве системы поддержки и обучения. Нам также потребуется обновить конфигурацию в соответствии с нашим экземпляром разработки и перенести пилотные проекты из того, что они сейчас есть в нашей новой системе.
Обучение
Обучение — это плохой шаг развертывания проекта. Это часто забывается в плане развертывания. Убедитесь, что наши пилоты прошли обучение, необходимое для правильного использования системы.
Запуск активных проектов
Теперь управляйте этими пилотными проектами на основе процессов, методик, процедур и автоматизации, на определение которых вы потратили столько времени. В пилотном проекте должно быть расписание, которое часто ориентируется на продолжительное время выполнения этих проектов.
Извлеченные уроки и документирование
После завершения пилотного проекта пришло время повторно собрать и посмотреть, как созданное решение решило задачи, которые были заданы для него. Если необходимо внести корректировки, исправления или основные изменения, пришло время.
Время для завершения пилотного проекта и проверки: Двенадцать недель.
8. Развертывание этапа 1 в рабочей среде
Go-live
Время. Развертывание новой системы для соответствующих пользователей и перенос соответствующих данных. Не забывайте о обучении, поддержке и последующем выполнении по мере того, как система будет жить.
Время развертывания в значительной степени зависит от общего числа пользователей: четыре недели.
9. Просмотр и адаптация главного плана развертывания
Просмотр и корректировка плана master в рамках подготовки к следующему этапу план master, вероятно, не просматривался в течение нескольких месяцев. Время, чтобы пылить его и посмотреть, что было первоначально запланировано на второй этап. Это неизбежно, что глаза, которые смотрят на следующий этап, будут видеть вещи по-другому. В конце концов, они теперь имеют весь опыт первого этапа.
Время завершения этого этапа: две недели.
10. Этап 2. Снова выполните шаги 3–9
Мы завершили только первый этап, и при просмотре будущих этапов вам потребуется переработать шаги 3–9 (за исключением шага 5). Помните, что каждый этап должен привести к созданию рабочей среды EPM, которая оставляет организацию более эффективной, чем раньше.
Вы подсчитывали продолжительность каждого из этапов первого этапа? Он суммирует до 58 недель. Ниже приведено расписание сводных шагов, определенных выше.
Теперь каждая организация отличается. Существует множество факторов, влияющих на общую продолжительность проекта. Наиболее важным из них является степень зрелости существующих процессов управления корпоративными проектами. Далее следует размер организации и ее сложность. Очевидно, что проще развернуть систему EPM в организации, которая находится в одном здании, чем для организации, которая распределена по многочисленным подразделениям, офисам, городам и даже странам и регионам.
В каждом развертывании расписание будет выглядеть по-разному и не всегда короче. Практически всегда требуется создать расписание, которое может быть выполнено в течение нескольких дней или даже недель, но важно, чтобы для успешного развертывания рассматривалось не только установка программного обеспечения EPM.
Об авторе
Крис Вандерслуис (Chris Vandersluis) — президент и основатель канадской компании HMS Software( Монреаль), сертифицированного партнера Майкрософт. Он имеет степень экономики в Университете Макгилла и более 30 лет опыта в автоматизации систем управления проектами. Он является давним членом Института управления проектами (PMI) и помог основать отделения Монреаля, Торонто и Квебека группы пользователей проекта (MPUG). Публикации, для которых Крис написал, включают Fortune, Heavy Construction News, Computing Canada magazine, PMNetwork PMI, и он является регулярным обозревателем Project Times. Он преподает расширенное управление проектами в Университете Макгилла и часто выступает в функциях ассоциации по управлению проектами в Северная Америка и по всему миру. HMS Software является издателем системы хронометрирования, ориентированной на проекты TimeControl, и с 1995 года является партнером по решению проектов Майкрософт.
С Крисом Вандерслуисом можно связаться по электронной почте по адресу: chris.vandersluis@hms.ca
Если вы хотите прочитать дополнительные статьи Криса Вандерслуиса, связанные с EPM, см. на сайте руководства по EPM HMS (https://www.epmguidance.com/?page_id=39).