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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую