Cuando la aplicación estándar de Fiori cubre el 80 %, y el 20 % faltante acaba con la adopción

El taller fit-to-standard salió bien. La aplicación estándar de la Fiori Apps Reference Library se demostró de maravilla, el analista marcó la lista de requisitos y la diapositiva de resumen dijo lo que siempre dice: 80 % de cobertura, brechas restantes que se abordarán en una fase posterior.

Seis meses después del go-live, los aprobadores exportan la lista de trabajo a Excel porque el único campo en el que realmente basan su decisión no está en la object page. El empleado que libera doscientos documentos antes del almuerzo ha vuelto discretamente a la transacción de la GUI. La excepción de los jueves viaja por correo electrónico.

Esta es la paradoja: las aplicaciones Fiori estándar que fracasan con más fuerza rara vez son las que claramente no encajaban. Un desajuste evidente se rechaza pronto y a bajo coste. Una aplicación que cubre el 80 % se aprueba, se enseña y se celebra; luego fracasa silenciosamente, porque los porcentajes de cobertura ocultan un hecho que toda hoja de cálculo de ajuste-brecha ignora: no todos los requisitos pesan lo mismo.

Por qué "Adoptar lo estándar primero" sigue siendo el instinto correcto

La postura merece su mejor defensa, porque en gran medida es correcta.

El fit-to-standard es la lección acumulada de dos décadas de entornos ERP enterrados bajo transacciones Z: el sistema en el que una actualización tarda dieciocho meses porque diez mil objetos personalizados necesitan pruebas de regresión, y en el que el código personalizado ahora dicta cómo funciona el proceso.

El principio de clean core es la respuesta sensata. Las aplicaciones Fiori estándar vienen con algo que ningún desarrollo personalizado ofrece por completo: SAP las mantiene, las prueba frente a cada versión y las entrega integradas con los objetos de negocio y las autorizaciones. Cuando una aplicación estándar realmente encaja, adoptarla es la decisión de ingeniería correcta.

La crítica que sigue apunta a otras dos cosas: cómo se determina que algo "encaja" y el costo subestimado de cerrar las brechas que deja atrás.

Por qué la “cobertura del 80%” es una cifra sin sentido

Un análisis típico de ajuste-brecha produce una lista: cuarenta requisitos, treinta y dos cubiertos, ocho brechas. Cobertura: 80%. La cifra parece rigurosa. Es aritmética aplicada a un error de categoría.

Los requisitos se cuentan como unidades intercambiables. No lo son. “La aplicación muestra la moneda del documento” y “el aprobador puede ver las disputas abiertas del proveedor” cuentan ambos como una línea, pero uno es decoración y el otro es la razón por la que existe el paso de aprobación. Si el 20% faltante incluye un paso que el usuario no puede omitir, la adopción se desploma sin importar lo pulido que esté el resto.

La pregunta que predice la adopción es diferente: ¿puede cada usuario completar su trabajo diario real, incluidos los casos difíciles, sin salir de la aplicación? Esa es una pregunta de sí/no por rol, y convertirla en un promedio porcentual es la forma en que los despliegues fracasan educadamente. La cobertura es una cadena, no un montón: un eslabón roto, y el usuario experimenta la ruptura.

Una taxonomía del 20% faltante

La quinta parte faltante se agrupa en cinco familias.

Datos faltantes en pantalla. La object page muestra los datos de cabecera que SAP consideró universalmente relevantes, pero este aprobador decide en función de la referencia del contrato y del gasto contra el acuerdo marco, y ninguno de los dos aparece. Así que abre SAP GUI en una segunda ventana y pronto omite por completo el paso de Fiori. Un solo campo faltante convierte una pantalla completa al 95% en 0% suficiente.

Validaciones y controles de cumplimiento faltantes. El marco de control exige una verificación de cuatro ojos por encima de un umbral. La aplicación estándar no tiene lugar para ello, y una política que pide a los usuarios que "recuerden hacerlo" no es algo que los auditores acepten.

Operaciones masivas faltantes. El empleado que procesaba lotes en una cuadrícula ALV — seleccionar todo, aplicar, F8 — se encuentra con un list report diseñado para revisar elementos uno por uno. Doce minutos se convierten en una hora.

