La separación del ERP marca el calendario para todo lo demás
En resumen
El calendario de separación del ERP es lo que realmente marca el ritmo de una escisión corporativa. El departamento financiero no puede cerrar un libro mayor independiente. El departamento de compras no puede emitir sus propias órdenes de compra. El departamento de logística no puede realizar envíos a los clientes hasta que se haya completado el calendario de separación del ERP. Los equipos encargados de la operación suelen dimensionar el acuerdo de servicios de transición basándose en hipótesis de finanzas y recursos humanos. A continuación, tratan el calendario de separación del ERP como un detalle técnico que un integrador puede resolver bajo petición. Si la ruta de los sistemas se elige tarde, suele ser el calendario de separación del ERP el que fija la fecha real de salida, y no el contrato.
Por qué el calendario de la escisión del sistema ERP entra en conflicto con los acuerdos de servicios de transición (TSA)
La adquisición se ha completado. La empresa ha firmado el acuerdo de servicios de transición, que establece un plazo de doce meses para la salida de los servicios compartidos. Sobre el papel, el calendario de separación parece ordenado. Las líneas de trabajo de RR. HH., comercial, entidad jurídica y cadena de suministro cuentan cada una con sus propios hitos.
En los primeros sesenta días, la situación cambia. El departamento de Finanzas no consigue ultimar el plan de cuentas independiente. Nadie ha configurado el libro mayor. El departamento de Operaciones no puede emitir órdenes de compra independientes hasta que la base de datos de gestión de materiales se separe de la de la empresa matriz. El departamento de Logística no puede enviar los componentes terminados. El equipo no ha restablecido el enlace de intercambio electrónico de datos con la planta del cliente.
El calendario de la escisión del sistema ERP no es una línea de trabajo más entre otras. Marca el ritmo de todas las demás líneas de trabajo de la escisión. Pocos equipos de negociación lo tienen en cuenta a la hora de firmar el acuerdo.
Retos transfronterizos en la ejecución de una separación de activos de SAP
El calendario de separación del sistema ERP se complica considerablemente cuando las plantas de fabricación se encuentran en un país distinto al de la empresa matriz. Un caso habitual es que el vendedor aloje una instancia de SAP u Oracle desde una sede central en Alemania, Francia o Suiza, mientras que las plantas que realizan el trabajo se encuentran en Polonia, Chequia, Hungría o Rumanía.
Gestión de los datos maestros compartidos y riesgos de separación en el proceso de escisión de SAP
En un sistema integrado, los registros de materiales, proveedores y clientes se encuentran en tablas compartidas entre varias divisiones. Extraer una unidad de negocio no es una simple exportación. Un proveedor y una unidad cedida suelen compartir números de pieza de fundición, especificaciones de aleaciones o cuentas de clientes. Alguien tiene que separar los datos comerciales confidenciales sin alterar las listas de materiales históricas. Para ello se necesitan personas que conozcan la planta física, no solo la base de datos. Esta es precisamente la razón por la que el calendario de la separación del ERP se ralentiza primero aquí, antes de que cualquier otra línea de trabajo note el retraso.
Cumplimiento de la normativa local en materia legal y fiscal desde el primer día de la separación
Una entidad independiente en Europa Central no puede adoptar una única plantilla global y dar por sentado que se cumplirá la normativa. Las operaciones en Polonia necesitan un módulo de presentación de informes SAF-T que cumpla con la normativa. Las entidades checas tienen sus propias normas legales de amortización y declaraciones de control del IVA. Las filiales rumanas necesitan facturación electrónica certificada. Si el nuevo sistema ERP no puede generar estos documentos el día de la transición, la filial no podrá facturar ni enviar mercancías de forma legal.
Prevención de fallos en el intercambio electrónico de datos (EDI) y en la interfaz con el cliente
Los clientes de los sectores de la automoción y la industria aeroespacial aplican protocolos de entrega estrictos, como las normas alemanas VDA y europeas Odette. Es posible que el nuevo sistema no envíe un aviso previo de envío correcto. También puede generar una etiqueta de embalaje con un número de serie erróneo. Cualquiera de estos errores hace que un cliente de primer nivel rechace la entrega en la puerta de entrada. En ese caso, el cliente puede repercutir al proveedor el coste de la parada de la línea de producción.
Cómo identificar los primeros indicios de desviación en el calendario de la escisión de los servicios de gestión de riesgos empresariales (ERP)
Los consejos de administración rara vez se percatan de los problemas relacionados con el calendario de la escisión del sistema ERP cuando se incumple un hito. La desviación se manifiesta antes, a través de síntomas concretos que aparecen durante los primeros cuatro meses.
Retrasos de los socios de implementación del sistema y desviaciones en la fecha de puesta en marcha
El socio externo encargado de la implementación solicita repetidas prórrogas del plazo para la separación del sistema ERP. La fecha de puesta en marcha se va retrasando de nueve meses a quince o dieciocho.
Restricciones informáticas de la empresa matriz y retrasos en el acceso a las bases de datos
La antigua empresa matriz retrasa el acceso directo a la base de datos. Alega motivos de protección de datos y la confidencialidad de las cuentas compartidas de los clientes, que desea mantener.
Pruebas de EDI fallidas y escalado de incidencias en la cadena de suministro del cliente
Las pruebas de intercambio electrónico de datos previas al lanzamiento dan lugar a etiquetas dañadas o transmisiones rechazadas. El equipo de logística del cliente eleva el asunto a un nivel superior.
Soluciones manuales y el aumento de las primas de los acuerdos de servicios de transición (TSA)
Los responsables de planta y los jefes de envíos elaboran hojas de cálculo manuales. Nadie les ha formado en el nuevo sistema y nadie confía en los datos. Mientras tanto, el plazo del contrato de servicios de transición sigue corriendo. Las primas por prórroga aumentan según un calendario fijo, independientemente de cómo vaya realmente el proceso de separación del sistema ERP.
Cuando varios de estos síntomas aparecen a la vez, el patrón es inconfundible. Un retraso técnico en la migración de una base de datos se convierte, en cuestión de semanas, en un problema físico en el muelle de carga.
Marco estratégico para acelerar la separación de los sistemas informáticos y la transición a los nuevos sistemas
Para recuperar el calendario de la escisión tardía del ERP se necesita un directivo designado con autoridad operativa. No basta con un comité directivo que se reúna mensualmente.
Cómo elegir la estrategia adecuada para la separación de un ERP: migración frente a implantação desde cero
A la hora de evaluar cómo encajar la escisión en un plazo de tiempo ajustado, los responsables suelen barajar tres opciones arquitectónicas distintas:
- Clonar y dividir
- Migración selectiva de datos
- Construcción desde cero
En un plazo de entre nueve y doce meses, rara vez es posible llevar a cabo una construcción totalmente nueva. Una migración selectiva y específica o una plantilla en la nube preconfigurada minimizan la necesidad de personalización y reproducen los procesos existentes de la planta, lo que permite mantener las rutinas con las que ya está familiarizado el personal de planta.
Separación de la ejecución de la planta de la gestión de la transición de los sistemas informáticos
El director de una planta no puede gestionar tres turnos de trabajo y, al mismo tiempo, comprobar miles de transacciones del sistema ERP. Exigirle ambas cosas le condena al fracaso en ambas tareas. En su lugar, debería haber un responsable independiente del programa que se encargue de la fase de transición, coordinando directamente al departamento de TI de la empresa, al integrador y a las operaciones de la planta.
Establecimiento de márgenes de seguridad operativos antes de la transición del sistema
Para protegerse frente a posibles fallos en la cadena de suministro, el consejo de administración debería aprobar con antelación medidas de contingencia específicas. Hay tres aspectos que revisten especial importancia para el calendario de la separación del sistema ERP:
- Reserva de productos terminados: Establecer existencias en los almacenes de los clientes clave.
- Procedimiento en papel: Mantener un procedimiento de envío manual auditado como plan de contingencia.
- Congelación de cambios: Se aplicará una congelación de los cambios no esenciales en el sistema antes de que comience el periodo de transición.
Es posible que los informes no sean perfectos durante unos días. Sin embargo, no puede ocurrir lo mismo con una entrega al cliente que no se haya realizado.
Gestión de la gobernanza y las operaciones en el marco de la separación de sistemas informáticos entre distintas jurisdicciones
La oficina de implementación del comprador suele estar ubicada en un país. La oficina de separación del vendedor, en otro. A menudo, ambas dependen de personas diferentes con incentivos distintos. Establecer una base de datos común entre ellas permite que el calendario de la separación del ERP sea realista. Dos planes de proyecto contrapuestos, en cambio, no lo hacen. Algunas plantas cedidas se encuentran en lugares donde ni el equipo tecnológico del comprador ni el departamento de TI del vendedor operan en el día a día. En ese vacío, un ejecutivo responsable suele ser la única persona que realmente mantiene el calendario de separación del ERP.
Datos del sector sobre la separación de los sistemas ERP y los riesgos de los acuerdos de servicios de transición
De Gartner investigación muestra que entre el 55 % y el 75 % de los proyectos de ERP no logran alcanzar los objetivos operativos previstos. En la fabricación discreta y en las cadenas de suministro con múltiples centros, los fallos tras la puesta en marcha en la gestión de envíos desde el almacén y la planificación de la producción son las principales causas de problemas. Estos son precisamente los fallos que pone en riesgo un calendario de separación y escisión del sistema ERP.
La operación transfronteriza de Roland Berger estudios llegar a una conclusión al respecto. Señalan que la separación de las áreas de TI y RR. HH. son los dos principales escollos que provocan que más de un tercio de las escisiones no alcancen sus objetivos de coste, plazo o calidad. Una encuesta independiente de Roland Berger realizada a cerca de cuatrocientos expertos señala estas mismas dos áreas. La separación de las áreas de TI y RR. HH. es donde se concentran en mayor medida los sobrecostes y los retrasos. Las dos causas fundamentales recurrentes son: la falta de experiencia previa en separaciones por parte del equipo del programa y una planificación poco realista en el momento de la firma.
De BCG investigación indica que la separación de la arquitectura de ERP y de TI es la línea de trabajo que más tiempo lleva en las desinversiones corporativas. Los compradores de capital riesgo y las empresas vendedoras a veces no logran preparar previamente y aislar las dependencias de TI antes del cierre de la operación. Cuando eso ocurre, las prórrogas de los acuerdos de servicios de transición y las des-sinergias operativas merman rápidamente el valor de la operación.
De McKinsey análisis subraya que la separación de los sistemas informáticos suele ser más compleja que la integración por parte del comprador. La interfaz técnica entre la oficina de implementación del comprador y la oficina de separación del vendedor requiere una rigurosa gobernanza operativa, la misma que un acuerdo de servicios de transición para la separación de los sistemas informáticos pretende garantizar. Sin ella, las migraciones de sistemas empiezan a provocar disputas comerciales y fallos en la prestación de servicios al cliente.
Las directrices de EY para los programas de separación sitúan el calendario de separación del ERP en la misma posición. Su norma es la siguiente: dedicar el 80 % del esfuerzo de separación al ERP, la gestión de nóminas y la gestión del rendimiento corporativo. Estos sistemas suelen ser de los últimos servicios que se desactivan en un acuerdo de transición.
En conjunto, estas cinco fuentes apuntan en la misma dirección. El calendario de la escisión del ERP merece la misma atención por parte de la dirección que el equipo encargado de la operación suele reservar para la diligencia debida financiera. Rara vez se le presta más atención que a una dependencia técnica.
Caso práctico: Gestión de una separación de SAP de 10 meses en el sector de la fabricación de automóviles
El siguiente mandato muestra cómo una intervención ejecutiva disciplinada ha permitido llevar a cabo la separación de SAP dentro del plazo establecido en el acuerdo de transición.
El encargo: estrategia de escisión de la fabricación transfronteriza de automóviles
Este mandato de 85 millones de euros supone la puesta en práctica del calendario de separación del ERP. Un inversor europeo de capital riesgo adquirió una división de componentes de precisión para sistemas de propulsión de automóviles de un conglomerado industrial alemán de primer nivel. La entidad escindida gestionaba dos plantas: una planta de mecanizado de precisión en Sajonia (Alemania), que daba empleo a 320 personas, y una planta de montaje en Plzeň (República Checa), que empleaba a 200 operarios técnicos.
Según el contrato de compraventa, la antigua empresa matriz se encargaba de la infraestructura informática, el correo electrónico y el sistema central SAP ECC 6.0. Lo hacía en el marco de un estricto contrato de servicios de transición de doce meses de duración. El contrato contemplaba elevadas primas por prórroga: un 25 % para los meses 13 a 15, y un 50 % a partir de ahí. El incumplimiento de un plazo supuso para el comprador un coste adicional de hasta 600 000 euros.
Dónde se atascó el calendario de la escisión del ERP
Al llegar al cuarto mes, el programa acumulaba un retraso considerable. El integrador elegido por el patrocinador propuso migrar directamente a una implementación personalizada de SAP S/4HANA en la nube. Se trataba de ese tipo de separación ambiciosa de SAP que parece perfecta en una diapositiva. Su plazo de dieciocho meses supondría un incumplimiento de seis meses del acuerdo de transición.
La extracción de datos maestros se paralizó al mismo tiempo. El equipo informático corporativo de la empresa matriz alemana denegó el acceso a los extractos completos de la base de datos. Sus tablas históricas de datos maestros de clientes contenían datos confidenciales sobre precios de las líneas de productos que la empresa matriz había conservado.
En Plzeň, el equipo descubrió que el sistema de destino propuesto no cumplía con la normativa fiscal ni aduanera checa. A continuación, el proyecto llevó a cabo sus primeras pruebas de intercambio electrónico de datos con las plantas de montaje de Wolfsburg y Leipzig. Los mensajes de envío fallaron debido a una serialización de códigos de barras incompatible. Los principales clientes emitieron avisos formales de advertencia sobre el riesgo que esto suponía para sus plazos de entrega.
Dirección provisional del programa ERP e intervención de recuperación rápida
El socio operativo contrató a CE Interim para que dirigiera el calendario de la escisión del sistema ERP. En un plazo de 72 horas tras la finalización del informe del encargo, un director de programa de ERP interino, con experiencia demostrada y adecuado para el encargo, asumió la tarea. Este ejecutivo aportaba más de veinte años de experiencia en el sector de la fabricación industrial y la reestructuración empresarial.
Para recuperar el retraso en el calendario, el ejecutivo tomó cuatro decisiones en rápida sucesión:
- Se detuvo el proyecto de desarrollo a medida de dieciocho meses y se reorientó el programa hacia una extracción selectiva de datos en una plantilla estandarizada en la nube, imitando los flujos de trabajo existentes y acortando el plazo en cinco meses.
- Se creó un equipo específico bilingüe (checo-alemán) especializado en la corrección de datos, que trabajó directamente en la planta de producción para auditar y depurar 1.800 listas de materiales, hojas de ruta y perfiles de embalaje de clientes activos, resolviendo así las cuestiones relacionadas con la privacidad de los datos junto con el equipo jurídico de la empresa matriz.
- Colaboré con los directores de logística de los clientes para reconfigurar las transacciones de intercambio electrónico de datos de salida según las normas VDA 4905 y 4913, logrando la aprobación oficial en un plazo de 30 días.
- Se diseñó una transición estructurada de 72 horas a lo largo de un fin de semana festivo prolongado, con el respaldo de una reserva de productos terminados para cinco días y un procedimiento de contingencia en papel.
El resultado: salida rápida de la TSA y cero tiempo de inactividad operativa
La planta completó la migración completa de la base de datos durante el fin de semana festivo. No se produjo ni una sola hora de parada no programada. El martes por la mañana, el sistema autónomo ya estaba operativo. Las listas de preparación de pedidos automatizadas, los horarios de rutas de las máquinas y los manifiestos de aduana se procesaban sin problemas.
En el décimo mes, la empresa ya se había desconectado por completo de la infraestructura informática de la antigua matriz. Este hito se alcanzó con dos meses de antelación, lo que permitió evitar por completo el pago de los 600 000 euros en primas de prórroga previstas. A los treinta días de la puesta en marcha, la precisión del inventario alcanzó el 99,2 %. Las entregas puntuales y completas alcanzaron el 98,7 %. El equipo eliminó todas las soluciones manuales provisionales. A continuación, el ejecutivo completó un traspaso estructurado de la plataforma operativa, auditada e independiente, al equipo directivo permanente de TI. Así es como debe ser un calendario disciplinado de separación de un sistema ERP: gestionado de principio a fin por un único ejecutivo responsable.
Preguntas frecuentes: Plazos para la escisión de los sistemas ERP empresariales y estrategias de salida de los acuerdos de servicios de transición (TSA)
¿Por qué el calendario de la escisión del ERP determina el resto del proceso de escisión?
El sistema ERP es la base de la contabilidad general, la facturación, el control de existencias, las compras y los envíos a los clientes. Todas las demás funciones dependen de él. Ningún otro proceso puede completarse de forma independiente hasta que el calendario de separación del ERP haya desvinculado la base de datos de la antigua empresa matriz.
¿Cuál es la vía de migración de ERP más rápida en una escisión empresarial?
Una migración selectiva de datos, o una plantilla en la nube estandarizada y preconfigurada, suele ser la opción más rápida. Permite conservar las rutas de fabricación ya probadas. Una implementación desde cero, o una separación completa de SAP partiendo de cero, requiere meses adicionales de configuración y reciclaje profesional.
¿Qué ocurre si la puesta en marcha del ERP no cumple el plazo establecido en el acuerdo de transición?
El incumplimiento del calendario previsto para la separación del sistema ERP da lugar a la aplicación de las primas de prórroga contractuales. Esto pone a prueba la relación comercial con el vendedor. Además, conlleva el riesgo de que se produzcan interrupciones si el vendedor actualiza o retira la infraestructura de la que el comprador sigue dependiendo.
¿Cómo evita una planta las paradas en las líneas de producción durante la transición del sistema?
Las plantas que evitan las paradas de las líneas de producción crean una reserva temporal de productos terminados en los almacenes regionales. Congelan los cambios no esenciales en el sistema antes del periodo de transición. Preparan un procedimiento de envío manual, en papel y auditado, como plan de contingencia.
¿Cuándo debería el consejo de administración nombrar a un director interino del programa de ERP?
El nombramiento resulta necesario en tres situaciones: cuando la empresa cedida forma parte de una única entidad matriz con una estructura muy compleja; cuando los equipos internos carecen de experiencia en separaciones transfronterizas; o cuando el calendario propuesto por el integrador ya entra en conflicto con el acuerdo de transición.
¿Es posible que el calendario de la escisión del sistema ERP se lleve a cabo después de la finalización, en lugar de antes?
Es posible, y suele ocurrir. Resulta más económico corregir la decisión sobre la ruta y el mapa de dependencias antes de que se complete el proyecto. Un enredo de instancias compartidas que se descubra tras la firma suele alargar en meses un plan cuyo coste ya se ha presupuestado en el acuerdo de transición.
Conocimientos relacionados y siguiente paso
Algunas unidades escindidas ya funcionan en una instancia aislada con sus propias licencias. En esos casos, un equipo informático interno suele poder llevar a cabo por sí solo el calendario de separación del ERP. La situación cambia cuando la empresa comparte tablas de bases de datos, listas de materiales y licencias con la empresa matriz en varios países. También cambia cuando la propia hoja de ruta del integrador ya supera el plazo establecido en el acuerdo de transición.
Un director de sistemas de información (CIO) interino o un director de separación de TI es un perfil realmente poco común. Los motivos para contratar a uno de ellos son muy limitados. Se aplica a un proceso de separación de un sistema ERP de instancia única, profundamente complejo, que el equipo interno no ha gestionado anteriormente. En ese caso, la solución de CE Interim es un ejecutivo de probada solvencia, adecuado para el encargo y listo para incorporarse en un plazo de 72 horas tras la finalización del informe del encargo.
Lecturas relacionadas
Es necesario resolver la cuestión del perímetro antes de que nadie pueda definir el calendario de la separación del ERP. Para hablar en confianza sobre un calendario de separación del ERP en curso, ponte en contacto con un Socio interino de CE.
EN 
DE 
FR 
IT 
PL 
RO 
CS 
SK 
HU 
ES 
RU 
AR 
SL