Como o VTB chegou a um único conhecimento

Imagine que você está fazendo uma pergunta para o call center do banco e obtenha uma resposta. Então chegue ao ponto de venda, mas as informações obtidas anteriormente são irrelevantes. Para garantir que essas discrepâncias sejam evitadas, decidimos deixar a solução existente criada no banco no SharePoint, processamos todo o conteúdo, identificamos fontes de dados e consumidores e reembalamos todas as informações necessárias em um novo sistema de gerenciamento de conhecimento - o mesmo para todos os departamentos. Neste post, compartilharemos nossa experiência.



Declaração do problema e escolha da solução


Para começar, todas as informações relacionadas ao atendimento ao cliente, nossos produtos e serviços, precisavam ser unificadas. Historicamente, o conhecimento era armazenado em três grandes bases de conhecimento criadas em momentos diferentes, de fato, em bancos diferentes. Ao mesmo tempo, um dos principais requisitos era a capacidade de fornecer diferentes quantidades de dados - por exemplo, para pontos de venda e para ATP (call center). No primeiro caso, informações detalhadas são importantes: quando as pessoas acessam departamentos offline, esperam ouvir todos os detalhes sobre questões de interesse. No segundo caso, pelo contrário, basta uma breve informação - o principal é que seja fornecida de forma rápida e clara.

A tarefa foi complicada pelo fato de termos seis clientes internos. E, consequentemente, diferentes tipos de requisitos. Todos tinham critérios diferentes em relação à funcionalidade, desempenho e suporte. Por exemplo, a presença de SSO, integração com o Active Directory, etc. Os recursos de rápida implementação da equipe foram importantes. Esperávamos que o novo sistema reduzisse o tempo de serviço para 25% das chamadas para o call center em 5 segundos. Também reduzirá o tempo de treinamento. Anteriormente, 3% de todo o tempo de trabalho era gasto com isso - e quando se trata de mais de 30.000 trabalhadores, são gastos gastos consideráveis.

Além disso, durante o projeto, o VTB estava na fase de fusão de dois grandes bancos em sua estrutura, e os clientes do futuro sistema estavam em diferentes sub-redes, em diferentes segmentos. Tudo isso teve que ser combinado e fornecido aos funcionários que trabalham com o sistema, acesso completo, levando em consideração funções, vários níveis de acesso à informação etc. Foi necessário resolver muitos problemas adicionais de infraestrutura.

Colocamos todos os requisitos e critérios necessários em uma tabela de pontuação. Analisamos todas as principais soluções existentes no mercado, russas e estrangeiras, carregamos partes do nosso conteúdo e avaliamos o que funciona. E, no final, adotamos um sistema unificado de gerenciamento de conhecimento da KMS Lighthouse. Com a introdução, fomos ajudados pela equipe do Grupo DIS, que oferece o KMS Lighthouse no mercado russo.

2500 artigos em 16 modelos para 60 mil usuários


Existem duas entidades principais em nosso novo sistema de gerenciamento de conhecimento - "modelo" e "artigo". Um artigo é uma página formalizada com informações. O mesmo artigo parece diferente para todos os grupos de funções de usuário (funcionários do banco). Os grupos são formados dependendo da afiliação organizacional, funcional ou comercial dos funcionários.



Depois de analisar o conteúdo que temos, percebemos que estávamos lidando com 2500 artigos. Esse mar de informações precisava ser decomposto no número mínimo de modelos. Além disso, os artigos deveriam ter mantido a flexibilidade descrita acima. Houve muito trabalho manual na criação de modelos, coordenação e reconciliação. Mas, no final, consegui encontrar 16 modelos - para 2500 artigos, esse é um bom nível de sistematização.

Trabalhar no conteúdo


16 modelos são distribuídos em três grupos de gerenciadores de conteúdo. O primeiro grupo é responsável pelo conteúdo associado ao call center. O segundo é para produtos, serviços e informações relacionadas. O terceiro é o bloco de conteúdo da unidade operacional (DOPB), nosso back office. Além disso, temos uma unidade metodológica que opera no nível do banco. Quase todas as informações do banco passam por ele, como por um filtro, e, como resultado, apenas as informações que devem ser colocadas na base de conhecimento permanecem.

Discutimos uma divisão mais complexa. Pensou em apresentar os "proprietários" dos grupos responsáveis ​​pelo processo e sistema. Discutimos a posição do "editor chefe", que verificará todas as alterações. Mas no final, decidimos nos concentrar em três grupos, já que o conteúdo é claramente dividido entre eles.

