Как объединить ИТ-системы двух компаний после покупки: порядок действий и что идёт не так

Сделка подписана, юристы разошлись. Остаются два набора логинов, две системы учёта, две базы клиентов и цифра экономии, которую кто-то пообещал совету директоров. Вот порядок, который выдерживает нагрузку, решение, которое нужно принять по каждой системе, и то, что два публичных провала говорят об остальном.

КОРОТКО

Короткий ответ

Объединяйте в таком порядке: сначала возьмите под контроль учётные записи, доступы и мониторинг в обеих компаниях; затем следите, чтобы деньги и данные клиентов оставались верными; то, что видят клиенты, меняйте последним. По каждой системе решайте отдельно: оставить её в стороне, связать, влить в одну или заменить обе. Решайте исходя из того, как бизнес зарабатывает, а не из того, какой стек уже есть у покупателя. План начинается до подписания, потому что самые дорогие провалы на памяти рынка начинались с даты, назначенной раньше, чем кто-то прочитал системы.

ИТ-интеграция после слияния идёт сразу на трёх горизонтах: День 1, когда ничего нельзя сломать; первые 100 дней, когда вы узнаёте, что купили, и выбираете; и консолидация, которая в крупной компании занимает годы. Marriott держал системы Starwood отдельно, и злоумышленник, уже сидевший в них, оставался там ещё два года. TSB за один уикенд перевёл пять миллионов клиентов на новую платформу, а платформа не была готова. Один покупатель оставил системы порознь, другой свёл их вместе, и оба пришли к регуляторам, так что вывод не может звучать как «всегда делайте то или другое».

Полного кейса интеграции после покупки мы не публиковали и не станем намекать на обратное. Показать мы можем ту же работу вне сделок: связь CRM и складов, приём систем от прежнего подрядчика, обновление старых стеков, перенос сайтов с аккаунтов, которых мы не контролировали. Эти проекты упомянуты по ходу текста, у каждого указано, чем он был. Сторону сделки представляет Валерия Чумаченко, она ведёт наши проверки технического дью-дилидженс и работает в сделках с технологическими компаниями больше десяти лет.

Всё это труднее, чем может показаться из любого руководства. Настоящая интеграция требует людей с долгим опытом в M&A, иногда лицензированных, и аналитиков, которые понимают чужой код сверху донизу, а команды бывают большими. Это не бесплатно, не быстро и не просто. Если ваш вопрос касается только сайта, ответ есть в статье Валерии Что происходит с сайтом после покупки компании?, а здесь речь обо всём, что стоит за ним.

ДВА ДЕЛА

Два провала в открытых документах

Marriott объявил о покупке Starwood за $12,2 млрд в ноябре 2015 года и закрыл сделку в сентябре 2016-го. Согласно жалобе FTC, десять месяцев между этими датами компания изучала безопасность Starwood, а затем начала двухлетний процесс включения части систем Starwood в свою сеть. Злоумышленники находились в сети Starwood с июля 2014 года. Они оставались там до сентября 2018-го, вредоносный код нашёлся более чем в 480 системах в 58 точках, а сам Marriott оценил число затронутых записей о гостях в 339 миллионов. Постановление о штрафе британского регулятора от октября 2020 года назначило £18,4 млн, и только за месяцы после вступления в силу GDPR. По предписанию FTC, окончательно утверждённому в декабре 2024 года, компании подтверждают его соблюдение ежегодно в течение 20 лет.

TSB устроен наоборот. В марте 2015 года Banco Sabadell предложил за британский банк £1,7 млрд, и в документе оферты обещал около £160 млн ИТ-экономии в год за счёт перевода TSB на собственную платформу Sabadell. За выходные с 20 по 22 апреля 2018 года переехали около пяти миллионов клиентов. Отчёт Slaughter and May, заказанный советом директоров TSB, описывает интернет-банк и мобильное приложение в следующие дни как «нестабильные и почти непригодные к использованию». Итоговое уведомление FCA фиксирует: к обычной работе TSB вернулся только 10 декабря 2018 года, получил 225 492 жалобы и выплатил £32,7 млн компенсаций. FCA и PRA вместе оштрафовали банк на £48,65 млн в декабре 2022 года.

