Toda empresa que corre SAP desde hace más de una década carga un acervo que nadie consigue describir entero: informes, interfaces, cargas, enhancements, formularios y workflows construidos a lo largo de años, por gente que en buena parte ya se fue. Es el WRICEF, y es, casi siempre, la mayor fuente de incertidumbre de un proyecto de conversión.

La pregunta que el proyecto necesita responder al principio es simple de enunciar y difícil de responder: ¿cuántos de esos objetos existen, cuáles se usan todavía y cuáles hay que reescribir? Sin esos tres números, cualquier estimación de plazo es una corazonada con cara de cronograma.

Por qué el WRICEF asusta

No es el volumen en sí. Es la combinación de tres desconocidos.

Nadie sabe qué hace cada objeto. La documentación, cuando existe, describe la intención original, no en qué se convirtió el objeto después de siete modificaciones. El conocimiento real está en el código.

Nadie sabe qué se usa. Un informe creado para un cierre específico de 2016 sigue transportado, mantenido y migrado como si fuera esencial.

Nadie sabe qué se rompe. El cambio de modelo de datos en S/4 —tablas que se volvieron vistas, campos que cambiaron de tamaño, el cliente y el proveedor que se volvieron interlocutor comercial— golpea exactamente al código que lee tablas de forma directa. Y ese es justamente el código antiguo.

El resultado es el patrón conocido: el proyecto estima por promedio, descubre la realidad en plena ejecución y renegocia el plazo.

Primero el dato, después el criterio

Inventariar es trabajo de herramienta. El propio entorno sabe qué objetos personalizados existen, quién los creó, cuándo se modificaron por última vez y a qué paquete pertenecen. Y las herramientas de verificación de compatibilidad señalan, objeto por objeto, qué entra en conflicto con el modelo de datos nuevo. Esto no es territorio de IA: es consulta, y la consulta tiene que ser exacta.

Cortar por uso es el paso más rentable y el más olvidado. El entorno registra la ejecución. Cruzar el inventario con el dato de uso de los últimos dos años suele revelar que una porción grande del acervo simplemente no corre. Un objeto que nadie ejecuta no necesita ser analizado, ni reescrito, ni probado: necesita una decisión de retiro, que es barata.

Solo después de esos dos cortes el esfuerzo restante merece criterio, y ahí es donde la IA cambia la economía.

Dónde entra la IA de verdad

Explicar qué hace el objeto. Leer algunos miles de líneas de ABAP y devolver, en lenguaje de negocio, qué proceso atiende, qué tablas toca y qué pasa si deja de existir. Es el insumo que permite al usuario clave decir «esto lo uso» o «esto dejamos de usarlo en 2019», una conversación que hoy se traba porque nadie sabe explicar el objeto a quien decide.

Agrupar por finalidad. Suele haber cinco informes que resuelven la misma pregunta con pequeñas variaciones, creados por áreas distintas a lo largo de los años. Agrupar por semejanza de propósito, no de nombre, muestra dónde cinco objetos pueden volverse uno. Es la misma capacidad de similitud que usamos en saneamiento de datos maestros, aplicada al código.

Proponer el destino. Con el resultado de la verificación de compatibilidad, el uso y la finalidad sobre la mesa, el asistente sugiere la clasificación: retirar, sustituir por un recurso estándar, reescribir dentro del modelo de extensibilidad liberado, o mantener con un ajuste mínimo. Viene con justificación y con la evidencia que la sostiene.

Estimar con base comparable. Objetos parecidos que ya fueron tratados dan la referencia de esfuerzo. Una estimación por analogía rastreable es mucho mejor que una estimación por sensación.

Apoyar la reescritura. Cuando el objeto tiene que cambiar, el asistente propone la versión que usa una interfaz liberada en vez de la lectura directa de tablas, y explica qué cambió. La revisión sigue siendo de quien responde por el código.

Qué hacer con lo que sobra

Después de los cortes, el acervo restante se reparte en cuatro destinos, y nombrarlos evita la discusión infinita.

Retirar. Sin uso y sin dueño. Bloquear, observar un ciclo de cierre, eliminar.

Sustituir por el estándar. Mucho informe antiguo existe porque el estándar de la época no atendía. Buena parte ya está cubierta por un recurso nativo: verificar antes de reescribir es el punto que más reduce esfuerzo.

Reescribir en el modelo liberado. El objeto es necesario, pero fue construido de una forma que no sobrevive. Aquí es donde la reescritura asistida gana tiempo real.

Mantener con ajuste. Funciona, se usa, y el ajuste es puntual.

Esa clasificación es el puente hacia la conversación siguiente, la más importante del proyecto: cómo llegar al clean core, porque reescribir manteniendo el mismo vicio solo aplaza el problema hasta la próxima actualización.

Qué cambia en el proyecto

La estimación deja de ser una corazonada. Con inventario, uso y clasificación, el número de objetos a tratar se conoce antes de empezar, y casi siempre es bastante menor que el total, lo que suele ser la mejor noticia de la fase de preparación.

La conversación con el negocio cambia. En vez de «ustedes tienen que decir qué usan», el equipo llega con la lista de lo que no corre desde hace dos años y pide confirmación. Mucho más fácil de responder.

El conocimiento queda. La descripción de cada objeto, validada, se convierte en documentación que sobrevive al proyecto, y que hoy simplemente no existe.

El límite honesto: nada de esto decide por usted. El corte de alcance en desarrollo es una decisión política dentro de la empresa, porque cada objeto tiene a alguien que lo pidió. La automatización da el argumento con datos; la conversación sigue siendo humana.

Para preparar esa fase, en la Inove Academy la guía de brownfield, greenfield y bluefield ayuda a entender qué exige cada enfoque de su acervo de desarrollo: la elección cambia por completo el tamaño de este trabajo.