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

Портал самообслуживания как катализатор позитивных изменений

Опубликовано 24 ноября 2018
Рубрики: Service Desk, Всё это - ЛЮДИ, Постоянное улучшение, Практика и опыт, Управление инцидентами
Комментарии

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

Статья написана для того, чтобы продемонстрировать как создание портала самообслуживания может стимулировать позитивные изменения в работе внутреннего ИТ-подразделения компании.

Ситуация и текущая проблематика до создания портала

Несколько слов о компании:

  • крупная промышленная компания
  • географически распределенные подразделения
  • количество пользователей – более 3000
  • внутреннее ИТ-подразделение с низким уровнем зрелости ИТ-процессов.

Ситуация с первой линией:

  • Низкий процент закрытия заявок на первой линии (около 3%).
  • Постоянные жалобы пользователей на низкое качество обслуживания.
  • Массовые пропуски звонков в пиковые периоды.
  • Относительно долгое время регистрации поступающих заявок
  • Отсутствие заинтересованности в закрытии заявок на первой линии.
  • Постоянные типовые ошибки при регистрации заявок ( категоризация, приоритизация, назначение на исполнителей, “футбол заявками” и др)
  • прием заявок только по телефону или электронной почте
  • прием заявок по электронной почте требовал ручного заполнения пользователями форм данными которые уже содержались в CMDB
  • постоянные потери заявок в почте , значительные промежутки времени между поступлением заявок по почте и регистрации в ITSM-системе.

А теперь чуть подробней о текущей проблематике.

Отдельно хочется отметить издевательство над пользователями, которое выражалось в том, что бессердечные ИТ-специалисты обязывали пользователей заполнять длинные формы заявок и направлять их по почте , при этом почти всё требовалось выполнять вручную; некоторые заявки ИТ-специалисты первой линии поддержки забывали перенести из почты в ITSM-систему. Это приводило к тому, что порой простейшие запросы на заправку картриджей выполнялись неделями.

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

Например, для того чтобы заправить картридж для МФУ/принтера, пользователь направлял заявку по электронной почте, в которой необходимо было указать следующие атрибуты запроса: ФИО, подразделение, марку/модель МФУ или принтера, местоположение печатающего устройства, инвентарный номер, описать характер обращения. Часть заявок сотрудники первой линии забывали обработать в почте (перенести в ITSM-систему), что приводило к постоянному недовольству пользователей. Частенько  жалобы поступали на ИТ-отдел дождем.

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

Как была организована обработка запросов на обслуживание по печатающим устройствам до создания портала

Представьте, вы сотрудник компании и используете ИТ-активы. К примеру, вы используете МФУ в своей повседневной деятельности.

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

  1.  Подойти к МФУ, запомнить или записать идентификационный номер устройства
  2. Открыть корпоративную почту, авторизоваться
  3. Найти и ввести адрес почты службы поддержки
  4. Указать свое ФИО
  5. Указать свое подразделение
  6. Указать телефон пользователя
  7. Указать подробное местоположение кабинета где установлен МФУ
  8. Указать инвентарный или идентификационный номер МФУ
  9. Указать характер запроса
  10. Указать марку\модель МФУ
  11. Отправить заявку, выдохнув…

Теперь, что же происходит на «территории» ИТ после этого?

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

Подобные проколы постоянно случались и крайне негативно влияли на репутацию ИТ- подразделения, предел терпения близился к завершению…

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

Следует отметить то, что заявка на конкретного специалиста при регистрации еще пока не назначается, а назначается только на группу специалистов. Все это ожидает момента , пока менеджер этой группы не назначит на конкретного специалиста или кто-нибудь из специалистов не возьмет заявку из очереди, назначив на себя и начав ее выполнять. Обратите внимание, сколько “бюрократии”!

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

До разработки портала

До разработки портала ставились следующие цели:

  • максимальная простота, принцип минимализма в реализации интерфейса
  • высокая степень привлекательности интерфейса портала
  • регистрация заявки в ITSM-системе после выбора варианта заявки пользователем на портале и максимальная степень интеграции с данными в CMDB.
  • реализация принципов автоматизации за счет интеграции с CMDB
  • уход от ручного заполнения множества форм
  • снижение ошибок при регистрации
  • обеспечить пользователям дополнительные средства для регистрации заявок от имени других пользователей
  • разработать типовые формы для стандартных запросов на обслуживание с минимумом ручного ввода как со стороны пользователей, так и со стороны сотрудников первой линии.
  • разработать типовые страницы для отображения данных по печатающим устройствам и подачи заявок.

