Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Схватка двух ёкодзун: ITIL vs PMBoK

Всем привет, я Роман Резников, работаю в Project Management Office компании SoftServe. Одно из направлений моей работы — развивать компетенцию Service Manager и подходы в компании по работе с сервисными проектами (SLA-проекты, support, etc.). В этой статье я сделаю краткий сравнительный обзор двух источников best practices. Это позволит вам сориентироваться, что стоит добавить в свой арсенал PM’а.

В чем проблема

Для большинства проектных менеджеров (даже Agile) классическим источником best practices для ведения проектов является PMBoK. Те, кто хоть раз заглядывал в PMBoK, помнят, что проект ограничен по времени, уникален, имеет четкий скоуп. Но если посмотреть на большинство проектов в ІТ, особенно в сфере ІТ-аутсорсинга — чаще всего это T&M или Dedicated Team, — то такая форма кооперации больше похожа на сервис. По сути, мы предоставляем клиенту услугу, сервис разработки программного обеспечения, а настоящим проектом можно считать, скорее, Fixed-Price. Так что если у вас с клиентом контракт, по которому вы предоставляете ресурсы, а не конкретный результат, смело можно считать его сервисом. Не то чтобы PMBoK в таком случае вам не подходил, но это означает, что стоит обратить внимание и пристально изучить еще один источник знаний — ITIL (особенно такие разделы, как Service Level Management, Capacity/Availability Management, Request Fulfilment и Incident Management).

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

Как раз такой вид деятельности покрывают практики из ITIL. ITIL (IT Infrastructure Library) — это наиболее широко используемый и общепринятый подход к управлению ІТ-услугами во всем мире. ITIL был разработан относительно независимо от управления проектами, воплощает несколько ценных идей управления и включает проверенные процедуры, которые могут быть полезны также для практики управления проектами.

Сравнение процессов

PMBoK представляет best practices в виде 49 процессов, каждый из которых состоит из набора входов (Inputs), выходов (Outputs), инструментов и методов (Tools and Techniques). Пример процесса из PMBoK:

ITIL построен схожим образом, но все же отличается по структуре. Согласно оглавлению основных книг (Core library), в ITIL 26 процессов, однако существуют и так называемые подпроцессы, например Service capacity management или Component capacity management, которые лишь коротко описаны в составе процесса Сapacity management, не имея стандартной для ITIL структуры описания процессов. Кроме того, в ITIL есть виды деятельности, упоминаемые в тексте как процессы, но не имеющие отдельного описания вообще. Общая структура процесса в ITIL:

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

Как видно из таблиц, процессы в ITIL сгруппированы по 5 стадиям жизненного цикла сервиса (Service Strategy, Service Design, Service Transition, Service Operation, Continuous Service Improvement). Помимо 26 процессов описывается еще 4 функции. В PMBoK больше процессов и чуть сложнее их структура. 49 процессов объединены в 5 групп процессов (Initiation, Planning, Executing, Monitoring and Controlling, Closing); помимо этого, 49 процессов классифицированы по областям знаний. Часто группы процессов путают со стадиями жизненного цикла проектов, но это ошибочно. Из-за этого есть предвзятое отношение к PMBoK = Waterfall, что тоже неверно.

Таким образом PMBOK группирует процессы в матрицу для удобства навигации. В ITIL и PMBoK нет одинаковых процессов, но есть похожие. К примеру, менеджмент изменений (Change management) в ITIL и интегрированный контроль изменений (Integrated change control) в PMBoK.

Интегрированный контроль изменений (Integrated change control) в PMBoKМенеджмент изменений (Change management) в ITIL
Согласно PMBoK, интегрированный контроль изменений — процесс анализа всех запросов на изменения, их одобрения и управления изменениями поставляемых результатов, а также предоставления информации об их состоянии.

В ходе этого процесса происходит анализ всех запросов на изменение результатов, а также утверждение или отклонение изменений.

Ключевая выгода данного процесса состоит в том, что он позволяет учитывать документированные изменения в проекте, уменьшая риски проекта, которые часто возникают в связи с изменениями, внесенными без рассмотрения.

Процесс интегрированного контроля изменений проводится с самого начала проекта и вплоть до его завершения, он является ответственностью руководителя проекта. Запрос на изменение может подать любая заинтересованная сторона, вовлеченная в проект. Хотя изменения могут быть инициированы устно, они обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями и/или управления конфигурацией. Каждый документированный запрос на изменение должен быть либо одобрен либо отклонен ответственным лицом, обычно спонсором или руководителем проекта.