Rutas de excepción faltantes. El proceso real incluye rechazar con motivo y devolver, solicitar aclaración, reasignar porque el aprobador está de licencia. Sin un vocabulario para la excepción, la excepción se traslada al correo electrónico.

Integración faltante con el paso adyacente. El resultado debe llegar a un lugar al que la aplicación no alcanza — un adjunto en otro módulo, una notificación que el siguiente rol nunca recibe — por lo que el usuario realiza una segunda tarea manual para que la primera cuente.

Cada uno parece pequeño en una fila de fit-gap. Cada uno es fatal en la ruta crítica.

Por qué la brecha sobrevive al proyecto — y cómo la adopción colapsa silenciosamente

Si estas brechas son tan predecibles, ¿por qué llegan a producción? Por cuatro mecanismos estructurales.

Las demostraciones muestran los caminos felices. El taller ejecuta el escenario estándar con datos limpios. Nadie demuestra la excepción del jueves.

Los talleres toman muestras de los usuarios equivocados. Los asistentes son responsables funcionales y consultores que entienden el proceso, pero no lo ejecutan doscientas veces al día. El empleado que sabe qué campo importa está representado por un sustituto.

La cobertura se valida contra la documentación. El proceso documentado rara vez incluye las validaciones informales, las consultas paralelas y la gestión de excepciones que conforman el trabajo real.

"La fase 2" es una ficción con un código de proyecto. Después del go-live, el equipo se dispersa, el presupuesto se cierra y los usuarios ya han creado soluciones alternativas. La solución alternativa se convierte en el proceso.

Y el colapso es silencioso. Nadie presenta un ticket titulado "Me niego a usar la aplicación". La transacción de la interfaz gráfica sigue siendo accesible, la exportación a Excel se convierte en la verdadera lista de trabajo, y las aprobaciones se acuerdan previamente por correo electrónico y luego simplemente se registran en la aplicación — de modo que la pista de auditoría documenta una ficción. Las cifras de lanzamiento se mantienen respetables, porque los usuarios siguen abriendo la aplicación para el clic final. Por eso el 20% faltante es más peligroso que un 100% faltante: el fracaso total es visible en el taller; el fracaso parcial es invisible hasta la auditoría.

El espectro de extensibilidad: dónde se detiene cada herramienta

Nada de esto significa que las brechas no puedan cerrarse. SAP ofrece un espectro real de opciones, y una evaluación honesta requiere saber dónde termina cada una.

Extensibilidad de key user — las aplicaciones Custom Fields y Custom Logic en S/4HANA — permite que un experto de negocio capacitado agregue campos personalizados a un contexto de negocio, los exponga en la interfaz de usuario estándar y adjunte lógica restringida mediante BAdIs liberados. El límite está exactamente donde SAP lo trazó: puntos de extensión liberados. Un centímetro fuera de lo que SAP expuso, la herramienta simplemente termina, y el ajuste bloqueante requiere un desarrollador que nadie presupuestó.

Adaptación de la interfaz de usuario — adaptación en tiempo de ejecución por key users, o proyectos de adaptación en SAP Business Application Studio para variantes estables ante actualizaciones de aplicaciones SAPUI5 estándar — corrige problemas de disposición: el campo importante enterrado tres secciones más abajo. Mueve los muebles; no añade habitaciones. Una verificación de cumplimiento faltante no es un problema de diseño.

Extensibilidad de desarrollador — extensiones basadas en RAP, BAdIs liberados, vistas CDS personalizadas — implementa lógica real, validaciones y nuevas acciones de una manera compatible con clean core. La extensibilidad side-by-side en SAP BTP va más allá: una aplicación separada que consume S/4HANA mediante APIs y eventos, libre para construir lo que la aplicación estándar nunca modeló. Ambas son, sin ambigüedad, proyectos de desarrollo: habilidades escasas de RAP o CAP, transportes, regresión de actualizaciones y un responsable para los próximos diez años.

La pregunta nunca fue si se puede cerrar el 20%. Es cuánto cuesta — y quién asume ese costo después de que termina el proyecto.

La curva de costos que nadie dibuja

El costo de la cobertura no es lineal. El primer 80% llegó esencialmente gratis: SAP lo construyó, lo prueba, lo actualiza. El último 20% es trabajo a medida, y es completamente normal que cerrar "solo" la quinta parte faltante cueste más de lo que habría costado construir la funcionalidad cubierta, porque estás pagando por la integración en la aplicación de otra persona, a tarifas de servicios profesionales, con obligaciones de ciclo de vida adjuntas.

