Suporte de ERP após o go-live: não depender de uma pessoa

A maioria das implementações de ERP tem um plano bem definido até ao go-live e quase nada definido depois dele. O contrato do partner de implementação termina, a equipa de projeto dissolve-se e o suporte passa discretamente a ser responsabilidade da pessoa interna que por acaso esteve mais envolvida durante o projeto — normalmente porque era quem melhor compreendia o sistema, e não porque alguém tenha decidido deliberadamente que devia assumir o seu suporte de futuro.

Isto funciona por algum tempo, porque essa pessoa conhece genuinamente bem o sistema. Deixa de funcionar no momento em que goza uma licença prolongada, muda de funções ou sai da empresa, e é então que a organização descobre que uma quantidade substancial de conhecimento operacional existia apenas na cabeça de uma pessoa, nunca foi documentada e não tem plano de sucessão. É uma falha inteiramente previsível e é previsível precisamente por ser comum — a maioria das empresas mid-market com que trabalhamos já viveu alguma versão desta situação, habitualmente mais de uma vez.

Este artigo é sobre construir um modelo de suporte de forma deliberada, antes do go-live e não depois de a lacuna se tornar visível.

Por que motivo isto importa

O custo imediato de um suporte não documentado e dependente de uma só pessoa é a fragilidade operacional: uma pergunta que deveria levar uma hora a responder leva dias porque a única pessoa capaz de a responder está indisponível e todos os outros estão a reconstruir a lógica a partir do zero.

O custo acumulado é pior. Cada melhoria, alteração de configuração e solução de contorno feita informalmente por essa pessoa, sem documentação, torna-se dívida técnica indistinguível do problema de acumulação de customização abordado noutro artigo desta série — exceto que aqui se acumula na memória institucional e não no código, o que é possivelmente mais difícil de recuperar, porque não há registo para auditar nem código para ler. Quando essa pessoa acaba por sair, a organização não perde apenas uma pessoa: perde um mapa não documentado do seu próprio sistema.

Há também uma dimensão de governação. Um sistema cujo funcionamento depende de conhecimento tácito detido por um único indivíduo é uma debilidade de controlo que se torna visível no pior momento possível — durante uma auditoria, durante a ausência dessa pessoa ou durante um projeto posterior que precisa de compreender a configuração atual e não consegue, porque ninguém a escreveu.

Em resumo: os componentes do modelo de suporte

Todas as linhas desta tabela existem durante uma implementação bem conduzida, fornecidas pelo partner como parte do projeto. A falha não é que estas coisas sejam difíceis de fazer — é que ninguém decide deliberadamente quem as faz quando o contrato do partner termina.

O que funciona e sobre o que ser honesto

O que funciona:

Decidir o modelo de suporte antes do go-live, não depois. Isto deveria ser um entregável específico do projeto de implementação e não uma reflexão tardia — quem trata de que nível de incidente, com que recurso interno, escalando para que recurso externo, documentado antes de o contrato do partner terminar em vez de negociado em pânico depois.

A documentação como artefacto vivo, não como uma entrega única. A documentação de implementação descreve o sistema tal como foi construído. Um modelo de suporte precisa de documentação que descreva o sistema tal como está agora, atualizada sempre que muda — a mesma disciplina do registo de customizações abordado noutro artigo desta série, aplicada à configuração em geral e não apenas à customização.

Propriedade nomeada, distinta do conhecimento mais profundo. A pessoa que conhece melhor o sistema é um recurso a proteger e a apoiar, não automaticamente a proprietária da sua governação continuada. Separar estes papéis — um proprietário responsável que garante que existem documentação, sucessão e processo, apoiado por quem detém o conhecimento técnico mais profundo — reduz a dependência de uma só pessoa mesmo antes de essa pessoa sair.

