Monitorização e sinalização é a promessa de que um sistema acompanha e dá um aviso a tempo: uma fatura anómala, um cliente que ameaça sair, um processo que encravou. Por baixo da janela de chat ou do painel onde esse aviso aparece, há uma cadeia de escolhas que a própria organização tem de fazer. Essa cadeia determina se a sinalização traz algo de útil ou se sobretudo acrescenta ruído.
Um sinal é um desvio de um padrão. Para reconhecer um padrão, tem de existir primeiro uma linha de base: dados sobre como as coisas normalmente decorrem, recolhidos de uma forma comparável ao longo do tempo. Isso exige dados introduzidos de forma consistente, nos mesmos campos, com as mesmas definições. Uma organização em que três departamentos têm três formas diferentes de registar uma reclamação ainda não tem uma linha de base — tem três linhas de base que não se encaixam entre si.
Também faz parte disto: quem é responsável pela qualidade desses dados. Uma sinalização baseada em dados que ninguém controla vai, a dada altura, comunicar algo que não está correto, e aí a questão é quem detecta isso e o corrige. Sem responsabilização sobre a fonte de dados, um sinal é uma aposta com uma marca temporal.
Todo o sistema de sinalização funciona com limiares: a partir de que desvio é que algo se torna uma notificação. Esse limiar não é um detalhe técnico, mas uma escolha de conteúdo. Definido demasiado baixo, e todos recebem constantemente notificações que não significam nada, até que ninguém mais as lê. Definido demasiado alto, e o sistema mantém-se silencioso enquanto algo já está a correr mal.
Definir esse limiar exige alguém que conheça o processo subjacente — não uma configuração geral igual para todas as equipas. Um limiar para sinalização de stock num armazém é uma questão diferente de um limiar para sinalização de rotatividade de pessoal. Esta é uma das dimensões fundamentais: sem uma organização que torne estas escolhas explícitas e as registe, é a tecnologia que define o limiar por si, geralmente com um valor padrão que não se ajusta exatamente a ninguém.
Um sinal que não chega a lugar nenhum não é um sinal. Isso exige um percurso definido: quem recebe a notificação, dentro de que prazo é analisada, e qual é o passo seguinte se a notificação estiver correta. Sem esse percurso, a notificação acaba numa caixa de entrada que ninguém considera a sua primeira prioridade, e a vantagem da sinalização precoce desaparece no atraso do acompanhamento.
Isto está relacionado com a forma como os departamentos trabalham entre si: um sinal sobre um cliente surge muitas vezes numa equipa e tem de ser acompanhado por outra. A forma como a coordenação entre departamentos decorre na sua organização determina se essa transferência corre sem problemas ou encrava na fronteira entre duas equipas que não estão habituadas a partilhar a mesma informação.
A sinalização muitas vezes não funciona sobre um único fluxo de dados estruturados, mas sobre uma combinação: números provenientes de um sistema, e texto de e-mails, relatórios ou registos. Um sistema que tem de sinalizar com base em cartas de reclamação ou atas de reuniões tem primeiro de conseguir ler e interpretar esses documentos. A forma como a sua organização lida com a leitura e resumo de documentos determina, por isso, também se a sinalização a partir de fontes textuais é viável, ou se ainda exige trabalho prévio ao nível da gestão documental.
O mesmo se aplica a conversas. Um sinal que resulta de algo dito numa conversa com um cliente só existe se essa conversa tiver sido registada de uma forma que um sistema possa pesquisar. Sem uma estrutura para registar e dar seguimento a conversas, essa informação permanece na cabeça de quem teve a conversa, e aí nenhum sistema sinaliza nada.
A sinalização não é uma ação. O sistema informa que algo está a acontecer; não intervém por si mesmo. Quem espera que um sinal leve automaticamente a uma solução está a confundir sinalização com outro tipo de trabalho: trabalho que é assumido e executado. O que é possível nesse âmbito está descrito em agentes que executam trabalho — uma camada diferente da camada aqui abordada.
A monitorização é muitas vezes a primeira coisa que se tenta, precisamente porque parece pequena e delimitada: um painel, uma equipa, um processo. Esse carácter delimitado é também a armadilha. Um sistema de sinalização que funciona num único local, mas que não está ligado ao resto da organização, permanece uma curiosidade em vez de um instrumento. A razão pela qual um piloto que só funciona no seu canto não gera nada está diretamente relacionada com este padrão: um sinal sem ligação a um processo que faça algo com ele permanece uma demonstração. E uma demonstração sem alguém que veja o acompanhamento como tarefa própria desaparece por si só; é também por isso que uma demonstração sem responsável não gera nada.
Se a sua organização está preparada para a monitorização e sinalização não depende da tecnologia disponível, mas de a linha de base, os limiares, o percurso de acompanhamento e a responsabilização já existirem. É precisamente isso que a medição de maturidade da hybridresourcing analisa: não se é possível, mas o que tem de estar primeiro estabelecido.
A monitorização e a sinalização dizem-lhe que algo está a acontecer. Não dizem qual parte do trabalho subjacente — a avaliação, o relatório, o acompanhamento — pode efetivamente ser assumida pela IA. Essa questão está a cargo do scan de trabalho da FTE TO AI, que calcula, por tarefa, qual a parte do trabalho que é elegível para isso, independentemente da questão de saber se a organização já está preparada para tal.
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.