No SAP CPI / Integration Suite, a falta de ownership costuma aparecer tarde: durante um incidente, uma mudança urgente, rotação de credencial ou migração entre ambientes. O fluxo tem nome, o pacote existe, o endpoint responde, mas a decisão fica dividida entre infraestrutura, funcional, segurança, fornecedor externo e suporte.
Uma matriz de ownership não é uma tabela administrativa. É um mecanismo operacional para reduzir ambiguidade. Deve indicar quem conhece o processo, quem pode aprovar mudanças, quem responde no suporte, quem guarda evidência e quais limites exigem escalonamento.
1) Começar por interfaces, não por organogramas
O ownership deve ser mapeado por interface ou domínio de integração, porque a mesma área pode ter responsabilidades diferentes conforme o fluxo. Uma interface de admissão de empregado desde SuccessFactors não é igual a uma confirmação logística para SAP S/4HANA ou uma automação n8n que consome um endpoint CPI.
- Processo: qual operação de negócio a interface habilita.
- Sistema origem e destino: quais plataformas participam e quem as administra.
- Impacto: o que acontece se o fluxo parar, duplicar ou processar tarde.
- Janela operacional: quando deve rodar e quando não deve ser alterado.
2) Separar ownership funcional, técnico e operacional
Uma única pessoa raramente responde por todo o ciclo de vida. Convém separar responsabilidades para evitar que suporte técnico aprove decisões funcionais ou que negócio solicite reprocessamento sem conhecer risco de duplicidade.
| Role | Responsabilidade | Evidência esperada |
|---|---|---|
| Owner funcional | Define impacto, regras de negócio, tolerância a atraso e critério de conciliação. | Processo, SLA, contato e critério de aceitação. |
| Owner técnico | Governa desenho do iFlow, dependências, segurança, mudanças e dívida técnica. | Repositório, versão, arquitetura e registro de mudanças. |
| Owner operacional | Executa diagnóstico, escalonamento, reprocessamento autorizado e fechamento com evidência. | Runbook, severidade, registro e resultado final. |
3) Usar RACI somente onde melhora a decisão
RACI funciona quando responde perguntas concretas. Se vira uma tabela enorme, ninguém usa. Para integrações SAP, normalmente basta cobrir decisões recorrentes:
- Quem aprova uma mudança de endpoint produtivo?
- Quem autoriza reprocessamento quando pode existir duplicidade?
- Quem decide pausar um scheduler durante manutenção?
- Quem valida uma mudança de payload ou catálogo funcional?
- Quem aceita uma exceção temporária e sua data de retirada?
4) Conectar ownership com suporte real
A matriz deve viver perto dos runbooks, não em uma pasta isolada. Quando um alerta dispara, suporte precisa saber quem chamar, que evidência capturar e quais ações são permitidas sem aprovação adicional.
- Identificar interface, ambiente, iFlow e tenant.
- Confirmar severidade conforme impacto de negócio.
- Capturar Correlation ID, MPL, timestamp e sistema receptor.
- Consultar owner funcional e técnico conforme tipo de evento.
- Registrar decisão, ação tomada e resultado verificável.
Essa disciplina não substitui SAP Cloud ALM, SAP Transport Management nem monitoramento runtime. Ela complementa esses controles com clareza humana e evidência operável.
5) Manter ownership quando os times mudam
O ownership envelhece rápido: muda um fornecedor, sai um key user, roda o time AMS, migra um endpoint ou um projeto passa para suporte. Por isso a matriz precisa de data de revisão e gatilhos de atualização.
- Mudança de sistema origem ou destino.
- Nova versão de iFlow ou mudança de contrato de dados.
- Rotação de credenciais, certificados ou ownership de endpoints.
- Encerramento de hypercare ou passagem para operação recorrente.
- Incidente P1/P2 com causa associada a decisão ambígua.
6) Sinais de que falta ownership
- O suporte pergunta várias vezes "quem cuida desta interface" durante incidentes.
- Mudanças são aprovadas por chat sem registro nem owner claro.
- Uma pessoa específica é indispensável para explicar o fluxo.
- Reprocessamentos dependem de critério informal, não de regra documentada.
- A documentação lista sistemas, mas não decisões nem responsáveis.
Em uma avaliação de governança, o ownership mostra se o tenant pode operar com continuidade ou se depende de memória individual. O Picasso CPI Governance Assessment revisa responsáveis, runbooks, evidências, drift, segurança e limites operacionais para detectar riscos antes que apareçam como incidentes repetidos.