Uma relação mantida e de menor intensidade com a competência de implementação. Não necessariamente com o partner original, e não à intensidade de projeto, mas algum acesso continuado a competência para questões de configuração genuinamente difíceis, avaliação do impacto de atualizações e verificações periódicas do estado de saúde do sistema. As empresas que cortam isto por completo tendem a subaproveitar a capacidade do sistema ou a acumular um desvio de configuração que ninguém deteta.

Uma cadência deliberada para revisão das atualizações do fabricante. Alguém deveria ficar encarregado de revisar as notas de release, avaliar o impacto na sua configuração e nas suas customizações específicas e testar antes de as atualizações serem aplicadas — em vez de as aplicar às cegas ou de as adiar indefinidamente por receio.

Sobre o que ser honesto:

Isto custa dinheiro real e recorrente, e compete com outras prioridades pós-go-live. Um modelo de suporte com disciplina documental adequada, propriedade nomeada e acesso mantido a competência não é gratuito, e as empresas mid-market subinvestem aqui com frequência, porque o custo é visível e o risco que mitiga não é, até se materializar.

A disciplina documental degrada-se sem manutenção ativa. Um modelo de suporte que começa bem documentado e deixa de ser atualizado ao fim de seis meses não é significativamente melhor do que nenhuma documentação, porque documentação desatualizada que contradiz o estado real do sistema é muitas vezes pior do que uma ausência honesta de documentação — induz ativamente em erro.

A dependência de uma só pessoa serve muitas vezes os interesses dessa pessoa, mesmo sem intenção. Ser o único que compreende o sistema é uma fonte de segurança no emprego e de influência, e pode existir uma resistência silenciosa a transferir genuinamente esse conhecimento. Isto tem de ser gerido como um problema de incentivos e não apenas como um problema de documentação — reconheça e valorize explicitamente quem detém o conhecimento, em vez de tratar a transferência como algo que lhe é imposto.

As relações mantidas com o partner precisam de um âmbito genuíno, ou tornam-se caras sem serem úteis. Um contrato de retainer aberto e sem âmbito definido tende a ser subaproveitado até haver uma crise e, depois, a ser usado em excesso. Uma verificação periódica de estado de saúde com âmbito definido, mais disponibilidade para questões genuinamente difíceis, é habitualmente mais útil do que qualquer um dos extremos.

Quadro de decisão: construir ou corrigir o modelo de suporte

Percorra por ordem. Pare na primeira correspondência.

1. O seu modelo de suporte atual depende do conhecimento de um indivíduo específico, sem documentação?
Se sim, esta é a prioridade independentemente de tudo o resto — comece agora a documentar a configuração e a lógica atuais, não como um projeto mas como uma disciplina continuada, a começar por aquilo que essa pessoa considerar mais crítico ou mais frágil.

2. Tem uma estrutura de suporte por níveis definida — quem trata de que nível de incidente?
Se não, defina-a agora. Não precisa de ser elaborada numa empresa mid-market, mas precisa de existir e de ser conhecida, em vez de recair informalmente sobre quem estiver disponível.

3. Existe uma pessoa nomeada que responda pela governação continuada do sistema, distinta de quem detém o conhecimento técnico mais profundo?
Se não, atribua isto explicitamente. Os dois papéis servem propósitos diferentes e confundi-los recria a dependência de uma só pessoa que este quadro existe para evitar.

4. Existe um processo de controlo de alterações para as mudanças de configuração feitas depois do go-live?
Se não, estabeleça um, proporcional à sua escala — mesmo um simples registo do que mudou, por que motivo e quem aprovou evita que o desvio de configuração se torne impossível de rastrear.

5. Tem algum acesso mantido a competência de nível de implementação além da sua equipa interna?
Se não, e se a sua capacidade interna for genuinamente suficiente, pode não ser problema — mas confirme-o deliberadamente em vez de descobrir a lacuna durante uma atualização difícil ou um requisito novo e complexo.

6. Está alguém encarregado de revisar e avaliar as atualizações do fabricante antes de serem aplicadas?
Se não, atribua essa tarefa. A aplicação às cegas de atualizações e o adiamento indefinido são ambos piores do que um processo de revisão deliberado e testado, e isto não é, com frequência, responsabilidade explícita de ninguém.

