Como escolher uma empresa para automatizar processos ou desenvolver um sistema

Escolha pela forma de trabalhar, e não pela lista de tecnologias. Uma boa empresa de automação ou de sistemas começa pelo seu problema, diz quem vai desenvolver de fato, fecha o escopo por escrito (inclusive o que fica de fora), explica o que a sustentação cobre e deixa claro com quem ficam o código, os acessos e a documentação. Leve essas perguntas para a primeira conversa e compare as respostas, não só o preço.

Por que começar pelo problema, e não pela tecnologia?

A primeira conversa diz muito. Um fornecedor que propõe uma ferramenta, uma plataforma ou “uma IA” antes de entender como o trabalho acontece hoje está vendendo o que tem, e não resolvendo o que você precisa.

Uma boa primeira conversa tem mais perguntas do que respostas: como o pedido chega, quem confere, onde a mesma informação é digitada duas vezes, o que acontece quando algo dá errado. A partir disso, o fornecedor deve conseguir dizer se o caso pede automação, integração, um sistema novo ou nada disso.

Um bom sinal é ouvir que um software pronto resolve o seu caso. Quando ele resolve, deveria ser usado, porque custa menos. Outro bom sinal é a recomendação de uma regra simples onde você esperava inteligência artificial. Para chegar à reunião sabendo comparar os caminhos, veja software pronto ou sistema sob medida.

Quem vai desenvolver de fato?

Muitos problemas de projeto nascem da distância entre quem vende e quem constrói. Pergunte diretamente:

• Quem será o meu contato durante o projeto e depois da entrega?
• Essa pessoa escreve o código ou repassa o trabalho para outra equipe?
• O desenvolvimento é terceirizado, total ou parcialmente?
• Se a pessoa que conhece o sistema ficar indisponível, como outra pessoa assume?

A última pergunta é a que mais protege a empresa, e a boa resposta não é “confie em nós”. É código num repositório a que você tem acesso, documentação de como publicar e manter o sistema e acessos registrados em nome da empresa. Isso vale tanto para uma empresa com muitas pessoas quanto para um profissional independente: tamanho de equipe não substitui documentação.

Como o escopo é fechado?

Escopo é a descrição do que será entregue. Quando ele é vago, o projeto estoura no prazo, no preço ou nos dois. Pergunte como o fornecedor chega ao escopo:

• Em projeto pequeno, uma conversa bem conduzida pode bastar para fechar escopo e preço.
• Em projeto maior, é razoável haver um mapeamento antes do orçamento: o processo real, o que cada ferramenta faz hoje, onde está o retrabalho e quais integrações são necessárias.

O documento de escopo deve dizer o que entra, o que fica de fora, como mudanças no meio do caminho são tratadas e como você vai validar cada entrega. Desconfie de orçamento que é só um número: ele deve mostrar o que compõe o valor, como fluxos, integrações e regras de negócio. Para entender o que pesa no preço, veja quanto custa automatizar um processo.

O que a sustentação inclui?

Sistemas e automações precisam de cuidado depois da entrega: servidores, atualizações, integrações que mudam do outro lado, ajustes do dia a dia. Pergunte o que a mensalidade de sustentação cobre e peça a resposta por escrito:

• hospedagem, e quem paga cada serviço de terceiros;
• prazo de resposta para problemas, declarado em contrato;
• correção de falhas;
• pequenos ajustes, com um limite mensal definido;
• como novas funcionalidades são orçadas, separadas da sustentação.

A fronteira entre ajuste e funcionalidade nova é onde mais surgem conflitos. Se ela estiver escrita no contrato, a discussão acaba antes de começar.

Com quem ficam o código, os acessos e a documentação?

Esta é a pergunta de que as empresas costumam se lembrar só quando trocam de fornecedor. A Lei do Software (Lei 9.609/1998, art. 4º) atribui ao contratante de serviços os direitos sobre o programa desenvolvido durante o contrato, quando essa é a atividade prevista, mas a regra vale “salvo estipulação em contrário”. Ou seja: o que o contrato diz pesa, e vale revisá-lo com um advogado.

Na prática, pergunte:

• O código fica num repositório em nome da empresa, ou ao menos com acesso garantido a ela?
• Domínio, servidor e contas de serviços ficam no nome da empresa?
• Que documentação é entregue, e em que momento?
• Como o fornecedor trata os dados pessoais dos seus clientes? Pela LGPD, quem trata dados em nome da empresa deve seguir as instruções dela (art. 39).

Se você já está com um sistema e sem acesso a nada disso, veja como assumir um sistema de outro desenvolvedor.

Quais sinais de alerta observar?

• Prazo e preço fechados antes de alguém entender o processo.
• Proposta de trocar tudo sem olhar o que já funciona.
• Recusa em colocar por escrito o escopo, o que fica de fora e a sustentação.
• Respostas cheias de termos técnicos que não explicam o que muda na operação.
• Domínio, contas e código registrados apenas no nome do fornecedor, sem acesso da empresa.
• Promessa de retorno financeiro garantido.
• Orçamento muito abaixo dos outros, sem explicação do que ficou de fora.

Referências ajudam, mas leia com critério: conversar com um cliente atual ou ver um sistema em uso diz mais do que um depoimento curto. Tempo de mercado e tamanho da equipe dizem pouco se as respostas às perguntas acima forem vagas.

Quais perguntas levar para a primeira conversa?

Compare respostas, não promessas: o fornecedor certo é o que responde por escrito às perguntas que importam.

Como a Lutz Solution responde a essas perguntas?

As mesmas perguntas valem para qualquer fornecedor. Estas são as nossas respostas, que você pode conferir na primeira conversa:

• Problema antes da tecnologia: o trabalho começa pelo processo, e não pela ferramenta. Quando um software pronto resolve, isso é dito na primeira conversa.
• Quem desenvolve: quem desenvolve é o seu ponto de contato, do diagnóstico à sustentação. Não há camada de atendimento entre você e quem escreve o código, e o projeto não é repassado para outra equipe.
• Escopo: em projeto pequeno, a conversa inicial basta para fechar escopo e preço. Em projeto maior, há antes um diagnóstico pago, que mapeia o processo real, o que cada ferramenta faz, as tarefas repetitivas e o retrabalho, as integrações necessárias e o que fica de fora. O documento é seu mesmo que você não siga com o projeto; se seguir, o valor é abatido do desenvolvimento.
• Orçamento: montado a partir do que o processo precisa (fluxos, integrações e regras de negócio), sem pacote fechado. Uma estimativa sem compromisso pode ser pedida pelo WhatsApp.
• Sustentação: hospedagem, suporte com prazo de resposta declarado em contrato, correção de falhas e pequenos ajustes dentro de um limite mensal. Novas funcionalidades são orçadas à parte, e isso fica escrito no contrato.
• Tecnologia: a escolha é do projeto, não o contrário.
• Sistemas de outros fornecedores: também assumimos sistemas feitos por outra pessoa ou empresa, com um diagnóstico em linguagem clara do estado real antes do orçamento, inclusive quando a recomendação é reescrever.

Os detalhes de cada etapa estão em como funciona o diagnóstico, e quem conduz o trabalho está em quem é a Lutz Solution.