A armadilha do stack tecnológico: por que mais ferramentas não significa mais transformação

Existe um fenômeno que poderíamos chamar de armadilha do stack: a tendência de organizações em processo de transformação digital a acumular ferramentas em vez de integrá-las. Cada área identifica suas necessidades, avalia as opções disponíveis e adota a ferramenta que parece mais adequada ao seu contexto específico. O resultado, visto de fora, é uma organização com dezenas de assinaturas ativas, múltiplos sistemas que fazem coisas parecidas, dados que vivem em silos distintos e uma equipe que dedica uma parte crescente do seu dia a alternar de contexto entre plataformas.

Mais ferramentas, nesse cenário, não produzem mais transformação. Produzem mais atrito.

, . ,

Como se constrói um stack disfuncional

O processo pelo qual uma organização acumula um stack tecnológico disfuncional raramente envolve más decisões individuais. Quase sempre é o resultado de decisões localmente corretas que produzem consequências sistemicamente problemáticas.

A equipe de marketing adota uma ferramenta de automação de campanhas porque é a melhor opção para suas necessidades. A equipe de vendas usa um CRM diferente porque se integra melhor aos seus processos específicos. A área financeira implementa uma plataforma de relatórios porque tem os conectores de que precisa. A área de operações usa um sistema de gestão que o fornecedor do equipamento recomenda.

Cada uma dessas decisões faz sentido vista isoladamente. Mas, em conjunto, produzem uma arquitetura onde os dados do cliente vivem em três sistemas que não se sincronizam, onde a equipe de vendas não tem visibilidade das interações de marketing, onde o financeiro não consegue cruzar dados de operações sem trabalho manual e onde ninguém tem uma visão integrada de nada.

A organização acabou com um stack caro, fragmentado e ingerenciável. Não por decisões irresponsáveis. Pela ausência de uma visão arquitetônica que anteceda as decisões individuais.

, . ,

O custo oculto das ferramentas que ninguém calcula

Quando se avalia uma ferramenta tecnológica, a análise habitual considera o custo da licença e, se a equipe for rigorosa, o custo de implementação. O que raramente se calcula com seriedade são os custos que se distribuem ao longo do tempo e que, em conjunto, podem superar de longe o custo da própria ferramenta.

O custo da fragmentação de dados. Cada sistema que não está integrado aos demais é uma fonte de trabalho manual de consolidação. Alguém precisa copiar dados de um sistema para outro, reconciliar versões que não coincidem e construir os relatórios que nenhum sistema individual consegue gerar. Esse trabalho é invisível no orçamento de TI, mas muito visível no tempo que consome.

O custo da troca de contexto. Cada ferramenta adicional que a equipe precisa usar implica trocar de contexto: interface diferente, lógica diferente, lugar diferente para encontrar a informação. A psicologia cognitiva documentou bem o custo da troca de contexto na produtividade. Em organizações com stacks muito fragmentados, esse custo é substancial e difícil de atribuir à tecnologia porque é vivido como "o trabalho que leva mais tempo do que deveria".

O custo da manutenção e da atualização. Cada ferramenta tem seu ciclo de atualizações, suas mudanças de interface, suas novas funcionalidades que precisam ser avaliadas e suas integrações que quebram quando algum dos sistemas envolvidos muda. Multiplicado por dezenas de ferramentas, esse custo de manutenção permanente é uma carga operacional significativa.

O custo da adoção incompleta. As organizações com ferramentas demais raramente aproveitam bem qualquer uma delas. A equipe usa 20% das funcionalidades de cada sistema, pagando por 100%. A adoção parcial é a regra, não a exceção, em stacks muito fragmentados.

, . ,

Os princípios de um stack que funciona

Um stack tecnológico que produz transformação real em vez de complexidade adicional se constrói seguindo princípios que são fáceis de enunciar e difíceis de manter sob a pressão constante de novas ferramentas promissoras.

Integração como condição, não como projeto posterior. Antes de adotar qualquer ferramenta nova, a pergunta obrigatória é como ela vai se integrar aos sistemas existentes. Não se ela pode integrar-se teoricamente, mas como vai se integrar na prática, a que custo e com quais dependências. Uma ferramenta que não se integra ao resto do stack não multiplica a capacidade da organização. Divide seus dados.

Profundidade antes de amplitude. Uma organização que usa plenamente três sistemas integrados tem mais capacidade analítica e operacional do que uma que usa parcialmente dez sistemas fragmentados. A tendência natural é acrescentar ferramentas para resolver problemas novos. A disciplina necessária é primeiro explorar se os sistemas existentes conseguem resolver o problema, antes de avaliar ferramentas novas.

