Como estruturar o modelo de governança de um MSP

Por que terceirizar é fácil; governar é difícil

Muitas relações com MSP fracassam não por incompetência do fornecedor, mas por falta de estrutura clara na relação: quem aprova o quê? Como escala? Como se resolve conflito? Sem isso, cada lado assume coisas diferentes, blame-shifting é comum, e a relação deteriora rápido.

Governança não é burocracia inútil — é ferramenta de operação eficiente que protege ambos os lados. Um MSP bem governado tem visibilidade clara do que é esperado; cliente bem governado tem certeza de que fornecedor está respondendo a demandas de forma ordenada. O retorno é: menos conflitos, menos re-trabalho, mais transparência.

Estrutura típica de governança conta com: comitês (estratégico, operacional), processos formalizados (mudança, incidente, requisição), cadência de reuniões, responsáveis claros, e métricas de desempenho.

Estrutura de comitês: quem participa e com que frequência

Não existe "um" modelo único — tamanho e complexidade da relação determinam. Mas há padrão que funciona bem:

Papéis e responsabilidades

Clareza aqui reduz 80% dos conflitos. Documente quem é responsável por quê e quando.

• Do lado do cliente: Gestor de Fornecedor (ou Service Manager) é o ponto único de contato com MSP. Ele agenda reuniões, distribui decisões, escalona problemas não resolvidos. Recomendação: uma pessoa, não um comitê.
• Do lado do MSP: Account Manager (AM) é responsável pela satisfação do cliente, gestão de relacionamento e articulação interna. Qualidade do AM é crítica — se não funciona, solicite substituição no contrato (cláusula típica permite isso a cada ciclo de renovação).
• Aprovação de mudanças: CAB (Change Advisory Board) é quem aprova alterações. Mínimo: representante do cliente + técnico do MSP. Para mudanças críticas, adicione representes de operacional/negócio.
• Escalação: Defina níveis. Problema não resolvido em 4h sobe para supervisor. Em 8h, para gerente. Isso evita frustração do cliente achando que "ninguém está resolvendo".

Processo de mudanças (CAB e janelas de manutenção)

Change Management é onde maioria dos relacionamentos MSP-cliente pioram. Sem processo claro, um lado faz mudança "sem avisar" e quebra produção do outro.

Estrutura recomendada:

1. Submeter Change Request (CR) com: descrição, impacto, rollback plan, janela de execução proposta
2. CAB avalia em reunião agendada (frequência: semanal para média empresa, bi-semanal para pequena)
3. Aprova ou solicita ajustes
4. Executa em janela agendada com ambos os lados monitorando
5. Documenta resultado (sucesso, rollback, lições) em ata

Ponto crítico: defina "janelas de manutenção" — horários em que mudanças podem ser feitas (ex: 22h a 6h em dias úteis, ou sábado 10h-14h). Fora da janela, exige aprovação executiva.

Comunicação e relatórios

Estabeleça cadência clara de quem comunica o quê para quem.

Resolução de problemas e escalação

Define quem faz o quê quando algo quebra. Sem isso, problema fica perdido entre time técnico do MSP.

Estrutura típica ITIL:

• L1 (Suporte de Nível 1): Primeiro contato, problemas simples (reset de senha, restart de serviço). SLA: 1 hora para resposta, 4 horas para resolução.
• L2 (Especialista): Problemas técnicos (configuração de sistema, troubleshooting de rede). SLA: 2 horas para resposta, 8 horas para resolução.
• L3 (Arquiteto/Principal): Problemas complexos que precisam redesign. SLA: 4 horas para resposta, 2-5 dias para resolução.
• Escalação automática: Se SLA não for cumprido no nível, problema sobe automaticamente para o próximo. Isso força time a priorizar.

Gestão de demandas (requisições que não são problemas)

Ticket não é só "bug" — é também requisição (novo usuário, novo servidor, mudança de configuração). Sem processo, requisições se perdem ou competem com incidentes.

Recomendado: categorizar todo ticket em incidente, requisição ou mudança. Cada um tem workflow próprio.

• Incidente: algo quebrou, precisa de quick fix. SLA curto (1-4h).
• Requisição: novo recurso ou mudança menor. SLA mais longo (1-3 dias). Entra em backlog de planning.
• Mudança: alteração planejada que afeta múltiplos sistemas. Precisa de CAB + janela de manutenção.

Avaliação de desempenho e melhoria contínua

Governança sem avaliação vira teatro. Reserve 10-15min em cada reunião de steering committee para refletir: "O que funciona bem? O que não funciona? O que podemos melhorar?"

Métricas tipicamente monitoradas:

• % de SLAs cumpridos por nível (L1, L2, L3)
• Tempo médio de resolução por tipo de ticket
• Taxa de escalação (% de tickets que sobem para nível seguinte)
• Satisfação do cliente (survey anual com score 0-10)
• Deployment frequency e lead time (se MSP gerencia releases)