Kennisbank

Por que um piloto sem acordo sobre o que deve ficar demonstrado não resulta em nada

A armadilha

Inicia-se um piloto. Uma equipa, uma ferramenta, um período de algumas semanas ou meses. No final, segue-se um feedback: correu bem, as pessoas ficaram entusiasmadas, algumas coisas aconteceram mais rapidamente. E então toma-se uma decisão com base nessa sensação, enquanto ninguém definiu previamente a que pergunta o piloto deveria efetivamente responder.

Essa é a armadilha. Não o piloto em si, mas a ausência de uma pergunta que o piloto deveria responder. Sem essa pergunta, qualquer resultado é um bom resultado, e é precisamente esse o problema. Um piloto sem acordo sobre o que deve ficar demonstrado não pode fracassar, e por isso também não pode provar nada.

Por que isto parece lógico

Um piloto parece uma forma segura de começar. Começar em pequena escala, ver o que acontece, depois escalar se funcionar. Isso parece sensato, e numa situação estável até é. Mas a IA não afeta apenas a equipa que executa o piloto. Afeta a forma como os dados são registados, quem decide sobre o quê, e quais sistemas precisam de comunicar entre si. Um piloto que nada mede sobre isso, também não mede nada sobre a questão de saber se o resto da organização obteria o mesmo resultado.

A lógica de "experimentar primeiro em pequena escala" assume que o sucesso em pequena escala se traduz em sucesso em grande escala. É precisamente por isso que escalar sem que a base esteja consolidada não resulta em nada: o que funcionou num piloto muitas vezes deveu-se a circunstâncias que não estão presentes noutros locais. Uma equipa motivada, um conjunto de dados limpo, um responsável que por acaso participou ativamente. Sem um acordo sobre o que deveria ser testado, permanece pouco claro se o resultado se deveu à tecnologia ou às circunstâncias excecionais em que foi testada.

Como percebe que está nesta situação

Há alguns sinais reconhecíveis.

O primeiro sinal é que o piloto termina com uma história em vez de uma resposta. Conta-se o que aconteceu, mas ninguém consegue dizer se a pergunta definida previamente — que na realidade nunca existiu — foi respondida.

O segundo sinal é que o piloto esteve isolado do resto da organização. Uma equipa, um caso de uso, sem ligação aos sistemas ou departamentos que deveriam sustentar o resultado se este funcionar. É a mesma armadilha de quando um piloto funciona apenas no seu próprio canto: o sucesso isolado diz pouco sobre o que acontece quando o resto da organização precisa de se juntar.

O terceiro sinal é que ninguém é dono do piloto. Há um gestor de projeto, talvez um fornecedor, mas nenhum responsável encarregado do que deve acontecer após o piloto. Só se percebe isto quando o piloto termina e a pergunta "e agora" permanece sem resposta, exatamente o padrão que se torna visível quando uma demonstração sem responsável não resulta em nada.

O quarto sinal é que a tecnologia foi testada, mas a estrutura na qual deve funcionar não foi. Funções, responsabilidades, linhas de decisão: permaneceram inalteradas durante o piloto, e é precisamente por isso que a tecnologia sobre uma estrutura inalterada não resulta em nada. Um piloto que não toca na estrutura testa apenas se a tecnologia funciona num ambiente que não precisa de mudar. Isso é uma pergunta diferente de saber se a organização está preparada para trabalhar com ela.

O que deve estar estabelecido primeiro

A ordem em que a maturidade em IA se constrói não é arbitrária. A organização, a infraestrutura de TI e a gestão de dados constituem a base sobre a qual as dimensões dependentes — como a forma como as pessoas colaboram com a IA ou como as decisões são tomadas — só depois podem assentar. Um piloto que ignora esta ordem mede, na prática, algo diferente daquilo que afirma medir. Mede a criatividade de uma equipa num determinado momento, não a maturidade da organização como um todo.

É também aqui que um CEO e um COO geralmente olham de forma diferente. Aquilo que um CEO analisa na maturidade em IA difere daquilo que um COO avalia nesse âmbito, e um piloto sem um ponto de medição acordado previamente deixa ambos sem referência. A questão não é se o piloto foi agradável, mas se diz algo sobre as dimensões que devem sustentar o resto.

Do piloto à medição

A medição de maturidade da hybridresourcing.com destina-se a tornar esse acordo prévio possível. Cinco níveis, de baseline a intelligence, em sete dimensões, com uma ronda de avaliação em que várias pessoas pontuam de forma independente, para que a dispersão fique visível em vez de uma única impressão ser tomada como verdade. Assim torna-se visível onde a organização realmente se encontra, antes de se iniciar mais um piloto que deverá provar, a posteriori, algo que nunca foi definido previamente.

Esta medição incide sobre a questão de saber se a organização pode sustentar a IA: se a base está estabelecida para que algo funcione de forma estrutural. Assim que essa pergunta é respondida, surge espaço para outra pergunta, nomeadamente que parte do trabalho efetivo a IA pode assumir. Essa pergunta é respondida pelo scan de trabalho da FTE TO AI, que calcula, por tarefa, que parte desta pode ser transferida para a IA. A ferramenta para esta medição de maturidade está em desenvolvimento; quem quiser utilizar a medição assim que estiver disponível pode inscrever-se na lista de espera.