O projeto não termina porque a decisão comercial não foi digitalizada

TL;DR

• Projetos de digitalização B2B se prolongam não por falha técnica, mas porque o escopo foi desenhado em torno de fluxo de dados, não de fluxo decisório.
• Cada regra de negócio não prevista no mapeamento inicial vira um novo ticket, um novo ciclo e mais um trimestre sem go-live real.
• O problema não é a plataforma: é que ninguém mapeou quem tem autoridade para decidir preço, condição e exceção antes de começar a integrar.
• A saída é tratar a governança comercial como pré-requisito de arquitetura, não como configuração pós-implantação.

Por que o seu projeto de digitalização B2B ainda está em homologação?

Existe um padrão reconhecível na maioria das operações B2B que tentam digitalizar o canal de vendas: o cronograma original previa quatro meses. Um ano depois, o ambiente de homologação ainda está aberto. A equipe técnica entregou o que foi pedido. As integrações funcionam nos casos de teste. Mas o sistema não vai para produção porque, toda semana, alguém do comercial identifica uma exceção que o fluxo não cobre.

Esse padrão não é acidente. É o resultado direto de uma escolha de escopo feita no início do projeto.

A maioria dos projetos de digitalização B2B é desenhada em torno de fluxo de dados: catálogo, estoque, pedido, fatura. O problema é que venda B2B não é um fluxo de dados. É um processo de decisão. E decisão envolve autoridade: quem pode dar desconto acima de X, quem aprova prazo estendido para um cliente estratégico, quem valida a exceção de tabela para um canal específico. Quando esse mapa de autoridade não existe antes de a arquitetura ser desenhada, ele aparece depois, na forma de casos não previstos. E cada caso não previsto é um ticket, um ciclo de mapeamento adicional, uma nova rodada de alinhamento entre TI e comercial, e mais tempo de projeto.

O custo disso não é só o custo do projeto em si. É o custo de oportunidade de uma operação que não foi ao ar.

O escopo que ninguém coloca no documento de requisitos

O documento de requisitos de um projeto de digitalização B2B típico detalha integrações com ERP, regras de catálogo, fluxo de pedido e lógica de precificação estática. O que raramente aparece nesse documento: quem tem autoridade para aprovar uma condição comercial que foge da tabela padrão, em qual momento da jornada essa aprovação precisa acontecer e o que o sistema deve fazer enquanto espera.

Essa ausência não é negligência. É uma consequência natural de como os projetos são iniciados: a demanda começa na TI ou no digital, o briefing é construído com base em funcionalidades observáveis, e a dinâmica de decisão comercial, que vive na cabeça de gerentes e representantes seniores, nunca é explicitamente documentada porque ninguém a enxerga como parte do escopo técnico.

O resultado é uma plataforma tecnicamente funcional que não consegue operar autonomamente porque, toda vez que a transação sai do caso padrão, ela depende de uma intervenção humana que o fluxo digital não sabe nem como solicitar, muito menos como registrar e rastrear.

O mercado, enquanto isso, não espera. O segmento de plataformas B2B digital vem crescendo a dois dígitos globalmente. Distribuidores, indústrias e atacadistas que demoraram mais para ir ao ar entregaram vantagem competitiva para quem chegou antes, mesmo que com um produto inicial mais simples.

A ilusão do problema técnico

Quando um projeto B2B se prolonga, o diagnóstico mais comum dentro das empresas é técnico: a integração com o ERP é complexa, a qualidade dos dados de catálogo está ruim, a plataforma escolhida tem limitações. Esses problemas existem e consomem tempo. Mas raramente são o gargalo principal.

O gargalo principal, na maioria dos casos, é que a operação comercial não foi modelada como objeto de governança antes de ser digitalizada. Preço, crédito e exceções ainda moram na cabeça de pessoas específicas, e a plataforma, por mais robusta que seja, não consegue operar um processo que nunca foi explicitamente definido.

Isso cria um ciclo: a equipe de TI entrega, o comercial identifica a exceção, TI vai mapear, o mapeamento gera novo requisito, novo desenvolvimento, novo teste, nova rodada de homologação. E o projeto, tecnicamente, nunca termina porque o escopo real nunca foi fechado: ele estava sendo descoberto durante a implementação.

A saída para esse ciclo não é tecnológica no sentido estrito. É metodológica: tratar a formalização das regras comerciais, incluindo as regras de exceção e os fluxos de aprovação, como entregável obrigatório antes de qualquer decisão de arquitetura.

O custo da inação

Cada trimestre que o projeto permanece em homologação tem um custo mensurável e um custo difuso.

