Кому нужен SLA?
Многие из вас, наверное, слышали, да и обсуждали такие инициативы как «Соглашение об уровне сервиса» (SLA или Service Level Agreement); многие, наверное, его используют при работе с внешними провайдерами. Например, с телеком провайдерами.
А нужно ли такое соглашение внутри компании? Как соглашение между ИТ службой и бизнес подразделением? По сути, ведь можно написать все, что угодно, но если ИТ служба или бизнес-подразделение нарушит соглашение, то применить штрафные санкции, такие как не заплатить или перезаключить контракт с новым поставщиком, просто невозможно.
Получается это уже не договор, а соглашение о намерениях. Так нужно ли оно? Это как брачный контракт, что ли. Надеемся жить долго и счастливо, но прописать такие детали, как кто и когда выносит ведро и гуляет с собакой, не забываем.
Если отбросить все эти новые и модные течения, ITSM и прочее, и взять и посмотреть, как оценивает бизнес потребитель ИТ службу? Да все очень просто – доволен или не доволен. Если все это упростить, то все службы, которые не зарабатывают деньги, оцениваются очень просто, а именно как соответствуют ожиданиям или нет. Получается, если ИТ служба просто сможет поставить ожидания своих потребителей в соответствии с тем качеством работы, которое способно выдавать, то это даст серьезное улучшение в оценке работы ИТ службы.
Так вот для того, чтобы начать работать с ожиданиями пользователей и нужно начинать создавать SLA. При этом нужно отдавать себе отчет в том, что SLA – это ни в коем случае не бюрократическая защита от запросов пользователей. Типа – мы не обязаны этого делать. Для таких маневров есть специальный термин – итальянская забастовка, это когда работники начинают работать строго в соответствии с должностными инструкциями. В нашем же случае, это должен быть обобщенный документ с нашими намерениями.
Очень важный момент состоит еще в том, что нельзя прописывать в нем параметры, которые сложно достижимы. Ну, допустим, реакция в течении 5 минут. Это приведет просто к разочарованию. Лучше прописать такие параметры, которые достигаются всегда и без усилий. После того, как убедились, что это достижимо можно уже согласовывать с пользователями новые условия сервиса и улучшать его. Эта техника считается базовой для наведения порядка в организациях. Сначала устанавливаются минимально необходимые правила, которые сложно нарушить. Когда добились того, что эти правила исполняются, а не исполнить их просто тяжело, так как это и так работает в таком режиме и с таким качеством, и только после этого начинают «закручивать гайки».
Ниже можно посмотреть пример простого соглашения об уровне сервиса. Параметры там реальные, да, именно с этих 8 часов на решение критической проблемы мы и начинали. Текст там был английский, это мой перевод. Если у кого есть примеры SLA, то присылайте, опубликуем.
Пример простого соглашения об уровне сервиса (157.0 Кб, 4,162 скачиваний)
Алексей Готсданкер
Похожие записи
(2 votes, average: 5.00 out of 5)
Loading ...
У меня архив не разархивируется. (Apple Mac OS X 10.5)
Выложите плиз еще раз в другом, более раннем ZIP-формате. Может в этом дело?
все вылечил проблему одну. и теперь можно выкладывать не только ZIP. попробуйте. Качается? открывается?
рад, что наконец то российские IT-шники от тупого копирования западных «разводилок» клиентов перешли к осмыслению сути идей
выложенный формат на моем макбуке читается, спасибо за док
Два момента:
1) SLA интересная вещь. И необязательно разрывать договор с таким «внутренним» провайдером IT-сервисов – можно просто поставить бонусы IT-директора в прямую зависимость от соблюдения SLA. Это один вариант. В крупных компаниях функции ИТ-поддержки вообще зачастую выделены в отдельную структуру, со своим юрлицом, и т.д. И взаиморасчеты между бизнесом и ИТ производятся порой за каждую оказанную услугу.
2)Удовлетворенность бизнеса – довольно неоднозначный показатель. Поскольку:под этим очень часто понимается удовлетворенность пользователей, а это не самый правильный вариант. Пользователи никогда не будут довольны, например, деятельностью службы ИТ-безопасности, службы ИТ-закупок, и т.д – в силу ограничения их запросов различными политиками и процедурами.
Поэтому тут скорее более корректным показателем должны быть некие показатели перерывов в сервисах и оказываемой помощи бизнесу – то есть, как раз тот самый SLA в том или ином виде.
Правильно все, но удовлетворенность ключевая вешь. Так как если ИТ служба сможет поставить правильные ожидания, то она и сможет получить нормальную удовлетворенность пользователей. Потом никто не говорит, что должна быть любовь. Нужна динамика, нужен прогресс, а удовлетворенностью можно померить взаимопонимание слжб:)
«Получается, если ИТ служба просто сможет поставить ожидания своих потребителей в соответствии с тем качеством работы, которое способно выдавать..»
Зачастую, главное ожидание потребителя заключается в оперативной фиксации запроса и высылаемых с какой-либо периодичностью отчетов о проделанной работе, людям хочется чтобы о них банально не забывали. Таким образом, не столько внедрение СЛА поднимает авторитет ИТ, сколько наведение видимого невооруженным глазом порядка в сумбуре закрытия заявок и выполнения работ.
Далее, первым шагом к СЛА может стать выделение единой точки обращения с фиксацией заявки. Таким образом за пару месяцев получим оперативный каталог услуг, который в Вашем втором пункте описан как «.. и т.д.»
Дополняя его долгосрочными проектами и перспективами получим полный каталог услуг, причём нормализуя его сможем выделить группы задач под разный шаблоны СЛА.
Подводя итог написанному – на мой взгляд, создание СЛА не от каталога услуг, а от написания бумаги «Соглашение..» не может дать положительного результата.
все правильно, прежде чем договориться нужно понимать о чем договариваться. Тут то и нужен каталог услуг
Кстати, как Вы считаете, кто должен приоритезировать инциденты?
Пользователь. Так как он знает что срочно, а что нет. Но ИТ специалист, ссылаясь на SLA может предложить другой приоритет. Если пользователь не согласен, то он делает бизнес кейс и расписывает подробно как это влияет на бизнес и почему предложенные обходные пути не помогают
Тогда все ваши инциденты будут с наивысшим приоритетом
да, будут инициироваться с высшим приоритетом, но потом ИТ служба на формальных основаниях (наличие work arond, угроза бизнесу и т.д.) будет менять приоритет и уведомлять инициатора.
Вообще-то это как раз образец «копирования». Если на практике использовать такой SLA то ИТ-служба быстро займет свое «законное» место. «Эти идиоты не могут обеспечить требования отдела продаж (выберите любой Центр Доходов по вкусу) и еще хамят». Все потому, что там нет одной детально расписанной главы……
Оставьте комментарий!
Метки
Рубрики
Свежие записи
Свежие комментарии
Самые просматриваемые