Как создавали большую энциклопедию для сотрудника

Банковскими услугами в России активно пользуется более 50% населения. Вне зависимости от возраста, специальности и размера бюджета, клиенту важно получать полную и достоверную информацию о состоянии счетов и быстрые ответы на свои вопросы. Для этого банки оптимизируют телефонию, разрабатывают скрипты разговора, создают роботов для ответов на типовые запросы. Помимо технологии, внедряются прогрессивные методики обучения, проходит регулярное тестирование знаний сотрудников и оценка качества обслуживания, но все держать в голове невозможно. Особенно, если в продуктовой линейке банка десятки различных продуктов, проходят акции и действуют специальные предложения для клиентов.

Под катом сегодня рассказываем о нашей википедии – умном справочнике, где есть вся информация обо всех продуктах и услугах банка.



В отделениях банка сегодня вас встречают молодые и энергичные сотрудники, средний возраст которых 25 лет. Они проявляют эмпатию, стремятся к профессиональному росту и ценят технологичность процессов. Ключевая компетенция – умение быстро находить ответ на любой вопрос клиента. Конечно, если сотрудник не может в полном объеме проконсультировать клиента, то он подключит старшего смены или переадресуют звонок в другую службу. Но какому клиенту понравится ожидать очередное соединение?

В случае телефонной консультации, время ожидания – ключевой SLA. Поэтому мы взялись создать единую базу знания с умной навигацией.

Всё и сразу

Подобные справочники, конечно, использовались и ранее. Но команды разрабатывали их в разное время для своего проекта и по своему разумению. Как следствие – техническая негибкость, сложности интеграции и поддержки.

Например, для одного из ранее созданных решений был реализован функционал, который позволял сохранять только видеоролики и презентации в формате pdf. Информация размещалась на временном сервере и была доступна ограниченное время, серверного места, конечного же, было мало, отсутствовали возможности для таргетированного размещения контента с учетом структуры подразделения, должностей и географии: все видели всё.

Компонентные команды

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

Подход к работе в компонентной команде ничем не отличается от бизнес-разработки: дизайн-мышление — обязательный этап для всех инициатив. Участники определили ключевых потребителей, разбив на группы, провели интервью. По итогам анализа данных, в Invision создали прототип и провели его тестирование на пользователях.



В основе решения 2 тезиса:

• данные должны быть представлены в виде статей, а не файлов в каталоге, с расширенными возможностями когнитивного поиска;
• адаптивность функционала к мобильной платформе.

В ходе сессии генерации идей участниками были предложены фичи, которые впоследствии были нарезаны в спринты команде:

• голосовой поиск;
• автоматический поиск решения на основе анализа голосового запроса клиента;
• внутренняя система оценок и рейтингования;
• внедрение тренажера эмоциональной разгрузки;
• добавление кросс-ссылки «с этим часто смотрят».

Разработка ведется итерационно, сейчас используется версия с ограниченным функционалом.

Временное решение

На старте разработки не было доступного wiki-движка, который бы смог обеспечить поддержку большого объема пользователей и был бы легко встраиваемым в существующий технический контур банка.

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

В ходе работы, команда проанализировала существующие wiki-движки: Сonfluene, IBM connections, Mediawiki, Xwiki. Для системы хранения контента и знаний смотрели: wikipedia, imdb, web базы знаний на сайтах Apple, Samsung, Tesla и др. Бесплатные wiki-движки, такие как mediawiki позволяют реализовать решение максимально быстро, но обладают ограничениями по интеграции и масштабируемости.

Следующие шаги

Сейчас разработка ведется в двух направлениях: одна команда занимается интеграциями с существующими сервисами, вторая трудится над Presentation Layer (PL) всех приложений, лидирует вопросы развития ИТ и архитектуры сервиса и оказывает техническую поддержку смежной разработки.

В качестве целевого решения на бэке решили использовать Atlassian Confluence. Это позволит на порядок увеличить надежность, масштабируемость решения, учитывая будущее количество пользователей – более 300 000, а также существенно нарастить функциональность за счет дополнительных плагинов, которые возможно докупить или создать самим. Порадовал контент-редактор — один из самых продвинутых в плане функциональности, при этом имеет понятный и простой интерфейс. Широкий набор сервисов и API, которые предоставляет система, упрощает интеграцию с ней.

Работа продолжается, в будущих публикациях расскажем о внедрении целевого решения и практике исправления багов.

А вы сталкивались с задачей создания подобного сервиса?

Наиболее популярные языки программирования, используемые разработчиками движков, — PHP, Java, Perl, С# и Python. В нашем стеке Java – основа, поэтому предлагаем пообщаться в комментариях и выбрать лучший wiki-движок, написанный на Java.