"БИСКВИТ" - современное решение, проверенное временем

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

Чтобы лучше понять причины замены АБС обратимся к рис. 1. На основных этапах смены автоматизированных банковских систем довольно хорошо прослеживается закономерность между потребностями рынка АБС и предложениями фирм-разработчиков.

Рис. 1. Этапы смены АБС в банках

Первый этап смены "локальных операционных дней" сетевыми решениями на основе Btrieve приходится на середину 90-х гг., когда локальные ОДБ уже полностью исчерпали свой моральный ресурс. Он характеризуется бурным развитием АБС на основе Btrieve, востребованных банками. В это же время появляются первые промышленные российские решения в архитектуре "клиент-сервер", распространение которых еще не носит массового характера. Банкам в середине 90-х гг. нужны были простые недорогие решения, обладающие определенным набором функциональных возможностей (например, сетевой real-time, мультивалютность, поддержка рублевых расчетов, набор обязательной отчетности), ими в полной мере обладали решения на основе Btrieve. Следует заметить, что и решения в архитектуре "клиент-сервер" на тот момент имели аналогичную функциональность, но проигрывали по другим параметрам (высокая цена, более сложные установка и сопровождение и, наконец, за счет маркетингового пресса со стороны фирм - поставщиков решений на базе Btrieve).

Далее следует период замены АБС (конец 1997 г.), который связан с переходом на новые Правила учета, когда у банков фактически не было времени для детального анализа АБС и взвешенного принятия решения. Перед ними стояла задача замены действующей системы на ее новую версию или выбор совершенно другой АБС. Жесткий цейтнот диктовал свои условия, и для быстрого и массового распространения решения на основе Btrieve опять подходили как нельзя лучше.

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

Банковский сектор изменился - возникла потребность в других АБС

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

Сегодня смена систем не носит ярко выраженного массового характера. В отличие от первой волны, когда выбор продукта диктовался распространенностью АБС, известностью фирмы, ее маркетинговой активностью, или второй, когда на тщательный выбор просто не было времени, на первый план при выборе АБС выходит индивидуальная долгосрочная работа фирмы - поставщика решения с клиентом (см. рис. 1). Каждый банк при выборе системы выдвигает свои индивидуальные требования, обусловленные планами развития собственного бизнеса. Банки, решившись на смену АБС, осуществляют долгосрочные и довольно серьезные инвестиции в информационные технологии.

Каковы же требования современных банков к новым системам автоматизации?

Новые тенденции развития АБС. Критерии выбора

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

1. возможность работы филиалов и отделений с единой базой данных в различных режимах (on-line, off-line);
2. как следствие - возможность удаленного доступа с использованием каналов различной пропускной способности;
3. возможность обрабатывать большие объемы данных (до сотен тысяч транзакций ежедневно);
4. возможность одновременной работы большого числа пользователей (сотни пользователей);
5. "эластичная производительность" - возможность одинаково хорошо работать в разных диапазонах нагрузок;
6. полный набор функциональности в рамках единого программного продукта (РКО, валюта, дилинговые операции, операции с ЦБ, рублевые и международные расчеты, "клиент-банк", аналитическая отчетность, консолидация данных и пр.);
7. наличие интерфейса с другими информационными и справочными системами;
8. соответствие индивидуальным требованиям банка;
9. качественное внедрение и сопровождение системы;
10. устойчивое положение фирмы - поставщика решения, наличие положительного опыта внедрения системы.

Безусловно, данный список может быть продолжен, но все же основные характеристики в нем присутствуют.

Рассмотрим далее некоторые из этих критериев и различные способы решения данных проблем в АБС.

Платформа и СУБД - определяющий параметр

Вне всякого сомнения, именно платформа и СУБД позволяют успешно решать большинство из сформулированных выше задач. Очевидно, что оптимальных показателей можно достичь, только применяя решения в архитектуре "клиент-сервер". Фирма БИС с начала 90-х гг. ведет разработку собственной АБС, используя в качестве базы данных профессиональную СУБД Progress. Она может быть отнесена к группе компаний, решения которых сейчас доминируют на рынке (на рис. отмечены цифрой 3). Почему это так? Ответ можно сформулировать следующим образом.