Мы постарались полностью исследовать текущую проблематику и, судя по результатам, большинство задач решить удалось.

Подробней о разработанном портале

Интерфейс портала был разработан на Microsoft Silverlight 5 и сторонних компонентах DevExpress, благодаря этому портал выглядел просто «симпатягой». Портал был интегрирован с CMDB с помощью родных средств интеграции. Портал автоматически идентифицировал пользователя по MAC адресу компьютера и соответствующей привязке компьютера к пользователю в CMDB. Портал позволял осуществлять множество дополнительных полезных функций, например:

  • отправка заявки от имени другого пользователя
  • отправка заявки от имени любого пользователя в кабинете (удобство в том, что если у Вашего коллеги нет сети или не включается компьютер\телефон, то можно быстро по списку компьютеров (или устройств связи) в кабинете отправить заявку- за несколько секунд Вы помогаете своему коллеге и отправляете заявку от его имени и на его ИТ-актив)
  • установка ПО без вмешательства ИТ персонала, несколькими щелчками пользователь может установить на свой компьютер ПО
  • отправка заявки на любое устройство по идентификационному номеру
  • отправка заявок по АСУТП
  • механизм контекстной подсказки для пользователя при выборе варианта (этот механизм позволял пользователю попробовать типовые варианты, при которых отправка заявки уже не требовалась , ибо нужная информация была выведена на экран)
  • возможность в реальном времени устранить некоторые типовые инциденты с помощью предопределённых сценариев которые были интегрированы с порталом (к примеру, когда пользователь не мог запустить корпоративную систему СЭД, портал позволял в реальном времени перезапустить процесс в ОС и тем самым помогал пользователю в полном устранении инцидента без вмешательства ИТ-специалистов)
  • возможность формирования массовых заявок на перемещении ВТ при переездах из одного кабинета в другой, что экономило массу времени и нервов и не требовало написания традиционных служебных записок.
  • три типа интерфейса в зависимости от уровня компьютерной грамотности пользователей

Техническая реализация:

  • использование cредств интеграции портала с API ITSM-системы (SDK)
  • язык программирования – C# (в отношении Silverlight использовался XAML)
  • часть дополнительных веб-сервисов было разработано с применением ASP.NET
  • среда разработки – Microsoft Visual Studio 2010
  • интерфейс портала – компоненты Developer Express
  • встроенные средства проверки “здоровья сервиса”, мониторинг значимых компонентов (БД, клиента на компьютере пользователя, веб сервиса и тд)
  • автоматическая установка и обновление клиента Silverlight на компьютере пользователя.
  • реализация разных типов клиента (windows приложение, веб приложение)
  • реализация логики приоритизации и маршрутизации заявок на стороне ITSM-системы
  • интеграция с системой Workflow.
  • полное формирование атрибутов заявки за счет интеграции с CMDB.

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

Портал разработан и запущен в работу

Портал произвел положительный эффект  во многих бизнес подразделениях компании и в самом ИТ-подразделении.

Вернемся к типовым запросам на обслуживание печатающих устройств о которых была речь выше. Итак, портал запущен в работу. Для отправки заявки на заправку картриджа МФУ, пользователю больше не требовалось подходить к МФУ и запоминать инвентарный номер или идентификационный номер с инвентарной наклейки. Пользователю больше не требовалось открывать корпоративную почту и вручную вводить данные  (которые уже присутствовали в CMDB)  и информацию о характере запроса.

Все что теперь требовалось от пользователя, это:

  1. Запустить портал (пользователь идентифицируется автоматически)
  2. Выбрать на портале раздел «Печать» (после этого на странице отображается информация о печатающих устройствах, которые находятся в кабинете пользователя согласно данным в CMDB)
  3. Выбрать вариант запроса рядом с печатающим устройством и нажать кнопку «отправить»

И на этом всё!

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

Это лишь половина преимуществ и надо отметить, что после нажатия пользователем кнопки «отправить», происходит следующее:

  1. информация по инциденту или запросу на обслуживание немедленно регистрируется в ITSM-системе (ФИО, подразделение, КЕ, местоположение КЕ, тема запроса, категория запроса, уточняющее примечание, исполнитель, срочность, воздействие, приоритет) Портал интегрирован с CMDB и вся информация извлекается из базы.
  2. Заявка автоматически (для каждого варианта заявки на портале,  менеджер группы исполнителей может указывать конкретных исполнителей) назначается на конкретного исполнителя.
  3. Направляется уведомление по почте исполнителю, менеджеру исполнителя.

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

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

