Sustentação do Protheus: Guia para Empresas

Veja como estruturar a sustentação do Protheus com SLA, triagem, monitoramento, mudanças controladas e prevenção de incidentes recorrentes na prática.

O que é sustentação do Protheus?

A sustentação do Protheus é a operação contínua que mantém o ERP disponível, seguro, atualizado e aderente aos processos da empresa depois da implantação. Ela combina atendimento a usuários, diagnóstico técnico, correção de falhas, controle de mudanças, manutenção preventiva e gestão do conhecimento.

Na prática, uma boa sustentação não se limita a “apagar incêndios”. Seu objetivo é restaurar o serviço com rapidez quando algo falha, impedir que o mesmo incidente se repita e reduzir o risco das alterações necessárias. Isso exige processo, responsabilidades claras e evidências técnicas — não apenas uma fila de chamados.

Este guia mostra como estruturar esse modelo sem confundir suporte diário com projetos, atualizações de release ou novas customizações.

O que entra — e o que não entra — na sustentação

O primeiro passo é definir o catálogo de atendimento. Sem essa fronteira, solicitações pequenas, incidentes críticos e projetos competem na mesma fila.

Normalmente, a sustentação cobre:

dúvidas de uso e orientação sobre rotinas;
incidentes que interrompem ou degradam processos;
análise de integrações, jobs e erros de processamento;
pequenas correções parametrizáveis;
investigação de recorrências e causas-raiz;
acompanhamento técnico do ambiente;
execução de mudanças padronizadas e de baixo risco;
documentação de soluções conhecidas.

Já uma nova integração, uma mudança extensa de processo, uma implantação de módulo ou uma customização relevante precisa de escopo, estimativa, testes e aceite próprios. Essas demandas podem nascer no suporte, mas devem migrar para uma esteira de projeto.

Também é útil separar quatro tipos de registro:

Incidente: algo que funcionava deixou de funcionar ou perdeu qualidade.
Requisição: pedido padronizado, como acesso autorizado ou ajuste cadastral.
Problema: investigação da causa de um ou mais incidentes recorrentes.
Mudança: alteração planejada em configuração, código, infraestrutura ou integração.

A classificação melhora prioridade, comunicação e métricas. Sem ela, o número bruto de tickets diz pouco sobre a saúde do ERP.

Como definir prioridade e SLA do suporte Protheus

Um SLA útil combina impacto e urgência. A prioridade não deve depender apenas de quem abriu o chamado ou de expressões como “tudo é urgente”.

O impacto pode considerar quantas áreas foram afetadas, se existe alternativa manual, qual processo de negócio está parado e quais obrigações têm prazo. A urgência considera quanto tempo a empresa pode tolerar a interrupção antes de sofrer consequência relevante.

Uma matriz simples pode usar quatro níveis:

Crítico: processo essencial indisponível, sem contorno viável, com impacto amplo ou prazo imediato.
Alto: degradação importante ou área relevante afetada, ainda com alternativa limitada.
Médio: impacto localizado, com contorno operacional aceitável.
Baixo: dúvida, melhoria ou solicitação sem interrupção do negócio.

Defina separadamente os tempos de primeira resposta, início do diagnóstico, atualização ao solicitante e restauração. “Resolver em quatro horas” pode ser inviável quando a causa está em um fornecedor externo ou exige correção de produto; já informar o andamento e aplicar um contorno seguro pode ser mensurável.

O SLA também precisa indicar horário de cobertura, canais autorizados, responsabilidades do cliente, critérios de pausa e forma de escalonamento. Um acordo vago cria expectativa, mas não cria capacidade de atendimento.

A triagem que reduz o tempo de diagnóstico

O ticket deve nascer com contexto suficiente para que outra pessoa consiga reproduzir ou investigar o caso. No mínimo, registre:

empresa, filial, ambiente, módulo e rotina;
data e horário aproximado;
usuário ou perfil afetado;
operação executada e resultado esperado;
mensagem completa de erro;
passos para reproduzir;
abrangência: um usuário, uma filial ou todos;
alterações realizadas antes da falha;
evidências, como captura de tela, identificador da transação e logs pertinentes.

Senhas, tokens, dados pessoais e informações fiscais sensíveis não devem ser copiados indiscriminadamente para o chamado. A coleta precisa seguir o princípio do mínimo necessário, com acesso restrito e prazo de retenção definido.

