Заурбек Алехин, статья опубликована в журнале "Enterprise Partner", № 4(45), 2002 г. стр.11-13

(окончание статьи)

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

Документы, регламентирующие оказание поддержки пользователям.

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

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

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

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

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

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

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

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

Информация, предоставляемая службой поддержки.

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

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

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

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

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

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

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

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

Для службы поддержки таковыми метриками могут быть:

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

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

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

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

Средства автоматизации: ключевые характеристики.

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы. Как поступить.

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

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

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

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

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

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

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

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

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

Об авторе: Заурбек Алехин (alekhin@i-teco.ru), руководитель проекта, компания i-Teco г.Москва.