Imaginez que vous appelez une question au centre d'appels de la banque et obtenez une réponse. Venez ensuite au point de vente, mais les informations obtenues précédemment ne sont pas pertinentes. Afin de garantir que ces écarts soient garantis pour être évités, nous avons décidé de laisser la solution existante créée sur la banque dans SharePoint, de traiter tout le contenu, d'identifier les sources de données et les consommateurs, et de reconditionner toutes les informations nécessaires dans un nouveau système de gestion des connaissances - le même pour tous les départements. Dans ce post, nous partagerons notre expérience.
Énoncé du problème et choix de la solution
Pour commencer, toutes les informations relatives au service client, nos produits et services, devaient être unifiées. Historiquement, les connaissances étaient stockées dans trois grandes bases de connaissances créées à différents moments, en fait, dans différentes banques. Dans le même temps, l'une des principales exigences était la capacité de fournir différentes quantités de données - par exemple, pour les points de vente et pour l'ATP (centre d'appels). Dans le premier cas, des informations détaillées sont importantes: lorsque les gens viennent dans des services hors ligne, ils s'attendent à entendre tous les détails sur les questions d'intérêt. Dans le second cas, au contraire, de brèves informations suffisent - l'essentiel est qu'elles soient fournies rapidement et clairement.
La tâche a été compliquée par le fait que nous avions jusqu'à six clients internes. Et, en conséquence, différents types d'exigences. Tout le monde avait des critères différents concernant la fonctionnalité, les performances et le support. Par exemple, la présence de SSO, l'intégration avec Active Directory, etc. Les capacités de mise en œuvre rapide de l’équipe sont importantes. Nous nous attendions à ce que le nouveau système réduise le temps de service de 25% des appels au centre d'appels de 5 secondes. Cela réduira également le temps de formation. Auparavant, 3% de tout le temps de travail y était consacré - et lorsqu'il s'agit de plus de 30 000 travailleurs, les dépenses sont considérables.
En outre, au cours du projet, VTB était au stade de la fusion de deux grandes banques dans sa structure, et les clients du futur système se trouvaient dans différents sous-réseaux, dans différents segments. Tout cela devait être combiné et fourni aux employés travaillant avec le système, l'accès de bout en bout, en tenant compte des rôles, des différents niveaux d'accès à l'information, etc. Il était nécessaire pour résoudre de nombreux problèmes d'infrastructure supplémentaires.
Nous mettons toutes les exigences et tous les critères nécessaires dans une seule table de notation. Nous avons examiné toutes les solutions clés existantes sur le marché, à la fois russes et étrangères, y avons téléchargé des parties de notre contenu et évalué ce qui fonctionne. Et à la fin, nous avons opté pour un système de gestion des connaissances unifié de KMS Lighthouse. Avec l'introduction, nous avons été aidés par l'équipe du groupe DIS, qui propose KMS Lighthouse sur le marché russe.
2500 articles dans 16 modèles pour 60 000 utilisateurs
Il existe deux entités clés dans notre nouveau système de gestion des connaissances - «modèle» et «article». Un article est une page formalisée contenant des informations. Le même article est différent pour tous les groupes de rôles d'utilisateurs (employés de banque). Les groupes sont constitués en fonction de l'affiliation organisationnelle, fonctionnelle ou commerciale des salariés.
Après avoir analysé le contenu que nous avons, nous avons réalisé que nous avions affaire à 2500 articles. Cette mer d'informations devait être décomposée en un nombre minimum de modèles. De plus, les articles auraient dû conserver la flexibilité décrite ci-dessus. Il y avait beaucoup de travail manuel sur la création de modèles, la coordination et la réconciliation. Mais au final, j'ai réussi à rencontrer 16 modèles - pour 2500 articles c'est un bon niveau de systématisation.
Travailler sur le contenu
16 modèles sont répartis dans trois groupes de gestionnaires de contenu. Le premier groupe est responsable du contenu associé au centre d'appels. Le second concerne les produits, services et informations connexes. Le troisième est le bloc de contenu de l'unité d'exploitation (DOPB), notre back office. De plus, nous avons une unité méthodologique qui opère au niveau de la banque. Presque toutes les informations de la banque passent par elle, comme par un filtre, et par conséquent, seules les informations qui devraient être placées dans la base de connaissances restent.
Nous avons discuté d'une division plus complexe. Pensé à présenter les «propriétaires» des groupes responsables du processus et du système. Nous avons discuté de la position du «rédacteur en chef», qui vérifiera tous les changements. Mais à la fin, nous avons décidé de nous concentrer sur trois groupes, car le contenu est assez clairement divisé entre eux.
KMS Lighthouse vous permet de construire rapidement plusieurs niveaux de coordination, mais nous avons décidé de ne pas compliquer ce système, et au niveau des gestionnaires de contenu nous avons fait deux niveaux - ceux qui écrivent et ceux qui publient. Au dernier niveau, ceux qui sont responsables de tout le contenu de leur groupe se distinguent. Il est vrai que la question se posait ici de fabriquer des documents sur les ventes réussies à la division alimentaire, mais jusqu'à présent, ils ont décidé de tout laisser tel quel.
Ainsi, la base de connaissances peut être développée sans délai. Supposons qu'un service alimentaire souhaite publier immédiatement des informations sur un nouveau produit. Envoie une demande par mail au gestionnaire de contenu: "Chers collègues, nous devons publier cet article ici." Après la publication via des mécanismes de rétroaction, le raffinement est en cours: quelque part, les informations peuvent ne pas suffire, quelque part quelque chose n'est pas conforme au modèle. Et ainsi de suite jusqu'à ce que l'unité et le gestionnaire de contenu soient satisfaits. Maintenant, nous venons d'introduire les éléments nécessaires à cette interaction: notifications, enquêtes, formulaires d'approbation. Si l'article en cours de création couvre les domaines de différents groupes de gestionnaires de contenu, alors chacun devient responsable de son propre onglet.
Un serveur d'applications distinct est alloué aux gestionnaires de contenu, où vous pouvez modifier des articles ou en créer de nouveaux à l'aide de modèles existants. Ici, vous pouvez afficher les statistiques nécessaires sur les requêtes de recherche, la pertinence des réponses, les conversions, etc. Les articles peuvent non seulement être modifiés, mais également optimisés - par exemple, créez des balises META pour améliorer la recherche. De plus, la recherche peut être améliorée en ajoutant de force certains articles à certaines requêtes. C'est ce qu'on appelle le «choix de l'éditeur»; lors de la recherche, l'utilisateur voit ces documents dans une colonne distincte.
Recherche de base
Dans SharePoint, les utilisateurs sont habitués à l'arborescence de présentation des informations et d'interaction avec les onglets. KMS Lighthouse implique l'utilisation d'une recherche complète. Lorsque 60 000 utilisateurs travaillent avec le système (une moyenne d'environ 1600 à la fois), il convient de penser à l'équilibrage de charge. Désormais, KMS Lighthouse fonctionne sur 10 serveurs. Chacun a déployé deux machines virtuelles. Un tas de 20 machines virtuelles fonctionnent. Entre eux se trouve un équilibreur bancaire.
La recherche est basée sur trois moteurs de recherche qui indexent tout le contenu. Les index de recherche sont construits en tenant compte des requêtes entrantes, de leur fréquence. La pertinence des réponses et leur position dans les résultats de sortie en dépendent. Lighthouse analyse les demandes et peut les présenter sous la forme de 16 rapports différents, à l'aide desquels les gestionnaires de contenu travaillent à remplir le système.
Fonctionnalités supplémentaires
Tous les employés travaillant avec le système sont divisés en environ 35 groupes de rôles. Chacun a accès à certaines parties des articles. Un utilisateur peut être dans plusieurs groupes - puis il voit le contenu de tous ces groupes à la fois.
Les groupes sont intégrés aux passerelles e-mail et SMS. Lorsqu'il travaille avec un client d'une banque, un employé peut lui envoyer rapidement les informations nécessaires, par exemple lors d'une consultation téléphonique. Si, bien sûr, des informations peuvent être envoyées; les articles sur la divulgation (et l'admissibilité à l'impression) indiquent des attributs individuels. Pas besoin de réécrire et de copier-coller quoi que ce soit.
Yandex.Maps est également intégré à la base de connaissances, grâce à laquelle les employés voient à quel point certains services sont occupés. Les informations sont mises à jour toutes les demi-heures. Ainsi, après avoir déterminé dans quels services le client peut recevoir tel ou tel service, les employés peuvent indiquer où il est préférable de s'adresser afin de gagner du temps.
KMS Lighthouse est intégré à notre système frontal et peut être amené directement à son interface en tant que widget. Vous pouvez y faire une demande rapide et accéder directement à l'article - comme dans n'importe quel moteur de recherche.
C'est ainsi que notre nouvelle base de connaissances est organisée. Nous sommes en train de le finaliser et nous espérons que non seulement les employés mais aussi les clients VTB apprécieront l'effet positif de la mise en œuvre du phare KMS.
En conclusion, nous voulons partager notre joie. En janvier, notre Business Wikipedia a été annoncé le projet de l'année selon le Global CIO. Nous vous tiendrons informés et vous dirons quelles nouveautés nous y attachons et comment cela aide le travail.