Заключение и результаты

Эффект от внедрения портала был значительным, вот некоторые положительные изменения:

  • нагрузка на первую линию по звонкам и обработке заявок по электронной почте после 3 месяцев с момента запуска портала, снизилась на 60%.
  • время реакции и выполнения заявок было значительно улучшено как на первой, так и на второй линиях поддержки
  • через год после запуска , на портале  регистрировалось около 80% поступающих заявок
  • у первой линии стало больше времени на обработку и выполнение заявок (часть рутинных действий по регистрации заявок легла на портал) , в течении года процент закрытия заявок на первой линии достиг 50%
  • портал имел преимущественно положительные отзывы от пользователей
  • улучшение качества регистрации заявок
  • снижение общего количества инцидентов и запросов на обслуживание за счет средств интеграции портала с ITSM-системой и автоматизации
  • улучшение восприятия ИТ со стороны пользователей

После запуска мы столкнулись с некоторым сопротивлением со стороны первой линии поддержки , об этом уже в следующей части статьи.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

  • Леонид

    Котоламповая история;) Ситуация «до» настолько клиентоориентированная, что не вериться в возможность перевоспитания этих дикарей одной лишь системой автоматизации. И низкий уровень зрелости процессов тут очевидно не первая проблема.

    • Денис Подольский

      Ну как Вам сказать, Леонид.

      Да, Вы правы, запустив портал , их не перевоспитали, такой цели и не стояло. Мы просто задали некую планку, устранили “кривоту” во внутренних ИТ процессах. Часть пользователей просто перестали звонить на первую линию и пользовались только порталом. Некоторые спецы почувствовали свою ненужность и у них не оставалось другого выхода кроме как стараться быстрей и качественней регистрировать заявки, а также больше выполнять на первой линии ибо основную деятельность 1 линии по регистрации , портал “перетянул” на себя. Во второй части я раскрою как это происходило.

  • Дмитрий Алексеевич

    Как в сказке. Сейчас разрабатываем портал самообслуживания с такими же плюшками, мои ожидания – 10-15% обращений, Ваши 50-60% мотивируют 😉
    Жду продолжения.

    • Денис Подольский

      Дмитрий

      Первый шаг, добейтесь поддержки ИТ-директора, а еще лучше – Гендира. Плюс, осветите преимущества для пользователей. Я на портале выкладывал не сухие мануалы, как пользоваться порталом, а выкладывал видео, как подать ту или иную заявку. Количество просмотров этих роликов было высоким. Еще раз повторюсь, что портал разрабатывался на сильверлайте, мордашка портала выглядело нестандартно и красиво. Это не просто веб страничка с приевшимися контролами, на портале были 3Д элементы, карусели и прочие плюшки, плюс , все работало быстро, надежно и как говорится – юзер friendly. Ну и конечно, в бекграунде была достаточно сильная ITSM система в которой гибкий механизм автоматизации обработки заявок.

  • Андрей

    Денис,
    в вашей статье названы технологии, продукты и языки. Это не сочли за рекламу.
    Назовите плиз и ITSM систему.
    И еще, в “До” сказано, что зрелость IT-процессов была не высокой. А CMDB кто-то не только внедрил, но и КЕ набил :). Как это?

    • Леонид

      Андрей,
      Если только “CMDB” не состояла только из названий КЕ с инвентарниками, качнули у бухов за шоколадку.;)

    • Денис Подольский

      Андрей.

      Речь об Altiris. В россии эта система мало где используется.

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

  • Сергей

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

    • Денис Подольский

      Добрый день.

      \\Но я обратил внимание что первая линия была занята решением заявок

      Наоборот, они закрывали лишь 3% поступающих. Очередная деятельность на 1 линии – лишь регистрация, да и то, масса ошибок при категоризации, маршрутизации и тд. Качество регистрации было очень низкое.

      \\Решение заявок с первой линии как видно из описания никто не снимал (не оставляли 1-ой линии функцию только регистрации\классификации\маршрутизации) и непонятен эффект описанный в описании.

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

      Основной эффект портала заключается в том, что он освободил от рутинного ввода как людей на стороне ИТ, так и и людей со стороны бизнеса. Кроме этого, портал сделал регистрацию заявок : удобной, быстрой и эффективной. К примеру на портале была отдельная фишка для регистрации крупных инцидентов, при этом система задирала приоритет и веерно направляла письма в соответствии с правилом иерархической эскалации., плюс это отправлялось с портала на дашборд и там начинало красным светится.

      \\1-ая линия раньше не снимала трубку потому что решала заявки, с порталом не сможет обрабатывать (классифицировать\маршрутизировать ну кроме совершенно явных) обращения — т.к. всё так же решает заявки. Вот здесь непонятно.

      Опять же напоминаю о 3% закрытия на первой линии. Вам кажется это волшебством, но портал действительно имел механизмы для полной классификации тикетов. Заявки сразу поступали на вторую линию, на конкретных спецов. На портале был создан модуль обработки заявок, который отдельно анализировал поступающие заявки, текущую нагрузку персонала. Механизм реализации базировался на маппинге данных из СМДБ и связки входного классификатора заявок с данными в helpdesk (категории, типы событий и тд) Чтобы было совсем понятно, после регистрации на портале, тикет был полностью готов и все необходимые атрибуты были заполнены. При этом , была сделана отдельная заглушка на портале, если юзер не нашел нужного варианта то он мог указать свой вариант , а 1 линия получала пометку в тикете что его надо классиицировать и тд. С течением времени таких “своих” вариантов было все меньше. Как-то так 🙂

  • Екатерина

    Добрый день, на эту тему, наверняка, сказано было уже много, но все-таки, как вы стимулировали пользователей пользоваться порталом, а не звонить в поддержку? Какой бы красивый ни был портал, пользователям всегда удобно (потому что привычно) снять трубку и позвонить. И единственным на сегодня способом вижу только менять правила дозвона и отключать тех, кто может дождаться помощи удаленно (не работает с клиентами в моменте, например). Но может быть есть более “человечные” способы?

    • Сергей

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

      Как некий промежуточный выход, можно предложить снизить (ужесточить SLA сами для себя – читай за свой счёт) время реакции\решения заявок поданных через портал. 🙂

    • Денис Подольский

      Екатерина, добрый день.

      Я наверное отвечу так.

      1. с течением времени юзеры действительно привыкают звонить и это становится для них привычкой, а раз привычка, то значит это комфортно, знакомо и тд

      2 в статье описано, что определенный вид ЗНО юзеров заставляли отправлять только через почту, при этом надо было заполнять тонну данных, все вручную.

      3. восприятие первой линии – разное. Есть говорливые юзеры которые иногда монополизируют внимание спецов на 1 линии, есть обратный вариант – когда говорливый спец с 1 линии ну просто любит долгое время болтать с юзерами. Такое было.

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

      \\как вы стимулировали пользователей пользоваться порталом, а не звонить в поддержку?

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

      Глядя на все это, я проектировал портал так, чтобы он фиксил сразу несколько “болячек”.

      После запуска портала проинформировали юзеров , часть юзеров заинтересовалась, части юзеров это было не интересно. Но заявки ,которые регистрировались через портал почти сразу попадали к исполнителям на второй линии и разница между тем , какое время эти заявки “варились\мариновались” у ИТ (до запуска портала) была огромна. Естественно люди делились между собой тем, что им понравилось. молва о портале пошла по компании и число юзеров стало резко расти, процент регистрации заявок бодро шел вверх. На портале были выложены видео о том, как отправить ту или иную заявку. Это людям понравилось. Сухие мануалы всем надоели ) Плюс, напомню что портал в реальном времени позволял юзерам фиксить проблемы без вмешательства ИТ спецов. Что выберете, зайти на портал, нажать пару кнопок и Ваш зависший лотус оживет или ждать кучу времени ИТ спеца если не догадаетесь перезапустить комп. Что выберете, зайти на портал и поставить софт или долго трезвонить по телефону, а потом еще долго ждать пока отработает ИТ “бюрократия”? Кроме этого , портал еще смотрел здоровье базовых сервисов на компе юзера и проверял их, юзер же получал инструмент который работал как виртуальный ИТ спец. Глючит безбожно софтина? Дай возможность отработать автоматике, она снесет софт, подчистит то что мешает и поставит заново. Вот так еще портал работал. И эти возможности портал имел только потому, что портал был интегрирован с ITSM Altiris, которая обладает весьма широким функционалом. Мне приходилось крутить разные системы, но Altiris – шедевральный! Надежность, кастомизируемость системы – выше всяких похвал.

      Забегая вперед, скажу что руководителю 1 линии это не понравилось, он сделал вывод, что запуск портала может ударить по численности 1 линии. Началось своего рода противостояние. Одной из вех было то, что позже вышел приказ ГД компании о том, что заявки необходимо регистрировать через портал.

      \\И единственным на сегодня способом вижу только менять правила дозвона и отключать тех, кто может дождаться помощи удаленно (не работает с клиентами в моменте, например). Но может быть есть более «человечные» способы?

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

      • Сергей

        \\\Одной из вех было то, что позже вышел приказ ГД компании о том, что заявки необходимо регистрировать через портал.
        Сергей: По моему это самый большой демотиватор и пользователей и специалистов поддержки.
        Как показатель что портал не стал настолько удобен что юзера сами стали им пользоваться и пришлось это делать в приказном порядке отказывая регистрировать заявки по телефону или почте.

        //Я скажу Вам так, регистрация заявки по телефону — это прошлый век.
        Если регистрация заявки по телефону удобнее пользователю – прошлый век отрицать этот факт. Значит проблема не в пользователе а в новом механизме и PR этого механизма.
        Это ИМХО – прошу не обижаться.

        • Денис Подольский

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

          Портал стал популярен задолго до выхода приказа.

          \\Если регистрация заявки по телефону удобнее пользователю — прошлый век отрицать этот факт. Значит проблема не в пользователе а в новом механизме и PR этого механизма.

          Мы делали замеры по времени, анализ и многое другое в части регистрации , выводы – портал эффективней спеца 1 линии на порядок. Стоит подчеркнуть, что регистрация тикета почти в любой ИТСМ системе – некий аналог ада (масса атрибутов, вагон полей, дропбоксы и прочая святотень) и это мое субъективное мнение и если хотите, я поясню дополнительно этот тезис.

  • Алексей

    Добрый день!

    По приведенному вами описанию можно предположить, что речь идет про довольно большую компанию, раз там есть первая линия и достаточно много заявок, и видимо это какая-то чрезвычайно консервативная компания. В моем понимании вы описали прямо ИТ-апокалипсис. Но в наше время иметь такую ситуацию в техподдержке непозволительная роскошь, меня бы давно уволили, если бы ситуация в моей компании соответствовала хотя бы 10 процентам того что вы описали в части “до”. Портал конечно неплохой канал подачи заявок, но тоже не самый удобный, ИМХО. И начинать надо с людей и процессов, снижать бюрократию… И какая-то странная ITSM-система, которая не может обрабатывать заявки из почты. Про количество ненужной запрашиваемой информации от пользователей я вообще молчу, это просто чудовищно!!!

    • Денис Подольский

      Добрый день!

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

      компания большая, да. Ну , насчет консервативности вряд ли, Порой юзеры\заказчики совсем не знают что такое “хорошо” и “плохо”. Им порой не с чем сравнить и они имеют дело с тем уровнем, на который способен ИТ, а этот уровень зависит от того, кто руководит ИТ.

      Добрый день!

      \\В моем понимании вы описали прямо ИТ-апокалипсис.

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

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

      \\И какая-то странная ITSM-система, которая не может обрабатывать заявки из почты.

      Верно – может, но что будет результатом? Ну пришло письмо , отмапировался емейл, в тикет попала инфа о заявителе, компьютере (если юзер вколотил хостнейм) и на этом все.
      Ни категории, ни типа тикета, на маршрутизации, ни верной формулировки темы тикета, ни комментария, другими словами – обработка по емейл далека регистрации тикета с заполнением большинства атрибутов, не говоря уже о маршрутизации и не говоря о том, что указывать инфу о конфигурационных единицах через почту – просто ад , это просто будет работать только при условии выполнении массы правил , которые предписывают юзеру не ошибаться воообще, а это – утопия. На портале , к примеру, компьютер юзера определяется автоматом и после регистрации заявки инфа о компьютере гарантированно шьется в тикет. При регистрации заявки на заправку картриджа, подобным образом, юзеру автоматом показываются принтеры в его кабинете и выбирая вариант, информация о принтере, опять же – шьется в тикет. Таким образом портал позволяет не только регистрировать заявки , а каждый раз в тикет поступает информация о КЕ. Сделать это через маппинг почты, почти нереально 🙂

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

      \\Про количество ненужной запрашиваемой информации от пользователей я вообще молчу, это просто чудовищно!!!

      Это еще цветочки)

  • Сергей

    \\\\Ни категории, ни типа тикета, на маршрутизации, ни верной формулировки темы тикета, ни комментария, другими словами — обработка по емейл далека регистрации тикета с заполнением большинства атрибутов, не говоря уже о маршрутизации и не говоря о том, что указывать инфу о конфигурационных единицах через почту — просто ад , это просто будет работать только при условии выполнении массы правил , которые предписывают юзеру не ошибаться воообще, а это — утопия.
    Сергей: не умаляя проделанной работы.
    Юзеру действительно проще сообщить что у него не работает комп или принтер.
    Не указывать модель копа\принтера и другие параметры.
    Далее проблемы спецов поддержки. Есть ITSM система и CMDB и из неё можно посмотреть что за комп у юзера, по каким принтерам он обращался ранее.
    Раньше юзер это инфу вписывал в форму карточки заявки, теперь вынужден заполнять на портале (выбирая принтер), что то конечно автоматом подтягиваться может.

    Заполнение кучи полей просто перенесли из бумаги в портал (частично автоматизировав).
    Проблему самого заполнения ( надо ж научить правильно что то выбрать, а не то заявка будет гулять не туда или не с той классификацией которая нужна) при наличии ITSM и CMDB из которой можно узнать инфу КАК РЕШИЛИ?

    И попутный вопрос:
    Обычно первая линия – самый дешёвый ресурс сервиса (особенно вынесенная на перефирию). Т.е. диспетчеров можно нанимать пачками (особенно если они всего 3% заявок только решают или не решают вообще). ITSM – система есть.
    Кто то подсчитал что было бы дешевле – нанять пяток диспетчеров на 1-ую линию, что б пользователь дозвониться смог и повысить корректность обработки заявок или внедрить портал самообслуживания попутно его поддерживая (а это дорогие спецы) и развивая (дорогой менеджмент). Есть в этом направлении какая то статистика?

    • Денис Подольский

      \\Юзеру действительно проще сообщить что у него не работает комп или принтер.

      То, что юзеры перестали звонить и перебрались на портал, говорит об обратном.

      \\Далее проблемы спецов поддержки. Есть ITSM система и CMDB и из неё можно посмотреть что за комп у юзера, по каким принтерам он обращался ранее.

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

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

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

      Я Вам просто объясняю кое какие вещи , портал был спроектирован таким образом, что практически не требовал никакого ввода кроме уточняющих комментариев. Просто работали и были использованы нужные ассоциации в СМБД, юзер-девайс, девайс-локация и тд и все это было приведено к такому виду, что не было , как такового, заполнения форм.

      \\Заполнение кучи полей просто перенесли из бумаги в портал (частично автоматизировав).

      Вы статью читали невнимательно )

      \\Обычно первая линия — самый дешёвый ресурс сервиса (особенно вынесенная на перефирию). Т.е. диспетчеров можно нанимать пачками (особенно если они всего 3% заявок только решают или не решают вообще). ITSM — система есть.

      Не очень обоснованное утверждение. Зависит от компании и других факторов.

  • Сергей

    Сергей: Юзеру действительно проще сообщить что у него не работает комп или принтер.
    \\\То, что юзеры перестали звонить и перебрались на портал, говорит об обратном.
    Сергей: Я читал про приказ гендиректора дословно и понятно.
    “Одной из вех было то, что позже вышел приказ ГД компании о том, что заявки необходимо регистрировать через портал.”

    Сергей: Далее проблемы спецов поддержки. Есть ITSM система и CMDB и из неё можно посмотреть что за комп у юзера, по каким принтерам он обращался ранее.
    \\\Это долго и муторно.
    Сергей: может проблема в этом а не в том что юзера заставляют писать при подаче заявки какой у него ком или принтер?

    Сергей: Обычно первая линия — самый дешёвый ресурс сервиса (особенно вынесенная на перефирию). Т.е. диспетчеров можно нанимать пачками (особенно если они всего 3% заявок только решают или не решают вообще). ITSM — система есть.
    \\\\Не очень обоснованное утверждение. Зависит от компании и других факторов.
    Сергей: непонятно что обосновывать надо, написал “ОБЫЧНО”
    Вопрос в просчёте что было дешевле нанять пяток диспетчеров на первую линию или купить\настроить и поддерживать портал.

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

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

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