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 relata de forma técnica e direta o que vimos em campo, com fatos e sem adjetivos. 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.

É um produto sério, em operação há décadas. O que segue é uma leitura dos padrões de fricção que aparecem em projetos, e não um veredito de que o produto é ruim.

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. Isso 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 e 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

A diferença está no modelo operacional:

• 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

• Indústria de processo com parceiro Sankhya recém contratado e sem plano de migrar no curto prazo.
• Empresa que valoriza fornecedor BR único e tem aversão a stack open source.
• Operação sem parceiro Odoo mapeado ainda; o risco cai com um parceiro experiente.
• Transportadora com Sankhya TMS implantado há pouco tempo e sem dor real hoje.

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 para diagnosticar, mesmo que a decisão final não seja migrar. Fale com um especialista KMEE.