Como este tema funciona na sua empresa
Raramente têm governança tripartite formal; quando terceirizam, é integrador único. Se usam subcontratados, deixam a cabo do integrador (você não controla diretamente). Risco: perda de controle total da operação. Abordagem: cláusula clara em contrato que integrador pode subcontratar, mas com sua aprovação.
Começam a usar modelo tripartite com integrador principal + provedores especializados (cloud, segurança). Acompanhamento em duas camadas: cliente-integrador (contrato principal) e integrador-fornecedor (subcontrato, que você não controla diretamente). Desafio: visibilidade de performance de subcontratados.
Governança tripartite formal com SLAs em cascata, comitês em múltiplos níveis, clareza contratual sobre subcontratação. Implementam portal de visibilidade ou integram informações de múltiplas fontes. Risco: complexidade excessiva; precisa de orquestração cuidadosa.
Governança tripartite em outsourcing envolve três atores: cliente (você), fornecedor principal (integrador), sub-fornecedores (cloud, software). Desafio: responsabilidades ficam ambíguas; culpa é passada entre partes; cliente perde visibilidade. Tripartite bem estruturado clarifica papéis e responsabilidades[1].
Mapa de dependências: visualizar quem oferece o quê
Criar documento visual (diagrama) que mostra: você (cliente) ? integrador ? sub-fornecedores (cloud, licenças, suporte). Identifica gargalos críticos: onde está o risco? Se cloud provider falha, qual é o impacto? Se integrador não conseguir ativar backup, qual é o tempo? Mapa de dependências é essencial antes de estruturar governança. Exemplo: cliente tem aplicação de vendas em cloud (AWS) + suporte de integrador. Se AWS cai, vendas caem. Se integrador não responde, você não consegue escalar para AWS (dupla dependência). Documentar isto é primeiro passo.
Definição clara de papéis
Cliente: definidor de requisitos, aprovador de decisões estratégicas, escalação final. Integrador: coordenador, responsável contratual perante cliente, gestor de sub-fornecedores. Sub-fornecedor: executor, responsável contratual perante integrador. Exemplo: você quer escalar performance. Cliente diz "preciso de mais power". Integrador diz "AWS é o gargalo, vou falar com eles". Mas você não fala diretamente com AWS; integrador é intermediário. Deixar isto claro no contrato evita confusão depois (ex: você tentando contratar AWS diretamente, criando conflito com integrador).
SLAs em cascata: cada nível tem responsabilidade
SLA cliente-integrador: integrador responde ao cliente com uptime 99.5%. SLA integrador-AWS: AWS responde ao integrador com uptime 99.99%. Resultado: se AWS está 99.99% mas integrador tem problema (demora responder), integrador falha SLA com cliente (99.5%). Cascata deixa claro: quem é responsável por cada SLA? Se uptime cai para 95%, você sabe se foi AWS ou integrador? Precisa documentação robusta para rastrear. Em contrato, incluir: "integrador é responsável por SLA com cliente, independentemente de performance de sub-fornecedores" (integrador absorve risco).
Visibilidade: acesso a métricas de sub-fornecedores
Desafio: integrador não quer que você fale diretamente com AWS (quer ser intermediário). Você quer visibilidade de performance de AWS. Solução: integrador fornece dashboard com métricas de AWS (uptime, latência, etc.), mas não acesso direto. Para small issues, você vai para integrador; para critical, pode pedir envolvimento direto de AWS via integrador. Contrato deve especificar: qual é nível de visibilidade que você tem? Você pode ver logs de AWS? Você pode acessar portal de AWS? Deixar vago = problema depois.
Simples: (1) contrato com integrador deixa claro que integrador pode subcontratar, mas com sua aprovação; (2) integrador é responsável por performance de subs (não você); (3) integrador deve fornecer list de subs (quem é cloud, quem é suporte?); (4) você tem direito a escalar diretamente ao sub-fornecedor se crítico + integrador não responde em 4h. Isto é suficiente para pequena; não precisa de complexity adicional.
Implementar: (1) mapa de dependências (quem oferece o quê); (2) SLAs em cascata (cliente-integrador, integrador-AWS); (3) contrato especifica subcontratação autorizada (AWS sim, Vendor X requer aprovação sua); (4) integrador fornece dashboard com métricas críticas de subs (uptime, latência); (5) protocolo de escalação: você ? integrador ? sub-fornecedor (em cascata); (6) reunião mensal cliente-integrador para revisar performance de subs; (7) contrato permite você auditar relação integrador-sub-fornecedor (ler contrato).
Implementar: (1) mapa sofisticado de dependências com scoring de criticidade; (2) SLAs em cascata com penalidades (se sub-fornecedor falha, integrador paga multa para você); (3) contrato muito detalhar especificando aprovação de subcontratação, critério de mudança, direito de auditoria; (4) portal integrado que consolida métricas de subs em tempo real (BI); (5) comités em 3 níveis: técnico (integrador+subs), gerencial (você+integrador), executivo (escalação); (6) MOU (Memorando de Entendimento) entre 3 partes definindo expectativas; (7) direito de você estar em reunião 1x/trimestre com integrador + subs críticos.
Cláusula de mudança de sub-fornecedor
Se sub-fornecedor muda ou falha, quem aprova a mudança? Contrato deve ser claro: "integrador pode substituir sub-fornecedor operacional sem aprovação sua, mas crítico requer sua aprovação (requer 30 dias aviso prévio)". Sem isto, integrador muda cloud provider (crítico!) sem avisar, você descobre quando já mudou (muito tarde).
Resolução de disputa tripartite
Se problema, três cenários: (1) problema é de integrador (culpa dele), você + integrador resolvem. (2) Problema é de sub-fornecedor, integrador escalda para sub, você fica informado. (3) Ambíguo (quem é culpa?), protocolo: integrador investigaçõe, você + integrador + sub-fornecedor em reunião conjunta para esclarecer. Deixar isto em contrato evita "passa o problema adiante".
Sinais de que sua governança tripartite é fraca
Se você se reconhece em três ou mais cenários abaixo, reforça governança.
- Não sabe quem são os sub-fornecedores do integrador; integrador não divulga
- Problema ocorre; integrador diz "culpa de AWS"; AWS diz "culpa de integrador"; você fica no meio
- Não tem visibilidade de performance de sub-fornecedores; integrador controla informação
- Integrador muda sub-fornecedor sem avisar; você descobri depois que algo mudou
- Contrato com integrador não especifica o que é subcontratável e o que não é
- SLA com cliente é 99.5%, mas SLA integrador com AWS é 99.9% (não em cascata apropriada)
- Crítico problema em production; levou 24h para esclarecer se foi integrador ou sub-fornecedor
Caminhos para estruturar governança tripartite
Estruturar com recursos que você já tem.
- Perfil necessário: gestor de contrato + advogado comercial + TI
- Tempo estimado: 3-4 semanas para mapear, documentar, revisar contrato
- Faz sentido quando: outsourcing é com integrador único; estrutura é relativamente simples
- Risco principal: contrato pode ficar confuso ou com brechas; falta de expertise
Se outsourcing é complexo ou tem múltiplos subs.
- Tipo de fornecedor: consultores em outsourcing + advogados especializados
- Vantagem: experiência em complexidade tripartite, contrato robusto
- Faz sentido quando: outsourcing é significativo; múltiplos sub-fornecedores; risco é alto
- Resultado típico: 6-8 semanas, estrutura clara, contrato bem redacionado
Precisa estruturar governança tripartite em outsourcing?
Governança tripartite fraca é fonte de conflitos e perda de visibilidade. oHub conecta você gratuitamente a consultores em outsourcing e especialistas em governança que ajudam a estruturar claramente. Em menos de 3 minutos, descreva seu outsourcing (integrador, subs críticos, problemas atuais) e receba recomendação, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe análise e decide se quer apoio.
Perguntas frequentes
Posso contratar sub-fornecedor diretamente, sem passar por integrador?
Tecnicamente sim, mas não recomendado. Integrador vira intermediário inútil. Melhor: integrador é responsável, mas você tem visibilidade e direito de escalação direta em críticos. Deixar isto claro em contrato.
Como definir SLA em cascata sem ficar muito complexo?
Simples: cliente-integrador tem SLA de empresa. Integrador-sub tem SLA mais apertado (ex: integrador 99.5%, subs devem ser 99.9%+). Assim integrador tem margem. Não precisa listar SLA de cada sub; agregado em contrato.
E se sub-fornecedor quer mudar preço?
Negociação entre integrador + sub-fornecedor. Se impacta contrato com você (ex: integrador repassapreço), integrador deve avisar e negociar com você. Contrato deve deixar claro: reajuste é absorvido por integrador (até limite), depois pode repassar.
Como evitar que integrador vire "caixa preta"?
Documentação clara: (1) lista de subs; (2) visibilidade de métricas; (3) direito de auditoria (você pode ver contrato integrador-sub?); (4) escalação direta em críticos; (5) reunião regular (mensal) incluindo integrador onde você pergunta sobre subs.
Quem paga se sub-fornecedor falha?
Contrato deve deixar claro: integrador é responsável para com você. Se sub falha, integrador paga multa para você (SLA não cumprido). Integrador depois cobra de sub ou absorve custo. Você não deveria pagar diretamente pela falha de sub (você contratou integrador, não sub).
Como estruturar MOU (Memorando de Entendimento) entre 3 partes?
MOU é documento simples (1-2 páginas) que todo mundo assina confirmando: papéis (quem é quem), SLAs (qual é esperado), escalação (como resolver problema), frequência de reunião. Não é contrato legal; é comprometimento. Facilita comunicação entre 3 partes.
Fontes e referências
- ITIL 4: Service Integration and Management (sAM). AXELOS, 2021.
- Forrester: Vendor Risk Management in Complex Ecosystems. Forrester Research, 2023.
- Gartner: Outsourcing Governance Framework. Gartner Research, 2023.
- CETIC.br: Pesquisa Outsourcing e Governança em Empresas Brasileiras. Instituto Brasileiro de Pesquisas, 2023.