Як об’єднати ІТ-системи двох компаній після купівлі: порядок дій і що йде не так

Угоду підписано, юристи розійшлися. Лишаються два набори логінів, дві системи обліку, дві бази клієнтів і цифра економії, яку хтось пообіцяв раді директорів. Ось порядок, який витримує навантаження, рішення, яке треба ухвалити щодо кожної системи, і те, що два публічні провали кажуть про решту.

КОРОТКО

Коротка відповідь

Об’єднуйте в такому порядку: спочатку візьміть під контроль облікові записи, доступи й моніторинг в обох компаніях; потім стежте, щоб гроші й дані клієнтів лишалися правильними; те, що бачать клієнти, змінюйте останнім. Щодо кожної системи вирішуйте окремо: залишити її осторонь, зв’язати, влити в одну чи замінити обидві. Вирішуйте виходячи з того, як бізнес заробляє, а не з того, який стек уже є в покупця. План починається до підписання, бо найдорожчі провали на пам’яті ринку починалися з дати, призначеної раніше, ніж хтось прочитав системи.

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

Повного кейсу інтеграції після купівлі ми не публікували й не натякатимемо на протилежне. Показати ми можемо ту саму роботу поза угодами: зв’язок CRM і складів, прийом систем від попереднього підрядника, оновлення старих стеків, перенесення сайтів з акаунтів, яких ми не контролювали. Ці проєкти згадані по ходу тексту, у кожного вказано, чим він був. Бік угоди представляє Валерія Чумаченко, вона веде наші перевірки технічного due diligence і працює в угодах з технологічними компаніями понад десять років.

Усе це важче, ніж може здатися з будь-якого посібника. Справжня інтеграція потребує людей з довгим досвідом в 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.

Тому due diligence має закінчуватися передачею справ, а не звітом у шухляді. Як проводити саму перевірку, розказано у статтях Як провести аудит сайту чи цифрового продукту перед покупкою і Чого побудова систем навчає про їх купівлю. Команда інтеграції має отримати від неї ось що:

Цифра синергії: гіпотеза про системи, які ще ніхто не відкривав.

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

День 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, due diligence і запевнення не врятували Marriott від штрафу.

Для покупця звідси випливають практичні кроки в перші тижні:

• Виходьте з того, що куплена компанія може бути вже скомпрометована, і замовте перевірку саме на це. Перевірка безпеки в due diligence дивиться на практики; ця шукає сліди чужої присутності.
• Тримайте мережі окремо до завершення цієї перевірки. Розділення тут допомогло Marriott: ICO фіксує, що атака не дійшла до основної мережі компанії.
• Одразу поставте моніторинг на старі системи, хоч би як скоро їх збиралися вимкнути, призначте дату виведення і відповідального за неї.
• Тримайте план на випадок інциденту з іменами людей з обох компаній і відпрацьовуйте його. Сценарії TSB, як зазначає FCA, покривали лише перші 48 годин.

Звичайні шляхи проникнення простіші, ніж очікують багато хто; ми розбираємо їх у статті Як зламують сайти компаній і що виправити насамперед?

ДАНІ Й ЗГОДА

Перенести записи, дотримати обіцянок

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

Навантажувальне тестування йшло на одному дата-центрі з двох, тож проблема конфігурації між ними не могла проявитися. Цільові показники знижували після невдалих тестів, і зведення цього ясно не показувало. Рада директорів чула про «приблизно 800» відкритих дефектів, а реальне число було щонайменше у два з половиною рази більшим. Після запуску, додає FCA, TSB не міг відкотитися на стару платформу. Звіт також каже, що міграція однією подією найшвидший, найдешевший і найменш складний шлях і за потрібних страховок не обов’язково була б помилкою. Отже, обирати її треба свідомо. У будь-якій міграції ми б наполягали на такому:

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

Далі питання, чи можна це робити взагалі, бо обіцянка про приватність переїжджає разом із даними. Коли Facebook купував WhatsApp, FTC написала обом компаніям, що WhatsApp має виконувати свої обіцянки незалежно від угоди і що їм потрібна явна згода перед суттєвою зміною використання вже зібраних даних. Це один лист про одну угоду у США, але логіка переноситься: прочитайте політику конфіденційності, з якою погодився клієнт, і запитайте, чи вписується в неї ваш план. Розсилку за купленою базою про ваші продукти чи завантаження її у ваші моделі має побачити юрист. В Україні діє Закон «Про захист персональних даних», а для європейських клієнтів додається 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 року наша Сесія технічного due diligence коштує $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