Suporte Protheus: quando contratar
Você já ficou parado porque um processo crítico do Protheus travou em plena janela de faturamento? Ou descobriu que, após uma alteração, relatórios passaram a retornar valores inconsistentes? Essas situações são comuns e geram a mesma pergunta: consigo resolver com a equipe interna ou é hora de contratar uma consultoria especializada?
O que é o suporte ao Protheus na prática
Suporte ao Protheus é o conjunto de ações, procedimentos e responsabilizações para manter o ERP disponível, corrigir falhas e garantir que os processos do negócio continuem funcionando. Não é só “consertar” quando algo quebra — envolve monitoramento, prevenção, aplicação de atualizações, tratamento de incidentes, gestão de mudanças e suporte ao usuário.
Na prática, um serviço de suporte cobre desde chamados simples (recuperar senha, ajustar configuração de usuário) até problemas críticos (erros em cálculos fiscais, falhas em integrações, perda de disponibilidade). O bom suporte desenha processos claros: registro do chamado, classificação por prioridade, diagnóstico, solução, validação e fechamento com lições aprendidas.
Tipos de modelos de suporte e quando cada um faz sentido
- Suporte interno (in-house): ideal para empresas com equipe técnica dedicada, volume de uso previsível e poucas customizações. Mantém conhecimento dentro da companhia, mas pode faltar profundidade diante de problemas complexos.
- Contratação por chamados (time & material): útil para casos esporádicos ou quando precisa de especialistas pontuais. Pagamento por hora/serviço.
- Contrato de consultoria/gestão (managed services): recomendado quando o Protheus é peça central do negócio. A consultoria assume responsabilidades operacionais definidas em SLA, incluindo monitoramento, updates, patches e atendimento 24x7 se necessário.
- Modelo híbrido: equipe interna para suporte de primeiro nível e consultoria para escalonamento L2/L3 e projetos.
Como identificar que é hora de contratar uma consultoria
Alguns sinais apontam que a consultoria já não é um luxo, mas uma necessidade:
- Incidentes frequentes que prejudicam o faturamento ou a entrega (problemas recorrentes em processos críticos).
- Equipe interna sobrecarregada com operação e sem tempo para melhorias (zero capacidade para projetos e prevenção).
- Alta dependência de customizações sem documentação ou autor original disponível.
- Atualizações e patches acumulados por medo de causar impacto — risco jurídico/fiscal em rotinas fiscais.
- Integrações críticas com outros sistemas ou equipamentos cuja falha paralisa operações (balanças, coletores, automação).
O que pedir e avaliar numa consultoria Protheus
Nem todo serviço de “suporte Protheus” é igual. Pergunte e verifique:
- Escopo técnico: quais módulos (SIGAFIS, SIGATF, etc.) e ambientes (desenvolvimento, testes, produção) estarão cobertos.
- Experiência com customizações: peça uma lista de entregas anteriores. Pergunte se conhecem práticas para isolar customizações problemáticas (um parâmetro de configuração usado para isso é IXBLOG — ele permite desativar ou registrar a execução de customizações no AppServer).
- Tratamento de integrações: capacidade para trabalhar com conexões por portas seriais, APIs, Schedulers e serviços de fila; experiência em parametrização usando MV_* (observe que parâmetros com prefixo MV_ ou MV_X_ costumam ser customizações ou parâmetros específicos do ambiente — trate-os como exemplos de ajustes não-padrão).
- Processo de diagnóstico: querem usar logs, tracing, AuditTrail? Uma boa consultoria descreve como vai localizar a causa — por exemplo, audit trail embutido (embedded audit trail) e campos reservados de auditoria (padrão que adiciona campos como ??_USERLGI e ??_USERLGA às tabelas) são usados para rastrear alterações em registros.
- SLA e métricas: tempos de resposta e de resolução para cada severidade, janelas de cobertura (horas úteis vs 24x7), penalidades claras por descumprimento.
- Segurança e acesso: controles para acesso a ambientes produtivos, política de senhas, registro de ações e aprovações para mudanças.
- Transferência de conhecimento: plano de documentação e treinamentos para seu time.
Como estruturar o contrato de suporte — itens essenciais
Um contrato bem escrito evita surpresas. Alguns pontos fundamentais:
- Definição clara de níveis de atendimento (L1: triagem e procedimentos documentados; L2: análise técnica; L3: alterações profundas/execução de fontes).
- Escopo de ambiente coberto (ambiente de produção, homologação, bancos de dados, arquivos RPO, smartclient/appserver, job scheduler).
- Métricas e SLAs: tempos de resposta inicial, tempo de resolução por severidade, disponibilidade mínima, janela para manutenção programada.
- Rotina de backups e recuperação (RTO e RPO definidos).
- Política de mudanças e janelas de deploy; testes e homologação obrigatórios antes de produção.
- Gestão de incidentes: template de abertura de chamado, exigência de registro de causa raiz e plano de ação corretiva.
- Cláusulas de confidencialidade e propriedade intelectual;
- Prazo de vigência e renovação; política de revisão de valores e reajustes.
Diagnóstico prático — passos que trazem resultados rápidos
Ao enfrentar problemas intermitentes ou recorrentes, alguns procedimentos práticos costumam revelar a origem:
- 1) Isolar customizações: usar recurso de execução controlada de customizações (por exemplo, configurando IXBLOG no appserver.ini para NORUN ou LOGRUN) indica se uma função customizada é a origem da falha. Se o problema desaparecer com as customizações desativadas, é sinal que a correção deve começar por aí.
- 2) Atualizar componentes padrão: aplicar LIBs e patches acumulados e rodar compatibilizadores. Às vezes o erro já tem correção oficial em pacotes liberados.
- 3) Registrar logs estratégicos: gravar pontos de interesse (valores de parâmetros, posição de registros nas tabelas, conteúdo de campos) — por exemplo, montar uma rotina que escreva em arquivo de log quando determinadas tabelas ou parâmetros são acessados. Isso ajuda quando o problema ocorre fora do horário do time ou é intermitente.
Auditoria e logging: o que usar e como interpretar
Para documentação de alterações e investigação de incidentes existem dois níveis úteis no Protheus:
- Campos reservados de auditoria (simples): adicionam metadados de inclusão e última alteração em cada registro e seguem um padrão com sufixos parecidos com ??_USERLGI e ??_USERLGA — úteis para saber quem alterou um registro e quando.
- Audit trail completo (embedded audit trail): registra todo o histórico de modificações em uma tabela, com detalhe de conteúdo antigo e novo, usuário, data/hora e tipo de operação. Essa configuração é feita via SIGACFG e permite ativar auditoria por tabela conforme necessidade.
Além disso, logs de execução (traces do AppServer, arquivos de Scheduler e logs gerados por rotinas customizadas) são essenciais. Uma boa prática é centralizar logs e ter procedimentos de retenção e rotação para não ocupar espaço crítico em disco.
Customizações: identificar, documentar e governar
Customizações são um dos maiores drivers de custo e risco. Antes de contratar suporte, faça um inventário mínimo:
- Lista de funções customizadas (nomes de user functions ou funções iniciadas por u_ ou z — exemplificando, funções como u_zCriaLog ou zCriaLog representam customizações típicas).
- Tabelas extras e campos Z* (por exemplo, tabelas chamadas ZD0 com campos ZD0_SEQ, ZD0_USRCOD em projetos de log são comuns como exemplos de implementação própria).
- Parâmetros MV_* e MV_X_* que alteram comportamentos do sistema (esses MV_ com prefixo costumam indicar parâmetros do ambiente ou customizados).
- Integrações externas e scripts de automação (schedulings, bat jobs, Schedulers do Protheus).
Governança de customização exige:
- Repositório único de fontes (RPO) e versão controlada.
- Documentação mínima por entrega: objetivo, ponto de entrada, dependências, testes executados.
- Mecanismo de desativação rápida (por exemplo, usar IXBLOG para desabilitar execução automática de customizações em casos críticos).
Monitoramento e automação operacional
Suporte eficiente depende de monitoramento que alerte antes de o problema afetar o negócio. Algumas ações recomendadas:
- Monitorar serviços do AppServer e smartclient; criar alertas de saúde para conexões, threads e filas.
- Verificar jobs agendados pelo Scheduler do Protheus: monitorar sucessos/falhas e tempo médio de execução.
- Automatizar verificações de integridade (checagens em tabelas críticas, validação de números sequenciais).
- Enviar notificações automatizadas por e-mail: a aplicação possui classes para envio de e-mail (por exemplo, recursos semelhantes à classe TMailManager) — útil para avisos de erro e alertas operacionais.
Como organizar o time interno para trabalhar com a consultoria
Uma parceria eficiente exige papel claro entre time interno e consultoria:
- Responsabilidades claras: quem abre o chamado, quem valida a solução, quem autoriza deploy em produção.
- Matriz de contatos: lista com substitutos, horários e níveis de autorização.
- Ambientes separados: produção, homologação e desenvolvimento. Testes e validações obrigatórias antes de qualquer alteração em produção.
- Runbooks e playbooks: scripts e procedimentos passo a passo para incidentes comuns (restaurar backup, reiniciar AppServer, aplicar patch crítico). A consultoria deve entregar ou colaborar para produzir esses materiais.
Indicadores e relatórios que valem acompanhar
Peça à consultoria relatórios mensais e dashboards simples com:
- Número de incidentes por severidade e tempo médio de resolução (MTTR).
- Tempo de resposta no SLA e percentuais de cumprimento.
- Top 10 causas de chamados (customização, integração, configuração, erro humano, infra).
- Status de patches e atualizações aplicadas; pendências e riscos.
- Melhorias entregues e itens em backlog.
Checklist prático para contratar: o que reunir antes da proposta
Antes de solicitar propostas, prepare:
- Inventário do ambiente: versões do Protheus, LIB aplicada, RPOs, módulos em uso, número de empresas/filiais cadastradas.
- Lista de customizações (funções u_ ou z_, tabelas Z*, parâmetros MV_*).
- Fluxos críticos de negócio e janelas de maior impacto (horários de fechamento, geração fiscal, picos de vendas).
- Política atual de backups e plano de recuperação.
- Ferramentas de integração e equipamentos (balanças, coletores, ERPs externos) e como se conectam (ports seriais, APIs, arquivos).
Boas práticas contínuas que o suporte deve promover
Um bom serviço vai além de apagar incêndio e deve estabelecer rotina de maturidade:
- Rodar atualizações e pacotes de correção em ambiente de homologação antes de produção.
- Documentar e versionar todo código customizado; evitar "autor único" sem documentação.
- Ter testes automatizados (mesmo que simples) para processos críticos.
- Rever parametrizações periódicas (parâmetros MV_* e MV_X_* frequentemente acumulam ajustes e esquecimentos).
- Treinar usuários e elaborar base de conhecimento com FAQs e soluções de baixa complexidade.
Custos e prazos: como pensar na proposta
Modelos de precificação variam:
- Retainer mensal: valor fixo para um pacote de horas e SLA — traz previsibilidade e prioridade no atendimento.
- Time & material: cobrança por hora; adequado para demandas imprevisíveis, mas pode sair mais caro para volume constante.
- Projeto de saúde do ambiente: avaliação inicial (inventory & health-check) com proposta de correções e roadmap — investe na redução de incidentes futuros.
Negocie prazos escalonados para entregas (ex.: plano de 30/60/90 dias) e metas claras de redução de incidentes e tempo de resposta. Um contrato inicial com avaliação de 90 dias permite ajustar expectativas antes de compromisso mais longo.
Exemplo real — como uma investigação pode seguir
Imagine falha intermitente na confirmação de pedidos durante picos. Um fluxo de investigação típico seria:
- Reproduzir o erro em ambiente de homologação durante carga similar.
- Usar configuração de logs e tracing no AppServer; caso haja customizações, usar mecanismo que permita desabilitá-las temporariamente (IXBLOG com NORUN/LOGRUN).
- Se customização for detectada como causa, identificar a função (por exemplo, uma função custom chamada u_zCriaLog em um ponto de entrada) e testar versão corrigida localmente.
- Se for problema padrão, aplicar patch/LIBs e testar; em paralelo, registrar auditoria nas tabelas envolvidas para verificar dados de entrada (audit trail ou campos reservados como ??_USERLGA).
- Fechar o chamado com documentação do root cause e aplicar ação preventiva (ajuste de parâmetro MV_*, melhorias no runbook, implantação de monitoramento).
Conclusão — tomar a decisão certa
Contratar uma consultoria Protheus é decisão estratégica. Se sua operação depende do ERP para faturamento, compliance fiscal e logística, o investimento em um parceiro com SLAs claros, experiência em customizações e capacidade de fazer transferência de conhecimento costuma se pagar rápido em redução de risco e tempo de inatividade.
Se estiver em dúvida, priorize um diagnóstico (health-check) inicial com proposta de melhorias. Esse trabalho revela os pontos de falha, define urgências e ajuda a comparar propostas de suporte com base em prioridades reais do seu ambiente.
Lembre-se: suporte eficiente é previsibilidade, documentação e comunicação — não apenas resolver o problema do dia.
