Автоматизация банковской системы

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

В большинстве случаев при работе с ИБС «STEM» бывает достаточно выполнения запроса «Получить все документы, для которых не выполнена заданная операция». Например, можно получить все выписанные кассовые документы, не прошедшие через кассира. В результате администратор получает доступ непосредственно к искомым документам (с указанием причины не обработки по каждому) и может принять решение по каждому отдельно или по всем. Широко применяемый сегодня в банках метод подсчета контрольных сумм дает интегрированный результат. Применяя этот метод для рассмотренного выше примера, мы бы получили информацию о том, что контрольная сумма выписанных кассовых документов не равна контрольной сумме прошедших через кассу документов. Отметим, что результат такого контроля не позволяет сразу найти конкретные документы.

Отдельно рассмотрим случай отрицательного ответа на подобный запрос. Например, если дан отрицательный ответ на запрос «Получить документы, для которых не выполнено проводка», то администратор может быть уверен, что все документы проведены. Таким же образом можно удостовериться в том, что по всем внешним документам сформированы платежные сообщения, или в том, что на все отправленные платежные сообщения получены квитанции, и т.д.

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

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

Таким образом, система располагает всем необходимым для реализации корректного метода отката обработки как по завершенным, так и по незавершенным технологическим процессам.

Возможность отката технологических процессов совместно с независимостью от даты ИБС «STEM», о которой говорилось во второй части (II), позволяет решать задачи типа "Play What if ...". При этом сотрудник банка может совершить операцию и посмотреть, как эта операция в будущем, например через месяц, отразится на состоянии банка. После завершения эксперимента, операция может быть отменена.

Вернемся к платежным документам ИБС «STEM». При создании нового документа, независимо от того, какой прикладной процесс его создает (ручной ввод или  обслуживание коммуникационных каналов, макрогенератор, импорт и т.д.), система строит для него уникальный технологический процесс.

Технологический процесс для документа строится на основе базовых технологий, результатов анализа документа и параметров настройки системы. В «STEM» технологический процесс является виртуальным методом для платежного документа.

Особую роль в системе играют базовые технологии, представляющие собой субъективные технологические знания, которые хранятся в виде данных. Таким образом, «STEM», с технологической точки зрения, является открытой для пользователя системой.

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

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

В «STEM» включены многофункциональные обработчики, на базе которых пользователи могут самостоятельно строить различные технологические операции. Кроме того, если это необходимо, дополнительные обработчики могут быть дописаны на PROGRESS 4GL  с использованием специальных соглашений.

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

Разберем подробнее работу с универсальными обработчиками. Тривиальным является пустой обработчик — процедура «NUL», которая ничего не делает. Создадим на основе этой процедуры ручную операцию «Виза на отправку платежного сообщения». Эта операция ничего с документом не делает, но важно само наличие этой операции в технологическом процессе и ее влияние на другие операции. Теперь можно сказать, что операция «Отправка платежного сообщения» выполняется только после выполнения операции «Виза на отправку платежного сообщения» и дать право на выполнение операции «Виза...» определенному сотруднику или группе.

Есть еще один очень интересный момент. Предположим, что некоторый банк достаточно долго и успешно работал на ИБС «STEM». В этом случае технологическая информация, содержащаяся в системе этого банка, приобретает самостоятельную ценность. Она представляет собой проверенные практикой знания. В этом случае технологическая информация в ИБС «STEM» может быть перенесена из одной копии системы в другую. Например, банк может передать эту информацию своему филиалу.

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

Заключение

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

В начале 90-х годов, в момент наиболее активного спроса на продукцию комплексной автоматизации банков, большинство пользователей довольно слабо предполагали себе, какой на самом деле должна быть банковская система. Именно тогда и появились простые системы, концепция построения которых была жестко ориентирована на "проводку" как основную структурную единицу. С точки зрения сервисных возможностей системы оставляли желать много лучшего, а об их надежности и говорить не приходится, ведь создавались они почти "на коленке", с использованием в качестве СУБД FOXPRO, dBase, Clipper или Btricte. Естественно, подход к задаче именно с такой точки зрения - универсальные средства реализации, относительная простота задачи (большинство банков требовали от системы только сам минимум), неготовность заказчика к более сложной постановке задачи - и привел к тому, что многие банки взялись за самостоятельную разработку, благо доходность бизнеса позволяла.

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

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

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

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

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

43