При необходимости в процесс интегрированного контроля изменений включается совет по контролю изменений (CCB) — формально созданная группа, ответственная за изучение, оценку, одобрение, отсрочку или отклонение внесения изменений в проект, а также за фиксацию соответствующих решений и информирование о них.

Одобренные запросы на изменения могут потребовать создания новых или пересмотра старых оценок стоимости, последовательностей операций, дат расписания, потребностей в ресурсах и анализа альтернатив реагирования на риски. Эти изменения могут потребовать внесения поправок в план управления проектом или в другие документы проекта.

В книге Service Transition, которая входит в библиотеку ITIL, менеджмент изменений описывается как процесс контроля жизненного цикла всех изменений и принятие необходимых изменений с минимальными негативными последствиями для ІТ-сервисов.

Ключевая выгода данного процесса в том, что он позволяет вносить изменения в ІТ-сервисы, чтобы они отвечали требованиям бизнеса. Все изменения должны быть оценены, записаны и утверждены. В менеджмент изменений не входят изменения в бизнес-процессы.

Изменением считается любая модификация или удаление любого компонента, который может оказать влияние на ІТ-сервис. Запрос об изменении обычно имеет стандартную, заранее утвержденную форму (RFC). ITIL выделяет 3 вида изменений:

  1. Нормальные изменения — прежде чем их внедрять, требуют оценки и утверждения.
  2. Срочные изменения — должны быть внедрены как можно скорее. Обычно проходят по особой, ускоренной процедуре и не всегда предполагают детальную оценку последствий.
  3. Стандартные изменения — как правило, это изменения, которые происходят довольно часто, имеют низкую степень риска и не требуют дополнительных утверждений и согласований. Как правило, проходят по заранее утвержденному сценарию.

Для авторизации изменений утверждается группа (CAB — Change Advisory Board), которая помогает менеджеру изменений оценить, приоритизировать и утвердить изменения. Все члены группы должны обладать авторитетом и необходимым опытом, чтобы оценить изменение. Отдельно создается группа по утверждению срочных изменений (Emergency Change Advisory Board). Такая группа часто собирается в срочном порядке для оперативной оценки срочных изменений.

Как видно из описания, взятого из официальных источников, оба процесса имеют много общего. Оба требуют предварительной оценки перед внедрением любого изменения, тщательного документирования; оба предполагают процедуру утверждения, которая может осуществляться как специально выделенной группой людей (CCB в PMBoK или CAB и ECAB в ITIL), так и отдельно взятым человеком (руководитель проектов или спонсор в PMBoK и менеджер изменений в ITIL).

Интегрированный контроль изменений (Integrated change control) в PMBoK:

Таким образом, можно заметить, что подходы в PMBoK и ITIL довольно схожи.

Различия

Рассмотрим несколько подходов, которые различают эти два стандарта. Они помогут нам по-другому взглянуть на некоторые вещи.

User vs Customer

ITIL различает заказчиков и пользователей. Заказчик определяет требования, заказывает проект, оплачивает его и утверждает (принимает) результаты проекта, в то время как пользователи используют результат проекта на ежедневной основе, не имея реальных полномочий для принятия решений (но они могут оказать влияние на заказчика). Обычно заказчик является лидером организации, а пользователи — ее членами. Заказчик и пользователь могут иметь разные интересы. Руководство PMBoK в настоящее время не дифференцирует эти роли. В действительности эти две роли часто путают между собою или применяют общий к ним подход, что часто является ошибкой.

Incident Management & Request Fulfilment

Проект по своей природе не предполагает, что мы получаем новые порции требований или запросы где-то в середине проекта. Точнее, такое может случиться, но каждый такой запрос должен пройти через Integrated Change Control — процесс, в результате которого должны получить модификацию baseline’ов проекта (scope baseline, quality baseline, schedule baseline and cost baseline). В общем, процедура непростая. Но как же быть, когда мы работаем по Scrum или Kanban? Мы получаем новые порции работы каждую итерацию, а то и чаще. Как правильно поступать с такими запросами и обрабатывать их, можно подсмотреть в ITIL в разделах Incident Management и Request fulfilment.

Problem Management

И ITIL, и PMBoK предлагают инструментарий для идентификации и решения проблем (хотя термин problem оба стандарта видят немного по-разному). PMBoK богат набором различных техник и инструментов, которые помогут эффективно работать с проблемами на проекте. Примеры таких инструментов:

  1. Контрольная карта.
  2. Диаграмма Парето.
  3. Гистограмма.
  4. Контрольный лист.
  5. Диаграмма Исикавы.
  6. Расслоение (стратификация).
  7. Диаграмма рассеяния.

