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