Выводы по проектированию и разработке услуг

Записаться

Границы ITIL 2011

В ITIL (IT Infrastructure Library) 2011, кроме общих слов, об этом ничего не говорится. Жаль: сказав «а», следовало бы сказать и «б».

Какие выводы по проектированию и разработке услуг можно сделать?

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

Таким образом, ITIL 2011 установил для себя границу. Она проходит по процессам, которые описывают жизненный цикл ИТ-услуг и управление этим жизненным циклом.

SLA

ITIL трактует SLA (Service Level Agreement, соглашение об уровне услуги) только как соглашение, фиксирующее договорённости, и не вкладывает в него иного смысла.

Управление изменениями и релизами

Управление изменениями в системе соглашений и контрактов специально не рассматривалось. В ITIL есть соответствующее место, но оно устроено просто: существуют релизы (releases), все изменения собираются в пакеты, затем эти пакеты обрабатываются в заранее согласованные даты.

Внешние поставщики

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

Краткие итоги

ITIL 2011 задаёт рамку, а не исчерпывающую методологию. Его практический смысл — в сознательном самоограничении: организация получает ориентир для управления жизненным циклом ИТ-услуг, но не должна ждать от ITIL готовых ответов на вопросы разработки информационных систем, программной инженерии или управления проектами. Такое разграничение снижает риск подмены инженерных и проектных дисциплин сервисными практиками. Оно также показывает, где требуется стыковка разных систем управления: сервисной, проектной и продуктовой.

Если граница проходит по жизненному циклу услуг, то всё, что связано с созданием и развитием систем, должно быть описано отдельно. Иначе возникает разрыв: услуга управляется по одним правилам, а её создание и изменение — по другим, часто не связанным с ней. Практический вывод — заранее определить интерфейсы между сервисными процессами и процессами разработки, проектирования и управления проектами. Это позволяет не дублировать ответственность и не терять управляемость на стыках.

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

Упрощённая схема управления изменениями через релизы показывает ставку на пакетную обработку и календарную дисциплину. Это снижает хаос, но требует зрелого планирования: нужно уметь группировать изменения, оценивать их совместимость и соблюдать согласованные даты. Для практики важно, чтобы пакеты не становились самоцелью и не задерживали критичные изменения.

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

Таким образом, ценность ITIL 2011 заключается не во всеохватности, а в ясном обозначении границ. Это помогает правильно распределить ответственность, не предъявлять к сервисной методологии лишних ожиданий и осознанно достраивать недостающие практики там, где они действительно нужны.