Довольно часто на практике при анализе проблем (как правило, на ретроспективах) я использую диаграмму Исикавы/"Рыбьей Кости" (Fishbone Diagram)

На рисунке представлен такой пример с двумя уровнями костей. Красным цветом обозначен 1-й уровень — главные (коренные) — a, b, c, d, а синим — 2-й уровень — углубленные (детализирующие) причины (факторы) исследуемого влияния на результат (среди факторов 2-го уровня как те, которые усиливают действие 1-го уровня: e, f, g, h, i, l, m, o, p, так и те, что его ослабляют: k, n). Далее углубляют разделение обнаруженных факторов по их возрастающей специфичности до тех пор, пока ветви проблемы подвергаются дополнительному разделу (при этом необходимо выявлять истинные причины, а не симптомы).

Работа с диаграммой Исикавы проводится в несколько этапов:

  • Выявление и сбор всех факторов и причин, каким-либо образом влияющих на исследуемый результат.
  • Группировка факторов по смысловым и причинно-следственным блокам.
  • Ранжирование этих факторов внутри каждого блока.
  • Анализ полученной картины.
  • «Освобождение» факторов, на которые мы не можем влиять.
  • Игнорирование малозначимых и непринципиальных факторов.

Еще один полезный инструмент для работы с проблемами, с которым можно ознакомиться на страницах PMBoK, это афинити-диаграмма (affinity diagram), или KJ Method. По сути, это дополнение к мозговому штурму, когда все собранные факты и идеи организовываются в кластеры в зависимости от связей между ними. Эта техника хорошо подходит для воркшопов: необходимо собрать нужных stakeholders, которые имеют отношение к данной проблеме; запастись большим количеством разноцветных стикеров, которые являются «атомами» фактов или идей, которые вы собираетесь объединить в различные группы.

Дальше несколько простых шагов:

ШагФазаОписание
1.Идентифицировать проблемуОпределите свою проблему или общую тему. Пример: почему уровень удовлетворенности клиентов снижается?
2.Собрать идеиПеречислите соответствующие факты, данные, идеи, мнения, касающиеся предмета, и поместите их на стикеры или запишите на доске
3.Найти связи между нимиОбратите внимание, какие из этих заметок или карточек похожи, и расположите их в соответствии с шаблонами, основанными на этих сходствах
4.Сгруппировать идеи в кластерыПометьте каждую группу похожих заметок или карточек ярлыком для каждой группы Affinity. Это могут быть аспекты рассматриваемой проблемы. Определите приоритетность проблем, которые были выявлены
5.Проанализировать результатПосмотрите на созданные группы и факты/идеи, связанные с каждой идеей. Какие идеи это дает в отношении проблемы, изложенной вначале? Предлагает ли это потенциальные решения?
6.Поделиться результатамиПоделитесь результатами со всеми заинтересованными сторонами

В PMBoK, инструменты, которые позволяют эффективно работать с проблемами, не вынесены в отдельные процесс или область знаний, а распределены по другим областям знаний (большинство — в Quality Management). В ITIL это отдельный процесс. Управление проблемами — еще одна важная глава, обсуждаемая в разделе «Сервисная поддержка» ITIL®. Цель этого процесса — «минимизировать негативное влияние инцидентов и проблем на бизнес, вызванных ошибками в ІТ-инфраструктуре, и предотвратить повторение инцидентов, связанных с этими ошибками». Проблема является неизвестной основной причиной одного инцидента или более. Известная ошибка — это успешно диагностированная проблема (известная основная причина), для которой были найдены временный обходной путь или постоянное решение.

Контроль проблем как часть ITIL направлен на преобразование проблем в известные ошибки, чтобы выяснить причину инцидентов, в то время как контроль ошибок отвечает за устранение известных ошибок с использованием процесса управления изменениями.

Этапы контроля проблемы:

  • идентификация и регистрация проблемы;
  • классификация проблемы;
  • исследование, диагностика проблемы и анализ первопричины (определение неизвестной основной причины проблемы).

Функции контроля ошибок:

  • идентификация и запись ошибок;
  • оценка ошибок;
  • устранение ошибок записи (это точка, в которой будет подан запрос на изменение для постоянного разрешения);
  • закрытие ошибок и прогресс разрешения монитора.

Одним из преимуществ ITIL по сравнению с PMBoK для ІТ-проектов является то, что он ориентирован на ІТ, в то время как PMBoK не имеет профилизации (не считая software extension to PMBoK Guide). В ITIL можно найти полезные рекомендации по Information Security и Release and Deployment Management. Те же процессы, что есть в PMBoK, к примеру Knowledge Management или Change Management, также более релевантны для ІТ.

