Разработка SLA — составление SLA внутри компании

О Service Level Agreement (SLA) чаще говорят в контексте работы со сторонним поставщиком. Но не менее важен этот документ и внутри компании. Это основа взаимопонимания между ИТ-отделом и собственно бизнесом, здоровый сон ИТ-команды и предсказуемость решения вопросов для других подразделений.

На самом деле разработать простой SLA не так уж сложно. Такой документ облегчит жизнь многим, и ИТ-отделу в первую очередь. Кроме того, он уравновесит ожидания от ИТ со стороны бизнеса с гарантированными реалиями при выделяемом на ИТ бюджете. При этом не обязательно получать значок ITSM или изучать теорию.

Этап 1 - сервисы

Начать стоит с того, чтобы выписать в единый документ набор сервисов (Service), которые оказывает ИТ-отдел — услуг или объектов поддержки, которые могут видеться бизнесом как один объект. Ключевые слова —  могут видеться бизнесом, так как:

• Сотрудников других отделов не колышет, что для сервера нужна поддержка вендора, работы собственных инженеров и поддержка внешних ИТ-интеграторов. Для них это просто сервер.

• Функция «поддержка рабочих мест» может восприниматься как что-то одинаковое для всех, и никого не следует грузить подробностями, например, что рабочие места бухгалтеров и рабочие места программистов — это два разных сервиса. Упрощайте. Если бизнес признает существование такого сервиса, как поддержка рабочих мест, — пусть будет так.

Описывать и группировать сервисы следует так, чтобы ваш генеральный директор, акционеры или учредители поняли с первого раза, о чем идет речь.

Сервисы, которые осуществляет ИТ-отдел

Не забываем о нетехнических процессах, которые обычно ложатся на ИТ, требуют времени и сил, но не относятся к прямым обязанностям поддержки компьютерного оборудования.

Перечень периодических нетехнических работ, которыми занимается ИТ-отдел

Сервисы следует указывать в соответствии с функциями, понятными руководителю. Например, если 1С имеет подсервисы, такие, как СУБД, веб-серверы, кластеризация и прочие, но ваш руководитель не готов к пониманию таких сложностей. Оставьте только то, что ему понятно — 1С. Не грузите владельцев и управленцев лишней информацией.

Этап 2 – внешние связи

Чаще всего в компании есть сервисы, которые обслуживаются не только внутренними, но и внешними подрядчиками. Например, 1С обслуживают свои программисты и сторонние подрядчики. А с печатью, как правило, дело обстоит так: настройкой и доступом к печатающим устройствам занимается локальная ИТ-служба, а заправку картриджей, их замену и ликвидацию аппаратных неисправностей обеспечивают внешние подрядчики. Возможно, в вашей компании есть вынесенный отдел, занимающийся этими вопросами. 

Так вот, если доступность сервиса и его работоспособность зависят от сторонних подрядчиков, руководству следует об этом знать.

Внешние подрядчики

Теперь руководству понятно, благодаря кому работают основные инструменты бизнеса и каких денег это стоит.

Этап 3 - описываем качество работы сервисов

Вначале оцениваем силы своего ИТ-отдела ответом на два вопроса:

• Какое время указано рабочим у всех сотрудников ИТ-отдела? Фиксированный ли обед? Соответственно, определяем временной интервал обслуживания. Т.е. если у всех сотрудников рабочее время с 10.00 до 19.00 с часом на обед по рабочим дням — формально устанавливаем интервал поддержки 10:00 — 19:00. А если обед ещё и фиксирован для всех, то время поддержки с 10:00 до 13:15 и с 14:15 до 19:00.

• Сколько времени требуется для начала работ по новой заявке? 1 час, 4 часа, 1 день? Это время мы обозначим как гарантированное время реакции на обычный инцидент (именно время реакции, а не время принятия в работу!!!)

Эту информацию мы фиксируем в состоянии AS IS (как есть) для того, чтобы показать руководству.

Рабочее время (время обработки заявок): 10:00 — 19:00 по рабочим дням.

Время реакции на новую заявку: 3 часа.

На нетехнические задачи время реакции можно обозначить более реальное — 1 рабочий день.

Эти две метрики являются уровнем сервисных соглашений (SLA) между ИТ-отделом и компанией, дополняем ими таблицу.

