ITIL и Развитие Процессов

Хорошие практики ITIL начинаются с четкого определения процесса, пишет для ITSM Watch Майк Тайнтер из компании Форсайт.

В настоящее время внедрение лучших практик ITIL (IT Infrastructure Library) в индустрии ИТ интенсивно развивается. Информация, содержащаяся в книгах ITIL, полезна для любого отдела ИТ, который хочет улучшить качество своего сервиса, предоставляемого бизнесу. Между тем, внедрение ITIL становится представляющим проблему вызовом для многих отделов ИТ, причём не столько в интерпретации ITIL, сколько в ее применении.

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

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

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

В соответствии с моделью зрелости процессов CMM SEI (Carnegie Mellon Software Engineering Institute’s Capability Maturity Model for Software), хороший процесс – это тот, который соответствует следующим критериям (что справедливо также для определения зрелости процесса):

• Level 1: Должным образом определен

• Level 2: Повторяемый

• Level 3: Документированный

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

Для перехода на Уровень 5 (Оптимизированный), процесс должен быть обследован и одобрен внешними специалистами для подтверждения того, что он соответствует желаемым целям и для определения областей совершенствования. И все же, определяя зрелость процессов, модель СММ не описывает компоненты, присущие модели хорошего процесса.

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

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

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

• Четко определенные роли и ответственности для каждого сотрудника, который выполняет процедуры внутри процесса.

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

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

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

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

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

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

Каждый инцидент должен обрабатываться в соответствии с одним и тем же процессом, независимо от типа запроса и разбираемого инцидента.

Блок-схема, с другой стороны, описывает, как выполняются специфические типы инцидентов/запросов (например, смена пароля, прием новых сотрудников, создание учетной записи электронной почты, запросы на сетевые доступы и т.п.).

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

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

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

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

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

Лучшие практики, содержащиеся в ITIL, несомненно ценны для вашей организации; однако, к усилиям на разработку дизайна процесса должно привлекаться наибольшее внимание для достижения желаемого уровня зрелости. Путь начинается с эффективного ознакомления и планирования.

Mike Tainter, менеджер ITSM, сотрудник компании Форсайт, работает в управлении технологиями и крупномасштабными проектами более 20 лет. Его области компетенции — ITSM, ITIL, операционное управление, разработка процессов и систем поддержки IT операций, логистические требования к IT для широкого круга организаций, включая высоко-мобильные глобальные подразделения.

Mike Tainter, 10 ноября 2006. Перевод Виталия Фролова.
URL: http://www.itsmwatch.com/itil/article.php/3643271

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

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