Соглашение об уровне сервиса (SLA) призвано упростить общение с IТ-службой, однако на практике так происходит не всегда. Попробуем разобраться, при каких условиях SLA оказывается действительно полезным инструментом.
Сервис (не только айтишный) должен быть удобным, быстрым и понятным. IТ-служба пытается такой сервис обеспечить, но для этого нужно как минимум получить правильную (в её понимании) постановку задачи.
Очень непросто далась нам выработка концепции работы с IТ-заявками. И руководство Корпорации, и менеджеры были едины в том, что нужно «единое окно» для обращения в IТ-службу.
Теоретически всё просто: возникла проблема при работе с IТ — обратился в единое окно (электронным письмом, телефонным звонком или заявкой, размещённой на корпоративном портале), и всё. Дальше должны закрутиться шестерёнки сервисной службы IТ, и в итоге всё выполняется в соответствии с оговорёнными (или нормативными) сроками.
Это в теории. На практике заявка заявке рознь. К примеру, заявка на покупку нового принтера и заявка на срочное исправление ошибки в ключевой бизнес-системе не только выполняются разными подразделениями внутри IТ-службы, но и имеют разную критичность и трудоёмкость, разные временные параметры.
Что же, готовить SLA под каждый тип заявок?
Можно и так, но это не спасает. Ведь срочность исполнения заявки может меняться.
Надо добавить ещё один фактор — корректность определения типа заявки. Что это — инцидент (ошибка), который нужно исправить молниеносно, или небольшая доработка системы, которая хоть и мешает нормальной работе, но может немного подождать?
«Единое окно» вступает также в противоречие со сложившимся укладом: пользователи привыкли работать с конкретными исполнителями. Набрали номер внутреннего телефона — и оперативно получили прямую консультацию от специалиста, который им нравится, или того, с кем раньше общались.
При внедрении технологии «единого окна» негатива было более чем достаточно. Как со стороны IТ-специалистов, лишившихся живого контакта с заказчиком, так и со стороны пользователей. Что делать? К решению подобных проблем следует подходить диалектически.
В 90% случаев централизация приёма заявок в службу поддержки нужна, и она работает эффективно. Это в ТЕХНОНИКОЛЬ реализовано. Другое дело, что централизация — не панацея, всегда есть и будут существовать исключения.
Да и нет глобальной централизации: после фиксации IТ-заявки в единой системе и классификации, происходящей практически в автоматическом режиме, заявка направляется IТ-специалистам на местах.
Следующий шаг — разработанная система SLA
Во многих IТ-учебниках необходимость подготовки и согласования SLA с бизнес-заказчиками рассматривается с точки зрения защиты IТ. Нет смысла спешить или оправдываться, если параметр зафиксирован в Соглашении. Правда, во многих дружественных нам компаниях слово SLA в области IТ давно уже является ругательным. И попытки с помощью SLA прикрывать свои промахи или неэффективную работу жёстко пресекаются.
SLA, конечно, можно привязывать не к любым процессам. Существуют творческие или исследовательские задачи, которые нельзя заранее просчитать и для которых нельзя утвердить жёсткие параметры.
Известно, что сотрудники, у которых жёстко зафиксированы KPI, начинают выполнять свои обязанности исключительно в рамках данных параметров. Подавляется творческий потенциал, любое отклонение от прописанных параметров становится для человека невыгодным. В Корпорации такой подход неприемлем — и потому, что у нас другая культура отношений, и потому, что у нас нет чётко выделенных должностей и жёстко закрепленных обязанностей.
Это позволяет творчески подходить к работе, не бояться границ и эффективно использовать командную работу сотрудников в подразделениях.
Вместе с тем без параметров эффективности нельзя обойтись, когда речь идёт о сервисном персонале, о коллегах, которые выполняют стандартные задачи по отработанным и стабильным бизнес-процессам.
Аналогичный подход в ТЕХНОНИКОЛЬ и к системе SLA. Соглашения зафиксированы, но они (по крайней мере, в области IТ) достаточно просты и не содержат множества ветвлений.
IТ-служба гарантирует определённые параметры качества исполнения стандартных задач (приём заявки, обработка заявки, решение локальной проблемы и т. д.). Это касается всего, что стабильно и не требует дополнительных вмешательств в процесс.
Очевидная выгода — пользователи могут планировать своё время и сроки исполнения задач.