Договор с IT-подрядчиком без SLA: как понять, за что вы вообще платите

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

Пятница, восемь вечера, и на телефоне тишина

Вернусь к той истории. Прежний подрядчик клиента брал 30 тысяч рублей в месяц за абонентское обслуживание. На бумаге — «техническая поддержка информационных систем заказчика». По факту — телефон менеджера, который отвечает, когда ему удобно. В пятницу вечером ему было неудобно. Ответил в понедельник в десять утра: «извините, был занят на другом объекте».

Формально он ничего не нарушил. В договоре не было ни строчки о том, за сколько часов он обязан отреагировать на заявку и в какой срок — решить. Просто «поддержка». Слово красивое, а юридически — пустое. Заказчик оплачивает абонентку каждый месяц, а получает её ровно тогда, когда подрядчику самому захочется этим заняться.

Вот в этом и весь фокус большинства договоров на IT-аутсорсинг без SLA. Они не про обязательства. Они про намерения. А намерения, как известно, не спасают, когда касса встала в разгар торгового дня или сервер 1С лёг за два часа до сдачи отчёта в налоговую.

SLA — это не юридическая заумь, а правила игры на бумаге

Расшифровывается SLA как Service Level Agreement, соглашение об уровне сервиса. Пугающая аббревиатура, но смысл предельно приземлённый. Это раздел договора, где чёрным по белому написано: что именно подрядчик обязан делать, за какое время и что будет, если он не уложился.

Есть миф, что SLA нужен только огромным компаниям с айтишным отделом и юристами в штате. Ерунда. Я работаю с клиентами на 8-15 рабочих мест — стоматологии, небольшие торговые компании, бухгалтерские аутсорсеры. У них SLA даже нужнее, чем у крупняка: там нет своего системного администратора, который в случае чего подхватит проблему сам. Есть только подрядчик. И либо он прописан в договоре, либо его как бы и нет.

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

Время реакции и время решения — это два разных числа, и их путают специально

Первое, на что нужно смотреть в договоре: время реакции (response time) отдельно от времени решения (resolution time). Это разные вещи, и недобросовестные подрядчики любят их смешивать в одну расплывчатую фразу «оперативно решаем проблемы».

Время реакции — это сколько минут или часов проходит от вашей заявки до момента, когда с вами связался живой инженер и начал разбираться. Время решения — сколько времени уйдёт на то, чтобы проблема реально исчезла. У нас в договорах, например, для критичных инцидентов реакция — 30 минут, решение — до 4 часов в рабочее время. Для некритичных — реакция 4 часа, решение — на следующий рабочий день.

Если в вашем договоре написано просто «в кратчайшие сроки» или «в разумный период» — это не срок. Это отсутствие срока, красиво упакованное. Спросите себя: если завтра сервер встанет, что означает «разумный период» — час, сутки, неделю? Юридически подрядчик прав в любом из этих вариантов, и вы ничего не докажете.

Не всё горит одинаково: без приоритетов SLA не работает

Второй обязательный блок — классификация инцидентов по приоритету. Потому что «не работает 1С на кассе в момент отгрузки» и «не печатает штрих-код на одном из трёх принтеров этикеток» — это две разные вселенные, а формально обе подпадают под «неисправность оборудования».

У нормального подрядчика в договоре прописано минимум три-четыре уровня. Критичный — остановлена работа всей компании или ключевого бизнес-процесса: не работает сервер 1С, упала касса, недоступен RDP для удалённых сотрудников. Высокий — не работает у части людей или один важный сервис, но бизнес пока идёт. Средний — неудобство, но есть обходной путь. Низкий — косметика, вопросы по настройке.

У одного нашего клиента, оптовой торговой компании, раньше в договоре с прежним подрядчиком приоритетов не было вообще. В итоге заявка «завис принтер у секретаря» и заявка «не проходят платежи в клиент-банке» стояли в одной очереди и решались в порядке поступления. Секретарский принтер, как назло, поступил первым. Директор потом два часа объяснял банку, почему платёж завис.

Что происходит, если подрядчик не берёт трубку

Третий блок, который почти всегда выпадает из типового договора — эскалация. Что делать, если ответственный инженер не отвечает, болеет, уехал, или просто не поднимает трубку в критичный момент? В хорошем договоре прописан второй контакт — руководитель проекта или дежурный, к которому автоматически переходит заявка, если не было реакции в срок.

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

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

Кто отвечает за бэкапы, если сервер сгорел физически

Отдельная больная тема — резервное копирование и ответственность за данные. У меня был случай с клиентом из производственной сферы: сервер стоял без ИБП, скачок напряжения вывел из строя диски RAID-массива. Восстановили железо за день, а вот данные — увы. Резервные копии в договоре с прежним подрядчиком упоминались одной строкой: «производится по мере необходимости». Как выяснилось, необходимость возникала у них примерно раз в квартал.

Компания потеряла две недели работы 1С — заказы, накладные, переписку с клиентами. Восстанавливали руками по бумажным копиям и звонкам поставщикам почти три недели. Обошлось это дороже, чем весь годовой контракт на IT-обслуживание.

Поэтому в SLA обязательно должно быть прописано: что именно бэкапится, с какой периодичностью, каким инструментом (у нас чаще всего Veeam или встроенные средства 1С и Windows Server), куда складывается копия, и главное — как часто проверяется восстанавливаемость. Бэкап, который никто ни разу не пробовал развернуть, с вероятностью процентов сорок окажется битым именно в тот момент, когда понадобится по-настоящему.

Как читать договор, если SLA в нём нет вообще

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

Если подрядчик начинает уходить от разговора, мямлить про «мы и так всё делаем оперативно», «зачем формальности, мы же партнёры» — это тревожный звонок. Партнёрство не мешает зафиксировать сроки на бумаге. Если ему это неудобно, значит, ему удобнее работать без обязательств, а вам без защиты.

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

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

У нас уже подписан договор без SLA. Что делать, переподписывать всё заново?
Необязательно расторгать основной договор. Достаточно оформить дополнительное соглашение к нему, где прописать конкретные сроки реакции, решения, приоритеты и ответственность за нарушение. Юридически это займёт одну-две страницы и подписывается за один визит. Если подрядчик отказывается — это уже сигнал задуматься о его замене.

Насколько дороже обслуживание с прописанным SLA по сравнению с обычным?
По моей практике разница обычно 10-20% к обычной абонентской плате, а не в разы. За компанию на 15-20 рабочих мест это плюс 3-6 тысяч рублей в месяц к типовой ставке 25-35 тысяч. Учитывая, во сколько может обойтись сутки простоя кассы или потеря базы 1С, это довольно дешёвая страховка.

Нужен ли SLA маленькой компании на 8-10 человек, или это только для крупных?
Нужен ещё сильнее, чем крупным. У большой компании часто есть свой IT-специалист в штате, который подстрахует, пока подрядчик тянет время. У маленькой компании подрядчик — единственная линия обороны. Без прописанных сроков вы полностью зависите от его личной добросовестности, а это не то, на чём стоит строить бизнес.

Как проверить, что подрядчик реально соблюдает SLA, а не просто написал его в договоре?
Попросите ежемесячный отчёт с фактическим временем реакции и решения по каждой заявке — это нормальное и законное требование, если оно прописано в договоре. Также можно просто засекать время самому пару месяцев подряд и сверять с обещанными цифрами. Расхождение сразу видно, и это повод для разговора или для тех самых штрафных санкций.