«Правила безопасности» для сервисной поддержки на базе ITIL

Внедряя ITIL, необходимо правильно заложить ее основы, пишет обозреватель ITSM Watch Майкл Тайнтер [Michael Tainter] из компании Форсайт.

Сервис-менеджмент ИТ (ITSM), основанный на ITIL, приобрел популярность за последние несколько лет и стал практическим стандартом для ИТ. ITSM — очень эффективная дисциплина, так как ее внедрение оказывает большое влияние на организацию.

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

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

    Отвечая на эти вопросы, следует принять во внимание следующие моменты:

  • Все ли ваши ИТ процессы оптимизированы для доставки этих IT сервисов;
  • Достаточно ли эффективно управляют в вашей ИТ организации процессами, используемыми для доставки ИТ сервисов?

    Большинство организаций правильно начинают внедрение ITIL c совершенствования своих процессов поддержки- Incident, Problem, Change, Configuration and Release Management. Данные процессы необходимо развивать, поднимая уровень зрелости ИТ организации. С этой целью приводим здесь несколько «правил безопасности»:

    Развитие процессов

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

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

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

    Организация

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

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

    Технология

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

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

    Управление инцидентами

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

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

    Упростите категории инцидентов, коды влияний/приоритетов и исполнения: наличие слишком большого количества категорий для инцидентов является причиной неправильной идентификации и классификации инцидентов.

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

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

    Открывайте и закрывайте запросы в сервис деске: Эта лучшая практика обеспечивает закрытие инцидентов одинаковым образом и пользователи получают уведомление об исполнении.

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

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

    Управление проблемами

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

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

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

    Управление Изменениями/Релизами

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

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

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

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

    Управление конфигурациями

    Объедините с процессом управления изменениями: чтобы поддерживать постоянное обновление конфигурационных единиц, введите обновление базы данных (CMDB) в структуру каждого изменения. Менеджер по конфигурациям должен изменять конфигурационные единицы, когда утвержденное изменение проведено.

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

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

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

    =====================================

    Michael Tainter is Forsythe’s ITSM practice manager. He has been managing technology and large scale projects for more than 20 years. His expertise encompasses IT service management, ITIL, operations management, process design, IT operations support system development, and IT logistical requirements for a wide variety of organizations including highly-mobile global organizations.

    Michael Tainter, 1 февраля 2007. Перевод Виталия Фролова
    URL: http://www.itsmwatch.com/itil/article.php/3657446

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.