Главная > Блог > Пост-интеграция IT-систем после M&A Пост-интеграция IT-систем после M&A: план на первые 100 дней Михаил Кадочников · 29 июля 2026 · 20 мин чтения 01 Почему IT интеграция часто убивает смысл M&A сделки Sтатистика из Harvard Business Review показывает, что 70% M&A сделок не достигают своих целей. Причины разные, но технологическая интеграция занимает ТОП-3. Компании недооценивают сложность объединения IT-систем, и в результате теряют месяцы, команды демотивируются, клиенты недовольны. Вот сценарий, который я видел десятки раз: Company A покупает Company B за ₽500M. На бумаге всё выглядит отлично: синергия команд, объединённый продукт, расширение рынка. Но когда наступает момент интеграции IT-систем, оказывается, что: A разрабатывает на Python/Django, B на JavaScript/Node.js A использует PostgreSQL, B использует MongoDB A развёртывается в AWS, B в Google Cloud Нет никакой документации на то, как системы работают Ключевые люди в обеих компаниях испуганы потенциальной потерей работы Что происходит дальше? В лучшем случае, интеграция занимает 6-9 месяцев вместо планируемых 2-3 месяцев. В худшем случае, она переходит на 1-2 года, теряется ценность сделки, хорошие разработчики уходят, проект становится неуправляемым. Почему IT интеграция критична: Это затрагивает core операций — если системы не интегрируются, компании не могут обслуживать клиентов эффективно Это требует кооперации обеих команд — если команды конфликтуют, интеграция идёт медленно Это технически сложно — две системы могут иметь противоречивые требования, несовместимые архитектуры Это влияет на культуру — когда люди боятся за свою работу, они менее кооперативны Это отвлекает от business development — вместо продажи новых фич, команда борется с интеграцией Профессиональный подход к IT интеграции требует скоординированного плана, четкие фазы, управление рисками, и хорошую коммуникацию со всеми stakeholders. Эта статья описывает проверенный подход, который я использовал в нескольких M&A сделках. 02 Фаза 1: Discovery (дни 1-14) — Понять, что у вас есть Первая неделя: картирование IT ландшафта Сразу же после signing документов нужна полная инвентаризация IT систем обеих компаний. Это должно включать: Все приложения — какие приложения запущены, на каких языках, в каком состоянии? Все данные — какие базы данных, как часто обновляются, какой размер, как они бэкапятся? Вся инфраструктура — какие серверы, облачные сервисы,네트ворк конфигурация? Все интеграции — какие системы обмениваются данными, через какие API/protocoly? Все люди — кто разрабатывает, кто поддерживает, кто администрирует? Все контракты — какие SaaS сервисы используются, какова стоимость, какие сроки контрактов? Результат: детальная диаграмма IT ландшафта с указанием всех систем, их связей, размеров, критичности. Обычно это выглядит как большая диаграмма с кучей линий, которые пересекаются во всех направлениях. Вторая неделя: выявление quick wins и критичных проблем После картирования начинают видеть возможности для быстрых улучшений: Дублирование функциональности — есть ли две системы, которые делают одно и то же? Можно ли отключить одну? Дешёвые выигрыши в стоимости — есть ли два подписания на один сервис вместо одного? Это немедленная экономия. Проблемы с безопасностью — есть ли явные уязвимости, которые нужно зафиксировать немедленно? Точки отказа — есть ли система, от которой зависят клиенты, и которая может сломаться? Quick wins важны психологически: они показывают, что интеграция приносит пользу немедленно, и помогают мотивировать команды. Шаблон для Discovery встреч: 30 мин: Обзор системы от владельца 15 мин: Вопросы об архитектуре, масштабируемости, проблемах 15 мин: Вопросы о данных, безопасности, бэкапах 15 мин: Вопросы об интеграциях, зависимостях от других систем 15 мин: Вопросы о команде, документации, планах развития Итого: 1.5 часа на систему Результаты фазы Discovery Полная инвентаризация систем (spreadsheet с деталями) Диаграмма зависимостей между системами Список критичных проблем, требующих немедленного исправления Список quick wins для фазы Stabilization Оценка сложности интеграции для каждой системы Рекомендуемый порядок интеграции (какую систему трогать первой, чтобы минимизировать риск) 03 Фаза 2: Stabilization (дни 15-45) — Устранить критичные риски Задача: привести обе системы в stable state На этой фазе нельзя трогать критичные компоненты. Вместо этого, нужно сделать обе системы максимально стабильными и защищёнными перед началом интеграции: Unified access control — все сотрудники обеих компаний должны иметь доступ к нужным системам. Это обычно требует интеграции с единым directory (Active Directory или LDAP). Unified security — обновить пароли, включить 2FA, пересмотреть권限, закрыть уязвимости. Unified backup и disaster recovery — убедиться, что обе системы имеют регулярные бэкапы, есть процедура восстановления, всё протестировано. Unified monitoring — подключить обе системы к единой системе мониторинга (например, Datadog, New Relic), чтобы видеть в реальном времени, что происходит. Quick wins — отключить дублирующиеся подписания, закрыть уязвимости, которые были выявлены на Discovery фазе. Communication plan на этой фазе Люди боятся неизвестности. Нужна регулярная коммуникация: Еженедельные townhalls для обеих команд с обновлениями о прогрессе Четкое сообщение: «Этап 2 фокусируется на стабильности, без больших изменений» Публичное признание quick wins: «Мы сэкономили ₽X млн в месяц благодаря объединению подписаний» Разъяснение: кто может потерять работу (редко, обычно дублирующиеся роли), кого это не коснётся «Лучшие интеграции I've seen — это те, где обе команды видят конечную цель и верят, что станут лучше, а не хуже, после интеграции.» Результаты фазы Stabilization Unified access control для всех сотрудников Все критичные уязвимости закрыты Unified backup и monitoring Выплата quick wins (экономия затрат) Обе системы стабильны и готовы к более глубокой интеграции 04 Фаза 3: Integration (дни 46-90) — Объединение систем Большие технологические выборы На этой фазе нужно принять основные решения о том, как интегрировать системы. Есть три подхода: 1. Absorb (поглощение) Выбираем одну систему как главную и постепенно переносим функциональность из другой в главную. Это самое радикальное решение, но иногда самое правильное. Пример: Company A использует свою CRM систему, Company B использует Salesforce. Решение: мигрируем данные из B в A, отключаем Salesforce. Плюсы: простота, нет необходимости в интеграции, одна система обслуживать. Минусы: теряем функциональность из B, требует полной переписи данных, может сломать workflow которые привыкли пользователи в B. 2. Best-of-breed (лучшее из обоих) Выбираем лучшие компоненты из обеих систем и объединяем их. Это более сложно, но может дать лучший результат. Пример: A имеет хороший billing module, B имеет хороший reporting module. Берём оба, связываем через API, создаём unified interface. Плюсы: сохраняем best practices, клиенты получают лучший продукт. Минусы: требует развития API, сложнее в поддержке, может быть медленнее. 3. Rebuild (полная переписка) Создаём новую систему с нуля, которая займёт место обеих. Это самое дорогое и длительное решение, но иногда необходимо. Пример: обе компании имеют 10-летнее legacy кода, лучше переписать с нуля на современных технологиях. Плюсы: свежий старт, современные технологии, нет наследованного техдолга. Минусы: очень дорого (может быть в 2-3x дороже, чем интеграция), рискованно (может быть новое ПО хуже старого), займёт 1-2 года. Как выбрать подход: Absorb: если одна система явно лучше, или техдолг в другой слишком высокий Best-of-breed: если обе системы имеют уникальные сильные стороны и невелик техдолг Rebuild: если обе системы в плохом состоянии, или требуется переход на новую технологию Data migration — самая опасная часть Если вы переносите данные из одной системы в другую, это огромный риск. Потеря данных = потеря клиентов = судебные иски. Процесс должен быть: Создать экспорт данных из старой системы Провести чистку (удалить дубликаты, исправить ошибки) Трансформировать в формат новой системы Загрузить в тестовую окружающую Проверить: все ли данные загрузились? есть ли потери? Провести пилотную миграцию на подмножество пользователей Провести full миграцию в нерабочее время (обычно ночью в выходной) Провести rollback процедуру (в случае чего, вернуться к старой системе) Провести полную проверку после миграции Рекомендую использовать специализированные инструменты для миграции (Talend, Informatica, Apache Nifi), а не писать свои скрипты. Инструменты имеют built-in логирование, monitoring, rollback. Поэтапная интеграция Не интегрируем все системы сразу. Начинаем с низкорисковых компонентов: Неделя 1: HR система (низкий риск, ограниченное число пользователей) Неделя 2: Email система (средний риск, но критично для коммуникации) Неделя 3: Knowledge management (низкий риск) Неделя 4: CRM система (высокий риск, но критично для бизнеса) И т.д. Поэтапный подход позволяет выучить lessons на низкорисковых системах и применить на высокорисковых. Результаты фазы Integration Основные системы объединены Данные мигрированы без потерь API интеграции работают Пользователи обучены новым системам Support team подготовлен 05 Фаза 4: Optimization (дни 91-100) — Измерить, документировать, спланировать Что вышло хорошо, что плохо После 90 дней нужно провести ретроспективу: что получилось, что не получилось, что нужно улучшить? Провести анонимный опрос сотрудников обеих команд о процессе интеграции Измерить метрики: uptime, performance, user satisfaction, cost savings Выявить bottlenecks, которые замедлили интеграцию Документировать lessons learned для будущих сделок Долгосрочная дорожная карта 100 дней — это не конец, это только начало. Нужна долгосрочная дорожная карта на следующие 1-2 года: Какие системы нужно полностью переписать (может быть в следующем году)? Какой техдолг нужно исправлять (может быть 20% времени на рефакторинг в течение года)? Какие новые фичи планируются для unified продукта? Какие cost savings реализовать (может быть в течение года)? Культурная интеграция команд Техническая интеграция — это только половина. Другая половина — это люди: Создать unified engineering team с представителями обеих компаний Установить единые стандарты разработки (code review процесс, naming conventions, testing standards) Провести knowledge sharing сессии между командами Признать good work и celebrate wins Быть прозрачным о potential role changes/redundancies (ничто не убивает мораль быстрее, чем неопределённость) Опытные IT интеграторы рекомендуют создать "integration buddy" программу: каждый разработчик из компании A получает бадди из компании B. Вместе они работают над интеграцией, обучают друг друга, создают личные связи. Это значительно улучшает cooperation и снижает конфликты. Также рекомендуется провести социальные события: shared lunch, team building, совместные проекты на стороне (hack-a-thon). Это помогает людям видеть друг друга как коллег, а не врагов из "другой компании". Критичные факторы успеха IT интеграции: Leadership buy-in — CEO и COO должны активно поддерживать процесс Clear communication — все stakeholders должны знать план и progress Risk management — мониторить риски активно, адаптировать план People focus — помнить, что это влияет на людей, быть empathetic Phased approach — не делать всё сразу, идти пошагово Результаты фазы Optimization Полная документация по интеграции (что было сделано, почему, как) Долгосрочная дорожная карта на 1-2 года Lessons learned для будущих сделок Unified engineering culture Базовый план для further improvements 06 Бюджет, сроки и организационная структура Сколько это стоит? IT интеграция обычно стоит 5-15% от стоимости сделки. Если вы покупаете компанию за ₽1B, интеграция обойдётся в ₽50-150M. Разбивка расходов: Personnel (60-70%) — дополнительные инженеры, архитекторы, project managers Tools и infrastructure (15-20%) — дополнительная вычислительная мощность для тестирования, tools для миграции External consultants (10-15%) — если нужна специализированная помощь Training и communication (5-10%) — training пользователей, документация Это значительное вложение, но без него риск провалить интеграцию очень высокий. Экономить на интеграции — это ложная экономия. Сроки 100 дней — это базовый план для небольших/средних компаний с простой архитектурой. Для больших компаний с сложной архитектурой может потребоваться 6-12 месяцев. Но базовые 100 дней есть всегда: Discovery: 2 недели Stabilization: 4 недели Integration: 6 недель Optimization: 2 недели Организационная структура Нужна dedicated IT Integration team, которая работает полный день на этом: IT Integration Lead (1 человек) — отвечает за весь процесс, координирует с обеими сторонами Architecture leads (2-3 человека) — один из A, один из B, один независимый (если нужен) Technical specialists (4-6 человек) — backend, frontend, devops, database, security, QA Project manager (1 человек) — отвечает за сроки, риски, communication Communication lead (1 человек) — отвечает за townhalls, документацию, FAQ Итого: 10-12 человек на 100 дней. Это дорого, но необходимо. «IT интеграция после M&A — это марафон, не спринт. Первые 100 дней это критична, но это основание для долгосрочного успеха. Правильно сделанная интеграция может увеличить стоимость сделки на 20-30%. Неправильно сделанная может уничтожить всю ценность.» 07 Частые ошибки и как их избежать Ошибка 1: Начать интеграцию слишком рано Некоторые компании хотят начать интеграцию через несколько дней после closing deal. Это ошибка. Нужно потратить время на Discovery, иначе вы делаете ошибки с неполной информацией. Ошибка 2: Забыть про культурную интеграцию Если люди в обеих компаниях находятся в конфликте или недоверии, технологическая интеграция будет невозможна. Нужна открытая коммуникация. Ошибка 3: Недооценить дата миграцию Миграция данных часто требует больше времени и ресурсов, чем ожидалось. Потеря данных может быть катастрофой. Не спешите. Ошибка 4: Забыть про backup Перед любой большой интеграцией, сделайте полный бэкап обеих систем. Нужна процедура rollback на случай, если что-то пойдёт не так. Ошибка 5: Попытаться интегрировать всё сразу Поэтапный подход медленнее, но безопаснее. Начните с низкорисковых компонентов, выучите lessons, применяйте на высокорисковых. Ошибка 6: Недооценить важность тестирования После интеграции нужно провести полное тестирование: unit тесты, интеграционные тесты, UAT (user acceptance testing). Баги найденные в production — это очень дорого. Ошибка 7: Забыть про внешние системы и интеграции Часто компания интегрирует внутренние системы, но забывает об интеграциях с внешними сервисами (payment gateway, CRM, analytics). Нужно проверить все. FAQ Часто задаваемые вопросы Нужно ли иметь единую технологическую платформу? Не обязательно. Две разные технологии могут хорошо работать вместе, если есть хорошие API и интеграция. Но если две платформы имеют fundamentally несовместимые архитектуры, может потребоваться переход на одну платформу. Как долго людям требуется привыкнуть к новым системам? Обычно 2-4 недели для базового использования, 2-3 месяца для полного овладения. Нужно проводить training и поддерживать hotline для вопросов. Что если люди отказываются использовать новые системы? Это может быть большой риск. Нужно понять причину: система может быть плохой, или люди просто боятся перемен. Нужна хорошая коммуникация и поддержка. Нужно ли выбирать одну компанию как «главную» при интеграции? Не всегда. Иногда лучше создать unified team, которая не относится явно к A или B. Это может помочь избежать конфликтов типа "это решение B" vs "это решение A". Сколько людей нужно уволить при интеграции? Это зависит от избыточности ролей. Обычно избыточность 10-30% (например, две HR системы требуют только одного team). Но это очень чувствительный вопрос, который нужно решать с большой осторожностью и прозрачностью. Как управлять рисками во время интеграции? Нужен риск-матрица с identificitation всех потенциальных проблем, их вероятности и влияния. Еженедельный мониторинг, быстрое реагирование на новые риски. Нужна процедура escalation. Готов обсудить вашу задачу Отвечу в течение 2 часов. Бесплатная оценка проекта за 24 часа. Написать в Telegram WhatsApp mk@cybergroup.su +7 (963) 275-29-83