Недавний опыт проведения курса ITIL RCV для сотрудников компании, являющейся поставщиком ИТ-услуг, порадовал свежими взглядами на мир, процессы, их востребованность в реальных ситуациях. Первая часть курса во многом посвящена “деятельным” процессам этапа преобразования услуг, таким как “Управление изменениями” и “Управление релизами”, во второй части курса основное внимание уделяется “библиотечным” процессам, в частности процессу Управления сервисными активами и конфигурациями. В ходе изучения этого процесса мы со слушателями обсуждаем ресурсно-сервисные модели услуг, для чего они могут быть нужны, как нужно организовать работу по их построению.
Выполняя практические задания, группа в хорошем смысле меня удивила и порадовала, выбрав в качестве услуги “Поддержка процесса управления изменениями”. Такой выбор точно не является характерным выбором наших слушателей, которые чаще склоняются к услуге “Поддержка приложения N” или к поддержке некоторого инфраструктурного сервиса, например сервиса печати/идентификации.
Ребята хорошо поработали и, проведя мозговой штурм, представили свою концепцию модели этой услуги. Опытным путем установлено, что процесс составления модели услуги находится в центре большого поля уложенного граблями и мы всласть походили по ним, получив столь необходимый опыт и пищу для обсуждения.
Давайте и мы с вами попробуем изобразить ресурсно-сервисную модель поддержки процесса управления изменениями.
Дубль №114. Мотор!
Ресурсно-сервисная модель конкретной услуги представляет собой перечень конфигурационных единиц/сервисных активов, т.е. всего того, что там необходимо для качественного оказания этой самой услуги, а также массив связей между конфигурационными единицами.
Договоримся на берегу о связях. Далее будем говорить только о направленных связях влияния одной конфигурационной единицы на другую. Если выключение одной конфигурационной единицы (далее для краткости, КЕ) влечет за собой полную неработоспособность зависимой КЕ, то такую связь будем называть критической. Если же зависимая КЕ деградирует в своем качестве, но остается работоспособной, то не критической. В реальной жизни такая классификация связей практически сразу потребует расширения, но для нашего примера её будет достаточно.
Что же будет выступать в качестве конфигурационных единиц? Сервисными активами, участвующими в модели, могут быть как наши ресурсы в виде вычислительной инфраструктуры, сетей, приложений, сотрудников, документации так и наши способности: процессы, компетенции, организационная структура.
Давайте начнем перечислять сущности, которые будут нужны для оказания нашей услуги, и будем соединять их связями влияния. О требовании к тому, чтобы входящие в РСМ сервисные активы входили в охват процесса управления изменениями, мы пока умолчим. Пример такой схемы можно увидеть на следующей схеме.
Для реализации нашего процесса управления изменениями, который мы предоставляем нашему заказчику, мы задействуем как ресурсы поставщика услуг, так и ресурсы заказчика. Со своей стороны мы предоставляем квалифицированного менеджера процесса, а также координаторов крупных/сложных “Major” изменений (намеренно опускаю декларацию критерия), которые будут координировать работу нескольких подразделений. Если же изменение не является “Major”, то координаторами будут выступать эксперты в соответствующих локальных функциональных областях заказчика.
Мы предполагаем, что у заказчика есть ITSM система, уже обладающая функциональностью для регистрации изменений, их обработки и формирования отчетности.
Для того чтобы все наши ресурсы могли работать совместно, они должны находиться в корпоративной сети, которая будет являться пререквизитом нашей услуги. В реальном примере территориально распределенной организации этот кубик будет представлен целым пулом сервисных активов, гарантирующих соединение ключевых элементов модели между собой.
В предположении того, что менеджер процесса не участвует в операционной обработке изменений его краткое отсутствие не вызовет остановку процесса, а отсутствие координаторов или исполнителей работ будет критичным.
Наши подготовленные координаторы Major изменений обладают опытом и смогут действовать при отсутствии доступа к своей ролевой инструкции, а внешние для нас, как поставщика, координаторы изменений, которые могут быть даже представителями третьих сторон – нет.
Если версии/функциональность компонентов приложения будут расходиться с требованиями устанавливающей документации, то можно сказать, что качество таких компонент деградировало.
Интересным объектом схемы является сервисный актив “Данные о КЕ и их группах обслуживания”. Без предоставления этой информации выполнение работ по преобразованию услуг и их компонент невозможно, т.к. либо отсутствует информация об объекте изменения, либо доступ к тем “рукам”, которые это самое изменение будут реализовывать. Очевидно, что полнота этой информации будут определять границы охвата процесса или ответственности поставщика услуг в нем.
На схеме специально опущены технические связи между компонентами приложений и серверами/виртуальными машинами на которых они установлены. Это может иметь смысл для компонентов, предоставляемых заказчиком.
Хорошей мыслью “на обдумать” является вопрос, а где же тут ITSM система? Может ли она быть представлена одним кубиком? Может ли ” ITSM система ” быть услугой, и если да, то как обозначать нашу зависимость от отдельных её компонент, таких как форма подачи RFC. Что означает для нее “доступность”?
Среды разработки и тестирования ITSM системы могут присутствовать в инфраструктуре заказчика и, более того, входить в модель его услуги “Поддержка ITSM системы”, но на наш процесс они не оказывают никакого влияния и по этой причине в нашей схеме не присутствуют.
Почем фунт лиха?
“Нет, все это просто прекрасно! И это интеллектуальное упражнение нас так увлекло, что мы потратили на это половину рабочего дня! Нам понравилось это все рисовать!” – можете воскликнуть вы.
Но зачем нам нужна эта схема?
Используя знания об архитектуре услуги вы сможете:
- Отследить влияние инцидентов и недоступности КЕ на наш сервис;
- Восстановить сервис из пепла по плану непрерывности;
- Тиражировать его для другого заказчика, не изобретая значительную часть велосипеда;
- Определить необходимость выполнения связанных изменений в компонентах, зависящих друг от друга;
- Отслеживать и прогнозировать наши возможности и потребности как поставщика этой услуги в зависимости от спроса на неё;
- Измерять здоровье сервиса, дополнив схему параметрами мощности/доступности и обладая средствами мониторинга;
- Строго определить границы процесса управления изменениями по нашей услуге;
- Определить себестоимость нашей услуги, зная объем потребления предоставляемых поставщиком компонент и стоимость единицы потребления этого сервисного актива.
На мой взгляд – совсем не мало.
Спасибо за то, что прочитали. Комментарии и критика приветствуются!
огромное спасибо за статью. Не так давно искал и ничего в сети вразумительного не нашел про практику построения РСМ, так что ценность материала высокая.