Каталог IT-услуг: как составить и поддерживать в рабочем состоянии

Зачем нужен каталог услуг

Без каталога типичная ситуация выглядит так: пользователь пишет в IT по любому вопросу — от «не печатает принтер» до «нужно организовать видеоконференцию на 200 человек». Одни вопросы IT решает легко, другие — не её зона ответственности, третьи — требуют согласования с бизнесом. Каталог решает эту неопределённость:

• Границы ответственности — чётко зафиксировано, за какие услуги отвечает IT.
• Ожидания пользователей — каждый видит параметры SLA для "своей" услуги и понимает, чего ожидать.
• Корректная маршрутизация — заявка сразу попадает к нужной команде.
• Бизнес-ориентация — услуги описаны в терминах бизнеса, а не IT-инфраструктуры.
• Точка для SLA — SLA всегда привязан к услуге, не к абстрактному «техподдержка вообще».

Два взгляда: бизнес и техника

Классический ITIL-подход делит каталог на два уровня:

Business Service Catalog

Услуги в терминах бизнеса — как их видит пользователь. Например:

• «Электронная почта»
• «Корпоративная CRM»
• «Система электронного документооборота»
• «Удалённый доступ» (VPN)
• «Выдача рабочего места новому сотруднику»

Это то, что видят пользователи на портале самообслуживания. Они не обязаны знать, что "Электронная почта" внутри — это Exchange-серверы, DNS, MX-записи и антиспам-фильтр.

Technical Service Catalog

Описание технической стороны — какие компоненты стоят за бизнес-услугой. Видно только внутри IT. Пример «Электронной почты»:

• Exchange Server 2019 (2 узла, NLB)
• DNS-записи домена
• Анти-спам шлюз
• Архивное хранилище
• Мобильный доступ (ActiveSync)

Используется для incident management: если падает один из компонентов, ясно, какие бизнес-услуги затрагиваются.

Анатомия одной записи в каталоге

Минимальный набор полей на услугу:

1. Название — в терминах бизнеса, без аббревиатур.
2. Описание — 2–3 предложения, что это за услуга и зачем нужна.
3. Категория — для навигации (коммуникации / бизнес-приложения / рабочая станция / сеть / безопасность).
4. Владелец — команда или человек, отвечающий за услугу.
5. SLA реакции / решения — по приоритетам.
6. Часы доступности — 24×7 / 9–18 Пн–Пт / другое.
7. Как заказать — форма в портале или email.
8. Требуется ли согласование — если да, то от кого.
9. Кто может заказывать — доступно всем, или по группам.
10. Связанные услуги и оборудование — для диагностики инцидентов.
11. Статьи БЗ — как настроить, типовые вопросы.

Опционально: плановая стоимость (для внутренних "биллов" между подразделениями), дата последнего ревью, версия.

Типовые категории каталога

Универсального стандарта нет, но следующая структура покрывает большинство компаний:

Количество категорий — оптимально 6–10. Меньше — теряется навигация, больше — пользователи путаются.

SLA для каждой услуги отдельно

Главное правило: один SLA на всю компанию не работает. Электронная почта — критичная услуга с дедлайном 2–4 часа. Выдача канцелярии — 2 рабочих дня. Согласование в CAB — 1 неделя. Эти цифры не могут быть одинаковыми.

Типовая структура SLA на услугу:

• По каждому приоритету (критичный / высокий / средний / низкий) — отдельное время реакции и решения
• Часы доступности (не для всех услуг 24×7)
• Правила пауз (когда ожидание пользователя не засчитывается)
• Процент соответствия (например, 95% заявок должны укладываться)

Подробно методика расчёта — в статье о SLA в техподдержке.

Каталог и сервисные запросы

Для типовых услуг создаются шаблоны сервисных запросов. Вместо формы «опишите проблему» пользователь выбирает «Выдача доступа к 1С» и получает уже структурированную форму:

• Кому выдать доступ (поле из справочника сотрудников)
• Какие роли нужны (чекбоксы)
• Срочность (радио)
• Обоснование (опциональное поле)

Дальше заявка:

1. Автоматически идёт на согласование руководителю заявителя (если настроено)
2. После согласования — на команду 1С-администраторов
3. Выполняется, возможно частично автоматически (скрипт создания доступа)
4. Закрывается с уведомлением

Это один из самых ценных эффектов каталога: стандартизация ускоряет выполнение в 3–5 раз и снижает долю ошибок.

Владельцы услуг

Каждая услуга должна иметь назначенного Service Owner. Это не тот, кто её обслуживает (это команда), а тот, кто отвечает за услугу в целом:

• Целевые параметры (SLA, часы доступности)
• Архитектурные решения
• Бюджет на развитие и поддержку
• Коммуникация с бизнесом-заказчиком
• Эскалации и разбор крупных инцидентов

В небольших компаниях один человек может быть владельцем 5–10 услуг. В крупных — отдельные роли или даже команды.

Регулярный ревью

Каталог — живой документ. Без регулярного ревью он устаревает за 6–12 месяцев. Типовой цикл:

• Ежеквартально — краткая проверка: актуальны ли описания, SLA, владельцы, не появились ли новые сервисы
• Ежегодно — полный ревью с бизнесом: какие услуги реально используются, какие стоит убрать, какие добавить, пересмотр SLA
• По событию — при внедрении нового сервиса, организационных изменениях, смене владельца

Типовые ошибки

1. Каталог в Excel-файле. Не обновляется, не связан с заявками, не виден пользователям. Решение: каталог живёт в ITSM-системе и виден на портале.
2. Сотни услуг. IT-команда детально каталогизирует каждый нюанс — пользователь теряется. Решение: начать с 20–40 самых частых услуг, остальное добавлять по запросу.
3. Технический язык. "Предоставление ресурсов CI/CD-пайплайна" — пользователи-бухгалтеры не понимают. Решение: описания в терминах бизнеса, технические детали — во внутреннем каталоге.
4. Нет владельцев. Услуга в каталоге есть, отвечает "IT вообще". Конкретный вопрос переходит из рук в руки. Решение: явный Service Owner для каждой услуги.
5. SLA от фонаря. Скопированы из презентации, не привязаны к реальным возможностям. Команда не может их держать. Решение: SLA согласуются с командой-исполнителем и проверяются на исторических данных.

Как запустить с нуля

1. Собрать список того, что IT реально делает. Из истории заявок за последние 3 месяца выбрать 20–30 типов самых частых обращений — это и есть ваши услуги.
2. Объединить в категории. Группировка по здравому смыслу, не более 8–10 категорий.
3. Для каждой услуги заполнить базовые поля. Название, описание, владелец, SLA, порядок заказа.
4. Согласовать SLA с бизнесом. Предъявить список руководителям подразделений, зафиксировать целевые цифры.
5. Опубликовать на портале. Сделать видимым для пользователей, проинформировать о запуске.
6. Отслеживать использование. Через 1–3 месяца смотреть, какие услуги реально заказывают, корректировать каталог.

Вывод

Каталог услуг — фундамент для всего остального в ITSM. Без него невозможно корректно вести SLA, правильно маршрутизировать заявки и давать бизнесу ясную картину, за что отвечает IT.

Начинайте с 20–40 услуг в терминах бизнеса. Назначьте владельцев. Зафиксируйте SLA. Публикуйте на портале самообслуживания. Через 6 месяцев живой работы каталог вырастет и станет инструментом, которым пользуются все — от рядового сотрудника до CIO.