K2opt

Как составить техническое задание (ТЗ) на абонентское IT-обслуживание, чтобы получить точную смету

K2opt

Разница между сметой в 40 000 и 120 000 рублей за один и тот же парк техники часто кроется не в жадности подрядчика, а в размытом ТЗ. Без четкого перечня активов и требований к доступности сервисов вы получите либо заниженную цену с бесконечными доплатами за «доп. работы», либо переплатите за избыточный функционал.

Инвентаризация активов: считаем «железо» и лицензии

Первая ошибка — указывать количество рабочих мест вместо количества единиц оборудования. Для сметы критично разделение: сколько ПК, сколько ноутбуков, сколько МФУ и какие именно серверы (физические или виртуальные). Например, поддержка одного сервера на Windows Server 2019 с тремя виртуальными машинами стоит в 2-3 раза дороже, чем обслуживание одного физического сервера с файловым хранилищем.

В ТЗ обязательно укажите объем данных в бэкапах и тип СХД. Разница в обслуживании архива на 500 ГБ и массива на 10 ТБ — это разные инструменты мониторинга и разные риски по времени восстановления (RTO). Рекомендую начать с составления чек-лист аудита ИТ-инфраструктуры перед заключением договора на абонентское обслуживание, чтобы не пропустить старый коммутатор в серверной, который «просто работает».

Экспертный вывод: Чем детальнее список оборудования (модель, ОС, версия ПО), тем ниже риск получить счет за «ввод в эксплуатацию» каждого устройства после подписания договора. Ошибка в инвентаризации на 10% обычно ведет к росту сметы на 15-20% в процессе работы.

Определение SLA: время реакции против времени решения

Многие путают время реакции (ответ диспетчера «мы приняли заявку») со временем восстановления сервиса. В МСБ стандартный диапазон реакции для критических инцидентов — от 15 до 60 минут, для низкоприоритетных — до 4-8 рабочих часов. Если вы требуете приезда инженера в офис за 2 часа в любой день недели, стоимость абонентской платы вырастет на 30-50%, так как подрядчик закладывает дежурство специалиста в вашем районе.

Пример: компания с 20 рабочими местами и одним сервером 1С. При SLA «реакция 15 мин / выезд 4 часа» цена будет условные 30 000 руб./мес. При требовании «выезд за 90 минут» цена прыгнет до 45 000 руб., так как потребуется выделенный инженер. Чтобы не переплачивать, изучите регламент выездной поддержки: сколько времени должен ехать инженер и что входит в понятие «срочный выезд».

Экспертный вывод: Не требуйте «мгновенного» реагирования по всем заявкам. Разделите инциденты на Critical (остановка бизнеса), Major (не работает отдел) и Minor (не печатает один принтер). Это позволит оптимизировать смету без потери качества.

Границы ответственности и «серые зоны» обслуживания

Самый конфликтный блок ТЗ — перечень работ. Типовое «техническое обслуживание» не включает в себя переезд офиса, монтаж новых кабельных трасс или замену термопасты в 50 старых ПК. В среднем 20-30% споров между клиентом и IT-компанией возникают из-за раздела «Дополнительные работы».

Четко пропишите: входит ли в абонентку настройка новых рабочих мест при расширении штата (например, до 2-х новых ПК в месяц) или это оплачивается отдельно по часовому тарифу. Если у вас есть специфический софт (1С, CRM, отраслевые программы), укажите, кто отвечает за обновление конфигураций — системный администратор или сторонний вендор. Изучите 5 скрытых ловушек в договорах на IT-поддержку офисов: на что смотреть в разделе «Дополнительные работы», чтобы не платить за каждый чих.

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

Безопасность и контроль доступа к инфраструктуре

Для компаний с оборотом от 100 млн руб. в год вопрос доступа внешнего подрядчика к базе данных клиентов становится критическим. В ТЗ необходимо указать требования к способу подключения: только через VPN с двухфакторной аутентификацией (2FA) или через выделенный шлюз. Без этого подрядчик предложит самый дешевый и небезопасный вариант — AnyDesk или TeamViewer под общим паролем.

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

Экспертный вывод: Безопасность не должна быть «по умолчанию». В ТЗ должен быть пункт о предоставлении отчета по действиям администратора (логов) и регламент смены паролей после увольнения сотрудника подрядчика.

Оценка эффективности: KPI и отчетность

Смета без KPI — это покупка «кота в мешке». Чтобы абонентское обслуживание не превратилось в оплату за отсутствие проблем (когда кажется, что админ ничего не делает, потому что все работает), заложите в ТЗ требования к отчетности. Стандарт — ежемесячный отчет с количеством закрытых тикетов, временем простоя серверов (Uptime) и анализом повторяющихся ошибок.

Если вы выбираете между штатным сотрудником и аутсорсом, используйте расчет стоимости и рисков для МСБ. В среднем, аутсорс обходится на 40% дешевле штатного специалиста уровня Middle с учетом налогов, отпусков и стоимости лицензионного ПО для мониторинга (Zabbix, PRTG), которое подрядчик предоставляет бесплатно.

Экспертный вывод: Требуйте KPI по доступности критических сервисов (например, 99.9% для сервера 1С). Это превращает отношения из «мы платим за процесс» в «мы платим за результат».

Вывод

Чтобы получить точную смету, ваше ТЗ должно превратить IT-инфраструктуру из «набора компьютеров» в структурированный перечень активов с конкретными требованиями по SLA и безопасности. Избегайте формулировок «полная поддержка» и «быстрый выезд» — используйте цифры: «количество устройств», «время реакции в минутах», «процент доступности сервисов». Начните с полной инвентаризации и анализа критических точек отказа; только так вы сможете сравнить предложения разных компаний по единому знаменателю и не переплатить за скрытые опции.

Оставить комментарий

Your email address will not be published. Required fields are marked *