Как выбрать IT-аутсорсера: 7 red flags в договоре, которые дорого обойдутся

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

Почему это читают после сбоя, а не до

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

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

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

Red flag №1: SLA без единой цифры

Открываю договор — и вижу формулировку: «Исполнитель обязуется реагировать на заявки клиента оперативно, в разумные сроки». Всё. Ни минут, ни часов, ни определения слова «разумные». Оперативно — это когда? Через десять минут, потому что инженер сидит и ждёт звонка, или через три дня, потому что у подрядчика запара с другим, более крупным клиентом, а вы платите по нижнему тарифу?

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

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

Red flag №2: инциденты не разбиты по приоритетам

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

Спросите у подрядчика прямо: какая у вас матрица приоритетов? Хороший ответ звучит примерно так — P1, полная остановка бизнеса: сервер, интернет, 1С недоступна всем; P2, проблема у части сотрудников, есть обходной путь; P3, косметика, не мешает работать прямо сейчас. У каждого приоритета свои сроки, и они прописаны в самом договоре или приложении к нему, а не звучат только устно на встрече перед подписанием.

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

Red flag №3: команда — это призрак, а не люди

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

У меня был разговор с директором юрфирмы на тридцать рабочих мест: их обслуживал подрядчик, который на словах представлял «команду профессионалов» и показывал красивую презентацию с фотографиями сотрудников. В реальности всей поддержкой занимался один фрилансер на удалёнке. Заболел ковидом на две недели — и компания две недели жила без техподдержки вообще, а сервер с RDP тем временем начал сбоить из-за несогласованных обновлений от кого-то, кого наняли в панике за один вечер по объявлению.

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

Red flag №4: никто не разграничил зоны ответственности

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

Хороший договор содержит матрицу ответственности: что именно входит в зону подрядчика — рабочие станции, локальная сеть, принтеры, антивирус, Windows Server на месте, а что явно вынесено за скобки — провайдер интернета, облачный хостинг 1С, сторонние SaaS-сервисы. И, что важно, обязанность подрядчика координировать работу со смежными подрядчиками при инциденте, а не просто сказать «это не к нам» и закрыть заявку.

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

Red flag №5: пароли и доступы остаются у подрядчика навсегда

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

Реальный случай: небольшая юрфирма на Ленинском проспекте рассталась с подрядчиком после года не самого качественного обслуживания. При расторжении выяснилось, что пароль администратора от роутера Keenetic знает только уволившийся с той стороны инженер, а бывший директор подрядчика «сейчас занят, перезвоню на днях». Три дня компания жила без доступа к настройкам собственной сети, и всё это время боялась, что старый подрядчик из вредности что-нибудь поменяет удалённо.

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

Red flag №6 и №7: бэкапы на бумаге и невозможность выйти из договора

Шестой флаг — резервное копирование прописано красиво, а по факту никто не проверяет, что бэкап реально восстанавливается. Мы в своей практике настраиваем Veeam с ежедневным копированием баз 1С и обязательно закладываем тестовое восстановление не реже раза в квартал — на отдельный виртуальный стенд, чтобы убедиться, что файл не битый, база поднимается, а данные читаются и открываются документами, а не просто занимают место на диске.

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

И седьмой флаг — договор, из которого невозможно выйти без потерь. Смотрите на срок уведомления о расторжении, нормально — 30 дней, а не 90 и не полгода, на штрафы за досрочное прекращение и на право заказчика запросить отчёты и логи за весь период обслуживания. Если подрядчик отказывается показать вам статистику по собственным же инцидентам, тем более странно доверять ему на год вперёд с полным доступом к вашей инфраструктуре. Хороший партнёр не боится прозрачности — потому что ему нечего скрывать.

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

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

Нормально ли, если в SLA время реакции на критичный инцидент — 4 часа?
Для критичного инцидента — остановка кассы, недоступность 1С у всех сотрудников, падение сервера — 4 часа это много. Такие вещи должны решаться за 15-60 минут реакции и максимум за несколько часов устранения. Четыре часа реакции нормальны разве что для некритичных заявок вроде настройки нового рабочего места.

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

Как проверить, что бэкапы реально восстанавливаются, а не просто создаются по расписанию?
Попросите подрядчика провести контрольное восстановление при вас — на тестовый стенд, с открытием базы 1С и проверкой хотя бы нескольких документов. Это занимает час-полтора. Если подрядчик тянет с ответом или говорит, что такое никогда не делали, это и есть готовый ответ на ваш вопрос.