Quando uma empresa precisa de um sistema personalizado

A pergunta é econômica, não técnica

Todo software de prateleira parte de uma premissa: a de que a sua empresa opera como a média do mercado. Quando isso é verdade, comprar pronto é a decisão certa e mais barata, e insistir em construir é desperdiçar dinheiro para chegar a um resultado pior.

A questão, portanto, não é se um sistema sob medida seria melhor. Quase sempre seria. A questão é se a diferença entre o que a ferramenta atual entrega e o que a operação precisa é grande o bastante para pagar a construção, a manutenção e o risco de um projeto.

Essa conta tem dois lados que raramente são medidos com o mesmo cuidado. O custo de construir todo mundo estima. O custo de continuar como está — horas de contorno, retrabalho, controles paralelos, decisões atrasadas por falta de informação — quase ninguém calcula. Sem os dois números, a decisão é intuição.

Sinais de que o software de prateleira chegou ao limite

Estes sinais têm em comum o fato de indicarem um descompasso estrutural, e não uma insatisfação passageira com a ferramenta.

• A equipe mantém controles paralelos porque o sistema não prevê uma etapa essencial do processo.
• O processo que diferencia o seu negócio precisa ser dobrado para caber na ferramenta — e o resultado entregue ao cliente piora por isso.
• A ferramenta não expõe integração, o que trava qualquer conexão com o restante da operação.
• O custo por usuário cresce mais rápido que a empresa, mesmo quando o uso de muitos deles é pontual.
• Não há histórico: ninguém consegue saber quem alterou o quê, quando e por quê.
• Já foram testadas duas ou três alternativas de mercado e todas esbarraram na mesma limitação.
• O software é, ele próprio, o produto que a empresa pretende vender.

O sexto item merece atenção. Se apenas uma ferramenta foi testada, o problema pode ser escolha, não categoria. Se três foram testadas e todas falharam no mesmo ponto, o mercado provavelmente não atende aquele processo — e aí a construção passa a ser a hipótese razoável.

Sinais de que o problema não é o software

Este é o outro lado, e ignorá-lo produz o pior desfecho possível: um sistema novo, caro, que reproduz a mesma desordem em uma interface diferente.

• Cada pessoa executa o processo de um jeito. Construir obriga a escolher uma versão, e essa escolha feita às pressas costuma consolidar a pior delas.
• Ninguém concorda sobre quais são as regras. Se a alçada de aprovação muda conforme quem pede, o sistema não vai resolver — vai expor o conflito.
• A queixa é sobre relatórios. Frequentemente o dado existe e falta consolidação. Isso é projeto de indicadores, não de sistema.
• A queixa é sobre digitação dupla. Isso é falta de integração, e integrar costuma custar uma fração do que custa substituir.
• A queixa é sobre esquecimento e atraso. Isso é caso de automação sobre as ferramentas atuais.

As três alternativas que vêm antes

Antes de considerar construir, três caminhos mais baratos precisam ser testados e descartados por escrito. Se algum deles resolve, a discussão termina ali.

Um erro comum é pular direto para a última linha porque as três primeiras parecem paliativos. Às vezes são mesmo. Mas o teste é barato e a resposta muda a conta em ordens de grandeza — vale gastar algumas semanas para ter certeza.

O custo real de construir

A estimativa de desenvolvimento é a parte visível e frequentemente a menor. Um orçamento honesto de sistema sob medida inclui itens que raramente aparecem na primeira conversa.

• Migração dos dados históricos, incluindo a limpeza do que está inconsistente na base atual.
• Convivência com o sistema antigo durante a transição, que costuma durar mais do que o previsto.
• Treinamento e queda temporária de produtividade nas primeiras semanas de uso.
• Tempo da sua equipe. Alguém interno precisa decidir sobre regras de negócio ao longo de todo o projeto. Não é opcional e não é pouco tempo.
• Manutenção e evolução. Um sistema que não evolui volta, em poucos anos, a ser o problema que veio resolver.
• Hospedagem, segurança e cópias de segurança, que passam a ser responsabilidade da empresa e não mais do fornecedor da prateleira.

O teste do processo central

Quando a decisão continua empatada depois de todas as contas, existe um critério que costuma desempatar. Pergunte: o processo em questão é aquilo que faz o cliente escolher a minha empresa em vez da concorrente?

Se a resposta é sim, padronizá-lo dentro de uma ferramenta de mercado significa abrir mão do que diferencia o negócio. Aqui, construir é investimento em vantagem competitiva.

Se a resposta é não — se o processo é contabilidade fiscal, folha de pagamento, emissão de documento padronizado ou qualquer atividade em que ser igual a todo mundo é aceitável e até desejável —, construir é gastar dinheiro para reproduzir o que o mercado já entrega maduro, testado e atualizado por conta própria diante de mudanças de legislação.

Quando adiar a decisão

Existem momentos em que a resposta correta é esperar, mesmo com todos os sinais apontando para a construção.

• Quando o processo ainda está sendo descoberto e muda a cada mês. Estabilize antes de fixar em software.
• Quando não há ninguém disponível internamente para participar das decisões do projeto. Sistema construído sem interlocutor vira o sistema que o fornecedor imaginou.
• Quando a urgência é de semanas. Nenhuma construção séria entrega nesse prazo, e uma automação sobre as ferramentas atuais provavelmente resolve o alívio imediato.
• Quando a empresa está no meio de outra mudança grande. Duas transições simultâneas competem pela mesma atenção e costumam prejudicar as duas.

Se a decisão for construir, comece por onde

A pior forma de começar é tentar reproduzir de uma vez tudo o que o sistema atual faz. Isso produz prazo longo, escopo inflado e um projeto cujo valor só aparece no fim — quando o orçamento e a paciência já se esgotaram.

O caminho de menor risco é escolher o processo mais crítico e mais mal atendido hoje, entregá-lo em uma versão navegável e colocá-lo em uso real enquanto o restante é construído. Isso antecipa o retorno, revela erros de entendimento cedo e mantém a organização engajada.

Dois cuidados práticos fecham a decisão. Primeiro, defina em contrato de quem é o sistema, onde os dados ficam hospedados e o que acontece se a parceria terminar. Segundo, exija entregas navegáveis desde o início: acompanhar o avanço em partes é a única proteção real contra descobrir um mal-entendido no último mês. Uma conversa sobre sistemas personalizados só é produtiva depois que essas duas definições estão claras.