AI
Почему SLA так часто превращается в формальную «бумажку» и не работает в реальной жизни ИТ? IT-World разбирался, как превратить соглашение об уровне сервиса в живой инструмент управления — через диалог с бизнесом, осознанные компромиссы и регулярную проверку реальностью. Практические примеры показывают, где SLA ломается и что с этим делать. erid: 2W5zFHsocfi
ООО Р-платформа Реклама
При запуске в эксплуатацию еще одной системы или при наведении порядка новым ИТ-менеджером в «авгиевых конюшнях» неизбежно возникает вопрос: как оценивать качество управления ИТ-сервисом? Казалось бы, ответ простой — внедрите SLA (соглашение об уровне сервиса). SLA позволяет оцифровать ожидания от сервиса и обеспечить единый взгляд на работу ИТ со всех сторон, как многочисленных заказчиков, так и самих исполнителей сервиса. Единообразно оценивать и конструктивно обсуждать качество сервиса, а также планировать его развитие.
Формально — ключевой документ, но почему раз за разом мы видим примеры красивых и детально прописанных соглашений, которые не имеют ничего общего с жизнью? Один из примеров — ситуация в международной компании, в которой есть описание единого на весь мир уровня сервиса, при этом вся локальная специфика закрывается исходя из реальной срочности, а формальные показатели просто подгоняют. Пару раз встречал в своей практике совсем вопиющие случаи — когда о наличии соглашения бизнес просто не знал. В таких случаях SLA не выполняет заявленных выше целей и является бесполезной бумажкой, на составление которой зря потратили время.
Поделюсь ключевыми моментами подхода, в котором работаю сам и рекомендую клиентам.
Содержание:
SLA — это диалог
Это не бумага, которую сделала служба ИТ и принесла бизнесу на утверждение. Это результат детального внутреннего обсуждения ИТ и ключевых бизнес-пользователей, который ИТ, как ответственные за процесс, положили на бумагу.
Ключевое свойство соглашения — понятность для всех участников сделки. Гораздо лучше иметь бумагу на одном листе, которую все понимают и с которой все согласны, чем красивое соглашение, оформленное по ГОСТу. Особенно это важно в компаниях с низкой зрелостью процессов, где сложные бумаги могут и не прочитать.
Как SLA влияет на бизнес
Например, раздел метрик качества в нашем типовом соглашении состоит из 10–15 различных метрик — здесь и среднее время выполнения заявок в разрезе приоритетов, и доля заявок, выполненных в срок (тоже в разрезе приоритетов), и несколько ключевых вопросов из анкетирования пользователей (так называемые качественные метрики оценки удовлетворенности). При этом в ходе обсуждения с одним из ключевых клиентов стало понятно, что в реальности никто оценивать качество нашей работы по этим метрикам не собирается. Важны три простые вещи — стабильная отработка критичных заявок (отгрузка готовой продукции), своевременное закрытие учетного периода (выполнение графика fast close) и непрерывность работы системы. В итоге мы остановились на очень простых метриках:
Из принципа «SLA — это диалог» следует и то, что соглашение просто обязано меняться с течением времени. Во-первых, не факт, что в момент его создания удалось полноценно сформулировать требования к сервису. Во-вторых, меняется бизнес, его приоритеты и ожидания от ИТ-систем и поддержки. И наконец, даже если бизнес не приходит с запросом на изменение сам, не факт, что у нас все хорошо. Поставьте регулярную встречу по выравниванию ожиданий с реальностью хотя бы раз в полгода и проверьте его на прочность. Обзор российского рынка мини-ПК Сервис-деск как фабрика доверия Инна Сенчугова: «Если решение не сокращает издержки и не снижает риски — зачем оно бизнесу?»
Эффект зеленых арбузов: SLA не гарантирует счастливых пользователей
Так, у одного из наших клиентов за первые четыре месяца работы накопилось напряжение между ИТ и бухгалтерским подразделением (ОЦО). На старте поддержки мы в первую очередь сфокусировались на удовлетворении потребностей основного бизнеса — поддержке стабильного процесса «производство/склад/заказы» и ритмичной отгрузки готовой продукции. Интересы же ОЦО были втиснуты в стандартный «бухгалтерский» норматив среднего приоритета и 8 рабочих часов на решение заявки. Уже по итогам первого месяца работы нам пришлось усилиться ресурсом, чтобы проталкивать срочные заявки ОЦО с опережением нормы: иначе, несмотря на выполнение формального SLA, мы получали стабильно негативный фидбек.
Проанализировав процесс, мы увидели, что закрытие не имеет шансов «сходиться» в заданные сроки при текущем нормативе, и вынуждены были вынести бухгалтерские заявки по закрытию в высокий приоритет и установить двухчасовой норматив. Приведя бумагу в соответствие с жизнью, далее получилось разбирать возникающие проблемы уже с опорой на SLA, причем и сторона бизнеса начала мерить ИТ той же меркой. Ситуация, когда стороны не слышат друг друга («Мы выполняем SLA» / «Вы работаете плохо»), ушла.
SLA — это компромисс
Идеальный процесс будет стоить бесконечных денег, и роль ИТ-менеджера — донести это понимание до бизнес-пользователей, совместно с ними разделить процессы по степени критичности и трезво оценить уровни сервиса для каждого процесса. И эта гибкость может быть проявлена во всех аспектах соглашения. Например, раздел с графиком работы. Как мы знаем, бухгалтерия часто работает с переработками, и, разумеется, они ожидают, что эта практика распространится и на ИТ-поддержку. Рынок труда в ИТ непрост для работодателя, и вывод людей в сменный график до 8–9 вечера на постоянной основе очевидно приведет к необходимости дополнительной штатной единицы и оплате переработок. Зафиксировать расширенный график и тратить деньги на поддержку слабо организованного процесса? Неразумно. Договориться с бизнес-заказчиком и ввести расширенный график до 21:00 на три пиковых дня закрытия периода, как сделала ИТ-служба у одного из наших клиентов, — взрослое решение.
В качестве другого, встречного, примера возьмем раздел с зонами ответственности. Для всех очевидно, что сотрудники ИТ не могут вносить правки в первичные документы в системе, поскольку это нарушает аудиторский след: главный бухгалтер не может отвечать за корректность отчетности, если первичку правит «кто попало». Однако если мы живем в легаси-мире 1С и у нас есть процедура перепроведения документов, запускаемая службой поддержки 24*7, в основном в нерабочее время (чтобы не замедлять систему во время пиковой нагрузки), то переложить внесение технических правок (документ расхода по ошибке встал по времени раньше документа прихода) на специалиста поддержки, чтобы не тянуть несколько часов до выхода бухгалтеров в рабочий день и сократить график закрытия, — тоже пример разумного и гибкого подхода. Конечно, это требует отражения и в SLA. Читайте также
Офисные пакеты: изучаем редакторы от Google, Яндекс и Р7 офис Онлайн-офис больше не экзотика, но насколько он действительно готов заменить привычные «тяжелые» решения? IT-World сравнил новые браузерные редакторы Яндекса с Р7 Офис и Документами Google — по функционалу, скорости, совместной работе и реальной пригодности для повседневных задач. Выясняем, где минимализм и ИИ помогают работать, а где без «взрослого» офиса все еще не обойтись.
Наконец, такую же гибкость можно проявить и в приоритетах. Несвоевременная сдача регуляторной отчетности в компаниях финансового сектора подобна смерти. Поэтому с одним из представителей этой отрасли у нас в SLA включены две матрицы приоритетов: одна обычная, регулярная, и вторая — на период сдачи отчетности. В ней любые заявки, которые могут привести к задержке отчетности, повышены до критического приоритета, а все остальные на этот период понижаются до среднего и ниже. Операционные подразделения, которые не отвечают за отчетность, также проявили компромиссный подход и согласились с этим временным понижением. Это простое решение позволяет не раздувать стоимость поддержки.
***
Если резюмировать, серебряной пули в составлении SLA не существует, и единого стандарта, который достаточно только заполнить, быть не может. Уметь и хотеть слушать, договариваться и формулировать условия, удобные для обеих сторон, — этого вполне достаточно для создания годного SLA. А дальше — постепенное оттачивание его о реальную жизнь.
Журнал IT Manager
Дмитрий МалыгинУправляющий партнер компании ФТОСервисные услугиКонтроль качества