Когда люди задумываются об организации процесса управления уровнем услуг, они сразу вспоминают несколько ключевых документов SLM. И среди них, как правило, возникают: каталог услуг (с делением на бизнес-услуги и технические услуги), SLA и OLA. Эта ассоциация между процессом и его документами весьма устойчива. И, по крайней мере, иногда (будем аккуратны в формулировках) срабатывает сама собой, без размышления на тему необходимости этих самых документов в данном конкретном случае.
Начнём с технических услуг и OLA. По-серьёзному это конечно разговор не на 5 минут. Но если быть кратким, наличие каталога технических услуг и OLA почти всегда недооценивается по последствиям в виде влияния на другие процессы, отношения между подразделениями и даже на оргструктуру. Такая практика управления применима далеко не ко всем компаниям. То есть уточню: сервисный подход вообще применим лишь к небольшому количеству компаний (из тех, что известны мне), и только к очень небольшой доле из этого маленького количества компаний применима практика ведения каталога технических услуг и OLA. О том, что с этим надо быть осторожнее, как-то давно (2006?) писал Pink elephant, а относительно недавно (2011) – IT Skeptic. Подтверждает это и наша проектная практика.
Теперь про каталог бизнес-услуг и SLA. Здесь тоже нет единственно верной дороги. Сам по себе каталог услуг с различными уровнями обслуживания по каждой услуге фактически востребован только в сценариях массового обслуживания – когда у одной услуги может быть множество заказчиков, каждый – на своём уровне. В случае внутреннего ИТ-подразделения довольно часто мы имеем одного заказчика, в качестве которого выступает основной бизнес (в виде одного или нескольких подразделений). Да и технические возможности по варьированию уровня услуги также ограничены (поскольку используется единая инфраструктура). В этом случае отделение бизнес-услуг от SLA может быть излишним. Фактически сам каталог услуг становится «каталогом SLA» (а приложением к SLA идут внешние спецификации услуг).
Поэтому стандартное восприятие продуктов (outcomes) SLM как «два каталога услуг + SLA + OLA» имеет довольно ограниченное применение. Это вдвойне важно осознавать в случае, когда сам процесс управления уровнем услуг в основном воспринимается как процесс, который готовит и актуализирует эти документы. Хотя, на мой взгляд, это не составляет и половины содержания SLM как процесса 🙂
«Контора пишет!», как говорил один известный персонаж.
что-то я в понедельник не уловил глубокую мысль статьи ? 🙂
SLM – это нечто большее чем каталог услуг + SLA + OLA ? это идея?