Две оговорки. TSB, как отмечает FCA, не согласился с выводами Slaughter and May в ряде ключевых пунктов. И обе компании намного крупнее большинства читателей этой статьи; мы берём их потому, что документы открыты, а механизмы повторяются при любом масштабе.

ДО ПОДПИСАНИЯ

Интеграция начинается до подписи

К 1 июля 2015 года, на следующий день после того, как оферта стала безусловной, Sabadell уже назначил дату запуска: воскресенье, 5 ноября 2017 года. Slaughter and May отмечает, что ожидание закончить к концу 2017-го сложилось «без детального знания требований TSB» и что привычка сначала задавать желаемую дату, а потом строить под неё план сохранилась до конца программы.

Цифра синергии в предложении о покупке остаётся гипотезой о системах, которые никто на стороне покупателя ещё не открывал. Её должны проверить те, кто будет её выполнять, пока покупатель ещё может изменить цену или условия.

Есть и юридический предел. До закрытия две компании остаются независимыми. Разъяснение FTC об обмене информацией до слияния предупреждает, что обмен конкурентно чувствительными данными может стать частью незаконного gun jumping, то есть объединения раньше времени, и советует сторонних консультантов и чистые команды: небольшие проверенные группы видят то, что бизнесу видеть нельзя, и передают только обезличенные выводы. Планировать вместе можно, управлять чем-либо вместе нельзя; где проходит граница в вашей юрисдикции, решает юрист. Доступ бывает скудным и по обычным причинам: Marriott сообщил британскому регулятору, что смог провести лишь ограниченную проверку систем данных Starwood.

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

Цифра синергии: гипотеза о системах, которые ещё никто не открывал.

ТРИ ГОРИЗОНТА

День 1, 100 дней, длинная дорога

У Дня 1 одна цель: не ломается ничего, на что опираются клиенты и сотрудники. Счета уходят, зарплата начисляется, заказы отгружаются, поддержка отвечает. В этот же день покупатель принимает ключи: кто держит права администратора, кто может менять DNS, кому звонят в три часа ночи. Крупные видимые изменения ждут, а заморозка рискованных релизов на время закрытия обходится недорого.

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

В долгой консолидации и лежит экономия, а её длительность обычно недооценивают. Marriott планировал на интеграцию сети 18 месяцев, а нужные системы Starwood выключились примерно через 27 месяцев после закрытия. Программа TSB шла с 2015 года до апреля 2018-го, и ещё до декабря сервис возвращался к норме. Ваша компания, вероятно, меньше, но каждый из этих планов казался разумным серьёзным людям в день, когда его писали.

TSA

Системы продавца, со счётчиком

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

Опубликованные сроки расходятся. BDO India со ссылкой на Gartner в октябре 2026 года называет типичным TSA на 17 месяцев; Deloitte в Швейцарии писал в 2021 году, что команды часто закладывают от 8 до 12 месяцев и больше на всю ИТ-функцию. Обычно ломаются три вещи:

• Лицензия этого не позволяет. Программы, которые продавец лицензировал для внутреннего использования, могут не покрывать обслуживание бизнеса, которым он больше не владеет. Mayer Brown отмечает, что крупное выделение бизнеса может потребовать сотен таких согласий, так что соглашение должно указывать, кто их получает и оплачивает.
• Объём покрывает работу, но не уход. L.E.K. Consulting разделяет услуги продолжения работы и помощь в переходе, то есть разовый перенос данных и передачу знаний.
• Продление случается по умолчанию, потому что ни одна сторона не следила за движением к выходу, и обычно по более высокой цене.

