AMS e Protheus
Um chamado crítico fica aberto além do prazo contratado, o financeiro já recebeu multa por atraso e ninguém consegue rastrear quem escalou a demanda: como garantir que o suporte ao Protheus cumpra SLAs e mantenha rastreabilidade operacional? Essa é a dor diária de muitas equipes de TI responsáveis pelo ERP.
O que entendemos por AMS no contexto do ERP
No jargão de fornecedores e consultorias, AMS (Application Management Services) é o conjunto de serviços responsáveis por operar, manter e evoluir aplicações críticas — aqui, o Protheus. Em prática operacional, AMS cobre triagem de incidentes, resolução de problemas, execução de correções, gestão de mudanças simples, manutenção preventiva e a governança de contratos de suporte com métricas de SLA.
No âmbito do ERP, AMS não é apenas um service desk: exige integração com objetos do sistema (cadastros e tabelas), processos automatizados (jobs, agendadores), rotinas de notificação e regras que permitam auditar todo o ciclo de vida dos chamados e ações realizadas sobre o sistema.
Tabelas e artefatos do Protheus relevantes para AMS
- SA1 — tabela de cadastro de clientes (útil para identificar solicitante/empresa quando o próprio ERP é o objeto do chamado).
- SC5 e SC6 — tabelas de pedido (cabeçalho e itens); servem como referência quando incidentes impactam processos comerciais.
- SI1 — plano de contas e demais tabelas contábeis (importante quando o incidente afeta apurações ou integrações fiscais).
- SX6 — tabela de parâmetros do ambiente; frequentemente usada para armazenar flags e controles que influenciam comportamento de integrações e rotinas operacionais.
- Conjunto SK* — várias tabelas com prefixo SK relacionadas a teleatendimento, registro de SLA, contratos e modelos de atendimento. Exemplos que aparecem no ambiente padrão incluem SK5 (registros de SLA correntes), SK6 (contrato de SLA), SK7 (entidades associadas ao SLA), SK9 (prazos por severidade) e SKA (modelos de atendimento).
Conhecer essas tabelas é requisito para qualquer operação de AMS que precise auditar causalidade, histórico e impactos de chamados; elas servem como fonte para relatórios de conformidade e indicadores.
Elementos técnicos que compõem a solução AMS integrada ao Protheus
Arquitetonicamente, uma solução AMS eficiente sobre Protheus combina:
- Mecanismo de filas e orquestração (jobs do Scheduler do Protheus ou agendador externo) para processamento assíncrono de integrações e rotinas de reconciliação.
- Mecanismos de integração (REST/serviços) e adaptadores que alimentam o ERP com dados de sistemas de service desk.
- Componentes de notificação e envio de e‑mail; internamente, a plataforma disponibiliza classes para comunicação com servidores de e‑mail, como mecanismos que suportam SMTP/SMTPS/TLS, POP/IMAP etc.
- Logs e auditoria persistidos em tabelas do ERP, além de logs operacionais gerados por appserver/SmartClient e processos job.
Do ponto de vista de implantação, componentes que costumam aparecer são SmartClient (ou variantes Web/Electron), appserver configurado para um ambiente de jobs dedicado (pastas como apo_job e appserver_job são práticas adotadas para isolar agendamentos), e o uso do appserver.ini para configurar ambientes de execução dos jobs.
Fluxos de atendimento e modelos de SLA aplicáveis
Um fluxo AMS típico integrado ao Protheus segue etapas bem definidas para garantir rastreabilidade e cumprimento de SLAs:
- Ingestão do chamado: pode ocorrer via portal de service desk, e‑mail ou integração direta. No caso de integração automática, um conector insere metadados relevantes nas tabelas SK* (contrato, severidade, tempo alvo).
- Triagem e classificação: campos de severidade e categoria alimentam regras que determinam prazos (ex.: SK9 contem prazos por severidade).
- Encaminhamento e execução: ações técnicas são acionadas (correção em ambiente sandbox, hotfix, job de reconciliação) e os passos são registrados para auditoria.
- Monitoramento do SLA: jobs periódicos verificam registros de SLA correntes (por exemplo, linhas em SK5) e geram alertas quando há risco de violação.
- Fechamento e validação: fechamento só após validação funcional e registro em tabelas de resposta ou log; geração de relatórios de conformidade.
Esse desenho exige que o AMS tenha visibilidade das tabelas de SLA e contratos para poder calcular prazos remanescentes e acionar notificações automáticas quando necessário.
Integrações técnicas: padrões e meios de comunicação com Protheus
Existem duas frentes principais de integração que um AMS deve dominar ao trabalhar com Protheus:
- Integração assíncrona via filas e jobs: o Scheduler do Protheus permite configurar rotinas periódicas; é comum criar um ambiente separado (apo_job/appserver_job) para executar jobs sem impactar cargas transacionais. Jobs identificados por códigos específicos processam lotes de integrações e atualizam tabelas, produzindo logs processuais.
- Integração síncrona via serviços e APIs: a arquitetura atual do Protheus suporta serviços REST e mecanismos multi‑protocolo que permitem chamadas de sistemas externos. A Porta Multiprotocolo concentra comunicações e facilita o uso de SmartClient, SmartClient WebApp, serviços REST e outros componentes.
Na prática, um AMS implementa um conector que:
- Recebe eventos do tool de service desk (criação, mudança de severidade, comentário) e persiste referências no Protheus (registros SK*).
- Consulta o Protheus para extrair informações de contexto (ex.: SA1 para identificação do cliente, SC5/SC6 para pedidos afetados).
- Aciona jobs para tarefas de correção ou reconciliamento e consome logs resultantes para atualizar o estado do chamado no sistema de origem.
Notificações, alertas e integração de e‑mail
A camada de notificação é essencial para cumprimento de SLA. A plataforma disponibiliza bibliotecas para envio de e‑mail em diferentes protocolos (SMTP, SMTPS, TLS), o que permite ao AMS enviar avisos automáticos quando um chamado atingir determinado limiar temporal.
Boas práticas operacionais:
- Padronizar templates de e‑mail e regras de disparo para evitar ruído e garantir que só notificações relevantes sejam enviadas.
- Centralizar envio por um serviço de mail manager para controlar autenticação, filas e tentativas de reenvio, além de registrar entregas e falhas.
- Integrar notificações com ações automáticas (por exemplo, criar um job quando um chamado estiver a X horas do vencimento).
Parametrização e governança: como controlar comportamentos do AMS
O controle fino do AMS passa por parâmetros globais e configurações. No Protheus, SX6 é a tabela central onde vários parâmetros de ambiente são mantidos; a leitura e ajustes desses parâmetros permitem toggles operacionais que influenciam como integrações e rotinas se comportam.
Observações importantes sobre customizações:
- Parâmetros cujo nome contém MV_X_ costumam ser exemplos de customizações locais; ao documentar ou automatizar processos, deixe claro quando um parâmetro é uma extensão implementada pela equipe versus um parâmetro padrão do sistema.
- Funções com prefixo U_ ou com nomes iniciando por "z" costumam indicar rotinas customizadas. Distinga claramente ações executadas por código padrão do ERP das implementações locais.
Essa distinção é crítica para AMS porque parametrizações customizadas impactam atualizações e patches; procedimentos de manutenção devem prever como preservar ou migrar essas chaves e rotinas durante rollouts.
Logs, auditoria e evidências para gestão de contratos
Uma operação AMS madura precisa gerar evidências que sustentem métricas de SLA e apontem responsabilidade em caso de não conformidade. Para isso, use:
- Registros detalhados em tabelas de SLA (SK5/SK6) com timestamps de cada evento relevante.
- Logs do Scheduler e do appserver, mantendo histórico de execução de jobs e retornos de erro para troubleshooting.
- Relatórios consolidados que correlacionem incidentes com transações afetadas (consulta a SA1/SC5/SC6/SI1 conforme contexto).
Além do armazenamento, é necessário definir retenção, mecanismos de compactação e rotinas de exportação para auditoria externa quando o contrato exigir prova de atendimento.
Boas práticas para automação e prevenção
Automação inteligente reduz reincidência e aumenta previsibilidade operacional. Recomendações:
- Automatizar verificações periódicas que identifiquem inconsistências entre cadastros e movimentações — por exemplo, reconciliações noturnas por job que geram tickets automáticos quando detectam bloqueios ou divergências.
- Implementar sondas de integridade (health checks) que monitoram componentes críticos (appserver, filas, conectividade SMTP) e geram alertas antes que o impacto atinja o negócio.
- Usar modelos de atendimento (SKA) padronizados para reduzir variação de diagnóstico e acelerar a resolução.
Governança de mudanças e patches: separar ambiente de produção e jobs
Para reduzir risco durante atualizações, o AMS deve adotar segregação de ambientes e práticas operacionais específicas:
- Executar jobs de integração e testes em instâncias isoladas (ex.: pastas appserver_job/apo_job) que replicam o appserver de produção; isso evita que testes sobrecarreguem o ambiente produtivo.
- Controlar deploy de rotinas customizadas U_* com versões e compatibilizadores; documentar dependências em SX6 ou tabelas equivalentes.
- Testar compatibilidade com processos de atualização do fornecedor antes de aplicar patches, principalmente quando a solução contém customizações que alteram fluxos de dados.
Modelo operacional proposto para equipes AMS que suportam Protheus
Um modelo operacional robusto combina três camadas:
- Camada de operação: triagem, resolução de incidentes, execução de jobs e manutenção de rotina. Responsável por cumprir SLAs operacionais e registrar evidências.
- Camada de integração: desenvolvimento e manutenção de conectores, orquestração de jobs, filas e adaptadores REST; é quem garante comunicação confiável entre service desk e Protheus.
- Camada de governança e melhoria contínua: gerencia contratos, analisa KPIs (tempo médio de atendimento, taxa de violação de SLA) e conduz ações estruturantes para reduzir incidências recorrentes.
Na prática, responsabilidades e hipóteses de trabalho precisam mapear elementos técnicos explicitados anteriormente: tabelas SK* para SLA/contratos, SX6 para parâmetros, SA1/SC5/SC6/SI1 para contexto de negócio, e o uso de mail manager para notificações.
Checklist técnico para implantação ou evolução de AMS sobre Protheus
- Inventariar tabelas que serão envolvidas no processo de suporte (SK5, SK6, SK7, SK9, SA1, SC5, SC6, SI1, SX6).
- Definir modelo de ingestão de chamados (API REST vs e‑mail vs portal) e desenhar conector de entrada.
- Criar jobs de monitoramento de SLA e configurá‑los em ambiente de jobs dedicado (isolar em appserver_job/apo_job).
- Configurar serviço de notificação via mail manager e validar entrega de alertas em cenários de falha.
- Documentar parametrizações e destacar itens customizados (MV_X_*, U_*, z*) para mitigar riscos em atualizações.
- Implementar logs estruturados e relatórios gerenciais com evidências para contratos.
Exemplo prático (padrão, conceitual) de ação automatizada
Imagine que uma rotina noturna verifica integridade de duplicatas financeiras e encontra divergência que pode gerar bloqueio fiscal. Fluxo conceitual:
- Job noturno executa verificação e grava incidente em SK5 com severidade alta.
- Regra de triagem identifica SLA crítico (consultando SK9) e aciona alerta via mail manager para equipe de finanças e AMS.
- Se não houver intervenção em X horas, outro job gera ação preventiva: bloqueio parcial de entrada de notas em filas não críticas, e registra tentativa de mitigação em tabela de log.
- Após correção, os timestamps de resolução são gravados e o chamado é fechado com evidências armazenadas para auditoria.
Esse exemplo usa componentes padrão de integração e job orchestration; a implementação concreta dependerá da topologia do ambiente e do escopo do contrato de AMS.
Riscos comuns e como mitigá‑los
Principais riscos detectados em operações AMS:
- Dependência excessiva de rotinas customizadas sem documentação — mitigar com inventário e testes automatizados.
- Falta de isolamento entre jobs e processamento transacional — mitigar com pastas de job separadas e limites de recursos.
- Notificações redundantes ou sem prioridade — mitigar com definição clara de thresholds e templates de notificação.
- Ausência de evidência para SLA — mitigar com logs detalhados em tabelas de SLA e relatórios periódicos.
Conclusão técnica e próximos passos para equipes de AMS
AMS é uma disciplina operacional que combina governança, automação e domínio técnico do ERP. Para o Protheus, isso significa mapear tabelas e parâmetros relevantes (como as tabelas SK* para SLA e SX6 para parâmetros), isolar jobs críticos em ambientes dedicados, e integrar de forma confiável com o layer de service desk via APIs ou filas.
Priorize três eixos iniciais: (1) inventário e classificação das customizações; (2) implementação de jobs e monitoramento automatizado; (3) estrutura de notificações com evidência. Com isso a operação reduz risco de violação de contrato e melhora previsibilidade para o negócio.
