Вот еще одна модель с минимальной прикладной ценностью, зато для меня обеспечивающая полное понимание вопроса.

В процессных моделях ITIL, COBIT 5, ISO 20000, MOF 4, CMMI for Services присутствуют одни и те же слова: доступность, мощность, непрерывность и, конечно, безопасность. Если брать за основу идеологию ITIL, то это – четыре равноправных и обязательных составляющих качества ИТ-услуг (есть еще функциональность, но я не о ней пока).

И вот, в ITIL всё понятно: есть четыре процесса, которые оперируют ими: проектируют и контролируют. А вот в других источниках всё по-другому, по-разному. Во всех перечисленных моделях эти слова комбинируются в произвольном порядке. Стандарт –  объединяет, и управляет вместе доступностью и непрерывностью, MOF –  все объединяет в «надежность» и т.д.

Почему же эти процессы объединяют в разных процессных моделях, и как поступать на практике?

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

И, тем не менее, следуя не букве, но духу ITIL, я рискну представить, что все четыре (два, три) процесса – это один и тот же процесс: управление рисками. Попробую объяснить.

Функциональности ИТ-системы, которую проектируют, разрабатывают, тестируют и внедряют другие ребята, а ITSM считает «полезностью услуги», в эксплуатации постоянно что-то угрожает. Каждый из четырех процессов отвечает за один класс подобных угроз: доступность – за сбои, мощность – за дефицит ресурсов против спроса, непрерывность – за "пожары", безопасность… ну вы поняли. Действуют они примерно одинаково, в соответствии с методикой управления рисками (последовательно и упрощенно):

1. Выявление 
2. Классификация
3. Отбор важнейших угроз
4. Разработка контрмер
5. Мониторинг угроз и контрмер

– почти как на картинке.

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

Пятый шаг этой процедуры – это мониторинг. ИТ-организация отслеживает все угрозы и значения их характеристик. В случае реализации угрозы быстро применяется правильная контрмера, и составляется и анализируется отчетность об этой угрозе. Деятельность операционная.

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

• Резервирование систем
• Запасные ресурсы на случай всплеска потребления
• Средства защиты
• Планы поведения при наступлении угрозы
• и т.п.

И вот, получается, что все четыре процесса, в своих интересах, будут лезть за контрмерами в один общий кошелек! Ничего удивительного, что их объединяют! Так проще драться за ресурсы! 😉

Итак, мне кажется, объединять процессы проектирования можно, потому что у них:

• А. похожая структура.
• Б. общие ресурсы.

Но ведь ITIL всё-таки разделяет. Почему же?

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

ОБУЧЕНИЕ

IT Service Management

Учебные курсы от соавторов ITIL 4