Uma maneira de construir sua arquitetura de negócios é estruturando a tecnologia com base nos resultados que você deseja atingir, para a própria empresa, claro, mas principalmente para seus clientes. E para garantir que você tenha não apenas ótimos resultados rapidamente, mas que também manterá essa arquitetura no futuro, a Pega acredita que é muito importante abordá-la de “dentro para fora”, ou como costumamos dizer, Center-out™. E isso significa evitar alguns erros muito comuns que as empresas cometem ao abordar a arquitetura de seus negócios. Nesse artigo, a companhia explica um pouco como tudo isso funciona. Confira!

Dois erros básicos de construção da arquitetura

O primeiro erro é começar pelo canal – ou seja, coisas como o seu aplicativo móvel, site, chatbot ou um contact center tradicional. E ao começar pelo canal, você acaba inserindo a lógica do negócio e do processo diretamente em cada canal, codificando cada um separadamente. E isso cria várias compartimentações, vários silos entre eles. Se você já entrou no site de uma empresa e depois ligou para seu contact center – apenas para descobrir que o pobre atendente do outro lado da linha não tinha a menor ideia do que você estava tentando fazer, você se deparou com uma dessas barreiras.

Isso sai muito caro para a empresa. Eles codificam todos os canais independentemente e sempre que uma alteração é necessária, ela precisa ser feita em vários lugares. Além disso, essa abordagem reduz a velocidade da resposta às necessidades dos clientes, algo em constante mudança – ainda mais nesse novo cenário, onde os clientes demandam um nível de experiência superior com provedores de serviço.

O segundo erro é começar da base da arquitetura, a partir dos sistemas mesmo, estruturando databases, mainframes e sistemas ERP. Até mesmo sistemas modernos baseados em cloud às vezes entram nessa categoria. Porque, no fim das contas, todos esses sistemas no fundo são bases de dados, sendo desenvolvidos como produtos setorizados, sem pensar na jornada do cliente de ponta a ponta. Essa abordagem é muito complexa e é muito difícil, além de demorada e custosa para as empresas, porque elas têm de fazer com que essa estrutura reflita a jornada que o cliente precisa ter.

Então, apesar de vários provedores dizerem que são centrados no cliente, na verdade, eles são centrados no canal ou nos sistemas e nos dados. Uma arquitetura verdadeiramente centrada no cliente começa com o cliente no centro. E, o mais importante, começa com os resultados que o cliente deseja atingir. Ela captura a jornada, ou, como a Pega costuma dizer, a “microjornada”, com os elementos de uma jornada de cliente mais ampla sendo conectados a um resultado específico. Por exemplo: contratar um serviço adicional é uma microjornada. Resolver um problema de faturamento é uma microjornada.

Portanto, é preciso começar a partir do centro – não do canal, nem dos sistemas – construindo uma microjornada comum que funcione em todos os canais, para que o cliente tenha uma experiência consistente. E se uma mudança for necessária, será possível alterar a microjornada, fazendo com que isso seja refletido instantaneamente em todos os canais, sem necessidade exagerada de programação. Segundo um estudo da Forrester Research, uma implementação desse tipo pode gerar o equivalente a 677 milhões de dólares em 3 anos. OK, mas como fazer?

Sua arquitetura tem que ter um cérebro

Quando você arquiteta seu negócio a partir da abordagem Center-out ™, isso significa que evitará os erros do hardcoding em cada um de seus canais, algo que acaba criando experiências desconectadas que são difíceis e caras de mudar. Isso também significa que você evitará erros de “bottom-up” para tentar contornar os sistemas legados e os bancos de dados pensados nos produtos. Com uma arquitetura de negócios com abordagem Center-out™, você começa tendo como centro o seu cliente e, mais importante ainda, começa a partir dos resultados que esse cliente está tentando alcançar.

