Как организовать поддержку в ИТ – это вопрос, с которым сталкиваются почти все организации, вне зависимости от того, являются они внутренним поставщиком услуг или внешним. Да, это задача не из легких.
Сводить поддержку только к деятельности структурного подразделения под названием Сервис деск было бы недостаточно. В зависимости от требований заказчиков, ИТ-поддержка оказывается в разных форматах, которые и определяют цену услуги. Одним достаточно удаленной технической поддержки и консультаций, другим необходим постоянный контроль, участие специалистов в работе инфраструктуры.
Что входит в ИТ-поддержку
Спектр деятельности по ИТ поддержке довольно широк. Это:
- Администрирование серверов, компьютерной сети, телефонии
- Апгрейд ПО и модернизация оборудования
- Масштабирование инфраструктуры под изменяющиеся потребности бизнеса
- Развертывание, настройка нового оборудования
- Ликвидация последствий вирусных атак и мероприятия по корпоративной безопасности
- Ремонт оборудования, работа сисадмина для устранения неполадок и других задач
- Консультации пользователей по техническим вопросам
- Обслуживание автоматизированных рабочих мест и пользовательских компьютеров
- Аудит и анализ текущей ситуации
Это всегда последовательность работ, требующая знаний, навыков, распределения ответственности, технической оснащенности, участия третьих сторон.
Как обеспечить способность решать все вышеописанные задачи? Как выстроить управление этой деятельностью? Этому и посвящен наш авторский курс “VAP: Управление поддержкой ИТ-услуг”.
Об особенностях VAP’ов мы уже писали. Хочу уточнить еще один момент. На курсе мы подробно разбираем практики, задействованные в поддержке. Кроме управления инцидентами, управления запросами на обслуживание, мониторинга и управления событиями и практики Сервис деск, мы добавили практику управления проблемами.
Лучший способ понять суть практик ITIL – рассмотреть их назначение и факторы успеха.
Формулировки назначений
Практика |
Формулировка назначения |
Управление инцидентами |
Минимизировать негативное влияние инцидентов за счёт скорейшего восстановления нормальной работы услуги |
Управление запросами на обслуживание |
Поддерживать согласованное качество услуги, выполняя все предопределённые инициируемые пользователями запросы, эффективным и удобным для пользователей способом |
Мониторинг и управление событиями |
Систематическое наблюдение за услугами и их компонентами, запись и отчётность об изменениях, идентифицированных как события |
Сервис деск |
Обрабатывать спрос на решение инцидентов и выполнять запросы на обслуживание. Также Сервис деск является единой точкой входа и точкой контакта поставщика услуг со всеми пользователями |
Управление проблемами |
Уменьшение вероятности и влияния инцидентов путём идентификации фактических и потенциальных причин возникновения инцидентов, управления обходными решениями и известными ошибками |
Вместе эти практики гарантируют, что организация:
- быстро восстанавливает услуги при сбоях (управление инцидентами)
- эффективно обрабатывает запросы, связанные с обслуживанием (управление запросами на обслуживание)
- управляет услугами и сервисными компонентами, зная их состояние (мониторинг и управление событиями)
- обеспечивает каналы коммуникации для вышеупомянутых и всех других связанных с сервисом коммуникаций (service desk)
- выявляет и анализирует ошибки в продуктах с целью минимизации их негативного влияния на предоставляемые услуги (управление проблемами)
Управление инцидентами и управление запросами на обслуживание — это классические практики ITIL; ранее они были одним процессом, но затем были разделены.
Практика Сервис деск — это недавно введенная практика. Предыдущие версии ITIL включали Сервис деск, но назначение новой практики Сервис деск ограничивается обеспечением коммуникаций. Основное назначение практики service desk является создание эффективного коммуникационного интерфейса между поставщиком услуг и его пользователями, при этом инциденты и запросы на обслуживание являются лишь двумя субъектами коммуникации.
Управление инцидентами
Практика управления инцидентами гарантирует, что периоды незапланированной недоступности или ухудшения качества услуг будут сведены к минимуму. Этому способствуют два основных фактора: раннее обнаружение инцидентов и быстрое восстановление нормальной работы.
Хотя проактивное обнаружение инцидентов не всегда возможно. Чем раньше об инциденте будет сообщено и произведена регистрация, тем лучше.
Зачем нужна классификация? Очень часто этот шаг в жизненном цикле инцидента недооценивается. Постараемся повысить градус в обсуждении этого вопроса и разобраться с необходимостью, важностью правильной категоризации.
Приоритизация – это тема для отдельного обсуждения. Привычные нам уровень влияния и срочность больше не являются основанием для определения приоритета.
А вы используете повышение приоритета, как инструмент управления? С этим могут быть неприятные сюрпризы. Какие подводные камни ожидают менеджера в управлении инцидентами и как их избежать – мы разберем на нашем учебном курсе.
Прерывания и деградация услуг обычно демонстрируют некоторые закономерности, на основании которых их можно типизировать. Для типичных инцидентов поставщики услуг могут определить модели инцидентов. Они стандартизируют выполняемую работу, чтобы оптимизировать обработку и разрешение повторяющихся или похожих инцидентов.
Управление запросами на обслуживание
Предсказуемость является одной из основных характеристик запросов на обслуживание. В отличие от инцидентов, запросы на обслуживание являются “обычной” частью предоставления услуг, поэтому их “результаты и сроки хорошо понятны заказчику, пользователям и операционным командам поставщика услуг и обычно предсказуемы”.
В отличие от моделей инцидентов, модели запросов на обслуживание обычно создаются во время проектирования продукта и услуги. Причем практика управления запросами на обслуживание участвует на всех этапах, тестируется и внедряется в эксплуатацию вместе с другими сервисными компонентами. Постоянное совершенствование продуктов и услуг может включать улучшение связанных с ними моделей сервисных запросов.
Каталог запросов и каталог услуг – еще одна тема для обсуждения. Каталог услуг — это то, что сервис-провайдер предоставляет заказчикам. А каталог запросов — это то, что может запросить пользователь. Это не одно и то же, даже если пользователь = заказчик (хотя часто это не так). Уверен, что с разницей в этих понятиях точно стоит разобраться! Особенно, если вы занимаетесь управлением услугами и поддержкой.
Мониторинг и управление событиями
Обнаружение инцидентов обеспечивается практикой мониторинга и управления событиями. Она включает инструменты и процессы для категоризации событий, которые отличают инциденты от информационных событий и предупреждений.
Что выбрать: активный или пассивный, проактивный или реактивный мониторинг? Какая между ними разница?
Не все события одинаково важны или требуют одинакового ответа. Критерии будут определять категорию событий. Фильтрация, корреляция событий, настройка автоответа, адресное уведомление специалистов – требует тщательного анализа. При правильной настройке, мониторинг и управление событиями поможет автоматизации управления услугами и работе поддержки.
В чем может быть потенциальная опасность для мониторинга и управления событиями и что поможет избежать такой опасности.
Без мониторинга и управления событиями невозможно обеспечить качественное предоставление услуг и совершенствование.
Сервис Деск
Кроме рассмотрения самой практики Сервис деск, на курсе мы разбираем организацию работы функции (команды) Сервис деск. Как организовать подготовку персонала к самостоятельному дежурству? Что необходимо учитывать при составлении сменного графика работы? Сколько необходимо людей на первую линии поддержки (расчет и обоснование). Контроль качества и ключевые метрики для оценки работы Сервис деска. Какие есть зависимости и как выбрать правильные KPI. Это далеко не полный список обсуждаемых вопросов и выполняемых упражнений на курсе.
Управление проблемами
Нет идеальных услуг. Каждая услуга имеет ошибки или недостатки, которые могут привести к инцидентам. Ошибки могут возникать в любом из четырех аспектов управления услугами. Для управления ошибками, возникшими в продуктовой среде, организации разработали практику управления проблемами.
Далеко не у всех есть формализованная практика управления проблемами, но это не значит, что деятельность по расследованию первопричин инцидентов не ведется. Самое интересное, что ценность этой деятельности зачастую не очевидна для бизнеса и выделять на нее ресурсы организации не торопятся. Но ведь, если разобраться, управление проблемами может помочь в:
- снижении затрат и усилий при “пожаротушении” (экстренных решений INC) или при разрешении повторяющихся инцидентов
- сокращении затрат на обходные решения или исправления, которые не работают
- обеспечении более высокой доступности ИТ-услуг за счет уменьшения количества и продолжительности инцидентов, которые могут возникнуть у этих услуг
- повышении производительности ИТ-персонала за счет сокращения незапланированного труда, вызванного инцидентами
Правильно организовать управление проблемами – это целое искусство, ведь методик выявления корневых причин инцидентов довольно много. Каждому случаю свой метод! Да и при нынешней сложности ИТ-ландшафта очень часто причина может быть не одна.
Что лучше: проативное управление проблемами или реактивное? А если проблемами мы не управляем? Как управление рисками поможет нам в решении этих задач? Как выстроить работу менеджеру по управлению проблемами? И если временных рамок (SLA) в управлении проблемами нет, то это еще вовсе не значит, что мы не должны устанавливать точки для контроля времени в этой деятельности. Где их расставить, на что это повлияет – эти вопросы имеют давно аргументированные ответы.
Заключение
Как вы видите, управление поддержкой – важный аспект деятельности любого ИТ подразделения. Правильно выстроить работу, оптимизировать ее с течением времени помогут знания, полученные на нашем авторском курсе. Нам есть чем с вами поделиться. Консалтинговый опыт нашей компании это позволяет. А еще неплохим бонусом будет подробное знакомство с руководствами по практикам из ITIL4, участвующим в поддержке.
Знаний много не бывает. Возможно, что кто-то захочет в дальнейшем подтвердить этот тезис, пройдя сертификацию.