Как ВТБ к единому знанию приходил

    Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ. Затем приходите в точку продаж, но полученная ранее информация оказывается неактуальной. Чтобы гарантированно избежать таких расхождений, мы решили уйти от существующего в банке решения, созданного на SharePoint, переработали весь контент, определили источники и потребителей данных и переупаковали всю необходимую информацию в новую систему управления знаниями — единую для всех подразделений. В этом посте мы поделимся своим опытом.



    Постановка задачи и выбор решения


    Для начала всю информацию, которая касается обслуживания клиентов, наших продуктов и услуг, нужно было унифицировать. Исторически так сложилось, что знания хранились в трех крупных базах знаний, созданных в разное время, по сути, в разных банках. При этом одним из ключевых требований была возможность предоставлять разные объемы данных — например, для точек продаж и для ДКО (колл-центра). В первом случае важна развернутая информация: когда люди приходят в офлайн-отделения, они ожидают услышать все подробности по интересующим вопросам. Во втором случае, наоборот, достаточно краткой информации — главное, чтобы она предоставлялась быстро и четко.

    Задача усложнялась тем, что у нас было целых шесть внутренних заказчиков. И, соответственно, разные типы требований. У всех были разные критерии относительно функциональности, производительности и поддержки. Например, наличие SSO, интеграция с Active Directory и т.п. Важны были способности команды по быстрому внедрению. Мы рассчитывали, что новая система на 5 секунд сократит время обслуживания у 25% звонков в колл-центр. А также уменьшит время обучения. Раньше на это тратилось 3% всего рабочего времени — и когда речь идет о более чем 30 000 работников, расходы выходят немалые.

    Кроме того, во время проекта ВТБ находился на этапе слияния двух больших банков в своей структуре, и клиенты будущей системы находились в разных подсетях, в разных сегментах. Все это нужно было объединить и обеспечить сотрудникам, работающим с системой, сквозной доступ, с учетом ролей, различных уровней доступа к информации и т.д. Здесь требовалось решить много дополнительных инфраструктурных вопросов.

    Все необходимые требования и критерии мы сложили в одну скоринговую таблицу. Посмотрели все ключевые существующие на рынке решения, как российские, так и зарубежные, загрузили в них части нашего контента, оценили, что получается. И в итоге остановились на единой системе управления знаниями от компании KMS Lighthouse. С внедрением нам помогала команда DIS Group, которая предлагает KMS Lighthouse на российском рынке.

    2500 статей в 16 шаблонах для 60 тысяч пользователей


    В нашей новой системе управления знаниями есть две ключевые сущности — «шаблон» и «статья». Статья — это формализованная по шаблону страница с информацией. Одна и та же статья выглядит по-разному для всех ролевых групп пользователей (сотрудников банка). Группы формируются в зависимости от организационной, функциональной или бизнес-принадлежности сотрудников.



    После анализа имеющегося у нас контента мы поняли, что имеем дело с 2500 статьями. Это море информации нужно было разложить в минимально допустимое число шаблонов. Причем статьи должны были сохранить описанную выше гибкость. Было много ручной работы по созданию шаблонов, согласованию и пересогласованию. Но в итоге удалось уложиться в 16 шаблонов — для 2500 статей это неплохой уровень систематизации.

    Работа над контентом


    16 шаблонов распределены по трем группам контент-менеджеров. Первая группа отвечает за контент, связанный с колл-центром. Вторая — за продукты, услуги и связанную информацию. Третья — это контентщики операционного блока (ДОПБ), нашего бэк-офиса. Помимо этого, у нас есть методологическое подразделение, которое работает на уровне банка. Через него, как через фильтр, проходит практически вся информация банка, и в итоге остается только та, которую стоит размещать в базе знаний.

    Мы обсуждали более сложное деление. Думали вводить «владельцев» групп, отвечающих за процесс и систему. Обсуждали позицию «главного редактора», который будет верифицировать все изменения. Но в итоге решили остановиться на трех группах, поскольку контент достаточно четко делится между ними.

    KMS Lighthouse позволяет быстро выстроить несколько уровней согласования, но мы решили не усложнять эту систему, и на уровне контент-менеджеров сделали два уровня — те, кто пишет, и те, кто публикует. На последнем уровне выделяются те, кто ответственен за весь контент в своей группе. Правда, здесь возник вопрос о том, чтобы вынести материалы по успешным продажам продуктовому подразделению, но пока решили оставить все как есть.

    Таким образом развивать базу знаний можно без проволочек. Допустим, продуктовое подразделение хочет немедленно разместить информацию о новом продукте. Присылает по почте запрос контент-менеджеру: «коллеги, нам нужно разместить вот эту статью». После размещения через механизмы обратной связи идет доработка: где-то может не хватать информации, где-то что-то не по шаблону. И так пока подразделение и контент-менеджер не будут довольны. Сейчас мы как раз внедряем необходимые для этого взаимодействия элементы: уведомления, опросы, формы утверждения. Если создаваемая статья охватывает сферы разных групп контент-менеджеров, то каждый становится ответственным за свою вкладку.

    Для контент-менеджеров выделен отдельный прикладной сервер, где можно редактировать статьи или создавать новые по имеющимся шаблонам. Сюда же можно подтянуть необходимую статистику по поисковым запросам, релевантности ответов, переходам и т.д. Статьи можно не только изменять, но и оптимизировать — например, создавать метатеги для улучшения поиска. Кроме того, поиск можно улучшать, принудительно добавляя к определенным запросам определенные статьи. Это называется «выбор редактора», при поиске пользователь видит такие материалы в отдельной колонке.

    Поиск по базе


    В SharePoint люди привыкли к древовидной структуре представления информации и взаимодействию с вкладками. KMS Lighthouse предполагает использование полноценного поиска. Когда с системой работает 60 тысяч пользователей (в среднем около 1600 одновременно), стоит задуматься о распределении нагрузки. Сейчас KMS Lighthouse работает на 10 серверах. На каждом развернуто две виртуальные машины. В связке работают 20 виртуальных машин. Между ними стоит банковский балансировщик.



    Поиск основан на трех поисковых машинах, которые индексируют весь контент. Поисковые индексы выстраиваются с учетом приходящих запросов, их частоты. От этого зависит релевантность ответов, их позиция в выдаваемых результатах. Lighthouse анализирует запросы и может представить их в виде 16 разных отчетов, с помощью которых над наполнением системы работают контент-менеджеры.

    Дополнительные возможности


    Все сотрудники, работающие с системой, разделены примерно на 35 ролевых групп. Каждая имеет доступ к определенным частям статей. Пользователь может состоять в нескольких группах — тогда он видит контент для всех этих групп сразу.

    Группы интегрированы с email- и SMS-шлюзами. Работая с клиентом банка, сотрудник может быстро отправить ему нужную информацию — например, прямо во время телефонной консультации. Если, конечно, информацию отправлять можно; в статьях по поводу разглашения (и допустимости печати) указываются отдельные атрибуты. Не нужно ничего переписывать и копипастить.



    В базу знаний также интегрированы «Яндекс.Карты», через которые сотрудники видят, насколько загружены те или иные отделения. Информация обновляется раз в полчаса. Так что, определив, в каких отделениях клиент может получить ту или иную услугу, сотрудники могут посоветовать, куда конкретно лучше обратиться, чтобы сэкономить время.

    KMS Lighthouse интегрирована с нашей фронтальной системой и может быть вынесена прямо в ее интерфейс в виде виджета. В нем можно сделать быстрый запрос и сразу перейти к статье — как в любой поисковой системе.

    Вот так организована наша новая база знаний. Сейчас мы ведем финальные доработки и рассчитываем, что положительный эффект от внедрения KMS Lighthouse оценят не только сотрудники, но и клиенты ВТБ.



    В заключение хотим поделиться радостью. В январе наша «Бизнес-Википедия» была объявлена проектом года по версии издания Global CIO. Будем держать вас в курсе и рассказывать, что новое к ней прикручиваем и как она помогает работе.
    ВТБ
    75,26
    Компания
    Поделиться публикацией

    Комментарии 14

      +2
      Лучше бы ВТБ себе нормальное мобильное приложение сделал. Существующее, скорее напоминает поделку 1 курсника, а не приложение банка из ТОП 10.
        0
        Точно! Считывание QR то когда нормальный будет?
          +1
          да ладно QR, а загрузка по 5мин. с перекидованием между экраном с отпечатком, ПИН кодом и зимним лесом. Информация по картам появляется с такой дельтой, что складывается ощущение, что они его всем банком на арифмометрах считают. При этом и сбер и мкб банки летают на моем SGS8.
            0

            Скажите спасибо тем кому не нравилось экс-бм-ское, был шанс но судя по всему при исследовании домохозяйки со свисто… победили.

        +3
        Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ.

        Действительно, хотелось бы, чтобы я звонил в колл-центр банка и получал ОДИН ответ, а не отфутболивание от одного «специалиста» к другому по кругу, где у каждого свое мнение насчет моего вопроса.
        Никогда не понимал, что вообще мешает реализовать конференцию разговора с несколькими специалистами одновременно, дабы я не повторял информацию сказанную минуту назад еще раз? Это же супер-удобно, когда ты просто слушаешь, как к проблеме подключаются новые люди, обсуждают твою проблему и РЕШАЮТ! её сообща. А ты, слушая их диалог, дополняешь информацией по необходимости. Удобно — да. И что важно — по человечески, а не превращая call-центр в роботов, где все друг друга ненавидят.
        А, да, и при обрыве связи, хочу чтобы меня возвращало к тому, с кем я только что говорил (например код специалиста в смс приходил, чтобы напрямую звонить, актуально не только для обрыва связи, а при необходимости донесения данных например, либо повторении проблемы), а не заставляло проходить всю цепочку «девочек» до нужного спеца, заново объясняя подробности.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Специально старались не вдаваться в технические вопросы и в описание решенных в рамках проекта проблем по выстраиванию процессов и настройке решения/поисковой машины.
            Если есть конкретные вопросы – готовы прокомментировать.
            • НЛО прилетело и опубликовало эту надпись здесь
                –1
                Задавайте ваши вопросы. Мы будем рады на них ответить и постараемся подготовить более подробный материал :)
            +1
            Когда с системой работает 60 тысяч пользователей (в среднем около 1600 одновременно), стоит задуматься о распределении нагрузки. Сейчас KMS Lighthouse работает на 10 серверах. На каждом развернуто две виртуальные машины. В связке работают 20 виртуальных машин. Между ними стоит банковский балансировщик.

            2500 статей смотрят (понятно, что делают поисковые запросы) одновременно 1600 пользователей (плюс минус).
            Вопрос возник: 10 серверов не многовато ли на такие нагрузки (считаем что серверы это некие усредненные серверы, допустим, современные, вряд ли там старый медленных хлам зарядили)?
              +2
              10 серверов – это виртуальные ресурсы. Ими управляет балансировщик нагрузки. Для оптимизации/распределения нагрузки эффективней иметь набор серверов, чем один с такими же характеристиками.
              Инфраструктуру рассчитывали сразу под целевую нагрузку. Мы еще не вышли на реальные объемы пользовательской нагрузки.
              0
              А нет ли желания рассказать про этот кейс на конференции по управлению знаниями в IT KnowledgeConf? Вот тут подробнее про нас, оргвопросы и про аудиторию можно писать мне в личку knowledgeconf.ru/2019
                0
                Мда, читаешь и радуешься за ВТБ. Особенно порадовало вот это «допустим, продуктовое подразделение хочет немедленно разместить информацию о новом продукте. Присылает по почте запрос контент-менеджеру: «коллеги, нам нужно разместить вот эту статью»».
                Надо видимо завершить кейс, «а контент менеджер по почте и отвечает...». Завязалась неспешная переписка между менеджерами в уютном банковском офисе…
                  0
                  Кейс миграции с Sharepoint на KMS — достаточно распространенная практика для контакт-центров. Для общего развития сможете помочь понять: Какие условия были для выбора именно LightHouse, а не eGain к примеру? Было бы здорово понять вашу таблицу сравнения? Сможете также пояснить — KMS реализована для колл-центра или для общего среза омниканального обслуживания?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое