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

Карточные фокусы, или Победа сил разума над силами добра

Иногда процессы (процедуры/правила/формализация) берут верх над сервисами (ценностью/пользой/удовлетворённостью). То есть всё делается строго по правилам, а результат даёт обратный. Поделюсь парой примеров из недавнего опыта. 


Пример 1. Поддержка пользователей и устранение инцидентов.

Время от времени наш ребёнок, студент одного из питерских институтов, приезжает домой в Москву. А потом уезжает обратно. Чтобы эти путешествия были чуть менее накладны, при покупке билетов мы используем карточку "Сапсан молодёжная", она даёт 15% скидки при покупке билетов на поезда Сапсан. Так получилось, что купленный на сегодняшний вечер билет мы решили поменять на сегодняшнее же, но утро. Для этого на сайте, где продаются билеты, по старому оформили возврат, а новый попытались купить. И оказалось, что купить его можно только без скидки. Карточка не действовала, точнее, при её использовании процесс покупки останавливался с ошибкой. Без карточки всё работало прекрасно, но дороже. Мы купили билет за полную стоимость и обратились в службу поддержки. 

Этап 1, телефонный, был очень коротким. Меня выслушали и сообщили примерно следующее: "По этому вопросу вам следует обратиться по электронной почте. Они работают круглосуточно, норматив ответа на обращения – два часа, но обычно отвечают быстрее." Так я и сделал. 

Этап 2, электронно-почтовый. Я отправил письмо с описанием ситуации и скриншотами, иллюстрирующими её, в 23:40. Первый ответ получил в 0:39. И дальше получился такой диалог:

Служба поддержки, 0:39: Уважаемый Роман! Благодарим Вас за обращение в Единый Информационно-Сервисный Центр ОАО «РЖД». Уточните, пожалуйста, дату приобретения дорожной карты.

Я, 0:46: Любовь, карту купили в сентябре 2013 года. Нужна более точная информация?

Служба поддержки, 2:16: Уважаемый Роман! Благодарим Вас за обращение в Единый Информационно-Сервисный Центр ОАО «РЖД».  По Вашему запросу проведено тестирование сайта. По указанным реквизитам поездки заказ оформляется корректно, ошибки не возникает.

Я, 2:32: Спасибо за информацию! Это, наверное, хорошо. Но как это помогает нам?

Служба поддержки, 2:56: Уважаемый Роман! Уточнение данной информации займёт дополнительное время. Ответ будет направлен на адрес Вашей электронной почты позже.  Приносим извинения за причинённые неудобства.

Служба поддержки, 8:45: Уважаемый Роман! Благодарим Вас за обращение в Единый Информационно-Сервисный Центр ОАО «РЖД». Приносим извинения за длительное время ответа. По Вашему запросу может быть составлено обращение, официальный ответ на которое направляется только на почтовый адрес. Для передачи Вашего обращения в ответственное подразделение, пожалуйста, укажите Ваш почтовый адрес, включая индекс и номер телефона, по которому можно будет с Вами связаться в случае необходимости. Обращение рассматривается в течение 30 дней с момента его регистрации.Обработка Ваших персональных данных будет произведена в соответствии с Федеральным законом о персональных данных N 152-ФЗ  (ред._ от 23.07.13).

То есть с точки зрения процесса и формальных нормативов поддержки у них там всё хорошо:

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

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

  1. Всё ли в порядке с картой? Будут ли предоставлены по ней скидки в дальнейшем? 
  2. Если да, то почему возникла описанная ошибка и можно ли получить компенсацию непредоставленной скидки? 
  3. Если нет, и с картой какие-то проблемы, что сделать, чтобы в будущем карта работала, и скидки предоставлялись? 
  4. Если всё правильно, и скидка не должна быть предоставлена (второй раз за один день, в субботу, по утрам…), то где можно ознакомиться с правилами, которые это определили?

​То есть, простите меня за жаргон, outputs процесса поддержки (закрытые обращения) налицо, а outcomes (удовлетворенный потребитель, нормально работающая услуга) – как-то не очень. А сделано всё строго по правилам. 


Пример 2. Автоматизация производственного процесса. 

У меня есть карточка постоянного покупателя Stockmann. До ближайшего магазина Stokmann от моего дома примерно метров 500, так что пользуюсь я ей чаще многих. Так вот, у этой карточки не работает магнитная полоса. Кассиров в ближайшем магазине это никак не смущает, они после первой неуспешной попытки считать карту тут же вводят её номер руками – то, что ITIL называет manual workaround, находится у этих кассиров в активном наборе рабочих процедур. А вот их коллеги в Stockmann  в городе Хельсинки применяли это решение только после длительной консультации с базой знаний: им, видимо, не приходится делать это часто. И все они очень удивлялись: как это, почему это она не читается? 

Зайдя в очередной раз в магазин в Москве, я заглянул в отдел обслуживания покупателей и попросил их дать мне карточку с работающей магнитной полосой. (Мне как покупателю по очень большому счёту всё равно, работает она или нет. Здесь, пожалуй, главная польза – в сокращении времени обслуживания. В какие-нибудь "сумасшедшие дни", когда в универмагах этой сети аншлаг и очереди, ввод 16 цифр для каждого покупателя вместо автоматического считывания информации может заметно сказаться на времени обслуживания. Не говоря уж о том, что информации на той полосе существенно больше, чем 16 цифр, и гипотетически она может понадобиться. В общем, сделать так, чтобы карты работали правильно – в интересах магазина.) И вот какой у нас получился разговор:

Я: Вот, не работает полоса. Давайте починим. 

Они: Мы не намагничиваем карты. 

Я: И не надо. Дайте мне другую, работающую. 

Они: Мы и не меняем тоже. Вы получите новую карту по истечении срока действия этой. Он у вас когда истекает?

Я: В июне 2016 года.

Они: Вот тогда и поменяем. 

Я: А может, мне тогда просто новую открыть?

Они: Если вы уже есть у нас в базе, вторую мы вам открыть не сможем. 

Я: А если я её, скажем, потерял?

Они: Тогда мы вам выдадим новую. 

Я: О. Тогда я её как раз потерял. Буквально только что. 

Они: Хорошо, давайте паспорт. Выдадим вам другую. 

Занавес. 

Здесь, как мне кажется, другой случай, хотя тоже формальное следование правилам не только не ведёт к конечному результату, но отдаляет нас от него. Разница, на мой взгляд, состоит в том, что в истории про билеты процедуры изначально спроектированы не для того, чтобы помочь потребителю, а для того, чтобы от него отбиться. В то время как в истории с магазином дело, скорее всего, в отношении конкретного сотрудника к исполнению своих обязанностей и интересам компании, в которой этот сотрудник работает (мне отчего-то кажется, что директор магазина решил бы эту ситуацию сразу – если не нашего магазина, то уж магазина в Хельсинки – наверняка).


Но общее впечатление – очень схожее: правила есть, правила исполняются, польза от их исполнения сомнительна. Видимо, именно о такой практике думали авторы манифеста сервис-менеджмента, добавляяя в список ценностей ITSM слова " творчество и мастерство — важнее процессов, результаты — важнее услуг".

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Борис

    Я не уверен, что первый случай – это не дорога, выложенная благими намерениями. Вполне возможно случай такой же , как "в отношении конкретного сотрудника к исполнению своих обязанностей".

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

    Тогда получаются две ошибки: 1) неправильно мониторится качество. нужно мониторить именно удовлетворенность клиента, а не качество. Две ссылки в письме "нравится" и "не нравится" при больших объемах дадут более полезную статистику, чем количество писем и время ответа 2) слишком сильно сжаты сроки на ответ. первый ответ за 2 часа – ок, пожалуйста. Но стоит объявить, что каждый следующий будет поступать в зависимости от сложности инцендента.

    Что касаемо отфутболивания – с этим сталкиваюсь часто. Увы, у меня схожая ситуация. Работа техподдержки сложного ПО ведется в рамках OTRS. Совершенно логично, что периодически в техподдержку поступают вопросы, касающиеся расширения, продления, покупки лицензии на ПО. Этими вопросами занимается другое подразделение компании. Вместо того, чтобы перенаправлять запрос в рамках OTRS с мониторингом времени ответа и т.п. в другую очередь этих запросов, я вынужден футболить клиентов: пишите на другой e-mail.

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

    В данный момент вынужден отправлять пользователю письмо, что его запрос направлен продавцам и слать копию продавцам. Что лишь частично исправляет последнюю проблему.

    В описанном Вами случае уже оператор на телефоне должен был спросить e-mail клиента и предложить оформить заявуку в тикетсистему, а не предлагать клиенту повторно обращаться в поддержку.

  • Мне вот вообще сегодня автоответчик сказал, что я в очереди "одно"…


Добавить комментарий для БорисОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;