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

Лица каталога услуг

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

Позволю себе задекларировать приверженность следующему тезису: 

Каталог услуг — это инструмент коммуникации.

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

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

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

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

Давайте вместе посмотрим внимательно на этих людей, поставим себя на их место и попробуем определить, чего они могут хотеть от каталога услуг. 

SampleStakeholdersЗаказчик услуг хочет видеть:

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

Для потребителя услуг важно:

  • Понимать состав каталога услуг и осуществлять навигацию по нему;
  • Иметь простую возможность заказа услуг;
  • Быть информированным о текущем уровне обслуживания.

Руководитель ИТ-блока смотрит на каталог услуг, как на некоторый результат его работы по управлению портфелем услуг:

  • Полнота и достаточность текущего каталога услуг с точки зрения потребностей заказчиков услуг;
  • Рентабельность услуг;
  • Уровень удовлетворенности заказчиков услуг.

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

  • Способствовать локализации обращений и их адресации ответственным группам;
  • Способствовать возможности услуги с затратами, в т.ч. с закупками; 
  • Контролировать уровень потребления услуг;
  • Измерять доступность услуги и уровень качества её текущего предоставления.

Менеджер уровня услуг опирается на данные каталога услуг и в этих разрезах:

  • Формирует и заключает соглашения об уровне услуг с заказчиками услуг;
  • Измеряет и контролирует параметры гарантии услуг и уровни их потребления;
  • Мониторит удовлетворённость пользователей и заказчиков услуг.

Менеджер каталога услуг, как истинный библиотекарь/секретарь, следит за основными свойствами информации под его контролем:

  • Ценность: пользователи каталога услуг пользуются им в своих целях, в каталоге нет противоречий, устаревших записей;
  • Доступность: каталог общеизвестен и легко доступен для авторизованных стейкхолдеров;
  • Целостность: состав и структура каталога защищены от искажения, подлога, разрушения или утери, изменения каталога происходят управляемым образом;
  • Конфиденциальность: отдельные разделы каталога и отображаемой информации из SDP доступны ограниченному кругу лиц (например, финансовая информация).

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

Кроме вышеуказанных требований к контенту, можно увидеть, что к каталогу услуг предьявляют чрезвычайно разнообразные требования по формам и видам интерфейсов:

  • представление на портале самообслуживания для пользователей; 
  • аналитики сводного финансового отчета для заказчика услуг; 
  • мастерданные для ITSM системы для потребления операционными процессами обслуживания пользователей;
  • аналитики и статьи затрат для управления финансами в ИТ;
  • доступ к данным SDP в части параметров гарантии и определения доступности конкретных услуг для систем мониторинга;
  • содержательная структура для инструментов изменения удовлетворенности;
  • и др.

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

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

Да, в моем примере есть определенное смешение различных данных, ролей, задач и областей ответственности, но это то, с чем нам приходится сталкиваться в реальной жизни. Если вам хочется что-либо добавить или оспорить, буду рад подискутировать.

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

  • Игорь

    SDP — SeviceDesk Portal ?

    • Нет 🙂

      Это Service design package (SDP), пакет полной документации по услуге. Этот свод документов появляется на этапе проектирования услуги и продолжает жить с ней до вывода услуги из эксплуатации. Включает в себя описательный раздел, структуру услуги, её архитектуру, ресурсы которые она потребляет (люди и инженерные можности), описание поставщиков и потребителей и прочее. «Все об услуге». 

  • Игорь

    Спасибо!  🙂

  • Ольга

    Мне кажется, что серьезная задача при создании каталога — вовремя остановиться. Например, знаю реальный проект, где в каталог включены бизнес-услуги, инфраструктурные сервисы, информационные системы, от которых зависит предоставление услуг, все это с указанием параметров SLA и OLA; менеджер процесса управления изменениями настоял на включении ссылок на проекты в Jira для каждой информационной системы; да еще рассматривается возможность включить в него продукты (скрестить сервисное и продуктовое управление в компании). Получается такой монстр — гибрид каталога и CMDB в лучшем случае 🙁 Как этим управлять и поддерживать актуальность информации, совершенно непонятно.

    Так что я бы для обсуждения сформулировала вопрос, как оптимально установить границы каталога.

    • Замечание совершенно правильное, и есть работоспособный рецепт к тому, чтобы не скатываться в хаос. На каталог услуг, в широком смысле, со всеми его интерфейсами нужно смотреть также как и на CMDB. Это означает следующее:

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

      2. Для каждого информационного поля, справочника, интерфейса в каталоге должно быть явное предназначение. Для каждой части каталога определяется «заказчик» (основной потребитель) и «владелец» (отвечает за актуальность).

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

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


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT