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

ОГЛАВЛЕНИЕ

Введение…………………………………………………….…..………. 3

Автоматизированные банковские системы, их эволюция и технологическое построение……………………………………………….... 6

Основы автоматизации банковской деятельности…………………….……24

Ситуация на рынке банковских технологий……………………….……24

Классификация современных автоматизированный банковских систем………………………………………………………………………26

Принципы построения автоматизированный банковских систем как средства автоматизации работ с банковскими продуктами ……….28

Заключение ………………………………………………………………………… 36

ВВЕДЕНИЕ

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

Несмотря на существующие недостатки российского законодательства, ре­гулирующего деятельность банков, ситуация неуклонно меняется к лучшему.

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

Все это непосредственно связано с изменением общей экономиче­ской об­становкой в Российской Федерации. Спад промышленного про­извод­ства во всех отраслях народного хозяйства хрониче­ские неплатежи - все это за­ставляет искать новые формы расчетов, кредитных отношений.

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

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

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

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

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

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

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

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

Задачи, стоящие перед всеми финан­совыми организациями, одинаковые: ин­те­грация унаследованных систем в рас­пределенную архитектуру локальных се­тей. Дэвид Стюарт, главный консультант по новым техно­логиям в Global Con­cepts, счи­тает, что сегодня спрос на людей, пони­мающих в сетях, выше, чем ко­гда-либо пре­жде. По его мнению, в наше время при устройстве на работу в банк предпочтение отдается программисту, а не кассиру.

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

В качестве примеров передовых технологий, используемых в банковской деятельности, можно назвать базы данных на основе модели "клиент-сервер" (ха­рактерно использование ОС Unix и БД Oracle); средства межсетевого взаимо­дейст­вия для межбанковских расчетов; службы расчетов, целиком ориентиро­ванных на Internet, или, так называемые, виртуальные банки; банковские экс­пертно-аналити­ческие системы, использующие принципы искусственного ин­теллекта и многое другое.

АВТОМАТИЗИРОВАННЫЕ БАНКОВСКИЕ СИСТЕМЫ,

ИХ ЭВОЛЮЦИЯ И ТЕХНОЛОГИЧЕСКОЕ

ПОСТРОЕНИЕ

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

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

Коммерческим банкам сразу же пришлось предоставлять в Госбанк ежедневные ба­лансы. Без собственных средств автоматизации сделать это было, мягко говоря, за­труднительно — даже для того уровня банковских операций, который был тогда. К счастью, именно в это время появились кооперативы и центры НТТМ, завозившие в страну персональные компьютеры. Люди, способные к программированию, созда­вали «временные творческие коллективы», искали и находили заказы на автомати­зацию банковской деятельности и получали свои деньги за «внедрение научно-тех­нических достижений». Программы писались на Clipper или FoxBase, иногда на ТурбоПаскале, которые списывались умельцами друг у друга и осваивались безо всякой документации.

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

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

АБС второго поколения очень быстро завоевали рынок. На них выросли та­кие известные сейчас фирмы, как ЛИМ, «Инверсия», «ПрограмБанк», «Диасофт», «АСофт»... Некоторые из них до сих пор основной свой доход имеют от сопровож­дения старых систем второго поколения.

Однако уже в 1993 г. системы, сделанные на технологической базе «персональных» СУБД, перестали удовлетворять многие банки и прежде всего крупные: для них важна была эффективная работа в локальной сети. Ряд из них стали закупать запад­ные разработки, другие пытались создать АБС своими силами... Новые решения на­чали предлагать и отечественные фирмы-разработчики. Некоторые, ориентируясь на Запад, делали ставку на «тяжелые технологии» — мощные центральные компью­теры, работающие в режиме «хост-терминал» или «клиент-сервер», и профессио­нальные системы управления базами данных (СУБД). Именно так построены прак­тически все западные АБС, работающие в серьезных банках. Однако в России по­добные АБС до сих пор не слишком популярны: их техническая база (центральные компьютеры, лицензии на системное программное обеспечение и т.п.), по сравне­нию с персональной техникой, очень дорогостояща и требует специальной подго­товки персонала. В то же время в каждом банке, имеющем локальную сеть, есть уже вполне устойчивая сетевая СУБД: простенький, но эффективный менеджер записей Btrieve, входивший в состав сетевой операционной системы Novell NetWare. Сооб­разительные разработчики воспользовались этим и создали на базе Btrieve целый ряд АБС третьего поколения.

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

