O que muda quando os sistemas deixam de só arquivar

Durante trinta anos, os sistemas das empresas fizeram uma coisa: guardar. Entrava informação, ficava lá, e quem precisasse dela ia buscá-la. Toda a interpretação — perceber o que aquilo queria dizer e o que fazer a seguir — era trabalho de pessoas.

O que muda agora é essa fronteira. O sistema passa a ler o que tem lá dentro e a dizer alguma coisa sobre isso. Não é uma mudança de ferramenta: é uma mudança na divisão do trabalho, e tem consequências dos dois lados.

Três cenas, antes e depois

No atendimento. Antes: chega um pedido, alguém lê, percebe do que se trata e encaminha. Depois: o pedido chega já classificado, com o histórico daquele cliente ao lado e uma resposta sugerida por baixo. Quem atende passa a rever em vez de começar do zero.

Na operação. Antes: descobre-se que uma encomenda está atrasada quando o cliente liga. Depois: o sistema repara que aquele processo está parado há mais tempo do que o habitual para aquele tipo de trabalho e avisa antes de alguém do lado de fora dar por isso.

Na direção. Antes: o relatório do mês diz o que aconteceu. Depois: diz o que aconteceu e assinala que há três clientes com um padrão de compra diferente do costume. Continua a ser a direção a decidir se isso interessa.

O trabalho que desaparece

Quase sempre o mesmo: o trabalho de preparar informação para outra pessoa a usar.

Exportar, cruzar, formatar, reescrever a mesma resposta pela vigésima vez, procurar num histórico onde está aquela conversa. É trabalho que ninguém reclama quando acaba, e que costuma ocupar mais horas da semana do que qualquer gestor imagina — porque está espalhado por todos, dez minutos de cada vez.

O trabalho novo que aparece

Esta parte fala-se menos, e é a que costuma correr mal.

• Rever. Alguém tem de olhar para as sugestões, sobretudo nos primeiros meses. Uma sugestão aceite sem ser lida é pior do que não haver sugestão nenhuma.
• Corrigir na origem. Quando o sistema erra, é preciso perceber porquê. Quase sempre é um dado mal registado, e é esse dado que tem de ser corrigido — não a resposta.
• Decidir os limites. Até que valor é que uma sugestão avança sozinha? Que tipo de pedido vai sempre a uma pessoa? Estas regras têm de ser escritas por alguém que responda por elas.
• Saber desligar. Se a coisa não estiver a resultar, alguém tem de poder dizê-lo sem que isso seja visto como um fracasso pessoal.

Quem responde pela resposta

É a pergunta que costuma ficar para o fim e devia ser feita no princípio: quando o sistema sugere um preço errado a um cliente, de quem é o problema?

A resposta prática é sempre a mesma — é da empresa. Perante um cliente, um tribunal ou o regulador, não há grande diferença entre um erro de uma pessoa e um erro de um sistema que a empresa pôs a funcionar. O que muda é que um erro de sistema se repete mil vezes antes de alguém dar por ele.

Por isso a decisão de onde pôr a fronteira — o que avança sozinho e o que passa por olhos humanos — é uma decisão de gestão e não uma opção técnica. Vale a pena tomá-la de propósito, e não por omissão.

O que não muda com isto

A parte desconfortável: nada disto corrige uma operação desarrumada. Se os dados estiverem inconsistentes, as sugestões saem inconsistentes — só que mais depressa e com melhor apresentação.

É por isso que este tipo de projeto começa quase sempre pelo mesmo sítio: arrumar a origem dos dados e ligar o que não se fala, em CRMs e integrações, antes de pôr inteligência nos circuitos de trabalho.

Que parte do seu dia é preparar informação?

Conte-nos onde a sua equipa perde horas a passar dados de um lado para o outro. Dizemos-lhe o que dá para tirar do caminho.

Pedir orçamento