Odoo ERP para empresas de comércio: guia de implementação
O Odoo serve empresas de comércio que conseguem padronizar vendas, compras, stock e contabilidade numa única plataforma configurável, acrescentando módulos à medida só onde documentos, preços ou logística são específicos do seu negócio. Uma implementação por fases — processos mapeados primeiro, dados mestres limpos, testes em ambiente de pré-produção sobre fluxos reais antes da entrada em produção faseada — é o que mantém baixo o risco de um projeto de software destes.
O Odoo serve as empresas de comércio?
Um negócio de comércio funciona com um conjunto estreito de fluxos que se repetem muito: cotações em encomendas, encomendas em expedições, expedições em faturas, faturas em pagamentos, através de vários armazéns e frequentemente várias moedas. Essa repetição é exatamente para que serve uma plataforma padronizável, e é onde a estrutura de módulos do Odoo — Vendas, Compras, Stock, Contabilidade, com CRM e extras opcionais — quase se traduz no negócio sem tradução nenhuma.
O encaixe é mais forte ou mais fraco consoante quatro propriedades do negócio:
- O quão padrão são os fluxos. Um distribuidor que move produtos de marca através de encomendas repetidas com termos convencionais encaixa bem; um comerciante cujos negócios se estruturam de forma diferente de cada vez vai lutar contra o fluxo de encomendas.
- O quanto os documentos importam. Se clientes, bancos ou aduanas esperam sequências e layouts específicos de documentos, essa é a parte que decide o projeto — ou a localização cobre isso, ou se torna trabalho à medida.
- O quão limpos estão os dados mestres. Clientes, fornecedores, produtos, unidades, moedas e códigos de imposto são o material real do projeto; uma plataforma não consegue padronizar aquilo que o negócio nunca definiu de forma consistente.
- Como a equipa recebe o sistema. Os utilizadores de uma empresa de comércio trabalham sob pressão de tempo — uma expedição falhada ou uma fatura por lançar tem custo hoje —, por isso a adoção é uma restrição de desenho e não um pormenor tardio.
Mapa de módulos
| Necessidade de negócio | Área do Odoo | Questão típica de configuração |
|---|---|---|
| Cotações e encomendas | Vendas | Que listas de preços se aplicam por grupo de clientes, e os descontos são controlados? |
| Compras | Compras | As encomendas de compra nascem de regras de reposição ou de procura manual? |
| Stock em várias localizações | Stock | Estrutura de armazéns: quantos armazéns, que localizações intermédias? |
| Custeio correto das mercadorias | Stock, Contabilidade | Os custos de chegada — frete, seguro, direitos aduaneiros — fazem parte do custo do produto? |
| Faturação e conciliação | Contabilidade | Sequências de documento, códigos de imposto, e como se conciliam os pagamentos com as faturas |
| Clientes e funil | CRM | O que qualifica um contacto, e quem fica dono da conta depois da primeira encomenda? |
| Comércio multimoeda | Contabilidade, Vendas | Que moedas, a que taxas, e quem as mantém? |
| Reposição | Stock | Regras de reposição por produto e localização, ou um fluxo de planeamento? |
| Emissão de documentos | Vários | Que documentos impressos e em PDF têm de corresponder a um formato legal ou do cliente? |
Para um comerciante, as duas linhas que normalmente decidem se a plataforma parece nativa são os custos de chegada e o multimoeda. Os custos de chegada decidem se a margem de uma expedição é real ou uma estimativa; o multimoeda decide se a contabilidade continua honesta quando as moedas de compra e de venda diferem. Ambos são configuráveis em princípio e ambos exigem decisões do negócio e não apenas da equipa de implementação.
Os custos de chegada merecem uma paragem, porque são onde um negócio de comércio costuma descobrir a diferença entre um ERP que encaixa e um que apenas funciona. Um comerciante que compra um contentor paga mais do que o preço da fatura: frete, seguro, manuseamento e, na maioria dos países, direitos aduaneiros — e a forma como esses montantes se alocam às mercadorias decide a margem relatada em cada linha vendida. Se o negócio trata os custos de chegada numa folha de cálculo a posteriori, o ERP está a registar uma verdade parcial; se os aloca na entrada de mercadorias, a margem é real no momento em que fica visível. A questão de configuração é por isso não «o módulo tem custos de chegada?» mas «em que ponto do nosso fluxo são capturados, e por quem?».
O multimoeda tem uma profundidade parecida. Registar uma transação numa segunda moeda é a parte fácil; as questões que importam para uma empresa de comércio são que taxa é usada em cada passo — cotação, encomenda, receção, fatura, pagamento — como entram as diferenças cambiais nas contas, e quem é responsável por manter as taxas quando estas se movem. Uma empresa que responde a essas três questões antes da configuração raramente tem problemas de moeda depois; uma empresa que as deixa nas definições por omissão descobre as suas respostas na primeira conciliação de fim de trimestre.
Configuração ou personalização?
A distinção importa mais no Odoo do que em algumas plataformas, porque a linha entre as duas é desenhada dentro do produto. A configuração altera definições, sequências, formulários e fluxos dentro do que os módulos padrão fazem; a personalização acrescenta desenvolvimento novo — campos novos, lógica nova, documentos novos — que não existia antes.
A resposta por omissão deve ser a configuração, por uma razão que só aparece mais tarde: o código à medida é código que o negócio passa a deter, incluindo os seus bugs e o seu fardo de atualizações. Uma instalação pesadamente personalizada pode ficar difícil de mover para versões novas, porque cada atualização tem de ser conferida contra tudo o que foi alterado. Esse é um custo real, pago anos depois, por pessoas que não estavam na sala quando a decisão foi tomada.
Três testes antes de autorizar um módulo à medida:
- A funcionalidade padrão falta mesmo, ou é apenas desconhecida? Metade das personalizações que uma primeira implementação produz são pedidos de coisas que os módulos padrão já fazem sob outro nome.
- O processo pode mudar em vez disso? Muitas vezes o negócio quer um documento à medida porque um passo do processo está no sítio errado; mover o passo é mais barato do que programar à volta dele.
- Quanto custa na altura da atualização? Toda a personalização deve ser escrita com a sua finalidade, para que quem verificar a próxima versão saiba para que existe.
Roteiro de implementação
| Fase | Resultados | Responsável |
|---|---|---|
| Mapeamento de processos | Fluxos do estado atual, por processo, escritos; lista de lacunas face à solução padrão | Lideranças de negócio, com a equipa de implementação |
| Âmbito e sequência | Que módulos entram em que onda; o que fica de fora por agora | Direção, com o responsável do projeto |
| Configuração | Módulos configurados contra os fluxos mapeados; decisões registadas | Equipa de implementação |
| Limpeza dos dados mestres | Clientes, fornecedores, produtos, unidades, códigos de imposto e moedas limpos | Responsáveis de negócio de cada conjunto de dados |
| Migração e pré-produção | Migração de teste; fluxos reais executados de ponta a ponta em ambiente de pré-produção | Equipa de implementação, com utilizadores-chave |
| Formação | Utilizadores formados por função; procedimentos escritos para as tarefas diárias | Lideranças de negócio |
| Entrada em produção faseada | Primeiras entidades ou armazéns em produção; o resto segue após estabilização | Ambas as equipas, com um arranjo de suporte |
A ordem importa. Configuração antes do mapeamento de processos produz um sistema configurado em torno de palpites; migração antes da limpeza de dados leva a desordem para o sistema novo e dá-lhe uma interface nova; entrada em produção antes da formação garante que a primeira semana de uso real é também a primeira semana de aprendizagem.
Migração de dados
A migração é onde os projetos de comércio têm sucesso ou falham, porque os dados que um comerciante carrega são o tipo mais difícil: registos de produto com unidades inconsistentes, clientes com identificadores fiscais duplicados, listas de preços mantidas em folhas de cálculo que discordam umas das outras, e stock de abertura cuja última contagem física foi há algum tempo.
O conjunto de migração para um comerciante inclui normalmente clientes, fornecedores, produtos com as suas unidades e categorias fiscais, listas de preços, stock de abertura por localização e documentos comerciais em aberto — encomendas e faturas que ainda terão de ser entregues ou pagas depois da entrada em produção. Duas regras tornam-o suportável:
- Limpar antes de migrar, não depois. Deduplicação, alinhamento de unidades e mapeamento de códigos de imposto são trabalho de negócio; fazê-los no sistema novo, sob a pressão da entrada em produção, transforma um exercício de dados numa crise.
- Conciliar os valores de abertura. Os valores de stock de abertura e os saldos devem ser acordados com as contas antes da troca, por escrito; uma divergência descoberta depois torna-se uma discussão sobre qual sistema tinha razão.
Integrações
As integrações que uma empresa de comércio normalmente precisa são ligações bancárias para conciliação de pagamentos, canais de marketplace ou comércio eletrónico para captura de encomendas, parceiros logísticos para documentos de transporte e — na Turquia — a cadeia de fatura eletrónica. Esta última merece planeamento próprio: os documentos circulam através de um integrador privado sob as regras do GİB, o ERP tem de produzir a estrutura exigida, e as obrigações do sujeito tributário continuam a ser do sujeito tributário. A página de integração de fatura eletrónica trata o tema em detalhe.
Uma regra geral para todos estes casos: integre tarde e de propósito. Cada ligação acrescenta um modo de falha, e uma integração construída antes de os fluxos núcleo estarem estáveis simplesmente desloca a instabilidade para fora. Sequencie o projeto para que o núcleo corra primeiro, e acrescente depois os canais um de cada vez, cada um com o seu teste e o seu responsável.
Como escolher o parceiro de implementação de software
As implementações de Odoo são entregues por parceiros, e a escolha do parceiro importa normalmente mais para o resultado do que a escolha da versão. Vale a pena perguntar, por ordem:
- Experiência em comércio. Que projetos de distribuição ou de comércio entregaram, e se a equipa que ganhou o negócio é a equipa que vai fazer o trabalho.
- Disciplina de configuração primeiro. Como decidem entre configuração e personalização, e qual é a sua posição escrita sobre o impacto das atualizações.
- Conhecimento de localização. Para a Turquia: como tratam a fatura eletrónica e os requisitos contabilísticos locais, e através de que integrador.
- Abordagem aos dados. O que fazem com dados mestres sujos — se a limpeza está no seu âmbito, e como testam a migração.
- Formação e documentação. O que os utilizadores recebem na entrada em produção e o que os administradores recebem depois.
- Arranjo de suporte. Tempos de resposta, quem detém o conhecimento, e o que acontece quando uma pessoa-chave sai do parceiro.
- Referências. Uma chamada a uma empresa semelhante, arranjada de forma a que o cliente perceba no momento o que lhe está a perguntar.
Riscos
| Risco | Como se manifesta | Como gerir |
|---|---|---|
| Sobrepersonalização | O novo sistema replica cada velho hábito em código | Regra de configuração primeiro, aprovações de personalização por escrito, nota de impacto de atualização para cada uma |
| Qualidade dos dados | Os relatórios parecem errados nas primeiras semanas; ninguém confia nas margens | Limpar antes de migrar; conciliar os valores de abertura por escrito |
| Adoção pelos utilizadores | As encomendas são tiradas no papel e reintroduzidas depois | Formação por função, procedimentos escritos para as tarefas diárias, envolvimento precoce dos utilizadores-chave |
| Entrada em produção big-bang | Tudo entra em produção de uma vez, e cada problema tem o mesmo prazo | Fasear por entidade ou armazém; manter um plano de recurso para as primeiras semanas |
| Deriva de âmbito | Pedidos novos todas as semanas, nenhum deles no plano | Um procedimento de alterações; o que se acrescenta rouba a data a outra coisa |
| Dependência do parceiro | Só uma pessoa no parceiro conhece a configuração | Decisões por escrito, obrigações de documentação, um substituto nomeado |
Os três que afundam mesmo os projetos de comércio são a sobrepersonalização, a qualidade dos dados e a adoção — e os três decidem-se antes da entrada em produção, por escolhas que o negócio faz e não pelo software.
A adoção merece mais uma nota prática, porque é o risco que se esconde mais tempo. O pessoal de uma empresa de comércio faz qualquer sistema funcionar à mão: mantém a velha folha de cálculo ao lado do sistema novo, reintroduz encomendas e diz-lhe no terceiro mês que o software está lento. O sinal a observar não é a queixa mas o trabalho em paralelo — se o caminho do papel ou da folha de cálculo ainda existe, o sistema não substituiu nada, e cada relatório construído sobre ele está incompleto. A contra-medida é operacional e não técnica: torne o caminho novo o único caminho para um conjunto definido de transações, dê aos utilizadores um sítio para onde enviar as questões que surgem nas primeiras semanas, e faça a equipa de gestão parar visivelmente de pedir números que vêm das velhas folhas de cálculo. Esse último ponto decide mais adoções do que qualquer sessão de formação.
Perguntas frequentes
Quanto tempo demora uma implementação Odoo?
Depende do âmbito, do estado dos dados e de quantos processos a empresa padroniza, por isso a resposta honesta é descrita por fases e não por meses: mapeamento, configuração, limpeza de dados, pré-produção, formação, e depois entrada em produção faseada. Um parceiro que dá uma duração antes da fase de mapeamento está a estimar outra empresa.
O Odoo gere importação e exportação multimoeda?
Sim, no sentido geralmente conhecido: várias moedas, taxas que podem ser mantidas ou automatizadas, e transações registadas nas moedas funcional e documental. As questões que vale a pena colocar num contexto de comércio são quem mantém as taxas, como se tratam as diferenças cambiais na contabilidade, e que moedas o negócio efetivamente precisa — essas são decisões de negócio que a configuração depois implementa.
Devemos personalizar ou configurar?
Configure por omissão. A personalização deve sobreviver a três testes: a funcionalidade padrão tem de faltar genuinamente, o processo não tem de poder mudar em vez dela, e o custo de atualização tem de ser compreendido e aceite por escrito. A página ERP à medida versus comercial trata a versão mais ampla desta questão.
O Odoo pode emitir faturas eletrónicas turcas?
Através da localização apropriada e de um integrador privado sob as regras do GİB, como nos outros sistemas de ERP — a estrutura do documento, o selo financeiro e o canal do integrador são os mesmos requisitos. Confirme a configuração específica e o integrador com um consultor qualificado e com o parceiro de implementação; a página de integração de fatura eletrónica explica as peças em movimento.
Que dados têm de ser limpos primeiro?
Clientes e fornecedores com os seus identificadores fiscais, produtos com unidades e categorias fiscais consistentes, listas de preços, e o stock de abertura — este último porque entra no sistema como valor financeiro e não só como quantidade. A limpeza é trabalho de negócio com responsáveis nomeados por conjunto de dados, e antecede a migração.
Precisamos de um parceiro?
Para uma primeira implementação, quase sempre sim: a localização, a técnica de migração e a disciplina de atualização são coisas que os parceiros carregam todos os dias. O que verificar é se a abordagem do parceiro coincide com a sua em configuração primeiro, dados e formação — a checklist de RFP para fornecedores dá-lhe as perguntas e uma forma de pontuar as respostas.
Fontes e normas
- O Odoo, os seus módulos e os seus modelos de licenciamento são descritos aqui apenas em termos geralmente conhecidos; a disponibilidade de módulos, a cobertura da localização e os detalhes de versão mudam e devem ser confirmados na documentação oficial atual.
- A fatura eletrónica turca é referida através do quadro do GİB; não é alegada nesta página nenhuma relação de integrador, parceria, certificação ou cliente para a WorldwideTradeX, nem é indicada qualquer duração ou custo de implementação.
Páginas relacionadas
Desenvolvimento de software · ERP à medida versus comercial · Integração de fatura eletrónica na Turquia · Checklist de RFP para fornecedores · Pedir uma cotação