Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT