Как составить техническое задание для тендера на ИТ-услуги
Выбор подрядчика для обслуживания IT-инфраструктуры редко обходится без формализованной процедуры. Контракты на аутсорсинг, поддержку сетей или разработку сайтов требуют чёткого описания ожиданий, иначе сравнивать предложения разных исполнителей практически невозможно.
Техническое задание превращает разговор о потребностях компании в документ, который понимают одинаково и заказчик, и поставщик. Грамотно составленная спецификация снижает вероятность споров по объёму работ и помогает сразу отсеять неподходящие компании.
Проведение тендера на ИТ-услуги подразумевает и поиск выгодной цены, и проверку компетенций исполнителя, его готовности соблюдать SLA и работать с конкретным стеком технологий. Чем подробнее заполнен каждый раздел ТЗ, тем прозрачнее отбор.
Ниже разобраны ключевые этапы подготовки документа, требования к разделам, критерии оценки заявок и сравнение форматов сотрудничества — от разовых проектов до комплексного обслуживания.
Подготовка к закупочной процедуре
Прежде чем приступать к описанию требований, заказчик формирует рабочую группу. В неё обычно входят IT-руководитель, представитель службы безопасности, юрист и конечные пользователи сервисов. Такой состав помогает учесть технические, регуляторные и эксплуатационные нюансы.
На этом же этапе определяют верхнюю границу бюджета, сроки оказания услуг и допустимые рамки по критичности систем. Решения по этим параметрам лучше фиксировать в протоколе — тогда в дальнейшем проще обосновать отклонение заявок, не соответствующих рамкам.
Завершает подготовку публикация извещения и сбор вопросов от потенциальных исполнителей. Раздел с разъяснениями полезно публиковать открыто: это уравнивает всех участников и снижает вероятность жалоб в контролирующие органы.
Структура технического задания
Универсального шаблона не существует, но есть разделы, без которых закупка ИТ-услуг проходит с перекосами. К ним относятся общие сведения о заказчике, цели проекта, описание текущей инфраструктуры, перечень требуемых сервисов, требования к срокам, отчётности и приёмке.
Желательно выделить в отдельный блок требования к квалификации персонала: количество сертифицированных инженеров, опыт работы с конкретными вендорами, наличие круглосуточной линии поддержки. Эти параметры часто определяют качество обслуживания не меньше, чем стоимость контракта.
Дополнительно стоит описать порядок эскалации инцидентов, регламент резервного копирования и условия обновления программного обеспечения. Чем тщательнее расписаны процессы, тем меньше почвы для двусмысленности в ходе исполнения контракта.
Описание функциональных требований
Функциональный блок фиксирует, что именно должен делать исполнитель. Например, для обслуживания сетевой инфраструктуры указываются типы поддерживаемого оборудования, перечень площадок и режим реагирования на заявки.
Для услуг по разработке сайта или корпоративного портала описывают число страниц, требуемые интеграции с CRM и платёжными системами, поддерживаемые языковые версии. Полезно сразу обозначать ожидаемое поведение интерфейса в типовых сценариях — это снимает разночтения с дизайнерами.
Если услуга предполагает закупку оборудования, добавляют требования к гарантийному сроку, совместимости с существующими системами и условиям поставки. Лучше приводить конкретные модели или эквиваленты, а не абстрактные характеристики.
Нефункциональные требования и SLA
В этом разделе формулируют требования к доступности, производительности и безопасности. Для каналов связи обычно указывают допустимое время простоя, параметры задержки и пропускной способности, порядок резервирования. Это основа для расчёта уровней сервиса.
Отдельно прописывают требования к защите информации: шифрование трафика, разграничение доступа, журналирование событий. Если часть сотрудников работает вне офиса, в спецификации описывают принципы безопасного подключения к внутренним ресурсам — здесь уместно сослаться на пошаговое руководство по настройке VPN с типовыми сценариями подключения.
Уровни SLA удобно задавать таблицей: например, время реакции на критический инцидент — 15 минут, на некритический — 4 часа. Чем точнее цифры, тем проще начислять штрафы и аргументировать претензии.
Критерии оценки коммерческих предложений
Стоимость услуг обычно занимает 40–60 % итоговой оценки. Остальное распределяется между опытом подрядчика, качеством пилотных решений, скоростью реакции и полнотой команды.
Полезно ввести балльную систему, где каждый критерий имеет фиксированный вес. Тогда спорные решения легко обосновать протоколом, а не субъективным мнением членов комиссии.
При оценке комплексных предложений стоит проверять, как исполнитель планирует закрывать смежные задачи — насколько глубоко он готов погружаться в инфраструктуру заказчика и поддерживать её силами собственных инженеров, а не субподрядчиков.
Распространённые ошибки при подготовке ТЗ
Самая частая ошибка — отсутствие описания текущей инфраструктуры. Без этого подрядчик вынужден делать предположения, а итоговая смета отличается от ожидаемой.
Вторая типовая проблема — избыточные требования, не связанные с бизнес-целями. Например, обязательное использование конкретной СУБД без обоснования сужает круг участников и часто приводит к росту цены без реальной пользы.
Третья ошибка — отсутствие метрик приёмки. Если непонятно, как именно будет оцениваться результат, заказчик рискует получить формально выполненный договор и неработающий сервис.
Четвёртая — размытые сроки. Формулировки «в кратчайшие сроки» или «по запросу» не дают оснований для претензий при срыве графика.
Сравнение форматов сотрудничества
На этапе выбора формата заказчик сопоставляет разовые проекты, абонентское обслуживание и гибридные схемы. У каждого варианта свои сильные стороны и ограничения, которые удобно свести в таблицу.
| Формат | Что включает | Когда подходит | Главный риск |
|---|---|---|---|
| Разовый проект | Чёткий объём работ и фиксированный бюджет | Создание сайта, внедрение новой системы | Сложно масштабировать поддержку после сдачи |
| Абонентское обслуживание | Поддержка, мониторинг, регламентные работы | Текущее обслуживание IT-инфраструктуры | Слабая мотивация исполнителя развивать систему |
| Гибридная модель | Проектные работы и абонентская поддержка | Компании с растущей инфраструктурой | Требует зрелого управления со стороны заказчика |
Сопоставление характеристик помогает сразу заложить в ТЗ те условия, которые отвечают задачам бизнеса. Для небольших компаний оптимальна гибридная модель — она закрывает и точечные задачи, и регулярное сопровождение.
При крупной географии и разветвлённой сети площадок стоит сразу оговаривать условия выезда инженеров, лимиты на командировочные расходы и правила работы с подрядчиками в регионах.
Заказчику, который впервые готовит тендер на ИТ-услуги, разумнее опираться на практический опыт поставщика с подтверждённой экспертизой. Если вы формируете техническое задание и хотите заранее сверить требования с реальными возможностями рынка, обратитесь в TC Telecom — инженеры компании помогут выстроить спецификацию под вашу инфраструктуру и подобрать оптимальный формат обслуживания.