Рационализация портфеля после слияний и поглощений

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

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

Почему слияния и поглощения создают необходимость рационализации инвестиционного портфеля?

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

Рационализация не является необязательной. Две организации, каждая из которых использовала собственную ERP-систему, CRM-систему, HRMS-систему, платформу выставления счетов, систему отчетности и хранилище данных, теперь имеют по два экземпляра всего этого. Совокупные затраты на поддержание параллельных систем, лицензирование, инфраструктуру, поддержку и операционные издержки на эксплуатацию двух экземпляров того, что в конечном итоге должно быть одним, являются основным фактором синергии затрат, оправдавшей цену приобретения. Сроки интеграции прописаны в модели сделки. Реализация синергии отслеживается советом директоров. Несоблюдение сроков рационализации не только не позволяет достичь финансовых целей, но и ставит под сомнение стратегическую логику сделки.

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

Масштаб проблемы увеличивается с каждым последующим приобретением. Организация, которая росла за счет последовательных приобретений без тщательной интеграции портфеля после слияний, несет накопленный технический долг каждой сделки, которую она не полностью освоила. Среднее крупное предприятие использует более 370 приложений SaaS. От 25 до 30 процентов этих лицензий не используются или используются значительно неэффективно. По оценкам, организации ежегодно теряют неиспользованные лицензии на сумму 19.8 миллионов долларов. Добавьте к этому устаревший уровень приложений, программы COBOL, собственные настройки ERP и пакетные системы мэйнфреймов, которые не фигурируют в проверках лицензий SaaS, и портфель, который необходимо оптимизировать, окажется значительно больше, чем предполагает сам перечень SaaS-приложений.

Три причины неудач в рационализации

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

Пробел 1: Заявленная цель против реальной цели

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

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

Пробел 2: Необъявленные зависимости

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

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

Пробел 3: Недооценка масштабов миграции данных

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

Затраты на выявление пробела 3 после миграции: анализ первопричин, корректировка данных, повторная обработка, а в регулируемых отраслях — уведомление регулирующих органов и устранение выявленных недостатков.

Пять решений по рационализации

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

Решение	Определение	Когда подать заявку	Необходимые первичные доказательства
Сохранить	Сохранить в текущем виде, под управлением объединенной организации.	Уникальная функциональность, аналогов в других линейках продукции, высокое качество.	Составление карты бизнес-функций, анализ зависимостей
Консолидировать	Объединить функциональность обеих версий портфолио в один работоспособный экземпляр.	Обе организации выполняют эквивалентные функции; одна из них превосходит другую.	Анализ функционального пересечения, оценка пробелов в характеристиках, сложность миграции.
осовременить	Сохраните бизнес-функцию, трансформируйте техническую реализацию.	Функциональность необходима, но техническое качество слишком низкое для долговременной эксплуатации.	Метрики качества кода, оценка сложности, оценка технического долга
Замените	Откажитесь от этого приложения, замените его коммерческой или облачной альтернативой.	Функциональность — это товар; стандартный продукт адекватно её выполняет.	Наличие альтернативных вариантов на рынке, оценка глубины индивидуализации.
Уход на пенсию	Вывести из эксплуатации без замены	Функциональность действительно избыточна, отсутствует уникальная логика, нет активных потребителей.	Анализ мертвого кода и отображение зависимостей подтверждают отсутствие активных потребителей.

Решение, которое выглядит как «Вывести из эксплуатации», но на самом деле является «Сохранить»: приложение без активных пользователей, с низким объемом транзакций и без видимых конечных потребителей, похоже, является кандидатом на вывод из эксплуатации. Если оно содержит уникальную бизнес-логику, правила налогообложения в соответствующей юрисдикции, процедуры расчета нормативных требований, обработку договорных обязательств, которые не были воспроизведены где-либо еще, вывод его из эксплуатации означает безвозвратную потерю этой логики. Это сценарий с биллинговой системой из начала этой статьи. Решение кажется очевидным из инвентаризации; оно ошибочно, судя по имеющимся данным.

Необходимое условие для проведения структурного анализа.

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

