Трудна дорога от правды к истине.
Сергей Довлатов. Компромисс.

Любой проект – компромисс. Между желаниями и возможностями, планами и реальностью, сроками и охватом проекта. Иногда приходится идти и на более принципиальные компромиссы, чтобы достичь значимого результата за конечное время. Для ITSM такой принципиальный компромисс – исключение из области охвата управления уровнем ИТ-услуг вопросов разработки новой функциональности информационных систем.

С точки зрения классического ITSM это, конечно, тот еще трюк. Он не понятен заказчикам: «Как это вы опять не можете гарантировать мне время разработки? Зачем тогда мне SLA, ведь существующая функциональность и так работает, а гарантировать, что она будет работать лучше вы все равно не можете?». Он не очень понятен и самому поставщику ИТ-услуг, поскольку предполагает заключение SLA без соответствующей фазы проектирования (всех этих замечательных штук – SLR, SAC, …). Тем не менее, такой подход применяется на практике, и довольно широко.

Основная причина – объем и сложность организационных изменений, которые необходимо провести для реализации полноценного сервисного управления. В большинстве известных мне компаний ИТ-подразделение включает в себя две относительно автономные функции – разработку (Change the business) и сопровождение / эксплуатацию (Run the business). Они управляются разными людьми, по разным правилам, имеют разные точки входа для потребителей ИТ-услуг, взаимодействуют посредством управления изменениями и релизами (изменениями – со стороны «эксплуататоров», релизами – со стороны разработчиков), а также при устранении инцидентов и проблем. Разработчикам заказывают изменения в ПО, «эксплуататоры» обеспечивают целостность систем при развертывании разработок и максимальную доступность в ходе эксплуатации.

Взаимодействие разработки и эксплуатации на уровне операционных процессов (управление инцидентами, проблемами, изменениями) организуется несложно. Но организовать сквозную ответственность за ИТ-услуги, охватывающую и разработку, и эксплуатацию, – действительно масштабная задача. Потребуется пересмотр организационной структуры ИТ-подразделения (от функциональной к доменной), существенное усиление и развитие роли бизнес-аналитиков (именно они становятся менеджерами ИТ-услуг, обеспечивающих развитие и поддержание бизнес-процессов в своем бизнес-домене), формирование каталога ИТ-услуг от бизнес-процессов, умение осуществлять мониторинг бизнес-процессов (частично мы уже касались этой темы в моем вебинаре «Управление изменениями и релизами: один или два процесса?»). Однако именно такой подход позволяет ближе всего подобраться к ИТ-услуге, как к способу предоставления ценности заказчику, и к управлению отношениями между ИТ и бизнесом, построенными на сервисных принципах. Во всяком случае это справедливо для тех видов бизнеса, где зависимость от ИТ и потребность в их изменениях весьма высоки (банки, ритейл, инвестиционные услуги, …).

Буду честен – работая с крупным бизнесом, я знаю единицы компаний, которые идут по этому пути. Большинство идет на компромисс: Application lifecycle management (ALM) – для разработки, IT service management (ITSM) – для эксплуатации / сопровождения. Однако чем дальше, тем больше я думаю, что такой компромисс оправдан только если он используется в качестве временной меры, если ИТ-руководители стратегически нацелены на расширение сервисного подхода на разработку. Иначе управление уровнем ИТ-услуг заведомо принесет меньше пользы (чем написано в книжках) обеим сторонам – и ИТ-подразделению, и потребителям ИТ-услуг. И почему бы вообще в этом случае не отказаться от SLM, ограничившись реализацией оперативных процессов управления? Это соответствует уровню зрелости «Controlled» согласно модели «KPMG maturity phases model of the IT organisation», и может быть в данном случае это наиболее адекватная оценка? И может быть этого достаточно?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности