Процессы управления услугами и каталог услуг
Управление каталогом услуг (Service Catalog Management) — процесс, связанный с ведением каталога услуг. По мере разработки услуги информация о ней может появляться в каталоге. По-хорошему, услугу следует помещать в каталог только тогда, когда она полностью закончена и готова к передаче в эксплуатацию, но на практике это часто не так.
Обычно уже на фазе окончания разработки, опытно-промышленной эксплуатации или развёртывания в каталоге есть запись об услуге со статусом «в работе». Услуга ещё не готова, но уже понятно, что она будет и когда она будет. Это позволяет заказчикам гибче взаимодействовать с организацией.
Управление уровнем услуг
Управление уровнем услуг (Service Level Management) — деятельность по сбору требований в ходе проектирования и разработки и трансформации этих требований в SLA (Service Level Agreement, соглашение об уровне услуг).
Управление мощностями и доступностью
Управление мощностями (Capacity Management) нужно на протяжении всего процесса создания услуги и всего её жизненного цикла. Непрерывно требуются новые, более производительные и более мощные мощности.
Управление доступностью (Availability Management) — по смыслу тот же процесс, который используется в ITIL v2 (IT Infrastructure Library version 2).
Координация проектирования
Координация проектирования (Design Coordination) — первый процесс, о котором стоит сказать отдельно. Он обеспечивает единую точку координации и управления всеми активностями и процессами на протяжении всей фазы проектирования услуги.
В проектировании и разработке участвуют целые группы специалистов: архитекторы, проектировщики, программисты, тестировщики, бизнес-аналитики и другие. Это может быть один человек, группа людей или несколько групп. Координация регламентирует эту деятельность через создание и доведение до всех участников документов, политик, корпоративных правил, корпоративных ограничений и нормативных документов.
Зачем это сделано? Чтобы у руководства организации был рычаг воздействия на качество услуг, находящихся в разработке. Руководство должно иметь возможности влиять на деятельность по созданию услуги.
Если бы речь шла о бизнес-процессах, можно было бы опираться на стандартизированный процесс, например управление проектами по PMBOK (Project Management Body of Knowledge) или PRINCE2. Но описываемые здесь процессы — не бизнес-процессы в строгом смысле. У них широкие и неформальные границы. Стандартного описания на все случаи жизни быть не может.
Поэтому вводятся хотя бы политики и нормативные документы, которые не дают людям совсем отклоняться от общекорпоративных правил. Это единственный способ обеспечить единый уровень качества всех разных услуг ИТ-организации. Если общих документов, регулирующих процессы разработки услуг, нет, каждая услуга будет создаваться по-своему, и результат станет непредсказуемым. Координация проектирования хотя бы в слабом виде поддерживает связи между услугами и способами их разработки.
Другие процессы
Управление непрерывностью услуг (IT Service Continuity Management) — знакомый процесс. По сравнению с ITIL v2 в нём нет абсолютно нового.
Управление информационной безопасностью (Information Security Management) также рассматривается в этом контуре.
Управление поставщиками (Supplier Management) в ITIL v2 отсутствовало. Здесь сформулированы некоторые общие принципы управления поставщиками. Это позволяет обеспечивать одинаковый уровень качества работ поставщиков, а значит, и услуг, которые используют услуги поставщиков.
Как читать схему
Внизу расположен длинный прямоугольник со многими стрелочками, которые идут к названиям процессов. Выше находятся прямоугольники с названиями: Service Catalog Management, Design Coordination, Service Level Management и другими. От них идут косые стрелочки, показывающие, в чём состоит процесс и что он делает. Такова логика чтения рисунка.
Краткие итоги
Практический смысл управления услугами на этапе проектирования состоит в превращении разрозненной работы специалистов в управляемый поток решений. Каталог услуг выполняет роль витрины и инструмента коммуникации: даже неготовая услуга со статусом «в работе» даёт заказчику ориентир, снижает неопределённость и позволяет планировать взаимодействие. Управление уровнем услуг связывает требования с измеримыми обязательствами, поэтому качество перестаёт быть субъективным. Управление мощностями и доступностью задаёт рамки реализуемости: без ресурсов и надёжности обещания остаются декларациями.
Особую роль играет координация проектирования. Она не подменяет работу архитекторов, аналитиков, разработчиков и тестировщиков, а создаёт общий контур правил, политик и нормативных документов. Это нужно потому, что процессы проектирования услуг плохо сводятся к жёстким бизнес-процессам: их границы подвижны, а универсального стандарта на все случаи нет. Руководство получает рычаг влияния на качество через общие требования и ограничения, а не через точечное вмешательство. Тем самым поддерживается сопоставимый уровень качества разных услуг.
Управление непрерывностью, информационной безопасностью и поставщиками расширяет этот контур за пределы внутренней разработки. Оно показывает, что качество услуги зависит не только от собственных команд, но и от устойчивости, защищённости и внешних исполнителей. Управление поставщиками особенно важно там, где услуга собирается из чужих компонентов: единые принципы работы снижают разрывы ответственности.
Практическое применение такого подхода — создание прозрачной системы управления жизненным циклом услуги. Сначала фиксируются требования и ожидания, затем они переводятся в SLA, подкрепляются мощностями и доступностью, защищаются с точки зрения безопасности и непрерывности, а поставщики включаются в общие правила. Координация проектирования удерживает целостность. Если этот контур отсутствует, услуги развиваются несогласованно, качество становится случайным, а руководство теряет возможность влиять на результат до эксплуатации. Если контур есть, даже неполные стандарты и политики дают управляемость, предсказуемость и основу для дальнейшего совершенствования.
В управлении услугами на этапе проектирования и разработки рассматриваются несколько процессов. Управление каталогом услуг отвечает за ведение каталога. Идеально включать услугу в каталог после полной готовности, но на практике запись появляется раньше — на фазе окончания разработки, опытно-промышленной эксплуатации или развёртывания. Услуга может стоять со статусом «в работе». Это помогает заказчикам понимать, что услуга будет и когда, и гибче взаимодействовать с организацией.
Управление уровнем услуг собирает требования в ходе проектирования и разработки и превращает их в SLA — соглашения об уровне услуг. Управление мощностями обеспечивает новые, более производительные мощности на протяжении всего жизненного цикла услуги. Управление доступностью по смыслу совпадает с процессом в ITIL v2.
Отдельно выделяется координация проектирования. Она даёт единую точку координации и управления всеми активностями и процессами на всей фазе проектирования услуги. В проектировании участвуют архитекторы, проектировщики, программисты, тестировщики, бизнес-аналитики и другие. Это может быть один человек, группа или несколько групп. Координация регламентирует деятельность через документы, политики, корпоративные правила, ограничения и нормативные документы.
Зачем это нужно? Чтобы у руководства был рычаг воздействия на качество услуг, находящихся в разработке. Если бы речь шла о бизнес-процессах, можно было бы использовать стандартизированный процесс, например управление проектами по PMBOK или PRINCE2. Но описываемые процессы — не строгие бизнес-процессы: у них широкие и неформальные границы, и стандартного описания на все случаи нет. Поэтому хотя бы политики и нормативные документы не дают участникам отклоняться от общекорпоративных правил. Это единственный способ обеспечить единый уровень качества разных ИТ-услуг. Без общих документов каждая услуга создавалась бы по-своему, и результат был бы непредсказуем. Координация проектирования хотя бы слабо поддерживает связи между услугами и способами их разработки.
Управление непрерывностью услуг — знакомый процесс, без принципиальных отличий от ITIL v2. Управление информационной безопасностью также входит в этот контур. Управление поставщиками в ITIL v2 отсутствовало; здесь сформулированы общие принципы, позволяющие выравнивать качество работ поставщиков и услуг, которые эти работы используют.
На схеме внизу расположен прямоугольник со стрелками к названиям процессов. Выше — прямоугольники с названиями процессов, например Service Catalog Management, Design Coordination, Service Level Management. От них идут косые стрелочки, показывающие, что делает процесс. Так схема связывает процессы с их содержанием.
1. Каталог услуг может содержать запись об услуге до её готовности; статус «в работе» информирует заказчиков и повышает гибкость взаимодействия.
2. Управление уровнем услуг переводит требования проектирования в SLA.
3. Управление мощностями обеспечивает ресурсы на всём жизненном цикле услуги.
4. Управление доступностью повторяет логику ITIL v2.
5. Координация проектирования — единая точка управления активностями фазы проектирования.
6. Координация нужна для влияния руководства на качество разрабатываемых услуг.
7. Процессы проектирования услуг не являются строгими бизнес-процессами с формальными границами.
8. Политики и нормативные документы не дают участникам отклоняться от общекорпоративных правил.
9. Общие документы — способ обеспечить единый уровень качества разных ИТ-услуг.
10. Без координации услуги создавались бы по-своему, результат был бы непредсказуем.
11. Управление поставщиками добавлено относительно ITIL v2 и помогает выравнивать качество работ поставщиков.
12. Схема показывает процессы, а косые стрелки раскрывают их содержание.
1. Что такое управление каталогом услуг?
2. Почему информация об услуге может появляться в каталоге до завершения разработки?
3. Какой статус может иметь услуга в каталоге, пока она не готова?
4. Как управление уровнем услуг связано с SLA?
5. Что происходит с требованиями в ходе проектирования и разработки?
6. Для чего нужно управление мощностями на протяжении жизненного цикла услуги?
7. Чем управление доступностью в рассматриваемом контексте похоже на ITIL v2?
8. Какую задачу решает координация проектирования?
9. Кто участвует в проектировании и разработке услуги?
10. Почему процессы проектирования услуг не описываются как строгие бизнес-процессы?
11. Зачем руководству политики и нормативные документы в координации проектирования?
12. Что даёт управление поставщиками и почему его не было в ITIL v2?
