A transformação falha na porta do cliente: como desenhar uma mudança que as pessoas sentem

A transformação dá certo quando duas coisas mudam num dia de trabalho comum: a forma como as pessoas da linha de frente fazem o seu trabalho e o que o cliente vive no momento em que lida com vocês. A maioria dos programas muda a estrutura, os sistemas e a apresentação, e para antes desses dois lugares. A saída é desenhar a mudança de trás para a frente, a partir do momento do cliente, mapear o sistema que produz esse momento e deixar que as equipes que fazem o trabalho sejam donas do roadmap e das medidas.

Este é o texto principal da nossa série sobre Transformação. Ele mapeia o tema inteiro e leva aos textos mais aprofundados sobre cada parte.

Por que a transformação para antes de chegar a alguém

Imagine um programa típico. Um novo modelo operacional é aprovado. As áreas mudam de nome. Uma plataforma é comprada e configurada. Os painéis ficam verdes. Dezoito meses depois, um cliente liga com o mesmo problema de antes, é passado entre as mesmas três equipes e espera o mesmo número de dias. A funcionária que atende o telefone ainda usa uma gambiarra, porque o novo sistema não trata os casos que ela vê toda semana.

Nada nessa história é falta de esforço. É erro de pontaria do esforço. Os programas costumam ser desenhados de cima para baixo: estratégia, estrutura, tecnologia, processos, pessoas. O cliente aparece no fim, como meta de satisfação. Quando a mudança chega à linha de frente, já foi traduzida tantas vezes que ninguém sabe dizer o que deveria ser diferente na terça de manhã.

Três padrões aparecem o tempo todo:

• A mudança é organizada por área, mas o cliente circula entre áreas. Cada unidade melhora a sua parte. As passagens de bastão entre elas, onde está a maior parte da dor, não pertencem a ninguém.
• Mede-se a atividade em vez do resultado. Contam-se treinamentos realizados, sistemas lançados e políticas publicadas. Se um único cliente espera menos, isso não se conta.
• Quem faz o trabalho é informado, não envolvido. Recebe o novo processo numa reunião de apresentação. Sabe exatamente por que ele não vai funcionar nos casos difíceis, e ninguém perguntou.

Analisamos o segundo e o terceiro padrões em profundidade em por que os programas de transformação produzem relatórios e ninguém muda a forma de trabalhar.

As quatro camadas de uma transformação que as pessoas sentem

Ajuda pensar a transformação em quatro camadas, de fora para dentro. A mudança precisa ser desenhada nas quatro, e nessa ordem de atenção.

1. O que o cliente sente. Os momentos em que um cliente, cidadão ou colaborador encontra o seu serviço: o formulário, a ligação, o balcão, a mensagem, a espera. É a única camada que alguém de fora da organização vive.
2. Como as pessoas trabalham. As ações de linha de frente e de bastidores que produzem cada momento: quem faz o quê, com qual informação, em que sequência e com quanta autonomia.
3. O sistema por baixo. Políticas, regras de aprovação, sistemas de TI, dados, incentivos, orçamentos e linhas de reporte. Essa camada decide o que as pessoas podem e conseguem fazer.
4. Como a mudança é conduzida. O roadmap, a responsabilidade, a governança e as medidas que guiam o programa ao longo de meses e anos.

A maioria dos programas começa pela camada quatro e gasta sua energia na camada três. A camada do cliente é tratada como um resultado que virá depois. Raramente vem, porque ninguém desenhou a ligação entre uma nova política e um momento diferente no balcão.

O trabalho de experiência do cliente começa pela ponta oposta. Se a sua organização ainda está construindo esse hábito, leia foco no cliente é prática, não slogan: por onde começar junto com este texto. A transformação é onde essa prática precisa ganhar escala em toda a organização.

Como desenhar uma mudança que as pessoas sentem: sete passos

Estes passos servem tanto para a transformação organizacional quanto para a digital. Não substituem a gestão do programa. São o que você coloca dentro dela para que a mudança aconteça de fato.

1. Escolha jornadas, não áreas

Escolha de três a cinco jornadas do cliente que mais importam para o propósito da organização e que atravessam várias unidades: "obter uma licença", "abrir um sinistro", "entrar como novo colaborador", "mudar um plano de pagamento". Organize a primeira onda da transformação em torno dessas jornadas. Cada jornada ganha uma pequena equipe multifuncional, com um responsável nomeado que tem autoridade para mudar as coisas atravessando as fronteiras entre áreas.

Escolha jornadas sobre as quais você já ouve reclamações repetidas, em que a demanda é alta ou em que um objetivo estratégico está em jogo. Evite começar pela jornada politicamente mais segura; ela ensina à organização que a transformação é cosmética.

2. Vá ver antes de desenhar qualquer coisa

