Como reduzir incidentes no Protheus: guia de SLA, chamados e NOC 24x7

Ambiente Protheus lento no fechamento fiscal. Chamados que voltam toda semana com a mesma queixa. AppServer reiniciando sem que ninguém saiba o motivo. Se esses cenários fazem parte da rotina da sua equipe de TI, o problema não está no ERP: está na forma como os incidentes são tratados.

Este guia apresenta cinco passos para estruturar a redução de incidentes, desde o mapeamento inicial até a operação com NOC 24x7 integrado ao ERP.

Por que os incidentes se repetem no Protheus

A maioria dos ambientes Protheus opera no modelo reativo: algo quebra, o usuário abre chamado, o time de TI corre para resolver. O problema é resolvido, mas a causa permanece. Semanas depois, o mesmo chamado reaparece.

• Rotinas fiscais travando no fechamento. O SPED Fiscal trava no período mais crítico do mês. O time resolve pontualmente, mas não investiga se a causa é o dimensionamento do AppServer, a concorrência de processos ou uma customização mal otimizada.

• Patches que quebram rotinas existentes. A aplicação de um release TOTVS corrige um problema e cria outro. Sem GMUD estruturada, cada atualização vira uma roleta.

• Filas de jobs acumulando na madrugada. Processos batch que deveriam rodar entre 23h e 5h se acumulam, e o usuário descobre o atraso às 8h, quando tenta emitir uma nota fiscal.

• Dependência de pessoa-chave. Um único analista concentra o conhecimento sobre o ambiente. Quando sai de férias ou muda de empresa, o tempo de resposta dispara.

Nenhum desses é um problema de ERP. São problemas de operação, e se resolvem com processo, monitoramento e governança.

5 passos para reduzir incidentes no ERP Protheus

1. Mapear os incidentes recorrentes por módulo e severidade

O primeiro passo é saber o que está acontecendo. Classifique cada incidente por módulo (Fiscal, Financeiro, Compras, Faturamento, Estoque, RH) e por severidade, usando a escala N1 a N4:

Cruze esses dados com os períodos críticos do calendário fiscal. A concentração de incidentes N3 e N4 nessas janelas indica que o ambiente não está dimensionado para os picos de carga.

2. Definir SLA por severidade com baseline de atendimento

SLA sem baseline é apenas um número no contrato. Para funcionar, o SLA precisa definir o tempo máximo de resposta por nível de severidade e a matriz de escalonamento correspondente.

No SSG (Serviço de Sustentação Groundwork), o SLA é definido por contrato com baseline de tickets. Os indicadores são revisados mensalmente com o cliente para calibrar metas e identificar desvios.

3. Implantar monitoramento proativo do ambiente

O modelo reativo depende do usuário perceber o problema e abrir chamado. O monitoramento proativo detecta a anomalia antes que ela vire incidente. Em um ambiente Protheus, isso significa acompanhar em tempo real:

• Consumo de CPU, memória e disco dos AppServers

• Tempo de resposta de rotinas críticas (SPED, faturamento, folha)

• Filas de jobs e processos batch pendentes

• Conexões ativas, licenças em uso e saúde do banco de dados

O GWMS (Groundwork Monitor Suite) é o único APM para Protheus desenvolvido em parceria com a TOTVS. Ele coleta métricas específicas do ERP, gera dashboards de disponibilidade e performance e dispara alertas contextualizados. A diferença entre um alerta genérico ("servidor com 95% de CPU") e um contextualizado ("rotina SPEDFISCAL travada há 40 minutos no AppServer 03") é a diferença entre reagir e prevenir.

4. Estabelecer NOC 24x7 com escalonamento estruturado

Alertas sem alguém para receber, validar e agir são notificações ignoradas. O NOC (Network Operations Center) é a central de operações que fecha esse ciclo: o monitoramento detecta a anomalia, o NOC recebe o alerta, valida o impacto e aciona o time responsável conforme a matriz de escalonamento. Para incidentes N4, o NOC ativa a War Room com foco exclusivo até a normalização.

A diferença entre um NOC genérico e um NOC integrado ao ERP é o contexto. O NOC genérico monitora infraestrutura: CPU, disco, rede. Ele sabe que o servidor está lento, mas não sabe por quê. O NOC integrado ao ERP entende que a lentidão está na rotina de cálculo de impostos, que o AppServer 03 está com 200 conexões ativas quando o normal são 80, e que o problema começou após a aplicação do patch 12.1.2410.

No modelo Groundwork, o NOC opera integrado ao GWMS. Os alertas chegam com contexto de negócio, o que reduz o tempo de diagnóstico e permite correções antes que o usuário perceba a degradação.

5. Tratar causa raiz e eliminar recorrência

Resolver o incidente é a primeira etapa. Eliminar a causa que o originou é o que reduz o volume de chamados ao longo do tempo. Gestão de incidentes (incident management) restaura o serviço. Gestão de problemas (problem management) investiga por que o serviço caiu e atua para que não caia de novo.

• Análise pós-incidente. Após cada incidente N3 ou N4, registrar causa, tempo de resolução e o que deve mudar.

• Patches fora do horário de pico. Atualizações aplicadas em janelas de manutenção programadas, com plano de rollback documentado.

• Base de conhecimento centralizada. Documentar as soluções de incidentes recorrentes elimina a dependência de pessoa-chave.

• Evolução controlada. Customizações e integrações passam por GMUD antes de entrar em produção.

Quer entender como o NOC da Groundwork funciona integrado ao Protheus? [Fale com um especialista.]

Métricas para acompanhar a redução de incidentes

Cinco indicadores são essenciais para medir a evolução da operação:

O GWMS gera esses indicadores automaticamente via dashboards executivos, atualizados em tempo real.

Perguntas frequentes

Qual a diferença entre NOC e SOC?

O NOC (Network Operations Center) monitora disponibilidade e performance de infraestrutura e aplicações. O SOC (Security Operations Center) monitora ameaças de segurança. São complementares: o NOC garante que o ambiente funcione; o SOC garante que ele esteja protegido.

Quanto tempo leva para reduzir incidentes com NOC 24x7?

Os primeiros resultados aparecem entre 60 e 90 dias, com redução visível nos chamados N3 e N4. A redução consistente do volume total costuma se consolidar entre 4 e 6 meses.

O que é SLA de atendimento no contexto de ERP?

SLA (Service Level Agreement) define os tempos máximos de resposta para cada nível de severidade. No contexto de ERP, o SLA precisa considerar a criticidade do processo de negócio afetado, não apenas a complexidade técnica do chamado.

Como funciona o escalonamento N1 a N4?

N1 é tratado pelo suporte de primeiro nível (dúvidas e configurações). N2 escala para consultor funcional com domínio do módulo. N3 envolve especialistas técnicos e pode exigir apoio da TOTVS. N4 ativa a War Room, com equipe dedicada até a normalização.

É possível monitorar o Protheus sem NOC?

É possível instalar ferramentas de monitoramento e acompanhar alertas internamente. A questão é quem responde quando o alerta dispara às 3h de um domingo. Sem NOC, o alerta fica sem tratamento até o próximo dia útil.

O que é MTTR e por que importa para o ERP?

MTTR (Mean Time to Repair) é o tempo médio entre a detecção do incidente e sua resolução. Um MTTR alto significa que a operação fica parada por mais tempo a cada falha. Reduzi-lo é um dos indicadores mais diretos de melhoria na sustentação.

Se o volume de chamados no seu Protheus não diminui, vale uma conversa. Fale com um especialista em sustentação e monitoramento.