В небольшой компании IT часто описано через устройства: сервер, роутер, Wi-Fi, компьютеры, принтеры, камеры. Для инженера это полезно, но бизнес работает не устройствами, а сервисами: почта, файлы, 1С, интернет, удаленный доступ, печать, видеонаблюдение, телефония, обмен с клиентами, рабочие места сотрудников.
Каталог IT-сервисов переводит инфраструктуру на язык работы компании. Он показывает, что именно поддерживается, кто пользуется сервисом, насколько он важен, куда обращаться, какие есть границы ответственности и как проверить, что проблема решена. Для малого бизнеса это может быть короткая таблица на несколько страниц, а не тяжелая ITIL-система.
Начните с того, что видит бизнес
Сервис лучше называть не по серверу и не по программе, а по функции. «Файловый сервер» для пользователей может означать «общие папки отдела продаж», «архив договоров» и «обмен с бухгалтерией». У этих функций разные владельцы, доступы, важность и последствия сбоя. Если сложить их в одну строку, поддержка будет реагировать одинаково на разные по цене ошибки.
Хорошая первая версия каталога обычно включает 10-20 сервисов: рабочее место сотрудника, учетная запись и доступы, почта, интернет, Wi-Fi, VPN, общие файлы, учетная система, печать, видеонаблюдение, телефония, backup, сайт или внешние облачные сервисы. Не нужно стремиться описать все идеально с первого раза. Важнее отделить критичные сервисы от второстепенных.
Что должно быть в карточке сервиса
| Поле | Практический смысл |
|---|---|
| Название | Понятное бизнесу имя: «почта», «общие папки продаж», «доступ к 1С» |
| Пользователи | Отделы, роли или группы, которые зависят от сервиса |
| Владелец | Человек со стороны бизнеса, который решает, что для сервиса важно |
| Технический ответственный | Кто поддерживает сервис и координирует изменения |
| Зависимости | Серверы, сеть, провайдеры, облака, лицензии, учетные записи, backup |
| Границы поддержки | Что входит в сопровождение, а что требует отдельного проекта или внешнего подрядчика |
| Приоритеты | Как отличить массовый сбой от индивидуального обращения |
| Приемка | Как пользователь или владелец подтверждает восстановление |
Владелец сервиса - не обязательно IT
У каждого важного сервиса должен быть бизнес-владелец. Для почты это может быть руководитель офиса или операционный директор, для складской системы - руководитель склада, для видеонаблюдения - безопасность или администратор объекта, для общих файлов - руководитель отдела. IT отвечает за техническую работоспособность, но не должен единолично решать, кто имеет доступ, какой простой допустим и какие данные важнее восстановить первыми.
Без владельца сервис быстро превращается в набор привычек. Права выдаются по старым просьбам, папки копятся годами, уведомления уходят не тем людям, а при сбое начинается спор, кто должен подтвердить восстановление.
Границы поддержки защищают обе стороны
Каталог полезен только тогда, когда честно описывает границы. Например, поддержка рабочих мест может включать офисные приложения, подключение принтера и диагностику сети, но не обучение работе в отраслевой программе. Сопровождение сервера может включать мониторинг, обновления, место на дисках и backup, но не разработку интеграции с внешней системой.
Такие границы не нужны для отказа от работы. Они нужны, чтобы правильно маршрутизировать заявку: решить быстро в поддержке, передать поставщику программы, согласовать проектное изменение или привлечь провайдера. Пользователь получает понятное ожидание, а не ответ «это не к нам» после нескольких пересылок.
Приоритеты должны вытекать из сервиса
Одинаковая фраза «не работает» может означать разные уровни риска. Один сотрудник не может распечатать черновик договора - это одно. Весь отдел продаж потерял доступ к CRM перед отправкой счетов - другое. Каталог помогает связать приоритет с сервисом, числом затронутых людей, временем простоя и бизнес-последствием.
- критичный сервис остановлен для отдела или всей компании;
- есть обходной путь, но он медленный или рискованный;
- затронут один пользователь без влияния на общий процесс;
- это запрос на изменение, а не инцидент;
- нужна консультация или уточнение правил.
Каталог должен жить вместе с заявками
Если каталог лежит отдельно и не используется в поддержке, он устареет. Лучше привязать его к типовым заявкам: «новый сотрудник», «доступ к папке», «не работает VPN», «нет печати», «ошибка в 1С», «нужен гостевой Wi-Fi», «восстановить файл». Тогда каждая заявка уточняет сервис, владельца, ожидаемый результат и приемку.
Раз в квартал стоит просматривать каталог: появились ли новые облачные сервисы, не изменились ли владельцы, не ушли ли сотрудники с административными ролями, не добавились ли зависимости, не устарели ли инструкции. Это короткая профилактика, которая предотвращает много хаоса в момент сбоя.
Как это связано с IT-аутсорсингом
Для IT-аутсорсинга каталог сервисов помогает перейти от разрозненной помощи к управляемому сопровождению. Один ответственный подрядчик с командой видит не только отдельную заявку, но и сервис, к которому она относится: пользователей, серверы, сеть, backup, внешние зависимости и правила приемки. Это снижает зависимость от памяти одного администратора и делает поддержку проверяемой.
В разделе ITSM такой каталог становится основой для заявок, изменений, SLA и отчетности. Для небольшой компании достаточно легкой версии: понятные названия, владельцы, зависимости, приоритеты и регулярная актуализация.
Итог: каталог IT-сервисов нужен не для красивой документации, а для управляемой поддержки. Он показывает, что важно бизнесу, кто принимает решения, от чего зависит сервис и как отличить срочный инцидент от обычного запроса.