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