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

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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

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

Комментариев: 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.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.