Transformação digital é um problema de design de serviços, não de tecnologia

A transformação digital dá errado quando é conduzida como um programa de tecnologia: escolher uma plataforma, levar os formulários para a internet, contar os sistemas lançados. O cliente continua encontrando as mesmas passagens de bastão, os mesmos documentos e a mesma espera, só que agora numa tela. Trate-a como um problema de design de serviços. Redesenhe o que a pessoa está tentando resolver, de ponta a ponta, na linha de frente e nos bastidores, e só então decida o que a tecnologia precisa fazer.

A crença, dita com justiça

A crença é esta: os nossos serviços são lentos porque os nossos sistemas são antigos. Troque os sistemas, coloque os serviços on-line, e a experiência vai melhorar sozinha.

Não é uma crença tola. Sistemas antigos de fato deixam tudo mais lento. Papel de fato se perde. Muitos serviços realmente são melhores on-line, e alguns só ganham escala assim. O investimento em tecnologia também é fácil de planejar, aprovar e reportar. Tem fornecedores, marcos e data de lançamento. A diretoria consegue ver acontecer.

Então o instinto de começar pela tecnologia é compreensível. O problema é o que ele deixa de fora.

Por que falha na prática

Digitaliza o processo, não o resultado

O primeiro movimento da maioria dos programas é pegar o formulário existente e colocá-lo on-line. Cada campo, cada anexo, cada etapa de assinatura sobrevive à mudança. O cliente que antes fazia fila num balcão agora sobe os mesmos sete documentos num portal e depois espera que as mesmas três áreas aprovem em sequência. O serviço é digital. Não é melhor.

Os serviços atravessam áreas; os programas, não

O cliente vive um serviço só: "renovar minha licença", "abrir uma conta", "matricular meu filho na escola". Dentro da organização, esse serviço passa por várias áreas, cada uma com seu sistema, seu orçamento e suas metas. Os programas de tecnologia costumam ter escopo definido área por área, então cada parte é modernizada e as junções entre elas, onde mora a maior parte do atraso, ficam como estão.

Melvin Conway observou em 1968 que as organizações tendem a produzir desenhos que espelham suas próprias estruturas de comunicação. Os serviços digitais lhe dão razão todos os dias. Se três áreas não conversam entre si, o portal vai ter três seções que também não conversam.

Ninguém desenha os bastidores

A tela que o cliente vê é a linha de frente. Por trás dela estão as pessoas, políticas, aprovações e sistemas que de fato entregam o resultado. G. Lynn Shostack descreveu o blueprint de serviço pela primeira vez em 1982 e o levou a um público amplo de negócios num artigo de 1984 da Harvard Business Review, justamente para tornar visível essa parte escondida. A maioria dos programas de transformação desenha a linha de frente em detalhe e deixa os bastidores como estavam. O resultado é um app caprichado em cima de um processo que ainda precisa da assinatura de um gestor no papel.

O sucesso é medido como entrega, não como mudança

"Sistemas lançados", "serviços on-line" e "percentual digitalizado" são medidas de atividade. Todas podem subir enquanto o tempo para obter um resultado, o número de contatos repetidos e a taxa de desistência ficam parados. Quando o painel premia lançamentos, as equipes lançam. (Medir a coisa certa é o tema de Medir a transformação por resultados, não por atividade.)

O que funciona

Trate o serviço, e não o sistema, como unidade da transformação. Na prática, isso significa cinco hábitos.

1. Nomeie o resultado que a pessoa quer. Não "enviar solicitação", mas "conseguir autorização para abrir minha loja". Escreva com as palavras do cliente. Isso define os limites do trabalho, e eles quase sempre vão além de uma área.
2. Mapeie o serviço inteiro como ele funciona hoje. Use um mapa de experiência para vê-lo do lado do cliente e depois um blueprint de serviço para ver os bastidores: quem mexe no caso, o que verifica, pelo que espera. Percorra o serviço você mesmo; não o mapeie a partir do manual de procedimentos.
3. Questione cada passo antes de digitalizá-lo. Para cada documento, aprovação e campo, pergunte: por que isto está aqui, quem usa e o que acontece se tirarmos? Mudanças de norma e de processo costumam ser as melhorias mais baratas e maiores, e não custam uma linha de código.
4. Teste o novo serviço antes de construir o sistema. Rode a jornada redesenhada à mão por algumas semanas com um grupo pequeno, num teste concierge, ou coloque uma interface simples na frente de pessoas fazendo o trabalho manualmente, num teste Mágico de Oz. Você aprende o que a tecnologia realmente precisa fazer, que em geral é menos do que a especificação dizia.
5. Dê o serviço inteiro a uma pessoa. Nomeie um responsável pelo serviço com autoridade sobre as áreas envolvidas e meça o serviço pelo que o cliente recebe: tempo até o resultado, número de passos, contatos repetidos, desistências.

