Рано или поздно при организации технической поддержки в более или менее крупной организации приходится иметь дело вот с этим: с SLA.
И тут возникает ряд задач, успешно решив которые можно сильно упростить себе жизнь.
Итак предположим, что в нашей организации есть следующие подразделения, помимо ИТ:
- администрация-руководство и девушки-секретари им всячески помогающие,
- продавцы — желающие работать удалённо, "бо волка ноги кормят",
- логисты — ведающие закупками/складом/поставками/транспортом, и желающие жить неплохо,
- бухгалтерия — учёт всего в денежном выражении,
- кадры — решение всех вопросов с наймами, отпусками, отсутвиями и здоровьем персонала,
- безопасность — чтобы ничего не спёрли,
- маркетологи — как же сайту без них.
И пусть у нас есть каталог сервисов из 11 позиций:
- рабочие места,
- печать,
- 1С склад,
- 1С бухгалтерия и кадры,
- Office-софт,
- сайт,
- Интернет,
- Внутренняя сеть,
- Телефония,
- Видеонаблюдение и СКУД,
- VPN — удалённые рабочие места.
Так вот, если хочется сделать все по науке, но не особо вдаваться в суть процессов организации поддержки, то придётся заключить достаточно много SLA т.к. каждому подразделению нужен свой набор сервисов со своими в общем-то условиями поддержки, которых минимум бывает два: VIP и стандарт, но возможны и другие варианты, особенно если компания расположена в нескольких часовых поясах.
И становится видно, что даже такое небольшое количество базовых параметров способно легко породить порядка 60 SLA. То есть, конечно соглашений с подразделениями будет 7, но в каждом по 7-10 сервисов с различными опциями по реагированию и срокам устранения.
Оптимизируй это — типовые SLA
Что будет, если опереться на статистику и правило Парето и меньше слушать фантазии требования заказчиков на тему качества и срочности и недовольство начальства при объяснениях, что для удовлетворения всех хотелок бизнеса надо либо ещё 3-4 человека?
А то, что замерив сроки исполнения заявок и удовлетворённость заказчиков можно определить для каждого сервиса следующие параметры:
- уровень устраивающий 80% заказчиков, что позволит для большинства претензий занять подкреплённую статистикой позицию о том, что оказываемые конкретному подразделению услуги в целом имеют высокое качество и сильно не хуже чем в среднем по компании,
- кому (может быть и персонально) стоит оказывать VIP сервис.
Это позволит свести количество вариантов предоставления каждого сервиса к 1-3 вариантам и, пользуясь набранной статистикой по срокам и удовлетворённости, опровергать слишком уж завышенные ожидания к срокам реагирования. Что это даёт — типовой SLA, которых вместо 60 уже может вполне оказаться 25-30 штук, что заметно меньше, особенно если структура SLA будет иметь форму рамочного договора, состоящего из основного тела и набора приложений -SLA. Но эти SLA всё ещё пока надо заключать.
Оптимизируем дальше — SLA-оферта
Виду того, что статистикой мы уже располагаем и умеем отличать VIP от "не VIP", то можно подумать о следующем моменте: "сотрудник компании обращаясь за конкретным сервисом, соглашается тем самым с условиями его предоставления, опубликованными публично".
Что практически сразу приводит нас к выводу о том, что SLA по сути может заключаться в момент обращения за сервисом, если он изложен в форме Оферты.
При таком подходе возникают следующие тонкости в части отражения ответственности ИТ и представителей бизнеса в SLA :
- момент акцепта оферты должен быть чётко прописан в части сроков и перехода ответственности на ИТ и обратно на того, кто обратился за сервисом,
- явная ответственность ИТ за просрочку, выраженная, например, в выдаче статуса VIP на несколько последующих заявок при фиксации задержек исполнения или дисконте на объём потреблённого сервиса,
- требования к качеству сервиса, выраженные не только в абсолютных величинах, но и позволяющие отклониться от заданных сроков в оговоренных соглашением случаях но тоже в заданных рамках, например: "96% обращений должно быть выполнено в период до 2-х часов, не более 3% обращений допускается выполнять в период не более 4-х часов, не более 1% обращений допускается выполнять в период не более 6-и часов",
- правила отзыва и изменения оферты и правила изменения какого-либо из сервисов каталога — с предварительным оповещением всех заинтересованных сторон и публикации изменений на интернет портале службы ИТ.
Приведенный выше подход позволит в принципе отказаться от заключения SLA в большинстве случаев, ограничившись:
- согласованием каталога сервисов и текста оферты с руководством,
- публикацией указанных выше документов на внутреннем портале ИТ-службы,
- оповещением, всех, включая свеженанимающихся о данных правилах.
При этом "классические" SLA в форме соглашения сохраняются, но не в массе, а для особых случаев, не покрываемых офертой. Например круглосуточная доступность по телефону/интернету администраторов серверов и системы видеонаблюдения, и это будут именно объективно повышенные требования к качеству сервиса т.к. они "не ложатся" ни на один из стандартных уровней оферты.
Данный подход разработан в одном довольно крупном банке (top-15) в 2010-2011гг.
Текст оферты и пример описания сервиса можно взять тут. Если у кого будут вопросы — по формулировкам, использованным в соглашении — пишите — готов пояснять почему написано таким образом.
Благодарности и привет коллегам: Новиков Олег, Александр Никулин, Анатолий Малыхин, Санина Ирина, Юрий Салихов, Рустем Еникеев.
Комментарии (11)
other_letter
09.10.2017 13:56Самая большая проблема, которая почти нигде не описывается — это то, что бизнес крайне редко даёт вам список сервисов и отмечает что из них критично. Из всех случаев, с которыми сталкивался лично — лишь дважды бизнес это понимал и ещё один раз понимал, но «не отвечал за базар» (сиречь, к примеру, было заявлено «лишь бы сайт работал 24/7», а на деле «если не работает телефон, который написан на сайте — считай, сайт не работает»).
Rumyantsev Автор
09.10.2017 14:08Прошу прощения, так ведь часто функция оказания услуг лежит на ИТ и тут лучше использовать аналогию с супермаркетом: в нём есть тот товар, который берут
нав районе стандартного среднего качества. А мелкие магазины, учитывающие, по сути индивидуальные требования — либо не выживают, либо переходят на режим спиртное+закуска+пекарня, либо становятся "фермерскими лавками" с соответствующими ассортиментом и ценами.
Это к тому, что бизнес должен знать, что сервис сайт в себя включает и что (для особо упорных случаев) не включает, а также сколько людей на эти задачи работает.
Поэтому не спрашивайте бизнес — сайт продукт ИТ (по заказу бизнеса, но тем не менее продукт сделанный ИТ) и ИТ должна гарантировать, что он в принципе работает. А когда у бизнеса закончатся объективные претензии к качеству, вот тогда можно и обсудить, что в реальности хочет бизнес.
В реальности у бизнеса есть те же вопросы — обосновать бюджет и кол-во персонала, поэтому и говорить с ними после того, как займёте позицию понятную им (вот сервис, стоит столько) — будет база для договорённостей т.к. всегда можно будет обосновать затраты в ответ на дополнительные требования.
other_letter
09.10.2017 14:38Простите, я не понимаю сути.
Как это делаю я («на пальцах»): сперва рассказываю про влияние (affected). Мол, есть сервисы, которые влияют на весь Ваш бизнес вообще. Ну, у кого это инет, у кого рабочий сервак бухгалтерии, у кого телефон. Есть то, что сильно затрудняет. Тут примеры про, например, упавший 1С в случае, если всё в принципе-то работает, но страдает целый отдел/филиал/служба. Далее — понятно же?
На этом этапе важно не приступить к перечислению сервисов по категориям.
Лучше разъяснить, что-де высокую доступность инета обеспечить можно, но это будет стоить столько-то, потому как два провайдера, 10 км оптики с рытьём траншеи и блаблабла.
То же и с, например, принтером.
Ну а дальше — веселье, ибо сложно заранее предсказать тот или иной расклад, если у бизнеса нет даже примерных цифр, какие он тратит на ИТ. Обычно — на моей практике — их нет.
Rumyantsev Автор
09.10.2017 16:09Тут лучше пойти с другой стороны:
- зафиксировать в форме каталога сервисов все активности по поддержке и задекларировать это как каталог => базовая ставка — все заняты и понятно на какие сервисы;
- посчитать кто сколько и каких сервисов потребил => база для расчёта метрик качества по сервисам;
- понять какого качества реально достичь без увеличения кол-ва людей => те метрики качества которые стоит обсуждать с бизнесом и, при превышении которых просить доп. штат.
На этом этапе получим: каталог сервисов, параметры качества и кол-во персонала. В принципе, если нет аутсорсеров, то для разговора с бизнесом вполне достаточно, т.к. именно бизнес будет просить нанять людей если чего (т.к. задача найма вполне понятна бизнесу — они сами её постоянно решают).
Что касается требований выходящих за рамки каталога и параметров, то вариантов опять же два:
- либо повышение качества сервиса решается доп. людьми;
- либо повышение качества сервиса решается проектом с бюджетом, планом и сроками, если не верят Вашим утверждениям в этом случае, то проще получить 2-3 ТКП на решение — это будет вполне убедительным.
Не думаю, что ответ Вас полностью удовлетворит, но у меня такой опыт: сначала объект (сервисы и их цена в людях) — потом дискуссия по нему с заказчиком, на предмет лучше/хуже/пойдёт — почему так — в кризис проходили попытки сокращения и наличие нормального учёта и дружественных заказчиков приводит к тому, что сокращают не твоих людей, а тех у кто не может обосновать затраты.
other_letter
09.10.2017 17:31а, ну у Вас иной подход. Я же выступаю в роли HeadOps`а. Свои сложности, свои особенности.
UrbanRider
Как-то сумбурно.
Начнем с того, что SLA – Service Level Agreement, что есть Соглашение об уровне сервиса.
Что мешает пойти таким путем:
1. Получаем полный перечень сервисов
2. Описываем тип запроса: сбой, запрос на обслуживание, запрос на изменение инфраструктуры
3. Определяем с заказчиком критичные сервисы и ВИП пользователей
4. Расписываем возможные типы работ по сервисам.
5. Описываем в документе уровень доступности каждой услуги и максимальное время производство работ по ним, а также время реакции.
6. Заводим все это в свою тикет систему
7. Радуемся и не нарушаем SLA по договору.
8. Profit!
P.S.: Описанный метод — большой труд, но этот труд не оставляет разночтений и досконально опиcывает необходимый заказчику уровень доступности сервисов.
При этом разный уровень доступности означает разные деньги для заказчика и затраты для исполнителя соответственно.
Rumyantsev Автор
Что касается сумбурности — может быть поторопился, правда.
Что касается пути, то тут решается задачка не как согласовать SLA, а как упростить себе жизнь с ними. Т.е. если идти так, как описано, то шаги 1-8 необходимо проделать с каждым заказчиком, по каждому интересному ему сервису.
Это реально большой труд как на создание пула SLA, так и на его поддержание в актуальном состоянии т.к. требования заказчика склонны меняться со временем. В общем, требует человеческих ресурсов уровня account-менеджер со стороны ИТ, который будет заниматься согласованием требований.
Если же идти от оферты, и выбрать уровень сервиса, который заведомо превосходит требования большинства, то практически того же результата можно добиться ничего не согласовывая т.к. основные востребованные сервисы, типа "рабочее место", "телефония", "печать", "интернет", требуются основному количеству пользователей в ± одном высоком качестве.
При этом SLA потребуется заключать (Ваши шаги 1..8) применяются не ко всему множеству: "заказчик-сервис-уровень сервиса", а только к тем кому действительно необходимо получать нестандартный сервис, а таких, обычно, меньшинство.
Прозрачность же можно получить — через публикацию отчётов по заявкам на интранет-портале, чтобы всем было видно объективное качество работы поддержки.
UrbanRider
В целом согласен, возможно с некоторыми компаниями пройдет.
Есть же заказчики, скажем так «трудные». С которыми приходится работать именно так, как описал я, иначе не получается.
В общем все зависит от уровня бюрократии и ее необходимости.
P.S. наша команда держит SLA > 99%
Кстати такой вопрос на счет оферты:
Вот есть сервис телефония. Конкретный заказчик требует SLA > 99%, время реакции не более 30 минут и время на решение 4 часа. И готов за это платить деньги.
Другой заказчик не так требователен и требует SLA > 94%, время реакции 4 часа и 3 дня на решение проблемы и готов платить гораздо меньше, чем первая компания.
Ну и к примеру у вашей аутсорсинговой компании 20-30 клиентов, которые готовы платить разные деньги за разный уровень сервиса.
Как быть в таком случае?
Rumyantsev Автор
Круто, что больше 99%
Тут несколько вопросов/ответов, основной — что делать с вариативностью
nixon22
В теории — все верно. А на практике мы сталкиваемся с различными подводными камнями, например, с нежеланием заказчика идти на компромиссы или вовсе заключать SLA (дескать — и так все устраивает). В этом случае оферта — сильный ход со стороны IT-подразделения.