TSB показывает, что растущий счётчик делает с планом. Его соглашения с прежним владельцем, Lloyds, предусматривали базовую плату около £92 млн в год с ростом примерно до £187 млн с 2017 года. Операционный директор группы Sabadell сообщил авторам отчёта, что около £130 млн из обещанных £160 млн экономии давали уход с этой платформы и отказ от роста платы. Так у каждого месяца задержки появилась цена, и давление работало в ту же сторону, что и дата.

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

ЧЕТЫРЕ РЕШЕНИЯ

Оставить, связать, влить, заменить

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

Ловушка кроется во фразе «у нас для этого уже есть платформа». У Sabadell она была, и, по данным Slaughter and May, на неё уже перевели двенадцать банков. Но британская программа, по словам отчёта, означала переход на платформу, по сути новую, с более чем 70 сторонними поставщиками, и TSB не оценил, насколько применим прежний опыт. Собственный стек подсказывает, что дёшево использовать повторно. На вопрос, помещается ли в него купленный бизнес, он не отвечает.

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

Вот проекты за каждым решением. Ни один не был покупкой компании; каждый показывает решение в чистом виде.

Связать. Для клиента из электронной коммерции, у которого продажи шли в Salesforce, а склад в отдельной системе, мы построили собственный слой, синхронизирующий заказы в обе стороны; ни одна система не была сломана, поэтому ни одну не заменили. Наша платформа для Honda связана с внутренними CRM и складскими системами бренда; запущенная в 2019 году, она работает до сих пор, и её поддерживает наша команда. В проекте FIAT задача была в том, чтобы наличие и запись на сервис работали и тогда, когда CRM дилера присылает обновление. Как строить такие связи, рассказано в статье Как связать CRM, сайт, склад и учёт, чтобы данные не расходились.

Оставить и обновить. Магазин Trichocosmetics работал на PHP 5.6. Мы перевели его на OpenCart 3.0.5.1 и PHP 8.4 и обновили модули и интеграции, не перестраивая его заново. Унаследованные системы заслуживают такого же взгляда, прежде чем их спишут; проверка описана в статье ИИ-проект застрял на старой системе?

Влить в стандартное решение. Клиент из сферы профессиональных услуг был уверен, что ему нужна собственная CRM. Мы разобрали его трёхэтапный процесс продаж и рекомендовали настроенный HubSpot: две недели настройки вместо месяцев разработки.

Заменить. Магазин LavShash был построен на Magento прежним подрядчиком. Мы начали с бизнес-логики, с того, как формируются цены по регионам и доставка по городам, и пересобрали его на Laravel вокруг этих правил; в первый год клиент сэкономил около $17 000 по сравнению с работой магазина на Magento. Позже планы клиента изменились, и проект приостановлен, о чём рассказывает страница кейса. Большую систему другого клиента на PHP 5.3 мы полностью перестраиваем, потому что обновление перетащило бы с собой все старые обходные решения.

По распространённым системам мы бы начали разговор отсюда:

ПОРЯДОК

Сначала доступы, витрина последней

Что бы вы ни выбрали по каждой системе, работа идёт примерно в таком порядке, потому что каждый слой защищает следующий:

1. Учётные записи и доступы. Перечислите все админские аккаунты, общие пароли, API-ключи и логины подрядчиков в обеих компаниях. Уберите то, что никто не может объяснить, смените ключи, включите многофакторный вход. Переведите домены, репозитории и облачные аккаунты на имя компании.
2. Видимость. Логи критичных систем в одном месте, оповещения человеку, который отвечает, и проверка восстановления из бэкапов, потому что непроверенный бэкап остаётся обещанием, которое никто не проверял.
3. Деньги. Счета, платежи, учёт и зарплата должны быть верными каждый день, поэтому их меняют поздно и осторожно, с ежедневным сравнением старого и нового.
4. Данные клиентов. Решите, какая система владеет каждой записью, потом объединяйте. Они идут после денег, потому что дубль клиента раздражает, а неверный счёт становится спором.
5. Операции. Склад, логистика, внутренние инструменты, подключаемые по одному.
6. Видимая витрина. Сайт, приложения, бренд. Она идёт последней, хотя генеральный директор хочет её первой, потому что редизайн поверх систем в движении делают дважды. У переноса сайта свои ловушки, они описаны в статье Чек-лист миграции сайта, который пропускают большинство агентств.

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

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

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