A tecnologia passa então a ser o que deveria ser: a forma de entregar em escala o serviço redesenhado, não o redesenho em si.

Um exemplo

Ilustrativo. A prefeitura de uma cidade europeia de porte médio conduziu um programa de três anos para "colocar o licenciamento de empresas on-line". O novo portal foi lançado no prazo. As solicitações continuaram levando mais ou menos o mesmo número de semanas, e as ligações para a central de atendimento aumentaram, porque os solicitantes não conseguiam saber qual das quatro áreas estava com o seu processo.

Pediram a uma pequena equipe que olhasse de novo. Ela fez o blueprint de uma única jornada, a de uma dona de café pedindo autorização para abrir, e encontrou onze passagens de bastão entre urbanismo, vigilância sanitária, prevenção de incêndio e licenciamento, cada uma esperando a anterior terminar. Três dos documentos exigidos já estavam com outra área. Duas aprovações eram sequenciais só por costume.

A equipe conduziu um piloto manual num distrito: um único analista responsável por cada solicitação do início ao fim, as áreas analisando em paralelo e os documentos duplicados eliminados. O portal ficou, mas a sua função mudou: passou a mostrar ao solicitante um responsável e um status. O piloto disse à prefeitura exatamente quais integrações valia a pena construir e quais nem eram necessárias.

O que fazer e o que evitar

Faça

• Comece por um serviço de alto volume, não pela organização inteira.
• Coloque na sala as pessoas que entregam o serviço, não só as que o gerenciam.
• Faça o blueprint dos bastidores antes de escrever qualquer requisito técnico.
• Trate normas e procedimentos como material de design, não como restrições fixas.
• Teste a nova jornada à mão antes de se comprometer a construir.

Evite

• Levar um formulário de papel para a internet campo por campo.
• Definir o escopo do trabalho por área ou por sistema.
• Reportar "serviços digitalizados" como sucesso.
• Deixar que o formato do produto do fornecedor decida como o serviço funciona.
• Entregar o redesenho só à TI, ou só ao design de serviços. Ele precisa dos dois, com a liderança da área de negócio à frente.

Perguntas frequentes

Design de serviços é só experiência do cliente com outro nome? Não. O trabalho de experiência do cliente muitas vezes se concentra no que o cliente vê e sente. O design de serviços cobre isso e também os bastidores: as pessoas, regras, sistemas e passagens de bastão que produzem a experiência. Na transformação, é nos bastidores que a maior parte da mudança precisa acontecer. Se você está escolhendo entre os dois mapas, veja Mapa da jornada ou service blueprint?

Ainda precisamos de um roadmap de tecnologia? Sim, mas ele deve vir depois do redesenho do serviço, não à frente dele. Quando vocês sabem como o serviço deve funcionar, o roadmap descreve o que os sistemas precisam fazer para sustentá-lo. Muitas organizações descobrem que a lista fica mais curta.

Por onde começar se tudo precisa ser corrigido? Escolha o serviço com mais volume e mais reclamações, mapeie-o de ponta a ponta e corrija primeiro as junções entre as áreas. Um serviço bem-feito ensina mais à organização do que dez feitos pela metade. Antes de redesenhar qualquer coisa, ajuda mapear o sistema antes de mudá-lo.

Para onde ir agora

Este texto faz parte da seção liderada por A transformação falha na porta do cliente. Para o trabalho prático, comece pelo blueprint de serviço e pelo mapa de experiência, use um mapa de sistema para ver quais áreas e regras moldam o serviço e uma matriz de pontos de contato para ver todos os canais que o cliente atravessa.