Поделиться
Как выбрать систему управления знаниями для банка: 7 советов и другие лайфхаки
Финансовый сектор сейчас переживает не самые простые времена: число банков сокращается, на рынке происходит глобальная консолидация. Многие банки проигрывают из-за несвоевременной адаптации к требованиям цифровизации бизнеса. Выигрывает тот, кто лучше работает с данными, и одним из необходимых инструментов для него становится система управления знаниями. Зачем она нужна и с какой стороны к ней подойти? Расскажем об этом на основе практического опыта.Пока банки решают проблемы перехода в мир «Индустрии 4.0», растут ожидания клиентов. Они становятся все более требовательными к качеству сервиса, хотят решать свои вопросы как можно оперативнее и по привычным каналам связи, без посещения банка. Типичный портрет современного розничного клиента – это человек, использующий смартфоны, гаджеты, активно общающийся в соцсетях и мессенджерах, привыкший получать любую необходимую информацию быстро, не выходя из дома.
Банки находятся в условиях жесткой борьбы за клиента, и эффективным инструментом в этой борьбе становятся технологические решения. Сокращение издержек, оптимизация бизнес-процессов, повышение эффективности клиентского сервиса – все это могут обеспечить современные цифровые инструменты. Особый класс таких решений представляют системы, позволяющие управлять данными, необходимыми в процессе обслуживания клиентов – системы управления знаниями, или СУЗ.
Четыре уровня управления знаниями
С точки зрения построения процессов управления знаниями можно выделить четыре категории банков.
Первая категория – банки, у которых этот процесс практически никак не выстроен. Есть системный диск с папками, где хранятся различные файлы. Для того чтобы найти необходимую информацию, сотруднику нужно знать, в какой именно папке находится файл или знать его точное название. Если для опытных сотрудников эта задача хоть и сложная, но выполнимая, то для новичков такой поиск крайне затруднителен и отнимает много времени. При использовании данного варианта хранения информации очень сложно уведомлять сотрудников об изменениях и обновлениях контента, а также контролировать, ознакомился ли сотрудник с информацией. В результате риск предоставления неактуальных данных и сведений для клиентов высокий, что может негативно сказываться на имидже банка, потере лояльности.
Вторая категория – банки, развивающие собственные корпоративные порталы на базе готовых платформ. Это распространенный вариант, он позволяет существенно сэкономить на разработке или покупке специализированного решения. Однако такие порталы обладают ограниченными возможностями развития, они часто не отвечают текущим трендам, и зачастую мы сталкиваемся с тем, что у подобных решений отсутствует открытый API. Он необходим для интеграции ПО с другими решениями, например, с CRM системами или чат-бот платформами, что крайне необходимо для качественного решения задач клиентского сервиса.
Третья категория – это крупные финансовые структуры, имеющие собственные R&D-подразделения и программные продукты. Именно эти игроки задают тренды на рынке, выступают локомотивом цифровых преобразований. Если финансовая организация не перенимает digital-модель развития, которую диктуют лидеры отрасли, то она становится убыточной и быстро закрывается.
Четвертая категория – банки, использующие готовые решения по управлению знаниями. На российском рынке представлены разные варианты таких систем, как от российских, так и от зарубежных производителей. Подобные системы создаются под реализацию определенных задач и поэтому имеют определенные особенности.
Есть решения, созданные в качестве вспомогательного инструмента для разработчиков, чтобы они могли в едином информационном пространстве ставить задачи, обсуждать проекты со всей командой. Подобное решение в большей степени предназначено для внутренних пользователей. Возможности управления знаниями в таких системах вторичны: скорость поиска информации и быстрое отслеживание всех изменений для разработчиков не настолько критичный параметр, как, например, для контактных центров, где именно скорость и качество ответа влияют на стоимость операторского ресурса.
Как показывает опыт, самыми эффективными и полезными являются системы управления знаниями, в основу которых положен практический опыт обеспечения эффективности клиентского сервиса и потребности реальных пользователей. Важно, чтобы функциональное тестирование всегда проводилось на конечных пользователях, и полученная обратная связь помогала оптимизировать продукт под реальные потребности бизнес-заказчиков. В частности, некоторые крупные российские аутсорсинговые контактные центры разрабатывают собственные СУЗ.
Что касается решений от зарубежных разработчиков, то далеко не все российские компании готовы работать с импортным программным обеспечением, поскольку непонятны его дальнейшие перспективы на рынке РФ с учетом курса на импортозамещение. Кроме того, зачастую при работе с иностранным ПО некоторые банки сталкиваются со сложностями в части кастомизации решений под специфику российских процессов. Поэтому банки с большим интересом смотрят в сторону отечественных разработок.
Зачем банку система управления знаниями
Основные проблемы, связанные с управлением знаниями, таковы. Информация хранится разрозненно и ее много. Информация сама по себе очень хаотична, нет единого формата. Информация в базе знаний не всегда актуальна. Нет удобных инструментов для быстрого и качественного поиска в базе. Нет функциональных инструментов контроля работы пользователей. Отсутствует детализированная статистика и отчетность по действиям пользователей. Отсутствует взаимосвязь между различными ИС (BI, CRM и другими).
У большинства банков есть проблемы, связанные с управлением знаниями. Вот, например, с чем мы столкнулись при работе для одного банка. В существующем решении не была реализована ролевая модель, а значит нельзя дать доступы разным группам пользователей к разным разделам одной и той же статьи. Контент-менеджеры банка вынуждены создавать 7 разных статей с описанием определенного типа тарифа для каждого из макрорегиональных филиалов, при этом 90% информации в статье одинаковы для каждого из регионов.
В современных решениях можно создать одну статью вместо семи, при этом к общей информации будут иметь доступ все регионы, а к индивидуальной – только отдельные, в соответствии с распределенными ролями. Это значительно облегчает работу контент-менеджера и экономит трудозатраты. Очень многие финансовые организации (и не только они) понимают определение «хранилище информации» слишком буквально. В результате хранилище есть, но найти нужную информацию в невозможно.
Поскольку каждый контактный центр использует несколько информационных систем для работы с клиентами, важно, чтобы все решения можно было интегрировать в одно целое, нужен единый источник информации для всех элементов общей экосистемы. В противном случае будет «рассинхронизация»: клиенты получат недостоверную информацию, время обработки обращений вырастет, расходы увеличатся.
Что требуют банки от поставщиков ИТ
Требования банков к ИТ-системам индивидуальны, но есть несколько общих пунктов, которые следует учитывать при работе с любым заказчиком из финансовой сферы. В первую очередь, это высокие требования по безопасности, поэтому такие решения, как СУЗ, устанавливают в защищенный информационный контур банка.
Бывают ситуациями, когда заказчик отказывается давать VPN-доступ для установки системы управления знаниями, объясняя это строгими требованиями к защите данных. Тогда приходится проводить установку с внешнего носителя под присмотром нескольких сотрудников службы безопасности. С одной стороны, это вызывает некоторые неудобства. С другой, это вполне предсказуемое поведение заказчика.
Во-вторых, для банков крайне важны отказоустойчивость и масштабируемость решения, при этом ИТ-ландшафт таких заказчиков всегда индивидуален и зачастую очень непростой, поэтому при выборе решения банки оценивают технические возможности потенциальных поставщиков.
Портфолио – это следующее, на что обращает внимание заказчик. Банки интересует релевантный опыт работы с компаниями из финансовой сферы, поскольку клиент хочет не только купить программное обеспечение, но и получить качественную консультацию от профессионалов относительно грамотного структурирования контента, его переноса в новое пространство и т.д. Как показывает опыт, если контент размещен в СУЗ некорректно, то искать информацию неудобно, процесс поиска занимает много времени – система становится бесполезной.
Еще одно частое требование – готовность к кастомизации. Заказчику принципиально важно, чтобы новая система обладала открытым API для встраивания в ИТ-контур организации и внесения нужных изменений с учетом требований заказчика (например, дополнительный функционал или новый интерфейс).
Нужен ли единый инструмент для клиентского сервиса?
Практически ни один заказчик уже не рассматривает ИТ-решения как самостоятельное ПО. Банки используют в своей работе огромное количество самых разных систем, поэтому ключевое требование – не просто встраивание в ИТ-контур, а интеграция с остальными решениями, которые использует заказчик. В том числе с интеллектуальными платформами, чат-ботами и т.д. Если такой возможности нет, то система заказчику не интересна, она становится невостребованной на рынке. Те же чат-боты должны точно знать, какую информацию они могут предоставлять, поэтому в СУЗ должна быть возможность разметки контента для бота.
Интеграция всех банковских систем в единое окно, с которым работает сотрудник контактного центра, стала трендом, определяющим направление развития для всех элементов программно-аппаратного комплекса в компаниях. Большинство банков уже пришли к «единому окну», либо на пути к нему.
Насколько финансовые организации заинтересованы в новых технологиях?
Все банки заинтересованы в новых digital-решениях и технологиях. Не осталось ни одного банка, который бы сказал, что ему это не нужно и он хочет работать по старинке. Все упирается только в финансовые возможности.
Обычно за внедрение решений вроде системы управления знаниями отвечают два департамента: клиентского сервиса и ИТ. При покупке того или иного программного продукта оба департамента должны понимать, для каких задач оно приобретается и в чем будет заключаться экономический эффект от его внедрения. Это либо дополнительный доход, либо сокращение расходов, либо работа на имидж и создание WOW-эффекта.
Самый эффективный для подрядчика способ представить свою систему – дать заказчику возможность протестировать ее в течение определенного периода. Обычно трех месяцев хватает, чтобы получить первые измеримые результаты и принять взвешенное решение о покупке.
Что финансовым организациям нужно от СУЗ?
Прежде всего, они ждут, что снизится время обработки обращения, что контент в базе будет понятно изложен, актуален, ну и, конечно же, что в системе будет реализован удобный поиск информации. В конечном счете, заказчику нужно оптимизировать работу сотрудников контактного центра, в частности, контент-менеджеров. Все эти параметры напрямую влияют на деятельность банка в целом. Разрозненный и неактуальный контент не только увеличивает время поиска, но и снижает вероятность предоставления качественной консультации. Для банков это критично, потому что это влечет за собой финансовые ошибки и риски. Важно, чтобы база могла фиксировать все изменения в контенте и действия конкретных пользователей, тогда в случае сбоя или ошибки всегда можно найти причины неполадок.
7 рекомендаций банку по выбору системы управления знаниями
Интеграция
Если ваша клиентская служба использует несколько систем, обязательно узнайте про возможности интеграции с ними системы управления знаниями, поскольку СУЗ вполне может стать информационным ядром для других программ, в том числе для чат-бота.
Реестр отечественного ПО
Если банк следует политике импортозамещения, то вопрос происхождения ПО он должен уточнить еще «на берегу». Заказчик также должен четко представлять себе, как будет развиваться продукт, не возникнет ли проблем с поддержкой системы, доработкой функционала.
Кастомизация
В процессе эксплуатации у заказчика всегда появляются новые требования и пожелания к функционалу. Поэтому важно, чтобы разработчик был готов к кастомизации решения в кратчайшие сроки. Нас часто спрашивают, как часто мы выпускаем новые релизы, есть ли у нас собственный штат разработчиков, готовых к доработкам системы. При выборе поставщика заказчик должен сразу оценить, насколько быстро тот сможет реализовать возникающие запросы.
Релевантный опыт
Обязательно поинтересуйтесь уже реализованными проектами, запросите референс-встречу с клиентами разработчика, чтобы получить информацию из первых рук, посмотреть на решение в действии.
Функциональность
При выборе системы управления знаниями нужно выяснить, насколько она отвечает текущим трендам на рынке и насколько при разработке решения вендор опирался на мнение конечных пользователей и учитывал их потребности. Важен не только существующий функционал, но и план дальнейшего развития системы. Разработчик должен знать рынок, его запросы, чтобы решение было актуальным и конкурентным. У любой уважающей себя компании есть road-map развития продукта. С этой картой необходимо ознакомиться и выяснить заранее, насколько она соответствует вашим интересам.
Информационная безопасность
Поскольку большинство банков устанавливают системы в свой информационный контур, все решения должны отвечать самым высоким требованиям безопасности. Выясните у вашего партнера, какие тесты по безопасности проводились, какие соответствующие сертификаты были получены на ПО.
Отказоустойчивость
Количество пользователей системы управления знаниями может быть очень большим, вплоть до нескольких тысяч человек. Поэтому важно перед началом эксплуатации продукта провести нагрузочные тестирования для проверки отказоустойчивости.
Короткая ссылка