A documentação oficial da TOTVS mostra que a Central de Diagnóstico do Protheus reúne informações como consumo do AppServer e logs de uso do DBAccess. Esses dados podem acelerar a triagem, mas precisam ser interpretados no contexto do incidente. Um pico isolado não prova a causa.

Para lentidão, o artigo sobre performance do Protheus detalha uma investigação específica. Na sustentação, o ponto central é ter um procedimento repetível de coleta, comparação e escalonamento.

Monitoramento deve acompanhar processos, não só servidores

CPU e memória são importantes, mas não representam sozinhas a experiência do usuário. A operação precisa observar sinais técnicos e de negócio.

Entre os itens técnicos, considere disponibilidade de AppServer e DBAccess, erros de conexão, filas, jobs, integrações, espaço em disco, banco de dados, certificados e crescimento de logs. Entre os sinais de negócio, acompanhe rotinas críticas, processamento de pedidos, emissão fiscal, integrações pendentes e fechamentos.

A documentação de exemplo do AppServer em Linux mostra parâmetros de console, arquivo de log, balanceamento e conexão com DBAccess. Ela é uma referência técnica, não uma configuração para copiar diretamente em produção: topologia, release e requisitos de segurança precisam ser avaliados no ambiente real.

Todo alerta deve ter dono, condição de encerramento e ação esperada. Alertas sem resposta viram ruído; ausência de alertas pode significar apenas que ninguém está observando o processo certo.

Sustentação do Protheus com resposta a incidentes

Quando ocorre uma indisponibilidade relevante, a equipe precisa executar um roteiro conhecido. Uma sequência prática é:

Detectar e registrar: confirmar o evento, seu horário e sua abrangência.
Classificar: definir impacto, urgência, prioridade e responsáveis.
Conter: limitar o efeito sem destruir evidências ou criar um risco maior.
Restaurar: aplicar contorno ou correção validada para recuperar o serviço.
Comunicar: informar estado, impacto, próxima atualização e decisão necessária.
Verificar: confirmar com áreas afetadas que o processo voltou ao normal.
Aprender: registrar causa, ações, lacunas de controle e prevenção.

Para incidentes de segurança, esse fluxo deve se integrar à gestão de risco e ao plano corporativo de resposta. O NIST SP 800-61 Rev. 3, publicado em abril de 2025, trata a resposta a incidentes como parte da gestão contínua de risco, abrangendo preparação, detecção, resposta e recuperação.

É importante preservar a linha do tempo: o que foi observado, quem decidiu, qual mudança foi aplicada e quando o serviço foi validado. Isso reduz discussões baseadas em memória e melhora a análise posterior.

Recorrência exige gestão de problemas

Restaurar o serviço encerra o incidente, mas não necessariamente elimina a causa. Quando a mesma falha retorna, abra um registro de problema e investigue padrões.

A análise pode relacionar horário, módulo, filial, volume, versão, integração, usuário, mudança recente e condição de infraestrutura. Em seguida, formule hipóteses, defina testes controlados e registre evidências que confirmem ou descartem cada uma.

O resultado pode ser uma correção definitiva, uma alteração de processo, um monitoramento adicional ou um erro conhecido com contorno documentado. Se a causa estiver em código personalizado, trate a correção com versionamento, revisão e homologação. Nosso guia de customização do Protheus explica essa governança com mais detalhes.

Evite encerrar a análise com rótulos genéricos como “instabilidade” ou “erro de usuário”. Uma causa útil precisa indicar o mecanismo que produziu o efeito e a ação que reduz sua probabilidade ou impacto.

Mudanças controladas evitam novos incidentes

Uma parte relevante das falhas operacionais nasce de alterações mal preparadas. Mesmo uma mudança pequena deve informar objetivo, itens afetados, risco, dependências, teste, janela, responsável, comunicação e plano de retorno.

Ambientes de desenvolvimento, homologação e produção devem ter funções separadas. O teste precisa representar fluxos reais, integrações e perfis de acesso, sem transformar a produção em laboratório.

Para mudanças repetitivas e de baixo risco, crie modelos pré-aprovados. Para alterações com maior impacto, faça avaliação técnica e de negócio antes da execução. Depois da implantação, verifique indicadores e confirme se o objetivo foi atingido.

Atualizações de release merecem planejamento próprio. A TOTVS informa em seu ciclo de vida da Linha Protheus que releases expirados deixam de receber manutenção regular, salvo condições específicas. Por isso, a sustentação precisa acompanhar o calendário oficial, e não esperar a expiração para iniciar a preparação. Veja também o checklist de atualização do Protheus.

