Необходимо пересмотреть и перепроектировать процессы и действия для того, чтобы увеличить продуктивность, повысить ценность, уменьшить затраты и улучшить восприятие Заказчиков. Подумайте над вопросами: «Если бы это был Ваш бизнес, организовали бы Вы его таким образом? Такой ли штат сотрудников Вы бы определили? Так ли Вы бы им управляли?».

4.2.1 Подбор персонала.

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

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

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

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

4.2.2 Плановые метрики эффективности.

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

При установке таких метрик следует руководствоваться следующими принципами:.

■ не устанавливайте плановые значения, которые нельзя измерить;.

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

■ установите базовый вариант до того, как начнете обсуждать официальное Соглашение об уровне обслуживания (SLA) с Заказчиками;.

■ можно использовать общие SLA для формирования структуры сбора показателей и их использования при измерении эффективности выполнения условий SLA;.

■ убедитесь в том, что Заказчикам известно, что вы делаете и почему.

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

4.2.3 На что следует обратить внимание.

Ниже приведены основные моменты, на которые надо обратить внимание при создании Службы Service Desk:.

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

■ убедиться в поддержке руководства и в том, что требуемые бюджет и ресурсы доступны до начала работ;.

■ убедиться в том, что предлагаемое решение соответствует вашей стратегии по поддержке услуг и концепции развития;.

■ определить, достичь и сообщить о «быстрых победах» (например, обеспечение информированности заказчиков, сокращение времени инсталляции);.

■ четко определить цели и результаты;.

■ начать с малого; не надо пытаться сделать все сразу; использовать поэтапный подход;.

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

■ привлечь для консультаций конечных Пользователей;.

■ «продать» преимущества персоналу службы поддержки;.

■ обучить ИТ-персонал навыкам предоставления услуг;.

■ обучать/проводить тренинги для Заказчиков и Пользователей по использованию новой услуги и показывать ее преимущества;.

■ рекламировать и «продавать» свои услуги.

4.2.4 Выбор подходящей структуры Службы Service Desk.

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

4.2.5 Типы структуры Службы Service Desk.

Чтобы определить оптимальный вариант, необходимо рассмотреть три типа структуры Службы Service Desk:.

1. локальная Служба Service Desk;.

2.

центральная Служба Service Desk;.

3.

виртуальная Служба Service Desk.

Далее следует более подробное описание каждого из этих типов.

4.2.6 Локальная Служба Service Desk.

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

Рисунок 4.7 - Локальная Служба Service Desk.

При создании структуры локальных Служб Service Desk необходимо учесть:.

■ определение общих процессов по всем офисам и, там, где это возможно, общих процедур;.

■ информирование и обеспечение доступа к локальным навыкам для других Служб Service Desk;.

■ обеспечение совместимости аппаратного и программного обеспечения и сетевой инфраструктуры;.

■ использование единых процессов эскалации, а также единых кодов для определения влияния, степени важности, приоритетов и статуса во всех офисах;.

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

■ использование общих показателей для управленческой отчетности;.

■ совместное использование (логически) единой базы данных;.

■ если это возможно, создание возможности передавать или проводить эскалацию запросов между Службами Service Desk, предпочтительно автоматически.

4.2.7 Централизованная Служба Service Desk.

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

■ уменьшение операционных затрат;.

■ улучшение общего обзора бизнес-деятельности для руководства;.

■ более рациональное использование имеющихся ресурсов.

Рисунок 4.8 - Централизованная Служба Service Desk 4.2.8 Виртуальная Служба Service Desk.

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

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

■ уменьшение операционных затрат;.

■ возможности для улучшения общего обзора бизнес-деятельности для руководства;.

■ более рациональное использование имеющихся ресурсов.

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

Рисунок 4.9 - Виртуальная Служба Service Desk.

При внедрении Виртуальной Службы Service Desk следует иметь в виду:.

■ Весь персонал, имеющий доступ к Виртуальной Службе Service Desk, должен использовать единые процессы, процедуры и терминологию.

■ Ввод данных должен осуществляться на едином, приемлемом для всех языке.

■ Заказчики и Пользователи должны вести все общение через единую точку контакта. Следует рассмотреть возможность использования глобальных телефонных номеров и локальных номеров, которые перенаправляются на Виртуальную службу с использованием технологии Автоматического распределения звонков (Automatic Call Distribution, ACD).

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

