
Вас насправді цікавить, який постачальник ERP виграє битву за домінування програмного забезпечення після злиття, або до якої CRM-системи ви перенесете інформацію про своїх клієнтів та обліковий запис?
Часто ці технологічні та додаткові запитання затьмарюють або заважають більш важливим діловим питанням, які визначають цінність сценарію злиття та поглинання. Хоча деякі люди захоплені своїм технологічним ландшафтом, найважливіше питання полягає в тому, як ви забезпечите бізнесу доступ до важливих даних та можливостей за межі компанії з 1-го дня або незабаром після цього.
Цей підхід, орієнтований на дані, вимагає фундаментального перегляду традиційного підходу, орієнтованого на ІТ Злиття та поглинання.
Перехід від додатків до даних
На першому етапі критично важливо визначити критичні дані за категоріями даних, включаючи, наприклад, дані про клієнтів, продажі або ланцюжки поставок. Часто важливість різних категорій даних різниться між галузями та секторами послуг, однак найважливіші дані завжди пов’язані з ключовим потоком вартості організації.
На наступному кроці слід визначити пріоритетні найвищі категорії даних та елементи даних, а також розглянути обмеження щодо обміну конкретними даними між компаніями до або після першого дня. Після того, як буде розроблено чітке розуміння того, які дані та можливості є критично важливими для бізнесу для досягнення цільових переваг після злиття у вигляді економії витрат та збільшення доходів, слід розробити зосереджену на даних проміжну архітектуру, яка забезпечує хмарний доступ до даних для всієї компанії межі. Частково спираючись на існуючі додатки та сховища даних, швидше за все, буде потрібно створити швидке розгортання хмарного рішення, яке підтримуватиме обмін даними якомога раніше на законних підставах. Така проміжна архітектура повинна забезпечувати можливості технологій бізнесу, наприклад для перегляду клієнтів на 360 °, перехресних продажів та видимості рахунку тощо.

Побудова надійних іт-можливостей злиття та поглинання
У сучасному бізнес-середовищі постійні поглинання, злиття та поглинання є скоріше нормою, ніж винятком. Тому надзвичайно важливо розробити можливості інтеграції, які можуть бути використані для майбутніх справ без серйозних коригувань внаслідок змін обставин. Такі орієнтовані на ІТ можливості злиття та поглинання та поглинання повинні використовувати хмарні можливості для зберігання даних, доступу, штучного інтелекту тощо. Хмарні провайдери, такі як AWS, Azure та інші, надають широкий спектр відповідних послуг “нестандартно”. Доповнення таких хмарних можливостей стандартними моделями доступу до даних та операційними процедурами дозволить створити платформу злиття та поглинання для обміну даними та співпраці, орієнтованої на дані, між компаніями.
Настав час розмістити дані в центрі іт-злиттів та поглинань
Для прискорення реалізації вартості у випадку поглинань та поглинань шляхом надання відповідних перехресних можливостей компанія має вирішальне значення для бізнесу. Легкий, хоча безпечний доступ до даних та інформації через межі компанії сьогодні є найчастіше найбільшою перешкодою для операцій після злиття та доставки вартості споживача.
Як професіоналам з ІТ-злиттів та поглинань, буде критично переглянути спосіб, яким ми підходимо до технологічної інтеграції бізнесу, поставивши дані в центр наших міркувань. Наявність даних та співпраця між компаніями мають вирішальне значення для прискорення процесу інтеграції, забезпечення підвищеного рівня задоволеності споживачів та збільшення ефективності та збільшення доходу. Таким чином, ІТ відіграватимуть вирішальну роль у забезпеченні інтеграції бізнесу, водночас домагаючись “традиційної” економії синергії, яка є результатом консолідації та оптимізації ІТ-процесів, програм та послуг.
Сьогодні перенесіть свій план злиття та поглинання з моделі, орієнтованої на застосування, на підхід, орієнтований на дані!
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/data-centric-ma-blueprint-rethinking-post-merger-integration-hanf/.
Michael Hanf люб’язно дозволив нам перекласти і опублікувати цю статтю.