Автоматизированные банковские системы

В конце 1996 г. стало известно об АБС шестого технологического поколе­ния, построенных на базе новейших компонентных технологий. Промышленных систем шестого поколения пока нет, хотя есть примеры удачно выполненных по этим технологиям элементов АБС.

Таким образом, сегодня на российском рынке АБС одновременно присутст­вуют системы четырех технологических поколений — со второго по пятое. Доста­точно часто одна и та же фирма-разработчик одновременно предлагает клиентам системы нескольких поколений. Так работают, например, «Инверсия», «Програм­Банк», «Диасофт» (они предлагают системы второго, третьего и четвертого поколе­ний), ЦФТ (предлагают системы третьего, четвертого и пятого поколений). Недавно компания «R-Style Software Lab.» также представила свою новую разработку «Кон­дор», относящуюся к четвертому технологическому поколению.

В российских банках преобладают системы второго и третьего поколений, хотя за рубежом они практически не встречаются. Почему же АБС на базе профессиональ­ных СУБД не заняли в России того места, которое они занимают за рубежом? Ос­новная причина этого — разница в мотивах и механизме принятия решений в об­ласти информационных технологий у нас и в других странах.

Как принимаются решения?

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

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

Как выбирается и внедряется АБС у нас, читатели знают по собственному опыту. Чаще всего новая АБС приобретается либо для нового банка, либо когда прежнюю уже совершенно невозможно использовать. При этом главное требование к новой АБС — заткнуть те дыры, которые не затыкает предыдущая. Многие руко­водители банков ставят во главу угла дешевизну системы, до сих пор не понимая, что «настоящая» АБС должна стоить дороже хотя бы автомобиля, на котором ездит председатель правления: именно от нее по большому счету зависит благополучие банка.

В отставании российских банков отчасти повинны и разработчики. Когда в 1994-1995 гг. создались благоприятные условия для смены поколений АБС (банки имели свободные средства, а норма прибыли начала ощутимо снижаться — это спо­собствовало созданию у банков внутренней мотивации к совершенствованию тех­нологий), на рынке почти не оказалось отечественных АБС четвертого поколения, приемлемых по критерию «стоимость — эффективность». Ведущие (по числу про­данных копий) разработчики АБС предыдущих поколений либо сочли, что «от до­бра добра не ищут», либо отнеслись к созданию АБС нового поколения недоста­точно продуманно. Многие из них решили, что для успеха достаточно перенести на профессиональную СУБД то, что было наработано на Clipper или FoxPro. Техниче­ски осуществить такой «перенос» было относительно легко, но очень сложным де­лом оказалось объяснить покупателям, зачем надо платить в несколько раз больше за систему, в которой практически нет отличий от старой с точки зрения функцио­нальности. К тому же подавляющее большинство разработчиков просто не смогло вовремя представить на рынок законченные системы четвертого поколения, так как освоение инструментальных средств и выработка концепции новой системы отняли у них слишком много времени. Ряд разработок, с большой помпой объявленных два-три года назад, не готовы и до сих пор.

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

«Оправданием» отечественных банков может служить то, что они вынуждены по­купать системы по принципу «побыстрее да подешевле», как говорится, не от хо­рошей жизни. До сих пор нормотворчество Центробанка заставляло разработчиков не реже, чем дважды в год, переделывать ядро системы и схему данных, а что каса­ется отчетов, то они добавлялись или изменялись порой по несколько раз на неделе. Апофеозом такого стиля руководства отечественной банковской системой стал пе­реход на новый План счетов, который объективно необходим и полезен, но внедря­ется со свойственной нашему национальному характеру бесшабашностью и недаль­новидностью.

Из всех постсоциалистических стран, где вводился план счетов по образцу международного, только в России национальный банк тянет до последнего с фор­мированием полного комплекта инструктивных и методических материалов. От­дельные инструкции, без которых, кстати говоря, невозможно представить заказ­чику законченную АБС, должны быть готовы к 1 ноября1997 г., то есть за два ме­сяца до перехода — и это по плану, а что будет на самом деле — Бог весть... Но даже в случае, если ЦБ РФ выдержит собственный план, инструкции поступят в банки отнюдь не в день их подписания.

В этой ситуации некоторые банки искренне надеются, что «все рассосется», и каким-то чудодейственным образом переход на новый План счетов будет сдвинут с 1 января 1998 г. на какой-то неопределенный срок. Ассоциация российских банков даже обратилась в Банк России с просьбой перенести переход на начало второго квартала(!). Не дай Бог, если эта просьба будет удовлетворена. Тогда к организаци­онным сложностям перехода добавятся чисто технические, поскольку — и это дос­таточно очевидно — всякие изменения в бухгалтерском учете гораздо легче ввести с начала года, чем с начала квартала.

Новый план счетов и АБС

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

