Houve um piloto bem-sucedido. A direção quer avançar rapidamente. A decisão é tomada: implementar no resto da organização, outras equipas, outros departamentos. O que funcionou num canto agora deve funcionar em todos os lugares.
Isso nem sempre corre bem. Não porque a tecnologia reage de forma diferente de repente, mas porque o ambiente em que ela deve funcionar está organizado de forma diferente em todos os lugares. A equipa onde o piloto teve sucesso tinha, por acaso, uma infraestrutura de TI capaz de suportar o que era exigido, uma gestão de dados em ordem e uma estrutura organizacional em que alguém assumia responsabilidade. Noutras partes da organização, um ou mais desses elementos estão diferentes. O resultado: o mesmo esforço gera resultados num lugar e nada em outro, ou, pior, trabalho extra para corrigir erros.
Escalar parece o próximo passo porque o piloto provou algo. Há um resultado, há entusiasmo, há pressão para aumentar o retorno. Quem já viu algo funcionar não quer mantê-lo limitado a uma equipa. Além disso, escalar é visível: mais utilizadores, mais equipas, mais linhas de processo que adotam a nova forma de trabalhar. Isso parece progresso, mesmo quando as dimensões fundamentais — organização, infraestrutura de TI, gestão de dados — ainda não estão em todos os lugares no nível em que a dimensão que depende delas pode funcionar.
A ordem em que isto funciona não é opcional. Se a camada fundamental não está estabelecida, a camada dependente não tem nada sobre o que construir. Isto não é uma questão de preferência ou de dar mais tempo; é a forma como as dimensões se sustentam mutuamente. Escalar ignora essa ordem e espera que a repetição de uma forma de trabalhar seja suficiente, mesmo sem a base que, por acaso, estava presente na primeira vez.
Alguns sinais aparecem com frequência. Equipas que adotam a nova forma de trabalhar relatam resultados variáveis, e ninguém consegue explicar bem por que funciona numa equipa e não noutra. Pede-se mais formação ou mais comunicação, enquanto o problema está noutro lugar: em sistemas que não se conectam entre si, em dados que não têm a mesma qualidade, numa estrutura em que ninguém é proprietário do resultado além das fronteiras das equipas.
Também é reconhecível a situação em que a tecnologia é implementada sobre uma estrutura que não mudou: a nova forma de trabalhar é disponibilizada tecnicamente, mas as funções, responsabilidades e linhas de decisão permanecem as mesmas de antes do piloto. Comparável é o padrão em que um piloto funciona bem no seu próprio canto, mas não se conecta ao resto da organização: a escalagem copia a forma de trabalhar, não as condições sob as quais essa forma de trabalhar surgiu.
Um terceiro sinal é menos visível, mas igualmente determinante: dois entusiastas carregam o projeto e mais ninguém se sente responsável. Enquanto a iniciativa depender de algumas pessoas que por acaso estão motivadas, não há base organizacional para escalar — há apenas entusiasmo que não se multiplica quando a equipa cresce.
Quem reconhece estes sinais deve perguntar-se se a dispersão entre equipas é uma consequência da execução, ou de uma diferença de preparação que já existia muito antes de se escalar. Essa distinção é exatamente o que a medição de maturidade da hybridresourcing analisa: não uma única pontuação para toda a organização, mas cinco níveis em sete dimensões, medidos através da pontuação separada de várias pessoas, tornando visível a dispersão entre as suas respostas. Essa dispersão diz frequentemente mais do que a média: se a avaliação do CEO diferir fundamentalmente da do CIO, parte da explicação de por que escalar funciona em alguns lugares e não em outros está aí. O que um CEO revela nesta medição sobre a própria organização e o que um COO reconhece nela a partir da execução diária raramente produzem a mesma imagem, e essa diferença é exatamente o que fundamenta a medição.
Esta página trata da questão de saber se a organização consegue suportar a IA: se a estrutura, a infraestrutura e a gestão de dados estão a um nível em que escalar faz sentido. Essa é uma pergunta diferente de saber qual parte do próprio trabalho é adequada para transferir para a IA. Esta última pergunta é respondida pelo scan de trabalho da FTE TO AI: este calcula, por tarefa, qual parte do trabalho pode ser assumida pela IA, independentemente de a organização já estar preparada para isso. As duas perguntas estão relacionadas, mas a ordem não é opcional — saber o que é transferível tem pouco valor enquanto não estiver estabelecido se a base pode suportar essa transferência.
A medição de maturidade da hybridresourcing ainda está a ser construída. Quem quiser utilizar a medição assim que estiver disponível pode inscrever-se na lista de espera.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.