SLA с IT-подрядчиком

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

Хороший SLA не обещает чудес. Он заранее объясняет, как классифицируются проблемы, за какое время подрядчик реагирует, когда начинает работу, что считается критичным, какие работы планируются отдельно и где граница ответственности. Для малого бизнеса это не бюрократия, а способ снизить количество разочарований.

Реакция и решение - разные вещи

Самая частая путаница - время реакции принимают за время решения. Реакция означает, что подрядчик принял заявку, понял контекст, зафиксировал приоритет и начал следующий шаг. Решение зависит от причины: можно ли исправить удаленно, нужен ли провайдер, есть ли запасное оборудование, требуется ли восстановление из бэкапа.

В SLA лучше прямо разделить эти понятия. Например: для критичных инцидентов подрядчик отвечает быстро и начинает диагностику, но срок полного восстановления может зависеть от внешних факторов. Это честнее, чем обещать «устранение за час» для ситуации, где оборван кабель провайдера или умер диск без резерва.

Также стоит определить рабочее время поддержки и правила внеурочных работ. Если клуб работает вечером и в выходные, а подрядчик только по будням до 18:00, конфликт неизбежен. Можно договориться о дежурстве, отдельной ставке или ограниченном наборе критичных сценариев.

Приоритеты на языке бизнеса

Приоритеты должны быть понятны не только ИТ. «P1» сам по себе ничего не говорит управляющему. Лучше описывать через влияние.

Критичный инцидент: остановлена работа площадки, не проходят продажи, не работает 1С у всех, нет интернета в филиале, телефония не принимает входящие, сервис с клиентскими данными недоступен.

Высокий приоритет: проблема затрагивает группу сотрудников или важный процесс, но есть временный обходной путь.

Средний: ошибка мешает одному пользователю или некритичной функции.

Низкий: консультации, настройки, плановые изменения, улучшения.

Такая шкала помогает и бизнесу, и подрядчику. Администратор не поднимает каждую мелочь как аварию, а подрядчик не относит падение телефонии к «обычной заявке». Сценарии можно связать с playbook инцидентов, чтобы в момент аварии не спорить о статусе.

Что входит в SLA

В договоре стоит явно перечислить зоны поддержки: рабочие места, серверы, сеть, Wi-Fi, резервное копирование, мониторинг, телефония, 1С, сайт, почта, взаимодействие с провайдерами. Если подрядчик отвечает не за все, это нормально, но границы должны быть видны.

Например, подрядчик может администрировать серверы и сеть, но не отвечать за ошибки в конфигурации 1С, если ее сопровождает другая компания. Или поддерживать телефонию как инфраструктуру, но не менять скрипты продаж без отдельного проекта. Чем раньше это написано, тем меньше взаимных претензий.

Полезно добавить порядок приема заявок. Один канал лучше десяти: почта поддержки, портал, Telegram-бот или общий чат с фиксацией. Если заявки приходят в личные сообщения инженеру, их невозможно нормально учитывать. Даже в маленькой компании нужна точка входа.

Что не входит в SLA

Этот раздел иногда кажется неприятным, но он защищает обе стороны. В SLA обычно не входят проектные работы, крупные изменения архитектуры, миграции, внедрение новых систем, закупка оборудования за счет подрядчика, исправление проблем у внешних провайдеров сверх коммуникации с ними.

Также не стоит включать в стандартную поддержку любые действия без ограничений: «настройте CRM», «переделайте сайт», «подключите новую кассовую схему», «срочно переезжаем в облако». Это отдельные задачи с оценкой, рисками и планом.

Важно прописать, что подрядчик не может гарантировать доступность сервисов, которыми не управляет: интернет-провайдер, облачная платформа, SaaS CRM, банк, оператор связи. Он может диагностировать, открыть заявку, контролировать коммуникацию, предложить резерв, но не управляет чужой инфраструктурой.

Окна работ и изменения

Плановые работы должны иметь окна: когда можно обновлять сервер, перезагружать оборудование, менять правила firewall, переключать телефонию. Для клуба это может быть ночь или раннее утро, для офиса - вечер, для e-commerce - периоды с меньшей нагрузкой.

Если окна не согласованы, подрядчик выбирает удобное технически время, а бизнес получает простой в неподходящий момент. В SLA стоит указать, какие изменения требуют согласования, за сколько предупреждать, кто утверждает рискованные работы.

Отдельно полезно прописать экстренные изменения. Например, закрыть критичную уязвимость можно быстрее обычного окна, но подрядчик обязан сообщить о рисках и результате. Это связывает SLA с реальной безопасностью, а не только с расписанием.

Отчеты и контроль

SLA без отчетности быстро превращается в ощущение. Раз в месяц полезно смотреть: сколько было заявок, какие приоритеты, что нарушало работу, где повторяются проблемы, какие работы запланированы. Не ради красивых графиков, а чтобы видеть, что поддержка улучшает ситуацию.

Если много однотипных обращений, возможно, нужна автоматизация, обучение сотрудников или замена оборудования. Если критичные инциденты повторяются, стоит пересмотреть архитектуру, бэкапы или провайдера. Здесь подрядчик должен быть не только «ремонтной бригадой», но и советником по ИТ-аутсорсингу.

Вместо заключения

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

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