Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ. Затем приходите в точку продаж, но полученная ранее информация оказывается неактуальной. Чтобы гарантированно избежать таких расхождений, мы решили уйти от существующего в банке решения, созданного на SharePoint, переработали весь контент, определили источники и потребителей данных и переупаковали всю необходимую информацию в новую систему управления знаниями — единую для всех подразделений. В этом посте мы поделимся своим опытом.
Для начала всю информацию, которая касается обслуживания клиентов, наших продуктов и услуг, нужно было унифицировать. Исторически так сложилось, что знания хранились в трех крупных базах знаний, созданных в разное время, по сути, в разных банках. При этом одним из ключевых требований была возможность предоставлять разные объемы данных — например, для точек продаж и для ДКО (колл-центра). В первом случае важна развернутая информация: когда люди приходят в офлайн-отделения, они ожидают услышать все подробности по интересующим вопросам. Во втором случае, наоборот, достаточно краткой информации — главное, чтобы она предоставлялась быстро и четко.
Задача усложнялась тем, что у нас было целых шесть внутренних заказчиков. И, соответственно, разные типы требований. У всех были разные критерии относительно функциональности, производительности и поддержки. Например, наличие SSO, интеграция с Active Directory и т.п. Важны были способности команды по быстрому внедрению. Мы рассчитывали, что новая система на 5 секунд сократит время обслуживания у 25% звонков в колл-центр. А также уменьшит время обучения. Раньше на это тратилось 3% всего рабочего времени — и когда речь идет о более чем 30 000 работников, расходы выходят немалые.
Кроме того, во время проекта ВТБ находился на этапе слияния двух больших банков в своей структуре, и клиенты будущей системы находились в разных подсетях, в разных сегментах. Все это нужно было объединить и обеспечить сотрудникам, работающим с системой, сквозной доступ, с учетом ролей, различных уровней доступа к информации и т.д. Здесь требовалось решить много дополнительных инфраструктурных вопросов.
Все необходимые требования и критерии мы сложили в одну скоринговую таблицу. Посмотрели все ключевые существующие на рынке решения, как российские, так и зарубежные, загрузили в них части нашего контента, оценили, что получается. И в итоге остановились на единой системе управления знаниями от компании KMS Lighthouse. С внедрением нам помогала команда DIS Group, которая предлагает KMS Lighthouse на российском рынке.
В нашей новой системе управления знаниями есть две ключевые сущности — «шаблон» и «статья». Статья — это формализованная по шаблону страница с информацией. Одна и та же статья выглядит по-разному для всех ролевых групп пользователей (сотрудников банка). Группы формируются в зависимости от организационной, функциональной или бизнес-принадлежности сотрудников.
После анализа имеющегося у нас контента мы поняли, что имеем дело с 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. Будем держать вас в курсе и рассказывать, что новое к ней прикручиваем и как она помогает работе.
Постановка задачи и выбор решения
Для начала всю информацию, которая касается обслуживания клиентов, наших продуктов и услуг, нужно было унифицировать. Исторически так сложилось, что знания хранились в трех крупных базах знаний, созданных в разное время, по сути, в разных банках. При этом одним из ключевых требований была возможность предоставлять разные объемы данных — например, для точек продаж и для ДКО (колл-центра). В первом случае важна развернутая информация: когда люди приходят в офлайн-отделения, они ожидают услышать все подробности по интересующим вопросам. Во втором случае, наоборот, достаточно краткой информации — главное, чтобы она предоставлялась быстро и четко.
Задача усложнялась тем, что у нас было целых шесть внутренних заказчиков. И, соответственно, разные типы требований. У всех были разные критерии относительно функциональности, производительности и поддержки. Например, наличие 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. Будем держать вас в курсе и рассказывать, что новое к ней прикручиваем и как она помогает работе.
Комментарии (12)
cyber_roach
21.02.2019 11:47+1Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ.
Действительно, хотелось бы, чтобы я звонил в колл-центр банка и получал ОДИН ответ, а не отфутболивание от одного «специалиста» к другому по кругу, где у каждого свое мнение насчет моего вопроса.
Никогда не понимал, что вообще мешает реализовать конференцию разговора с несколькими специалистами одновременно, дабы я не повторял информацию сказанную минуту назад еще раз? Это же супер-удобно, когда ты просто слушаешь, как к проблеме подключаются новые люди, обсуждают твою проблему и РЕШАЮТ! её сообща. А ты, слушая их диалог, дополняешь информацией по необходимости. Удобно — да. И что важно — по человечески, а не превращая call-центр в роботов, где все друг друга ненавидят.
А, да, и при обрыве связи, хочу чтобы меня возвращало к тому, с кем я только что говорил (например код специалиста в смс приходил, чтобы напрямую звонить, актуально не только для обрыва связи, а при необходимости донесения данных например, либо повторении проблемы), а не заставляло проходить всю цепочку «девочек» до нужного спеца, заново объясняя подробности.
dedyshka
21.02.2019 12:30Статья откровенно слабая.
Если описывалось внедрение, то как-то «по верхам» и перескакивая с одного на другое без подробностей. А если это попытка описать систему KMS Lighthouse, то тоже ни о чём.
Пример:Поиск по базе
далее ожидается сравнение одного с другим, плюсы/минусы, но нет… следующее предложение уже про распределение нагрузки.
В SharePoint люди привыкли к древовидной структуре представления информации и взаимодействию с вкладками. KMS Lighthouse предполагает использование полноценного поиска.
От статьи ощущение, что вы договорились с DIS Group, они вам условия внедрения, а вы им немножко рекламы Lighthouse (через всю статью нитью протянуто — «SharePoint плохо, Lighthouse хорошо» ). Может быть это и не так, может вы хотели совсем другого эффекта, но тот кто писал статью откровенно налажал.
У вас есть опыт внедрения системы управления знаниями и опыт выбора/сравнения таких систем. Статья про первое или про второе была бы значительно интереснее.elenissimo
21.02.2019 13:51+1Специально старались не вдаваться в технические вопросы и в описание решенных в рамках проекта проблем по выстраиванию процессов и настройке решения/поисковой машины.
Если есть конкретные вопросы – готовы прокомментировать.dedyshka
21.02.2019 14:01Специально старались не вдаваться в технические вопросы и в описание решенных в рамках проекта проблем
а зачем тогда статья на Хабре??elenissimo
21.02.2019 14:35Задавайте ваши вопросы. Мы будем рады на них ответить и постараемся подготовить более подробный материал :)
VMichael
21.02.2019 12:50Когда с системой работает 60 тысяч пользователей (в среднем около 1600 одновременно), стоит задуматься о распределении нагрузки. Сейчас KMS Lighthouse работает на 10 серверах. На каждом развернуто две виртуальные машины. В связке работают 20 виртуальных машин. Между ними стоит банковский балансировщик.
2500 статей смотрят (понятно, что делают поисковые запросы) одновременно 1600 пользователей (плюс минус).
Вопрос возник: 10 серверов не многовато ли на такие нагрузки (считаем что серверы это некие усредненные серверы, допустим, современные, вряд ли там старый медленных хлам зарядили)?elenissimo
21.02.2019 13:50+110 серверов – это виртуальные ресурсы. Ими управляет балансировщик нагрузки. Для оптимизации/распределения нагрузки эффективней иметь набор серверов, чем один с такими же характеристиками.
Инфраструктуру рассчитывали сразу под целевую нагрузку. Мы еще не вышли на реальные объемы пользовательской нагрузки.
nerazzgadannaya
21.02.2019 16:55+1А нет ли желания рассказать про этот кейс на конференции по управлению знаниями в IT KnowledgeConf? Вот тут подробнее про нас, оргвопросы и про аудиторию можно писать мне в личку knowledgeconf.ru/2019
vlsinitsyn
21.02.2019 20:06Мда, читаешь и радуешься за ВТБ. Особенно порадовало вот это «допустим, продуктовое подразделение хочет немедленно разместить информацию о новом продукте. Присылает по почте запрос контент-менеджеру: «коллеги, нам нужно разместить вот эту статью»».
Надо видимо завершить кейс, «а контент менеджер по почте и отвечает...». Завязалась неспешная переписка между менеджерами в уютном банковском офисе…
al_sh
Лучше бы ВТБ себе нормальное мобильное приложение сделал. Существующее, скорее напоминает поделку 1 курсника, а не приложение банка из ТОП 10.
iPrime
Точно! Считывание QR то когда нормальный будет?
al_sh
да ладно QR, а загрузка по 5мин. с перекидованием между экраном с отпечатком, ПИН кодом и зимним лесом. Информация по картам появляется с такой дельтой, что складывается ощущение, что они его всем банком на арифмометрах считают. При этом и сбер и мкб банки летают на моем SGS8.