Racionalización de la cartera tras fusiones y adquisiciones

El sistema de facturación de la empresa objetivo se marcó como redundante en la tercera semana del proceso de integración. La empresa adquirente contaba con su propia plataforma de facturación, la entidad resultante no necesitaría dos, y el sistema de la empresa objetivo parecía duplicar funcionalidades. Se programó su retirada a los seis meses. Al quinto mes, el equipo de migración descubrió que el sistema de facturación de la empresa objetivo no solo generaba facturas, sino que contenía cuarenta años de lógica de cálculo de impuestos específica para cada jurisdicción en sesenta y tres países, integrada en programas COBOL que habían sido mantenidos por un equipo de desarrolladores que habían aceptado indemnizaciones por despido en el segundo mes. La plataforma de facturación de la empresa adquirente gestionaba dieciocho países. La decisión de retirada se revirtió, el equipo de desarrolladores tuvo que ser reconstruido con tarifas de contrato de emergencia y el cronograma de sinergia se extendió catorce meses.

La decisión de racionalización se basó en lo que el sistema parecía hacer. Debería haberse basado en lo que realmente hacía. Estos aspectos varían en cada cartera de aplicaciones, y son aún más distintos en aquellas que incluyen sistemas heredados con décadas de lógica empresarial acumulada, dependencias no documentadas y conocimiento institucional que solo existe en el código.

Por qué las fusiones y adquisiciones generan el imperativo de racionalización de la cartera.

Al fusionar dos empresas, es imprescindible racionalizar las aplicaciones de cada una para crear un holding unificado y consolidado. En ese entorno de alta presión, la capacidad de fusionar sistemas rápidamente determina la celeridad con la que la nueva entidad puede operar de manera eficiente.

La racionalización es imprescindible. Dos organizaciones que gestionaban sus propios sistemas ERP, CRM, HRMS, plataforma de facturación, suite de informes y almacén de datos, ahora cuentan con dos de cada uno. El coste combinado de mantener sistemas paralelos, licencias, infraestructura, soporte y la sobrecarga operativa de gestionar dos instancias de lo que debería ser una sola, es el principal factor que explica las sinergias de costes que justificaron el precio de adquisición. Los plazos de integración están contemplados en el modelo de la operación. El consejo de administración realiza un seguimiento de la consecución de las sinergias. No racionalizar los sistemas a tiempo no solo supone incumplir un objetivo financiero, sino que también pone en entredicho la lógica estratégica de la operación.

La mayoría de las empresas tienden a acumular una amplia cartera de aplicaciones de tecnología de la información con el tiempo, especialmente si crecen mediante fusiones y adquisiciones y no integran completamente las operaciones y los activos después de cada transacción. En su conjunto, muchas de estas aplicaciones pueden no estar alineadas con la estrategia general de fusiones y adquisiciones de la empresa; fueron creadas como soluciones puntuales y no necesariamente respaldan los objetivos empresariales y organizativos posteriores a la transacción.

La magnitud del problema se agrava con cada adquisición sucesiva. Una organización que ha crecido mediante adquisiciones en serie sin una integración rigurosa de su cartera tras la fusión arrastra la deuda técnica acumulada de cada operación que no ha asimilado por completo. La empresa grande promedio ejecuta más de 370 aplicaciones SaaS. Entre el 25 y el 30 por ciento de esas licencias no se utilizan o se utilizan muy poco. Se estima que las organizaciones dejan de percibir 19.8 millones de dólares anuales en licencias sin usar. Si a esto le sumamos la capa de aplicaciones heredadas, los programas COBOL, las personalizaciones propietarias de ERP y los sistemas de procesamiento por lotes de mainframe que no aparecen en las auditorías de licencias SaaS, la cartera que debe abordarse para su racionalización es sustancialmente mayor de lo que sugiere el inventario de SaaS.

Las tres brechas que provocan fallos en la racionalización

Las decisiones de racionalización que dan lugar a la prórroga de catorce meses no son fallos de ejecución, sino fallos de información. Tres lagunas de información específicas se repiten en los programas de racionalización posteriores a la fusión:

Brecha 1: Propósito declarado versus propósito real

