Автор: Дена Уайдер-Фреиден (Dena Wieder-Freiden)
Публикация 18 октября 2016 года
в разделе Service Desk богов на sysaid
Роза пахнет розой, хоть розой назови её, хоть нет.
(У.Шекспир)
Я не часто начинаю свои записи в блоге про Управление ИТ услугами с цитат Уильяма Шекспира, но в его “Ромео и Джульетте” есть идеально подходящая для текущей темы фраза: “Роза пахнет розой, хоть розой назови её, хоть нет”. К сожалению, как и герои Шекспира, находящие трагическую кончину, человеческое сообщество и в реальности зациклено на именах, ярлыках и словах, которые использует. Так из-за подмены авторами ITIL значений у некоторых общепринятых слов на специфичные для ITIL (например, “инцидент” и “проблема”), многие начинают путаться в смысле сказанного. Ситуация так похожа на пьесу Шекспира, когда весь накопленный поколениями ком проблем в отношениях между семьями Монтекки и Капулетти, разрушается значением любви для юноши и девушки друг к другу.
Итак… Пользователи и Заказчики в Управлении ИТ услугами.
Давайте сосредоточимся сейчас на одной важной идее, которая, на мой взгляд, вызывает множество проблем из-за особенностей терминологии. В ITIL понятия “пользователь” и “заказчик” имеют сильно различающиеся значения.
Заказчик имеет финансовую основу, т.е. это тот, кто платит за сервис. Но это может означать не только оплату реальными деньгами. Иногда это может быть и ответственность за бюджет, т.е. лицо, кто его распределяет, или просто ответственность за приёмку работ с подписанием актов работ, без непосредственной их оплаты. Но каждый раз Заказчик — это позиция ответственного за получением большего результата в соотношении цены услуги к выгодам, которые та даёт.
Пользователь — это тот кто использует сервис. Пользователи имеют дело с входами и выходами услуги, а не с ее ценой и получаемой выгодой (ценностью). Пользователи — это носители мнения, основного на том, что услуга делает и ничего кроме этого.
На самом деле мы все уже знакомы с этой концепцией, т.к. она является частью наше повседневной жизни. Давайте покажу это на примере.
Выбор автомобиля
И так, представим, что Ваш автомобиль был украден, страховая компания присылает чек с компенсацией и Вы идете покупать замену. Вы обходите автодилеров в округе и на глаза попадается прекрасная сверкающая красная машина с симпатичной скачущей лошадкой на эмблеме.”О, да”, — думаете Вы: “я хочу ее получить”. Затем они говорят сколько стоит эта Феррари и Вы уезжаете домой на купленном в кредит подержанном Форде кормить своих детей.
Вы только что были Заказчиком, балансирующим свои пожелания и выгоды от владения автомобилем с его стоимостью и тем, что Вы можете себе позволить. Заказчик может найти компромисс, т.к. он видит оба аспекта. Пользователь же (например, Ваш ребенок, которому Вы даёте тоже пользоваться этим автомобилем) только водит автомобиль и никогда не бывает доволен, что именно он водит и всегда хочет большего, потому что это не его деньги.
История с игрушкой
Пожалуй, Вы уже участвовали на обеих сторонах в этом примере и в качестве взрослого, и как ребенок. Вы идете в магазин игрушек с сыном, дочкой, племянницей или племянником (представьте такую картину) и позволяете ему или ей оглядеть все выставленные игрушки и выбрать одну понравившуюся, обещая ее купить. Дети не будут смотреть на ценники, они будут сосредоточены на том, что игрушка умеет делать и на сколько им это нравится или на сколько они хотят ею обладать. Взрослые же имеют другие представления. Первое и главное, их заботит, что каждая игрушка имеет цену, за которую можно либо ее получить, либо получить от этих денег получение другой выгоды. Они могут пойти дальше и оценить образовательную или развлекательную ценность игрушки.
В этом примере взрослые выступают в качестве заказчиков, а дети — пользователей.
Различие ролей означает не только то что это разные люди.
В ИТ сценариях и в обычной жизни важно понимать, что заказчики и пользователи — это роли не обязательно выполняемые разными людьми. Вы можете выбирать выгодную опцию, выступая в роли заказчика, и ощущать недовольство позже из-за недостаточных функциональности, надёжности или поддержки (или отсутствия), выступая уже в роли пользователя.
Этот появляется в ситуациях, когда заказчик подписывает, например, соглашение об уровне обслуживания с поддержкой с 8 утра до 8 вечера по рабочим дням. Не смотря на то что это даёт ощущение хорошей экономии при покупке, пользователь будет не удовлетворен, когда в субботу не сможет воспользоваться услугой из-за ее отказа и никто не будет доступен, чтобы ему помочь до следующего рабочего дня.
Или для дома Вы можете иметь предложение от энергетической компании за дополнительные 400 долларов в месяц за гарантию стабильной и непрерывной подачи электроэнергии. Это может быть так много для вашего внутреннего заказчика и Вы отклоните это предложение. Потом когда спустя шесть месяцев, когда электричество “закончится” ваш пользователь будет огорчен, не то энергетической компанией, не то самим собой.
Как их не назовешь, а они будут все теми же двумя ролями
Конечно, только из-за того, что в ITIL используются именно эти два наименования: пользователи и заказчики, Вы не обязаны использовать их же. Но понимание значения этих понятий позволяет Вам эти две роли видеть и использовать. Заказчики, безусловно, должны принимать решения, на которые полномочны, а пользователи должны использовать услуги, если те соответствуют их навыкам, стилю работы, пристрастиям и общей культуре. Если это не будет выполняться, то услуги не будут использоваться на все их возможности и вряд ли будут представлять ценность для зарабатывания денег.
И это все не заканчивается, когда услуга запущена в эксплуатацию, текущая поддержка и запросы на улучшение п рождаются в виде диалога с обоими группами. ITIL предлагает каналов для обсуждений с ними обоими: и с заказчиками и с пользователями. Заключение и оценка выполнения соглашений об уровне обслуживания (SLA), процедуры по улучшению услуг, управление изменениями и т.д. взаимодействуют заказчиками. С пользователями же основной канал сказали это Служба поддержки (Service Desk), которая кроме приема звонков о проблемах с работой чего-либо также может собирать жалобы и пожелания пользователей и передать их в процедуры по улучшению услуг.
Передовые организации уже предприняли шаги для установления и поддержания контакта с обоими типами заинтересованных лиц в услугах. А Вы тоже так делаете?
Комментариев нет:
Отправить комментарий