PMBoK и ITIL имеют соответствующие сертификации, детали можно почитать тут. Также в Украине действует комьюнити сертифицированных PMP-специалистов.

Выводы

Подводя итоги, стоит отметить, что у PMBoK и ITIL схожий подход к некоторым вопросам, но они имеют разные сферы применения. Для проектов с фиксированной ценой и скоупом (Fixed-Price) PMBoK является более подходящим источником практик. Для проектов, которые имеют SLA, проекты поддержки (Support, Maintenance) ITIL более релевантен. Большинство проектов, которые работают по Kanban, могут найти много полезного в Service Operations (одна из книг, которая входит в библиотеку ITIL). ITIL также широко применяют IT-отделы крупных компаний, Service Design и Service Strategy отлично подходят для запуска новых IT-сервисов. А вот уже разработка и реализация нового сервиса может быть осуществлена в рамках проекта, где будут применяться практики из PMBoK. Передача этого сервиса от разработки к поддержке и непосредственная поддержка сервиса и его улучшение также описаны в ITIL.

В проектах, в зависимости от их специфики, можно использовать практики как из PMBoK, так и из ITIL. В ІТ-проектах, которые часто используют гибкие (Agile) подходы для решения отдельных вопросов, которые не предписаны в том же Scrum или Kanban, можно смело пользоваться процессами, предлагаемыми PMBoK или ITIL, смотря на то, что лучше подходит. К примеру, процесс управления рисками может быть построен согласно рекомендациям PMBoK, а управление инцидентами — согласно ITIL. Стоит иметь оба набора Best Practice в своем арсенале, чтобы в нужный момент использовать нужный инструмент.

Надеюсь, эта статья натолкнет вас на новые идеи по управлению вашими проектами.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному9
LinkedIn

Схожі статті




20 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо за статью, крайне познавательно. Подскажите пожалуйста какого издания лучше всего смотреть бумажные книги по ITIL?

Тут выбор невелик, все права на публикацию ITIL книг принадлежат AXELOS. Так что тут только такой вариант: www.axelos.com/...​foundation-itil-4-edition

есть еще всякие адаптации, вроде таких: www.ebay.co.uk/...​11585761?iid=391649915880 но не могу посоветовать, что-то конкретное, читал только оригинальные книги.

на Amazon есть такие опции:
— www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
— www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
— www.amazon.com/...​Suite-ebook/dp/B00OYTB3VS
— www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ
— www.amazon.com/...​fRID=7EJ1FMY940T88JWZZYVJ

Тема действительно интересна. Как по мне, то если речь идет о развитии компетенции Service Management в компании, то я бы все-таки отодвинул PMBoK на второй план и сделал бы упор на ITSM (ITIL). С другой стороны, ITSM — уж очень монструозен, и если речь идет о быстром развитии компетенции с нуля или околонуля, то стоит присмотреться к вышедшей недавно модели CMMI v2.0. CMMI Institute сделал большой шаг вперед по сравнению с версией 1.3. В новой версии реально интегрированы Development, Services и Acquisition, убрано дублирование, радикально упрощен язык. Модель стала понятна не только спецам, но и бизнесменам... :) И, мне кажется, это лучше ITIL.

Юрий, я исхожу из опыта работы в ИТ-аутсорсинговой компании, у нас более 600 проектов, на всех разные подходы, методологии и практики. Я не видел проекта, где применяются все 49 процессов из PMBoK или все 26 процессов в ITIL, думаю, это и нецелесообразно. Но отдельные практики из обоих подходов работают очень даже хорошо. Те проекты, где у нас есть SLA (обязательства перед клиентом решить его реквест определенной сложности за определенное время), практики из ITSM работают очень даже хорошо. Fixed-Price проекты могут использовать арсенал PMBoK. Многие проекты, могут использовать отдельные практики с обоих подходов.

Если честно, я ни разу не слышал про удачную имплементацию CMMI. Под удачной имплементацией, я понимаю, та, которая принесла дополнительную ценность компании. Но не исключаю, что такое явление существует. Видел когда CMMI применяют для очень ограниченного куска бизнеса (один проект) для получения сертификации. Поэтому у меня немного скептический взгляд на ее счет.

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

Спасибо за комментарий!

оба [процесса] предполагают процедуру утверждения, которая может осуществляться как специально выделенной группой людей (CCB в PMBoK или CAB и ECAB в ITIL), так и отдельно взятым человеком (руководитель проектов или спонсор в PMBoK и менеджер изменений в ITIL).

интересно, как эта процедура утверждения в идеале работает с Continuous Delivery & Trunk Based Development?