Кроме того, добавляем следующую информацию:

• Фонд оплаты труда ИТ-отдела;

• количество сотрудников;

• годовой бюджет на покупку оборудования;

• ежегодная сумма на продление лицензий;

• годовой бюджет на поддержку;

• примерное среднемесячное количество часов переработки сотрудников ИТ-отдела.

И с этой таблицей идём к руководству на согласование.

Этап 4 - согласование SLA с бизнесом

Очевидно, что мало какому работающему бизнесу понравятся условия, при которых в случае проблемы скорость реакции будет 3 часа. Но мы же пришли с отчетом о реалиях, и начинаем разговор со словами:

«Вот тот уровень сервиса, который мы можем обеспечить гарантированно для того, чтобы компьютерная техника работала. Где здесь вы видите проблемы?»

И директор начинает думать и выдвигать требования, например, чтобы принятие заявки в работу осуществлялось не позднее чем через час, а поддержка рабочих мест в выходные для сотрудников производства осуществлялась в интервале с 8:00 до 20:00.

Тут надо обратить внимание руководителя на то, что сейчас, например, все сотрудники ИТ работают по пятидневке, имеют высокую загрузку, потому что какой-то старый сервер без поддержки постоянно падает, а на нем непереносимая 1С. А в выходные люди неохотно работают, так как им не платят за переработку, и работы производятся после дерганья за рукав кого-то по личному номеру телефона с криками «СРОЧНО!»

Этим вы открыли глаза руководству на вопросы, от которых может зависеть работоспособность компании.

И теперь дайте директору решение, что нужно сделать для изменения SLA в соответствии с его реальными требованиями:

• нанять одного человека в штат на полную ставку — ZZZ руб. в месяц;

• ввести оплату за дежурство в выходные дни и составить очереди дежурств. — ZZZ руб. за смену;

• заменить старый сервер на новый — ZZZ рублей с поддержкой на 5 лет.

• заплатить подрядчику за миграцию 1С на новый сервер в нерабочее время — ZZZ рублей.

Директор теперь понимает, что за лучшие условия нужно заплатить конкретную сумму, и самостоятельно взвесит все «за» и «против», видя информацию на понятном для него языке. Альтернатива такова: либо вложиться в ИТ, либо жить с фактическим уровнем сервиса.

Главное — чтобы этот документ был подписан руководством и стал частью внутреннего регламента.

SLA — это не статика, это фиксация реальных договоренностей. Оно подвержено изменениям как под действиями требований, так и по причине изменения реалий — например, в случае перегрузки ИТ-отдела.

Увеличение количества рабочих мест в компании отразится на загрузке ИТ-отдела и когда-нибудь непременно окажет негативное влияние на время реакции — люди будут перегружены. При возникновении дисбаланса нужно идти к руководству и показать две таблицы SLA: раньше было 200 рабочих мест и мы обеспечивали время реакции в 1 час. Сейчас 400 рабочих мест при том же штате ИТ-отдела — нужно расширять штат или вводить аутсорсинг, либо увеличивать время реакции в рабочие дни, скажем, до двух часов. Выбор остается за бизнесом, и крайним ИТ-отдел никто не сделает.

Как видите, SLA — это:

• путь к уважению труда ИТ отдела: сотрудники других отделов — потребители сервиса — будут понимать, на что они могут рассчитывать, и ИТ-специалисты будут работать в плановом порядке, выполняя задачу за задачей, без авралов и требований с высоких шпилек сделать что-то немедленно.

• понятный инструмент для согласования требований к ИТ с выделяемым бюджетом. С ним проще выбить ставку или средства на оптимизацию и развитие ИТ-инфраструктуры.

• Инструмент повышения качества работы ИТ-отдела, так как стабильность — признак хорошо организованной работы. Негатив от того, что 10 % задач отложены на неопределенный срок, будет перекрывать качественное решение 90 % задач. Если все будут знать, что в течении 1 часа или 3 часов их обращение будет принято к выполнению, и эта метрика будет соблюдаться — довольны будут все. 

Начните с малого, и вы увидите, как улучшится ваша жизнь и насколько легче станет договариваться с бизнесом. А если возникнут вопросы, мы с удовольствием ответим на них в нашем телеграм-канале (ссылка).