Короткий ответ: качество IT-подрядчика проверяется не по обещаниям, а по фактам: как принимаются заявки, соблюдаются ли приоритеты, фиксируются ли причины сбоев, есть ли документация, проверяется ли backup, видны ли риски до аварий и становится ли повторяющихся проблем меньше.
Что смотреть
| Зона | Хороший признак | Плохой признак |
|---|---|---|
| Заявки | Есть единый канал, статус, ответственный и история | Просьбы теряются в чатах и личных сообщениях |
| Реакция | Приоритет связан с влиянием на работу компании | Все срочно или все ждут одинаково |
| Восстановление | Фиксируется результат и причина инцидента | Есть ответ, но сервис остается нестабильным |
| Документация | Актуальны серверы, сеть, доступы, backup, контакты | Инфраструктура держится в памяти одного инженера |
| Backup | Есть успешные копии и периодическая проверка восстановления | Видно только, что задание запускалось |
| Отчет | В отчете есть риски, повторения и план действий | Отчет состоит из количества закрытых заявок |
| Коммуникация | Понятно, что затронуто, кто делает и когда следующий статус | Пользователь сам выясняет, что происходит |
Вопросы подрядчику
- Какие системы считаются критичными и кто их владелец со стороны клиента?
- Где фиксируются заявки, приоритеты, сроки реакции и результат?
- Какие инциденты повторялись за последний месяц и что сделано с причиной?
- Какие серверы, сети, учетные записи и внешние сервисы задокументированы?
- Когда в последний раз проверялось восстановление из backup?
- Какие риски требуют плановых работ или отдельного проекта?
Что должно быть видно в ежемесячном отчете
Хороший отчет показывает не активность подрядчика, а состояние IT. В нем должны быть заявки по приоритетам, аварии, повторяющиеся причины, просрочки, состояние backup и мониторинга, изменения за период, открытые риски и рекомендации с приоритетом.
Если отчет нельзя использовать для решения, это слабый отчет. Руководителю не нужны все технические детали подряд; ему нужно понять, где компания может остановиться, что уже исправлено и какие действия согласовать дальше.
Чек-лист приемки качества
- Заявки не теряются и имеют понятный статус.
- Критичные инциденты отделены от обычных обращений.
- Пользователи получают понятные обновления по важным сбоям.
- Повторяющиеся проблемы не закрываются как отдельные мелкие заявки.
- Backup контролируется не только по факту запуска, но и по восстановимости.
- Документация позволяет другому инженеру разобраться в инфраструктуре.
- Плановые изменения согласуются заранее и проверяются после выполнения.
- Риски не прячутся: подрядчик прямо показывает, где нужна модернизация или отдельный проект.
Типовые ошибки оценки
Оценивать только скорость ответа. Быстрый первый ответ не означает восстановление сервиса.
Считать количество заявок главным показателем. Много закрытых заявок может означать не хорошую поддержку, а повторяющуюся нерешенную причину.
Не проверять документацию и backup. Эти зоны редко видны каждый день, но именно они решают исход аварии.
Смешивать поддержку и проекты. Подрядчик может хорошо вести регулярную поддержку, но крупные миграции и модернизации должны оцениваться отдельными критериями.
Не назначить ответственного со стороны клиента. Даже сильный подрядчик не примет бизнес-решения вместо компании.
Итог: хороший IT-подрядчик делает инфраструктуру управляемой: заявки понятны, риски видны, восстановление проверено, повторяющиеся сбои уменьшаются, а руководитель получает факты для решений.