El propietario de la aplicación describe la finalidad del sistema. Tras años o décadas de personalización acumulada, el sistema ofrece muchas más funcionalidades. Un CRM que gestiona las relaciones con los clientes también puede calcular las comisiones trimestrales, gestionar las excepciones de las cuentas más importantes y mantener la única copia de ciertos términos contractuales en un formato del que dependen los informes posteriores. Nada de esto figura en la descripción del propietario de la aplicación, ya que no estaba incluido en los requisitos originales. Se fueron implementando soluciones provisionales una a una, cada una resolviendo un problema inmediato sin actualizar la descripción del propósito del sistema.

El coste de descubrir la Brecha 1 tras la jubilación: reconstruir las funciones ocultas en el sistema de reemplazo, a menudo a un coste de emergencia, mientras la empresa opera sin ellas o con soluciones alternativas manuales.

Brecha 2: Dependencias no declaradas

La aplicación parece funcionar de forma independiente. Otros doce sistemas dependen de su salida. Esta dependencia nunca se documentó formalmente, ya que se estableció mediante un flujo de datos informal que un desarrollador configuró hace tres años para resolver un problema de generación de informes. El propietario de la aplicación desconoce esta dependencia. Los propietarios de los sistemas dependientes saben que reciben los datos, pero asumen que provienen del sistema de facturación sin saber qué programa los genera específicamente.

Dependencias que el inventario nunca incluyó: una aplicación parece desechable porque nadie identificó qué dependía de ella. El costo de descubrir la Brecha 2 después de la jubilación: doce sistemas fallan o se degradan de maneras que se remontan a una dependencia que debería haber estado en el análisis de racionalización, pero no lo estuvo.

Brecha 3: Subestimación del alcance de la migración de datos

El plan de migración de datos estima el esquema del sistema de destino basándose en la documentación actual. El esquema presenta cuarenta y siete variantes acumuladas a lo largo de cuarenta años de cambios en las reglas de negocio, de las cuales tres están documentadas y cuarenta y cuatro solo son visibles en el código del programa que lee y escribe los datos. El alcance de la migración de datos se define en función de las tres variantes documentadas y se completa según lo previsto. Tras la migración, los procesos que dependían de las cuarenta y cuatro variantes no documentadas fallan silenciosamente, generando resultados incorrectos que no se detectan hasta que un informe trimestral o una presentación regulatoria revelan la discrepancia.

El coste de detectar la Brecha 3 tras la migración incluye: análisis de la causa raíz, corrección de datos, reprocesamiento y, en sectores regulados, notificación a las autoridades reguladoras y medidas correctivas.

Las cinco decisiones de racionalización

Cada aplicación en una cartera combinada se corresponde con uno de los cinco resultados de racionalización. El marco de decisión se aplica tanto a las aplicaciones heredadas como a las modernas, aunque la evidencia requerida para tomar la decisión difiere significativamente:

Decisión	Definición	Cuando aplicar	Se requiere evidencia primaria
Guardar	Conservar en su forma actual, operada por la entidad combinada.	Funcionalidad única, sin equivalente en el resto del catálogo, calidad adecuada.	Mapeo de funciones empresariales, análisis de dependencias
Consolidar	Combinar la funcionalidad de ambas versiones del portafolio en una única instancia superviviente.	Ambas organizaciones desempeñan funciones equivalentes; una de ellas es superior.	Análisis de superposición funcional, evaluación de brechas de características, complejidad de la migración
Modernizar	Conservar la función empresarial, transformar la implementación técnica.	Se requiere funcionalidad, pero la calidad técnica es demasiado deficiente para mantenerla a largo plazo.	Métricas de calidad del código, puntuación de complejidad, evaluación de la deuda técnica
Reemplace	Retire la aplicación y sustitúyala por una alternativa comercial o nativa de la nube.	La funcionalidad es un bien básico; un producto estándar la cumple adecuadamente.	Disponibilidad de alternativas en el mercado, evaluación del nivel de personalización
Retirarse	Desmantelar sin reemplazo	La función es genuinamente redundante, no tiene lógica única ni consumidores activos.	Análisis de código muerto, mapeo de dependencias que confirma la ausencia de consumidores activos.