Первые отечественные системы четвертого технологического поколения — на базе профессиональных СУБД — появились почти одновременно с системами второго поколения. В качестве примера можно привести систему «Пирамида» пи­терской фирмы НЕСТ, созданную в 1990 г. Системами четвертого поколения зани­мались фирмы CSBI EE из Санкт-Петербурга, БИС, «ФОРС», «Эскейп-М» и другие.

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

В конце 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. Архитектура построения системы.

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

Процедуры сервера приложений. Сервер приложений организуется средствами Open-Server Sybase. Он может функционировать на том же компьютере, что и сервер данных, но может быть реализован и на другом компьютере. Различают два вида процедур сервера приложений: первые из них отвечают за функционирование системы безопасности и управления доступом, вторые выполняют ту часть прикладных операций, которая неэффективно реализуется средствами сервера данных.

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

Технологическое построение

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

"

Рис.2. Технологическое построение системы.

Можно определить три составляющие системы:

Система безопасности и управления доступом.

Ядро системы.

Прикладная система.

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

Ядро системы — достаточно абстрагированный от предметной области проблемно-ориентированный инструмент. Работа механизмов ядра не зависит от функциональности системы. Ядро включает в себя:

систему учета банковских операций;

систему хранения документов;

транзитную систему.

Система учета выполняет фактический и позиционный учет операций, а также формирует “ограничения” на лицевые счета на базе единой абстрактной модели.

Система хранения документов обеспечивает формализацию и хранение документов предметной области.

Транзитная система осуществляет взаимодействие системы учета с прикладной системой.

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

компоненты поддержки документооборота и выполнения операций;

компоненты справочников и классификаторов;

компоненты представления системы учета в аспекте предметной области.

Прикладная система обеспечивает реализацию объектов и операций предметной области.

Система безопасности и управления доступом

Система безопасности и управлением доступом призвана обеспечить разграничение прав пользователей системы к ее объектам (операциям и данным). Она базируется на сервере данных и использует для управления доступом к объектам БД — таблицам и процедурам — возможности сервера данных. Для проверки возможности выполнения пользовательских процедур, которые защищает система, применяется специализированный сервер защиты. Он реализован в виде сервера приложений.

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

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

Функциональность системы основана на базовых операциях. Предоставляя пользователю набор базовых операций, администратор системы определяет тем самым его доступ. Базовые объекты определяют объектно-ориентированный взгляд на систему. Появляется возможность управлять доступом к объектам, определяя права на их методы, которыми являются элементарные операции. Каждая базовая операция использует какой-либо из методов базового объекта (т.е. какие-либо элементарные операции). Таким образом, доступ пользователя в системе складывается из его прав на базовые операции и объекты.

Рис.3. Объекты управления доступом.

Для обеспечения эффективной работы администратора системы по управлению доступом вводится понятие оргштатного элемента, модуля и способов группировок базовых объектов, базовых операций и самих оргштатных элементов. Дефиниции всех этих понятий представлены в Таблице 1, а схема управления — на Рис.3.

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

Таблица 1

ТЕРМИНЫ И ПОНЯТИЯ, КОТОРЫЕ ИСПОЛЬЗУЮТСЯ
ПРИ РАБОТЕ АДМИНИСТРАТОРА ПО УПРАВЛЕНИЮ ДОСТУПОМ.

