ITIL: что это простыми словами

Кратко

ITIL (Information Technology Infrastructure Library) — библиотека лучших практик управления IT-услугами: как принимать обращения, различать поломку и просьбу, договариваться о сроках и фиксировать изменения. Это не программа, не закон и не стандарт, обязательный к исполнению, — а свод рекомендаций, которые каждая компания подгоняет под себя. Сертификат ITIL получает человек, а не компания, и его отсутствие не мешает применять сами практики.

Актуально на 23 сентября 2026 года.

Что такое ITIL на самом деле

ITIL появился как попытка описать словами то, что хорошо работающие IT-отделы и так делали интуитивно: разделять типы обращений, назначать ответственных, считать сроки, не терять историю изменений. Сейчас правообладатель библиотеки — компания PeopleCert (через бренд AXELOS), она же выдаёт персональные сертификаты по уровням (Foundation, Practitioner и выше). Это важно понимать сразу: сертифицируют людей, а не софт и не компании. Программа, которая называет себя «ITIL-совместимой», просто утверждает, что её логика не противоречит практикам библиотеки — формальной проверки для софта не существует.

Второе частое смешение — ITIL и ITSM. ITSM (IT Service Management, управление IT-услугами) — это общее название подхода «относиться к IT как к услуге со своими процессами», а ITIL — самая известная, но не единственная библиотека рекомендаций внутри этого подхода. Подробнее о том, чем ITSM-система как класс софта отличается от конкретной программы, — в статье Что такое ITSM и чем она отличается от ITIL.

Из чего состоит ITIL

Актуальная версия (ITIL 4) описывает работу через 34 «практики», но в повседневной работе службы поддержки на практике используются несколько ключевых:

ПрактикаЧто описываетПрактический вопрос, на который отвечает
Service DeskЕдиная точка приёма обращенийКуда клиент пишет и кто это видит первым
Управление инцидентамиВосстановление сломавшегося как можно быстрееЧто делать, когда что-то не работает
Управление проблемамиПоиск и устранение первопричины повторяющихся инцидентовПочему одно и то же ломается снова
Управление запросами на обслуживаниеОбработка стандартных просьб, а не поломокКак выдать доступ, завести почту, подключить сотрудника
Управление уровнем услугДоговорённость о сроках и их соблюдениеЗа сколько обязаны ответить и решить
Управление изменениямиКонтролируемое внесение изменений в системуКто разрешил это менять и почему это не сломало остальное
Управление знаниямиНакопление решений для повторного использованияПочему одну и ту же проблему каждый раз решают заново

Разницу между первой парой строк — инцидентом и запросом на обслуживание — стоит запомнить отдельно: это самая частая практическая ошибка внедрения. Инцидент — то, что сломалось и должно быть как раньше; запрос — то, чего раньше не было и что нужно завести. У них разные сроки и разная логика приоритета. Подробный разбор — в статье Инцидент или запрос на обслуживание: в чём разница.

Одна из практик ITIL, которая чаще всего нужна службе поддержки, — управление уровнем сервиса; что в неё входит, разобрано в статье Управление уровнем сервиса (SLM): что это в ITIL.

Как применить ITIL без покупки специальной платформы

ITIL не требует конкретного программного обеспечения — требует дисциплины в пяти шагах.

  1. Разделите инциденты и запросы на входе. Заведите два разных типа обращения или хотя бы обязательное поле «тип», которое сотрудник заполняет при приёме.
  2. Назначьте единый жизненный цикл обращения. Обращение обязано проходить понятные статусы от создания до закрытия, и переход между ними — не произвольный, а по правилам (кто может перевести заявку из статуса в статус и при каком условии).
  3. Договоритесь о сроках по приоритету. Не один срок на всё, а хотя бы два-три уровня: критично, обычно, не срочно — с отдельным временем первого ответа и временем решения для каждого.
  4. Фиксируйте, кто и что менял. Любое изменение статуса, приоритета или самого запроса должно оставлять след: кто, когда, что было — что стало. Без этого управление проблемами превращается в гадание по памяти сотрудников.
  5. Собирайте типовые решения в базу знаний. Повторяющийся инцидент, решённый один раз без записи решения, будет решаться заново каждый следующий раз тем же самым способом проб и ошибок.

Пример: быстрая самооценка зрелости процесса