La decisión que parece ser de retirar pero en realidad es de mantener: una aplicación sin usuarios activos, con un bajo volumen de transacciones y sin consumidores finales visibles parece ser candidata a ser retirada. Si contiene lógica de negocio única, normas fiscales jurisdiccionales, rutinas de cálculo regulatorio y procesamiento de obligaciones contractuales que no se han replicado en ningún otro lugar, retirarla implica perder esa lógica de forma permanente. Este es el escenario del sistema de facturación del inicio de este artículo. La decisión parece obvia a partir del inventario; sin embargo, es errónea según las pruebas.

Requisito previo para el análisis estructural

La racionalización de aplicaciones durante las fusiones y adquisiciones implica la decisión de conservar, migrar, consolidar o retirar software, un aspecto fundamental del modelo de transacción antes del cierre. Las licencias paralelas, las integraciones ocultas y la secuencia de retirada de software representan el verdadero costo.

Para tomar decisiones acertadas, se requiere evidencia estructural que va más allá de lo que los propietarios de las aplicaciones pueden aportar en las entrevistas, lo que registran los sistemas de gestión de activos de TI y lo que revelan las auditorías de licencias SaaS. En el caso de la capa de aplicaciones heredadas (sistemas COBOL, programas por lotes personalizados, middleware propietario y aplicaciones empresariales basadas en bases de datos que llevan décadas en funcionamiento), la evidencia estructural solo existe en el código fuente.

Cuatro resultados del análisis estructural que requieren las decisiones de racionalización:

Inventario de lógica de negocio. ¿Qué reglas codifica la aplicación? No la descripción funcional proporcionada por su propietario, sino los cálculos específicos, las bifurcaciones condicionales, las reglas de validación y la lógica de transformación implementadas en el código del programa. Para los programas COBOL, esto implica analizar la DIVISIÓN DE PROCEDIMIENTOS para extraer la lógica IF/EVALUATE, las sentencias COMPUTE y las rutas de procesamiento condicional que implementan las reglas de negocio. Este inventario constituye la especificación que debe cumplir cualquier sistema de reemplazo o consolidación.

Análisis de dependencias. ¿Cuántas otras aplicaciones, programas o procesos dependen de los resultados de esta aplicación? Las dependencias son el principal indicador del riesgo de retirada: una aplicación con dependencias nulas puede retirarse sin problemas; una aplicación con dependencias del 50 % conlleva el riesgo de que su retirada provoque fallos en otros cincuenta sistemas. En entornos heredados, las dependencias incluyen no solo las llamadas directas a la API, sino también las dependencias de la fuente de datos, los consumidores de archivos VSAM compartidos, los flujos de trabajos JCL que invocan el programa y los procesos por lotes posteriores que leen sus conjuntos de datos de salida.

Porcentaje de código muerto. ¿Qué porcentaje del código de la aplicación es inaccesible desde cualquier ruta de ejecución en producción? El código muerto acumulado a lo largo de décadas de adiciones de funcionalidades y correcciones de errores aumenta la complejidad aparente de la aplicación y el costo aparente de la modernización. Identificar y excluir el código muerto del alcance de la racionalización proporciona una imagen más precisa de lo que realmente debe migrarse, consolidarse o reemplazarse.

Complejidad de la migración de datos. ¿Cuál es la estructura de diseño de registros de cada conjunto de datos que gestiona la aplicación? ¿Cuántas variantes de REDEFINES existen? ¿Qué campos COMP-3 requieren una asignación de tipo de destino que preserve la precisión? ¿Qué reglas de negocio rigen los datos de los que dependen los usuarios de la aplicación? Las respuestas determinan si la migración de datos es una simple conversión de esquema o un programa de transformación de datos que dura varios meses.

El cronograma de 100 días: Cuando la velocidad entra en conflicto con la minuciosidad

El plan de integración de 100 días es el referente del sector en cuanto a la velocidad de ejecución posterior a la fusión. Inversores, miembros del consejo de administración y consultores de gestión miden el éxito de la integración en función de este plazo. La presión por demostrar la consecución temprana de sinergias, por mostrar al mercado que la operación funciona, comprime todos los procesos, incluida la racionalización de las aplicaciones.

El conflicto entre la presión de los plazos y la exhaustividad del análisis es donde los programas de racionalización generan sus errores más costosos. Una organización que no puede completar un análisis estructural exhaustivo de su cartera combinada en 100 días se enfrenta a una disyuntiva: tomar decisiones de racionalización con información incompleta o incumplir el plazo y tener que responder preguntas sobre la ejecución de la integración.

