Портал №1 по управлению цифровыми
и информационными технологиями

Проектирование услуг как управление рисками – часть 2

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

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

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

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

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

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

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

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

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

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

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

Комментариев: 9

  • Pavel Solopov

    Придётся выбрать направления инвестиций.

    Как раз для этого и стоит рассматриать все эти процессы вместе, чтобы понимать их взаимосвязь и взаимовлияние. Иначе можно неэффективно размазать бюджет по 4 направлениям,и н еполучить эффекта нигде.

    • Павел, так я их вместе рассматриваю) но взаимосвязь и взаимовлияние имеют место между показателями качества, а не самими процессами. Бюджет надо не размазывать, а заставлять всех четверых (троих, двоих, а может быть и одного), размазывать этот бюджет не неэффективно, а как надо 😉

      • Pavel Solopov

        Что-то я не очень понял, как это если показатели качества взаимосвязаны, то по идее и процессы обеспечивающие эти показатели взаимосвязаны,как минимум через эти самые показатели, или нет?
        Заставлять это хорошая идея, вот только кто будет заставлять, кто будет выстраивать эти четыре процесса в общую картину и искать баланс между ними? Если их не оюъединять, то этим должен заниматься некто Главный, который отвечает ещё за 20 таких же процессов и ещё чего-нибудь для него будет сложно анализировать эти 4, если объеденить, то будет один ответственный за эти четыре, а он уже будет в агрегированом виде нести информацию главному…

        Ох и канцелярия же, правад получится… Кто работать-то будет? На одних клерках-то доступная непрерывность мощностей не удержится…

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

          Ответил в следующей части 

          Ох и канцелярия же, правад получится… Кто работать-то будет? На одних клерках-то доступная непрерывность мощностей не удержится…

          =)

  • Pavel Solopov

    Ещё вот какой момент, Вы всё время рассматриваете линейную структуру либо 4 процесса рядом, либо 2, либо 1 и т.д. А правильнее было бы рассмативать эти процессы в иерархии.

    Так управление мощностями можно рассматривать как подпроцесс управления доступностью, а управление доступностью и упрвление непрерывностью, как подмножество управления рисками.

    Хотя с рисками тут спорный вопрос. Скорее всего управление рисками это всё же одна из методик внутри процессов управления нерерывностью, доступностью, мощностями.

    • Павел, а каковы принципы построения такой иерархии? 

      Насчет методики и техник внутри процессов, то мне кажется управление рисками это дисциплина более высокоуровневая, чем expanded inc lifecycle, sfa, cfia и проч техники. Как тут не вспомнить цитату из управления доступностью: 

      Availability can also improve the ability of the business to follow an environmentally responsible strategy by using green technologies and techniques in availability management.

      А вот со вторым абзацем я согласен:)

      • Pavel Solopov

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

        • Насчет подмножества дочерних элементов материнского – улыбнуло.

          А управление безопасностью – это подмножество чего?

          • Pavel Solopov

            С управлением безопасностью, всё не так просто. ИБ может разделиться на несколько частей. Обеспечение конфиденциальности это подмножество экономической безопасности предприятия, а обеспечение целостности данных, это подмножество управления доступностью.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM