Conhece a sua empresamelhor do que qualquerconsultor alguma vez conseguirá.
O que precisa é de alguém que construa. Não um documento de estratégia. Não um roadmap. Um sistema a funcionar — construído em torno de como as suas pessoas realmente trabalham, entregue em semanas, medido pelo uso diário.
“Trabalhei com empresas de 15 pessoas e empresas de 15.000. O problema é sempre o mesmo. As apostas são maiores quando são 15.”
Comecei em 1998 a implementar tecnologia em empresas portuguesas — a maioria pequenas, a maioria com pouca paciência para qualquer coisa que não funcionasse imediatamente. Esse contexto ensinou-me mais sobre adopção do que qualquer projecto enterprise alguma vez o fez. Quando a margem de erro é pequena, aprende-se depressa o que realmente importa.
O que aprendi: o CEO de uma empresa em crescimento já sabe qual é o problema. Vive com ele todos os dias. O que não tem é tempo, equipa técnica, ou confiança de que a solução que lhe estão a vender vai realmente ser usada pelas pessoas que a deveriam usar. Esse gap — entre conhecer o problema e confiar na solução — é o que construí a Bitsapiens para fechar.
A investigação por detrás desta abordagem — os frameworks para sistemas AI-Humanos, o pensamento sobre como as organizações precisam de evoluir para absorver tecnologia sem partir — está em amartins.io. É onde penso em voz alta antes de qualquer coisa se tornar um produto. Se quiser perceber por que razão trabalhamos como trabalhamos, é por aí que deve começar.
Construída para empresas que não se podem dar ao luxo de falhar com tecnologia.
Uma grande empresa que compra o sistema errado perde dinheiro e escreve um relatório sobre isso. Uma empresa de 20 a 200 pessoas perde meses de momentum, uma equipa desmotivada, e frequentemente uma parte significativa do seu orçamento anual de tecnologia — sem nada para mostrar.
Construímos a Bitsapiens para o segundo tipo de empresa. Não porque os clientes enterprise não sejam interessantes — mas porque as apostas são maiores, a margem de erro é menor, e as pessoas com quem trabalhamos estão mais próximas do problema do que qualquer outra pessoa na sala.
Não somos consultores que aconselham. Somos construtores que criam ao lado dos clientes — desde a primeira conversa até a um sistema a funcionar que a equipa realmente usa. Medimos o sucesso da mesma forma que o cliente mede: pelo facto de funcionar, e pelo facto de ainda estar a ser usado seis meses depois.
“A maior parte da tecnologia falha não porque não funciona. Porque ninguém mapeou como as pessoas a iam realmente usar.”
A equipa de finanças ainda processa facturas à mão às sextas à tarde. O director comercial ainda mantém o pipeline numa folha de cálculo que só ele percebe. O CEO ainda lê dados com três semanas de atraso.
O sistema existe. Ninguém o usa. O problema persiste.
Corrigimos a razão disso — antes de escrever a primeira linha de código.
Três coisas que fazemos
que a maioria não faz.
Começamos pelo problema, não pela ferramenta
A maioria dos vendedores de tecnologia começa com o produto e encontra uma forma de o aplicar à situação do cliente. Nós começamos pela situação do cliente — quem faz o quê, onde desaparece o tempo, que solução alternativa existe porque o processo oficial não funciona. Só depois de perceber isso decidimos o que construir. Esta é a fase que determina se o sistema é usado ou fica inactivo.
Construímos o que se vê antes de pagar pelo que se recebe
Antes de qualquer compromisso significativo, construímos um protótipo funcional com os dados reais do cliente. Não uma demo, não uma maquete — um sistema ligado aos processos reais. A equipa testa. Se não resolver o problema de forma satisfatória, o cliente pode retirar-se. Se resolver, discutimos como é a implementação completa. É assim que achamos que deveria funcionar — e como a maioria das compras de tecnologia deveria funcionar, mas não funciona.
Medimos o sucesso pela adopção, não pela entrega
Entregar um sistema não é o mesmo que resolver um problema. Continuamos envolvidos após a implementação — a formar equipas, a medir o uso real, a adaptar o que não está a funcionar. Porque um sistema que é entregue e abandonado não é um sucesso. É uma versão mais cara do problema que existia antes.
25 anos do mesmo problema. Finalmente, uma resposta diferente.
Em 1998, António Martins começou a implementar projectos de transformação digital em empresas portuguesas. Os sistemas eram mais simples. Os orçamentos eram menores. O problema fundamental era idêntico ao que ainda vemos hoje.
Tecnologia instalada em organizações que nunca foram redesenhadas para a receber. Equipas de armazém que continuavam a gerir stock em cadernos porque o ERP era demasiado lento para navegar no meio de um dia de trabalho. Equipas de finanças que mantinham ficheiros Excel paralelos porque o sistema oficial exigia três passos extra por cada transacção. Directores comerciais que mantinham o pipeline real numa folha de cálculo porque o CRM reportava o que deveria ter acontecido, não o que realmente aconteceu.
“O sistema funciona. As pessoas não o usam. E todos fingem que o problema são as pessoas.”
O problema nunca foram as pessoas. O problema foi que ninguém observou como realmente trabalhavam antes de desenhar o sistema que deveriam usar. E ninguém ficou tempo suficiente após a entrega para perceber por que razão a adopção não tinha acontecido.
Após 25 anos a ver este padrão em empresas de 15 pessoas e em empresas de 15.000 — a conclusão é a mesma. A ordem importa. Começar pelas pessoas. Perceber o que realmente fazem. Depois construir algo que se adapte a essa realidade. Tudo o resto são detalhes de implementação.
Perceber →
co-criar →
construir →
evoluir.
Cada projecto segue o mesmo processo de quatro fases — porque cada fase aborda um modo específico de falha que faz a maioria dos projectos digitais decepcionar.
Perceber
Começamos com observação, não com pressupostos. Quem faz o quê? Onde desaparece o tempo? Que solução alternativa existe porque o processo oficial não funciona? Esta é a fase que a maioria dos projectos salta — e cuja ausência explica a maioria dos fracassos.
Co-criar
Em conjunto, definimos a solução através de prototipagem iterativa. Quando os utilizadores moldam o produto em vez de assinar um documento de requisitos, o produto que emerge reflecte a sua realidade — não a nossa interpretação dela.
Construir
Desenvolvimento em ciclos de duas semanas com utilizadores reais a testar e a redirigir em cada iteração. O sistema que é entregue é o que foi refinado pelo uso real — não o que foi desenhado antecipadamente e descoberto errado no dia da entrega.
Evoluir
Os produtos nunca estão terminados. A tecnologia muda. As organizações mudam. Continuamos envolvidos após a implementação para formar equipas, medir a adopção e adaptar o sistema à medida que a realidade para que foi construído continua a desenvolver-se.
Inteligência distribuída.
A nossa equipa abrange múltiplas localizações — profundidade de experiência com amplitude geográfica. Os clientes em diferentes mercados recebem contexto local genuíno, não um serviço ajustado ao fuso horário.
Perguntas que ouvimos antes de cada projecto.
Somos uma empresa de 30 pessoas. Isto é para nós?
Sim — e é o tamanho de empresa com que melhor trabalhamos. Entre 15 e 200 pessoas, o CEO está suficientemente próximo do problema para o descrever com precisão e suficientemente afastado do dia-a-dia para ver o padrão. O investimento mínimo para um projecto é tipicamente €8.000–€12.000. A maioria dos nossos casos foi entregue entre €9.500 e €28.000, dependendo da complexidade.
Já comprámos tecnologia que ninguém acabou por usar. Como é que isto é diferente?
Começamos pela observação, não por pressupostos — a perceber como a equipa realmente trabalha antes de propor qualquer coisa. Construímos um protótipo funcional com os dados reais antes de qualquer compromisso significativo. E continuamos envolvidos após a entrega para medir a adopção e corrigir o que não está a funcionar. A maioria das implementações falhadas salta pelo menos duas dessas três coisas.
Não temos equipa de IT interna. Podemos trabalhar convosco?
Sim — e a maioria dos nossos clientes está exactamente nessa situação. Assumimos completamente o lado técnico. Não precisa de gerir programadores, perceber arquitecturas, ou traduzir entre negócio e tecnologia. O seu trabalho é descrever o problema e dar-nos acesso às pessoas que o têm. O nosso trabalho é todo o resto.
Com que rapidez pode estar algo a funcionar?
Na maioria dos casos, um protótipo funcional está pronto em 72 horas após a nossa primeira conversa — com os dados reais, ligado aos processos reais. A implementação completa leva tipicamente 4 a 12 semanas dependendo da complexidade do problema. Nunca entregámos um projecto que demorou mais de 14 semanas desde a primeira conversa até ao sistema em produção.
Tem um problema que lhe custa tempo ou dinheiro todas as semanas?
Diga-nos qual é em linguagem simples. Dizemos-lhe se já o vimos antes — e como foi resolvê-lo.
DESCREVER O PROBLEMA →