Возьмите пять практик из таблицы выше (без управления изменениями и знаниями — они сложнее и обычно приходят вторым шагом) и поставьте себе от 0 до 2 баллов за каждую: 0 — нет вовсе, 1 — есть частично или неформально, 2 — работает системно и записано.

Практика0 баллов1 балл2 балла
Service DeskПишут кому попалоЕсть общий адрес/номерЕдиная очередь с историей
ИнцидентыКаждый решает как умеетЕсть статусы, но без сроковСтатусы + срок реакции и решения
Запросы на обслуживаниеСмешаны с инцидентамиПомечены, но без отдельного срокаОтдельный процесс и срок
Управление уровнем услугСрок не названСрок озвучен устноСрок зафиксирован и контролируется

Сумма 0–2 балла — процессов пока нет, начинайте с Service Desk. 3–5 — есть основа, дальше стоит разделить инциденты и запросы. 6–8 — можно переходить к управлению проблемами и изменениями. Это не официальная методика ITIL, а рабочий способ понять, с чего начать разговор с командой.

Частые заблуждения

«Работать по ITIL» не означает купить конкретный продукт. ITIL — это книга рекомендаций, а не лицензия. Купленная программа может как помогать применять эти практики, так и мешать, если она не позволяет разделить типы обращений или посчитать срок.

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

Полное соответствие ITIL не нужно почти никому. Из 34 практик реально используется, как правило, пять-семь. Пытаться внедрить всё сразу — частая причина, по которой внедрение ITIL останавливается на середине.

Как проверить, что вы уже что-то из этого используете

  • Найдите последнее обращение с пометкой «инцидент» или «поломка» и посмотрите, отличается ли срок его решения от обычной просьбы. Если нет — разделения на практике пока нет, только на словах.
  • Откройте любую заявку старше месяца и проверьте, видно ли, кто и когда менял её статус. Если это восстанавливается только по памяти сотрудника — управления инцидентами как процесса ещё нет, есть только переписка.
  • Спросите двух разных сотрудников, за сколько служба обязана ответить на срочное обращение. Разные ответы — признак того, что уровень услуги согласован не письменно, а «как договорились когда-то».

Частые вопросы

ITIL — это стандарт или методология?

Ни то, ни другое в строгом смысле. Это библиотека рекомендаций (best practices): она не сертифицирует компании и не имеет статуса обязательного стандарта вроде ISO. Организации выбирают из неё то, что подходит их масштабу.

Нужен ли сертификат ITIL, чтобы работать по этим практикам?

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

Чем ITIL отличается от service desk как инструмента?

ITIL описывает, как должен работать service desk (единая точка приёма, регистрация, маршрутизация). Service desk как инструмент — это конкретная программа, которая эту логику реализует. Одно без другого работает плохо: практика без инструмента упирается в таблицы и память, инструмент без практики — просто ещё один почтовый ящик с интерфейсом.

Обязательно ли внедрять ITIL целиком?

Нет, и почти никто так не делает. Штатная рекомендация — начинать с Service Desk и управления инцидентами, а управление проблемами, изменениями и знаниями добавлять по мере роста числа обращений и команды.

Чем ITIL отличается от системы управления инцидентами как программы?

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

Как это устроено в TehProf.kz Support

TehProf.kz Support не требует сертификата ITIL и не продаётся как «ITIL-платформа», но реализует техническую часть ключевых практик из таблицы выше. У заявки девять статусов, образующих конечный автомат с явными правилами перехода — от «Новой» до «Выполнена» или «Отменена», без произвольных прыжков между состояниями; подробности — в статье Статусы заявок. Каждой заявке назначается приоритет и правило SLA с отдельным сроком первого ответа и сроком решения, время считается по рабочим часам компании — это настраивается в разделе Настройка SLA, приоритетов и крайнего срока. Каждая смена статуса и любое действие с заявкой пишутся в append-only журнал аудита: ни одна роль, включая администратора, не может отредактировать или вручную удалить запись из интерфейса или API — это техническая основа для управления инцидентами и проблемами, когда нужно разобраться, что и когда происходило на самом деле. Хранится журнал не вечно: система автоматически удаляет записи старше срока, который зависит от тарифа (от 7 дней на бесплатном до 365 на «Бизнесе», без ограничения на «Энтерпрайзе»).

Связанные статьи

Нужна поддержка, которая так и работает?

TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.