Портал №1 по управлению цифровыми
и информационными технологиями

Кого поддерживает служба поддержки?

Опубликовано 5 октября 2010
Рубрики: ITIL, ITSM, Service Desk, SLA, SLM, BRM, Аналитика: точка зрения, Источники знаний
Комментарии

Ответ зависит от того, для кого вообще работает ИТ. 

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

Service Desk — фильтр, защищающий ИТ от шумов, производимых пользователями. И тогда это внутренний механизм, и не очень важный. 

Если же Service Desk призван служить пользователям, мы будем стремиться помогать им работать более продуктивно, лучше использовать, понимать и принимать технологии, будем определять (и удовлетворять!) их потребности в дополнительном обучении. Мы будем анализировать их потребности, а не текст SLA — и сейчас, а не когда SLA кто-нибудь напишет. В этом случае Service Desk — передовая работы ИТ. И очень важная часть всей службы. 

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

оригинальный текст заметки — в блоге ИТ-Скептика

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 4

  • old fuddy-duddy

    Извините за тавтологию, но к ИТ-скептику я отношусь скептически;). Как известно любую хорошую идею можно довести до абсурда и самый простой способ для этого — рассматривать идею вне контекста, что ИТ-скептик обычно и делает. SLA полезен и сам по себе, так как позволяет сформулировать общую точку зрения на ИТ-услугу, однако если у вас есть еще и полноценный SLM, то пользы будет гораздо больше. Любой айтишник уверенно скажет, что причина большинства инцидентов – «тупой юзер», но если ликвидация безграмотности пользователей, по условиям SLA, входит в зону ответственности поставщика ИТ-услуг, будьте любезны, обучайте юзеров, а если таких условий нет, и бизнес не видит в это необходимости (читай, выгоды), то альтруистичное обучение юзеров может привести ИТ-директора к финалу Лужкова. А вот для понимания потребностей заказчика и применения этого понимания в работе нужен SLM. В ITIL конечно есть недостатки, но все-таки это вполне цельная модель, а критиковать ее элементы по отдельности также глупо как, построив от дома только стены, защитившие вас от ветра, пенять, что они не спасают от дождя и холода.

    • Роман Журавлёв

      Про скептика и цельную модель:

      ITIL, конечно, довольно цельная модель, но несовершенная. И в целом к этому ничего не добавить.

      А в ответ на логичный вопрос «и в чем же, например, она такая несовершенная?» придется критиковать ее несовершенные элементы по отдельности и их несовершенные взаимосвязи... что Скептик и делает давно и довольно последовательно, хоть и не без перегибов.

      То есть, используя Вашу метафору, архитекторы и строители как раз утверждают, что дом готов полностью. Так что повод пенять на холод и сырость все же есть...

      По сути заметки:

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

      Иными словами, инструментарий ITSM — будь то SLA, или Service Desk, или каталог услуг, — можно рассматривать как средства «нанесения добра» потребителям, а можно — как основной критерий качества работы сервисной службы. Вторая позиция, как я понимаю, скептику не нравится.

      [...и выходит, что он в данном случае не столько скептик, сколько романтик и идеалист. Забавно...]

  • Павел Солопов

    На каком-то сайте посвящённом ТОиР мне попадалось обсуждение, вопроса, как организовать взаимоотношения со сторонними подрядчиками, которые занимаются эксплуатацией оборудования компании.

    Так вот там приводился интересный пример, когда с эксплуатирующей организацией расчёты осуществлялись по тонно/часам, т.е. чем меньше было перерывов в работе оборудования и чем больше на этом оборудовании произвели, тем больеш получает эксплуатаирующая организация.

    так вот после ввода такой системы оплаты, эксплуатирующая организация сама занялась и профилактическим обслуживанием, и рабочих начала обучать (которые на оборудовании работают), как правильно оборудование использовать, чтобы не ломалось и эффективней работало.

    Мне очень понраивлся такой опыт.

    К вопросу об SLA — бизнесу нужно, чтобы всё работало как можно стабильнее и с максимальной производительностью. И когда вы начинаете лезть к ним с вопросами: а вам надо, чтобы мы пользователей обучали, а вам надо чтобы мы профилактику делали... Бизнес начинает нервничать, он не понимает надо ли это ему, он понимает, что надо чтобы работало, но как это связано с пользователями, профилактиками и т.д. не знает. Вот и получается. Что теоретически SLA должно было разгрузить бизнес от ответа на эти вопросы. а выходит нагрузило ещё больше.

  • Дмитрий Исайченко

    Мне кажется вопрос немного глубже пользы/вреда SLA (как частного инструмента) или даже SLM (как целостного инструментария). Вопрос в том для чего этот инструмент (инструментарий) используется. То, что SLA во многом трактуются как «средство защиты от юзера», вызвано простым фактом: низким уровнем доверия между сторонами.

    Наверняка каждый из вас оказывался в ситуации заказа услуг, в которых вы не настолько понимаете, чтобы все самому сделать или даже полностью проконтролировать. В этом случае вы ищете своих гарантий в прежде всего в договоре (это механизм защиты), но и поставщик ищет своих гарантий в договоре (это его защита).

    Разница с ДИТ, который является частью организации в том, что этот поставщик услуг не разовый, отысканный по интернету за 5 минут, а постоянный. И грамотный директор ИТ занимается доверием к себе и своим службам. Потому что именно это дает возможность двигаться вперед, а не SLA и не новое железо.

    Только вот прививать руководителю (другому или самому себе) хорошие привычки — умение брать на себя ответственность, держать свое слово и в конечном счете обеспечивать доверие к себе и своим подчиненным — гораздо сложнее, чем «внедрить SLM». Так идея «Cooperative SLM» и превращается в «Protective SLM».

    Думаю, что если говорить о внутреннем ИТ, «настоящий» SLM из-за особеностей культуры подходит очень немногим организациям. По крайней мере, это то, что я вижу на практике. Подчеркну, это не уровень зрелости, это не «бескультурье», это именно особенности культуры. Для многих лучший договор — по рукам, глядя в глаза. Бумажный договор — это бюрократия. А историческая память быстро строит цепочку «бюрократия -> чиновники -> вранье -> противостояние».

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.