En SAP CPI / Integration Suite, la falta de ownership suele aparecer tarde: durante un incidente, un cambio urgente, una rotación de credencial o una migración entre ambientes. El flujo tiene nombre, el paquete existe, el endpoint responde, pero la decisión queda dispersa entre infraestructura, funcional, seguridad, proveedor externo y soporte.
Una matriz de ownership no es una tabla administrativa. Es un mecanismo operativo para reducir ambigüedad. Debe indicar quién conoce el proceso, quién puede aprobar cambios, quién responde por soporte, quién conserva evidencia y qué límites no deben cruzarse sin escalamiento.
1) Empezar por interfaces, no por organigramas
El ownership debe mapearse por interface o dominio de integración, porque una misma área puede tener responsabilidades distintas según el flujo. No es lo mismo una interface de altas de empleado desde SuccessFactors, una confirmación logística hacia SAP S/4HANA o una automatización n8n que consume un endpoint CPI.
- Proceso: qué operación de negocio habilita la interface.
- Sistema origen y destino: qué plataformas participan y quién las administra.
- Impacto: qué pasa si el flujo se detiene, duplica o procesa tarde.
- Ventana operativa: cuándo debe correr y cuándo no se debe tocar.
2) Separar ownership funcional, técnico y operativo
Una sola persona rara vez puede responder por todo el ciclo de vida. Conviene separar responsabilidades para evitar que soporte técnico apruebe decisiones funcionales o que negocio pida reprocesos sin conocer el riesgo de duplicidad.
| Rol | Responsabilidad | Evidencia esperada |
|---|---|---|
| Owner funcional | Define impacto, reglas de negocio, tolerancia a atraso y criterio de conciliación. | Proceso, SLA, contacto y criterio de aceptación. |
| Owner técnico | Gobierna diseño del iFlow, dependencias, seguridad, cambios y deuda técnica. | Repositorio, versión, arquitectura y registro de cambios. |
| Owner operativo | Ejecuta diagnóstico, escalamiento, reproceso autorizado y cierre con evidencia. | Runbook, severidad, bitácora y resultado final. |
3) Usar RACI solo donde mejora la decisión
RACI funciona cuando responde preguntas concretas. Si se convierte en una tabla enorme, nadie la usa. Para integraciones SAP, suele bastar con cubrir decisiones recurrentes:
- ¿Quién aprueba un cambio de endpoint productivo?
- ¿Quién autoriza reproceso cuando puede existir duplicado?
- ¿Quién decide pausar un scheduler durante mantenimiento?
- ¿Quién valida un cambio de payload o catálogo funcional?
- ¿Quién acepta una excepción temporal y su fecha de retiro?
4) Conectar ownership con soporte real
La matriz debe vivir cerca de los runbooks, no en una carpeta aislada. Cuando una alerta se dispara, soporte necesita saber a quién llamar, qué evidencia capturar y qué acciones están permitidas sin aprobación adicional.
- Identificar interface, ambiente, iFlow y tenant.
- Confirmar severidad según impacto de negocio.
- Capturar Correlation ID, MPL, timestamp y sistema receptor.
- Consultar owner funcional y técnico según tipo de evento.
- Registrar decisión, acción tomada y resultado verificable.
Esta disciplina no reemplaza SAP Cloud ALM, SAP Transport Management ni monitoreo runtime. Los complementa con claridad humana y evidencia operable.
5) Mantener ownership cuando cambian los equipos
El ownership envejece con rapidez: cambia un proveedor, se mueve un key user, rota el equipo AMS, se migra un endpoint o se entrega un proyecto a soporte. Por eso la matriz debe tener fecha de revisión y gatillos de actualización.
- Cambio de sistema origen o destino.
- Nueva versión de iFlow o cambio de contrato de datos.
- Rotación de credenciales, certificados o ownership de endpoints.
- Cierre de hypercare o traspaso a operación recurrente.
- Incidente P1/P2 con causa asociada a decisión ambigua.
6) Señales de que falta ownership
- El soporte pregunta varias veces "quién ve esta interface" durante incidentes.
- Los cambios se aprueban por chat sin registro ni owner claro.
- Una persona específica es indispensable para explicar el flujo.
- Los reprocesos dependen de criterio informal y no de una regla documentada.
- La documentación lista sistemas, pero no decisiones ni responsables.
En una evaluación de gobierno, el ownership muestra si el tenant puede operar con continuidad o si depende de memoria individual. El Picasso CPI Governance Assessment revisa responsables, runbooks, evidencias, drift, seguridad y límites operativos para detectar riesgos antes de que aparezcan como incidentes repetidos.