Итак, продолжая начатое в предыдущем посте рассмотрение процессов проектирования, отвечу на вопрос:

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

Мне кажется, причины две.

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

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

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

Иллюстрация.Только у нас их четверо. А воз должен всё-таки похать куда .

Вот и получится, что одноименные процессы будут в каждом конкретном случае пребывать на разных уровнях зрелости управления. Чем важнее, тем трезвее, гарантированнее. Остальные – подвиньтесь. И по доступу к кошельку, и по уровню полномочий. Вон, во второй версии ITIL про безопасность вообще была отдельная книжка, вне процессной модели.

Поэтому будем четыре процесса разделять. Так говорит ITIL. Но ему «не верят» остальные процессные модели, группируя эти параметры произвольно. Глупые что ли? Или настаивают на практике управления рисками?

Опять получилось много, закончу в третьей части.

ОБУЧЕНИЕ

IT Service Management

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