Неверный логотип поправят в понедельник. Неверный счёт приводит юриста.

НАСЛЕДСТВО

Считайте, что внутри уже кто-то есть

Самое полезное в постановлении по Marriott касается системы, которая уже уходила. Marriott утверждал, что систему Starwood собирались выводить из работы, поэтому более серьёзные меры не требовались. Вывод планировался на первый квартал 2018 года и сдвинулся на конец того же года. Регулятор ответил: запланированное отключение может влиять на то, какие меры разумны, но «не снимает основной обязанности» защищать данные, пока они используются.

Старая система остаётся вашей ответственностью, пока работает. ICO назвал четыре главных провала: слабый мониторинг привилегированных аккаунтов, слабый мониторинг баз данных, слабый контроль критичных систем и пробелы в шифровании. Улучшения, сделанные Marriott после покупки, по его выводу, не поймали «существенные и легко обнаружимые» недостатки. Защита по договору работает между покупателем и продавцом. Как заметили Simmons & Simmons, дью-дилидженс и заверения не спасли Marriott от штрафа.

Для покупателя отсюда следуют практические шаги в первые недели:

• Исходите из того, что купленная компания может быть уже скомпрометирована, и закажите проверку именно на это. Проверка безопасности в дью-дилидженс смотрит на практики; эта ищет следы чужого присутствия.
• Держите сети раздельно до окончания этой проверки. Разделение здесь помогло Marriott: ICO фиксирует, что атака не дошла до основной сети компании.
• Сразу поставьте мониторинг на старые системы, как бы скоро их ни собирались выключить, назначьте дату вывода и ответственного за неё.
• Держите план на случай инцидента с именами людей из обеих компаний и отрабатывайте его. Сценарии TSB, как отмечает FCA, покрывали только первые 48 часов.

Обычные пути проникновения проще, чем ожидают многие; мы разбираем их в статье Как взламывают сайты компаний и что исправить в первую очередь?

ДАННЫЕ И СОГЛАСИЕ

Перенести записи, сдержать обещания

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

Нагрузочное тестирование шло на одном дата-центре из двух, так что проблема конфигурации между ними не могла проявиться. Целевые показатели снижали после неудачных тестов, и сводка этого ясно не показывала. Совет директоров слышал о «примерно 800» открытых дефектах, а реальное число было минимум в два с половиной раза больше. После запуска, добавляет FCA, TSB не мог откатиться на старую платформу. Отчёт также говорит, что миграция одним событием самый быстрый, дешёвый и наименее сложный путь и при нужных страховках не обязательно была бы ошибкой. Значит, выбирать её надо сознательно. В любой миграции мы бы настаивали на следующем:

• Репетируйте на закрытой копии. Обновления мы делаем на временной копии, закрытой снаружи, с обезличенными данными и без реальных записей клиентов. Повторяйте весь прогон там, пока он не уложится в срок.
• Тестируйте при пиковой нагрузке на реальной конфигурации и письменно сообщайте об изменении целей тому, кто решает о запуске.
• Сверяйте. Количества и суммы, старое против нового, с человеком, который подписывается под расхождением; наша статья об интеграциях объясняет ночной вариант.
• Не теряйте ничего на лету. На нашем сайте каждая заявка пишется в лог до отправки письма, поэтому сбой почты её не потеряет.
• Знайте путь назад. Если его нет, скажите об этом совету и заранее подготовьте дополнительную поддержку.

