Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ. Затем приходите в точку продаж, но полученная ранее информация оказывается неактуальной. Чтобы гарантированно избежать таких расхождений, мы решили уйти от существующего в банке решения, созданного на 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 оценят не только сотрудники, но и клиенты ВТБ.
