Пора ли менять используемую сейчас систему банк-клиент?

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

Начнем с простого разделения систем на "толстого" (стационарного) и "тонкого" (на базе интернет-браузера) клиента. И хотя это разделение весьма грубое мы будем понимать под "толстым" клиентом версию, системы которую необходимо устанавливать на компьютеры клиентов – юридических лиц банка, а под "тонким" мы будем иметь ввиду легкое решение на основе браузера, которое работает на сайте банка и там же работают все клиенты. Как известно, развитие систем шло от толстого клиента к тонкому. Большинство банков имеет либо оба таких клиента, либо использует какое-то одно, как правило, тонкое решение. И если 5 лет назад количество клиентов на толстом клиенте было 80%, а на тонком 20%, то сейчас статистика обратная. Причем во многих банках на толстом клиенте работают единичные клиенты, которым по каким-либо причинам необходимо это решение. К таким причинам часто относятся правила внутренней безопасности, использование наработанных процедур для обмена данными, привычки пользователей. Но, тем не менее, очень многие банки уже сейчас работают только с тонким клиентом. При этом необходимо учитывать, что такое решение как тонкий клиент в банках появилось совсем недавно, около пяти, может чуть более, лет назад. Тем более вопрос, заданный в статье в самом начале приобретает свою актуальность. Почему сравнительно молодые системы приходится заменять сейчас?

Ответ на этот вопрос, казалось бы, лежит на поверхности. Это происходит потому, что разработанные 5 лет и более назад системы уже исчерпали свои возможности. Они либо не справляются с текущей нагрузкой и приходится наращивать «железо» для более-менее адекватной работы системы, либо их архитектура такова, что не позволяет наращивать функционал без серьезной переделки системы. Из-за этого появляются наросты на системе в виде отдельных доработок, подсистем, которые решают только одну задачу, да и то не всегда успешно. Отчасти это связано с тем, что банки торопились запустить свой сервис и не очень-то задумывались о том как и в каком направлении он должен развиваться. Рынок был достаточно активен и важно было как можно быстрее получить сервис. Кроме того, эта проблема вызвана отсутствием опыта внедрения подобных проектов. На общей волне создавались практически одинаковые сервисы. Никто не знал, как нужно делать правильно потому, что аналитики всегда были и остаются слабым звеном любого банка. И еще одна причина связана с тем, что помимо заказных или собственных доработок, банки покупали «коробочные» решения от различных поставщиков, в том числе и западных, пытаясь их адаптировать под свои нужды. Как выясняется, коробка является не наилучшим в решении задач обслуживания клиентов, так как и эти решения устаревают, а обслуживание их обходится очень дорого. Есть и другие причины, но давайте для начала рассмотрим указанные выше подробнее.

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

1. Слабая аналитика.

Пожалуй, эта основная причина замены систем. Все остальное фактически вытекает из того, что прежнее решение не было проработано или было слабо проработано, а работал фактор скорости выхода на рынок. Возможно, что это принесло свои дивиденды в виде новых клиентов, но нам видится, что это не совсем так. В то время канал (лучше будем называть систему каналом!) не играл такой важной роли, какая отводится ему в настоящее время при выборе банка клиентом. Так или иначе, важным фактором было наличие канала, а какой там был клиент - толстый или тонкий, какая функциональность это было не важно. Об этом если и задумывались, то только некоторые единичные клиенты, да 3-4 банка. Поэтому внедрение тонкого клиента было скорее делом престижа, репутационной привлекательности для банка. Кроме того, слабая аналитика успокаивала умы руководства «легкостью» решения и простотой использования на стороне клиента. Из этого складывалось впечатление, и в первую очередь у самих банковских аналитиков, что такое решение настолько же легко и в модернизации и в разработке, и в обслуживании. Очевидно, что это не так и, как мы видим, подобная ошибка рискует вновь повториться, потому что замену текущей системы часто связывают только с задачей выбора поставщика, проведения тендера. Слабая аналитика не позволила построить систему на долгие годы, а позволила этому процессу развиваться спонтанно, часто даже по инициативе внешней компании – разработчика. И хотя многие банки думали, что управляют этим процессом, это было не так. Банки управляли очередью разработок, приоритетами задач, но никак не системой.

2. Сложность наращивания функционала.