Antes de qualquer workshop, a equipe da jornada vive o serviço como um cliente viveria e observa-o sendo entregue. Um safári de serviço coloca os membros da equipe para percorrer a jornada pessoalmente. A observação contextual significa sentar ao lado da linha de frente enquanto ela trabalha, anotando cada gambiarra, planilha e ligação que o processo oficial não menciona.

Este passo muda aquilo em que o programa acredita. Executivos descobrem com frequência que o processo que aprovaram não é o processo que roda.

3. Mapeie a experiência e o trabalho por trás dela

Desenhe a jornada atual com um mapa de experiência: etapas, ações, pensamentos, sentimentos e pontos de dor do lado do cliente. Depois desenhe por baixo o blueprint de serviço, a ferramenta que G. Lynn Shostack apresentou nos anos 1980, que mostra as ações de linha de frente, as ações de bastidores e os processos de suporte, separados pela linha de visibilidade.

É no blueprint que a transformação fica concreta. Dá para apontar a passagem de bastão exata em que um caso espera quatro dias, ou o passo em que a equipe redigita dados porque dois sistemas não se falam. Se não tiver certeza de qual dos dois mapas precisa primeiro, veja mapa da jornada ou service blueprint.

4. Mapeie o sistema antes de mudá-lo

O blueprint mostra o trabalho. Não mostra por que o trabalho é do jeito que é. Para isso você precisa de um mapa de sistema das regras, incentivos, fluxos de dados e decisões que mantêm o padrão atual no lugar, e de um mapa de stakeholders de quem ganha, quem perde e quem precisa aprovar.

Acrescente uma análise de campo de forças, a ferramenta de Kurt Lewin para listar as forças a favor e contra uma mudança. Ela muitas vezes revela que a força de restrição mais forte é uma única regra de aprovação ou um indicador de reporte, e não a resistência das pessoas. O passo a passo completo está em mapear o sistema antes de mudá-lo.

5. Desenhe os novos momentos e o novo trabalho juntos

Agora desenhe a jornada futura: quais momentos mudam, o que o cliente deve sentir em cada um e o que cada pessoa por trás da linha de visibilidade vai fazer de diferente. Desenhe as camadas um e dois na mesma sessão, com a linha de frente na sala. Uma nova promessa ao cliente sem uma nova forma de trabalhar por trás é um slogan.

Teste os novos momentos antes de construir qualquer coisa. Uma dramatização da nova conversa no balcão, feita com a equipe real e alguns clientes reais, expõe lacunas numa tarde que o desenvolvimento de um sistema exporia em seis meses. Para toda a gama de testes baratos, veja testar uma experiência antes de construí-la.

6. Construa um roadmap de que as equipes sejam donas

Transforme as mudanças desenhadas num roadmap organizado por jornada e por resultado, não por versão de sistema. Cada item diz qual momento melhora, qual equipe é dona dele e o que será desativado quando ele entrar em vigor. Use uma matriz RACI para as decisões entre áreas, para que as passagens de bastão tenham dono.

A questão é a responsabilidade. Um roadmap escrito por um escritório de programa e entregue às equipes é um cronograma. Um roadmap que as equipes das jornadas escreveram, e revisam a cada trimestre, é um compromisso. Como montar isso está em conduzir um roadmap de transformação de que as equipes sejam donas.

7. Meça o que as pessoas sentem e desative o que elas não precisam mais

Construa uma árvore de KPIs que ligue o objetivo estratégico aos resultados das jornadas (tempo de resolução, contatos repetidos, casos concluídos de primeira, esforço) e, mais abaixo, às medidas operacionais que as equipes conseguem mover. Reporte essas medidas, não a contagem de workshops ou de entradas em produção. O método está em medir a transformação por resultados, não por atividade.

Depois mantenha uma lista do que parar de fazer. Todo processo novo deve desligar um formulário, relatório, aprovação ou sistema antigo. A transformação que só acrescenta é como as organizações acabam com o jeito novo e o antigo funcionando lado a lado, e a equipe fazendo os dois.

Onde entra a transformação digital

A transformação digital é a versão mais comum desse problema, e a mais cara quando dá errado. Uma nova plataforma reproduz o processo antigo numa tela, ou impõe um processo que a linha de frente não consegue usar, e o cliente vê uma interface mais bonita sobre o mesmo atraso.

Trate cada iniciativa digital como um redesenho de serviço que, por acaso, envolve tecnologia. Comece pela jornada e pelo blueprint, decida quais momentos e passagens de bastão devem mudar e só então especifique o sistema. O argumento completo está em transformação digital é um problema de design de serviços.

Se você precisa saber o quanto a organização está pronta para conduzir esse tipo de trabalho, uma avaliação de maturidade em inovação dá uma linha de base. Se a própria agenda de transformação não está clara, comece por construir uma estratégia de inovação em poucos workshops.

Exemplo ilustrativo: o novo sistema de faturamento de uma concessionária

