Управление ИТ-сервисом — это на данный момент «серая» зона: непрозрачны механизмы, подходы к реализации разнятся, отсутствуют детальные стандарты и практики. Незрелость сервисных подходов — это временная проблема: в открытом доступе и COBIT, и TOGAF, определяющие контекст сервисного управления; в открытом доступе и ITIL.
Управление сервисом ИТ располагается немного в стороне от остального предприятия. С точки зрения управления сервисом ИТ - предприятие можно представить в виде трапеции:

Сервисный сегмент ИТ управляет, уровнем предоставляемого ИТ-сервисов, как внешних, так и внутренних. Сегмент управления сервисом ИТ управляет факторами влияния на ИТ - предприятие, такими, как процессы, организационная структура, информация, политики и т.п. Многие считают сервисный сегмент бесполезным и даже вредным, его сотрудники порой воспринимаются, как бездельники. Структурно сервисный сегмент может быть таким:

Сервисный сегмент предоставляет технологии управления ИТ для стратегического сегмента предприятия, для руководителей подразделений, для операционного блока предприятия. Управление сервисом начинается со стратегии.

Согласно методологии управления ИИ COBIT 5 стратегия управления сервисом определяется потребностями заинтересованных сторон бизнеса(учредители, государство, внешняя среда). Потребности, определяющие стратегию, можно классифицировать, как: Получение выгод, Оптимизация рисков, Оптимизация ресурсов.

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

Факторы влияния включают в себя процессы, организационные структуры и информацию, а для каждого фактора влияния можно определить набор конкретных целей, которые связываются с ИТ-целями. Процессы являются одним из факторов влияния. © COBIT 5.
Знакомый администратор, совершивший множество подвигов при решении проблем баз данных однажды узнал, что наградой ему стало то, что он не был уволен во время массового сокращения. Его похвалили и увеличили нагрузку, требуя инновационных решений. Его зарплата составляла половину рыночной, он очень быстро перешел на другую работу. Повышенная текучесть экспертов—частое явление, возникающее при оптимизации ИТ- ресурсов.

Управление ИТ-сервисом начинается с коммуникаций со стратегическим сегментом, для уточнения информации об ИТ-целях, организационных проблемах, болевых точках и красных зонах ИТ. Естественно, что в нашем случае, ключевыми рисками для ИТ будет снижение качества ИТ-услуг и деградация ИТ- инфраструктуры(ухудшение показателей доступности IT-сервисов). Исходя из этой потребности, сервисный сегмент должен сформировать такую отчётность о доступности, которая показывает не только среднюю температуру по больнице, но и красные зоны различных групп ИТ- инфраструктуры и ИТ- сервисов. Так же нам необходимо отобразить то, как подразделения нашей организации реагируют на те или иные факторы рисков.

После общения со стратегическим сегментом мы начинаем анализировать данные о текущем положении дел: насколько ситуация с доступностью «запущена», на какие факторы риска влияет текучесть экспертов. К примеру, мы формируем гипотезу о том, что надвигается дефицит администраторов PostgreSql, что приведёт к деградации внедрений отечественных ERP-услуг.

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

После проведённых коммуникаций у сервисного сегмента формируются минимум две задачи: мониторинг факторов риска нарушения показателей доступности, связанных с просадкой компетенций и накопление экспертных знаний по решению проблем, связанных с решением проблем БД. Мониторинг факторов рисков удобно осуществлять с помощью метрик процессов управления ИТ, таких, как управление инцидентами, проблемами, изменениями.

Понятное дело, что на самом деле данная простенькая таблица существенно сложней, однако нам нужно донести мысль о том, как с помощью процессов можно организовать мониторинг факторов рисков. Задача сервисного сегмента в нашем случае сводится к модификации процессов управления ИТ так, чтобы было удобно мониторить риски. Для этого в Service Desл объекты изменений, проблем и инцидентов соответствующим образом классифицируются, к примеру, в объекте проблема стоит создать признак того, что одним из факторов проблемы является нехватка компетенций. Классификация объектов ITSM должна быть гибкой и соответствовать целям ИТ.

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

Классифицируем проблемы так, чтобы был виден тип сбоящего компонента. В данную классификацию должна попасть строка примерно такого вида: «Зависание БД Postgresql при обработке больших данных».

Если присмотреться, то можно увидеть:

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

  2. Блок административного управления получил инструмент контроля факторов рисков и монторинга работы с базой знаний о проблемах.

  3. Директор по ИТ(CIO) получил стратегическую отчётность, он может подойти к акционерам и сказать, хватит оптимизировать ИТ: смотрите сколько у нас проблем и сбоев. В том числе по крайне важным и критическим системам. И. Очень важна грамотная классификация, при которой Директор по ИТ может жонглировать причинами, в качестве аргументации.

Какие выводы из статьи?

  • Стратегия управления сервисом должна быть.

  • Управление сервисом — это умение видеть потребности движущие силы и бизнеса.

  • Управление сервисом — это коммуникации: со стратегическим сегментом на языке реализации ИТ‑целей; с административным блоком административного на языке инструментария управления; с операционным блоком на языке сценариев выполнения производственных процедур.

  • Управление сервисом — это про удобство управления ИТ.

  • Управление сервисом — это про удобство выполнения производственных процедур.

  • Управление сервисом‑это умение оперативного тюнинга процедур управления ИТ(регламентация, классификация, показатели).

  • Управление сервисом — это настройка конфигураций ITSM, Service Desk.

  • Управление сервисом — это знания в области менеджмента разработки и эксплуатации и утилизации информационных и инженерных систем.

Управление сервисом—довольно интересное занятие и относительно новое направление в ИТ.

P.S. В данной статье я привёл решение небольшой задачи сервисного сегмента для понятности его деятельности и демонстрации полезности. Как пример того, когда всем выгодно от развития сервиса. Как пример, того, как ИТ может участвовать в достижении целей бизнеса. Пример, конечно же негативный, но довольно жизненный.
Всем удачи и счастливых случаев. Ура!

Комментарии (4)


  1. AlexeyK77
    03.12.2024 15:21

    Спасибо за статью. Полагаю, что из-за ориентированности на технологии и разработку, вопросы менеджмента ИТ по ITIL выглядят аудитории чуждо. Но все именно так и должно быть


  1. Thomas_Hanniball
    03.12.2024 15:21

    Управление ИТ-сервисом — это на данный момент «серая» зона

    ITSM\ITIL для кого создавали? Уже все, кому не лень, знают как управлять IT сервисами.

    ITIL появился в 1980-х годах, когда британское правительство поняло, что качество их ИТ-услуг просто не стоит на месте.

    Причём об этом известно на протяжении последних 40 лет.


    1. scarab
      03.12.2024 15:21

      В статье рассказывается больше про COBIT, это альтернативный подход к управлению.

      Что не мешает многим компаниям по-прежнему держать этот вопрос действительно в "серой" зоне, управляя ИТ стихийно, "как бог на душу положит".


    1. ingvarotto Автор
      03.12.2024 15:21

      Если погрузиться в тему, то можно увидеть множество серых зон и в ITIL. К примеру, вопрос распределения ответственности внутри процесса в соответствии с жизненным циклом ис. Вопросы разработки оптимальных сценариев процессов так же не проработаны. Механизмы взаимодействия процессов, базовые классификации, интеграции в цели бизнеса и многое другое осталось за рамками мышления британских учёных. Тут есть куда расти...

      ITIL , как методология, остановился в развитии и всё меньше соответствует текущим потребностям.