O dado como ativo compartilhado, não como propriedade de cada área. O desenho do stack deve garantir que os dados gerados por cada sistema estejam disponíveis para o resto da organização de forma controlada. Um CRM que só a equipe de vendas pode acessar é menos valioso do que um cujos dados também enriquecem a operação do financeiro, do marketing e do atendimento ao cliente.

Simplicidade operacional como critério de avaliação. A melhor ferramenta não é a mais sofisticada. É a que a equipe consegue adotar completamente, que resolve o problema que precisa resolver e que se mantém sem exigir atenção técnica constante. A sofisticação que ninguém usa não gera valor.

, . ,

A diferença entre o stack certo e o stack da moda

O mercado de ferramentas tecnológicas para empresas é extraordinariamente bom em gerar urgência. A cada ano surgem soluções que prometem resolver o problema que nenhuma ferramenta anterior havia resolvido. As conferências do setor, os artigos especializados e os próprios fornecedores constroem narrativas sobre o que as organizações líderes estão usando e sobre o que as organizações que não estão usando estão perdendo.

Nenhuma dessas narrativas considera o contexto específico de cada organização. O stack que funciona para uma empresa de tecnologia com cem engenheiros de dados não é o stack certo para uma distribuidora de porte médio com uma equipe de TI de três pessoas. A ferramenta que gera transformação em uma organização com dados integrados e processos maduros pode ser uma distração cara em uma que ainda tem os dados no Excel.

O stack certo não é o mais avançado disponível. É o mais adequado ao estado de maturidade atual da organização e o que melhor prepara o terreno para o próximo nível de maturidade. E determinar qual é esse stack exige conhecer com precisão o ponto de partida.

, . ,

A arquitetura como decisão estratégica

As decisões sobre infraestrutura tecnológica, onde vivem os dados, como se conectam os sistemas, quais plataformas se adotam para quais funções, não são decisões técnicas no sentido de que devam ser tomadas apenas pelas equipes técnicas. São decisões estratégicas que determinam o que a organização pode e não pode fazer nos próximos anos.

Uma arquitetura cloud bem desenhada permite escalar sem investimento de capital em infraestrutura. Uma arquitetura com dados integrados permite uma análise transversal que uma arquitetura fragmentada não consegue produzir. Uma arquitetura construída sobre APIs abertas permite evoluir e trocar componentes sem substituir todo o sistema. Uma arquitetura construída sobre sistemas fechados e proprietários cria dependências que limitam a capacidade da organização de escolher ferramentas melhores no futuro.

Essas consequências estratégicas raramente são avaliadas no processo de seleção de ferramentas. São descobertas anos depois, quando mudar implica um custo que ninguém orçou.

, . ,

O diagnóstico do stack atual

O primeiro passo para construir um stack que funcione é entender o estado do stack que existe: quais sistemas há, como estão integrados, quais dados produzem e onde vivem, o que está funcionando e o que está gerando atrito operacional, e quais lacunas críticas existem entre o que a tecnologia atual pode fazer e o que o negócio precisa.

COBIZ Analyst realiza esse diagnóstico como parte de sua avaliação de escalabilidade técnica, identificando as lacunas mais críticas na arquitetura tecnológica atual e as prioridades de investimento com melhor relação entre impacto no negócio e viabilidade de implementação.

Avalie o estado do stack tecnológico da sua organização e as lacunas mais críticas.
Faça o diagnóstico gratuito no COBIZ Analyst →

, . ,

Menos, porém melhor integrado

O paradoxo do stack tecnológico é que menos ferramentas, mais bem integradas e mais completamente adotadas, produzem mais transformação do que mais ferramentas fragmentadas e parcialmente usadas.

As organizações que entendem isso não avaliam sua maturidade digital pela quantidade de sistemas que têm. Avaliam pela qualidade das decisões que esses sistemas viabilizam, pela fluidez com que os dados fluem entre as áreas e pelo tempo que a equipe dedica a trabalhar com a tecnologia em vez de em torno dela.

Essa diferença, trabalhar com a tecnologia versus trabalhar em torno dela, é talvez a descrição mais prática do que significa ter um stack que funciona.

, . ,

Antes de avaliar a próxima ferramenta que o mercado propõe, vale a pena se perguntar se as que já existem estão sendo aproveitadas completamente. Quase sempre, a resposta revela mais oportunidade do que se esperava.