Обсуждали недавно интересный вопрос, касающийся договоренностей с бизнесом об уровне ИТ-сервисов. Допустим, для простоты, что уровень ИТ-сервиса включает в себя только характеристики поддержки. Например:
- время поддержки
- время решения инцидентов
И пусть мы в соглашении об уровне ИТ-сервиса фиксируем долю инцидентов решенных в обещанные сроки. Построить отчетность по времени решения инцидентов и соблюдению сроков довольно просто, любая система автоматизации нам это легко сделает. Да и с точки зрения процесса все более-менее понятно. Звонят пользователи, регистрируются и решаются инциденты, считаются сроки.
Но как только мы начинаем работать еще и с инфраструктурными инцидентами (сбоями), которые пришли не от пользователей, а стали известны, например в результате мониторинга. Тут же возникает вопрос, как объективно отразить из наличие в соглашениях с бизнесом.
Приведу пару примеров:
1. Вышел из строя почтовый сервер. Пользователи звонят, мы восстанавливая ИТ-сервис "Электронная почта" (пусть для простоты у нас такой есть :)) решим инциденты восстановив сервер. В отчетах по ИТ-сервису "Электронная почта" будут фигурировать вовремя решенные инциденты.
2. Отключилось электропитание на одной из площадок. Т.е. не просто ИТ-сервисы перестали предоставляться, а жизнь полностью встала. Пользователи не могут даже чайник вскипятить. Возможно они будут звонить в ИТ со словами "мы не можем работать в программе ABCDE", но это вряд ли. И допустим, что питания нет, т.к. перерубили кабель, который будут восстанавливать пару дней. Что будет в отчетах по ИТ-сервисам? По-идее все прекрасно, пользователи не звонят, инцидентов нет. ИТ-сервис как предоставлялся, так и предоставляется. Фактически же картина другая.
Выход? Для того чтобы отражать фактическое состояние дел надо включать в условия соглашения возможные перерывы в предоставлении ИТ-сервиса. Видится, что в соглашении можно описать тремя параметрами, понятными бизнесу:
- максимальная продолжительность одного перерыва
- частота перерывов
- суммарная длительность перерывов за период (например, за месяц)
Остается только понять, какие сервисы перестанут предоставляться, если площадка оказалась без электричества или каналов связи. Но это уже дело техники 🙂
“Для того чтобы отражать фактическое состояние дел надо включать в условия соглашения возможные перерывы в предоставлении ИТ-сервиса”
Ну да, так и есть. Деятельность по эксплуатации можно принципиально описать тремя KPI – по обработке обращений пользователей, по доступности VBF, по удовлетворённости заказчиков / ключевых потребителей услуг (давным-давно такую схему предлагал Гартнер). Учёт и анализ инфраструктурных инцидентов как раз позволяет выйти на второй KPI – по доступности (в отличие от индивидуальных обращений пользователей, которые годятся только для первого KPI). Классика жанра.
“в соглашении можно описать тремя параметрами, понятными бизнесу”
Зачем три? Достаточно два:
1. максимальная продолжительность одного простоя;
2. суммарная длительность простоев за период.
Частота не нужна (да и договориться о частоте простоев, вероятно, будет не просто).