Поколения российских АБС

Распространяемые с исходными текстами «Тула» и «Киев» были теми семенами, из которых взошли, выучились и выросли российские АБС второго поколения. На самом старте рынка АБС (1992-1993 гг.) практически все разработчики с удовольствием рассказывали о том, чем их система банковской автоматизации в лучшую сторону отличается от «Киевского» опердня. Тройка лидеров второй волны (читай второго поколения) АБС обозначилась еще в 1991-1992 гг.: ^[1] (разработки велись на FoxBase), «Инверсия» (Clipper) и «ПрограмБанк» (также Clipper). Кроме них заметным явлением рынка стали московские фирмы АБТ, «Инфа», СКИЛ, красноярский «Комбис-Рамбо», минские «Надежные программы», чебоксарский «Тагрис», кисловодский «Террасофт» и некоторые другие. Примерно в 1993--1994 гг. лидеров АБС второго поколения серьезно потеснил «Диасофт» также с системой второго поколения, разработанной на Clarion ^[2].

Наиболее популярной в то время сетевой операционной системой для персональных компьютеров была OC Novell Netware с ОС DOS на рабочих местах. UNIX-системы не были столь же широко распространены, но они обеспечивали возможность работы программного комплекса под управлением более мощной операционной системы, чем связка Novell+DOS и, соответственно, на более мощных и надежных аппаратных платформах, чем персональная Intel-совместимая техника. Такими ОС могут быть UNIX, OS/400, VAX VMS и другие.

Бурный рост российских банков довольно-таки скоро обозначил проблемы безопасности, надежности и быстродействия АБС на персональных компьютерах. Поэтому практически параллельно со вторым поколением АБС уже в начале 90-х гг. появились первые банковские системы на профессиональных СУБД (позже названные четвертым поколением): система «БИС» фирмы «Сервер» на СУБД Informix Software, система «Ва-Банк» фирмы ФОРС на СУБД Oracle, система «Пирамида» петербургской фирмы «Нест» также на СУБД Informix. Их называли также UNIX-системами.

Заметим, что не всегда действующие UNIX-системы будут эффективнее, чем DOS-системы (системы первого-второго-третьего поколений). Здесь важны как минимум два момента: каким образом в прикладных разработках используются архитектурные преимущества распределенных СУБД и операционных сред высокого уровня, и каким образом банк-пользователь использует заложенные разработчиком возможности.

Cами компании-разработчики считают важными следующие характеристики АБС: действительно реальный масштаб времени (онлайн-системы), наличие встроенного генератора отчетов, развитая система разграничения прав пользователей, многопользовательский режим, логически прозрачный и дружественный пользовательский интерфейс, простота эксплуатации, гибкость настройки системы в процессе работы. Метавселенная ВДНХ 2.8 т

Ласточкой третьего поколения АБС (фактически самого распространенного в России за первые 20 лет рынка) стала разработка RS-Bank фирмы R-Style, вышедшая на рынок в первой половине 1993 г. Использование в качестве инструментария нижнего уровня менеджера записей Btrieve под ОС Novell Netware позволило в системах третьего поколения организовать поддержку режима транзакций базы данных на уровне ядра банковской системы. Конечно же, транзакции баз данных a la Btrieve организованы не с такой степенью надежности, как в профессиональных реляционных СУБД класса Oracle, Informix, Progress, Sybase. И все же это был колоссальный рывок вперед, поскольку банки в большинстве своем смогли забыть, что такое сбой базы и переиндексация *.dbf- и *.ntx- файлов (археологи-антиквары, любители Clipper и Fox под DOS, а вы-то помните?). И банковским работникам не надо было менять ставшие знакомыми и любимыми персоналки на какую-то неизвестную платформу Unix с цифровыми терминалами.

Как только появились подобные системы третьего поколения (сначала только RS-Bank), старожилы рынка АБС сразу и резко встревожились и заговорили что, мол, «Btrieve - это не база данных», что «И на dbf-структурах можно поддерживать режим транзакций». Но когда по продажам R-Style рванул вверх, и к тому же появились другие системы третьего поколения: «Кворум» фирмы «Банковские системы» (позднее фирма получила название «Кворум»), МакроБанк фирмы «Канопус», IB System новосибирского Центра Финансовых технологий (ЦФТ), Optimum BS банка «Оптимум», - вал этой не вполне заслуженной критики существенно спал. Огромное значение для раскрутки рыночного имиджа R-Style имел контракт с Мосбизнесбанком на 30 копий по филиалам, полученный по результатам тендерного отбора. Это был первый из известных автору тендеров, который проводился российским банком среди российских же разработчиков.

К 1994 г. лидерство на рынке от Большой Тройки (АСОФТ, «Инверсия», «ПрограмБанк») стало постепенно переходить к Большой Четверке (те же минус АСОФТ плюс «Диасофт» и R-Style). Формально АСОФТ еще относился к грандам и даже очень удачно смог выступить на первом Форуме разработчиков в июне 1995 г., но фирма быстро теряла рыночные позиции, уступая более молодым и агрессивным.

Заметное усиление АБС третьего поколения произошло в 1995 г., когда на Btrieve перевели свои разработки «Диасофт» и «Инверсия». Правда, «Инверсии» для этого понадобилось открывать новый интегрированный проект «Банк 2000» со своим коллективом разработчиков параллельно тогда еще вполне сильному многомодульному проекту (вслушайтесь в музыку названия!) АСУ «Комбанк». А вот «Диасофту» продвижение досталось, практически даром и «по наследству» при смене версии инструментария: Clarion v 3.* в отличие от Clarion v 2.* стал поддерживать транзакции и все базовые функции менеджера записей Btrieve напрямую (Да здравствует Clarion!).

На фоне успехов систем третьего поколения разработчики АБС на профессиональных СУБД также не теряли времени даром. Так, после снятия КОКОМовских ограничений в России стала доступной СУБД Progress. Сразу две фирмы -- петербургская CSBI EE и московская БИС -- решились разрабатывать АБС на основе инструментария Progress. Причем CSBI EE взяла в качестве прототипа российской системы «Банкир» польско-английскую разработку Bankier своей материнской компании CSBI, а БИС использовала богатый опыт работы специалистов Внешэкономбанка в качестве постановщиков задачи.

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

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

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

Для поддержки конкретных банковских бизнес-направлений создавались модули «Кредиты», «Депозиты», «Частные вклады», «Внутренняя бухгалтерия», «Фондовый отдел». В частности, под «Фондовым» модулем понималось наличие подсистемы автоматизации работы фондового отдела банка или банковского депозитария. При этом разновидности подсистемы «Депозитарий» отличались по тому, какие именно ценные бумаги могут учитываться: акции самого банка, полные выпуски акций сторонних эмитентов, ценные бумаги, закупаемые на биржевых торгах/внебиржевом рынке или те ценные бумаги, которые приносят на хранение клиенты банка.

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

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

Примечания