Проектирование и разработка услуг в ITIL 2011
Схема услуг и место Service Design
В ITIL 2011 часто используются иллюстрации, которые повторяют текст. Одна из полезных схем показывает организацию или бизнес, оказывающую бизнес-услуги A, B, C клиентам. Внутри этих бизнес-услуг работают бизнес-процессы, которые создают услуги и управляют ими. Бизнес-процессы получают ИТ-услуги A, B, C, D, E, F, G. Одни ИТ-услуги обслуживают один бизнес-процесс, другие — несколько. В стороне SLA (Service Level Agreement, соглашение об уровне услуг) описывает эти услуги. Внизу большой сиреневый прямоугольник обозначает провайдера услуг. Внутри него находится процесс Service Design (проектирование услуг). Он работает с ИТ-услугами A–G, получает информацию о бизнес-процессах, например от Business Process 1, формирует и затем использует SLA. Service Design взаимодействует с процессами из других книг ITIL 2011: стратегическими процессами, Service Transition (развёртывание услуг), Service Operation (оказание услуг) и Continual Service Improvement (непрерывное улучшение услуг). Также он использует информацию из Service Knowledge Management System (SKMS, система управления знаниями об услугах). В SKMS входят портфель услуг, каталог услуг и информационные объекты, которые применяют процессы проектирования и разработки услуг. Справа на схеме показаны, например, система управления дизайном, информация для менеджмента и соответствующие инструменты. Схема не добавляет новых идей, а лишь наглядно связывает уже описанные элементы.
Проектирование и разработка услуг
Работа с портфелем услуг завершается подписанием устава и передачей услуги в разработку: запускается проект, группа проектов, программа или длительный процесс оказания услуги. Требования к новым услугам или к изменениям существующих поступают из портфеля услуг. Каждое требование анализируется, документируется и согласуется. Затем разрабатывается решение для услуги. Оно должно соответствовать стратегиям и ограничениям, в том числе стратегии услуг. Нужно обеспечить совместимость новой или изменённой услуги с остальными услугами. Все услуги, которые взаимодействуют с ней или зависят от неё, также должны быть приведены в соответствие. В ITIL 2011 эта мысль повторяется с разных сторон.
Анализ процессов
Процессы анализируются, чтобы убедиться: они, включая роли, ответственность и умения, могут выполнять и поддерживать новую или изменённую услугу. Если нет, пересматривают либо услугу, либо процессы. Процесс управления услугой или процесс создания услуги должен быть доступен для анализа заказчику. Для заказчика процесс — единственный источник информации об услуге, потому что услугу нельзя материально осязать или ощутить. Услуга — результат выполнения процессов. Глядя на процессы, заказчик может формулировать требования к услуге и даже потребовать изменения процессов, если считает, что так работать не нужно. Это относится не только к стадии проектирования и разработки, но и ко всем процессам на протяжении жизненного цикла. Заказчик должен иметь возможность видеть, анализировать и изменять их. Метрики здесь отдельно не комментируются.
Источники требований к услуге
Структура услуги в схеме: в центре — услуга; сверху — источники требований к ней; сбоку — Policy, Strategy, Governance (политики, стратегии, управление); снизу — Infrastructure, Environment, Data, Applications (инфраструктура, среда, данные, приложения). Нижние элементы показывают ресурсы, используемые для оказания услуги. Белые прямоугольники — документы SLA, Service Management Processes (процессы управления услугами), описания процессов управления услугами внешних подрядчиков и источники вспомогательных услуг. Внизу также показаны Support Teams (команды поддержки) и Suppliers (поставщики). Слева расположены группы требований и групп метрик, соответствующие объектам справа. Например, Assets Resources (активы и ресурсы) относятся к инфраструктуре, окружающей среде, данным и приложениям. Assets Capability (активы и способности) относятся к внешним поставщикам, у которых есть свои активы и способности, и к внутренней команде поддержки, у которой есть технические активы и способности управлять ими. В этом и состоит смысл схемы: она показывает, как и почему требования к услуге структурируются именно так.
Краткие итоги
Практическая ценность изложенного подхода в том, что услуга рассматривается не как изолированный объект, а как узел взаимных обязательств между бизнесом, ИТ-провайдером, поставщиками и командами поддержки. Это позволяет выстраивать проектирование и разработку услуг от требований, а не от технологий. Центральная логика такова: источником изменений служит портфель услуг, где фиксируются новые потребности и модификации. Далее требования проходят анализ, документирование и согласование, после чего решение проверяется на соответствие стратегии и ограничениям. Ключевой практический фильтр — совместимость с другими услугами и зависимыми процессами. Если её не проверить, изменение одной услуги может нарушить смежные обязательства и уровни сервиса. Поэтому проектирование должно охватывать не только саму услугу, но и всё, что с ней связано.
Второй практический контур — анализ процессов. Недостаточно описать будущую услугу; нужно доказать, что процессы, роли, ответственность и умения смогут её выполнять и поддерживать. Если это невозможно, пересматривается либо услуга, либо процесс. Заказчик при этом должен видеть процесс, поскольку для него процесс — единственный доступный источник информации об услуге. Это превращает прозрачность процессов в инструмент управления ожиданиями и требованиями. Возможность заказчика анализировать и инициировать изменения процессов должна сохраняться на всём жизненном цикле, а не только на старте.
Третий контур — знания и структура требований. Система управления знаниями об услугах связывает портфель, каталог и информационные объекты, необходимые для проектирования. Это снижает разрывы между стратегией, дизайном и эксплуатацией. Группировка требований по ресурсам, активам, способностям, поставщикам и командам поддержки помогает не потерять важные аспекты: инфраструктуру, среду, данные, приложения, внешние зависимости и внутренние компетенции.
На практике такой каркас можно применять для проверки полноты требований, назначения ответственности, проектирования SLA и оценки реализуемости услуги. Он также помогает отделять существенные изменения от косметических и заранее выявлять конфликты между услугами, процессами и поставщиками. В результате управление услугами становится связной системой решений, где каждое требование прослеживается до ресурса, процесса и обязательства, а не остаётся локальной инициативой.
В ITIL 2011 схема показывает организацию или бизнес, которая оказывает бизнес-услуги A, B, C клиентам. Внутри бизнес-услуг работают бизнес-процессы, создающие и управляющие этими услугами. Бизнес-процессы получают ИТ-услуги A–G. Одни ИТ-услуги обслуживают один бизнес-процесс, другие — несколько. SLA (Service Level Agreement, соглашение об уровне услуг) описывает эти услуги. Внизу большой сиреневый прямоугольник — провайдер услуг. В нём находится Service Design (проектирование услуг). Он работает с ИТ-услугами A–G, получает информацию о бизнес-процессах, формирует и использует SLA. Service Design взаимодействует со стратегическими процессами, Service Transition (развёртывание услуг), Service Operation (оказание услуг) и Continual Service Improvement (непрерывное улучшение услуг). Он использует Service Knowledge Management System (SKMS, система управления знаниями об услугах). В SKMS входят портфель услуг, каталог услуг и информационные объекты для проектирования и разработки. Справа — система управления дизайном, информация для менеджмента и инструменты.
Работа с портфелем услуг завершается подписанием устава и передачей услуги в разработку: проект, группа проектов, программа или длительный процесс оказания услуги. Требования к новым или изменённым услугам поступают из портфеля. Каждое требование анализируется, документируется и согласуется. Затем разрабатывается решение. Оно должно соответствовать стратегиям и ограничениям, включая стратегию услуг. Нужно обеспечить совместимость услуги с другими услугами. Все услуги, которые взаимодействуют с ней или зависят от неё, должны быть приведены в соответствие.
Процессы анализируются, чтобы убедиться: они, включая роли, ответственность и умения, могут выполнять и поддерживать новую или изменённую услугу. Если нет, пересматривают услугу или процессы. Процесс управления услугой или создания услуги должен быть доступен заказчику для анализа. Для заказчика процесс — единственный источник информации об услуге, потому что услугу нельзя материально осязать; она результат выполнения процессов. Заказчик может формулировать требования и требовать изменения процессов. Это относится ко всем процессам на протяжении жизненного цикла: заказчик должен видеть, анализировать и менять их.
Требования к услуге структурируются по источникам и объектам. В центре — услуга. Сверху — источники требований. Сбоку — Policy, Strategy, Governance (политики, стратегии, управление). Снизу — Infrastructure, Environment, Data, Applications (инфраструктура, среда, данные, приложения) — ресурсы для оказания услуги. Белые прямоугольники — документы SLA, Service Management Processes (процессы управления услугами), описания процессов внешних подрядчиков и источники вспомогательных услуг. Внизу показаны Support Teams (команды поддержки) и Suppliers (поставщики). Слева — группы требований и метрик, соответствующие объектам справа. Assets Resources (активы и ресурсы) относятся к инфраструктуре, среде, данным и приложениям. Assets Capability (активы и способности) относятся к внешним поставщикам с их активами и способностями и к внутренней команде поддержки с техническими активами и способностями управлять ими.
1. Service Design связывает бизнес-услуги, бизнес-процессы, ИТ-услуги, SLA и провайдера услуг.
2. SKMS содержит портфель услуг, каталог услуг и информационные объекты для проектирования.
3. Service Design взаимодействует со стратегическими процессами, Transition, Operation и CSI.
4. Требования к новым или изменённым услугам поступают из портфеля услуг.
5. Каждое требование анализируется, документируется и согласуется до разработки решения.
6. Решение должно соответствовать стратегиям и ограничениям, включая стратегию услуг.
7. Новую или изменённую услугу нужно проверять на совместимость с другими услугами.
8. Зависимые и взаимодействующие услуги должны быть приведены в соответствие с изменением.
9. Процессы анализируются на способность выполнять и поддерживать услугу с учётом ролей и умений.
10. Если процессы не готовы, пересматривают услугу или процессы.
11. Заказчик должен видеть и анализировать процессы; услуга нематериальна и познаётся через процессы.
12. Требования группируются по ресурсам, активам, способностям, поставщикам и командам поддержки.
1. Что обозначает большой сиреневый прямоугольник на схеме?
2. Какие элементы входят в SKMS?
3. С какими группами процессов ITIL взаимодействует Service Design?
4. Чем завершается работа с портфелем услуг перед передачей услуги в разработку?
5. Откуда поступают требования к новым или изменённым услугам?
6. Что делают с каждым требованием до разработки решения?
7. Чему должно соответствовать решение для услуги?
8. Почему важно проверять совместимость услуги с другими услугами?
9. Что проверяют при анализе процессов?
10. Что делать, если процессы не могут поддерживать услугу?
11. Почему заказчику важен доступ к процессам?
12. Как группируются требования к услуге и с чем они соотносятся?
