Clean core: lo que realmente hay que gobernar.

El principio cabe en una frase. En un sistema limpio, el núcleo se mantiene conforme al estándar del editor; todo lo que la empresa añade vive al lado, en una plataforma de extensión prevista para ello, detrás de interfaces documentadas. SAP lo ha convertido en la doctrina oficial de SAP S/4HANA y de RISE with SAP, y sería un error ver en ello solo un argumento de venta: la promesa de actualizaciones regulares solo se sostiene si nadie ha soldado el núcleo desde dentro. Pero la verdadera razón para interesarse no está en el editor. Está en sus cuentas.

Cada desarrollo específico es una deuda

Un desarrollo específico nace siempre de una buena intención. Un proceso que se atasca, un informe reglamentario que el estándar no genera tal cual, una petición del negocio que se quiere satisfacer rápido: unos días de desarrollo y el tema queda resuelto. En el momento de codificarlo, un específico parece casi gratuito. Es después cuando empieza a costar.

Cuesta en cada subida de versión: todo lo que toca el núcleo debe analizarse, adaptarse y volver a probarse, y la factura se repite mientras el código viva. En un mundo RISE with SAP, donde el editor impulsa sus actualizaciones a su ritmo, esa carga deja de ser un acontecimiento cada cinco años para convertirse en un peaje recurrente. Cuesta en innovación: las capacidades que SAP entrega, con la IA integrada en primer lugar, se apoyan en los procesos y las estructuras de datos estándar; un núcleo plagado de excepciones las ve pasar de largo. Cuesta, por último, en dependencia: con los años, el conocimiento de un específico se concentra en dos o tres cabezas, y el día en que se marchan, la empresa descubre que ya no sabe explicar su propio sistema. En un mercado donde las competencias SAP son escasas, este último coste es el más pesado.

Ninguno de estos costes figuraba en la estimación del desarrollo inicial. Ahí está toda la dificultad del tema: el gasto es visible y modesto, la deuda es invisible y larga. Una dirección general que la ignora la pagará de todos modos.

El caso particular de la localización

En el espacio OHADA, una parte de lo específico no es un capricho del negocio. Los estados financieros del SYSCOHADA revisado, el IVA y las declaraciones propias de cada Estado de la UEMOA, las nóminas y las cotizaciones sociales nacionales: todo eso debe salir del sistema, y el estándar del editor no siempre cubre cada detalle de cada país. Esos desarrollos son legítimos. La cuestión no es prohibirlos, sino decidir dónde viven.

Nuestra posición es clara: la localización se construye en extensión, sobre SAP BTP, con interfaces documentadas, y no mediante modificaciones en el núcleo. Un estado SYSCOHADA desarrollado fuera sobrevive a las subidas de versión y lo mantiene un equipo local. El mismo estado codificado en el núcleo del sistema tendrá que revalidarse en cada actualización, por las pocas personas que todavía lo entienden. La diferencia de coste a diez años es considerable, y se decide el primer día.

La prueba: un diferenciador demostrado, o el estándar

¿Hay que proscribir entonces todo específico fuera de la localización? No, y los partidarios del todo estándar se equivocan tanto como los demás. Algunos procesos hacen ganar clientes, márgenes o días de tesorería precisamente porque no se parecen a los del vecino. Esos merecen defenderse, desarrollarse limpiamente fuera del núcleo y mantenerse como activos.

Todo está en el criterio. El nuestro es sencillo de enunciar e incómodo de aplicar: un específico se justifica si lo impone la reglamentación, o si el proceso que soporta es un diferenciador de negocio demostrable. Demostrable, no percibido: ¿quién puede decir lo que la empresa perdería, en concreto, al pasar al estándar? Si nadie sabe responder, la respuesta es el estándar, y es el proceso el que se adapta. Nuestra experiencia con inventarios de específicos es constante en este punto: la gran mayoría no supera la prueba. Reproducen una costumbre, rara vez una ventaja.

La pregunta correcta no es «¿qué hace este específico?» sino «¿cuánto valdría la empresa sin él?». Si la respuesta es «lo mismo», no tiene nada que hacer en el núcleo.

Lo que la disciplina exige de la gobernanza

Un criterio no basta; hace falta alguien que lo sostenga. Aquí es donde el tema sale de la esfera técnica, porque sostener un criterio es decir que no. No a un director de negocio con prisa, no a un proyecto que ya ha prometido, no a la solución fácil que reabriría el núcleo. Una autoridad de arquitectura que no pueda apoyarse en la dirección general cederá. Educadamente, y sistemáticamente.

La gobernanza que funciona se apoya en tres prácticas. Una instancia de decisión donde el negocio viene a defender su petición, con la prueba del diferenciador como regla del juego anunciada de antemano. Un registro de excepciones, después: cada específico aceptado se inscribe en él con su propietario, su justificación, su ubicación (núcleo o extensión) y su fecha de revisión, porque una deuda se gestiona mal cuando no se lleva su contabilidad. Una revisión en cada subida de versión, por último: un específico debe volver a ganarse su sitio en cada vencimiento, o sale. Sin esa cita, la deriva vuelve en pocos años, por acumulación de pequeñas excepciones, todas razonables una a una.

2027, la purga que no volverá a pasar

Queda el calendario. El fin del mantenimiento estándar de ECC, fijado a finales de 2027 con una extensión posible hasta finales de 2030, impone a cada empresa un paso a SAP S/4HANA. Y una conversión es el único momento en que purgar cuesta menos que conservar: de todos modos hay que inventariar, analizar y volver a probar cada desarrollo. Cribar en esa ocasión es un esfuerzo marginal; embarcarlo todo es convertir la deuda al mismo tiempo que el sistema, y pagarla durante diez años más.

Por eso defendemos que la doctrina de lo específico se fije desde el encuadre, antes de la elección del escenario y del integrador, en lugar de descubrirla en pleno programa cuando cada arbitraje retrasa un hito. La empresa que llega a la negociación con su regla del juego, su registro y su lista de purga elige su programa. La otra lo sufre.

Para prolongar: nuestra lectura del vencimiento de 2027 para las empresas de la subregión, nuestra oferta SAP · S/4HANA y ERP y nuestras aplicaciones a medida, donde las extensiones se diseñan y se construyen.