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

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

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

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

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

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

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

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

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

Масштабируемость

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

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

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

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

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

Регистрация

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

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

· Уникальный регистрационный номер.

· Дата и время регистрации.

· Идентификационные данные о лице, регистрирующем инцидент.

· Идентификационные данные о лице, сообщившем об инциденте (включая фамилию, отдел, местоположение и контактную информацию).

· Метод контакта.

· Информация о затронутых конфигурационных единицах (CI).

· Описание симптомов и любых кодов ошибок.

· Действия, необходимые для преодоления затруднения.

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

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

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

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

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

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

Примеры категорий состояния:

· Новый. Инцидент был зарегистрирован, но все еще могут потребоваться разъяснения.

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

· Назначенный. Инцидент был назначен в группу решения и теперь ожидает прогресса.

· Активный. Выполняется действие по разрешению инцидента.

· Ожидание сведений. Действие временно приостановилось, ожидая получения дополнительных сведений.

· Запланированный. Дальнейшие действия не могут быть выполнены до запланированного времени.

· Приостановленный или находящийся в состоянии ожидания. Действие временно приостановлено в ожидании события или времени.

· Разрешенный. Считается, что инцидент разрешен. Служба поддержки должна подтвердить разрешение инцидента вместе с инициатором запроса до закрытия инцидента. Если инициатор запроса не удовлетворен решением, то состояние инцидента переустанавливается в "назначенный" или "активный".

· Закрытый. Инициатор запроса подтвердил, что инцидент разрешен и таким образом инцидент был закрыт.

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

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

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

На приведенном ниже рисунке показан типичный шаблон регистрационной записи инцидента.

Рисунок 4. Типичный шаблон регистрационной записи инцидента

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

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

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

Рисунок 5. Инцидент, сгенерированный предупреждением

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

· Пиктограмма часов или восклицательного знака рядом с инцидентом, когда рассматривается очередь инцидентов.

· Инцидент, выделяемый определенным цветом (например, красным), когда рассматривается очередь.

· Всплывающее диалоговое окно.

· Сообщение или письмо, посылаемое по электронной почте, которые направляются на определенное имя.

· Регулярный вывод сообщения (два - три раза в день).

Дата добавления: 2015-10-29