Оргштатный элемент	Это “обезличенный” пользователь системы, для которого проводится работа по управлению доступом к операциям и объектам системы. Затем реальному пользователю выдается право быть представленным в системе в виде оргштатного элемента.
Модуль	Это характеристика клиентской части системы, физически объединяющая вызовы базовых операций. Одна базовая операция может входить в несколько модулей.
Обобщенный объект	Логическое объединение группы базовых объектов. Это иерархическая структура, “листьями” которой являются базовые объекты, а “ветвями” — обобщенные объекты различного уровня “вложенности”. При управлении доступом администратор системы манипулирует обобщенными объектами наравне с базовыми объектами.
Обобщенная операция	Логическое объединение группы базовых операций. Это иерархическая структура, “листьями” которой являются базовые операции, а “ветвями” — обобщенные операции различного уровня “вложенности”. При управлении доступом администратор системы манипулирует обобщенными операциями наравне с базовыми операциями.
Оргштатная структура	Логическое объединение группы оргштатных элементов. Это иерархическая структура, “листьями” которой являются оргштатные элементы, а “ветвями” — оргштатные подразделения различного уровня “вложенности”. При управлении доступом администратор системы манипулирует оргштатными структурами наравне с самими оргштатными элементами.

"Ядро системы

Центральное место в ядре системы занимает учетная система. В ее основе — абстрактная модель бухгалтерского учета с основополагающим принципом двойной записи. Основными объектами системы учета являются:

конто;

показатель;

журнал;

проводка.

В терминах бухгалтерской модели конто и показатели являются абстрактными счетами учетной системы.

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

Показатель предназначен для синтетического учета, для группировки аналитики при формировании отчетности и анализа. На внешнем уровне показателям соответствуют счета I—II порядков, разделы Плана счетов ЦБ, символы отчетности различных форм.

Структура показателей и конто строится на основе иерархии неограниченного уровня вложенности.

Журнал — это объединение показателей, имеющих один экономический смысл.

Примерами журналов могут быть главы Плана счетов ЦБ (“Балансовые счета”, “Внебалансовые счета”, “Счета депо”), список символов кассовой отчетности, формы отчетности по Инструкции № 17 и т.д.

Проводки формируют состояния конто — хранящиеся в системе обороты по дебету и кредиту, остаток. Состояния показателей рассчитываются на основе их отношения к конто.

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

осуществлять ведение структуры объектов учетной системы;

организовывать доступ для проведения аудита ко всем счетам и проводкам системы учета независимо от их прикладного применения.

Интерфейс модулей технолога представляет журналы, показатели, конто и проводки в терминах прикладной области.

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

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

Прикладная система

Компонента поддержки документооборота — самая важная в прикладной системе. В ее состав входят: документ, картотека и портфель.

Взгляд на систему обеспечения документооборота достаточно подробно освещен в одноименном разделе статьи В.Чаусова “Концептуальное построение банковской системы” [5].

В нашей статье понятие “папка” заменено на понятие “картотека”. Картотеки (в отличие от папок) имеют некоторые ограничения, в частности:

их количество в системе конечно;

пользователи системы не могут создавать и уничтожать их;

разрешенные перемещения документа из одной картотеки в другую заранее прописываются технологом системы;

обращение к транзитной системе для инициирования проводок в системе учета происходит при перемещении документа из картотеки в картотеку.

Картотека объединяет документы, находящиеся на одной стадии обработки (скажем, лицевые счета картотеки № 2).

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

Взаимодействие прикладной системы с учетной в процессе движения и обработки документа представлено на Рис. 4.

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

"

Рис. 4. Процесс обработки документа.

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

Модули клиентской части и процедуры сервера данных обеспечивают как выполнение операций над документом, так и информационный сервис по документообороту.

Компонента представления учетной системы дает (независимо от документооборота) возможность доступа к системе учета в пределах, необходимых конкретной прикладной подсистеме.

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

Для каждого из этих объектов предусмотрены по две группы программных модулей: одна отвечает за создание и поддержку объектов, другая является модулями использования объектов.

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

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