7. Tudo o acima está no lugar — a documentação está efetivamente a ser mantida atualizada?
Audite isto periodicamente. Um modelo de suporte com a estrutura certa mas com documentação em degradação falhará em silêncio, e a única defesa é verificar, não presumir.

Custo e esforço indicativos

Peça um orçamento para um desenho de modelo de suporte com âmbito definido ou uma verificação de estado de saúde.

Perguntas frequentes

Devemos manter o nosso partner de implementação em retainer depois do go-live?
Não necessariamente o mesmo partner, e não necessariamente com a mesma intensidade, mas alguma forma de acesso mantido a competência além da sua equipa interna vale habitualmente a pena pelo menos durante o primeiro ano ou os dois primeiros, quando é mais provável que as questões de configuração e os impactos das atualizações excedam a capacidade interna.

Como conseguimos que o nosso especialista do sistema documente o seu conhecimento sem que isso pareça uma ameaça ao seu posto?
Apresente-o explicitamente como proteger e valorizar o que essa pessoa sabe, não como substituí-la — a documentação transforma o seu conhecimento num ativo organizacional em vez de um encargo pessoal que carrega sozinha, e este enquadramento, feito com sinceridade e não como uma frase para apaziguar resistências, importa mais do que qualquer modelo de documentação específico.

Qual é o modelo de suporte mínimo viável para uma pequena empresa mid-market?
Uma estrutura por níveis (mesmo que os níveis dois e três apontem ambos para a mesma pequena equipa interna), um documento vivo da configuração atual e das soluções de contorno conhecidas, um proprietário responsável nomeado distinto do especialista técnico mais profundo se os efetivos o permitirem, e algum caminho definido para competência externa em tudo o que exceda a capacidade interna. Não são precisas ferramentas elaboradas; é precisa a atribuição deliberada destas responsabilidades.

Com que frequência deve o próprio modelo de suporte ser revisto?
Anualmente é razoável para a maioria das empresas mid-market, e adicionalmente sempre que haja uma alteração significativa de pessoas, uma atualização importante do sistema ou um novo módulo ou integração — cada um destes é um momento em que é mais provável que os pressupostos do modelo precisem de ser reconsiderados.

Estamos a meio da implementação. É demasiado cedo para pensar nisto?
É o momento ideal. O desenho do modelo de suporte é muito mais barato e mais eficaz quando é integrado no plano de implementação como entregável do que quando é acrescentado depois, e responde diretamente ao padrão de falha de formação e transferência de conhecimento abordado no artigo sobre implementações de NetSuite noutro ponto desta série.

Encerramento — Próximos passos

A distância entre o go-live e um modelo de suporte sustentável raramente é um problema técnico. É uma decisão não tomada — ninguém escolheu explicitamente quem seria proprietário do sistema, o documentaria e daria continuidade quando a pessoa que melhor o conhece estiver indisponível — e as decisões não tomadas recaem por omissão sobre quem por acaso estava mais perto, o que é um alicerce frágil para algo de que o negócio já depende diariamente.

Se já passou o go-live e não tem a certeza da situação em que está: pergunte à pessoa que melhor conhece o sistema o que acontece se estiver incontactável durante um mês. A resposta honesta dessa pessoa é o diagnóstico mais direto disponível, e revela habitualmente com exatidão o ponto por onde o modelo de suporte tem de começar.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Península Ibérica. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e implanta agentes de IA em plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e capazes de se monitorizarem a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são de nível de editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de administração e suporte — https://docs.oracle.com/en/cloud/saas/netsuite/
• ITIL (Axelos), quadro de gestão de serviços — princípios de níveis de suporte e de controlo de alterações — https://www.axelos.com
• Experiência de projetos da Atypical Tech, modelos de suporte de ERP mid-market na Península Ibérica