O custo mensurável: horas de equipe interna, licenças de plataforma ativas sem operação real, custo de consultoria de implantação, e o pedido que continuou sendo processado manualmente, com o custo operacional que isso implica.

O custo difuso, mas frequentemente maior: o canal digital que não foi ao ar não gerou dados. Sem dados de comportamento de compra, sem histórico de negociação digital, sem visibilidade sobre o mix de pedidos por canal. A operação que não digitalizou não só perdeu eficiência: perdeu a capacidade de aprender sobre o próprio cliente.

E há um terceiro custo que raramente é contabilizado: o desgaste interno. Projetos que se prolongam consomem credibilidade política da área de tecnologia junto ao negócio, tornam mais difíceis as próximas iniciativas de transformação e, em muitos casos, resultam na escolha de trocar de plataforma, reiniciando o ciclo com uma nova ferramenta e o mesmo problema de governança não resolvido.

Princípios para sair do ciclo

• Antes de definir arquitetura, mapear o fluxo decisório completo: quem aprova o quê, em qual momento, com qual prazo e o que acontece quando não há resposta.
• Tratar exceção como regra: em B2B, a exceção não é o caso raro, é o caso frequente; o sistema precisa ter fluxo de aprovação nativo, não um workaround manual.
• Separar o que é dado do que é decisão: integrações de catálogo, estoque e fatura são resolvíveis com arquitetura técnica; política de preço, crédito e condição são resolvíveis só com governança explícita.
• Definir o escopo mínimo viável em termos de processos cobertos, não de funcionalidades entregues: ir ao ar com menos casos cobertos e ampliar é mais produtivo do que prolongar o projeto para cobrir todos os casos antes do go-live.
• Incluir o gestor comercial como parte da equipe de projeto, não como validador final: ele é quem detém o conhecimento que precisa ser formalizado.

Perguntas frequentes

O problema é sempre de governança, ou às vezes a plataforma realmente tem limitações? Limitações técnicas existem e importam na escolha de ferramenta. Mas a maior parte dos projetos que não terminam carrega os dois problemas ao mesmo tempo: uma plataforma que poderia funcionar e uma governança comercial que nunca foi definida. Resolver só o técnico sem resolver o governamental prolonga o ciclo.

Como convencer o time comercial a formalizar regras que sempre foram informais? O argumento mais eficaz não é o da eficiência operacional: é o do risco. Regras informais dependem de pessoas específicas. Quando essas pessoas saem, a operação perde capacidade. Formalizar não é burocracia: é resiliência operacional.

Faz sentido trocar de plataforma quando o projeto está travado? Raramente. Na maioria dos casos, o problema que travou o projeto vai aparecer de novo com a nova plataforma, porque ele não estava na ferramenta. Antes de trocar, vale diagnosticar se o gargalo é técnico ou de governança.

Quem já vive isso

"Estavamos á quase 2 anos tentando implantar uma solução B2B, com a CWS, implantamos em 60 dias."

EDIVALDO C., reviewer verificado, setor automotivo, empresa de 201 a 500 funcionários, via Software Advice.

O relato é de uma empresa do setor automotivo com estrutura de médio porte. Dois anos de tentativa de implantação não foram revertidos por uma plataforma tecnicamente superior: foram revertidos por uma abordagem que incluiu o fluxo decisório no escopo desde o início.

Um caso que ilustra

Em operações B2B, o gargalo de produtividade raramente é capacidade humana: é a ausência de regras formalizadas no sistema. Quando política de preço, crédito e exceções migram da cabeça do vendedor para o fluxo digital, o tempo de resposta deixa de depender de disponibilidade humana. Esse é o movimento que transforma uma plataforma de canal em uma plataforma de governança comercial, e é o que separa projetos que vão ao ar de projetos que ficam em homologação.

Sobre esta publicação

O Custo da Venda é a publicação da CWS Platform sobre operação comercial B2B: negociação, governança de preço, digitalização de canal e custo de transação. A CWS Platform é uma plataforma B2B Commerce for Governed Negotiation, desenhada para digitalizar transações comerciais complexas com rastreabilidade de decisão.

Fontes

• Tese própria, CWS Platform: ponto de partida analítico sobre o padrão de projetos B2B que se prolongam por ausência de governança comercial no escopo, baseado em observação de operações reais.
• Software Advice, depoimento de EDIVALDO C.: avaliação verificada de usuário do setor automotivo publicada na plataforma de avaliação de software Software Advice. https://www.softwareadvice.com/product/546664-CWS-Platform/