Неизбежен передел рынка АБС: с него уже ушли некоторые фирмы, напри­мер «АСОФТ» (не путать с «АСофт», которая благополучно продолжает существо­вать) или «VIMCOM». По-видимому, понесут некоторые потери такие заслуженные разработчики, как «Инверсия», «ПрограмБанк», «ЛИМ», чьи DOS-комплексы в не­которых банках будут заменены на системы третьего поколения — и вовсе не обя­зательно тех же самых фирм. Ожидается, что самые большие «убытки» понесут собственные программные разработки банков.

Целый ряд опросов, проведенных журналом «Банковские технологии», по­казал парадоксальную картину: среди банков-респондентов, имеющих АБС собст­венной разработки, довольных этой АБС оказалось значительно меньше, чем среди тех, кто работает на «фирменной» АБС. Объясняется это просто: во-первых, собст­венные системы в большинстве случаев выполнялись на тех же FoxPro или Clipper; во-вторых, коллективы разработчиков, которых могут позволить держать у себя в штате банки, весьма немногочисленны; в-третьих, разработка ведется по принципу «латания дыр», что исключает системный подход и нормальное взаимодействие от­дельных модулей. «Доморощенные» АБС очень трудно, да и практически невоз­можно, подвергнуть серьезной модернизации, так как нормальная документация проекта обычно не ведется. Именно такие АБС скорее всего потребуют замены. Если какие-то банки еще питают иллюзии, что им удастся «довести до ума» подоб­ную разработку собственными силами и в срок, и поэтому тянут с решением о пе­реходе на АБС, созданную внешними фирмами, то их ожидают большие разочаро­вания.

Совершенно очевидно, что многие банки будут вынуждены «менять коней на пере­праве», так как имеющиеся у них АБС неадекватны, и любые попытки как-то удер­жаться на старой платформе приведут к большим потерям. В этом случае следует помнить одно: переход на новый План счетов будет успешным только там, где во­время проведена тщательная его организационная подготовка (жаль только, что ме­тодичность и скрупулезность не свойственны нашему национальному характеру). Руководство банка должно было уже в октябре составить и утвердить детальный план перехода, в котором следует четко распределить обязанности и ответствен­ность подразделений и должностных лиц. Этот план должен быть расписан по не­делям, а с декабря — по дням, с соответствующей оперативной отчетностью.

Чтобы более нагляднее представить, что такое современная АБС, постараемся более подробно разобрать ее строение.

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

Архитектурное построение
Вся система состоит из трех компонентов:

1) клиентской части системы;
2) объектов сервера данных;
3) процедур сервера приложений.

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

Объекты сервера данных являются центральной частью системы. Здесь хранятся все данные системы и процедуры, обеспечивающие выполнение ее операций. Хранимые процедуры получают запрос от клиентской части на выполнение операций и подготавливают для нее результаты своей работы. Для выполнения некоторых специфических операций хранимые процедуры могут вызывать процедуры сервера приложений.

На сервере приложенией выполняются специализированные AS-процедуры, которые вызываются по запросам от процедур сервера данных.

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

Клиентская часть системы. Основное назначение клиентской части системы — обеспечить взаимодействие пользователя с системой, предполагающее организацию интерфейса пользователя (отображение и обработка событий) и связь с сервером данных (Manager SQL).

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

Объекты сервера данных. Объекты сервера данных — это таблицы и процедуры. По своему назначению они разделяются на системные (в контексте банковской системы, а не базы данных) и прикладные.

Системные объекты реализуют задачи “секретности” и управления доступом (этим правом обладает только уполномоченный оператор — так называемый “офицер безопасности”).

Доступ к прикладным объектам клиентов возможен только через узкую “щель”, определенную системой безопасности. Система построена так, что все функции, необходимые клиенту, реализуются через вызов хранимых процедур. Последние надежно защищены системой управления доступом, и поэтому давать разрешение пользователю на использование таблиц нет необходимости. Иначе пришлось бы заботиться о том, кому из персонала банка следует передать таблицу для выполнения определенных действий — при этом о доступе к конкретным записям (“сайтам”) речь не могла бы идти вообще.

При вызове клиентом пользовательских процедур (объектов, представляющих для системы безопасности основной интерес) сразу же происходит обращение к серверу защиты (он реализуется как сервер приложений). При получении соответствующего разрешения выполнение процедур продолжается. В этом и заключается сущность взаимодействия клиента с сервером данных под надзором системы безопасности. Остальные процедуры (т.е. те, которые не вызываются клиентом) не связаны с системой безопасности, поскольку они защищаются средствами сервера данных (Рис. 1).

Рис. 1. Архитектура построения системы.

Все объекты на сервере данных создаются при инсталляции системы системным администратором. Этот процесс проходит в пакетном режиме, когда с клиента на сервер посылаются запросы на создание процедур и таблиц, а также на их заполнение.