- •Введение
- •1 Сравнительный анализ возможных вариантов реализации научно-технической информации по теме исследования
- •1.1 Общая информация о способах проектирования систем sdm
- •1.2 Сравнительный анализ существующих решений
- •3 Общее описание проектируемого объекта
- •3.1 Этапы проектирования
- •3.1.1 Фиксирование регламентов
- •3.1.1.1 Способы приема заявок пользователей
- •3.1.1.3 Классификация обращений
- •3.1.1.4 «Главный регламент»
- •3.1.1.2 Приоритеты и временные регламенты
- •3.1.2 Обучение сотрудников
- •3.1.3 Организация call-центра
- •3.1.4 Разработка и внедрение Service Desk Manager
- •3.1.5 Поддержка работы системы
- •4 Реализация некоторых из возможных путей решения поставленной в техническом задании задачи
- •Эффект от внедрения процесса управления проблемами
- •Заключение
- •Список использованных источников
- •Приложение а Договор поставки оборудования № 26182012g1
- •1. Предмет договора
- •2. Обязательства сторон и условия поставки оборудования
- •3. Сумма договора и порядок расчетов.
- •4. Сертификация, упаковка,
- •5. Ответственность сторон
- •6. Форс-мажор
- •7. Разрешение споров. Арбитраж
- •8. Прочие условия
- •Адреса и банковские реквизиты сторон:
3.1.1.2 Приоритеты и временные регламенты
Здесь необходимо описать временные рамки и возможные приоритеты обращений пользователей. Например, обращение пользователя в связи с остановкой основного бизнес-приложения, от которого напрямую зависит прибыль компании, должно иметь высший приоритет. А обращению по вопросу сбоя в работе принтера у одного пользователя должен присваиваться низкий приоритет (если, конечно, этот пользователь – не генеральный директор). В зависимости от приоритетов обращений, необходимо указать время реакции. Например, время обработки инцидента с высоким приоритетом на первой линии поддержки не должно превышать 10 минут. Если проблему не удалось ликвидировать, она переводится на вторую линию поддержки, где на ее решение отводится два часа, после чего обращение переводится на третью линию поддержки. На третьей линии инцидент может решаться, например, пять часов. Если в течение и этого времени не удалось восстановить работоспособность, тогда проблема эскалируется на уровень ИТ-менеджера. Существуют более точные, но в то же время и более сложные варианты расчета времени работы над инцидентом.
Каждый сбой в ИТ-инфраструктуре влечет за собой остановку бизнес-процесса одного конкретного специалиста, и/или отдельного отдела, и/или целого предприятия. Следовательно, каждый сбой имеет различные степени влияния. Поломка принтера у одного человека влияет только на бизнес-процессы одного сотрудника предприятия, и то не на все. Если же принтер сетевой, то влияние сбоя усиливается, поскольку сбои в бизнес-процессах затрагивают нескольких сотрудников. Если же остановился сервер обмена сообщениями (например Exchange Server), то сбой, скорее всего, затрагивает большинство подразделений.
При определенном навыке оператор Service Desk может сразу определить степень влияния того или иного сбоя. Например, если принтер остановился в бухгалтерии, то приоритет может быть невысоким. Бухгалтерские отчеты можно распечатать и днем позже (если, конечно, бухгалтерия не печатает отчеты накануне их сдачи в налоговую инспекцию). А остановка принтера, допустим, в главной диспетчерской центрального склада влечет за собой остановку отгрузки товара и, как следствие, убытки для предприятия. Таким образом, имеются два параметра: степень влияния и приоритет обращения. Исходя из этих данных, можно более детально рассчитать сроки прохождения инцидента по линиям поддержки.
Задача на этапе составления документации – определить степени влияния и приоритеты и на их основе рассчитать время разрешения инцидента на первой, второй и третьей линиях поддержки.
3.1.1.3 Классификация обращений
Теория предлагает стандартную классификацию запросов: запрос на обслуживание, на изменение, на предоставление информации и т. д. Можно придумать свои классы или использовать только некоторые из известных. Вообще отказываться от классификации обращений не следует. В дальнейшем, при анализе обращений она сослужит добрую службу.
3.1.1.4 «Главный регламент»
Это не маршрутизация инцидентов и не перечень предоставляемой отчетности. «Главный регламент» – это мотивация ваших сотрудников. По опыту многих организаций и предприятий, которые развертывали службы Service Desk, можно однозначно утверждать: если не будет выстроена система материальной (и нематериальной) мотивации сотрудников, то служба Service Desk никогда не начнет работать эффективно. Необходимо уделить особое внимание этой части документа. Вот несколько рекомендаций, которые помогут в построении грамотной схемы мотивации.
Мотивация в большей степени должна быть построена на поощрении сотрудников, а не на наказании. Использовать штрафные санкции допустимо только в крайних случаях, например при нарушении сотрудником установленных регламентов.
Материальная мотивация должна быть ощутимой. 5% от оклада специалиста – это пародия на мотивацию.
Схема мотивации должна быть проста и понятна каждому сотруднику ИТ-департамента. Пять-шесть параметров, которые используются для расчета премий специалистов, можно считать пределом.
