Начальная поддержка

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

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

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

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

Рисунок 13. Пример TechNet, базы знаний, доступной от Microsoft

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые факторы успешного достижения этого уровня интеграции являются следующими:

· Интерфейс для использования персоналом поддержки должен быть максимально автоматизированным и не громоздким.

· Интерфейс должен иметь надлежащие уровни доступности и надежности.

· Интерфейс должен предоставлять обеим сторонам соответствующую безопасность.

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

· Запланированное время разрешения и приоритеты должны быть надлежащим образом определены между организациями и четко поняты.

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

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