Então, como você constrói a arquitetura de negócios com abordagem Center-out ™? Você precisa de um cérebro, uma inteligência computacional capaz de operar em todos os seus canais, tomar as decisões para ajudá-lo a realmente satisfazer seu cliente de maneira proativa e criativa e garantir que o trabalho seja realizado com eficiência de acordo com suas regras e regulamentos. E esse cérebro pode assumir diferentes formas:

  • Pode orientar os agentes/atendentes de contact center a encontrar a melhor maneira de solucionar um problema ou ajudar o cliente;
  • Pode consistir em uma PNL (Processamento de Linguagem Natural), capaz de coletar texto não estruturado (ao receber um e-mail ou documento e categorizá-lo, por exemplo), identificando a intenção do cliente e informações como nome ou número da conta; 
  • Pode assumir o formato de regras de negócios que são absolutamente essenciais para aplicar suas normas e regulamentos, garantindo que, se você estiver em um setor altamente regulamentado, esteja operando de acordo com essas políticas.
  • E pode assumir o formato de análise preditiva ou adaptativa. A análise preditiva é uma forma de machine learning usada para tratar os dados e encontrar padrões para que o sistema possa tomar decisões. Já a análise adaptativa é o machine learning que auto aprende (self-learning), se otimizando com o tempo. Você pode juntar esses dois formatos para adotar o que chamamos de a próxima melhor ação (o verdadeiro Next-Best-Action: NBA).

Então, como você descobre em tempo real, em todos os canais, qual é a conversa certa para ter com o cliente? Ou quando recomendar um novo produto? Qual é a melhor ação, que gerará mais valor para o cliente e para o seu negócio?

Em qualquer arquitetura, podemos encontrar diversos locais onde há inteligência. Talvez exista inteligência nos sistemas ERP ou em seus bancos de dados. Talvez você tenha um sistema de CRM que faça cálculos para descobrir o valor potencial do seu cliente. Mas o que importa de verdade é que sua arquitetura tenha um cérebro que atue como um árbitro nesse cenário! Este cérebro reunirá todas as informações relevantes que estão passando por seus diferentes canais, garantindo que, sempre que você converse com seu cliente, tenha uma conversa consistente e opere em tempo real com base nas informações mais recentes. E quando você consegue fazer isso, os resultados são inacreditáveis!

Case Management

Para que o cérebro seja realmente eficaz, ele precisa de duas coisas. Primeiro, ele precisa de contexto (precisa entender onde o cliente está em uma determinada jornada ou microjornada). Em seguida, ele precisa de “músculo”, a automação inteligente. Uma vez tendo esses dois elementos, o cérebro será capaz de fazer a Gestão de Casos (Case Management), executando o trabalho da forma mais eficaz – e rentável – possível no contexto da microjornada do cliente.

Isso é feito por meio da divisão do trabalho em etapas, os marcos pelos quais ele flui em direção à resolução – que são muito importantes, porque criam uma linguagem comum para todas as partes interessadas no caso. Podem ser pedaços reutilizáveis de um processo de negócios. Algumas podem ser paralelas; outras podem ser condicionais, acontecendo em circunstâncias distintas. Mas, com alguma sorte, a maioria será automatizada, para que você finalize o trabalho com eficiência e de uma maneira que seja fácil para o cliente. E, na medida em que isso acontece, o caso na verdade mantém uma trilha de autoria.

A Cisco, por exemplo, tem hoje um CRM que pode ser considerado centrado nos dados, mas que não tinha a capacidade Center-out™ de gestão de casos. Assim que a companhia incorporou a tecnologia Pega no sistema, eles conseguiram fazer com que 88% dos pedidos passassem diretamente pelo processamento do CRM, dispensando qualquer ação de agentes. Isso permitiu que 60% dos agentes fossem realocados do setor administrativo para o setor de operações, para trabalhar diretamente com os clientes e oferecer uma experiência altamente personalizada.

Então, além de diminuir custos, a Cisco conseguiu ainda aumentar o Net Promoter Score, a pontuação da experiência do cliente com seus serviços. Esse é o poder da gestão de casos.

Conectando-se aos canais

A partir do momento que a lógica é definida centralmente na arquitetura de negócios Center-out™, você precisa conectá-la aos canais, mas de uma forma que seja consistente em cada um deles. Ou seja: se você fizer uma oferta ao cliente no contact center e a resposta for “Não, muito obrigado”, o cérebro deve aprender com essa resposta para que você não insista na mesma oferta novamente por e-mail ou pela internet. Ou se um cliente iniciar um processo no site e depois ligar para o contact center, a tecnologia permitirá que o atendente retome o contato exatamente do ponto em que o cliente parou.

Mas a maneira como essa lógica é conectada nos canais é importante, pois pode variar muito. Em alguns casos, esse front-end pode muito bem ser da Pega, onde a companhia usa um sistema de design chamado Cosmos para oferecer uma experiência completa aos usuários finais, tudo baseado em low-code (o mínimo de programação possível). Mas em outros casos, é possível que a empresa use outras tecnologias, como Javascript, Angular ou React para desenvolver o site, ou usar o Adobe Experience Manager na gestão de parte das experiências digitais dos clientes.