Для принятия таких решений необходимы структурные доказательства, выходящие за рамки того, что владельцы приложений могут предоставить в ходе интервью, записей в системах управления ИТ-активами и результатов аудита лицензий SaaS. Для устаревшего уровня приложений, систем COBOL, специально разработанных пакетных программ, проприетарного промежуточного программного обеспечения и бизнес-приложений, работающих на основе баз данных и функционирующих десятилетиями, структурные доказательства существуют только в исходном коде.

Четыре результата структурного анализа, необходимые для принятия решений о рационализации:

Инвентаризация бизнес-логики. Какие правила закодировано в приложении? Не функциональное описание, предоставленное его владельцем, а конкретные вычисления, условные ветвления, правила проверки и логика преобразования, реализованные в программном коде. Для программ на COBOL это означает анализ раздела PROCEDURE DIVISION для извлечения логики IF/EVALUATE, операторов COMPUTE и путей условной обработки, реализующих бизнес-правила. Эта инвентаризация представляет собой спецификацию, которой должна соответствовать любая заменяемая или объединяемая система.

Анализ зависимостей. Сколько других приложений, программ или процессов зависят от выходных данных этого приложения? Зависимости являются основным показателем риска вывода из эксплуатации: приложение с нулевым количеством зависимостей может безопасно завершить работу; приложение с пятьюдесятью зависимостями несет риск того, что его вывод из эксплуатации нарушит работу пятидесяти других компонентов. В устаревших средах зависимости включают не только прямые вызовы API, но и зависимости от потоков данных, потребителей общих файлов VSAM, потоки заданий JCL, которые вызывают программу, и последующие пакетные процессы, которые считывают ее выходные наборы данных.

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

Сложность миграции данных. Какова структура записей каждого набора данных, которым управляет приложение? Сколько существует вариантов REDEFINES? Какие поля COMP-3 требуют сопоставления целевых типов с сохранением точности? Какие бизнес-правила регулируют данные, от которых зависят пользователи приложения? Ответы на эти вопросы определяют, будет ли миграция данных простым преобразованием схемы или многомесячной программой преобразования данных.

100-дневный срок: когда скорость противоречит тщательности

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

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

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

Первая волна (дни 1-30): Только четкие и однозначные решения. Приложения, которые явно избыточны и не имеют уникальной логики, приложения, которые явно следует сохранить и для которых нет кандидатов на консолидацию, приложения, которые уже запланированы к выводу из эксплуатации в дорожной карте одной из организаций. Эти решения не требуют глубокого структурного анализа, поскольку результат не вызывает сомнений. Быстрое принятие таких решений демонстрирует импульс интеграции без риска принятия неверных решений на основе неполной информации.

Вторая волна (дни 31-90): Решения, требующие целенаправленного анализа. Приложения, которые кажутся избыточными, но обоснование которых зависит от конкретных структурных данных: существует ли уникальная бизнес-логика? Каково количество подключений? Насколько сложна миграция данных? Структурный анализ заказывается специально для приложений этой категории, при этом ресурсы концентрируются на решениях, где анализ меняет результат.

Третья волна (91+ дней): Решения, требующие расширенного анализа. Приложения, сложность которых делает принятие решений о рационализации в течение 90 дней действительно нецелесообразным, устаревшие системы с десятилетиями накопленной логики, общие платформы данных, обслуживающие обе организации, критически важные пакетные программы, поведение которых не до конца изучено. Эти решения откладываются с документально обоснованным объяснением, а не принимаются в спешке с неверным ответом.

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

Отчуждение активов: обратная проблема

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

В контексте продажи активов, SpinCo часто начинает свою новую жизнь с раздутым портфелем, состоящим из существующих приложений, используемых исключительно SpinCo, и приложений, которые она использовала совместно с ParentCo, таких как HR и ERP. В то же время, ParentCo часто остается с невозмещенными затратами на приложения, от которых она избавляется вместе со SpinCo.

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

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

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

Устаревший код в слияниях и поглощениях: аспект, который никто не учитывает

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

Когда и приобретающая, и целевая компании используют мэйнфреймовые системы на языке COBOL для обработки основных бизнес-процессов, решение о рационализации требует ответов на вопросы, на которые не могут ответить интервью с владельцами приложений и системы управления ИТ-активами:

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

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

