Современные банковские автоматизированные системы (стр. 3 из 8)
В этой ситуации некоторые банки искренне надеются, что «все рассосется», и каким-то чудодейственным образом переход на новый План счетов будет сдвинут с 1 января 1998 г. на какой-то неопределенный срок. Ассоциация российских банков даже обратилась в Банк России с просьбой перенести переход на начало второго квартала(!). Не дай Бог, если эта просьба будет удовлетворена. Тогда к организационным сложностям перехода добавятся чисто технические, поскольку — и это достаточно очевидно — всякие изменения в бухгалтерском учете гораздо легче ввести с начала года, чем с начала квартала.
Новый план счетов и АБС
Необходимо отметить, что переход на новый План счетов бухгалтерского учета потребует обязательной замены или модернизации АБС практически во всех отечественных банках. Дело в том, что изменяется не только План счетов, но и сама методология бухгалтерского учета, причем в нормативных документах ЦБ РФ некоторые функции в обязательном порядке возлагаются на АБС. Почти во всех системах автоматизации, которые сегодня работают в наших банках, этих функций просто-напросто нет. Поэтому современная ситуация на рынке напоминает ту, которая сложилась в 1992 г., когда число банков стремительно росло, и фирмы-разработчики не успевали удовлетворять спрос на специализированные банковские программные продукты.
Неизбежен передел рынка АБС: с него уже ушли некоторые фирмы, например «АСОФТ» (не путать с «АСофт», которая благополучно продолжает существовать) или «VIMCOM». По-видимому, понесут некоторые потери такие заслуженные разработчики, как «Инверсия», «ПрограмБанк», «ЛИМ», чьи DOS-комплексы в некоторых банках будут заменены на системы третьего поколения — и вовсе не обязательно тех же самых фирм. Ожидается, что самые большие «убытки» понесут собственные программные разработки банков.
Целый ряд опросов, проведенных журналом «Банковские технологии», показал парадоксальную картину: среди банков-респондентов, имеющих АБС собственной разработки, довольных этой АБС оказалось значительно меньше, чем среди тех, кто работает на «фирменной» АБС. Объясняется это просто: во-первых, собственные системы в большинстве случаев выполнялись на тех же FoxPro или Clipper; во-вторых, коллективы разработчиков, которых могут позволить держать у себя в штате банки, весьма немногочисленны; в-третьих, разработка ведется по принципу «латания дыр», что исключает системный подход и нормальное взаимодействие отдельных модулей. «Доморощенные» АБС очень трудно, да и практически невозможно, подвергнуть серьезной модернизации, так как нормальная документация проекта обычно не ведется. Именно такие АБС скорее всего потребуют замены. Если какие-то банки еще питают иллюзии, что им удастся «довести до ума» подобную разработку собственными силами и в срок, и поэтому тянут с решением о переходе на АБС, созданную внешними фирмами, то их ожидают большие разочарования.
Совершенно очевидно, что многие банки будут вынуждены «менять коней на переправе», так как имеющиеся у них АБС неадекватны, и любые попытки как-то удержаться на старой платформе приведут к большим потерям. В этом случае следует помнить одно: переход на новый План счетов будет успешным только там, где вовремя проведена тщательная его организационная подготовка (жаль только, что методичность и скрупулезность не свойственны нашему национальному характеру). Руководство банка должно было уже в октябре составить и утвердить детальный план перехода, в котором следует четко распределить обязанности и ответственность подразделений и должностных лиц. Этот план должен быть расписан по неделям, а с декабря — по дням, с соответствующей оперативной отчетностью.
Чтобы более нагляднее представить, что такое современная АБС, постараемся более подробно разобрать ее строение.
Технологическое построение АБС описывает группировку программных модулей и процессы, происходящие в ходе функционирования системы. Суть части этих процессов определяют абстрактные механизмы, лежащие в основе реализации конкретных прикладных компонент системы. Такие механизмы составляют технологическое ядро системы.
Архитектурное построение
Вся система состоит из трех компонентов:
1) клиентской части системы;
2) объектов сервера данных;
3) процедур сервера приложений.
Клиентская часть системы обеспечивает взаимодействие пользователя с системой. Никакой обработки данных в клиентской части не происходит. Ее назначение сводится к тому, чтобы принять от пользователя запрос на выполнение операции системы и необходимые для выполнения этого запроса данные. После того, как запрос реализован, клиентская часть дает пользователю возможность ознакомиться с результатами выполнения операции.
Объекты сервера данных являются центральной частью системы. Здесь хранятся все данные системы и процедуры, обеспечивающие выполнение ее операций. Хранимые процедуры получают запрос от клиентской части на выполнение операций и подготавливают для нее результаты своей работы. Для выполнения некоторых специфических операций хранимые процедуры могут вызывать процедуры сервера приложений.
На сервере приложенией выполняются специализированные AS-процедуры, которые вызываются по запросам от процедур сервера данных.
Процедуры сервера приложений обеспечивают функционирование системы безопасности и управления доступом, а также выполняют ту часть прикладных операций, для которой реализация средствами сервера данных неэффективна. AS-процедуры могут обращаться и к объектам сервера данных, если это необходимо для их работы.
Клиентская часть системы. Основное назначение клиентской части системы — обеспечить взаимодействие пользователя с системой, предполагающее организацию интерфейса пользователя (отображение и обработка событий) и связь с сервером данных (Manager SQL).
Интерфейс пользователя состоит из процедур отображения результатов работы системы, представленных в виде экранных форм или отчетов, а также из процедур обработки событий, возникающих в результате действий пользователя или по сообщениям сервера данных.
Объекты сервера данных. Объекты сервера данных — это таблицы и процедуры. По своему назначению они разделяются на системные (в контексте банковской системы, а не базы данных) и прикладные.
Системные объекты реализуют задачи “секретности” и управления доступом (этим правом обладает только уполномоченный оператор — так называемый “офицер безопасности”).
Доступ к прикладным объектам клиентов возможен только через узкую “щель”, определенную системой безопасности. Система построена так, что все функции, необходимые клиенту, реализуются через вызов хранимых процедур. Последние надежно защищены системой управления доступом, и поэтому давать разрешение пользователю на использование таблиц нет необходимости. Иначе пришлось бы заботиться о том, кому из персонала банка следует передать таблицу для выполнения определенных действий — при этом о доступе к конкретным записям (“сайтам”) речь не могла бы идти вообще.
При вызове клиентом пользовательских процедур (объектов, представляющих для системы безопасности основной интерес) сразу же происходит обращение к серверу защиты (он реализуется как сервер приложений). При получении соответствующего разрешения выполнение процедур продолжается. В этом и заключается сущность взаимодействия клиента с сервером данных под надзором системы безопасности. Остальные процедуры (т.е. те, которые не вызываются клиентом) не связаны с системой безопасности, поскольку они защищаются средствами сервера данных (Рис. 1).
