Sankhya: o pesadelo de implantação que vimos em campo

Sankhya é um dos ERPs brasileiros mais relevantes — fundada em 1989, base estimada em 12 mil clientes, forte em mid-market industrial e distribuição. Tem fiscal BR nativo, customização via Sankhya-W, e ecossistema de parceiros consolidado.

Em projetos KMEE recebemos com regularidade clientes que vieram de implantações Sankhya travadas. Este artigo é um relato técnico-direto do que vimos em campo — sem adjetivos, com fatos. O objetivo é ajudar quem está avaliando Sankhya a entender riscos comuns e quem está numa implantação em curso a antecipar pontos de atenção.

O que Sankhya entrega bem

• Localização fiscal BR nativa, sem ISV externo.
• Cobertura ampla: ERP, RH, fiscal, BI (Sankhya-Om).
• Forte em distribuição e indústria de processo.
• Parceria com VARs regionais com presença capilar.

Não há mistério aqui — é um produto sério, em operação há décadas. O que segue não é “o produto é ruim”, é uma leitura dos padrões de fricção que aparecem em projetos.

Padrões observados em implantações travadas

Os relatos abaixo são consolidação do que vimos em mais de 10 casos diferentes de clientes que migraram de Sankhya ou que pediram apoio em projetos Sankhya em curso. São consistentes com o que aparece em Reclame Aqui e em fóruns de usuários.

1. Customização “via consultoria” cresce sem governança

Sankhya tem linguagem proprietária (Sankhya-W, eventos JS, regras de tela). Em projetos sem governança técnica clara, cada solicitação vira customização — e ao longo de 12-24 meses a empresa acumula centenas de eventos customizados sem testes automatizados, sem versionamento Git, sem rastreabilidade. Quando precisa de upgrade de versão, o esforço é alto.

2. Upgrade de versão é evento de risco

Reclamações recorrentes em fóruns falam de upgrades demorados e regressões em telas customizadas. Não é exclusividade do Sankhya — todo ERP proprietário com forte customização sofre disso — mas a percepção é que a janela entre versões e o esforço de upgrade são acima da média de mercado.

3. Time de produto x time de customização

Várias dores reportadas dependem de fix do fabricante. O ciclo entre abrir chamado, ser aceito, entrar em backlog, sair em release pode ser de meses. Para empresas com ritmo intenso de mudança regulatória (Reforma Tributária, EFD-Reinf novas versões), isso vira gargalo.

4. Custo total acima do anunciado

O contrato inicial costuma estar abaixo da expectativa. O custo real aparece em horas de consultoria ao longo do projeto. Empresas que orçaram R$ 200-300k de implantação relatam fechar em R$ 600k-1M+ depois de 12-18 meses. Esse padrão é replicado em qualquer ERP proprietário com cobrança por hora — não é específico do Sankhya — mas vale registrar.

5. Lock-in com parceiro

A cultura Sankhya é de VAR forte. Trocar de parceiro é caro porque a documentação técnica do que foi customizado raramente está fora do parceiro. Isso é estrutural do modelo.

O que Odoo + KMEE faz diferente

Não é “Odoo é melhor que Sankhya”. É um modelo operacional diferente:

• Customização versionada em Git. Toda alteração vira commit, PR, code review, CI. Doodba é o template padrão de stack.
• Upgrade com openupgrade — projeto OCA que mantém scripts de migração entre versões, com cobertura de teste pública.
• Código aberto auditável. O cliente pode trocar de parceiro a qualquer momento — o código é dele, está no Git dele, e tem comunidade global lendo.
• Localização BR pela OCA (l10n-brazil) com release acompanhando IN da Receita em semanas.

Para a comparação completa: /comparativos/odoo-vs-sankhya/.

Quando Sankhya faz sentido

• Empresa industrial de processo com necessidade fiscal pesada e parceiro Sankhya forte na região.
• Empresa que valoriza fornecedor BR único e tem aversão a stack open source.
• Operação onde o time interno não vai assumir camada técnica — Sankhya com parceiro maduro é menos arriscado que Odoo sem parceiro.
• Caso onde a indústria do cliente já é de fato bem coberta por verticais Sankhya (ex: transportadoras com Sankhya TMS).

Quando NÃO migrar (para Odoo ou para Sankhya)

• Empresa em meio a um projeto Sankhya em curso com 60%+ de adoção — terminar o projeto é geralmente mais barato que abandonar.
• Empresa sem governança técnica para absorver Odoo (ou Sankhya) — qualquer ERP customizado sem disciplina vira problema.
• Empresa que ainda não mapeou processos. Migração sem mapeamento prévio é trocar dor por dor.

Sinais de que vale considerar mudança

• Backlog de chamados abertos > 6 meses sem solução.
• Custo mensal de consultoria > 30% do custo de licença.
• Última atualização de versão foi há 3+ anos.
• Time interno não consegue ler/entender o que foi customizado.
• Roadmap regulatório (Reforma Tributária, novos SPED) está atrasado.

Se 3 ou mais batem, vale uma conversa franca — não necessariamente para migrar, mas para diagnosticar. Fale com um especialista KMEE.