Manutenção preventiva: uma agenda mínima

A rotina preventiva deve ser proporcional à criticidade do ambiente. Uma agenda possível inclui:

Semanalmente:

revisar incidentes críticos, recorrências e backlog envelhecido;
verificar falhas de jobs e integrações;
acompanhar capacidade e crescimento anormal;
confirmar a execução dos controles operacionais definidos.

Mensalmente:

analisar tendências de disponibilidade, tempo de restauração e reincidência;
revisar acessos privilegiados e contas sem uso conforme a política da empresa;
conferir mudanças realizadas e resultados;
atualizar erros conhecidos e procedimentos;
avaliar patches, compatibilidade e pendências técnicas.

Trimestralmente:

revisar o catálogo de serviços e a matriz de criticidade;
testar restauração de backups dentro do escopo de infraestrutura;
exercitar o plano de resposta para cenários relevantes;
revisar release, componentes, integrações e customizações;
atualizar o plano de capacidade e continuidade.

A frequência exata depende de volume, arquitetura, obrigações e tolerância a risco. O valor está na regularidade, na evidência e no tratamento das exceções — não em marcar uma checklist sem analisar resultados.

Métricas que mostram qualidade, não só velocidade

Tempo médio de atendimento, isoladamente, pode incentivar fechamentos rápidos e superficiais. Combine indicadores de fluxo, estabilidade e percepção.

Boas métricas incluem:

tempo até a primeira resposta;
tempo até restauração do serviço;
percentual atendido dentro do SLA por prioridade;
reincidência do mesmo problema;
taxa de reabertura;
idade do backlog;
volume de incidentes causados por mudanças;
proporção de demandas preventivas e reativas;
satisfação do solicitante, com contexto.

Analise tendências por processo, módulo e causa, sem usar o indicador para culpar pessoas. Se o volume de chamados cai porque os usuários desistiram do canal, o número parece bom e o serviço piorou.

Equipe interna, terceirizada ou híbrida?

O modelo interno oferece proximidade com os processos e disponibilidade de conhecimento do negócio, mas pode sofrer com concentração em poucas pessoas. A terceirização amplia especialidades e cobertura contratada, porém exige governança, documentação e acesso seguro. O modelo híbrido costuma separar atendimento próximo ao usuário, especialistas técnicos e escalonamento ao fabricante.

Na seleção de um parceiro, avalie:

experiência compatível com módulos e arquitetura utilizados;
método de triagem, escalonamento e comunicação;
controle de acesso e rastreabilidade;
capacidade de documentar e transferir conhecimento;
regras para código-fonte e artefatos;
métricas, cadência de revisão e plano de continuidade;
clareza sobre o que é sustentação e o que vira projeto.

Uma consultoria Protheus pode apoiar diagnóstico, organização do backlog, governança de mudanças e evolução técnica. Para uma visão independente de riscos, dependências e prioridades, uma avaliação de TI ajuda a transformar percepções em um plano verificável.

Plano de 90 dias para organizar a sustentação

Nos primeiros 30 dias, inventarie módulos, integrações, customizações, responsáveis, ambientes e processos críticos. Defina canais, categorias, prioridades e critérios de escalonamento. Reúna procedimentos existentes e identifique pontos sem dono.

Entre 31 e 60 dias, implante a triagem mínima, estabeleça SLAs realistas, organize o backlog e crie painéis com poucos indicadores. Selecione incidentes recorrentes para análise de causa e documente os contornos conhecidos.

Entre 61 e 90 dias, formalize a agenda preventiva, revise acessos, teste procedimentos de restauração e consolide o fluxo de mudanças. Faça uma reunião de serviço com áreas de negócio para validar resultados, gargalos e próximas prioridades.

O plano deve produzir artefatos concretos: catálogo, matriz de criticidade, árvore de escalonamento, modelos de ticket, runbooks, calendário preventivo e painel de métricas.

Checklist para avaliar o modelo atual

Conclusão: sustentação do Protheus é disciplina operacional

A sustentação do Protheus funciona melhor quando atendimento, monitoramento, incidentes, problemas e mudanças fazem parte do mesmo sistema de gestão. O resultado esperado não é uma fila vazia a qualquer custo, mas um ERP previsível, com decisões rastreáveis e menos recorrência.

Se sua empresa precisa estruturar esse modelo, revisar o backlog ou definir prioridades de evolução, fale com a Mattos Tech Solutions. A conversa inicial pode mapear o cenário atual e indicar os próximos passos sem promessas genéricas.