Durante años, los equipos técnicos han desarrollado lógica a medida dentro del sistema SAP para cubrir necesidades de negocio que los estándares no resolvían.
Esto ha generado grandes dependencias, altos costes de mantenimiento y un lastre para las actualizaciones.
Hoy, SAP propone un nuevo paradigma: externalizar las reglas de negocio a través de herramientas como SAP Business Rules (BRFplus, Rule Services, Decision Tables) o incluso SAP BTP.
En este artículo analizamos cuándo usar reglas de negocio vs lógica custom, y cómo elegir la mejor opción para mantener el equilibrio entre control, agilidad y Clean Core.
1. ¿Qué entendemos por lógica custom?
- Desarrollo específico dentro del sistema (ABAP, User-Exits, BAdIs, Z-programs)
- Programación a medida que resuelve reglas o decisiones complejas
- Muy potente, pero de difícil mantenimiento y poco reutilizable
- Requiere acceso técnico y pruebas en cada modificación
- Puede romperse tras upgrades si no se gestiona bien
2. Qué son las SAP Business Rules
- Herramientas declarativas que permiten modelar reglas sin codificar
- Separan la lógica de negocio del sistema transaccional
- Son modificables por usuarios expertos sin intervención del equipo técnico
- Se pueden versionar, simular, desplegar y auditar
- Están disponibles en SAP BTP y también en entornos on-premise (BRFplus)
3. Comparativa rápida: lógica custom vs SAP Business Rules
| Criterio | Custom Logic (ABAP) | SAP Business Rules |
| Flexibilidad | Muy alta | Alta, con limitaciones |
| Control | Total (pero técnico) | Delegable a negocio |
| Clean Core | Comprometido | Respeta Clean Core |
| Mantenimiento | Costoso y dependiente | Más simple y trazable |
| Escalabilidad | Limitada sin refactor | Alta con BTP |
| Auditoría | Requiere esfuerzo | Incluida por defecto |
4. ¿Cuándo usar SAP Business Rules?
- Cuando el proceso cambia con frecuencia
- Cuando las reglas pueden estar gestionadas por negocio (pricing, scoring, aprobaciones, etc.)
- Cuando hay que probar múltiples escenarios
- Cuando se quiere independencia del equipo técnico
- Cuando se busca un entorno auditable y gobernado
5. ¿Cuándo seguir con lógica custom?
- Cuando el proceso está altamente integrado con lógica compleja del sistema
- Cuando hay dependencias técnicas que no pueden abstraerse
- Cuando el rendimiento es crítico y se requiere código optimizado
- Cuando ya existe una base ABAP consolidada y bien documentada
6. El enfoque recomendado: equilibrio real
No se trata de eliminar toda lógica custom, sino de encontrar un equilibrio pragmático:
- Estándar + extensiones limpias (BTP) + lógica delegada (Business Rules)
- Aplicar Clean Core en lo técnico y dar autonomía al negocio en lo funcional
- Diseñar sistemas donde el cambio no implique un proyecto cada vez
- Gobernanza clara para todos los niveles
Esto mantiene el sistema ágil, estable y preparado para el futuro.
7. Herramientas SAP disponibles
- SAP Business Rules Service (en BTP): gestión completa de decisiones, compatible con Workflows
- SAP BRFplus: motor de reglas en entornos on-premise
- SAP Decision Tables: para lógica condicional visual
- SAP Build Process Automation: combinación de reglas + procesos + formularios
8. Cómo lo plantea principal33
Desde principal33 ayudamos a:
- Rediseñar procesos críticos con lógica delegada
- Identificar qué reglas deben externalizarse del core
- Implementar SAP BTP para alojar reglas sin romper integraciones
- Crear una arquitectura escalable, auditable y mantenible
- Formar equipos de negocio en el uso de herramientas no-code para decisiones
Conclusión
En proyectos SAP modernos, la lógica de negocio no debe bloquear la evolución del sistema. El reto está en separar lo que cambia frecuentemente (y puede ser gestionado por negocio) de lo que debe permanecer estable.
Con SAP Business Rules, las empresas ganan en velocidad, trazabilidad y autonomía — sin comprometer el rendimiento ni el control.
Y con principal33, este enfoque se convierte en una realidad técnica y funcional desde el diseño del sistema.