А то пришлось как-то с CAB процессом столкнуться — совсем не ажильно как-то было. Перегибы на местах?

CAB процесс согласования нового сервиса. По сути, вы предлагаете что-то новое на уровень всей компании и да, как правило это процедура долгая, сложная и не очень Agile. Но на это есть причины, новый сервис, как правило затрагивает много разных департаментов и аспектов работы предприятия. Чем больше компания, тем больше согласований проходит CAB.

Когда мы утвердили, что сервису быть, прошли фазу дизайн и начали непосредственно разработку, тут уже работает Integrated Change Control из PMBoK. В зависимости от гибкости компании он может быть разным. Если мы говорим про Agile проект, который работает итерациями по Scrum, то CCB может состоять из Product Owner или PO и Architect. а процесс согласования может проходить во время одного митинга. Эта процедура отлично работает с Continuous Delivery.

Если же мы говорим про проект с фиксированным бюджетом и сроками, то тут любое изменение будет наверняка проходить цепочку согласований и оценку его влияния на остальные требования, сроки, бюджет, качество и пр. Целесообразность CD тут зависит от длины фазы и прочих факторов.

IMHO

ОК, то есть если я понимаю правильно, можно в принципе отделить Change Management от технической доставки изменений и работать с высокоуровневыми требованиями по утяжеленному процессу.

Ну, я бы по-другому сказал. Change Management это процесс, который стоит подумать, чтобы он отвечал потребностям проекта. Вы промежете спланировать его таким образом, что если у Вас есть Hot Fix, он может пойти по упрощенному workflow. Если есть крупные изменения сущестущих изменений, то изменения должны быть оценены командой и Architect и Product Owner (которые входят в Change Control Board) утверждают, чтобы это изменение взяли в Backlog. Изменения в Schedule, Cost, Scope документируются и всем нужным stakholders вы высылаете уведомление. Если изменение имеет слишком большой импакт на Scope, Cost, Schedule мы идем за апрувом к спонсору проекта или к budget owner. Ну и т.д. Это как пример. Доставка изменений или CD это технический аспект работы, Integrated Change Control это процессный, чтобы мы не упустили, что наши изменения повлияли на дату релиза, остальной scope или cost проекта. Идея большинства agile подходов, это максимально упростить этот процесс, но тем не менее в том или инном виде он существует даже в Scrum, Kanban и пр. просто отдается на откуп PO и тут больше фокус на приоритизацию backlog.

Ну здесь все просто. Определитесь, зачем вам нужен CAB? Какую конкретно проблему, как Вам кажется, это может решить? Пока не ответите себе на этот вопрос, нет никакого смысла обсуждать, как оно будет сожительствовать с помянутыми подходами... :)

Мне лично не нужен, но не всегда есть возможность легко и быстро влиять на процессы в больших компаниях. Меня интересовала практическая совместимость

ёкодзун

с гибкой разработкой, в частности частым и малым диплоям.

Чудова стаття. Дякую!

PMBoK и ITIL схожий подход к некоторым вопросам, но они имеют разные сферы применения. Для проектов с фиксированной ценой и скоупом (Fixed-Price) PMBoK является более подходящим источником практик. Для проектов, которые имеют SLA, проекты поддержки (Support, Maintenance) ITIL более релевантен.

Кратко — с этого нужно начинать и этим же и заканчивать.

Спасибо автору за подробную статью сравнения операционной и проектной деятельности. Я предложу выпустить продолжение (а может надо было так сперва поступить автору), где сфокусироваться на проектной деятельности (PMBOK для разработки софта) и на дополняющей его операционной деятельности (ITIL и предоставление услуг разработанным софтом).
Часто работодатели не видят разницы и на проектного менеджера вешают операционные процессы (включая поиск новых клиентов и пресейл, поддержку и продвижение сайта в топ-5 и т.п. — кто «попадал» тот понимает о чем я).

Спасибо за комментарий. Действительно очень интересная тема

PMBOK для разработки софта

, спасибо за идею для следующей статьи.

Рад, что Вам понравилась, статья!

А диаграммы Исикавы Такубоку, или это одноименный однофамилец?

Хороший вопрос! Признаюсь честно, полного имени автора не знал, но википедия подсказала: «Диаграмма названа в честь одного из крупнейших японских теоретиков менеджмента профессора Каору Исикавы (яп. 石川 馨, ромадзи Kaoru Ishikawa), который предложил её в 1952 году (по другим данным — в 1943 году[1]) как дополнение к существующим методикам логического анализа и улучшения качества процессов в промышленности Японии». Детали можно почитать тут: uk.wikipedia.org/wiki/Діаграма_Ішикави

Підписатись на коментарі