Um projeto Odoo que não decorre como previsto é uma situação mais comum do que parece, e não tem nada de excecional na implementação de um software de gestão. Investiu tempo e recursos, e o resultado não corresponde ao que era esperado. Antes de propor seja o que for, é preciso reconhecer esta situação pelo que é: um projeto raramente falha por culpa de uma só parte, e não temos conhecimento do contexto completo — prazos, orçamento, comunicação, restrições de ambos os lados — em que as decisões foram tomadas. Este documento descreve como retomar um projeto Odoo em dificuldade de forma serena, sem oportunismo.
Não há motivo para procurar um culpado antes de agir. Uma implementação Odoo envolve várias partes — o prestador, a empresa cliente, por vezes terceiros como um alojador ou outro software conectado — e cada uma influencia o resultado final. O que importa nesta fase não é reconstituir o histórico das decisões, mas compreender o estado real do sistema hoje e decidir com conhecimento de causa qual a continuação a dar-lhe.
As situações típicas
Vários cenários repetem-se regularmente entre empresas que procuram retomar um projeto Odoo existente.
- O prestador anterior está incontactável ou cessou a atividade. Já não responde a pedidos, já não há acompanhamento, por vezes já nem há empresa.
- O projeto parou a meio do caminho. Parte da configuração existe, mas a implementação nunca foi concluída.
- O orçamento foi ultrapassado sem entrada em produção. Foram investidos recursos, mas a ferramenta continua sem poder ser utilizada no dia a dia.
- A instância está em produção, mas inutilizável. As equipas contornam a ferramenta, voltam ao Excel ou a sistemas antigos, por falta de uma configuração adaptada aos seus processos reais.
- A contabilidade produzida está errada. Diferenças, apuramentos de IVA inconsistentes, reconciliações bancárias que nunca se fazem.
- Desenvolvimentos não documentados. Código específico corre em produção sem que ninguém saiba exatamente o que faz nem porque foi escrito assim.
- Ninguém, internamente, sabe como funciona a instância. A dependência de uma única pessoa — muitas vezes o próprio prestador — instalou-se sem que a empresa se apercebesse.
O primeiro passo: retomar o controlo dos seus acessos, do seu código e dos seus dados
Antes de qualquer diagnóstico ou decisão sobre a continuação, é preciso garantir que a empresa controla efetivamente os seus próprios ativos. É uma etapa a tratar prioritariamente, muitas vezes antes mesmo de procurar um novo prestador, porque um acesso perdido pode tornar-se muito difícil de recuperar depois de o vínculo com o prestador anterior estar definitivamente rompido.
- O acesso de administrador à instância Odoo, não apenas uma conta de utilizador.
- O acesso ao alojamento onde a instância funciona, ou pelo menos o conhecimento de quem a aloja e sob que contrato.
- A propriedade do nome de domínio associado, caso exista, e da sua gestão de DNS.
- O código dos desenvolvimentos específicos, num repositório controlado pela empresa, não apenas na máquina do prestador.
- As cópias de segurança existentes e uma exportação dos dados atualizados, independentemente do que aconteça a seguir.
Enquanto estes elementos não estiverem garantidos do lado da empresa, qualquer discussão sobre a continuação do projeto permanece frágil: não se decide serenamente o futuro de um sistema sobre o qual não se tem controlo. Nos casos mais tensos, em que o contacto com o prestador anterior está rompido, esta etapa pode exigir contactar diretamente o alojador, verificar as condições contratuais de propriedade dos dados, ou fazer valer um direito de recuperação previsto no contrato inicial. É uma diligência por vezes incómoda, mas condiciona tudo o resto.
O levantamento técnico e contabilístico
Uma vez garantidos os acessos, a etapa seguinte é um diagnóstico completo, próximo no método de uma auditoria de instância Odoo clássica, mas orientado para uma decisão de recuperação em vez de uma simples fotografia. Incide sobre a configuração contabilística e de IVA, a parametrização da folha de salários se existir, os módulos ativos, os desenvolvimentos específicos e o seu nível de documentação, a qualidade dos dados, os direitos de acesso, e o estado das cópias de segurança. A dimensão contabilística é examinada com o mesmo rigor que a dimensão técnica: uma instância que funciona sem erro visível pode, ainda assim, produzir valores errados, e é frequentemente esse ponto preciso que motivou a procura de um novo acompanhamento.
Este diagnóstico responde a perguntas muito concretas. Os lançamentos contabilísticos gerados até agora são aproveitáveis, ou é preciso voltar a um período para os corrigir? O apuramento de IVA transmitido às autoridades corresponde realmente à atividade da empresa? Os desenvolvimentos específicos em produção representam um risco imediato, ou podem esperar por uma próxima etapa? As respostas a estas perguntas determinam a urgência de cada ação, e evitam tratar como prioritário um ponto secundário enquanto um problema mais grave continua ignorado.
Decidir: reparar, reconstruir, ou repor ao padrão
O levantamento da situação leva a uma escolha entre três opções, e essa escolha deve assentar em critérios concretos, não numa impressão geral da situação.
- Reparar o existente faz sentido quando a base é globalmente sólida: a configuração corresponde às necessidades reais, os desenvolvimentos específicos têm qualidade correta, e os problemas constatados estão localizados e identificáveis.
- Recomeçar a partir de uma base limpa justifica-se quando a configuração se afasta demasiado dos processos reais da empresa, quando os desenvolvimentos são demasiado frágeis ou demasiado numerosos para serem fiabilizados um a um, ou quando a qualidade dos dados está demasiado degradada para ser corrigida de forma fiável.
- Repor a instância ao padrão Odoo consiste em retirar as personalizações mais arriscadas e voltar, tanto quanto possível, às funcionalidades nativas, nomeadamente quando os desenvolvimentos específicos não estão documentados e complicam cada atualização de versão. É frequentemente a via mais sustentável a médio prazo.
O critério determinante não é a amplitude aparente dos danos, mas a sustentabilidade de cada opção ao longo do tempo: uma reparação rápida que deixa as mesmas causas em vigor apenas terá adiado o problema. Uma instância tecnicamente instável mas cuja configuração de negócio é pertinente não precisa de ser reconstruída; inversamente, uma instância estável mas construída sobre processos que já não correspondem à atividade real da empresa continuará a ser um entrave, quaisquer que sejam as correções técnicas aplicadas.
A reposição em estado
Uma vez escolhida a opção, a reposição em estado segue as prioridades identificadas no levantamento da situação: correção da configuração contabilística e de IVA em primeiro lugar, uma vez que tem um impacto direto e imediato nas obrigações legais da empresa, depois fiabilização dos dados, depois retoma ou substituição dos desenvolvimentos mais frágeis. Consoante as necessidades, isto pode mobilizar as nossas páginas dedicadas à Odoo Contabilidade, à folha de salários, ou ao desenvolvimento específico. Quando a situação se assemelha mais a uma nova implementação do que a uma correção, junta-se à nossa página implementação Odoo.
Documentação e transferência de conhecimento
Uma recuperação de projeto que se limita a corrigir os sintomas reproduz a dependência que levou à situação inicial. A documentação não é, por isso, uma etapa secundária: cada escolha de configuração, cada desenvolvimento específico, cada regra de negócio parametrizada no Odoo deve estar escrita nalgum lado de forma compreensível para alguém que não participou no projeto. Esta documentação não precisa de ser exaustiva no sentido de um manual técnico completo: deve sobretudo responder às perguntas que uma pessoa externa colocaria ao descobrir a instância — porque existe este campo, para que serve esta automatização, que regra de negócio justifica esta parametrização e não outra.
Este trabalho é acompanhado de uma transferência de conhecimento para as suas equipas, para que a utilização diária da ferramenta deixe de depender de uma única pessoa, interna ou externa. Veja a nossa página formação Odoo para este acompanhamento, e suporte Odoo para o seguimento seguinte, uma vez reposta a instância.
Evitar voltar a esta situação com o prestador seguinte
Algumas precauções, estabelecidas desde o início de uma nova colaboração, reduzem claramente o risco de voltar a viver uma situação semelhante:
- A reversibilidade: a possibilidade concreta de mudar de prestador sem recomeçar do zero, prevista desde o início em vez de negociada com urgência.
- Os acessos: a empresa mantém sempre os acessos de administrador à sua instância, ao seu alojamento e ao seu nome de domínio.
- A documentação: exigida como um resultado do projeto, não como uma opção deixada ao critério do prestador.
- A propriedade do código: os desenvolvimentos específicos realizados para a empresa pertencem-lhe, num repositório que ela controla.
Estes quatro pontos não garantem que um projeto decorra sem incidentes, mas garantem que um incidente continua reparável. Para situar esta abordagem no conjunto das nossas prestações, veja Odoo ERP em Genebra e Odoo em Genebra. Se a dúvida incidir mais sobre o estado geral de uma instância do que sobre um projeto claramente parado, a nossa página auditoria de instância Odoo pode ser o ponto de partida mais adequado.