Как выбрать IT-аутсорсинг: критерии, вопросы и проверка договора

Начните не с подрядчика, а с границ услуги

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

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

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

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

Хорошее техническое задание описывает не только количество устройств, но и ожидаемые часы поддержки, критичные процессы и допустимые перерывы.

Сформируйте короткий список по проверяемым признакам

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

Размер подрядчика сам по себе ничего не гарантирует. Важнее, соответствует ли дежурная модель вашему режиму работы, есть ли резервирование специалистов и кто отвечает за конкретные технологии. Для небольшой стандартной инфраструктуры узкая команда может быть эффективнее крупного интегратора; для распределённой среды важнее формализованная диспетчеризация и покрытие часовых поясов.

Проверьте SLA как рабочий механизм

SLA полезен, когда определяет измеримое обязательство и способ измерения. Формулировка «реагируем за 15 минут» неполна: неизвестно, для каких обращений, в какие часы, когда запускается таймер и что считается реакцией. Подтверждение получения заявки ещё не означает начало диагностики.

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

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

• Каналы регистрации и единая временная зона событий.
• Определения реакции, восстановления, решения и закрытия.
• Матрица влияния и срочности с примерами.
• Плановая доступность и исключённые интервалы.
• Эскалация при риске нарушения цели.
• Периодичность разбора нарушений и корректирующих действий.

Оцените безопасность и управление доступом

Аутсорсер получает технические возможности, поэтому его доступ должен проектироваться как доступ привилегированной третьей стороны. Спросите, используются ли персональные учётные записи, многофакторная аутентификация, ограничение по ролям и журналирование. Общая учётная запись «admin» не позволяет установить автора изменения и затрудняет немедленный отзыв прав.

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

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

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

Разберите цену до сопоставимой модели

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

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

Проведите пилот на реальных процессах

Презентация показывает намерения, пилот — поведение процесса. Выберите ограниченный, но репрезентативный контур: одну площадку или группу пользователей, несколько типов обращений, мониторинг согласованного набора систем и одно плановое изменение. Не переносите сразу все административные полномочия.

До старта определите критерии: полнота регистрации обращений, соблюдение приоритета, качество коммуникации, корректность эскалаций, документирование изменений и полезность отчёта. Оценивайте не только скорость закрытия. Быстро закрытая заявка без проверки результата или с потерей контекста создаёт повторную работу.

1. Зафиксировать исходное состояние, границы пилота и ответственных с обеих сторон.
2. Настроить ограниченные персональные доступы и каналы регистрации обращений.
3. Провести вводную передачу знаний по согласованному чеклисту.
4. Воспроизвести обычные обращения, эскалацию и контролируемое изменение.
5. Сверить события с отчётом, разобрать отклонения и оценить корректирующие действия.
6. Принять решение о расширении, доработке условий или завершении пилота.

Закрепите управляемый вход и выход

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

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

Финальная оценка должна объединять качество процесса, риск и полную стоимость, а не выдавать победителя по одному баллу. Назначьте веса критериям до получения предложений. Тогда привлекательная скидка или яркая демонстрация не изменят правила сравнения задним числом.

• Приложение с перечнем систем и услуг.
• SLA и матрица эскалации.
• Регламент доступа и обработки инцидентов.
• Порядок согласования изменений.
• Формат отчётности и право на выгрузку данных.
• План перехода, завершения и удаления доступов.