Компании, ориентированные в середине 90-х гг. на реализацию решений на платформе Btrieve, потратили на это большие финансовые и временные ресурсы. Они фактически на 3-5 лет позже начали вести работы в области клиент-серверных решений (цифры 2 и 4 на рис.). Чудес не бывает, и "9 женщин не могут родить за один месяц ребенка". Поэтому отставание новых клиент-серверных АБС как в технологическом, так и в функциональном планах, закономерно. В этом случае ни агрессивная маркетинговая политика, ни специальные ценовые предложения не способны ликвидировать тот разрыв, который образовался между данными группами АБС. Несомненно, через 2-3 года АБС в архитектуре "клиент-сервер" "второй волны" имеют возможность сравняться с современными лидерами, но, как говорится, время уже будет упущено.

Наоборот, компании, которые с самого начала своей деятельности (первая половина 90-х гг.) приняли правильные (но на тот момент вовсе не очевидные!) стратегические решения по поводу СУБД и соответственно платформы и, что очень важно, довели до промышленных установок свои решения, вышли сейчас на лидирующие позиции. Без сомнения, АБС БИСКВИТ, находившаяся в середине 90-х гг. "в тени" решений на базе Btrieve, - из их числа. Это подтверждается успехом, которым она пользуется на рынке в течение последних лет.

Например, для решения такой важной проблемы, как удаленный доступ, оптимально подходит режим "хост-терминал". Именно такой режим является основным для АБС БИСКВИТ. При таком построении системы, во-первых, минимизирован сетевой трафик, что позволяет существенно экономить ресурсы на телекоммуникациях, а во-вторых, очень низки требования, предъявляемые к рабочим станциям, что дает возможность банкам сохранять инвестиции в аппаратное обеспечение.

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

Многоплатформенность - остерегайтесь подмены понятий

К сожалению, сегодня на российском рынке АБС часто происходит подмена понятия многоплатформенности. Некоторые фирмы вместо реальной многоплатформенности, благодаря которой одно и то же приложение с использованием одной и той же СУБД может работать на разных аппаратных платформах (под управлением различных операционных систем), предлагают так называемое решение "multi-DBMS" (что в переводе на русский язык может звучать не совсем благозвучно, например: "поддержка множества СУБД"). На первый взгляд подмена понятий практически незаметна (в принципе, конечному пользователю не всегда интересно знать, на какой СУБД функционирует его АБС). Тем не менее при более тщательном рассмотрении вопроса проблемы, возникающие при последней реализации, приобретают очень серьезный характер.

Наличие единого подхода к обработке данных в SQL-серверах различных производителей позволяет говорить о возможности наличия решения типа "multi-DBMS". Однако возможность оптимального соединения в одном прикладном коде обработки файл-серверных (Btrieve) и клиент-серверных СУБД (Oracle, Sybase, MS SQL и пр.) вызывает большие сомнения. Такое решение, например, возможно, если массовую обработку при помощи оператора select (для SQL-серверов), для которого нет прямого аналога в СУБД файл-серверной архитектуры, заменить на единичную обработку записей (например, при помощи того же оператора select, но применяемого к каждой отдельной записи!). Тем не менее в этом случае теряются все преимущества SQL-подхода к массовым обработкам и налицо серьезная потеря производительности.

Кроме того, такой подход является более трудоемким по сравнению с "классическим" решением проблемы средствами СУБД, так как предполагает необходимость разработки специального сервиса для унификации доступа к различным базам данных. Фактически при этом фирма - разработчик АБС перекладывает на себя очень сложную и трудоемкую задачу, которая уже решена фирмами - разработчиками СУБД. В условиях современной конкуренции на рынке АБС такая расточительность может стоить очень дорого.

Ни в коем случае не желая бросить тень на подобное решение проблемы многоплатформенности (масштабируемости), все же отметим, что наиболее оптимальным, по мнению автора, является решение проблемы средствами СУБД, когда одна и та же СУБД работает на различных аппаратных платформах. Например, выбранная фирмой БИС для АБС БИСКВИТ СУБД Progress одинаково успешно работает на целом ряде платформ под управлением операционных систем UNIX и Windows NT. Помимо поддержки таких "традиционных" для России платформ имеется возможность работать и под управлением операционной системы AS 400.

Кроме того, стоит отметить, что выбор аппаратной платформы для банка не часто выполняемая операция. Если банк приобретает систему в архитектуре "клиент-сервер", то возможность масштабирования ему уже гарантирована. Следовательно, потребность в смене платформы, а уж тем более СУБД, отпадает. Естественно, банки, работающие на Btrieve, рано или поздно "упираются в потолок" и вынуждены менять платформу, а иногда и АБС.

