Как построить службу поддержки пользователей ИС

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

Регламентирующие документы

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

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

«Регламент осуществления поддержки пользователей» — основной документ, в котором детально описаны все процессы, реализуемые службой поддержки пользователей, правила взаимодействия специалистов в рамках ИТ-департамента, правила взаимодействия с пользователями и внешними поставщиками сервисов.

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

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

«Документация по средствам автоматизации». В нее, как правило, входят «Руководство администратора», «Руководство системного программиста», «Руководство пользователя», а также «Паспорт системы» для каждой из применяемых систем автоматизации службы поддержки.

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

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

Предоставление информации

Одна из весьма важных функций службы поддержки пользователей (кроме собственно оказания помощи пользователям) — это накопление информации, характеризующей:

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

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

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

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

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

Оценка деятельности службы поддержки

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

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

Многие из приведенных метрик не несут непосредственной информации для оценки; смысл имеет их динамика, т. е. сравнение показателей за текущий период с предыдущими периодами.

Учет приведенных и иных параметров, их дальнейший анализ должны позволить оптимизировать процессы, реализуемые службой поддержки; сократить (или, наоборот, увеличить) численность тех или иных специалистов; определить перечень направлений, по которым следует провести дополнительное обучение пользователей.

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

Средства автоматизации

Третий (после четких правил и подготовленного персонала) ключевой элемент системы поддержки пользователей — специализированные технологии, используемые для деятельности сотрудников в соответствии с оговоренными правилами.

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

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

• системы «самопомощи» — автоматизированные системы, дающие пользователям возможность без участия диспетчера выполнить определенные действия: регистрацию заявок, получение информации и т. д.;
• экспертные системы, базы знаний;
• средства группового взаимодействия и управления работами;
• средства регистрации и учета заявок;
• средства мониторинга сервисов и отдельных их элементов;
• средства анализа и отображения информации.

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

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

Некоторые из перечисленных недостатков удается устранить, адаптируя несложные программные продукты для целей автоматизации службы поддержки. Например, в небольших организациях часто используют стандартный офисный пакет: текстовый редактор, электронные таблицы и простейшую СУБД. Как правило, этот вариант намного лучше, чем «бумажный», но все же возможности его весьма ограничены, и большинство операций сотрудникам приходится выполнять вручную. Это, как и прежде, приводит к потенциальным ошибкам, усложняет процедуры, требует дополнительных затрат времени. Часто такая автоматизация заслуженно воспринимается как нечто лишнее, только мешающее нормальной работе персонала. В итоге сотрудники не используют системы по назначению и работают так, как им удобнее. Отдельные репрессивные мероприятия периодически «подогревают энтузиазм» в использовании средств автоматизации, но его хватает ненадолго.

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

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

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

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

В идеале систему следует строить «с нуля», выбрав за основу достаточно производительную СУБД. В этом случае решение будет максимально полно отвечать потребностям организации. С другой стороны, цена такого решения окажется весьма существенной, поскольку предстоит разработать довольно сложный продукт и обеспечить его дальнейшее сопровождение. К тому же это потребует длительного времени: системы такого класса не создаются быстро.

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

Как поступить

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

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

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

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

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

Много ли организаций, готовых сделать все самостоятельно? Вопрос скорее риторический. В то же время не стоит воспринимать ситуацию как категоричное «нет». Существует множество промежуточных вариантов, в том числе привлечение внешних исполнителей на отдельных этапах. Есть и возможность приобрести некое стандартное (и поэтому более дешевое) решение, а дальнейшую его доработку провести собственными силами через некоторое время по итогам эксплуатации. Имеются и иные возможности.

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

Принятие решения о приглашении консультантов — шаг, требующий определенных раздумий и преодоления существенного внутрикорпоративного сопротивления. С другой стороны, большинство успешных проектов было реализовано именно при участии внешних специалистов, что свидетельствует о полезности такого шага. В любом случае решение за вами…

Заурбек Алехин — руководитель проекта в компании i-Teco. С ним можно связаться по e-mail: alekhin@i-teco.ru.