La solución que han adoptado los compradores experimentados no consiste en comprimir el análisis, sino en secuenciar las decisiones:

Primera fase (días 1-30): Solo decisiones claras e inequívocas. Aplicaciones claramente redundantes sin lógica única, aplicaciones que se deben conservar sin candidatos para consolidación, aplicaciones que ya están programadas para su eliminación en la hoja de ruta de una organización. Estas decisiones no requieren un análisis estructural profundo, ya que el resultado es previsible. Tomarlas rápidamente demuestra el impulso de la integración sin el riesgo de tomar decisiones erróneas con información incompleta.

Segunda fase (días 31-90): Decisiones que requieren un análisis específico. Aplicaciones que parecen redundantes, pero cuya racionalización depende de evidencia estructural concreta: ¿existe una lógica de negocio única? ¿Cuál es el número de entradas? ¿Qué tan compleja es la migración de datos? El análisis estructural se encarga específicamente para las aplicaciones de esta categoría, concentrando los recursos en las decisiones donde el análisis modifica el resultado.

Ola 3 (días 91+): Decisiones que requieren un análisis exhaustivo. Aplicaciones cuya complejidad hace que las decisiones de racionalización a 90 días sean realmente inapropiadas, sistemas heredados con décadas de lógica acumulada, plataformas de datos compartidas que dan servicio a ambas organizaciones, programas por lotes de misión crítica cuyo comportamiento no se comprende del todo. Estas decisiones se posponen explícitamente con una justificación documentada, en lugar de apresurarse a tomar una decisión errónea.

Este enfoque de secuenciación concilia la presión del cronograma con el requisito de exhaustividad: las primeras fases demuestran el impulso; las fases posteriores protegen contra las decisiones erróneas catastróficas que generan extensiones de plazo de catorce meses.

Desinversión: El problema inverso

Las adquisiciones generan la necesidad de consolidar dos carteras en una sola. Las desinversiones generan el problema inverso: separar una cartera que se construyó como un todo integrado en dos carteras independientes que puedan operar cada una sin la otra.

En un contexto de desinversión, la empresa derivada (SpinCo) suele comenzar su nueva etapa con una cartera sobredimensionada compuesta por las aplicaciones existentes que utiliza exclusivamente y las que compartía con la empresa matriz (ParentCo), como las de recursos humanos y planificación de recursos empresariales (ERP). Mientras tanto, la empresa matriz suele quedarse con costes residuales derivados de las aplicaciones que eliminó junto con la SpinCo.

El reto de la racionalización de las desinversiones es fundamentalmente diferente al de las adquisiciones, porque primero hay que responder a la pregunta de la separabilidad: ¿puede esta aplicación funcionar de forma independiente o está integrada con el resto de la organización de manera que una separación clara resulte impracticable?

Un programa COBOL que da servicio a la unidad de negocio desinvertida, pero que lee de una base de datos compartida en un sistema central que también da servicio a la unidad de negocio restante, no se puede separar fácilmente. Las opciones de separación son: replicar la base de datos (con la complejidad de mantener la sincronización durante la transición), migrar el programa desinvertido a una nueva instancia de base de datos (con la complejidad de la migración de datos y el riesgo de divergencia de comportamiento) o continuar con el acuerdo de acceso compartido después de la separación (con la complejidad de gobernanza que supone que dos entidades independientes compartan la infraestructura de datos).

Cada una de estas opciones tiene diferentes implicaciones en cuanto a costos, riesgos y plazos. Ninguna puede evaluarse sin conocer con exactitud cómo el programa utiliza la base de datos compartida: qué tablas, qué campos, con qué patrones de acceso, volumen y frecuencia. Se trata de un análisis estructural del código heredado, no de una revisión de la documentación.

Código heredado en fusiones y adquisiciones: la dimensión que nadie tiene en cuenta

El problema de la racionalización del SaaS (qué aplicaciones conservar, qué contratos rescindir y qué proveedores consolidar) se resuelve eficazmente con las herramientas y los marcos de trabajo existentes. Sin embargo, la mayoría de las organizaciones no cuenta con herramientas equivalentes para la racionalización del código heredado.