Nesses casos a Pega oferece a chamada DX API, ou a experiência digital API. E o importante nisso é que essa experiência não é estática. Veja, quando temos uma API estática que conecta as decisões e os processos com os canais, em última instância é necessário codificar o processo novamente. Portanto, cada passo do processo representa outro passo no canal. E se outros processos forem adicionados ou se múltiplos canais forem usados, essa estrutura será muito difícil e custosa. 

Já a DX API possibilita que o processo e o caso informem o canal para que ele saiba exatamente quais campos são necessários, em qual passo o processo está. E, devido à maneira como a DX API informa o canal, se um passo é alterado ou até mesmo se um novo passo ou etapa é adicionado ao processo, o caso pode informar ao canal e ele se ajustará praticamente por mágica. A lógica permanece central e você ainda recebe a potência para usar o front-end que deseja para oferecer essa experiência. É assim que a lógica de negócio Center-out™ é mantida uniforme em todos os canais.

Live Data

Um outro ponto importante são os dados em tempo real. É necessário que também haja uma conexão com eles nos sistemas, para que seja possível automatizar esses processos e orientar as decisões com base em todos os bancos de dados. Em abordagens tradicionais, isso frequentemente é feito por meio da incorporação da busca por dados no processo. E essa é uma péssima ideia porque dá origem para vários “comportamentos ruins”, como, digamos, procurar os mesmos dados várias vezes, ou procurar dados desnecessários. E, sempre que é necessária uma alteração nos sistemas, é necessário também alterar os processos de negócios, o que interrompe a experiência do cliente e do funcionário.

Então, em vez de incorporar todas as buscas por dados diretamente nos processos, o indicado é uma camada de virtualização que isole a complexidade dos sistemas da lógica de negócios definida centralmente. Essa camada de virtualização é chamada de live data. Ela pega todos os dados do seu sistema – coisas como o cliente, a conta, a política ou a transação – e os reflete na gestão de caso em um formato padrão, independentemente da maneira como esses dados são armazenados na base e da necessidade de acessar um ou três sistemas.

A camada de dados em tempo real captura e gerencia toda essa complexidade, de maneira que o caso e a lógica do negócio precisam apenas consultar os dados no formato padrão dos negócios. E a camada de live data extrai os dados automaticamente apenas quando é necessário, ou quando antecipam sua necessidade para um caso. Portanto, nenhuma busca de dados é feita sem necessidade e você não lida com buscas duplicadas, que podem deixar os sistemas lentos.

Layers

Por fim, a última coisa que sua arquitetura Center-out™ precisa é de fato organizar o negócio em camadas. Por que isso é importante? Bem, a Pega tem conversado com vários clientes e o feedback das empresas é: “Nós temos 1.000 processos de negócios, e isso deixa o negócio complexo.” Mas, quando olhamos a situação com algum distanciamento, muitas vezes, não há 1.000 processos de negócios distintos. Existem 20, talvez 50. Mas esses processos têm variações, existem diferenças que precisam ser aplicadas a uma área regional da operação ou a um produto para um segmento específico de clientes.

E, historicamente, nós gerenciamos essas variações por meio do desenvolvimento de sistemas distintos, o que causa a compartimentação de vários esforços duplicados. Ou dividimos a implementação da equipe de vendas em vários domínios para gerenciar tudo isso separadamente, e isso acaba ficando muito caro com o tempo. Se pensarmos em camadas que começam nos canais, atravessam a lógica de negócios, e chegam até os sistemas, se torna possível lidar com a complexidade de maneira muito mais eficiente. O que a Pega propõe é fazer isso com o chamado Situational Layer Cake™ (SLC).

Essa função possibilita a criação de camadas de elementos comuns a toda a empresa para depois introduzir apenas os deltas, as diferenças, coisas que precisam ser especializadas. Simplesmente definimos as diferenças e as variações, para que, se for necessário alterar algo comum, a alteração seja feita em um lugar e refletida instantaneamente nos outros. Essa abordagem possibilita que você comece de maneira reduzida com um único processo, talvez com operação em uma única área, e consiga resultados rápidos em semanas, ou até mesmo dias, e use isso como base para conseguir escalar uma transformação muito mais global em toda a empresa.

Enfim, esse é o poder da uma arquitetura de negócios Center-out™ desenvolvida em camadas. Se você quer saber mais como funciona, acesse o site da Pega sobre o assunto e entre em contato com a companhia.