Y el costo se repite. Cada actualización de S/4HANA implica pruebas de compatibilidad de las extensiones. Las extensiones en contextos liberados están diseñadas para sobrevivir a las actualizaciones, y en su mayoría lo hacen, pero "estable por contrato" aún significa "pruébalo cada vez".

Esto no es un argumento en contra de extender. Es un argumento a favor de fijar el precio de la decisión con honestidad. Cuando el verdadero costo del ciclo de vida está sobre la mesa, las alternativas que sonaban como una derrota empiezan a sonar como ingeniería.

Dos alternativas honestas: mantener SAP GUI o rediseñar el proceso

La primera alternativa es la coexistencia. Para el rol de procesamiento masivo, la pregunta madura no es "cómo los llevamos a Fiori", sino "qué problema resolvería eso y para quién?". Si la extensión para hacer que la aplicación sea rápida implica un desarrollo significativo y la transacción de GUI cuenta con soporte y está dominada, mantener SAP GUI para ese rol es una asignación correcta del esfuerzo. Fiori se gana su lugar donde realmente es mejor: aprobaciones en dispositivos móviles, autoservicio para usuarios ocasionales, páginas de listas analíticas. La versión honesta de la coexistencia nombra la decisión, la delimita al rol y la revisa periódicamente; la versión deshonesta es descubrirla en una auditoría.

La segunda alternativa es rediseñar el proceso. A veces, el 20% faltante no es una deficiencia de la aplicación, sino un fósil del proceso: la aprobación paralela nacida de un incidente en 2017. Antes de financiar una extensión para codificar una excepción, pregúntese si la excepción debería existir. "Solo simplificar" puede ser tan simplista como "solo extender", pero el rediseño de procesos pertenece a la misma lista de opciones que la extensión.

Un marco de decisión: pondera las brechas, no las cuentes

Primero, pondera cada brecha en tres ejes:

• Gravedad: bloqueante (el usuario no puede completar la tarea correctamente sin ello) frente a inconveniente.
• Frecuencia: con qué frecuencia se encuentra la brecha y por cuántos usuarios.
• Radio de impacto: quién se ve afectado: un rol operativo central, un usuario ocasional, un auditor.

Una brecha bloqueante que se presenta cincuenta veces al día pesa más que cualquier cantidad de brechas estéticas. Puntúa las brechas; no las promedies. Luego elige un camino por cada brecha, no un único camino para la aplicación:

1. Aceptar la brecha: elementos de baja gravedad y baja frecuencia.
2. Adaptar la interfaz de usuario: problemas de disposición y ajuste en pantalla.
3. Extensión de key user: campos faltantes y lógica restringida dentro de los puntos de extensión publicados.
4. Extensión de desarrollador (RAP/BAdI): lógica real, validaciones y acciones, presupuestadas como un proyecto de desarrollo.
5. Side-by-side en BTP: brechas lo suficientemente grandes como para ser su propia aplicación.
6. Mantener SAP GUI para el rol: flujos de trabajo de usuarios avanzados que la aplicación atiende peor.
7. Rediseñar el proceso: excepciones que merecen ser eliminadas.

Sea cual sea el camino elegido, nombra al responsable del mantenimiento. Una extensión sin propietario es deuda técnica con fecha de entrega.

Cómo ejecutar el Fit-Gap para que esto no ocurra

El lugar más barato para detectar el 20% fatal es antes del go-live, y el formato estándar de taller es estructuralmente deficiente para hacerlo. Cuatro ajustes cambian las probabilidades:

Valide con los operadores reales. Ponga al usuario de mayor volumen de la transacción actual frente a la aplicación estándar y haga que realice su martes real con volúmenes similares a los de producción. El campo que revisa en silencio saldrá a la luz en diez minutos.

Pruebe explícitamente los casos complicados. Guionice el rechazo con retrabajo, la delegación, el pico de fin de mes. Una aplicación validada solo contra el camino feliz ha sido validada contra un proceso que no existe.

Ejecute una prueba cronometrada de un día en la vida real. Una ralentización de 5 veces encontrada aquí es un dato de entrada de diseño; encontrada después del go-live, es una solución alternativa ya en curso.