Cuando tanto la empresa adquirente como la adquirida utilizan sistemas COBOL de mainframe para sus procesos de negocio principales, la decisión de racionalización requiere responder a preguntas que las entrevistas con los propietarios de las aplicaciones y los sistemas de gestión de activos de TI no pueden responder:

¿Qué programas COBOL son exclusivos de cada organización? El portafolio de mainframes del comprador y el del objetivo pueden tener funciones similares (ambos gestionan cuentas), pero difieren en su implementación (cada uno acumula décadas de reglas de negocio únicas). Identificar la verdadera superposición funcional requiere analizar los programas, no solo leer sus etiquetas.

¿Qué programas son de infraestructura compartida y cuáles son específicos de una unidad de negocio? Un programa de utilidad JCL, llamado por cuarenta programas en toda la organización, es de infraestructura compartida. Una rutina de cálculo COBOL, llamada por tres programas que dan servicio a una sola unidad de negocio, es específica de dicha unidad. El análisis de entrada de programas en el inventario combinado genera esta clasificación automáticamente.

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.

Este programa genera un resultado específico y auditable para cada jurisdicción que gestiona. Para su desmantelamiento, es necesario replicar cada cláusula WHEN y cada objetivo PERFORM subyacente en un sistema de reemplazo, o bien aceptar que el sistema de reemplazo generará resultados diferentes para algunas jurisdicciones. Ninguno de estos resultados es visible en el inventario de aplicaciones. Ambos son visibles en el código fuente COBOL.

¿Cuál es el alcance de la migración de datos para cada aplicación? Los datos asociados a una aplicación COBOL heredada se definen en entradas FD y copybooks que pueden haber acumulado múltiples variantes REDEFINES, campos COMP-3 que requieren mapeo con precisión y restricciones de validez integradas capturadas en nombres de condiciones de nivel 88. La migración de datos definida en función de la documentación en lugar del esquema real produce el error Gap 3.

¿Qué programas contienen código obsoleto que se puede excluir del alcance de la migración? El código obsoleto en programas heredados aumenta la complejidad aparente de la modernización o migración. Los programas con un 40 % de código obsoleto requieren el análisis y la migración de un 40 % más de código del que realmente exige el comportamiento en producción. Identificar el código obsoleto antes de definir el alcance de la migración reduce las estimaciones de esfuerzo y mejora la precisión del cronograma.

Lista de verificación para la toma de decisiones en la racionalización de carteras de fusiones y adquisiciones

Para cada solicitud incluida en el ámbito de aplicación, se requiere la siguiente evidencia antes de que se pueda tomar una decisión de racionalización con confianza:

Evaluación de la lógica empresarial

• ¿Se ha verificado el funcionamiento real de la aplicación mediante análisis de código, y no solo mediante entrevistas con el propietario?
• ¿Están todas las reglas de negocio integradas en el código documentadas de forma que la sustitución deba coincidir con ellas?
• Para los programas COBOL: ¿se han inventariado todas las ramas EVALUATE, las condiciones IF y las sentencias COMPUTE?

Evaluación de dependencia

• ¿Se ha medido estructuralmente el ángulo de entrada (no se ha estimado por el propietario de la aplicación)?
• ¿Se enumeran todas las dependencias de la fuente de datos, tanto a nivel de JCL como a nivel de archivo y a nivel de base de datos?
• ¿Se han rastreado las dependencias dinámicas de las llamadas, y no solo las aristas estáticas del gráfico de llamadas?

evaluación de la migración de datos

• ¿Se ha extraído el diseño completo del registro de las entradas FD y los miembros COPY?
• ¿Se han identificado todas las variantes de REDEFINES y se han documentado las condiciones que las caracterizan?
• ¿Se han asignado todos los campos COMP-3 y binarios a tipos de destino con la precisión adecuada?

Evaluación de código muerto

• ¿Se ha identificado el código obsoleto y se ha excluido de las estimaciones del alcance de la migración?
• ¿Las decisiones de retirada se confirman mediante el análisis de código muerto (cero entrada desde las rutas de ejecución de producción)?

Clasificación de riesgos

• ¿Se ha verificado la puntuación de criticidad de la aplicación con respecto a los resultados del análisis estructural?
• ¿El cronograma de retención, migración o retiro es coherente con la complejidad de las dependencias?