Ilustrativo. Uma concessionária regional de água num país europeu de porte médio está há dois anos num programa de transformação. A peça central é uma nova plataforma de faturamento e atendimento. Ela entrou em produção dentro do prazo. As reclamações sobre contas não caíram, e o tempo médio de atendimento subiu.

O diretor do programa pede uma abordagem diferente para uma jornada: "a minha conta parece errada". Forma-se uma equipe de seis: dois atendentes da central, um analista de faturamento, um técnico de campo, um product owner de TI e uma gerente de atendimento como responsável pela jornada.

Eles passam uma semana num safári de serviço e sentados ao lado dos atendentes. Descobrem que os atendentes não conseguem ver o histórico de leituras do hidrômetro na nova plataforma, então abrem um chamado para o faturamento a cada dúvida. O faturamento trata os chamados em lotes. Ao cliente se promete um retorno em cinco dias, e muitas vezes ele recebe uma carta em vez disso.

O blueprint mostra três passagens de bastão em que os casos esperam. O mapa de sistema mostra por quê: uma regra de proteção de dados tinha sido interpretada de modo a restringir os dados de leitura à equipe de faturamento, e a própria meta do faturamento conta chamados fechados, não dúvidas resolvidas no primeiro contato.

A equipe desenha um novo momento: o atendente explica a conta na primeira ligação. Por trás disso, os atendentes ganham acesso somente leitura ao histórico de leituras, acordado com o encarregado de proteção de dados, e um roteiro curto para as três causas mais comuns. Eles fazem uma dramatização com dez clientes voluntários antes de qualquer mudança de configuração. A meta do faturamento passa a ser dúvidas resolvidas de primeira. A carta de retorno entra na lista do que parar de fazer.

O item do roadmap pertence à equipe da central de atendimento, não à TI. A medida reportada ao conselho é a parcela de dúvidas sobre contas resolvidas no primeiro contato, acompanhada mensalmente.

O que fazer e o que evitar

Faça

• Comece com um número pequeno de jornadas que atravessam áreas e dê a cada uma um único responsável com autoridade real.
• Coloque a linha de frente em todas as sessões de desenho, não só na apresentação depois.
• Observe o trabalho antes de redesenhá-lo. O processo oficial e o real raramente são iguais.
• Mapeie regras, incentivos e fluxos de dados; em geral, é ali que a mudança está travada.
• Teste os novos momentos com dramatização ou um piloto manual antes de configurar sistemas.
• Faça um pré-mortem de cada item do roadmap: imagine que ele fracassou daqui a um ano e liste os motivos.
• Desative algo toda vez que lançar algo.
• Faça uma retrospectiva com cada equipe de jornada a cada trimestre e mude o roadmap com base nela.

Evite

• Medir o sucesso por entradas em produção, horas de treinamento ou número de processos documentados.
• Redesenhar o organograma primeiro e torcer para que a experiência do cliente venha atrás.
• Deixar o escritório de programa escrever o roadmap sozinho.
• Digitalizar um processo que você não olhou de perto; você vai automatizar a espera.
• Tratar o trabalho de experiência do cliente como uma frente separada ao lado da transformação. Ele é o teste da transformação para saber se algo mudou.
• Anunciar uma nova promessa ao cliente antes que o trabalho por trás dela tenha mudado.

Perguntas frequentes

Por que a maioria das transformações falha? Raramente por falta de esforço ou de dinheiro. Falham porque a mudança é desenhada e medida no nível da estrutura e dos sistemas e nunca é desenhada até os momentos específicos que clientes e equipes vivem. As passagens de bastão entre áreas, onde está a maior parte do atraso e da frustração, não pertencem a ninguém, então continuam iguais.

Qual a diferença entre transformação e gestão de mudança? A gestão de mudança costuma tratar de ajudar as pessoas a adotar uma mudança que já foi decidida. A transformação, bem-feita, envolve essas pessoas na decisão sobre o que muda, para começar. Os métodos deste texto tornam isso possível: a equipe ajuda a observar, mapear, desenhar e testar a nova forma de trabalhar, e a adoção deixa de ser um problema separado para resolver depois.

Como saber se uma transformação está funcionando? Olhe para o cliente e para a linha de frente, não para o programa. As jornadas estão mais rápidas ou mais fáceis em medidas que os clientes reconheceriam? Os contatos repetidos estão caindo? A equipe parou de usar gambiarras? Algo antigo foi desligado? Se a resposta às quatro perguntas é não, o programa está ocupado, não funcionando.

Para onde ir agora

Comece por uma jornada. Use um safári de serviço para vê-la como o cliente vê, um blueprint de serviço para ver o trabalho por trás dela, um mapa de sistema para ver o que a mantém no lugar e uma árvore de KPIs para decidir como vocês vão saber que ela mudou. Os 75 guias de métodos estão na biblioteca de guias.