Дальше вопрос, можно ли это делать вообще, потому что обещание о приватности переезжает вместе с данными. Когда Facebook покупал WhatsApp, FTC написала обеим компаниям, что WhatsApp должен выполнять свои обещания независимо от сделки и что им нужно явное согласие перед существенным изменением использования уже собранных данных. Это одно письмо об одной сделке в США, но логика переносится: прочитайте политику конфиденциальности, с которой согласился клиент, и спросите, вписывается ли в неё ваш план. Рассылку по купленной базе о ваших продуктах или загрузку её в ваши модели должен увидеть юрист. В ОАЭ федеральный закон № 45 от 2021 года запрещает обработку без согласия, с исключениями, в DIFC действует свой закон, а для европейских клиентов добавляется GDPR. И оставьте то, что не нужно: предписание FTC требует от Marriott хранить персональные данные лишь столько, сколько разумно необходимо.

КЛЮЧЕВЫЕ ЛЮДИ

Знания, которые могут уволиться

Сделки меняют работу людей в тот момент, когда нужна их память. Лучшие данные, которые мы нашли, это исследование Дж. Дэниела Кима, о котором MIT Sloan рассказал в 2019 году. По данным переписи США о 4 000 покупок высокотехнологичных стартапов с 1990 по 2011 год, 33% перешедших сотрудников ушли в первый же год, против 12% обычных новых сотрудников с похожими навыками. Это стартапы и прошлый период, так что читайте это как направление. Отчёт 2014 года о старой платформе TSB предупреждал о «высоком риске зависимости от ключевых людей в некоторых критичных старых приложениях». В компании из сорока человек таким риском может быть один разработчик, который знает, почему задача биллинга запускается дважды в последний день месяца.

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

Код пришёл со сделкой. Причины, стоящие за ним, могут уйти в марте.

СТОИМОСТЬ

Почему цифры синергии сползают

Вот счёт TSB рядом с обещанием. Сравнение не прямое, потому что экономия должна была повторяться каждый год, а расходы разовые, но оно показывает масштаб того, что может не войти в расчёт экономии.

TSB показал убыток £105,4 млн за 2018 год против прибыли £162,7 млн годом раньше. Исследования указывают туда же, хотя консультанты продают эту работу. Bain писал в июне 2019 года, что 70% интеграций процессов и систем проваливаются в начале, а не в конце, что расходы превышают оценки на величину от 20% до 50% и что у худших компаний ИТ-расходы в доле от выручки в два-три раза выше, чем у лучших. Выборки для 70% страница не называет, так что считайте это опытом самой фирмы.

Сползание чаще всего идёт от строк, которых нет в модели:

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

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

Так мы работаем там, где результат несём сами. В Schoeffel, жемчужном доме, основанном в 1921 году, мы стратегический партнёр и владеем долей компании. Когда строишь бизнес по-взрослому, просчитываешь сценарии его возможного развития, и будущая сделка заложена как один из них: цель в том, чтобы компания стоила не десятки миллионов, а сотни, и чтобы всё было готово, когда владельцу понадобится выход. Это цель и незавершённая работа, а не кейс покупки или интеграции. Мысль, стоящая за этим, изложена в статье Цифровая архитектура: как построить систему, что растёт вместе с бизнесом.

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

Предложения в последние месяцы приходят и самому Peretz. В качестве эксперимента мы упаковали собственный бизнес так, как его пришлось бы принимать команде покупателя, с обновлением до Laravel 13 и PHP 8.4 и документами о правах на код, о которых шла речь выше. Это был эксперимент, а не продажа.

МАЛЫЕ СДЕЛКИ

Что может пропустить небольшая покупка

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

Вот что нельзя пропустить даже в самой маленькой сделке:

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

Небольшая сделка пропускает церемонии и сохраняет порядок. Если прежний разработчик ушёл или доступы неполны, начните с аудита в услуге «Приём проекта от другого подрядчика»: по состоянию на ноябрь 2026 года он стоит от $2 500.

КОМАНДА

Кто это делает и сколько это занимает

