Como este tema funciona na sua empresa
Poucos contratos — frequentemente com hospedagem ou suporte básico. O desafio é que muitos são assinados sem clareza sobre SLA, resultando em conflitos quando algo falha. Abordagem: contrato simples com SLA básico (tempo de resposta e disponibilidade), monitoramento informal com o fornecedor.
Múltiplos contratos descentralizados — hospedagem, suporte, desenvolvimento, consultoria. O risco é que cada área assina com o seu fornecedor sem visão consolidada. Abordagem: contrato padrão com SLA estruturado, responsável designado por categoria de fornecedor, reunião trimestral de avaliação.
Múltiplos fornecedores críticos com integração operacional complexa. SLAs em cascata e interdependências. O desafio é gerenciar risco de fornecedor e integração entre eles. Abordagem: contrato estruturado com SLA em cascata, governança formal de fornecedor, auditorias periódicas, plano de risco.
Governança de contratos de TI é o conjunto de processos, papéis e controles que garantem que os contratos com fornecedores de tecnologia entregam valor, cumprem o acordado e protegem a empresa de riscos. Inclui definição clara de escopo, SLA monitorável, estrutura de governança do fornecedor e procedimento de resolução de disputas.
Por que contrato bem estruturado importa em TI
Um contrato mal estruturado é como colocar um time em campo sem estratégia — todos estão ocupados, mas ninguém sabe o que vencer significa. Muitos contratos de TI são assinados com definições vagas: "suporte rápido", "sistema disponível", "resposta em tempo razoável". Na prática, o que é rápido para o cliente pode ser lento para o fornecedor, e disputas aparecem quando algo falha.
Contrato bem estruturado é benefício mútuo: fornecedor sabe exatamente o que é esperado e pode planejar recursos; cliente tem clareza de serviço e pode monitorar cumprimento. Segundo frameworks de gestão de fornecedor como ITIL 4, a qualidade do contrato é o primeiro determinante da qualidade do serviço[1].
Elementos essenciais do contrato de TI
Um contrato deve conter cinco elementos críticos: escopo, SLA, termos financeiros, propriedade de dados e terminação. Cada um tem implicações diferentes por porte de empresa.
Escopo: defina com precisão o que entra e o que não entra
Escopo é a descrição do que o fornecedor vai fazer. Muitos contratos são genéricos — "suporte em TI" — sem detalhe de quais sistemas, em qual horário, ou qual a prioridade de cada solicitação. O resultado é que ambas as partes interpretam diferente.
Escopo bem feito inclui: sistemas cobertos (quais infraestruturas, aplicações, dados), horário de funcionamento (24/7 ou horário comercial), prioridades de solicitação (crítica em 2 horas, normal em 24 horas), exclusões (o que não entra — terceiro fornecedor, custom development não incluído), e direitos sobre código ou configuração produzida.
Escopo simples: "Suporte a hospedagem da aplicação X em servidor na nuvem, horário comercial, máximo 8 horas para primeira resposta". Não precisa de detalhe extremo, mas deve ser claro e mensurável.
Escopo segmentado por serviço: escopo para hospedagem, outro para suporte nível 1, outro para desenvolvimento. Cada um com detalhes de sistemas, horários e prioridades específicas.
Escopo multi-camadas: infraestrutura central, aplicações críticas, plataformas de dados. Cada serviço com escopo detalhado, dependências documentadas, e critério claro de escalação entre fornecedores.
SLA: métricas claras e alcançáveis
SLA (Service Level Agreement) define as métricas que o serviço será medido. Bons SLAs têm três características: mensuráveis (você consegue verificar se foi cumprido), realistas (o fornecedor consegue cumprir) e relevantes (importam para o negócio).
As métricas mais comuns são: disponibilidade (% de tempo que o sistema fica ativo), tempo de resposta (quanto tempo leva para fornecedor responder a um problema), e tempo de resolução (quanto tempo para resolver completamente). Para serviços críticos, adicionar RTO (Recovery Time Objective — tempo máximo para recuperar) e RPO (Recovery Point Objective — perda de dados máxima aceitável).
O erro comum é criar SLAs muito rigorosos que o fornecedor não consegue cumprir. Se o contrato promete 99,99% de disponibilidade (menos de 1 hora de parada por ano) mas a infraestrutura não suporta, você nunca receberá crédito e o relacionamento deteriora. SLA realista é melhor que promessa impossível.
2-3 métricas: disponibilidade 99% (máximo 7 horas/mês), primeira resposta em 4 horas, resolução em 24 horas. Simples e viável.
5-10 métricas por serviço: disponibilidade diferenciada por criticidade (99% para não-crítico, 99.5% para crítico), tempo de resposta por prioridade, tempo de resolução, qualidade (bugs entregues em desenvolvimento).
15+ métricas em cascata: SLA de infraestrutura que alimenta SLA de aplicação que alimenta SLA de negócio. Métricas de resiliência, segurança, performance além de disponibilidade.
Como monitorar SLA: da promessa à evidência
Monitorar significa medir regularmente se o fornecedor cumpre o SLA. Surpreendentemente, muitos contratos não definem como isso vai ser feito — quem mede, com qual ferramenta, quando reporta.
Monitoramento eficaz exige: fonte de verdade (quem mede — pode ser ferramenta de monitoramento, fornecedor reporta, ou cliente valida), frequência (diário para crítico, mensal para genérico), formato de reporte (formato acordado que facilita análise), e ação corretiva (o que acontece se o SLA não for cumprido).
A ITIL 4 reforça que monitoramento deve ser contínuo, não apenas quando algo falha — permite detectar tendência de degradação antes de virar incidente[1].
Estrutura de governança: quem faz o quê
Governança de contrato é quem toma decisão sobre o fornecedor. Incluir papéis, frequência de reunião e escalação.
Papéis essenciais: gestor de fornecedor (acompanha dia-a-dia, resolve problemas operacionais), responsável de negócio (o proprietário do serviço — decide prioridades), TI (operacional — executa ações), financeiro (acompanha custo, adicionais). Em pequena empresa, uma pessoa pode ter múltiplos papéis.
Reuniões estruturadas definem frequência: operacional (semanal se crítico, mensal se normal), de gestão (mensal para revisar SLA, incidentes, satisfação), de revisão (trimestral ou anual para avaliar continuar ou renegociar contrato).
Reunião mensal de 30 minutos: status, problemas, próximas prioridades. Frequência simples, presença de quem toma decisão.
Reunião operacional mensal (TI com fornecedor), reunião trimestral com stakeholders (avaliar SLA, satisfação, roadmap). Responsável por fornecedor documenta e comunica desvios.
Reunião operacional semanal (crítico), reunião mensal de gestão (SLA, riscos, escalação), reunião trimestral executiva (strategic review, renovação, renegociação). Comitê de fornecedores consolida visão.
Negociação de contrato: o básico
Negociar contrato não é apenas sobre preço — é sobre risco, escopo e sustentabilidade. Uma negociação bem feita evita conflitos meses depois.
Pontos-chave a negociar: SLA realista (você consegue medir? Fornecedor consegue cumprir?), penalidades por não-cumprimento (crédito se falhar, mas penalidade excessiva pressiona demais), termos de renovação (contrato de 1, 2 ou 3 anos? Renovação automática ou renegociação?), propriedade de dados (se você sair, consegue levar seus dados?), e cláusula de saída (como terminar contrato se não funcionar).
Resolução de disputa: quando SLA não é cumprido
Quando fornecedor falha no SLA, duas coisas acontecem: técnica (entender por que falhou e corrigir) e comercial (qual é a consequência — crédito, multa, terminação).
Disputa bem-resolvida segue processo claro: 1) fornecedor reporta falha imediatamente (se SLA foi quebrado, não esconder); 2) análise de causa raiz (foi erro do fornecedor ou causa externa?); 3) crédito ou multa aplicado conforme contrato (se foi erro, credita; se não, não); 4) plano de ação para não repetir.
Muitos conflitos acontecem porque o contrato é vago sobre culpa — se sistema foi derrubado por ataque DDoS, quem é responsável? Contrato claro distingue: falha operacional do fornecedor (aplicável SLA) versus incidente de segurança (exceção, não conta contra SLA).
Sinais de que seu contrato de TI precisa ser renegociado
Se você se reconhece em três ou mais cenários abaixo, é provável que o contrato atual não está suportando a estratégia de TI.
- SLA foi cumprido em forma (números existem) mas não em substância (negócio continua insatisfeito)
- Fornecedor tem frequentes disputas sobre o que "entra" e o que "não entra" no escopo
- Você não consegue encontrar o contrato ou não lembra dos termos exatamente
- Prioridade de demandas é constantemente renegociada; não há critério claro
- Fornecedor foi trocado (ou precisa ser trocado) mas o conhecimento e dados ficaram retidos
- Mensal, há discussão sobre que problema "é de quem" — TI interna ou fornecedor
- Custo está crescendo mas benefício não é claro
Caminhos para estruturar contratos de TI
Estruturar contratos pode ser feito internamente pelo próprio gestor de TI, ou com apoio externo de consultoria jurídica e de TI.
Viável quando o gestor de TI tem tempo e base de conhecimento em contratos.
- Perfil necessário: gestor de TI com experiência em negociação ou profissional de procurement
- Tempo estimado: 1 a 2 meses para estruturar contrato novo, renegociar existente
- Faz sentido quando: empresa tem experiência prévia, contrato é relativamente simples
- Risco principal: contrato pode ter brechas legais ou deixar riscos descobertos
Indicado para contratos complexos ou primeira vez estruturando contrato de fornecedor crítico.
- Tipo de fornecedor: Consultoria jurídica especializada em TI ou Consultoria de Gestão de Fornecedor
- Vantagem: experiência em padrões de mercado, proteção legal, SLAs realistas
- Faz sentido quando: contrato é crítico ou valores altos estão envolvidos
- Resultado típico: em 4 a 8 semanas, contrato estruturado com SLA, termos claros, governança definida
Precisa estruturar contrato de TI com fornecedor?
Se contrato com fornecedor é prioridade, o oHub conecta você gratuitamente a consultorias de TI e jurídica especializadas em governança de contrato. Em menos de 3 minutos, você descreve a necessidade e recebe propostas personalizadas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como estruturar contrato de TI com fornecedor?
Contrato bem estruturado inclui: escopo claro (o que entra e não entra), SLA mensurável e realista (disponibilidade, tempo de resposta, resolução), papéis definidos (quem é responsável por quê), frequência de revisão (reuniões operacionais e trimestrais), e processo de resolução de disputa. Comece com template padrão e adapte para sua realidade.
O que deve conter um SLA de TI?
SLA deve conter: métrica (disponibilidade, tempo de resposta, tempo de resolução), target (ex: 99% disponibilidade), exclusões (incidentes que não contam contra SLA), e consequência de não-cumprimento (crédito de horas de suporte, redução de pagamento). Mantenha SLA simples e realizável — com 3 a 5 métricas bem acompanhadas é melhor que 20 métricas não monitoradas.
Como monitorar cumprimento de SLA?
Monitorar exige: fonte de dados (ferramenta de monitoramento ou fornecedor reporta), frequência (diário para crítico, mensal para genérico), formato (tabela ou dashboard que ambos veem), e ação corretiva (reunião mensal para discutir desvios). Automatizar coleta de dados reduz discussão e aumenta confiança.
Como negociar contrato de TI com fornecedor?
Negocie com base em realidade: dados de SLA históricas (se existe fornecedor atual, use histórico de performance), benchmarks de mercado (quanto custa esse serviço em média), e valor de negócio (qual é o impacto se falhar). Negocie escopo e SLA realistas, não preço apertado que pressiona qualidade.
Como gerir fornecedor de TI de forma eficaz?
Gestão eficaz exige: reunião regular (mensal mínimo), agenda clara (status, problemas, prioridades), monitoramento de SLA, e comunicação transparente. Respeite o fornecedor, reconheça quando cumpre bem, e aborde problemas de forma colaborativa — bom relacionamento é fundamental para sucesso de longo prazo.
Qual é o impacto de contrato ruim em TI?
Contrato ruim resulta em: falta de clareza sobre responsabilidades (quem faz o quê fica ambíguo), SLA não-monitorado ou não-cumprido (você paga sem garantias), conflitos frequentes sobre escopo, dificuldade de trocar fornecedor (dados ou conhecimento retido), e finalmente insatisfação de negócio com serviço de TI.