Часто слышал об использовании SLA в качестве инструмента прикрытия своей задницы ИТ-шниками. Например, такие сценарии:
Ничего не знаем, вот SLA, в нем так и написано - время восстановления - 24 часа... Мы ничего не нарушили!или:
Мы не обязаны были это делать. В SLA этого нет!
ИТ-директор, и любой другой ИТ-сотрудник, который выгораживает и снимает с себя ответственность с помощью SLA, должен быть наказан.
С точки зрения руководства и акционеров, SLA должен содержать минимальный гарантированный уровень услуг, который может предоставить ИТ-подразделение. Но ни в коем случае не ограничения по предоставляемым услугам (типа "хотите больше - платите"). Какой бы низкий уровень сервиса не был бы зафиксирован в этом документе, от вас в праве требовать максимально высокий уровень. Руководство с чистой совестью может требовать предоставления услуг, которых нет в SLA - на то оно и руководство. SLA должен обеспечить здоровый сон руководителям и акционерам организации, но никак не ИТ-директору.
6 комментариев:
"Часто слышал об использовании SLA в качестве инструмента прикрытия своей задницы ИТ-шниками." -
понятно, о чем речь, но воображение все же рисует такого злобного типа, прикрывающего свою задницу несчастными айтишниками.
Шутки шутками, но ведь возможно и такое. И если руководство будет с чистой совестью требовать предоставления того, чего нет в SLA, такая ситуация будет вполне вероятна.
Хорошие SLA призваны обеспечить спокойный здоровый сон ВСЕМ, кто честно выполняет свои обязательства - как на стороне провайдера, так и на стороне заказчика. А требовать того, чего в SLA нет, заказчик может только после того, как он это в той или иной форме профинансировал.
Наряду с минимальным гарантированным уровнем услуг в SLA должен быть определен и целевой, желательный. Все, что лучше - не оплачивается. И задача ИТ - удержать качество услуг как можно ближе к целевому уровню и никогда не опускать ниже минимально допустимого.
Не могу согласиться с тем, что SLA, каким бы замечательным он не был, способен обеспечить здоровый сон провайдеру. Поставщик днем и ночью должен быть готов удовлетворить заказчика. Это и есть сервис.
SLA запросто может не успеть актуализироваться в соответствии с изменившимися бизнес-потребностями. А они могут меняться очень часто, много-много раз в день. А если бизнес Заказчика станет работать со скоростью обновления SLA, то скорее всего не продержится и месяца.
Как правило, важные вопросы, в т.ч. новые и изменившиеся потребности, решаются по звонку. А форма финансирования зависит от личных взаимоотношений между поставщиком и заказчиком.
Насчет целевого и желательного - как вы будете за них отвечать? Вы же не можете гарантировать целевой или желательный уровень сервиса? За их не достижение не полагается же никаких санкций? Они никого ни к чему не обязывают. Так зачем они нужны в SLA? :-)
"Поставщик днем и ночью должен быть готов удовлетворить заказчика. Это и есть сервис."
Нет, это не сервис. Это по-другому называется.
"SLA запросто может не успеть актуализироваться в соответствии с изменившимися бизнес-потребностями"
Для того, чтобы SLA актуализировались вовремя, должен работать специальный процесс, называется SLM. Если они не успевают актуализироваться, значит он плохо работает. И потребности бизнеса не должны меняться много-много раз в день. даже мои личные потребности меняются существенно реже.
Если вопросы решаются по звонку, а финансирование зависит от личных отношений, SLA просто не нужны. Как и SLM. Как и процессное управление ИТ-услугами вообще. Тогда нет темы для разговора.
Целевой и желательный в моем прошлом посте - одно и то же, я разделял целевой и необходимый, то есть оптимальный и минимальный. Отвечать буду за снижение относительно целевого мягче, за снижение относительно минимального - жестче, примерно как школьники отвечают за "четверки" и "двойки". Санкции - предмет соглашения сторон, могут полагаться, могут нет.
Но это все - в тех SLA, которые определяют обязанности, права и ответственность обеих сторон. Мы же договорились выше, что "SLA должен обеспечить здоровый сон руководителям и акционерам организации, но никак не ИТ-директору." Такие SLA не нужны, точнее, такие документы обычно не называются SLA.
Разруливание и предотвращение описанных ситуаций - прямая обязанность сервис-менеджера.
>> Нет, это не сервис. Это по-другому называется.
Не поверите, но это тоже сервис. Один из самых первых и самых популярных :)
>> И потребности бизнеса не должны меняться много-много раз в день. даже мои личные потребности меняются существенно реже
А как часто должны меняться потребности клиента должен определить сам клиент а не поставщик. Зачем вы ограничиваете своих заказчиков?
>> Если вопросы решаются по звонку, а финансирование зависит от личных отношений, SLA просто не нужны.
Нужны. Как гарантия заказчику минимально возможного качества сервиса.
>> Отвечать буду за снижение относительно целевого мягче, за снижение относительно минимального - жестче, примерно как школьники отвечают за "четверки" и "двойки". Санкции - предмет соглашения сторон, могут полагаться, могут нет. Но это все - в тех SLA, которые определяют обязанности, права и ответственность обеих сторон
Ни один год в поиске таких идеальных SLA, в реальной жизни разумеется, а не в теории. Можете привести реальные примеры?
В IT работают тоже люди - это ресурс, а не расходный материал,по вашемуsla вообще не нужны, в любом случае IT крайний. При таком подходе об эффективности IT речи-не может быть.
Если вы с провайдером заключили sla и требуете еще что-то, что вам ответят, или вы думаете там армия людей, которая по взмаху кидается решать проблему?
Все в этом мире стоит денег, никто не будет мониторить сервера в выходной день, если за это не платят, но это очень нужно бизнесу
Отправить комментарий