План перехода на внешнюю IТ‑поддержку: что делать в первую очередь

Переходный период при смене IT‑подрядчика — критический этап: от его организации зависит, останется ли передача функций незаметной для пользователей и не пострадает ли качество сервисов. Рекомендациями, как это сделать, делится Павел Грищенко

Мини‑проект и его структура

Часто значение переходного периода в IT недооценивают, воспринимая его как техническую формальность. На самом деле это фундамент для всей дальнейшей работы с аутсорсерами. Любой переходный период по сути — мини‑проект со своей логикой, структурой и управлением.

Переход всегда начинается с диагностики (Due Diligence) со стороны аутсорсеров: они проверяют, как устроены IT‑системы, насколько они адаптированы под бизнес, насколько полная и понятная документация, есть ли доступ к ключевым специалистам и как быстро компания принимает решения.

После этого формируется индивидуальный план перехода, где фиксируются сроки, этапы и ресурсы. Далее проводится kick‑off — стартовое совещание, где стороны вместе фиксируют единое понимание целей, рисков, формата взаимодействия, правил информирования и др.

После старта наступает этап подготовки. Из основного на этом этапе важно представить аутсорсерам ключевых экспертов или SME (Subject Matter Expert — эксперт по предметной области) — тех, кто хранит уникальные знания о работе систем. Часто это неформальные лидеры, разработчики, аналитики, администраторы, чья экспертиза существует не в документах, а в опыте. Их вовлечение критично: без передачи этих знаний невозможно будет полноценно выстроить поддержку со стороны IT‑подрядчика.

Одновременно проводится аудит документации, проверка доступов, уточнение архитектурных схем и процессов. Параллельно формируется команда поддержки со стороны исполнителя — распределяются роли, назначаются ответственные за конкретные системы, выстраивается взаимодействие между линиями поддержки, формируется календарный план переходного периода и еще много других активностей.

Следующий этап — передача знаний. Пожалуй, самый трудоемкий и нервный этап переходного периода как в части планирования, так и в части реализации. Речь здесь идет не об обучении сотрудников работе с системой в принципе, а о передаче экспертам уникальных знаний о конкретном ее экземпляре. Условно этот процесс можно представить как три взаимосвязанных направления:

• Первое — функциональное: компания, как владелец процесса, показывает, как она использует систему в реальной работе и почему логика процесса устроена именно так.
• Второе — техническое: команда разработки объясняет, какие модификации были внесены в стандартное решение, чтобы поддержать требуемый сценарий.
• Третье —эксплуатационное: команда поддержки демонстрирует, где чаще всего возникают инциденты и запросы, какие типовые решения применяются и какие уязвимые точки важно учитывать при дальнейшем развитии системы.

Здесь проводятся воркшопы, обучающие сессии, демонстрации рабочих сценариев. Форматы могут быть разными, от офлайн‑встреч до записей видеосессий, особенно если сроки сжаты. Важно не просто передать информацию, а убедиться, что она усвоена: команда исполнителя должна уметь действовать самостоятельно, без оглядки на прежнего подрядчика.

Финальный этап переходного периода — проверка готовности к запуску. Чек‑лист по всем пунктам плана, причем есть общие для всех пункты: проведены ли тренинги, переданы ли доступы, утвержден ли регламент поддержки, но в каждом конкретном случае этот список свой.

Стоит отдельно обратить внимание на регламент поддержки — это своего рода настольная книга для инженеров со стороны подрядчиков, где указаны контакты, приоритеты, процедуры эскалации, порядок реагирования на инциденты.

Только после этого переходный период можно считать завершенным, а сервис полностью готовым к работе.

Возможные риски и как их снизить

1. Метрики: Процесс передачи идет, встречи проводятся, документы согласовываются, но никто не может ответить, когда же переход завершен и по каким признакам можно считать его успешным. Избежать этого можно, если сформировать набор метрик и целевое состояние процесса на старте и определить, что должно быть передано, какие проверки выполнены, какие системы протестированы, кто это подтверждает и принимает.

2. Неполная, неактуальная или противоречивая документация: Нередко в компании системы живут по своим законам, а знания о них хранятся в головах нескольких специалистов или в головном офисе. Иногда этих людей уже нет в компании или к ним нет доступа, и тогда приходится буквально восстанавливать или документировать действующий процесс практически с нуля. Даже если все описано правильно, практика показывает обратное: написанное на бумаге часто расходится с реальностью.

Поэтому стоит проверить каждый раздел, актуализировать требования, обновить инструкции, зафиксировать все аспекты, которые могут повлиять на стабильность работы. Качество документации прямо влияет на сроки и бюджет проекта перехода.

3. Человеческий фактор: Выделенные сотрудники далеко не всегда доступны: отпуска, загруженность, а иногда и банальное нежелание делиться опытом могут парализовать процесс. Бывает и открытое сопротивление.

