ITIL

Что это значит

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

Изначально он появился в британской госслужбе, а сегодня это самая распространённая рамка для IT service management. Текущая версия ITIL 4 делает упор на ценность для клиента и связывает классические процессы с гибкими подходами и DevOps, а не требует строго следовать предписанным шагам.

ITIL - не стандарт и не программа. Это рамка, из которой организация выбирает то, что ей полезно. Сертифицироваться могут люди, а не компании; для сертификации организации служит стандарт ISO/IEC 20000, основанный на идеях ITIL.

Как это работает на практике

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

При внешнем ИТ-поставщике ITIL переносится в договор через SLA: время реакции, время решения по приоритетам, доступность сервисов и регулярная отчётность. Без таких определений трудно оценить, действительно ли работает аутсорсинг ИТ и за что компания платит.

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

На что обратить внимание

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

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