Автоматизированная банковская система. Проблемы, поиски, решения.

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

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

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

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

Выбор среди наиболее известных баз данных сводится на сегодняшний день к выбору между Oracle, Sybase, Informix, MS SQL Server и Progress. Тут не последнюю роль сыграл принцип "цена - качество". Среди всех перечисленных баз данных (БД) самой мощной, но и самой дорогой в эксплуатации является Oracle. Остальные БД примерно однотипны, но Progress при этом дешевле. Исследования, проведенных компанией Aberdeen Group, показали, что эксплуатация Progress Workgroup Server в течение пяти лет обходится на 21% дешевле, чем Microsoft SQL Server, и на 70% дешевле, чем Oracle аналогичной конфигурации. Достигнуто это за счет более низкой цены продажи и более простого, а значит, и дешевого сопровождения БД при ее высокой надежности. О последнем свидетельствует, например, такой случай. Во время демонстрации работы системы тогда еще заместителю председателя НБ РК Бектасову А.А. в разгар рабочего дня был выключен сервер, затем его снова включили. После этого в течение нескольких минут автоматически произошел откат незавершенных транзакций и была восстановлена БД, что практически никак не отразилось на работе банка. Из выводов, к которым пришла Aberdeen Group, следует, что Progress является "рентабельной и надежной базой данных, с простой инсталляцией, сопоставимой, если не лучшей по качеству, с другими базами данных, обладающей ошибкоустойчивостью и надежностью. Данная БД эффективна для решения проблем автоматизации малых, средних организаций и больших корпораций и предъявляет самые низкие требования к обслуживанию и ресурсам". Конечно, в 1996 г. у нас не было этих данных, но, основываясь на указанных выше сопоставлениях и сравнивая имеющиеся на базах данных АБС, мы выбрали Progress, а вместе с ним и БИСКВИТ.

Что касается операционной системы, то по рекомендации разработчика была выбрана ОС UNIX, которая и сейчас остается одной из наиболее надежных, высокопроизводительных, гибко настраиваемых и масштабируемых операционных систем (ОС). Правильно выбрав ту или иную версию UNIX для подходящей аппаратной платформы, можно получить центральную ЭВМ практически любой производительности с рекордно низким уровнем параметра "цена - производительность". И вот тут хотелось бы бросить камешек в огород всеми нами любимой фирмы Microsoft, которая успевает своим новым программным обеспечением почти полностью забить память и процессоры еще только готовящихся к выпуску компьютеров.

Для работы интегрированной банковской системы БИСКВИТ мы используем "хост-терминальную" схему. В этом случае "процесс-сервер" и "процесс-клиент" выполняются на центральной ЭВМ (так называемом "хосте"), а на рабочем месте происходит лишь ввод и отображение данных. Такой "хост-терминальный" подход позволяет существенно минимизировать требования, предъявляемые к оборудованию персонального рабочего места, поскольку программный эмулятор терминала не требует большой вычислительной мощности ЭВМ и в зависимости от выбора конкретной программы-эмулятора может использоваться под различными ОС, в том числе и под DOS. Естественно, что при этом значительно снижается и нагрузка на сеть. Согласитесь, что данный способ работы позволяет значительно уменьшить затраты на покупку оборудования, так как можно, например, использовать компьютеры с 286 и 386 процессорами. Трудно поверить, но остается фактом, что, внедряя ИБС БИСКВИТ и эксплуатируя систему в течение нескольких первых месяцев, администратору БД пришлось работать на компьютере с 286 процессором. При этом самым большим неудобством было написание отчетов о проделанной работе в лексиконе, но никак не сама эксплуатация системы.

Теперь хотелось бы поделиться с читателями своим опытом в решении созданной Национальным Банком Республики Казахстан проблемы Главной книги (ГК). Тут НБ РК, проявляя под давлением консультантов из IBTCI заботу о менеджменте коммерческих банков, на самом деле сильно подтолкнул процесс автоматизации банков второго уровня к развитию (по крайней мере в нашем банке точно). Конечно, можно было легко создать видимость существования Главной книги, написав некоторую отдельную от основной базы "примочку" на dBase, или подешевке купить ГК в банковском сервисном бюро. Но в данном вопросе, несмотря на мировой кризис и трудности в экономике, руководство банка проявило принципиальность, и в результате банк пошел на значительные расходы, связанные не только с внедрением Главной книги, но и с дальнейшей автоматизацией банковских работ. В конце 1998 г. нами была приобретена лицензия на использование следующей версии ИБС БИСКВИТ как для головного офиса (ГО), так и для каждого филиала. В этой версии (версия 4.1) уже исключен старый План счетов, но зато специально для банков Казахстана предусматривается ведение Главной книги. Для ее ведения мы, в свою очередь, разработали единый для головного офиса и всех филиалов бланк распоряжения на открытие счета, в котором предусматривается проставление необходимой, как для ГК, так и для других целей, информации о счетах и клиентах, на основании которой в дальнейшем Главная книга и формируется. Самым трудным для нас было, да и сейчас является, формирование ГК по каждому филиалу и по банку в целом. Вначале мы собрались получать отчеты по Главной книге из каждого филиала, а потом формировать сводную ГК, но тогда возникает вопрос: как быть с проводками по ГК каждого филиала, да и где гарантия, что отчет по ГК филиала составлен верно? Статистика показывает: сколько бухгалтеров, столько и балансов, не говоря уже о таком новом деле, как ведение ГК, назначение которой только сейчас становится ясным, а уж как ее составлять, понятно далеко не всем. Таким образом, было решено составлять Главную книгу самим в головном офисе на основе всех проводок, которые делаются в нем и в филиалах. Для этого на основе распоряжения на открытие счета мы создали макет телеграмм на открытие, изменение, а также закрытие счета и макет проводок. Завели в ГО операционный день на каждый филиал, внесли туда всех клиентов с признаками, открыли все счета с признаками и в течение декабря 1998 г. получили вступительные балансы по каждому филиалу. Теперь филиалы шлют нам телеграммы проводок, которые автоматически втягиваются в операционный день соответствующего филиала. Далее для филиала формируются баланс, проверочные ведомости, которые затем отсылаются обратно для проверки. Если что-то не совпадает, филиал имеет возможность подкорректировать. В итоге в головном офисе владеют почти всей информацией о филиале и имеют возможность оперативно составлять большинство требуемых отчетов. Точно так же можно отслеживать остатки, обороты и проводки по счетам Главной книги как каждого отдельного филиала, так и банка в целом.

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