Выбор по комплексу параметров

При всей важности системных требований (платформа, СУБД и пр.) не менее значимыми являются прикладные свойства АБС. Несомненно, при выборе новой АБС банк должен обратить внимание на наличие требуемых ему полнофункциональных модулей в рамках единой системы. Решения, построенные на интеграции разнородных продуктов, получившие распространение с середины 90-х гг., уже не могут удовлетворить банки и сходят с рынка. Не будем останавливаться на недостатках такого подхода, они очевидны (взять, например, проблему пакетного обмена информацией с моментальной потерей режима real-time!).

Современная АБС должна содержать необходимые функциональные модули, перечень которых хорошо известен, и мы не будем на них подробно останавливаться (это может быть темой отдельной статьи).

Важным требованием к современной АБС, которое учитывается банками при выборе, является адаптируемость АБС. Дискуссии по возможным способам решения этой проблемы ведутся уже давно. При этом существуют различные варианты решения - от совершенно жестких систем, адаптация которых возможна только силами фирм-разработчиков, до полностью "гибких", представляющих собой "банковские конструкторы". По-видимому, как всегда оптимальное решение находится где-то посередине. "Жесткие" системы (в основном, к этому классу принадлежат западные АБС) мало подходят для динамично изменяющихся внешних условий и законодательных требований России. Например, изменения макетов, форматов платежных документов, способ расчета ФОРа и пр. необходимо осуществлять в очень сжатые сроки, что не всегда реально для фирм-разработчиков.

АБС, построенные по принципу "банковского конструктора", практически так и не были востребованы рынком

Это другая крайность. Такие программные продукты, несомненно, представляют интерес как полигон для развития информационных технологий. Однако интерес этот скорее академический, и подогревается он не реальными потребностями банков, а самими же фирмами-разработчиками, усиленно пытающимися "создать спрос" на новую продукцию. Вызывает большое сомнение непременное наличие в АБС таких обязательных атрибутов "конструкторов", как репозитарий, словарная система, workflow-модель и пр. С данными понятиями должны иметь дело разработчики различных информационных систем, в то время как решение прикладных банковских задач этими средствами, как правило, сложно и очень трудоемко. При этом результаты, достигаемые с их помощью, ничем принципиально не отличаются от результатов, которых можно достичь "классическим" методом многопараметрической настройки.

Наиболее оптимальным практическим решением для АБС все-таки является сочетание многопараметрической настройки системы с возможностью "локальных", собственных доработок силами отделов автоматизации. Именно такой подход реализован в АБС БИСКВИТ. Наличие в системе мощного механизма настройки банковских операций с возможностью генерации различных типов связанных документов позволяют осуществить настройку (именно настройку, а не "конструирование") любой банковской технологической цепочки с поддержкой распределения выполнения ее различных этапов как по подразделениям банка (по пользователям), так и по времени. Это как раз соответствует современным "академическим" требованиям (поддержка workflow-технологии) к автоматизации документооборота банка.

Индивидуальная работа с клиентом - требование современного рынка

Несомненно, важным параметром выбора АБС является качество внедрения и сопровождения продукта. Здесь по аналогии с западной "кредитной историей" на первый план выходит история работы компании со своими клиентами. Процесс завоевания положительного имиджа - дело долговременное и кропотливое. Эту задачу не решить в течение полугода, хотя растерять с трудом нажитое вполне реально даже за такой короткий срок. Невозможно переоценить ту роль, которую играют высококвалифицированные специалисты, способные решать задачи любой сложности. За время работы фирмы БИС сложился коллектив высококвалифицированных сотрудников, полностью отвечающих данным требованиям. Это касается всех подразделений компании: разработки, тестирования, сопровождения, внедрения и аналитики. Подтверждением тому могут служить высокое качество программного продукта и положительные отзывы пользователей системы.

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

* В статье не будут использованы термины "интегрированная", "система управления банком" и прочие, так как практически все фирмы-разработчики наделяют собственные АБС такими эпитетами. Термин "АБС" наиболее лаконично и емко отражает суть описываемого объекта.

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

*** Чтобы не вступать очередной раз в дискуссию, под документом в системе БИСКВИТ понимается любой банковский документ (заявка, платежный документ, распоряжение и пр.). Понятию "сделка" соответствует договор привлечения-размещения.