Cómo SMART TS XL Apoya la racionalización de la cartera de fusiones y adquisiciones.

SMART TS XL Proporciona la base estructural para las decisiones de racionalización que no pueden tomarse correctamente basándose únicamente en la documentación y las entrevistas.

La capacidad de análisis de código estático extrae el inventario de lógica de negocio de COBOL, JCL, Java, Python y cualquier otro lenguaje presente en los portafolios de ambas organizaciones, ofreciendo una visión completa de la funcionalidad de cada aplicación, más allá de su nombre. Para programas COBOL como el ejemplo de cálculo de impuestos mencionado anteriormente, este análisis enumera cada jurisdicción, cada condición de regla y cada rama de cálculo que una aplicación de reemplazo debe implementar para obtener resultados equivalentes.

El mapeo de dependencias de aplicaciones proporciona el análisis de ramificación y dispersión que determina el riesgo de retirada y la secuencia de consolidación. Para las carteras de ambas organizaciones analizadas simultáneamente, el mapa de dependencias muestra qué programas son verdaderamente independientes, cuáles están profundamente integrados en una infraestructura compartida y cuáles conllevan las dependencias ocultas que dan lugar a los fallos de la brecha 2.

La capacidad de análisis de impacto permite comprobar cada decisión de racionalización propuesta antes de su ejecución: si se retira este programa, ¿qué otros programas pierden una dependencia? Si se migra este conjunto de datos, ¿qué programas deben actualizarse para leer desde la nueva ubicación? El alcance del impacto de cada decisión propuesta se puede cuantificar a partir del modelo estructural, lo que convierte las decisiones de racionalización, desde las estimaciones de riesgo hasta los planes definidos y con alcance delimitado.

El análisis de modernización de sistemas heredados produce una puntuación de complejidad y una identificación de código muerto que hacen que las estimaciones de esfuerzo sean precisas: los programas en el cuartil inferior de complejidad con un alto porcentaje de código muerto son candidatos sólidos para ser retirados o modernizados; los programas en el cuartil superior de complejidad con un alto fan-in son candidatos para ser mantenidos independientemente de la redundancia aparente.

La capacidad de búsqueda empresarial permite consultar la cartera combinada a lo largo de todo el programa de racionalización: encuentre en segundos todos los programas que acceden a un conjunto de datos específico, todos los programas que implementan una función empresarial específica, todos los programas COBOL con una complejidad ciclomática superior a un umbral, a través de los millones de líneas de código combinadas de ambas organizaciones.

Para las organizaciones que llevan a cabo una racionalización bajo presión de tiempo, SMART TS XLEl análisis automatizado reduce el tiempo necesario para el análisis estructural: el mapa completo de dependencias, el inventario de lógica de negocio y la puntuación de complejidad para una cartera combinada se pueden generar en días, en lugar de las semanas o meses que requeriría una revisión manual del código. Esta reducción es lo que hace viable el enfoque de secuenciación Wave 1 / Wave 2 / Wave 3; el análisis estructural específico para las aplicaciones Wave 2 se puede completar dentro del plazo de 90 días que permite el cronograma.

La decisión que tomes será tan buena como las pruebas que la respaldan.

La racionalización de la cartera tras una fusión se lleva a cabo bajo una presión real de tiempo, una presión financiera real y una presión organizativa real para demostrar que la operación funciona. Todas estas presiones impulsan a tomar decisiones más rápidas. Ninguna de ellas cambia el coste de tomar una decisión equivocada.

El sistema de facturación que estaba programado para ser retirado y luego reactivado a un costo de emergencia no es una advertencia sobre actuar con demasiada lentitud. Es una advertencia sobre actuar sin la evidencia que habría cambiado la decisión. El análisis estructural que revela lo que realmente hace un sistema, su lógica de negocio integrada, sus dependencias ocultas, su complejidad de migración de datos, no ralentiza la racionalización. La hace precisa. Y la precisión, en el contexto de un programa de integración posterior a una fusión donde las decisiones erróneas generan extensiones de plazo de dieciocho meses y sobrecostos de nueve cifras, es la propiedad más valiosa que puede tener una decisión de racionalización.

La racionalización de cartera que tiene éxito no es la más rápida, sino la que sabe qué es lo que está racionalizando.