Мифы о портале самообслуживания

36591.strip

Не так давно на глаза попался пресс-релиз отчета Gartner «Addressing IT Self-Service Myths and Realities for Successful Implementations.» Пресс-релиз, как и отчет, не самой первой свежести (2010 год), но сути это не меняет. Авторы упоминают 4 мифа об организации порталов самообслуживания:

Миф 1: Порталы самообслуживания снижают затраты на предоставление ИТ-сервисов.
Реальность: Снижается только загрузка первой линии.

Действительно, если функциональне возможности портала будут ограничиваться традиционным списком:

  • самостоятельная регистрация обращений пользователя
  • просмотр статусов зарегистрированных обращений 
  • получение информации из базы знаний (FAQ)
  • выполнение простых операций без участия ИТ-специалистов (например, сброс пароля)

то мы сократим только время, которое тратят специалисты первой линии на регистрацию обращений пользователей, ответы на вопросы «А как там мое обращение?» и т.д. 
Сделать из мифа реальность можно добившись снижения загрузки второй линии за счет:

  1. Сбора максимального количества информации, необходимой для выполнения работ по обращению. Во многих компаниях, есть формы стандартных/сервисных/типовых запросов, которые пользователи заполняют в офисных приложениях и отправляют в службу поддержки. При заполнении они часто ошибаются, что-то забывают вписать, путают формы и т.д., что добавляет забот не только первой линии, но и второй, которой приходится разбираться в том, что имел ввиду пользователь.   
  2. Корректной маршрутизации обращений на вторую линию в зависимости от полученной информации. Если у вас используются ресурсы внешних компаний, то желательно их привлечение без участия специалистов второй линии, там где это возможно, например, при обслуживании орг.техники.
  3. Автоматизации выполнения операций без привлечения специалистов (предоставление прав доступа, развертывание ПО и т.д.). Естественно, что должно быть обеспечено проведение необходимых согласований.

Миф 2: Организация портала самообслуживания требует разовых инвестиций.
Реальность: Портал требует постоянных вложений

Тоже сложно поспорить. Чем больше «обязанностей» возложено на портал, тем чаще будет возникать необходимость что-то добавить, что-то изменить. Поэтому еще до начала реализации портала важно выявить часто меняющиеся разделы и оценить трудозатраты на развитие. Примеры направлений развития:

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

Миф 3: Пользователи ринутся  на портал самообслуживания.
Реальность: Бывает сильно по-разному.

​Пользователям надо суметь «продать» портал, то есть убедить их в том, что он им полезен. Многим пользователям, как ни странно, нравится простое человеческое общение с первой линией. Практика показывает, что чем сильнее пользователи связаны с ИТ-технологиями, тем большей популярностью у них пользуется портал. Например, в банке или телекоммуникационной компании вероятность получить высокую посещаемость портала выше, чем на металлургическом заводе. Очевидно, что на популярность портала влияет и удобство работы и преимущества, которые получает пользователь от электронного обращения (например, более быстрая реализация). Доступность первой линии тоже играет не последнюю роль, однако не следует снижать доступность в угоду посещаемости портала 🙂 

Миф 4: Внедрить портал самообслуживания просто.
Реальность: Помимо «правильного» средства автоматизации потребуется организация процессов, обеспечивающих актуализацию и наполнение портала и выполнении массы других важных требований. Кроме того, если по итогам регистрации обращений на портале внешние системы выполняют некоторые действия, то потребуется еще и интеграция с ними. 

Появление портала важно сопроводить включением в соответствующие процессы процедур, которые не только будут использовать его возможности, но и обеспечивать его актуализацию. Иначе есть риск, что портал замрет в своем развитии в состоянии «так внедрили».

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

А был ли у вас опыт реализации порталов самообслуживания, с какими сложностями столкнулись вы?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Павел Жаворонков

    Несмотря на давность публикации все еще актуально)

    У Заказчика есть портал, в котором возможно обращаться в ServiceDesk, но его нужно «докрутить».

    0
    0
  2. KGP

    Портал должен быть единым\полезным ресурсом, более эффективным для пользователя, чем email\телефон.

    На портал я бы ходил, если бы на нем

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

    2. Мои Фаворитные формы запросов.

    3. Возможность эскалировать к менеджеру текущего исполнителя.

    0
    0
  3. Алексей Лосев

    По первому мифу, часть портала реализована как интернет магазин, т.е. пользователь может очень точно заказать то, что ему нужно. А т.к. этот магазин фильтрует товары и услуги на основе SLA на которые подписан пользователь, то получается совсем хорошо.

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

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

    Ну а если говорить про сложности, то это интеграция с внешними системами. С системой управления заявками, с системой документооборота и т.д.

    0
    0
  4. Александр

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

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

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

    0
    0
  5. Андрей

    Портал САМООБСЛУЖИВАНИЯ. Из названия следует, что пользователь должен пользоваться им самостоятельно. Из опыта могу сказать, что это касается только заказа услуг и лучший вариант — некое подобие интернет магазина. Пользователь лучше всех понимает что ему нужно и посредник в виде диспетчера вносит только искажения в процесс. При этом важны следующие моменты — пользователю должны быть видны только те услуги, которые ему в принципе доступны. Параметры заказываемых услуг должны выбираться из списка возможных. Например, при заказе видео конференции в списках точек должны быть только те города, здания и помещения, где установлено необхоимое оборудование. Также можно посмотреть статус своих обращений (заявок и инцидентов). Всё остальное — только через специалистов. Хотя, что остальное? Инциденты при грамотно построенной системе мониторинга должны автоматически регистрироваться еще до того, как пользователь что-то заметит. Если, тем не менее, он обратился с инцидентом, то только профессионально подготовленный диспетчер может корректно классифицировать и зарегистрировать его, чтобы инцидент был сразу назанчен правильному сотруднику с необходимым контекстом. Организация общедоступных баз знаний для самостоятельного решения инцидентов — это из разряда самолечения на основе медицинской энциклопедии. Открыл, прочитал симптомы, поставил сам себе диагноз и сам себе назначил лечение. Всё просто! А эти дураки в медицинском годами учатся!:)))

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

    По поводу сокращения затрат. Может для ИТ оно и будет, но для компании в целом — вряд ли. Перекладывание работы с диспетчера на пользователя приводит к обратным результатам, поскольку час пользователя в основном бизнесе, как правило, стоит дороже часа диспетчера.

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)