Коротко: Надёжность подрядчика проверяется процессом работы и условиями передачи знаний, а не числом логотипов в презентации.
До подписания договора полезно разыграть несколько реальных сценариев: отказ сервера, потеря ноутбука, увольнение сотрудника и критичная заявка вечером. Ответы показывают зрелость процесса лучше общего коммерческого предложения.
Проверяйте операционную модель
Уточните, кто принимает заявки, кто выполняет вторую линию и как происходит замещение инженера. Попросите показать обезличенный пример отчёта и структуры базы знаний.
Разберите безопасность доступа
Должны быть персональные учётные записи, MFA, журналирование и процедура аварийного доступа. Общий пароль «admin» у нескольких инженеров — плохая основа для контроля.
Заранее обсудите завершение работы
Документы, резервные копии конфигураций, перечень доступов и история изменений должны передаваться компании в понятном формате. Выход из договора не должен превращаться в восстановление инфраструктуры по памяти.
Практический чек-лист
- Попросить пример SLA и отчёта
- Уточнить состав закреплённой команды
- Проверить порядок доступа инженеров
- Согласовать хранение документации
- Описать процедуру передачи дел
Что зафиксировать в документах
| Объект | Что записать | Зачем |
|---|---|---|
| Заявки | Канал, приоритеты, эскалации | Показывает управляемость |
| Доступы | MFA и персональные учётки | Снижает риск |
| Выход | Формат передачи документов | Защищает независимость клиента |
Частые вопросы
Нужен ли тестовый период?
Полезен ограниченный пилот с заранее определённым контуром и критериями.
Что важнее — сертификаты или опыт?
Нужны оба сигнала, но главным остаётся способность показать воспроизводимый процесс.
Вывод
Выбирайте подрядчика, который готов подробно описать обычную работу, неприятные инциденты и передачу дел, а не только идеальный старт.
Нужен взгляд на вашу инфраструктуру?
Опишите текущую задачу — предложим, с какой диагностики или документа начать.
Обсудить задачу →