O KMS Lighthouse permite que você crie rapidamente vários níveis de coordenação, mas decidimos não complicar esse sistema e, no nível dos gerenciadores de conteúdo, criamos dois níveis - aqueles que escrevem e aqueles que publicam. No último nível, destacam-se os responsáveis ​​por todo o conteúdo do grupo. É verdade que aqui surgiu a questão de fazer materiais com vendas bem-sucedidas para a divisão de alimentos, mas até agora eles decidiram deixar tudo como está.

Assim, a base de conhecimento pode ser desenvolvida sem demora. Suponha que um departamento de alimentos queira postar imediatamente informações sobre um novo produto. Envia uma solicitação por correio ao gerente de conteúdo: "Colegas, precisamos postar este artigo aqui." Depois de postar pelos mecanismos de feedback, o refinamento está em andamento: em algum lugar, a informação pode não ser suficiente, em algum lugar algo não está de acordo com o modelo. E assim por diante até que a unidade e o gerenciador de conteúdo estejam satisfeitos. Agora, estamos apenas introduzindo os elementos necessários para essa interação: notificações, pesquisas, formulários de aprovação. Se o artigo que está sendo criado cobrir as áreas de diferentes grupos de gerenciadores de conteúdo, todos se tornarão responsáveis ​​por sua própria guia.

Um servidor de aplicativos separado é alocado para gerenciadores de conteúdo, onde é possível editar artigos ou criar novos usando modelos existentes. Aqui você pode obter as estatísticas necessárias sobre consultas de pesquisa, a relevância de respostas, conversões etc. Os artigos não só podem ser alterados, mas também otimizados - por exemplo, crie metatags para melhorar a pesquisa. Além disso, a pesquisa pode ser aprimorada adicionando à força determinados artigos a determinadas consultas. Isso é chamado de "escolha do editor"; ao pesquisar, o usuário vê esses materiais em uma coluna separada.

Pesquisa base


No SharePoint, as pessoas estão acostumadas à estrutura em árvore de apresentar informações e interagir com guias. O KMS Lighthouse envolve o uso de uma pesquisa completa. Quando 60 mil usuários trabalham com o sistema (uma média de cerca de 1600 por vez), vale a pena pensar em balanceamento de carga. Agora o KMS Lighthouse roda em 10 servidores. Cada um implantou duas máquinas virtuais. Um monte de 20 máquinas virtuais funcionam. Entre eles está um balanceador de banco.



A pesquisa é baseada em três mecanismos de pesquisa que indexam todo o conteúdo. Os índices de pesquisa são criados levando em consideração as solicitações recebidas e sua frequência. A relevância das respostas e sua posição nos resultados de saída dependem disso. O Lighthouse analisa solicitações e pode apresentá-las na forma de 16 relatórios diferentes, com a ajuda de quais gerenciadores de conteúdo trabalham no preenchimento do sistema.

Recursos adicionais


Todos os funcionários que trabalham com o sistema são divididos em aproximadamente 35 grupos de funções. Cada um tem acesso a certas partes dos artigos. Um usuário pode estar em vários grupos - ele vê o conteúdo de todos esses grupos ao mesmo tempo.

Os grupos são integrados aos gateways de email e SMS. Ao trabalhar com um cliente do banco, um funcionário pode enviar rapidamente a ele as informações necessárias - por exemplo, durante uma consulta por telefone. Se, é claro, informações podem ser enviadas; artigos sobre divulgação (e admissibilidade impressa) indicam atributos individuais. Não há necessidade de reescrever e copiar e colar nada.



O Yandex.Maps também é integrado à base de conhecimento, através da qual os funcionários veem o quão ocupados certos departamentos estão. As informações são atualizadas a cada meia hora. Assim, tendo determinado em quais departamentos o cliente pode receber esse ou aquele serviço, os funcionários podem aconselhar onde exatamente é melhor abordar para economizar tempo.

O KMS Lighthouse está integrado ao nosso sistema front-end e pode ser trazido diretamente para sua interface como um widget. Nele, você pode fazer uma solicitação rápida e acessar imediatamente o artigo - como em qualquer mecanismo de pesquisa.

É assim que nossa nova base de conhecimento é organizada. Agora estamos finalizando e esperamos que não apenas os funcionários, mas também os clientes da VTB apreciem o efeito positivo da implementação do KMS Lighthouse.



Em conclusão, queremos compartilhar nossa alegria. Em janeiro, nossa Wikipedia de negócios foi anunciada como o projeto do ano, de acordo com o CIO Global. Manteremos você informado e informaremos quais são as novidades que prendemos a ela e como isso ajuda o trabalho.

Source: https://habr.com/ru/post/pt441020/


All Articles