■ Производительность сети должна соответствовать ее назначению. Она должна определяться на основе прогнозируемых уровней загрузки. Например, если локальная Служба Service Desk в Голландии обрабатывает только десять запросов в день, то пропускная способность сети не имеет большого значения. Тем не менее, низкая пропускная способность может оказаться большой проблемой, если необходимо обрабатывать несколько сотен запросов в день.

■ Для Виртуальной Службы Service Desk технические средства должны предоставлять возможность распределения загрузки и разграничения уровней доступа к информации. (Например, если кто-либо захочет воспользоваться локальной технической поддержкой, допустим, в офисе в Амстердаме, то этот пользователь сможет увидеть только запросы, связанные с этим офисом.) Эти разграничения также должны включать другие сопутствующие процессы и данные, такие как планируемые Изменения, данные об активах и конфигурациях.

■ В работе Виртуальной Службы Service Desk должны применяться согласованные процессы владения и управления Инцидентами. Должна существовать возможность автоматической передачи Инцидентов и текущего представления списка Инцидентов между локальными службами.

4.2.9 Конфигурирование Службы Service Desk.

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

■ бизнес-цели и результаты;.

■ уровень зрелости и навыков существующей службы поддержки;.

■ бюджет, механизмы учета и возмещения затрат;.

■ уровни и качество требуемой управленческой информации;.

■ размеры организации и вид ее бизнеса;.

■ политические соображения;.

■ организационная структура:.

отдельный офис, несколько офисов или центральный офис.

количество поддерживаемых Заказчиков.

часы, в которые должна обеспечиваться поддержка.

языки общения персонала службы поддержки и Заказчиков;.

■ охват, количество и типы приложений, которые необходимо поддерживать;.

стандартные;.

специализированные;.

сделанные на заказ;.

■ общие требования бизнеса (например, офисные программные средства);.

■ сетевая инфраструктура (LAN, WAN);.

■ охват, количество и типы аппаратного обеспечения/технологий, которые необходимо поддерживать;.

■ цикл обновления технологий;.

■ уровни навыков Заказчиков;.

■ уровни навыков основной массы Пользователей;.

■ уровни навыков персонала службы поддержки;.

■ количество сотрудников службы поддержки (первая и вторая линии);.

■ зависимость от внешних поставщиков;.

■ текущее количество обращений.

4.2.10 Глобальная круглосуточная поддержка.

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

■ возможность взаимодействия телекоммуникационных систем/коммутаторов;.

■ включены ли данные о поддерживаемых временных поясах в Соглашения об уровне обслуживания;.

■ доступна ли управленческая отчетность в местных и удаленных временных поясах;.

■ доступна ли поддержка на местных языках;.

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

■ локальные особенности и нужды, связанные с культурными различиями (например, в Испании часы работы часто разделяются на утренние и вечерние);.

■ должны быть определены локализованные SLA и Операционные соглашения об уровне взаимодействия (OLA);.

■ четкие процедуры эскалации и цепочка управленческой отчетности;.

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

Проектирование.

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

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

■ определить услугу или оборудование, с которыми связан Инцидент;.

■ связать существующие Соглашение об уровне обслуживания и Операционное соглашение об уровне взаимодействия;.

■ выбрать/определить тех специалистов или группы специалистов, которые наилучшим образом справятся с устранением Инцидента;.

■ определить приоритет и влияние на бизнес;.

■ оценить уровень загрузки;.

■ определить, какие вопросы должны быть заданы, и какая информация должна быть проверена;.

■ определить критерии привязки при выборе того или иного решения, Известных ошибок или Обходных решений;.

■ обобщить и определить, какие окончательные действия необходимо выполнить (например, требуется дополнительное обучение или неисправность не найдена);.

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

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

■ номер версии;.

■ поставщик;.

■ модуль программного обеспечения (например, печать, книга закупок);.

■ группировка (например, бизнес-приложения).

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

■ Инцидент успешно разрешен;.

■ требуется обучение Заказчика;.

■ требуется обзор документации;.

■ неисправность не найдена;.

■ требуется мониторинг;.

■ предоставлены рекомендации;.

■ необходимо оформить Запрос на Изменение.

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

4.2.12 Обзор процесса классификации.

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

Начните с малого и увеличивайте сложность модели исходя из требований бизнеса.