Настоящая интеграция требует сразу нескольких видов людей. Руководитель интеграции с долгим опытом в M&A, иногда лицензированный, держит план и может сказать «нет» дате. Аналитики читают код и данные купленной компании сверху донизу, без их авторов в комнате. Дальше специалисты по безопасности, инженеры и инженеры данных, тестировщики, которые сообщают о нагрузочных тестах как есть, владелец от бизнеса по каждой системе, который решает, что значит «правильно», и юрист.

Здесь уместен один урок TSB. Slaughter and May считает, что совету следовало взять независимого советника по всей программе. Так что относитесь к собственному ИТ-подразделению покупателя как к поставщику и держите за столом человека, которому «да» ничего не приносит.

Сроки зависят от того, что вы найдёте. Диапазоны в разделе вопросов ниже отражают наш взгляд на планирование, и уточнить их может только проверка реальных систем.

Оценка и ремонт разные вещи. По состоянию на ноябрь 2026 года наша Сессия технического дью-дилидженс стоит $1 500, полная проверка начинается от $7 500, с ценой по объёму бизнеса; Discovery-фаза проекта начинается от $4 000. Каждая из них даёт оценку и направление. У работы по интеграции, которая следует дальше, честной начальной цены нет, потому что сначала мы должны увидеть системы. Если нужен старший человек, который держит всё вместе на часть времени, CTO по подписке стоит от $3 500 в месяц примерно за день в неделю, разработка считается отдельно.

Команды бывают большими, и здесь у нас настоящее преимущество. Всё, что мы делаем, это аутсорсинг или аутстаффинг, из большой базы проверенных разработчиков европейского происхождения по адекватным ценам, поэтому выделенную команду можно собрать на те месяцы, которых требует миграция. Для Neon AI мы предоставляем команды разработчиков на Python больше шести лет, как рассказано в статье Аутсорсинг, аутстаффинг или выделенная команда; это работа команд, а не интеграция после сделки. То, что мы строим, собрано вокруг бизнес-логики клиента и принадлежит клиенту, код и развёртывание передаются по договору, и это важнее обычного, когда у бизнеса только что сменился владелец.

ВОПРОСЫ

Частые вопросы

Как объединить ИТ-системы после покупки компании?

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

Сколько длится ИТ-интеграция после слияния?

По нашей оценке, месяцы для небольшой компании с немногими системами, год и больше для средней и годы для смены платформы в крупной. Запланированные у Marriott 18 месяцев превратились примерно в 27, прежде чем системы Starwood выключились.

Что такое соглашение о переходных услугах в ИТ?

Договор, по которому продавец продолжает оказывать ИТ-услуги проданному подразделению за плату и ограниченное время. Он типичен, когда из группы выделяют часть. Пишите его как план выхода: по каждой услуге ответственный, цена, дата выхода, цена после неё и период передачи знаний.

Стоит ли переводить купленную компанию на наши системы?

Только там, где это поддерживает бизнес-логика. Своя платформа показывает, что дёшево использовать повторно, но не то, подходит ли она купленной компании. Учётные записи обычно переходят рано, CRM можно просто связать, а основной продукт часто долго оставляют и защищают.

Кто отвечает за взлом, начавшийся до сделки?

С момента закрытия этими системами управляет новый владелец, и регуляторы обращаются к компании, которая держит данные. ICO оштрафовал Marriott за месяцы после вступления GDPR в силу из-за атаки на Starwood, начавшейся в 2014 году. Что можно взыскать с продавца по договору, спросите юриста.

Источники

• Управление комиссара по информации Великобритании (ICO): постановление о штрафе Marriott International, 30 октября 2020
• Федеральная торговая комиссия США (FTC): жалоба по делу Marriott International и Starwood, 2024
• Управление по финансовому регулированию Великобритании (FCA): итоговое уведомление TSB Bank plc, 20 декабря 2022
• Slaughter and May: независимая проверка миграции TSB 2018 года, 31 октября 2019
• Bain & Company: Process and Systems Integration, a New Source of Competitive Advantage, 12 июня 2019