Владельцы процессов ITIL и менеджеры проектов часто живут в параллельных мирах и используют разные термины для обозначения одних и тех же объектов. Интеграция проектного управления и сервис-менеджмента может существенно повысить полезность и того, и другого. Об этом рассуждают в своей статье на ITSMWatch Ed Rivard и Kristy Smith из компании Forsythe
Как-то даже страшновато комментировать эту тему после истории с «еретическими мыслями о жизненном цикле услуг» (http://www.itsmportal.com/columns/some-heretical-opinions-itil-service-lifecycle), когда мои мелкие придирки к ITIL сначала вызвали оживленную дискуссию, а потом пришел лесник Ян ван Бон и всех разогнал: «Я, – говорит, – еще три года назад все об этом написал.» И дальше высказался в том смысле, что Земля на самом деле – «шар, пребывающий в пустоте», а наши споры о количестве слонов и породе черепахи под земным диском – антинаучные глупости.
И тем не менее:
Тема совмещения управления проектами и управления услугами давно уже обсуждается – в открытых дискуссиях, в статьях и на курсах. Вкратце все эти обсуждения, по-моему, сводятся к следующему:
1. Инфраструктура ИТ-услуг постоянно меняется. Изменения бывают большие и маленькие. «Большие» и «маленькие» – это совокупность таких факторов как влияние на бизнес, затраты на проведение изменения, цена ошибки при проведении изменения, влияние на компоненты инфраструктуры и количество ресурсов ИТ, необходимых для проведения изменения.
2. Для того, чтобы обеспечить уверенность в том, что изменения дают запланированный результат и делают это за разумные деньги, а связанные с изменениями риски контролируются и сведены к приемлемому уровню, необходимо обеспечить определенный (в зависимости от того, «большие» они или «маленькие») уровень контроля при их подготовке и проведении. Стоимость контроля в каждом случае должна быть ниже цены рисков, связанных с его отсутствием.
3. Основным средством такого контроля является процесс управления изменениями. В рамках этого процесса могут быть задействованы различные инструменты управления и контроля, соответствующие масштабу и содержанию проводимых изменений.
4. Для «очень больших» изменений может оказаться оправданным применение более сложной и дорогой системы инструментов управления и контроля, повышающей степень уверенности в результативности и рациональности проводимых преобразований. Такая система называется «методология управления проектами», поскольку сами «очень большие изменения» принято называть проектами.
5. Методология управления проектами может применяться как при внедрении новых/изменямых услуг в эксплуатацию, так и при проведении «очень больших» изменений в операционной среде, не связанных с таким внедрением нового.
Таким образом, управление проектами (как методология: PMBOK, PRINCE2, …) – не более чем специализированная система инструментов управление и контроля, предназначенная для управления изменениями в тех случаях, когда ее применение оправдано с учетом связанных с ним расходов и рисков.
А управление проектами как функция (проектный офис, например) – совокупность ресурсов, методов и знаний, привлекаемых к управлению такими изменениями.
То есть нет такой проблемы как «связь управления проектами и управления услугами». И то, и другое – часть корпоративной системы контролей, обеспечивающих эффективное управление ИТ. И то, и другое следует использовать уместно и ответственно. Решать, кто из них главный, или искусственно их разделять – не надо.