Escriba la lista de brechas en lenguaje de severidad. Sustituya "80% de cobertura" por una frase por rol: "El rol X puede / no puede completar el trabajo diario en la aplicación; las brechas bloqueantes son A y B; el camino elegido es Y, a cargo de Z." Esa frase sobrevive al contacto con la realidad.

Opciones para cerrar brechas comparadas

Preguntas frecuentes

¿Qué es la extensibilidad key user en SAP S/4HANA?

Permite que expertos de negocio capacitados amplíen las aplicaciones estándar de S/4HANA sin un proyecto de desarrollo: añadiendo campos personalizados mediante la aplicación Custom Fields y lógica restringida a través de BAdIs liberados en la aplicación Custom Logic. Funciona estrictamente dentro de los puntos de extensión que SAP ha liberado.

¿Cuál es la diferencia entre la extensibilidad en la aplicación y la extensibilidad side-by-side?

La extensibilidad en la aplicación se ejecuta dentro de la pila de S/4HANA (herramientas de key user, RAP, BAdIs), ampliando directamente los objetos estándar. Side-by-side crea una aplicación separada en SAP BTP que consume S/4HANA mediante APIs y eventos liberados. La extensibilidad en la aplicación es más económica para pequeñas brechas; side-by-side se adapta a capacidades más grandes, con el coste de operar una segunda aplicación.

¿Por qué los usuarios vuelven a SAP GUI después de los despliegues de Fiori?

Porque una parte específica y de alta frecuencia de su trabajo es peor en la aplicación: falta en la pantalla un campo crítico para la toma de decisiones, las operaciones masivas son más lentas que el antiguo flujo de trabajo de ALV, o hay rutas de excepción que la aplicación no modela. Como las transacciones de GUI siguen estando disponibles, los usuarios vuelven a ellas discretamente.

¿Cómo evalúas si una aplicación estándar de Fiori se ajusta a tu proceso?

Pondera las brechas en lugar de contarlas. Haz que los usuarios reales con mayor volumen ejecuten su carga de trabajo diaria real, incluidas las excepciones, en un sandbox, y clasifica cada brecha como bloqueante o inconveniente. La pregunta decisiva es si cada rol puede completar el trabajo real sin salir de la aplicación.

¿Las extensiones de Fiori sobreviven a las actualizaciones de S/4HANA?

Las extensiones construidas sobre puntos de extensión liberados —extensiones key user, proyectos de adaptación, extensiones de desarrollador contra APIs liberadas— están diseñadas para ser estables ante actualizaciones y, por lo general, lo son. "Estable" sigue significando "realiza pruebas de regresión en cada actualización", y cualquier cosa que toque objetos no liberados es un riesgo permanente.

¿Es mejor ampliar una aplicación estándar de Fiori o crear una personalizada?

Una o dos brechas a nivel de campo dentro de puntos de extensión liberados favorecen la ampliación. Un conjunto de brechas bloqueantes en torno a la lógica, el procesamiento masivo o los flujos de excepción puede hacer que una aplicación creada para un propósito específico —mediante RAP o side-by-side en BTP— sea más económica a lo largo de su ciclo de vida que apilar extensiones sobre un floorplan diseñado para un trabajo diferente.

La brecha más costosa es la que encuentran tus usuarios

Las aplicaciones estándar de SAP Fiori merecen ser consideradas en primer lugar; esa parte de la sabiduría convencional se mantiene intacta. Lo que no se mantiene es la forma en que se mide la cobertura. Una cifra del 80% obtenida contando requisitos no responde a ninguna pregunta que importe; lo que predice la adopción es si cada rol puede completar su trabajo diario real, incluidos los casos difíciles, sin salir de la aplicación.

Los equipos que evalúan las brechas una por una, antes del go-live, y asignan un responsable para cada vía de cierre obtienen lo que promete el fit-to-standard. Los equipos que marcan “80% — cubierto por estándar” y siguen adelante obtienen una aplicación que muestra un uso respetable mientras el trabajo real se traslada silenciosamente a Excel, al correo electrónico y a la transacción que nunca desapareció.

La brecha más barata es la que cierras en un taller. La más costosa es la que tus usuarios descubren después del go-live, porque para entonces ya la habrán resuelto sin ti.