Вторая проблема, которая появилась вскоре связана с тем, что функционал систем оказалось не так-то просто наращивать. Как выяснилось, это медленно и дорого. Часто появление нового функционала затрагивало работу всей системы, и приходилось совершать множество итераций по тестированию, регресс-тестированию и т.д. Трудность заключается еще и в том, что внешним (или внутренним) разработчикам для работы с системой требовалось увеличить количество сотрудников. А это обернулось проблемой, так как часто получалось, что правая рука не знает, что делает левая. Из-за этого появляются ошибки в функционировании, огромный поток бумаг (различные BRD, FCD etc) и привлечение к разработке сотрудников операционных блоков банка и бизнеса. С одной стороны, подобного рода привлечения могут быть полезны, но в данном случае из-за этого время появления нового функционала значительно возрастает, потому что формулировка задачи у каждого блока различная. Поэтому очень долго даже внутри банка не получается договориться, что же необходимо делать, и как это впишется в процесс. Что касается набора документов (BRD, FCD), то, с одной стороны, это также упорядочение процессов в банке, а с другой стороны, это явная бюрократизация процесса. Задача измельчается, времени тратится неимоверно много, все большее количество людей вовлекаются в процесс, язык у документов становится сухим до безобразия. В результате работа выполняется не разработчиком, а кодером, у которого может быть, вообще говоря, и не очень высокая квалификация. И это тоже накладывает свой отпечаток на сложность разработки, потому что несовершенство кода отдельного функционала тянет за собой проблему для всей системы.

3. Тупиковые архитектурные решения

Опять же, слабая архитектурная проработка решения в результате вылилась в полное отсутствие модульности у канала. Система стала настолько монолитной, что сразу появился целый воз различных проблем. Большинство из них описаны выше, но главное, что монолитная система не является гибкой, а значит не может вовремя реагировать на потребности рынка. Знаете, как некоторые банки выходили из подобного тупика? Они имели несколько систем. Не просто толстый и тонкий клиент, а еще и другие системы, которые немного различались функционально. Или потому, что клиенты хотели видеть привычный им интерфейс. Улавливаете? Система настолько сложна, что интерфейс пользователя невозможно поменять (хотя, казалось бы, легкое решение, интернет-технологии и т.д.) его проще купить вместе с другой системой. Кроме того, архитектура подобных систем превращала их в темный ящик, к которому нельзя ни подключиться, ни заставить его работать иначе. Как правило, такие системы не имеют описанных Веб-интерфейсов или API, а значит не могут быть использованы в банковских процессах иначе, более гибко. А еще непродуманность архитектуры привела к избыточности хранения данных. Например клиентская информация дублируется в такой системе, а если их несколько, то в каждой из систем. Документы и выписки также хранятся в нескольких базах. Естественно, что этому есть и объяснения, например, такое, что АБС банка может не выдержать нагрузки от запросов, поэтому проще информацию из нее скопировать в промежуточную базу и пусть клиенты работают с ней, а данные с АБС реплицировать. И последнее, о чем тут хотелось бы сказать, это то, что слои бизнес-логики во всех имеющихся системах перемешаны и со слоем представления, и со слоем данных. Это значит, что система использует имеющуюся базу данных не только как хранилище, но и как элемент программного кода, то есть хранит в ней процедуры, триггеры, которые отражаются не только на бизнес-логике, но и на поведении системы, то есть систему трудно настроить в других реалиях (например с другой БД).

4. Недостаточная пропускная способность.

Эта проблема появилась неожиданно. При проектировании системы, конечно, закладывались на будущий рост и клиентской базы, и документов, и другой нагрузки. Но, то ли посчитали неверно, то ли потеряли уже эти данные, только выяснилось, что большинство систем просто виснут, когда количество документов увеличивается. Причем происходит это в час пик с 11 до 14 часов, когда клиенты отправляют документы для исполнения текущим днем. Важно, чтобы система работала именно в это время без перебоев, а она на это не рассчитана. Потому что при проектировании в требованиях либо указывали количество документов (транзакций) в день, либо скорость перерисовки формы. Формально эти требования выполняются, только есть разница, когда 1000 документов приходит не за весь 9-ти часовой день (с 9 до 18) а за один час. И форма у клиента перерисовывается, только сервер документы не успевает обработать и передать в банковские системы на исполнение. Естественно, что существуют комплексные методы оценки производительности, но в данной статье мы их не рассматриваем.

5. Наличие коробочного решения

