1. O que resolvemos exatamente
Quatro problemas que quase sempre aparecem juntos:
- «Os mesmos dados estão em quatro aplicações e ninguém sabe qual é o bom.» O ERP diz uma coisa, o CRM outra e a folha de cálculo do comercial uma terceira. As divergências não avisam: aparecem no dia em que é preciso decidir algo.
- «Copiamos e colamos entre sistemas todos os dias.» Trabalho mecânico feito por gente cara, com o erro de transcrição incluído no preço.
- «O dado chega tarde a onde é preciso.» Atualiza-se quando alguém se lembra de exportar, não quando o dado muda.
- «Cada relatório dá um número diferente.» Porque cada um foi alimentado a partir de uma fonte diferente e num momento diferente.
2. Como funciona
A integração é construída em torno dos sistemas que já tem, e liga-se por onde cada um deixar: API, acesso a base de dados ou troca de ficheiros. Se algum não expuser nenhuma das três, dizemo-lo antes de começar e não a meio do projeto.
O que separa uma integração que aguenta de um script que se parte a cada duas semanas são três coisas que não se veem na demonstração:
- Repetições sem duplicar. As ligações falham: cai a rede, o ERP está em manutenção, a API devolve um erro temporário. A sincronização tem de poder repetir-se sem criar a encomenda duas vezes.
- Conciliação de divergências. Quando os dois sistemas não coincidem, o dado não é forçado nem descartado em silêncio: fica numa fila com as duas versões para que uma pessoa decida. Essa fila é o que evita descobrir o desajuste três meses depois.
- Registo do que se moveu. O que se leu, o que se escreveu, quando e com que resultado. Sem isso, a primeira discussão sobre um dado estranho não tem forma de se resolver.
Postos um ao lado do outro, a mudança vê-se melhor. Note que o dado nasce no mesmo sítio e acaba no mesmo sítio: o que desaparece é o passo do meio.
- O dado nasce num sistemaUma encomenda no ERP, um contacto no CRM
- Alguém exporta e escreve à mãoQuando se lembra, e como o entende
- Chega ao outro sistemaCom atraso e, às vezes, diferente
As divergências não avisam: aparecem no dia em que é preciso decidir algo com esse dado.
- O dado nasce igualNinguém muda de sistema nem de hábitos
- A sincronização recolhe-oPor API, base de dados ou ficheiro, segundo o que o sistema permitir
- Concilia-se e repete-seSe algo falhar, repete sem duplicar
- Chega ao outro sistemaEm minutos, com registo do que se moveu
↳ O que não bate não é forçado nem descartado em silêncio: fica numa fila de divergências com as duas versões do dado, para que uma pessoa decida.
Ninguém exporta nada. E quando alguém pergunta qual é o dado bom, há resposta.
Os dois percursos avançam ao mesmo tempo e na mesma escala temporal: o de cima ainda vai no segundo passo quando o de baixo já terminou e está à espera. As proporções são ilustrativas — o que sustentamos é que um demora bastante mais do que o outro, não quanto exatamente no seu caso.
3. O que NÃO fazemos com o seu ERP
Convém dizê-lo cedo e com clareza: não somos especialistas em nenhum ERP concreto e não o pretendemos. Já integrámos com os habituais do tecido industrial, mas o que sabemos fazer é falar com o que já tem —ler, escrever e sincronizar— não configurá-lo nem parametrizá-lo por dentro.
Isso significa que não vamos tocar no seu plano de contas, nem nos seus circuitos de aprovação, nem na parametrização de armazéns. Para isso existe o seu implementador, e trabalhamos com ele sem nenhum problema: de facto, os projetos saem melhor quando ele está na conversa desde o início.
Se alguém lhe oferecer ao mesmo tempo a integração e a parametrização do seu ERP, pergunte-lhe pela segunda com detalhe. É uma especialidade diferente e nota-se depressa.
4. Casos típicos
Os nossos clientes estão hoje na indústria —fabricação discreta e de processo: automóvel, alimentação e bebidas—, que é onde temos o percurso. Os outros são padrões que se repetem em qualquer setor.
Indústria: automóvel, alimentação e bebidas
Os dados de produção vivem no sistema de fábrica e a faturação no ERP, e alguém cruza-os à mão em cada fecho. O fecho depende de uma pessoa e de um ficheiro que só ela sabe montar.
Produção e ERP sincronizam-se sozinhos, e o fecho passa de ser montado a ser revisto.
Comercial e operações
O CRM e o ERP guardam o mesmo cliente com dados diferentes: endereço, condições, risco. O comercial promete um preço que o ERP não reconhece, e o problema aparece na encomenda.
Uma única origem para cada dado, com conciliação do que não bater em vez de sobrescrever às cegas.
Administração
Os relatórios são alimentados por exportações manuais feitas em momentos diferentes. Cada relatório dá um número diferente e discute-se o valor em vez da decisão.
Todos bebem da mesma fonte sincronizada, pelo que a conversa volta a ser sobre o que fazer.
5. O que precisa de ter antes de começar
- Que os sistemas deixem entrar. API, acesso a base de dados ou exportação programada. Com uma das três basta; com nenhuma, não há projeto e é preciso dizê-lo.
- Credenciais e permissão para as usar. Parece óbvio e é o que mais vezes atrasa o arranque, sobretudo quando o sistema é mantido por um terceiro.
- Saber qual é o sistema de referência para cada dado. Se o preço manda no ERP e o contacto manda no CRM, é preciso decidi-lo antes. É uma decisão de negócio, não técnica, e não a podemos tomar nós.
- Alguém que saiba o que significa cada campo. Metade dos problemas de uma integração são de significado, não de ligação.
- Tolerância a que algo fique em fila. Haverá sempre divergências; o importante é que alguém as veja.
6. Quando NÃO é a solução
- Vai mudar de ERP nos próximos meses. Integrar o que está a ponto de desaparecer é atirar dinheiro fora. Convém esperar e desenhar a integração contra o sistema novo.
- O volume é baixo. Se são cinco registos por semana, copiá-los à mão sai mais barato do que manter uma sincronização.
- Ninguém quer decidir qual é o dado bom. Sem essa decisão, a integração só propaga o desacordo mais depressa.
- O problema real é o processo, não os sistemas. Se o dado chega mal porque ninguém sabe quem o deve introduzir, integrar dois sistemas não resolve: primeiro é preciso organizar o processo.
7. Como se mede o retorno
- Horas por mês que deixam de se ir em exportar, escrever à mão e conciliar, com o seu custo equivalente.
- Taxa de divergências entre sistemas, antes e depois. Costuma ser o número que mais surpreende quando se mede pela primeira vez.
- Atraso do dado: quanto tempo demora uma alteração a estar disponível onde é preciso.
- Erros evitados e o que custava cada um: reprocessamentos, notas de crédito, encomendas mal servidas.
O quadro completo está em como se mede o retorno do guia. E se os dados que se movem forem pessoais, as obrigações aplicáveis estão em conformidade em IA.
Aviso: esta página tem finalidade informativa; não constitui assessoria jurídica nem garantia de resultados. Os valores citados são intervalos habituais em projetos reais, não compromissos contratuais, e dependem do âmbito e do ponto de partida de cada empresa.
8. Perguntas frequentes
Com que ERPs e CRMs integram?
Com o que já tiver, por onde ele deixar: API, base de dados ou troca de ficheiros. E convém a precisão de sempre: não somos especialistas em nenhum ERP concreto nem o pretendemos. Sabemos falar com o seu —ler, escrever e sincronizar—, não parametrizá-lo por dentro; disso encarrega-se o seu implementador e trabalhamos com ele sem problema.
É necessário que o sistema tenha API?
Não necessariamente. Com acesso à base de dados ou com uma exportação programada de ficheiros também se pode montar uma sincronização sólida. O que não se pode é integrar um sistema que não deixa entrar por nenhuma das três vias, e isso verifica-se antes de orçamentar nada, não a meio do projeto.
O que acontece se a sincronização falhar a meio?
Repete-se sem duplicar. As ligações falham por definição —cai a rede, o ERP está em manutenção, a API devolve um erro temporário—, por isso a sincronização é desenhada para poder repetir-se sem criar a mesma encomenda duas vezes. E o que não bate não é forçado nem descartado em silêncio: fica numa fila de divergências com as duas versões do dado para que uma pessoa decida.
Com que frequência se sincronizam os dados?
Depende de para que sejam usados. Se o dado move uma decisão operacional, em minutos ou a cada alteração; se alimenta um relatório diário, uma vez por dia basta e sai mais barato de manter. Sincronizar tudo ao segundo porque soa melhor é uma forma cara de não decidir.
Podem integrar com um sistema antigo ou feito à medida?
Normalmente sim, e costuma ser o caso mais frequente na indústria. Os sistemas antigos raramente têm uma API moderna, mas quase todos permitem ler a sua base de dados ou deixar ficheiros numa pasta, e com isso há suficiente. Verificamos antes de comprometer nada.
Quem mantém a integração depois?
Pode ficar com a sua equipa ou connosco, e decide-se antes de a construir, porque muda como se constrói. Se for a sua gente a mantê-la, é escrita na linguagem que já usam e documentada para isso. Uma integração que só entende quem a fez é uma dependência, não um serviço.
Serviços que costumam acompanhar este: automatização de processos · analítica avançada e BI.