Портфель услуг
Портфель услуг включает три компонента: воронка услуг (Service Pipeline), каталог услуг (Service Catalog) и услуги, выведенные из эксплуатации (Retired Services). Они связаны с системой управления конфигурациями (CMS, Configuration Management System), которая находится в центре.
CMS сложнее, чем просто конфигурационная база данных (CMDB, Configuration Management Database) из ITIL v2. Внизу справа показана совокупность CMDB. Кроме них, CMS включает пять объектов: портфель клиентов, портфель приложений, систему управления внешними исполнителями, портфель клиентских соглашений (договоров или SLA) и портфель проектов.
CMS — это программно-технический комплекс и совокупность процессов. Они управляют всеми объектами как единым целым: следят за соответствием объектов друг другу, синхронно вносят изменения.
Воронка и каталог услуг
Воронка услуг технически может быть базой данных, структурированным документом, набором файлов или иной структурой данных. Это не принципиально. В ней фиксируются услуги, которые обсуждаются или предлагаются, и причины их попадания в корзину.
Каталог услуг — база данных или структурированный документ, который используется для заказа и фиксации спроса на услуги. Каталог может быть сложным, потому что существует естественная иерархия услуг: для оказания одних услуг нужны другие.
Иерархия услуг
В многослойной архитектуре предприятия были услуги для клиентов, услуги для поддержки этих услуг и технические услуги. В ITIL 2011 эта иерархия явно определена на двух уровнях:
- пользовательские услуги — их ИТ-организация оказывает заказчикам; заказчики компенсируют затраты;
- поддерживающие услуги — невидимы для внешних заказчиков, но необходимы для пользовательских услуг.
Пример: пользовательская услуга автоматизирует бизнес-процесс с помощью бизнес-приложений. Пользователю неважно, где размещены приложения и как ими управляют. Для ИТ-организации это важно. Если приложения размещают не на своей инфраструктуре, а заказывают внешнюю услугу хостинга или SaaS (Software as a Service — программное обеспечение как услуга), возникает поддерживающая услуга — хостинг, которую оказывает внешний провайдер.
Поддерживающие услуги могут выделять, даже если их оказывают сотрудники ИТ-департамента другим его сотрудникам. Тогда картина такая: у ИТ-департамента есть бизнес-заказчики и роли, отвечающие за взаимодействие с ними, например аккаунт-менеджеры (account managers). Чтобы предлагать решения и собирать требования, они должны понимать, что могут сделать технические специалисты.
Диалог между аккаунт-менеджерами и техническими специалистами идёт через интерфейс внутренних технических услуг. Это даёт естественную иерархию ответственности: видно, кто оказывает поддерживающие услуги, как формируется услуга и какие затраты нужны. Можно точнее посчитать себестоимость услуги, если известны необходимые технические услуги.
Иерархия может быть глубже: технические услуги делятся на более мелкие и низкоуровневые, например связанные с работой платформ, баз данных или специфических приложений. За них могут отвечать отдельные специалисты. Чем подробнее прорисована иерархия услуг, тем понятнее, сколько стоит услуга и стоит ли ею заниматься или лучше управлять требованиями клиентов, чтобы постепенно отказаться от услуги.
Система управления конфигурациями
CMS — не просто набор конфигурационных баз данных. Это набор баз данных и инструментов — организационных, программных или смешанных, — которые управляют конфигурационными данными.
В отличие от ITIL v2, CMS включает информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Иначе говоря, внутри CMS хранится полная история создания и оказания услуг. Туда же входят инструменты сбора, хранения и представления этой информации для принятия решений.
Портфель приложений
Портфель приложений — часть CMS. Это база данных или структурированный документ с ключевыми атрибутами всех приложений. Иногда он реализуется как часть портфеля услуг. Если портфеля услуг не существует, он может быть частью системы управления знаниями об услугах.
ITIL 2011 — референтная модель. Она не выдвигает жёстких требований, а даёт рекомендации. Поэтому портфель услуг может отсутствовать. Тогда должна существовать система управления знаниями об услугах, но ITIL 2011 не уточняет, как она должна выглядеть.
Портфель приложений нужен для грамотного управления приложениями. В ITIL v2 был процесс управления мощностями, он есть и здесь. Приложение — ресурс, который нужно закупать. Его выделяют в отдельную базу данных, потому что приложения существенно отличаются от аппаратного обеспечения или услуг третьих сторон.
О приложениях можно описать многое: что они делают, какую функциональность дают, какие выходы позволяют генерировать. Можно показать связь приложения с бизнес-процессом, который оно автоматизирует. Например, если приложение автоматизирует управление складом, это помогает понять его место и важность в архитектуре предприятия. Многие компании отдельно ведут архитектуру приложений: описывают все приложения, связи между ними, информационные обмены, способы взаимодействия и форматы данных.
Портфель клиентов
Портфель клиентов устроен похоже. У клиентов есть специфические атрибуты и свойства, полезные для портфеля услуг. Например, при формировании воронки услуг каждая услуга, по которой идут переговоры, должна ссылаться на клиента. Информация о клиенте может включать должностное положение, историю взаимоотношений, контактные лица и план работы с клиентом.
Эту информацию удобно хранить отдельно, потому что ею пользуется не только управление портфелем услуг, но и процесс управления взаимоотношениями с клиентами (CRM, Customer Relationship Management). Оба процесса должны получать данные из общего источника.
Портфель клиентских контрактов
Портфель клиентских контрактов — это база договоров или соглашений об уровне обслуживания (SLA, Service Level Agreement). Контракт может быть коммерческим, с большим объёмом сопутствующей информации, или слабо формализованным высокоуровневым соглашением. ITIL не проводит разницы между типами провайдеров и не уточняет эти детали.
Такую базу удобно иметь, потому что к ней обращаются не только процессы управления портфелем услуг, но и финансовые процессы, управление спросом (demand management) и другие.
Портфель проектов
Портфель проектов используется, когда создают, модифицируют, дорабатывают или расширяют услугу. Информацию обо всех таких проектах удобно хранить вместе. Это позволяет видеть, как проекты взаимодействуют, как они направлены на общие цели, строить программу проектов и управлять ею. Без понимания взаимосвязей трудно распределять инвестиции и деньги между взаимодействующими проектами.
Краткие итоги
Управление ИТ-услугами строится не вокруг отдельных устройств или разрозненных договоров, а вокруг связей между спросом, предложением, ответственностью и стоимостью. Ключевая логика — представить все элементы ИТ-деятельности как взаимозависимые портфели, которые описывают разные стороны одной системы. Такой подход позволяет перейти от учёта к управлению: видеть не только текущее состояние, но и историю, причины изменений и влияние на заказчика.
Практическая ценность возникает там, где данные начинают использоваться повторно. Один и тот же клиент, договор или приложение нужны разным процессам: продажам, финансам, управлению спросом, проектам, поддержке. Если эти сведения хранятся раздельно и не связаны, компания теряет целостность. Если они сведены в согласованную систему, появляется возможность считать себестоимость, оценивать риски и принимать решения о развитии или отказе от услуг.
Особую роль играет иерархия услуг. Разделение на пользовательские и поддерживающие уровни помогает увидеть, что ценность для заказчика создаётся не одним подразделением, а цепочкой внутренних поставщиков. Это делает ответственность прозрачной и позволяет управлять требованиями: иногда выгоднее изменить ожидания клиента, чем поддерживать дорогую услугу.
Гибкость модели важна: рекомендательный характер позволяет внедрять только нужные элементы. Но чем меньше формализации, тем выше риск, что знания об услугах останутся разрозненными. Поэтому практический смысл имеет не слепое следование схеме, а создание единого языка и связанных данных, на которых можно строить решения.
Портфель услуг — верхний объект. В него входят: воронка услуг (Service Pipeline), каталог услуг (Service Catalog), услуги, выведенные из эксплуатации (Retired Services). Все они связаны с системой управления конфигурациями (CMS, Configuration Management System).
CMS сложнее, чем конфигурационная база данных (CMDB, Configuration Management Database) в ITIL v2. Она включает:
- совокупность CMDB;
- портфель клиентов;
- портфель приложений;
- систему управления внешними исполнителями;
- портфель клиентских соглашений (договоров, SLA);
- портфель проектов.
CMS — программно-технический комплекс и процессы. Они управляют объектами как единым целым: следят за соответствием, синхронно вносят изменения. CMS также хранит информацию об инцидентах, проблемах, известных ошибках, изменениях, релизах — полную историю создания и оказания услуг — и инструменты для сбора, хранения и представления данных.
Воронка услуг может быть базой данных, структурированным документом, набором файлов или иной структурой. В ней фиксируются услуги и причины попадания в корзину. Каталог услуг — база данных или структурированные документы для заказа и фиксации спроса. Он может быть сложным из-за естественной иерархии услуг: для одних услуг нужны другие.
Иерархия услуг:
- пользовательские услуги — оказываются заказчикам ИТ-организации; заказчики компенсируют затраты;
- поддерживающие услуги — невидимы внешним заказчикам, но необходимы для пользовательских услуг.
Пример: пользовательская услуга автоматизирует бизнес-процесс через приложения. Пользователю неважно, где они размещены. Для ИТ-организации важно. Если приложения размещают у внешнего провайдера, возникает поддерживающая услуга — хостинг или SaaS (Software as a Service). Поддерживающие услуги могут выделять и внутри ИТ-департамента.
Аккаунт-менеджеры взаимодействуют с техническими специалистами через интерфейс внутренних технических услуг. Это даёт иерархию ответственности, позволяет видеть затраты и точнее считать себестоимость услуги. Иерархия может углубляться: технические услуги делятся на более низкоуровневые, связанные с платформами, базами данных, приложениями. Чем подробнее иерархия, тем понятнее стоимость и решение: развивать услугу или управлять требованиями, чтобы отказаться от неё.
Портфель приложений — часть CMS. Это база данных или структурированный документ с ключевыми атрибутами всех приложений. Иногда он входит в портфель услуг. Если портфеля услуг нет, он может быть частью системы управления знаниями об услугах. ITIL 2011 — референтная модель, даёт рекомендации, не жёсткие требования. Если портфеля услуг нет, система управления знаниями об услугах должна быть, но её точный вид ITIL 2011 не уточняет.
Портфель приложений нужен для грамотного управления приложениями. В ITIL v2 был процесс управления мощностями; он есть и в ITIL 2011. Приложение — ресурс для закупки, но специфический, отличается от аппаратного обеспечения и услуг третьих сторон. В портфеле можно описывать функциональность, выходы, связь с бизнес-процессом, место и важность в архитектуре предприятия. Компании часто отдельно ведут архитектуру приложений: приложения, связи, информационные обмены, способы взаимодействия, форматы данных.
Портфель клиентов хранит атрибуты клиентов. В воронке услуг каждая услуга ссылается на клиента. Информация может включать должностное положение, историю взаимоотношений, контактные лица, план работы. Её удобно хранить отдельно, потому что используют и управление портфелем услуг, и управление взаимоотношениями с клиентами (CRM, Customer Relationship Management). Нужен общий источник.
Портфель клиентских контрактов — база договоров или соглашений об уровне обслуживания (SLA, Service Level Agreement). Контракт может быть коммерческим или слабо формализованным. ITIL не уточняет различия. К базе обращаются управление портфелем услуг, финансовые процессы, управление спросом (demand management) и другие.
Портфель проектов используется для создания, модификации, доработки или расширения услуги. Хранение проектов вместе позволяет видеть их взаимодействие, общие цели, строить программу проектов, распределять инвестиции между взаимосвязанными проектами.
1. Портфель услуг включает воронку услуг, каталог услуг и услуги, выведенные из эксплуатации.
2. Система управления конфигурациями объединяет CMDB и дополнительные портфели, а не только конфигурационную базу.
3. CMS управляет объектами как единым целым: следит за соответствием и синхронно вносит изменения.
4. Воронка услуг может быть реализована по-разному: как база данных, документ или набор файлов.
5. Каталог услуг служит для заказа и фиксации спроса на услуги.
6. Иерархия услуг включает пользовательские и поддерживающие услуги.
7. Поддерживающие услуги невидимы заказчику, но необходимы для пользовательских услуг.
8. Выделение внутренних технических услуг помогает точнее считать себестоимость и ответственность.
9. Чем подробнее иерархия услуг, тем понятнее стоимость и решение о развитии или отказе от услуги.
10. Портфель приложений описывает ключевые атрибуты приложений и их связь с бизнес-процессами.
11. Портфели клиентов, контрактов и проектов нужны для повторного использования данных разными процессами.
12. ITIL 2011 даёт рекомендации, а не жёсткие требования, поэтому состав портфелей может варьироваться.
1. Какие три компонента входят в портфель услуг и как они связаны с системой управления конфигурациями?
2. Чем CMS отличается от простой конфигурационной базы данных?
3. Какие дополнительные объекты, кроме CMDB, могут входить в CMS?
4. Какие функции выполняет CMS по отношению к связанным объектам?
5. Какие технические формы может иметь воронка услуг?
6. Для чего используется каталог услуг?
7. В чём суть естественной иерархии услуг?
8. Чем пользовательские услуги отличаются от поддерживающих?
9. Почему для заказчика размещение приложений может быть неважно, а для ИТ-организации важно?
10. Как выделение внутренних технических услуг влияет на расчёт себестоимости?
11. Зачем нужен портфель приложений и что в нём можно описывать?
12. Почему портфели клиентов, контрактов и проектов удобно хранить отдельно?
