Многие из вас, наверное, слышали, да и обсуждали такие инициативы как «Соглашение об уровне сервиса» (SLA или Service Level Agreement); многие, наверное, его используют при работе с внешними провайдерами. Например, с телеком провайдерами.
А нужно ли такое соглашение внутри компании? Как соглашение между ИТ службой и бизнес подразделением? По сути, ведь можно написать все, что угодно, но если ИТ служба или бизнес-подразделение нарушит соглашение, то применить штрафные санкции, такие как не заплатить или перезаключить контракт с новым поставщиком, просто невозможно.
Получается это уже не договор, а соглашение о намерениях. Так нужно ли оно? Это как брачный контракт, что ли. Надеемся жить долго и счастливо, но прописать такие детали, как кто и когда выносит ведро и гуляет с собакой, не забываем.
Если отбросить все эти новые и модные течения, ITSM и прочее, и взять и посмотреть, как оценивает бизнес потребитель ИТ службу? Да все очень просто — доволен или не доволен. Если все это упростить, то все службы, которые не зарабатывают деньги, оцениваются очень просто, а именно как соответствуют ожиданиям или нет. Получается, если ИТ служба просто сможет поставить ожидания своих потребителей в соответствии с тем качеством работы, которое способно выдавать, то это даст серьезное улучшение в оценке работы ИТ службы.
Так вот для того, чтобы начать работать с ожиданиями пользователей и нужно начинать создавать SLA. При этом нужно отдавать себе отчет в том, что SLA — это ни в коем случае не бюрократическая защита от запросов пользователей. Типа — мы не обязаны этого делать. Для таких маневров есть специальный термин — итальянская забастовка, это когда работники начинают работать строго в соответствии с должностными инструкциями. В нашем же случае, это должен быть обобщенный документ с нашими намерениями.
Очень важный момент состоит еще в том, что нельзя прописывать в нем параметры, которые сложно достижимы. Ну, допустим, реакция в течении 5 минут. Это приведет просто к разочарованию. Лучше прописать такие параметры, которые достигаются всегда и без усилий. После того, как убедились, что это достижимо можно уже согласовывать с пользователями новые условия сервиса и улучшать его. Эта техника считается базовой для наведения порядка в организациях. Сначала устанавливаются минимально необходимые правила, которые сложно нарушить. Когда добились того, что эти правила исполняются, а не исполнить их просто тяжело, так как это и так работает в таком режиме и с таким качеством, и только после этого начинают «закручивать гайки».
Ниже можно посмотреть пример простого соглашения об уровне сервиса. Параметры там реальные, да, именно с этих 8 часов на решение критической проблемы мы и начинали. Текст там был английский, это мой перевод. Если у кого есть примеры SLA, то присылайте, опубликуем.
Пример простого соглашения об уровне сервиса (32.1 Кб)
А нужно ли такое соглашение внутри компании? Как соглашение между ИТ службой и бизнес подразделением? По сути, ведь можно написать все, что угодно, но если ИТ служба или бизнес-подразделение нарушит соглашение, то применить штрафные санкции, такие как не заплатить или перезаключить контракт с новым поставщиком, просто невозможно.
Получается это уже не договор, а соглашение о намерениях. Так нужно ли оно? Это как брачный контракт, что ли. Надеемся жить долго и счастливо, но прописать такие детали, как кто и когда выносит ведро и гуляет с собакой, не забываем.
Если отбросить все эти новые и модные течения, ITSM и прочее, и взять и посмотреть, как оценивает бизнес потребитель ИТ службу? Да все очень просто — доволен или не доволен. Если все это упростить, то все службы, которые не зарабатывают деньги, оцениваются очень просто, а именно как соответствуют ожиданиям или нет. Получается, если ИТ служба просто сможет поставить ожидания своих потребителей в соответствии с тем качеством работы, которое способно выдавать, то это даст серьезное улучшение в оценке работы ИТ службы.
Так вот для того, чтобы начать работать с ожиданиями пользователей и нужно начинать создавать SLA. При этом нужно отдавать себе отчет в том, что SLA — это ни в коем случае не бюрократическая защита от запросов пользователей. Типа — мы не обязаны этого делать. Для таких маневров есть специальный термин — итальянская забастовка, это когда работники начинают работать строго в соответствии с должностными инструкциями. В нашем же случае, это должен быть обобщенный документ с нашими намерениями.
Очень важный момент состоит еще в том, что нельзя прописывать в нем параметры, которые сложно достижимы. Ну, допустим, реакция в течении 5 минут. Это приведет просто к разочарованию. Лучше прописать такие параметры, которые достигаются всегда и без усилий. После того, как убедились, что это достижимо можно уже согласовывать с пользователями новые условия сервиса и улучшать его. Эта техника считается базовой для наведения порядка в организациях. Сначала устанавливаются минимально необходимые правила, которые сложно нарушить. Когда добились того, что эти правила исполняются, а не исполнить их просто тяжело, так как это и так работает в таком режиме и с таким качеством, и только после этого начинают «закручивать гайки».
Ниже можно посмотреть пример простого соглашения об уровне сервиса. Параметры там реальные, да, именно с этих 8 часов на решение критической проблемы мы и начинали. Текст там был английский, это мой перевод. Если у кого есть примеры SLA, то присылайте, опубликуем.
Пример простого соглашения об уровне сервиса (32.1 Кб)