Чтобы снизить напряжение, объясняйте, зачем это нужно, какие выгоды получат все участники, показывайте, что речь идет не об увольнениях, а о совместной эволюции. В большинстве случаев этого достаточно, чтобы 80% команды приняли изменения. С оппозицией нужно работать индивидуально: искать мотивацию, разбирать страхи, иногда договариваться о персональных условиях, если речь идет о ключевых специалистах.

4. Доступы к информации, системам, инфраструктуре: Этот пункт кажется формальностью, но именно он чаще всего негативно меняет график работ. В крупных корпорациях получение доступа подрядчика к внутренним системам занимает недели: проверки, комплаенс, согласования, физический доступ в офис. Это снижает темп передачи функций и может сдвинуть все сроки. Поэтому закладывайте дополнительный временной интервал на цепочку согласований. При таком подходе даже если риск реализуется, он перестает быть неожиданностью для аутсорсера: все понимают, что делать дальше и какие последствия это повлечет.

Приоритизация систем и методология

Когда переходный период затрагивает не одну систему, а целый IT‑ландшафт, ключевым становится вопрос приоритетов. В крупных компаниях десятки, а порой и сотни IT‑сервисов: одни напрямую влияют на ключевые бизнес‑процессы, другие обеспечивают внутреннюю операционную деятельность.

Попытка двигать их одновременно обречена на хаос, поэтому следует начинать с оценки того, какие системы являются бизнес‑критичными, а какие могут подождать. Для этого можно использовать, например, методику, напоминающую scorecard: каждая система получает баллы за критичность, количество пользователей, уровень кастомизации, зрелость кода, объем обращений, соответствие требованиям безопасности и еще несколько параметров.

Такое ранжирование превращает сложный, разветвленный контур в понятную карту работ. Системы с наивысшими баллами формируют первую волну запуска — именно они требуют максимальной концентрации усилий. Менее важные переходят во вторую или третью волну. Это позволяет не распылять ресурсы и контролировать риски: если в критичных зонах все работает без сбоев, значит, компания защищена от простоя или даже потенциально — от потери бизнеса.

Кастомизация затрудняет оценку: чем больше изменений в системе по сравнению со стандартом, тем выше трудозатраты и риски. При планировании важно учитывать: чем больше система изменена от стандартной версии, тем выше затраты. Для слабо измененных решений они составляют доли процента, а для сильно кастомизированных — могут достигать десятков процентов объема работ.

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

Но когда речь идет о десятках систем, распределенных между разными бизнес‑юнитами — продажами, логистикой, финансами, складами, — логичнее переходить к параллельной модели. Здесь приоритет отдается гибкости, а процесс строится по волнам: сначала запускаются наиболее критичные системы, затем менее чувствительные. Такой формат позволяет сохранять контроль над процессом, не теряя темпа.

Сжатые сроки: как действовать в цейтноте

Иногда обстоятельства не оставляют выбора — переходный период приходится проводить в авральном режиме. Такое случается, когда компания внезапно теряет возможность работать из‑за смены юрисдикции или внутренних ограничений. Здесь привычные схемы управления не работают, и единственный шанс обеспечить бесперебойную работу систем — максимальная концентрация и четкий план.

Рекомендуем зафиксировать жесткие рамки: определить, какие системы действительно критичны, какие можно временно отложить, какие знания нужно передать в первую очередь. Вся передача знаний должна документироваться — протоколы встреч, список вовлеченных экспертов, аудио‑ и видеозаписи сессий. Это не формальность, а способ сохранить непрерывность: даже если кто‑то уедет, сменит компанию или просто забудет деталь, информация останется.

Сжатые сроки могут увеличивать стоимость работ подрядчика. Как правило, быстро и качественно — возможно, но дешево — уже нет. Ускорение требует привлечения более опытных специалистов, расширения команды, продления рабочих смен. Это не прихоть, а закон управления проектами.

Если компания хочет запустить процесс без ошибок, ей придется инвестировать в людей, которые умеют работать в условиях высокой неопределенности. Правда, бывают случаи, когда в штате есть нужный эксперт, уже знакомый с конкретной реализацией и окружением, который без детальной передачи данных сходу видит и понимает задачу и вызовы.

Переходный период в сжатые сроки не предполагает обучения сотрудников. Здесь идеально подходят люди, которые уже проходили через кризисы и умеют сохранять темп без потери контроля.

Наконец, важна четкость коммуникации: длинные письма и совещания здесь не работают. В ход идут короткие ежедневные синки (от английского sync, сокращение от synchronization — «синхронизация»), обновления статусов в реальном времени, каналы в мессенджерах, где команда реагирует мгновенно. Нужно минимизировать все, что можно, чтобы сохранить скорость принятия решений.