Оставить заявку на демо
Заполните форму, и мы свяжемся с вами в течение рабочего дня
ITIL: Стандарты управления ИТ-услугами
Добавлено 21.08.2025
Обновлено 08.07.2026
ITIL (Information Technology Infrastructure Library) — это собрание лучших практик управления IT-услугами, которое развивается уже почти 40 лет вместе с самой отраслью. За это время оно вобрало подходы, которые действительно доказали свою эффективность в компаниях разного масштаба.
Опираясь на международные стандарты и накопленный опыт, ITIL помогает выстраивать более понятные и предсказуемые сервисы и процессы. Но важно понимать: сами по себе стандарты ничего не «чинят». Все решает то, как они применяются в реальной работе.
В этой статье разберем ключевые практики ITIL, посмотрим, где они действительно дают эффект, и как их использовать так, чтобы ИТ-служба поддерживала бизнес, а не жила ради регламентов.
Опираясь на международные стандарты и накопленный опыт, ITIL помогает выстраивать более понятные и предсказуемые сервисы и процессы. Но важно понимать: сами по себе стандарты ничего не «чинят». Все решает то, как они применяются в реальной работе.
В этой статье разберем ключевые практики ITIL, посмотрим, где они действительно дают эффект, и как их использовать так, чтобы ИТ-служба поддерживала бизнес, а не жила ради регламентов.
Что такое ITSM и чем ITIL отличается от ITSM
Когда речь заходит об управлении IT-услугами, чаще всего путают два термина — ITSM и ITIL. И это нормально: звучат они похоже, но означают разные вещи.
ITSM (IT Service Management) — это подход к управлению ИТ через сервисы. Его суть заключается в том, что ИТ существует не ради серверов и систем, а ради услуг для бизнеса. Проще говоря, ИТ должно обеспечивать работу сотрудников и бизнес-процессов компании: предоставлять доступы, поддерживать рабочие станции, корпоративные системы и сервисы. Пользователю не важно, какие технологии находятся «под капотом». Ему важно, чтобы все работало быстро, стабильно и без лишней сложности.
ITIL — это уже набор лучших практик, который помогает этот подход реализовать.
Компания может работать в логике ITSM и вовсе не использовать ITIL как целостный фреймворк. Или, наоборот, применять только отдельные практики ITIL, которые подходят под ее задачи. На практике именно так происходит чаще всего.
ITSM (IT Service Management) — это подход к управлению ИТ через сервисы. Его суть заключается в том, что ИТ существует не ради серверов и систем, а ради услуг для бизнеса. Проще говоря, ИТ должно обеспечивать работу сотрудников и бизнес-процессов компании: предоставлять доступы, поддерживать рабочие станции, корпоративные системы и сервисы. Пользователю не важно, какие технологии находятся «под капотом». Ему важно, чтобы все работало быстро, стабильно и без лишней сложности.
ITIL — это уже набор лучших практик, который помогает этот подход реализовать.
Компания может работать в логике ITSM и вовсе не использовать ITIL как целостный фреймворк. Или, наоборот, применять только отдельные практики ITIL, которые подходят под ее задачи. На практике именно так происходит чаще всего.
Таблица 1. ITSM и ITIL: основные отличия
ITSM | ITIL |
Подход к управлению ИТ-услугами | Библиотека лучших практик управления ИТ-услугами |
Отвечает на вопрос «что нужно организовать» | Отвечает на вопрос «как это можно организовать» |
Описывает цели и принципы работы ИТ-сервисов | Предлагает рекомендации по построению процессов |
Может существовать без ITIL | Используется как инструмент для реализации ITSM |
Не привязан к конкретной методологии | Представляет собой конкретный свод практик и рекомендаций |
Ориентирован на ценность для бизнеса | Помогает эту ценность создавать через процессы и практики |
История развития ITIL
В начале 1980-х годов IT-индустрия росла быстрее, чем появлялись единые стандарты. Каждая компания выстраивала процессы по-своему, часто буквально с нуля, опираясь только на собственный опыт. Это приводило к хаосу: одинаковые задачи решались разными способами, а качество сервисов сильно различалось.
ITIL стал попыткой собрать накопленные практики в единую систему и превратить их в воспроизводимую модель управления ИТ-услугами.
Первая версия ITIL появилась в конце 1980-х годов и представляла собой довольно объемный набор материалов — около трех десятков книг, посвященных различным аспектам работы ИТ. Это была скорее энциклопедия подходов, чем удобный практический инструмент.
В начале 2000-х вышла вторая версия, в которой акцент сместился на упрощение. Основное внимание уделили ключевым процессам: управлению инцидентами, изменениями и поддержкой пользователей.
Третья версия, опубликованная в 2007 году, уже рассматривала ИТ через жизненный цикл услуг. В центре внимания оказались не отдельные процессы, а создание, развитие и сопровождение сервисов как единой системы.
Самой современной версией стал ITIL 4, представленный в 2019 году. В него интегрировали идеи Agile, DevOps и Lean, сделав основной акцент на гибкости, ценности для бизнеса и способности быстро адаптироваться к изменениям.
При этом общая цель ITIL на всех этапах развития оставалась неизменной — связать IT-процессы с задачами бизнеса. Например, если компания запускает новый продукт, IT должно заранее понимать, какие сервисы понадобятся, какие ресурсы потребуются и где находятся основные риски.
ITIL стал попыткой собрать накопленные практики в единую систему и превратить их в воспроизводимую модель управления ИТ-услугами.
Первая версия ITIL появилась в конце 1980-х годов и представляла собой довольно объемный набор материалов — около трех десятков книг, посвященных различным аспектам работы ИТ. Это была скорее энциклопедия подходов, чем удобный практический инструмент.
В начале 2000-х вышла вторая версия, в которой акцент сместился на упрощение. Основное внимание уделили ключевым процессам: управлению инцидентами, изменениями и поддержкой пользователей.
Третья версия, опубликованная в 2007 году, уже рассматривала ИТ через жизненный цикл услуг. В центре внимания оказались не отдельные процессы, а создание, развитие и сопровождение сервисов как единой системы.
Самой современной версией стал ITIL 4, представленный в 2019 году. В него интегрировали идеи Agile, DevOps и Lean, сделав основной акцент на гибкости, ценности для бизнеса и способности быстро адаптироваться к изменениям.
При этом общая цель ITIL на всех этапах развития оставалась неизменной — связать IT-процессы с задачами бизнеса. Например, если компания запускает новый продукт, IT должно заранее понимать, какие сервисы понадобятся, какие ресурсы потребуются и где находятся основные риски.
Основные принципы ITIL 4
Focus on Value: думайте о ценности, а не о процессах
Первый принцип ITIL кажется очевидным, но именно о нем чаще всего забывают на практике. Любой сервис нужно строить не ради соблюдения процесса, а ради пользы для бизнеса и пользователей.
Можно привести простую аналогию. Если человек хочет поесть, его можно отправить в грязный подвал, где ему молча поставят тарелку с едой. Формально задача выполнена — человек накормлен. А можно организовать нормальный ресторан с комфортной обстановкой, понятным сервисом и предсказуемым результатом.
В ИТ работает тот же принцип. Недостаточно просто выдать сотруднику компьютер. Важно, чтобы он получил его вовремя, без лишней бюрократии и понимал, что происходит на каждом этапе. Если сервис создает неудобства, значит, он не приносит той ценности, ради которой создавался.
Поэтому при проектировании услуг стоит задавать простой вопрос: будет ли пользователю удобно этим пользоваться? Если ответ отрицательный, процесс нужно пересматривать.
Можно привести простую аналогию. Если человек хочет поесть, его можно отправить в грязный подвал, где ему молча поставят тарелку с едой. Формально задача выполнена — человек накормлен. А можно организовать нормальный ресторан с комфортной обстановкой, понятным сервисом и предсказуемым результатом.
В ИТ работает тот же принцип. Недостаточно просто выдать сотруднику компьютер. Важно, чтобы он получил его вовремя, без лишней бюрократии и понимал, что происходит на каждом этапе. Если сервис создает неудобства, значит, он не приносит той ценности, ради которой создавался.
Поэтому при проектировании услуг стоит задавать простой вопрос: будет ли пользователю удобно этим пользоваться? Если ответ отрицательный, процесс нужно пересматривать.
Start Where You Are: начинайте с того, что уже есть
Когда компания решает улучшить ИТ-сервисы, первым желанием часто становится масштабная трансформация. Поменять систему, переписать процессы, внедрить новую платформу, перестроить организационную структуру.
На практике рекомендуется сначала разобраться, где вы находитесь сейчас. Провести аудит процессов, посмотреть на реальные показатели и понять, что уже работает хорошо, а что действительно требует изменений.
Нередко оказывается, что проблема вовсе не в инструменте. Например, компания годами жалуется на низкую скорость обработки заявок и готовится к дорогостоящей миграции на новую Service Desk-систему. Однако после анализа выясняется, что причина кроется в неравномерном распределении нагрузки между сотрудниками или неудачно настроенных маршрутах согласования.
Поэтому прежде чем что-то кардинально менять, стоит понять, какие улучшения можно получить небольшими корректировками. Иногда достаточно слегка доработать процесс, а не перестраивать всю систему с нуля.
На практике рекомендуется сначала разобраться, где вы находитесь сейчас. Провести аудит процессов, посмотреть на реальные показатели и понять, что уже работает хорошо, а что действительно требует изменений.
Нередко оказывается, что проблема вовсе не в инструменте. Например, компания годами жалуется на низкую скорость обработки заявок и готовится к дорогостоящей миграции на новую Service Desk-систему. Однако после анализа выясняется, что причина кроется в неравномерном распределении нагрузки между сотрудниками или неудачно настроенных маршрутах согласования.
Поэтому прежде чем что-то кардинально менять, стоит понять, какие улучшения можно получить небольшими корректировками. Иногда достаточно слегка доработать процесс, а не перестраивать всю систему с нуля.
Progress Iteratively with Feedback: развивайтесь постепенно и собирайте обратную связь
Любое улучшение должно сопровождаться обратной связью. Без нее очень легко оказаться в ситуации, когда ИТ-команда считает свой сервис образцовым, а пользователи думают совершенно иначе.
Например, в одной компании ИТ-команда была уверена, что все работает отлично: заявки закрываются, SLA выполняются, показатели находятся в норме. Но позже выяснилось, что сотрудники стараются лишний раз не обращаться в поддержку, потому что считают этот процесс неудобным и слишком сложным.
Именно поэтому важно постоянно получать обратную связь и использовать ее для улучшения сервисов. Это могут быть оценки после закрытия заявки, короткие опросы удовлетворенности или регулярные внутренние исследования.
Развивать сервисы лучше небольшими шагами. Внедрили изменение, получили обратную связь, оценили результат, скорректировали подход. Такой цикл обычно оказывается гораздо эффективнее масштабных реформ, которые запускают раз в несколько лет.
Например, в одной компании ИТ-команда была уверена, что все работает отлично: заявки закрываются, SLA выполняются, показатели находятся в норме. Но позже выяснилось, что сотрудники стараются лишний раз не обращаться в поддержку, потому что считают этот процесс неудобным и слишком сложным.
Именно поэтому важно постоянно получать обратную связь и использовать ее для улучшения сервисов. Это могут быть оценки после закрытия заявки, короткие опросы удовлетворенности или регулярные внутренние исследования.
Развивать сервисы лучше небольшими шагами. Внедрили изменение, получили обратную связь, оценили результат, скорректировали подход. Такой цикл обычно оказывается гораздо эффективнее масштабных реформ, которые запускают раз в несколько лет.
Collaborate and Promote Visibility: взаимодействуйте и обеспечивайте прозрачность
Невозможно построить качественный сервис, если ИТ существует отдельно от бизнеса.
Чтобы понимать реальные потребности пользователей, необходимо постоянно взаимодействовать с людьми: общаться с сотрудниками, руководителями подразделений, участвовать в обсуждении изменений и разбираться в том, как устроены бизнес-процессы.
Не менее важна прозрачность. Пользователи гораздо спокойнее относятся даже к проблемам, если понимают, что происходит и когда можно ожидать результат. Поэтому хороший сервис — это не только техническая работа, но и постоянное информирование всех участников процесса.
Чтобы понимать реальные потребности пользователей, необходимо постоянно взаимодействовать с людьми: общаться с сотрудниками, руководителями подразделений, участвовать в обсуждении изменений и разбираться в том, как устроены бизнес-процессы.
Не менее важна прозрачность. Пользователи гораздо спокойнее относятся даже к проблемам, если понимают, что происходит и когда можно ожидать результат. Поэтому хороший сервис — это не только техническая работа, но и постоянное информирование всех участников процесса.
Think and Work Holistically: смотрите на ситуацию целиком
Одна из самых распространенных ошибок — рассматривать изменения изолированно.
Любая система существует не сама по себе. Она связана с другими сервисами, процессами, командами и пользователями. Поэтому любое изменение необходимо оценивать комплексно.
Допустим, компания внедряет новый корпоративный сервис. На первый взгляд кажется, что достаточно установить программное обеспечение и настроить доступы. Но на практике сразу возникают дополнительные вопросы. Кто будет обучать пользователей? Как изменятся существующие процессы? Какие интеграции придется дорабатывать? Как внедрение повлияет на другие системы?
То же самое касается любых инфраструктурных изменений. Если мы меняем что-то в одном месте, необходимо заранее понимать, какие последствия это вызовет в других частях ИТ-ландшафта.
Комплексный взгляд помогает избежать ситуации, когда локальное улучшение одной системы создает проблемы сразу для нескольких других сервисов.
Любая система существует не сама по себе. Она связана с другими сервисами, процессами, командами и пользователями. Поэтому любое изменение необходимо оценивать комплексно.
Допустим, компания внедряет новый корпоративный сервис. На первый взгляд кажется, что достаточно установить программное обеспечение и настроить доступы. Но на практике сразу возникают дополнительные вопросы. Кто будет обучать пользователей? Как изменятся существующие процессы? Какие интеграции придется дорабатывать? Как внедрение повлияет на другие системы?
То же самое касается любых инфраструктурных изменений. Если мы меняем что-то в одном месте, необходимо заранее понимать, какие последствия это вызовет в других частях ИТ-ландшафта.
Комплексный взгляд помогает избежать ситуации, когда локальное улучшение одной системы создает проблемы сразу для нескольких других сервисов.
Keep It Simple and Practical: не усложняйте то, что можно сделать проще
Очень часто красивые процессы существуют только на схемах и презентациях.
В реальной жизни пользователи всегда выбирают самый удобный путь. Поэтому при проектировании сервисов рекомендуется исходить не из того, как процесс выглядит на бумаге, а из того, как люди будут пользоваться им в действительности.
Есть простая аналогия. Если люди постоянно срезают угол, не стоит прокладывать дорожку в форме буквы «Г». Они все равно будут ходить по диагонали. Не потому, что нарушают правила, а потому, что так удобнее.
В ИТ происходит то же самое. Если для простой операции сотруднику приходится проходить пять экранов согласований и заполнять десяток полей, он найдет обходной путь. Напишет знакомому администратору напрямую, отправит сообщение в мессенджере или вовсе перестанет пользоваться сервисом.
Чем проще и понятнее процесс для пользователя, тем выше вероятность, что он действительно будет работать так, как задумывалось.
В реальной жизни пользователи всегда выбирают самый удобный путь. Поэтому при проектировании сервисов рекомендуется исходить не из того, как процесс выглядит на бумаге, а из того, как люди будут пользоваться им в действительности.
Есть простая аналогия. Если люди постоянно срезают угол, не стоит прокладывать дорожку в форме буквы «Г». Они все равно будут ходить по диагонали. Не потому, что нарушают правила, а потому, что так удобнее.
В ИТ происходит то же самое. Если для простой операции сотруднику приходится проходить пять экранов согласований и заполнять десяток полей, он найдет обходной путь. Напишет знакомому администратору напрямую, отправит сообщение в мессенджере или вовсе перестанет пользоваться сервисом.
Чем проще и понятнее процесс для пользователя, тем выше вероятность, что он действительно будет работать так, как задумывалось.
Optimize and Automate: оптимизируйте и автоматизируйте
Если действие выполняется регулярно и по понятным правилам, стоит задуматься об автоматизации. Ручные операции замедляют процессы, увеличивают нагрузку на сотрудников и повышают вероятность ошибок.
Например, при оформлении нового сотрудника можно автоматически создавать учетные записи, выдавать необходимые доступы, запускать подготовку оборудования и уведомлять ответственных специалистов. Если делать все это вручную, каждая операция будет занимать больше времени и потребует участия нескольких сотрудников.
Другой пример — автоматическая маршрутизация заявок. Вместо того чтобы диспетчер вручную распределял обращения между специалистами, система может делать это самостоятельно по заранее заданным правилам.
При этом автоматизация не должна становиться самоцелью. Сначала необходимо оптимизировать процесс, избавиться от лишних действий, а уже потом автоматизировать то, что действительно имеет смысл автоматизировать.
Иначе можно очень эффективно автоматизировать плохо работающий процесс.
Например, при оформлении нового сотрудника можно автоматически создавать учетные записи, выдавать необходимые доступы, запускать подготовку оборудования и уведомлять ответственных специалистов. Если делать все это вручную, каждая операция будет занимать больше времени и потребует участия нескольких сотрудников.
Другой пример — автоматическая маршрутизация заявок. Вместо того чтобы диспетчер вручную распределял обращения между специалистами, система может делать это самостоятельно по заранее заданным правилам.
При этом автоматизация не должна становиться самоцелью. Сначала необходимо оптимизировать процесс, избавиться от лишних действий, а уже потом автоматизировать то, что действительно имеет смысл автоматизировать.
Иначе можно очень эффективно автоматизировать плохо работающий процесс.
Основные процессы и практики ITIL
Incident Management: управление инцидентами
Управление инцидентами отвечает за максимально быстрое восстановление работы сервиса после сбоя.
Под инцидентом понимается любое событие, которое нарушает нормальную работу услуги или ухудшает ее качество. Например, сотрудник не может войти в корпоративную систему, перестала работать почта, пропал доступ к сети или возникли проблемы с бизнес-приложением.
Задача этой практики заключается не в том, чтобы сразу найти первопричину произошедшего. Главная цель — как можно быстрее вернуть сервис в рабочее состояние и минимизировать влияние сбоя на бизнес.
Представим ситуацию: перестала работать система электронного документооборота. Пока специалисты разбираются в причинах, сотрудникам можно предоставить временный способ работы или переключить систему на резервный контур. Бизнес продолжит работать, а команда поддержки получит время для детального расследования.
Именно поэтому управление инцидентами часто называют первой линией защиты бизнеса от простоев.
Под инцидентом понимается любое событие, которое нарушает нормальную работу услуги или ухудшает ее качество. Например, сотрудник не может войти в корпоративную систему, перестала работать почта, пропал доступ к сети или возникли проблемы с бизнес-приложением.
Задача этой практики заключается не в том, чтобы сразу найти первопричину произошедшего. Главная цель — как можно быстрее вернуть сервис в рабочее состояние и минимизировать влияние сбоя на бизнес.
Представим ситуацию: перестала работать система электронного документооборота. Пока специалисты разбираются в причинах, сотрудникам можно предоставить временный способ работы или переключить систему на резервный контур. Бизнес продолжит работать, а команда поддержки получит время для детального расследования.
Именно поэтому управление инцидентами часто называют первой линией защиты бизнеса от простоев.
Problem Management: управление проблемами
Если управление инцидентами отвечает на вопрос «как быстро восстановить работу?», то управление проблемами отвечает на другой вопрос — «почему это произошло?».
Проблема — это первопричина одного или нескольких инцидентов. Пока она не устранена, сбой может повторяться снова и снова.
Например, сотрудники регулярно жалуются на недоступность корпоративного портала. Каждый раз служба поддержки восстанавливает работу сервиса, но через несколько дней ситуация повторяется. В рамках управления проблемами специалисты начинают искать корневую причину и обнаруживают, что серверу не хватает ресурсов из-за ошибки в настройках.
После устранения причины исчезают и сами инциденты.
На практике многие компании хорошо умеют тушить пожары, но редко находят время на полноценный поиск первопричин. В результате одни и те же сбои повторяются месяцами. Именно поэтому управление проблемами считается одной из самых недооцененных практик ITIL.
Проблема — это первопричина одного или нескольких инцидентов. Пока она не устранена, сбой может повторяться снова и снова.
Например, сотрудники регулярно жалуются на недоступность корпоративного портала. Каждый раз служба поддержки восстанавливает работу сервиса, но через несколько дней ситуация повторяется. В рамках управления проблемами специалисты начинают искать корневую причину и обнаруживают, что серверу не хватает ресурсов из-за ошибки в настройках.
После устранения причины исчезают и сами инциденты.
На практике многие компании хорошо умеют тушить пожары, но редко находят время на полноценный поиск первопричин. В результате одни и те же сбои повторяются месяцами. Именно поэтому управление проблемами считается одной из самых недооцененных практик ITIL.
Change Management: управление изменениями
Любая ИТ-среда постоянно меняется. Устанавливаются обновления, внедряются новые системы, изменяются настройки инфраструктуры, появляются новые интеграции.
Каждое такое изменение связано с определенным риском. Даже небольшая настройка может неожиданно повлиять на работу критически важных сервисов.
Управление изменениями помогает внедрять изменения контролируемо и предсказуемо.
Перед выполнением изменений оцениваются возможные риски, влияние на бизнес, необходимые ресурсы и план действий на случай неудачи. Только после этого принимается решение о внедрении.
Хороший пример — обновление корпоративной ERP-системы. Если установить обновление без предварительной оценки последствий, можно столкнуться с остановкой ключевых бизнес-процессов. При использовании практик управления изменениями команда заранее анализирует риски, тестирует обновление, согласовывает работы и готовит план отката.
В результате изменения становятся не источником новых проблем, а инструментом развития ИТ-сервисов.
Каждое такое изменение связано с определенным риском. Даже небольшая настройка может неожиданно повлиять на работу критически важных сервисов.
Управление изменениями помогает внедрять изменения контролируемо и предсказуемо.
Перед выполнением изменений оцениваются возможные риски, влияние на бизнес, необходимые ресурсы и план действий на случай неудачи. Только после этого принимается решение о внедрении.
Хороший пример — обновление корпоративной ERP-системы. Если установить обновление без предварительной оценки последствий, можно столкнуться с остановкой ключевых бизнес-процессов. При использовании практик управления изменениями команда заранее анализирует риски, тестирует обновление, согласовывает работы и готовит план отката.
В результате изменения становятся не источником новых проблем, а инструментом развития ИТ-сервисов.
Service Request Management: управление запросами на обслуживание
Управление запросами на обслуживание (Service Request Management) отвечает за обработку стандартных, повторяющихся обращений пользователей в ИТ-службу. В отличие от инцидентов, такие запросы не связаны со сбоями или нарушением работы сервисов. Это заранее понятные и типовые операции.
Например, сотруднику понадобилась новая мышь, гарнитура или ноутбук. Или ему требуется доступ к информационной системе, назначение роли, изменение прав или установка программного обеспечения. Все это относится к запросам на обслуживание.
Задача этой практики – сделать обработку подобных обращений предсказуемой и максимально простой. Пользователь должен понимать, как оформить запрос, сколько времени займет его выполнение и какой результат он получит.
По сути, речь идет не о реакции на проблему, а о предоставлении стандартных ИТ-услуг по понятным и заранее определенным правилам.
Например, сотруднику понадобилась новая мышь, гарнитура или ноутбук. Или ему требуется доступ к информационной системе, назначение роли, изменение прав или установка программного обеспечения. Все это относится к запросам на обслуживание.
Задача этой практики – сделать обработку подобных обращений предсказуемой и максимально простой. Пользователь должен понимать, как оформить запрос, сколько времени займет его выполнение и какой результат он получит.
По сути, речь идет не о реакции на проблему, а о предоставлении стандартных ИТ-услуг по понятным и заранее определенным правилам.
Service Level Management: управление уровнем услуг
Если Service Request Management отвечает за выполнение стандартных запросов, то Service Level Management определяет, каким должен быть уровень предоставляемых услуг. Главная задача этой практики — договориться с бизнесом о том, какого качества сервис компания действительно ожидает от ИТ и какие обязательства ИТ-служба готова взять на себя.
Проще говоря, здесь появляется ответ на вопрос: с какой скоростью и на каком уровне качества ИТ обязуется предоставлять услуги и выполняются ли эти обязательства на практике.
Хороший пример — выдача оборудования новым сотрудникам. Бизнес может ожидать, что ноутбук будет готов сразу после оформления заявки. Однако И Т оценивает реальные ограничения: наличие техники, загрузку специалистов, стоимость ускоренной подготовки. В результате стороны договариваются о реалистичных сроках. В одной компании нормой становится выдача оборудования в течение рабочего дня, в другой — в течение трех дней, а для критически важных сотрудников может действовать отдельный регламент.
Именно так формируется SLA — соглашение об уровне услуг. В нем фиксируются ключевые показатели: сроки выполнения запросов, время реакции, приоритеты различных категорий обращений и допустимые отклонения.
После этого начинается постоянный контроль. Если из ста заявок только половина выполняется в рамках SLA, это сигнал для анализа. Причины могут быть разными: недостаток ресурсов, неэффективные процессы или технологические ограничения.
В зависимости от результатов принимаются соответствующие решения. Если проблема заключается в технологии — модернизируется инфраструктура. Если причина в процессах — они оптимизируются. Если не хватает специалистов — пересматривается распределение ресурсов или расширяется команда.
При этом важно заранее определить допустимый уровень отклонений. Практически ни один сервис не работает со стопроцентным соблюдением SLA, поэтому бизнес и IT должны заранее согласовать, какой уровень выполнения считается приемлемым.
По сути, Service Level Management представляет собой непрерывный цикл: договорились о показателях, зафиксировали их, измерили результат, проанализировали отклонения и внесли необходимые изменения.
Проще говоря, здесь появляется ответ на вопрос: с какой скоростью и на каком уровне качества ИТ обязуется предоставлять услуги и выполняются ли эти обязательства на практике.
Хороший пример — выдача оборудования новым сотрудникам. Бизнес может ожидать, что ноутбук будет готов сразу после оформления заявки. Однако И Т оценивает реальные ограничения: наличие техники, загрузку специалистов, стоимость ускоренной подготовки. В результате стороны договариваются о реалистичных сроках. В одной компании нормой становится выдача оборудования в течение рабочего дня, в другой — в течение трех дней, а для критически важных сотрудников может действовать отдельный регламент.
Именно так формируется SLA — соглашение об уровне услуг. В нем фиксируются ключевые показатели: сроки выполнения запросов, время реакции, приоритеты различных категорий обращений и допустимые отклонения.
После этого начинается постоянный контроль. Если из ста заявок только половина выполняется в рамках SLA, это сигнал для анализа. Причины могут быть разными: недостаток ресурсов, неэффективные процессы или технологические ограничения.
В зависимости от результатов принимаются соответствующие решения. Если проблема заключается в технологии — модернизируется инфраструктура. Если причина в процессах — они оптимизируются. Если не хватает специалистов — пересматривается распределение ресурсов или расширяется команда.
При этом важно заранее определить допустимый уровень отклонений. Практически ни один сервис не работает со стопроцентным соблюдением SLA, поэтому бизнес и IT должны заранее согласовать, какой уровень выполнения считается приемлемым.
По сути, Service Level Management представляет собой непрерывный цикл: договорились о показателях, зафиксировали их, измерили результат, проанализировали отклонения и внесли необходимые изменения.
Service Configuration Management: управление конфигурацией сервисов
Если Service Level Management отвечает за договоренности о качестве услуг, то Service Configuration Management позволяет понимать, как устроена сама ИТ-инфраструктура и как связаны между собой ее элементы.
В основе этой практики лежат конфигурационные единицы (Configuration Items, CI) — любые значимые компоненты инфраструктуры: серверы, приложения, сетевое оборудование, сервисы, учетные записи и другие объекты.
Представим сервер авторизации, через который сотрудники получают доступ к корпоративным системам. Он связан с почтовыми сервисами, внутренними приложениями, системой 1С и другими ресурсами.
Именно понимание этих зависимостей и является главной ценностью практики. Если перестает работать сервер авторизации, важно понимать не только сам факт сбоя, но и какие сервисы окажутся недоступны вслед за ним.
Для этого используется CMDB — база данных конфигурационных единиц, где фиксируются элементы инфраструктуры и связи между ними. В идеале она содержит не только логическую модель сервисов, но и сведения о физических IT-активах.
Тогда при возникновении проблемы можно быстро определить не только источник сбоя, но и оценить его влияние на остальные сервисы.
Показательный пример — переговорная комната. Она состоит из экрана, камеры, микрофонов, системы видеоконференций и другого оборудования. Если выходит из строя один из ключевых компонентов, фактически перестает работать вся переговорная. Если эти зависимости отражены в CMDB, влияние такого сбоя становится очевидным сразу.
Таким образом, Service Configuration Management позволяет рассматривать ИТ не как набор отдельных компонентов, а как единую взаимосвязанную систему. Это помогает точнее оценивать последствия инцидентов, безопаснее внедрять изменения и снижать риск неожиданных отказов.
В основе этой практики лежат конфигурационные единицы (Configuration Items, CI) — любые значимые компоненты инфраструктуры: серверы, приложения, сетевое оборудование, сервисы, учетные записи и другие объекты.
Представим сервер авторизации, через который сотрудники получают доступ к корпоративным системам. Он связан с почтовыми сервисами, внутренними приложениями, системой 1С и другими ресурсами.
Именно понимание этих зависимостей и является главной ценностью практики. Если перестает работать сервер авторизации, важно понимать не только сам факт сбоя, но и какие сервисы окажутся недоступны вслед за ним.
Для этого используется CMDB — база данных конфигурационных единиц, где фиксируются элементы инфраструктуры и связи между ними. В идеале она содержит не только логическую модель сервисов, но и сведения о физических IT-активах.
Тогда при возникновении проблемы можно быстро определить не только источник сбоя, но и оценить его влияние на остальные сервисы.
Показательный пример — переговорная комната. Она состоит из экрана, камеры, микрофонов, системы видеоконференций и другого оборудования. Если выходит из строя один из ключевых компонентов, фактически перестает работать вся переговорная. Если эти зависимости отражены в CMDB, влияние такого сбоя становится очевидным сразу.
Таким образом, Service Configuration Management позволяет рассматривать ИТ не как набор отдельных компонентов, а как единую взаимосвязанную систему. Это помогает точнее оценивать последствия инцидентов, безопаснее внедрять изменения и снижать риск неожиданных отказов.
Asset Management: управление IT-активами
Практика управления активами отвечает за учет и контроль всех ресурсов, используемых для предоставления ИТ-услуг.
Под активами понимаются не только компьютеры и серверы. Это также лицензии на программное обеспечение, сетевое оборудование, мобильные устройства, облачные ресурсы и любые другие объекты, представляющие ценность для компании.
Представим организацию, в которой работают несколько тысяч сотрудников. Без системы управления активами очень быстро возникает хаос. Становится сложно понять, сколько ноутбуков закуплено, какие лицензии используются, какое оборудование требует замены и за что компания продолжает платить, хотя этим уже никто не пользуется.
Кроме того, управление активами помогает принимать более обоснованные решения о закупках и инвестициях. Когда ИТ-служба видит полную картину использования ресурсов, она может избежать лишних расходов и эффективнее планировать бюджет.
По сути, Asset Management позволяет ответить на простой вопрос: какими ресурсами располагает компания и насколько эффективно они используются.
Под активами понимаются не только компьютеры и серверы. Это также лицензии на программное обеспечение, сетевое оборудование, мобильные устройства, облачные ресурсы и любые другие объекты, представляющие ценность для компании.
Представим организацию, в которой работают несколько тысяч сотрудников. Без системы управления активами очень быстро возникает хаос. Становится сложно понять, сколько ноутбуков закуплено, какие лицензии используются, какое оборудование требует замены и за что компания продолжает платить, хотя этим уже никто не пользуется.
Кроме того, управление активами помогает принимать более обоснованные решения о закупках и инвестициях. Когда ИТ-служба видит полную картину использования ресурсов, она может избежать лишних расходов и эффективнее планировать бюджет.
По сути, Asset Management позволяет ответить на простой вопрос: какими ресурсами располагает компания и насколько эффективно они используются.
Что такое Service Desk
Service Desk в ITIL — это единая точка входа пользователей в ИТ-службу и центральный узел взаимодействия между бизнесом и ИТ.
Его основная задача — принимать обращения пользователей, выполнять их первичную обработку, классификацию и маршрутизацию. Через Service Desk проходят инциденты, сервисные запросы, консультации пользователей, а в более зрелых организациях — и другие процессы, например отдельные изменения или элементы управления конфигурациями.
При этом важно понимать, что ITIL не является жесткой системой. Это набор практик, которые каждая организация адаптирует под собственные задачи.
Поэтому Service Desk может работать по-разному. В одной компании он ограничивается обработкой инцидентов и запросов на обслуживание. В другой становится полноценным центром управления сервисами, объединяющим сразу несколько практик ITIL.
Если говорить о его функциях, можно выделить три основные.
Во-первых, прием обращений через единый канал — портал самообслуживания, электронную почту, телефон или другие средства коммуникации.
Во-вторых, первичная классификация обращений и их распределение между соответствующими командами.
В-третьих, контроль выполнения заявок и постоянное взаимодействие с пользователем до полного решения вопроса.
Поэтому Service Desk — это гораздо больше, чем обычная служба поддержки. Он связывает пользователей с внутренними ИТ-процессами компании и обеспечивает управляемую работу всех сервисных практик.
Его основная задача — принимать обращения пользователей, выполнять их первичную обработку, классификацию и маршрутизацию. Через Service Desk проходят инциденты, сервисные запросы, консультации пользователей, а в более зрелых организациях — и другие процессы, например отдельные изменения или элементы управления конфигурациями.
При этом важно понимать, что ITIL не является жесткой системой. Это набор практик, которые каждая организация адаптирует под собственные задачи.
Поэтому Service Desk может работать по-разному. В одной компании он ограничивается обработкой инцидентов и запросов на обслуживание. В другой становится полноценным центром управления сервисами, объединяющим сразу несколько практик ITIL.
Если говорить о его функциях, можно выделить три основные.
Во-первых, прием обращений через единый канал — портал самообслуживания, электронную почту, телефон или другие средства коммуникации.
Во-вторых, первичная классификация обращений и их распределение между соответствующими командами.
В-третьих, контроль выполнения заявок и постоянное взаимодействие с пользователем до полного решения вопроса.
Поэтому Service Desk — это гораздо больше, чем обычная служба поддержки. Он связывает пользователей с внутренними ИТ-процессами компании и обеспечивает управляемую работу всех сервисных практик.
KPI и метрики ITIL
Response Time: время реакции
Этот показатель отражает, насколько быстро обращение принимается в работу после регистрации. По сути, измеряется время от создания заявки до ее назначения специалисту или группе, которая будет заниматься ее обработкой.
Для пользователя важно понимать, что его запрос замечен и работа по нему уже началась. Поэтому скорость реакции напрямую влияет на восприятие качества сервиса.
Для пользователя важно понимать, что его запрос замечен и работа по нему уже началась. Поэтому скорость реакции напрямую влияет на восприятие качества сервиса.
Resolution Time: время решения
Если Response Time показывает, насколько быстро специалисты приступили к работе, то Resolution Time отвечает на главный вопрос пользователя: когда его обращение будет полностью разрешено (устранен инцидент с какой-то системой или предоставлен доступ).
Это одна из ключевых метрик сервисной поддержки. Пользователю не так важно, через сколько минут обращение приняли в работу. Гораздо важнее понимать, когда он сможет вернуться к нормальной работе.
Именно поэтому при оценке SLA особое внимание уделяется времени полного решения обращения.
Это одна из ключевых метрик сервисной поддержки. Пользователю не так важно, через сколько минут обращение приняли в работу. Гораздо важнее понимать, когда он сможет вернуться к нормальной работе.
Именно поэтому при оценке SLA особое внимание уделяется времени полного решения обращения.
SLA Compliance: соблюдение SLA
В TIKITRIK мы используем разные показатели, но для оценки соблюдения SLA ключевыми остаются две метрики: время реакции и время решения.
Если оба показателя укладываются в согласованные нормативы, SLA считается выполненным. Остальные метрики помогают глубже анализировать качество сервиса, но сами по себе не определяют факт соблюдения соглашения.
Если оба показателя укладываются в согласованные нормативы, SLA считается выполненным. Остальные метрики помогают глубже анализировать качество сервиса, но сами по себе не определяют факт соблюдения соглашения.
MTTR: среднее время восстановления
MTTR (Mean Time To Restore) показывает, сколько времени в среднем требуется для восстановления работоспособности сервиса после сбоя.
Если Resolution Time чаще используют для оценки отдельных пользовательских обращений, то MTTR применяется при анализе работы инфраструктуры, серверов и критически важных корпоративных систем.
Например, если произошел сбой почтового сервера или системы электронного документооборота, именно MTTR показывает, насколько быстро команда смогла вернуть сервис в рабочее состояние.
Чем ниже этот показатель, тем устойчивее и надежнее работает ИТ-служба.
Если Resolution Time чаще используют для оценки отдельных пользовательских обращений, то MTTR применяется при анализе работы инфраструктуры, серверов и критически важных корпоративных систем.
Например, если произошел сбой почтового сервера или системы электронного документооборота, именно MTTR показывает, насколько быстро команда смогла вернуть сервис в рабочее состояние.
Чем ниже этот показатель, тем устойчивее и надежнее работает ИТ-служба.
Customer Satisfaction Score (CSAT)
Ни одна техническая метрика не дает полной картины без обратной связи от пользователей.
Для этого используется Customer Satisfaction Score (CSAT) — показатель удовлетворенности сервисом. Иногда встречается и другое название — Customer Satisfaction Index (CSI).
Обычно после выполнения заявки пользователю предлагают оценить качество обслуживания или оставить комментарий о своем опыте взаимодействия с поддержкой.
Такая обратная связь позволяет увидеть сервис глазами пользователей и выявить проблемы, которые невозможно обнаружить только с помощью отчетов и технических показателей.
Для этого используется Customer Satisfaction Score (CSAT) — показатель удовлетворенности сервисом. Иногда встречается и другое название — Customer Satisfaction Index (CSI).
Обычно после выполнения заявки пользователю предлагают оценить качество обслуживания или оставить комментарий о своем опыте взаимодействия с поддержкой.
Такая обратная связь позволяет увидеть сервис глазами пользователей и выявить проблемы, которые невозможно обнаружить только с помощью отчетов и технических показателей.
Ticket Backlog: объем незакрытых обращений
Ticket Backlog показывает количество активных заявок на определенный момент времени. Например, можно анализировать число открытых обращений на начало недели, месяца или квартала.
Рост бэклога обычно свидетельствует о нехватке ресурсов, увеличении нагрузки или проблемах в организации процессов. Поэтому эта метрика помогает оценивать текущее состояние сервисной поддержки и планировать нагрузку на команду.
Рост бэклога обычно свидетельствует о нехватке ресурсов, увеличении нагрузки или проблемах в организации процессов. Поэтому эта метрика помогает оценивать текущее состояние сервисной поддержки и планировать нагрузку на команду.
First Contact Resolution (FCR)
Эта метрика показывает долю обращений, которые удалось решить при первом контакте с пользователем.
В TIKITRIK для нее используется собственное название — ROC (Resolved on Call).
Суть показателя проста: пользователь обратился в поддержку и получил решение сразу во время общения. Обращение не потребовало, дополнительной обработки, маршрутизации, переписки и т. п.
Высокий показатель ROC говорит о хорошей подготовке специалистов поддержки и напрямую влияет на удовлетворенность пользователей. Люди ценят ситуации, когда проблему удается решить сразу, а не превращать ее в длинную цепочку согласований и ожиданий. При этом в ряде случаев высокий показатель говорит, что есть пространство для автоматизации.
Несмотря на большое количество доступных метрик, не стоит забывать, зачем они существуют. KPI нужны не для красивых отчетов, а для понимания реального качества сервиса. Поэтому в первую очередь рекомендуется контролировать скорость реакции и скорость решения обращений. Остальные показатели помогают разобраться в причинах возникающих проблем и определить направления для дальнейшего развития сервисов.
В TIKITRIK для нее используется собственное название — ROC (Resolved on Call).
Суть показателя проста: пользователь обратился в поддержку и получил решение сразу во время общения. Обращение не потребовало, дополнительной обработки, маршрутизации, переписки и т. п.
Высокий показатель ROC говорит о хорошей подготовке специалистов поддержки и напрямую влияет на удовлетворенность пользователей. Люди ценят ситуации, когда проблему удается решить сразу, а не превращать ее в длинную цепочку согласований и ожиданий. При этом в ряде случаев высокий показатель говорит, что есть пространство для автоматизации.
Несмотря на большое количество доступных метрик, не стоит забывать, зачем они существуют. KPI нужны не для красивых отчетов, а для понимания реального качества сервиса. Поэтому в первую очередь рекомендуется контролировать скорость реакции и скорость решения обращений. Остальные показатели помогают разобраться в причинах возникающих проблем и определить направления для дальнейшего развития сервисов.
Ошибки внедрения ITIL
«На мой взгляд, самая распространенная ошибка при внедрении ITIL заключается в самой формулировке: «Давайте внедрим ITIL». ITIL — это набор лучших практик и рекомендаций, а не универсальный рецепт, одинаково подходящий любой компании.
Часто организации пытаются копировать процессы коллег или конкурентов по принципу: «У них работает — значит, подойдет и нам». Но то, что эффективно в одной компании, может оказаться совершенно бесполезным в другой. Все зависит от людей, корпоративной культуры, масштаба бизнеса и конкретных задач.
Я всегда придерживаюсь простого принципа: внедрять нужно только то, что действительно работает на практике. Процесс должен поддерживать бизнес, а не существовать ради самого процесса.
Есть компании, где большинство решений принимается без сложных согласований, потому что сотрудникам доверяют. Есть организации, где практически каждое действие проходит несколько уровней утверждения. Какой подход правильный? Тот, который помогает конкретному бизнесу.
Хороший пример — дорожка в парке. Можно проложить красивый маршрут буквой «Г», но если люди постоянно ходят по диагонали, значит, именно этот путь для них наиболее удобен. Бороться с этим бессмысленно. Гораздо правильнее сначала посмотреть, как люди действительно действуют, а уже потом строить процесс вокруг реальной практики с учетом контроля рисков.
Поэтому я бы сформулировал главный принцип так: внедряйте работающие практики, а процессы выстраивайте вокруг них, а не наоборот».
Часто организации пытаются копировать процессы коллег или конкурентов по принципу: «У них работает — значит, подойдет и нам». Но то, что эффективно в одной компании, может оказаться совершенно бесполезным в другой. Все зависит от людей, корпоративной культуры, масштаба бизнеса и конкретных задач.
Я всегда придерживаюсь простого принципа: внедрять нужно только то, что действительно работает на практике. Процесс должен поддерживать бизнес, а не существовать ради самого процесса.
Есть компании, где большинство решений принимается без сложных согласований, потому что сотрудникам доверяют. Есть организации, где практически каждое действие проходит несколько уровней утверждения. Какой подход правильный? Тот, который помогает конкретному бизнесу.
Хороший пример — дорожка в парке. Можно проложить красивый маршрут буквой «Г», но если люди постоянно ходят по диагонали, значит, именно этот путь для них наиболее удобен. Бороться с этим бессмысленно. Гораздо правильнее сначала посмотреть, как люди действительно действуют, а уже потом строить процесс вокруг реальной практики с учетом контроля рисков.
Поэтому я бы сформулировал главный принцип так: внедряйте работающие практики, а процессы выстраивайте вокруг них, а не наоборот».
Артем Хижний
Генеральный директор РИКИТЛАБ
Попытка внедрить все процессы сразу
Одна из самых распространенных ошибок — желание внедрить весь ITIL одновременно.
На практике такой подход почти всегда приводит к перегрузке команды и разочарованию в самой методологии. Начинать стоит с базовых практик, без которых невозможно обеспечить стабильную работу IT-службы. В первую очередь это управление инцидентами и сервисными запросами.
При этом важно помнить, что далеко не всегда процесс приходится создавать с нуля. Во многих компаниях он уже существует и успешно работает, просто никто не называет его практикой ITIL.
Нередко оказывается, что команда много лет эффективно обрабатывает обращения пользователей, фактически используя подходы, описанные в ITIL, даже не задумываясь об этом.
Поэтому сначала стоит разобраться, что уже работает хорошо, и только потом принимать решение, какие практики действительно требуют развития.
На практике такой подход почти всегда приводит к перегрузке команды и разочарованию в самой методологии. Начинать стоит с базовых практик, без которых невозможно обеспечить стабильную работу IT-службы. В первую очередь это управление инцидентами и сервисными запросами.
При этом важно помнить, что далеко не всегда процесс приходится создавать с нуля. Во многих компаниях он уже существует и успешно работает, просто никто не называет его практикой ITIL.
Нередко оказывается, что команда много лет эффективно обрабатывает обращения пользователей, фактически используя подходы, описанные в ITIL, даже не задумываясь об этом.
Поэтому сначала стоит разобраться, что уже работает хорошо, и только потом принимать решение, какие практики действительно требуют развития.
Отсутствие KPI и согласованных целей
Если нет понятной цели, невозможно оценить, насколько успешно работает процесс.
Предположим, ИТ-служба закрывает 99% инцидентов в установленный срок. На первый взгляд это отличный показатель. Но если оставшийся один процент приводит к остановке производства и многомиллионным потерям, назвать такой результат успешным уже сложно.
Бывает и обратная ситуация. Для некоторых сервисов бизнес сознательно соглашается на более низкий уровень KPI, потому что дальнейшее повышение качества потребует несоразмерных затрат.
Поэтому показатели эффективности должны определяться совместно бизнесом и IT, а не одной только IT-службой. Только в этом случае появляется общее понимание того, какой результат считается хорошим, а какой требует улучшений.
Кроме того, без KPI практически невозможно объективно обосновать необходимость дополнительных ресурсов, расширения команды или изменения существующих процессов.
Предположим, ИТ-служба закрывает 99% инцидентов в установленный срок. На первый взгляд это отличный показатель. Но если оставшийся один процент приводит к остановке производства и многомиллионным потерям, назвать такой результат успешным уже сложно.
Бывает и обратная ситуация. Для некоторых сервисов бизнес сознательно соглашается на более низкий уровень KPI, потому что дальнейшее повышение качества потребует несоразмерных затрат.
Поэтому показатели эффективности должны определяться совместно бизнесом и IT, а не одной только IT-службой. Только в этом случае появляется общее понимание того, какой результат считается хорошим, а какой требует улучшений.
Кроме того, без KPI практически невозможно объективно обосновать необходимость дополнительных ресурсов, расширения команды или изменения существующих процессов.
Отсутствие владельцев процессов
Если за процесс никто не отвечает, значит им никто не управляет.
В такой ситуации изменения вносятся хаотично, решения принимаются ситуативно, а возникающие проблемы остаются без внимания. Со временем процесс начинает деградировать.
У каждого процесса должен быть владелец — сотрудник, который понимает, как он устроен, какие риски существуют, какие изменения допустимы и к каким последствиям они могут привести.
Это похоже на оборудование общего пользования, за которое никто не отвечает. Рано или поздно что-то выйдет из строя, а выяснять, кто должен заниматься ремонтом, будет уже поздно.
В такой ситуации изменения вносятся хаотично, решения принимаются ситуативно, а возникающие проблемы остаются без внимания. Со временем процесс начинает деградировать.
У каждого процесса должен быть владелец — сотрудник, который понимает, как он устроен, какие риски существуют, какие изменения допустимы и к каким последствиям они могут привести.
Это похоже на оборудование общего пользования, за которое никто не отвечает. Рано или поздно что-то выйдет из строя, а выяснять, кто должен заниматься ремонтом, будет уже поздно.
Отсутствие обучения и понимания процессов
Сотрудникам необязательно становиться экспертами по ITIL. Но они должны понимать, что именно от них требуется, как устроен процесс и почему он работает именно так.
Проблемы начинаются тогда, когда новые правила внедряются без объяснений. Люди не понимают, зачем нужны изменения, какие задачи они решают и как пользоваться новыми инструментами.
Особенно часто это происходит при внедрении сложных систем. Если для выполнения базовых операций сотруднику приходится проходить длительное обучение или постоянно обращаться к инструкциям, значит, процесс получился слишком сложным.
Хорошее обучение — это не набор теоретических курсов, а уверенность сотрудников в том, что они понимают, что, как и зачем нужно делать.
Проблемы начинаются тогда, когда новые правила внедряются без объяснений. Люди не понимают, зачем нужны изменения, какие задачи они решают и как пользоваться новыми инструментами.
Особенно часто это происходит при внедрении сложных систем. Если для выполнения базовых операций сотруднику приходится проходить длительное обучение или постоянно обращаться к инструкциям, значит, процесс получился слишком сложным.
Хорошее обучение — это не набор теоретических курсов, а уверенность сотрудников в том, что они понимают, что, как и зачем нужно делать.
Избыточная бюрократия
Иногда компании настолько увлекаются описанием процессов, что создают многостраничные регламенты и сложные блок-схемы, которыми никто не пользуется.
Проблема в том, что люди почти всегда выбирают самый удобный способ работы. То же самое происходит и с процессами. Если сотрудники постоянно ищут обходные пути, проблема чаще всего не в людях, а в самом процессе.
Поэтому процессы стоит строить вокруг реальной практики, а не наоборот. Сначала посмотреть, как люди действительно работают, а уже потом формализовать этот опыт в понятные и удобные правила.
Проблема в том, что люди почти всегда выбирают самый удобный способ работы. То же самое происходит и с процессами. Если сотрудники постоянно ищут обходные пути, проблема чаще всего не в людях, а в самом процессе.
Поэтому процессы стоит строить вокруг реальной практики, а не наоборот. Сначала посмотреть, как люди действительно работают, а уже потом формализовать этот опыт в понятные и удобные правила.
Преимущества внедрения ITIL
Главное преимущество такого подхода заключается в том, что компания начинает воспринимать ИТ не как набор разрозненных технических задач, а как сервис для бизнеса.
Это уже совсем другой уровень зрелости. Речь идет не просто о специалисте, который чинит компьютеры, устанавливает программы и выдает оборудование. ИТ становится полноценной сервисной функцией с понятными правилами работы, прозрачными ожиданиями и измеримым результатом.
Пока компания небольшая, модель «есть Вася, который все знает» обычно работает. Но по мере роста бизнеса становится непонятно, чем именно занимается этот Вася, сколько таких специалистов необходимо компании и насколько эффективно они работают.
Практики ITIL делают ИТ-процессы прозрачнее, управляемее и масштабируемее. Бизнес начинает понимать, сколько ресурсов тратится на поддержку, какие услуги получает взамен и какую ценность они создают.
В результате ИТ перестает быть «черным ящиком», который просто потребляет бюджет, и становится полноценной сервисной функцией, эффективность которой можно оценивать и развивать.
Это уже совсем другой уровень зрелости. Речь идет не просто о специалисте, который чинит компьютеры, устанавливает программы и выдает оборудование. ИТ становится полноценной сервисной функцией с понятными правилами работы, прозрачными ожиданиями и измеримым результатом.
Пока компания небольшая, модель «есть Вася, который все знает» обычно работает. Но по мере роста бизнеса становится непонятно, чем именно занимается этот Вася, сколько таких специалистов необходимо компании и насколько эффективно они работают.
Практики ITIL делают ИТ-процессы прозрачнее, управляемее и масштабируемее. Бизнес начинает понимать, сколько ресурсов тратится на поддержку, какие услуги получает взамен и какую ценность они создают.
В результате ИТ перестает быть «черным ящиком», который просто потребляет бюджет, и становится полноценной сервисной функцией, эффективность которой можно оценивать и развивать.
Недостатки и ограничения ITIL
Главное ограничение ITIL заключается в том, что это не инструкция из серии «сделай раз, сделай два, сделай три — и все заработает».
По сути, ITIL представляет собой набор рекомендаций и лучших практик, сформированных на основе опыта множества компаний. Но это именно рекомендации, а не универсальный рецепт.
Поэтому его главный недостаток одновременно является и особенностью: каждую практику все равно придется адаптировать под конкретную компанию, ее процессы, культуру и задачи.
Слепое следование рекомендациям редко приводит к хорошему результату. Более того, если пытаться внедрить все, что описано в ITIL, без учета реальных потребностей бизнеса, процессы могут стать сложнее, а пользы от них не прибавится.
Поэтому, работая с ITIL, всегда важно понимать, какую задачу вы пытаетесь решить. Это не готовое решение, а набор инструментов. Какие из них использовать и как именно применять — каждая организация определяет самостоятельно.
По сути, ITIL представляет собой набор рекомендаций и лучших практик, сформированных на основе опыта множества компаний. Но это именно рекомендации, а не универсальный рецепт.
Поэтому его главный недостаток одновременно является и особенностью: каждую практику все равно придется адаптировать под конкретную компанию, ее процессы, культуру и задачи.
Слепое следование рекомендациям редко приводит к хорошему результату. Более того, если пытаться внедрить все, что описано в ITIL, без учета реальных потребностей бизнеса, процессы могут стать сложнее, а пользы от них не прибавится.
Поэтому, работая с ITIL, всегда важно понимать, какую задачу вы пытаетесь решить. Это не готовое решение, а набор инструментов. Какие из них использовать и как именно применять — каждая организация определяет самостоятельно.
ITIL и современные методологии
Lean — это философия постоянных улучшений, устранения потерь и повышения эффективности процессов. Она хорошо сочетается с ITSM и во многом перекликается с принципами ITIL, особенно когда речь идет об оптимизации и автоматизации.
DevOps — это подход к разработке и поставке изменений, который помогает быстрее и безопаснее выпускать новые версии продуктов и сервисов. Многие его практики органично сочетаются с современным ITSM.
Agile — это проектный и продуктовый подход, ориентированный на гибкость и быстрые итерации. Однако подходит он далеко не всегда. Есть отрасли, где требования к безопасности, контролю и предсказуемости настолько высоки, что использовать Agile в чистом виде невозможно.
Если посмотреть на развитие ITIL, то в последних версиях в него постепенно интегрировали идеи Agile, Lean, DevOps и других современных подходов. В результате ITIL превратился в достаточно гибкий набор практик, который можно адаптировать под разные задачи.
DevOps — это подход к разработке и поставке изменений, который помогает быстрее и безопаснее выпускать новые версии продуктов и сервисов. Многие его практики органично сочетаются с современным ITSM.
Agile — это проектный и продуктовый подход, ориентированный на гибкость и быстрые итерации. Однако подходит он далеко не всегда. Есть отрасли, где требования к безопасности, контролю и предсказуемости настолько высоки, что использовать Agile в чистом виде невозможно.
Если посмотреть на развитие ITIL, то в последних версиях в него постепенно интегрировали идеи Agile, Lean, DevOps и других современных подходов. В результате ITIL превратился в достаточно гибкий набор практик, который можно адаптировать под разные задачи.
«Но здесь есть и обратная сторона. Чем больше инструментов появляется в методологии, тем выше риск сделать систему излишне сложной. Поэтому я всегда рекомендую исходить не из того, что написано в методологии, а из здравого смысла и реальных потребностей бизнеса.
Любая практика ценна ровно до того момента, пока помогает решать конкретную задачу. Если она начинает существовать сама по себе, ее ценность быстро становится сомнительной».
Любая практика ценна ровно до того момента, пока помогает решать конкретную задачу. Если она начинает существовать сама по себе, ее ценность быстро становится сомнительной».
Артем Хижний
Генеральный директор РИКИТЛАБ
FAQ
Что такое ITIL простыми словами?
ITIL — это библиотека лучших практик управления ИТ-услугами. Она помогает организовать работу ИТ-службы так, чтобы она не просто поддерживала инфраструктуру, а предоставляла качественные сервисы для бизнеса.
Для чего нужен ITIL?
ITIL помогает сделать работу ИТ более предсказуемой и управляемой. Он позволяет быстрее решать инциденты, эффективнее внедрять изменения, контролировать качество сервисов и выстраивать понятное взаимодействие между ИТ и бизнесом.
Чем ITIL отличается от ITSM?
ITSM — это подход к управлению ИТ-услугами, который определяет, как должна работать сервисная модель. ITIL — это набор практик, который помогает реализовать этот подход на практике. Проще говоря, ITSM отвечает на вопрос «что нужно построить», а ITIL — «как это сделать».
Какие процессы включает ITIL?
В ITIL десятки практик, но чаще всего компании используют управление инцидентами (Incident Management), проблемами (Problem Management), изменениями (Change Management), запросами на обслуживание (Service Request Management), уровнем услуг (Service Level Management), конфигурациями (Service Configuration Management) и ИТактивами (Asset Management).
Что такое Service Desk?
Service Desk — это единая точка взаимодействия пользователей с ИТ-службой. Через него сотрудники сообщают об инцидентах, оформляют сервисные запросы, получают консультации и отслеживают выполнение своих обращений.
Что такое Incident Management?
Incident Management — это практика, которая отвечает за максимально быстрое восстановление работы сервиса после сбоя. Ее главная цель — минимизировать влияние инцидента на работу бизнеса.
Что такое Change Management?
Change Management помогает безопасно внедрять изменения в ИТ-инфраструктуре. Перед выполнением работ оцениваются риски, влияние на бизнес, готовится план внедрения.
Что такое CMDB?
CMDB (Configuration Management Database) — это база данных конфигурационных единиц. В ней хранится информация о серверах, приложениях, сервисах, оборудовании и связях между ними. Благодаря этому можно быстро понять, какие системы затронет тот или иной сбой или изменение.
Что такое Service Value System?
Service Value System (SVS) — это модель ITIL 4, которая показывает, как различные компоненты управления сервисами работают вместе для создания ценности для бизнеса. В нее входят руководящие принципы, практики, управление, постоянное совершенствование и цепочка создания ценности сервисов (Service Value Chain).
Какие преимущества дает ITIL?
Практики ITIL делают работу ИТ-службы более прозрачной, управляемой и масштабируемой. Они помогают повысить качество сервисов, сократить количество повторяющихся сбоев, улучшить взаимодействие с бизнесом и принимать решения на основе объективных показателей.
Какие сложности возникают при внедрении?
Самые распространенные ошибки — попытка внедрить все практики сразу, избыточная бюрократия, отсутствие владельцев процессов, KPI и обучения сотрудников. Важно помнить, что внедрять нужно не ITIL целиком, а только те практики, которые действительно помогают решать задачи бизнеса.
Подходит ли ITIL малому бизнесу?
Да. Малому бизнесу необязательно внедрять весь набор практик. Обычно достаточно начать с управления инцидентами, сервисными запросами и изменениями, постепенно развивая процессы по мере роста компании.
Какие сертификаты существуют по ITIL?
Современная система сертификации построена вокруг ITIL 4. Базовым уровнем является ITIL 4 Foundation. Далее доступны специализированные направления Managing Professional (MP), Strategic Leader (SL), Practice Manager (PM), а высшим уровнем считается ITIL Master для специалистов с большим практическим опытом.
Заключение
ITIL давно перестал быть просто набором процессов или формальной методологией. Сегодня это гибкий набор практик, который помогает выстраивать управление ИТ-услугами вокруг потребностей бизнеса.
При этом не стоит воспринимать ITIL как готовую инструкцию. Универсального сценария внедрения не существует: каждая организация выбирает только те практики, которые действительно помогают решать ее задачи.
Именно поэтому успешное внедрение начинается не с желания «внедрить ITIL», а с понимания того, какие проблемы бизнеса необходимо решить. Если процессы делают сервис удобнее для пользователей, помогают быстрее устранять сбои, безопаснее внедрять изменения и принимать решения на основе данных, значит они работают правильно — независимо от того, насколько строго компания следует рекомендациям методологии.
При этом не стоит воспринимать ITIL как готовую инструкцию. Универсального сценария внедрения не существует: каждая организация выбирает только те практики, которые действительно помогают решать ее задачи.
Именно поэтому успешное внедрение начинается не с желания «внедрить ITIL», а с понимания того, какие проблемы бизнеса необходимо решить. Если процессы делают сервис удобнее для пользователей, помогают быстрее устранять сбои, безопаснее внедрять изменения и принимать решения на основе данных, значит они работают правильно — независимо от того, насколько строго компания следует рекомендациям методологии.