Por debaixo de uma janela de chat acontece algo diferente de uma pergunta e uma resposta. Uma cadeia é uma série de etapas que se sucedem umas às outras sem que um ser humano tenha de voltar a premir o botão de início entre cada etapa. Um pedido chega, é lido, verificado em relação a uma regra, encaminhado para um sistema, e o resultado é comunicado a quem dele necessita. Para um ser humano, isso é uma série de ações consecutivas. Para uma cadeia, é um único movimento, desde que cada etapa saiba o que a anterior produziu e o que a seguinte necessita.
Automatizar uma única tarefa é algo manejável: ler um documento, fazer um resumo, responder a uma pergunta. Uma cadeia é outra coisa, porque um erro na etapa dois repercute-se na etapa cinco, e ninguém vê esse erro até o resultado já ter aterrado em algum lugar. É por isso que as cadeias exigem mais do que etapas isoladas: tem de existir algo que verifique se a transferência entre etapas está correta, e tem de existir alguém ou algo que intervenha se não estiver. Sem isso, uma cadeia torna-se uma linha de montagem sem botão de emergência.
Uma cadeia envolve múltiplos sistemas, o que significa que esses sistemas têm de conseguir comunicar entre si. Se um CRM, uma ferramenta de planeamento e um sistema de faturação usam cada um a sua própria definição de 'cliente' ou 'estado', a cadeia quebra-se no ponto em que ocorre a transferência. Isso não é um problema de IA; é uma questão que precede a IA, sobre se a infraestrutura e a gestão de dados estão organizadas de forma a que a informação possa passar de um sistema para outro sem correção manual.
Além disso, uma cadeia exige uma organização que saiba quem é responsável por quê quando algo corre mal. Numa tarefa isolada, essa questão é pequena: alguém verifica o resultado e corrige-o pessoalmente. Numa cadeia, a questão é maior, porque o erro pode ocorrer num sítio diferente daquele onde se torna visível. Quem acompanha a cadeia, quem deteta uma falha, e quem decide se a cadeia pode continuar a funcionar ou tem de parar, são questões que devem ser respondidas antes de a cadeia ser ativada, não depois.
Um padrão frequente é a sinalização que conduz a uma etapa subsequente: algo é detetado, e essa deteção desencadeia uma ação seguinte em vez de ficar apenas numa notificação. O que é necessário para isso está descrito na página sobre monitorização que encaminha automaticamente para uma ação subsequente. Outro padrão é uma cadeia que transfere etapas entre departamentos: algo que começa nas compras, passa pela área financeira, e termina nas operações, sem que alguém tenha de o reencaminhar constantemente. O que isso exige da organização está descrito na página sobre alinhamento entre departamentos que atualmente ainda passa por pessoas. Também uma cadeia que começa com um documento recebido — ler, avaliar, encaminhar — baseia-se no que se pode encontrar na página sobre documentos que são lidos e resumidos antes de alguém os reencaminhar.
O que uma cadeia produz depende de quantas dessas etapas realmente se encaixam umas nas outras. Uma cadeia que no papel tem dez etapas mas que encrava na etapa três porque um sistema não fornece dados atualizados produz pouco em comparação com uma cadeia de três etapas que efetivamente decorre sem interrupção. O comprimento da cadeia é menos importante do que a questão de saber se cada elo realmente se liga ao seguinte.
A razão mais comum para uma cadeia não funcionar é as camadas fundamentais não estarem prontas para isso. Dados estruturados de forma diferente num sistema em relação a outro, uma infraestrutura de TI que não consegue transferir etapas automaticamente, ou uma organização sem clareza sobre quem reativa uma cadeia interrompida — isso não são questões que uma cadeia resolva por si própria. É precisamente por isso que a ordem importa: primeiro as camadas fundamentais em ordem, só depois a etapa dependente de uma cadeia que efetivamente funciona sem interrupção. Uma organização que inverte esta ordem constrói uma cadeia sobre um alicerce que ainda não foi assentado.
Uma cadeia que funciona raramente é apenas um problema técnico. É uma questão organizacional: quem é o responsável pelo processo quando este já não está dividido em tarefas isoladas mas existe como um único movimento contínuo? Quem avalia se uma excepção na cadeia pode continuar ou tem de ser removida? Estas são exatamente as questões que a medição de maturidade da hybridresourcing analisa, ao longo das sete dimensões, antes de se poder dizer algo sobre uma cadeia específica.
Se uma cadeia pode funcionar dentro da sua organização é uma questão de preparação. Que parte do trabalho nessa cadeia pode efetivamente ser assumida pela IA é outra questão, e essa é respondida pelo scan de trabalho da FTE TO AI, que calcula por tarefa que parte do trabalho é elegível para ser assumida. O que isso exige da organização quando a IA já não responde apenas a uma tarefa mas executa um processo está descrito na página sobre o que a utilização de agentes de IA exige da sua organização. Antes de essa questão poder ser respondida de forma significativa, tem de estar claro se as camadas fundamentais estão em ordem — e é por aí que esta medição começa.
A medição de maturidade da hybridresourcing está em construção. Quem quiser saber como os cinco níveis ao longo das sete dimensões se relacionam com a própria organização, e como uma ronda de posicionamento torna visível a dispersão entre colegas, pode inscrever-se na lista de espera. Não há atualmente nenhum resultado a entregar; há sim um lugar para ser o primeiro a saber quando isso passar a existir.
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.