Здесь тоже все не так однозначно. С одной стороны, многие банки приобрели коробочное решение, с другой стороны, это коробочное решение часто «допиливалось» под нужды банка и становилось кастомизированной версией. И третье, внешняя компания создавала или развивала какой-то из своих продуктов, а часто идею под нужды банка. Что из этого всего получилось? Казалось бы, те банки, которые имеют полностью купленный продукт, могут переложить бремя забот на вендора, а все остальные получат описанные выше проблемы. Но это вовсе не так. По сути, все описанные выше проблемы коснулись и разработчиков. Все то, о чем мы говорили выше: и слабая аналитика, и непродуманность архитектуры - все это в полной мере можно приложить и к готовым продуктам вендоров. Недаром они тоже в последнее время меняют не только версии, но и платформы для своих решений. А те решения, которые подгонялись под банк (кастомизированные версии) или созданные специально под банк имеют еще и очень большую стоимость для банка, так как поддержка их дороже и много потрачено средств на их развитие. Тем не менее, вендоры, естественно, не оставляют банки самостоятельно решать проблемы, а предлагают более или менее приемлемые решения. Однако, процесс смены решения и смены вендора происходит. Еще одна из причин – неудовлетворенность компанией разработчиком. Возможно, что за многие годы работы с внешним разработчиком банк накопил какой-то негативный опыт, что и заставило его искать новых партнеров. Причем появляется субъективная уверенность, в том, что при смене партнера удастся избежать всех тех проблем, которые были с предыдущим партнером. Конечно это не так, тех же проблем возможно и не будет, но появятся другие, не менее сложные. Об этом тоже не стоит забывать, и это весьма значимый фактор.

6. Слияния и поглощения банков

Этот пункт все более и более становится актуальным в последнее время. Банки укрупняются в том числе за счет покупки других банков. Часто этот процесс связан с развитием филиальной сети, которую проще купить, чем строить. Обычно в этом случае приобретается небольшой региональный банк, либо банк с развитой сетью. Приобретается он весь, со всеми клиентами, процессами, системами. И в какой-то момент оказывается, что у нового банка есть несколько различных систем, каждая из которых имеет свои недостатки и достоинства, но часто получается, что ни одна из них не может стать единой системой для объединенного банка. Тогда и запускается механизм смены канала, запуск тендеров и т.д. Причем банк может накопить несколько систем и в какой-то момент захочет от них избавиться. Хорошо, если подобный гэп удается предусмотреть на ранних стадиях планирования расширения банка. Тогда можно заранее изучить возможности своей системы и доработать ее, но часто на этом этапе не привлекаются сотрудники, ответственные за канал, а дело касается только узкого круга лиц из бизнеса. Так в одном из Российских банков было 7 систем и было принято решение остаться только с тремя.

Вместо заключения

Итак, выше мы рассмотрели основные причины смены системы банк-клиент для юридических лиц в российских банках в настоящее время. А что же происходит за рубежом, может быть это только локальный тренд? О нет, подобные процессы затронули не только нас, но и мировое банковское сообщество и здесь мы живем по единым законам рынка, не отставая от него. Важно, что смена систем на западе происходит по тем же самым причинам, плюс еще одна не описанная выше, характерная более для западного направления, чем для российского. Эта причина в том, что банки теряют клиентов, точнее, клиенты стали более разборчивы в выборе банка. Для них сейчас важна не только репутация учреждения, но и удобство работы с ним, набор продуктов и возможность самим выбирать необходимые сервисы. Этому можно посвятить отдельное исследование на тему мировых трендов для построения канала общения с клиентами.

Что же следует из всего вышесказанного? Во-первых, мы видим тенденцию к замене систем. Во-вторых, большинство банков пойдет по уже пройденному пути (не будем его называть ошибочным!) и построит себе новую систему на другом уровне, но изначально мертворожденную. Она будет удовлетворять текущим потребностям, ее функционал будет богаче того, что было в банке ранее, но эта система не сделает банк лидером, потому что будут повторены все или большинство из перечисленных выше ошибок. А значит, через лет 5-6 или даже ранее, систему опять придется менять, потому что она окажется «не в рынке». Поэтому именно сейчас необходимо очень тщательно подойти к процессу построения канала, учитывая, в том числе, и рост банка, чтобы не столкнуться с проблемой серьезной модернизации в будущем, которая обернется не просто очередной заменой системы, а потребует больших изменений всего IT банка. Даже сейчас очень многие банки, меняя систему, затрагивают и меняют многие процессы, а в следующей смене, задействовано будет большинство IT систем банка. Чтобы этого не случилось, необходимо серьезно поработать над вопросами архитектуры, стратегии, а также примерить на себя мировые тренды в развитии банков.

Именно этой теме и будет посвящено следующее исследование.