кобол

      *> Target company's tax calculation -- 40 years of jurisdiction rules
      *> 63 countries, 847 tax rule conditions, embedded in this program
      *> Not documented anywhere except in this PROCEDURE DIVISION
       CALCULATE-TAX.
           EVALUATE WS-COUNTRY-CD
               WHEN 'US' PERFORM US-TAX-CALC
               WHEN 'UK' PERFORM UK-VAT-CALC
               WHEN 'DE' PERFORM GERMAN-MWST-CALC
               WHEN 'FR' PERFORM FRENCH-TVA-CALC
               *> ... 59 more WHEN clauses
               WHEN OTHER PERFORM DEFAULT-TAX-CALC
           END-EVALUATE.

Эта программа выдает конкретный, подлежащий аудиту результат для каждой обрабатываемой ею юрисдикции. Для ее вывода из эксплуатации требуется либо скопировать каждое условие WHEN и каждый базовый целевой объект PERFORM в новую систему, либо смириться с тем, что новая система будет выдавать разные результаты для некоторых юрисдикций. Ни один из этих результатов не виден в инвентаризации приложения. Оба видны в исходном коде COBOL.

Каков объем миграции данных для каждого приложения? Данные, связанные с устаревшим приложением COBOL, определены в записях FD и копибуках, которые могут содержать множество вариантов REDEFINES, поля COMP-3, требующие сопоставления с учетом точности, и встроенные ограничения допустимости, зафиксированные в именах условий 88-го уровня. Миграция данных, привязанная к документации, а не к фактической схеме, приводит к ошибке Gap 3.

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

Контрольный список для принятия решения по заявке на рационализацию портфеля сделок слияния и поглощения.

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

Оценка бизнес-логики

• Была ли проверена фактическая функциональность приложения посредством анализа кода, а не только путем опроса владельца?
• Все ли бизнес-правила, заложенные в коде, задокументированы в такой форме, чтобы их замена должна была им соответствовать?
• Для программ на COBOL: были ли учтены все ветвления EVALUATE, условия IF и операторы COMPUTE?

Оценка зависимости

• Были ли измерены структурные параметры вентиляционного типа (а не оценены владельцем приложения)?
• Перечислены ли все зависимости потоков данных на уровне JCL, файлов и баз данных?
• Были ли отслежены динамические зависимости вызовов, а не только статические ребра графа вызовов?

оценка миграции данных

• Была ли полностью извлечена структура записи из записей FD и элементов COPY?
• Были ли выявлены все варианты гена REDEFINES и задокументированы ли характерные для них условия?
• Все ли поля COMP-3 и бинарные поля сопоставлены с целевыми типами, соответствующими требуемой точности?

Оценка мертвого кода

• Был ли выявлен неиспользуемый код и исключен ли он из оценок объема миграции?
• Подтверждаются ли решения о выводе кода из эксплуатации анализом мертвого кода (отсутствие вложений из путей выполнения в производственной среде)?

Классификация риска

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

Как SMART TS XL Поддерживает рационализацию портфеля слияний и поглощений.

SMART TS XL обеспечивает структурный слой доказательств для решений по рационализации, которые невозможно принять корректно, основываясь только на документации и интервью.

Функция статического анализа кода извлекает перечень бизнес-логики из COBOL, JCL, Java, Python и всех других языков, используемых в портфелях обеих организаций, создавая полную картину того, что фактически делает каждое приложение, а не только то, что указано в его названии. Для программ на COBOL, таких как приведенный выше пример расчета налогов, этот анализ перечисляет каждую юрисдикцию, каждое условие правила и каждую ветвь расчета, которые должна реализовать замена для получения эквивалентных результатов.

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

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

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

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

Для организаций, проводящих оптимизацию в условиях жестких сроков, SMART TS XLАнализ, проводимый этим методом, сокращает сроки структурного анализа: полная карта зависимостей, перечень бизнес-логики и оценка сложности для объединенного портфеля могут быть получены за несколько дней, а не за недели или месяцы, которые потребовались бы при ручной проверке кода. Именно это сокращение делает жизнеспособным подход к последовательности Wave 1 / Wave 2 / Wave 3: целевой структурный анализ для приложений Wave 2 может быть завершен в течение 90-дневного периода, предусмотренного временными рамками.

Ваше решение будет настолько же обоснованным, насколько хороши доказательства, лежащие в его основе.

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

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

Успешная рационализация портфеля — это не самая быстрая, а та, которая точно знает, что именно она рационализирует.