Организация и управление документооборотом в корпорации (на примере Уфимского филиала ОАО “УРСА Банк”)

3. В-третьих, это информационная  целесообразность. Автоматизаторам  не нужно рассказывать, насколько  полезно иметь единую НСИ во  всех подразделениях банка, насколько  это облегчает решение проблем получения непротиворечивой сводной отчетности по банку, не говоря уже о попытках получить аналитическую картинку [57,18].

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

Что же вкладывается в  понятие единой САБ? Прежде всего, в фундаменте такой системы лежит «сетевой» уровень: некая система доставки информации между подразделениями банка. Она обычно создается еще до того, как поднимается вопрос о создании единой САБ, в качестве почтовой системы (первоначально обычно для доведения до подразделений распоряжений из центра и передачи в центр отчетности). Это может быть система обмена сообщениями через Internet, либо некая корпоративная сеть с использованием телекоммуникационных пакетов вроде «Астры», ProCarry, FTN-мейлеров, либо еще что-то в этом роде. Такая система обычно имеет топологию «звезда» или «дерево» - в зависимости от организационного строение банка, горизонтальные связи между филиалами обычно отсутствуют. На первом этапе создания единой САБ пропускной способности такой почтовой системы обычно оказывается достаточно. Почтовая система оказывается по отношению к единой САБ некой «сетевой подложкой», средством доставки квантов информации между территориально отдаленными модулями единой САБ. То, что такая система не обеспечивает ни гарантированной доставки информации, ни конфиденциальности передаваемой информации значения не имеет.

Поверх «сетевой подложки»  надстраивается прикладное ПО. Если бы система автоматизации в банке  с самого начала строилась по принципу единой САБ, то вопросов по ее функциональности не возникало бы. Просто технология работы банка и технология ее автоматизации изначально строились бы распределенными. Известны примеры, они весьма впечатляющи. Поскольку на практике обычно приходится перестраивать существующую систему, то целесообразно сразу определиться с основными функциями, которые должна выполнять обновленная система. Таких функций три: платежная, информационная, контрольно-фискальная. Платежная функция: система должна обеспечивать оперативное проведение межфилиальных платежей. Информационная функция: система должна обеспечивать сбор полной информации о происходящем в филиалах и доступ к этой информации уполномоченных сотрудников центрального аппарата. Контрольно-фискальная функция: система должна обеспечивать авторизацию всех выполняемых в банке операций, вычленять подозрительные операции и не допускать их выполнения без санкции специально уполномоченного лица [57,19].

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

Рассмотрим организацию  документооборота многофилиального банка  на примере построения платежной  системы банка. Такая система  наиболее характерна для банка, к тому же требования к ней включают в себя практически все требования, предъявляемые к системам документооборота общего назначения, так и специфические требования, значительно усиливающие общепринятые. Далее по тексту теоретические соображения по поводу построения ВПС будут перемежевываться с описанием предлагаемой компанией R-Style Software lab реализации - системы RS-Payment. Они во многом неразделимы, что и понятно: система RS-Payment разработана и развивается под руководством автора этого текста, потому не удивительно, что в ней оказались реализованы представления автора о построении ВПС.

Задачи Внутрибанковской платежной системы [57,23]:

– принять из ОДБ Филиала-отправителя  платеж, возможно, произвести дополнительную верификацию, отправить в Расчетный центр;

– получить в Расчетном  центре платеж от Филиала, проверить  корректность заполнения реквизитов платежа, возможно, проверить правомочность  отправки такого платежа из Филиала (возможно, в ручном режиме);

– межфилиальный внутрибанковский платеж отправить в Филиал-получатель;

– начальный межбанковский  платеж спозиционировать на внешний  корсчет (возможно, в полуавтоматическом режиме), преобразовать в формат соответствующей платежной системы, отправить банку-корреспонденту;

– получить из внешней платежной системы ответный платеж, отправить платеж в Филиал-получатель платежа;

– получить в Филиале-получателе платеж из Расчетного центра, зачислить  получателю средств;

– корректно отразить проводимые операции по счетам бухгалтерского учета согласно принятой бухгалтерской модели;

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

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

Коль скоро все вращается  вокруг сущности «платеж», рассмотрим что понимается под платежом в системе RS-Payment. В терминологии системы, платеж - это электронный документ, имеющий несколько фиксированных полей (код валюты, сумма, код банка и номер счета плательщика и получателя, еще несколько полей, без которых платежный документ не имеет смысла) и некоторое количество дополнительных полей. Дополнительные поля могут содержать данные различных типов и длинны. Система содержит средства для описания форм платежей (одновременно система может оперировать неограниченным количеством различных форм платежей), для платежей каждой формы описывается формат хранения, формат передачи, формат отображения на экране, система открыта для редактирования существующих и добавления новых форм платежей. Каждый платеж уже от «рождения» относится к одной из форм, но, вообще говоря, по мере обработки платеж может поменять форму.

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

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

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

Если прикладной уровень  полностью абстрагирован от реализации транспортного, передав сообщение  в транспортный уровень, он перестает о нем беспокоиться, то реализация транспортного уровня достаточно тесно связана с возможностями, предоставляемыми сетевой подложкой. В настоящее время транспортный уровень системы RS-Payment имеет две возможности для использования сетевой подложки: если сеть предоставляет между двумя конкретными узлами возможность прямого IP-соединения, то транспортный узел использует этот канал для on-line передачи данных (используется протокол TCP). Если такой возможности не имеется, транспортный уровень организовывает обмен данными через файлы определенной структуры. В любом случае, передаваемая информация шифруется средствами внешней криптосистемы (подключаемой по технологии plug-in), и специальные средства, встроенные в транспортный уровень, следят за порядком прохождения информации, повторяют при необходимости отправку потерянного сетевой подложкой или поврежденного в пути сеанса, а также пресекают попытки навязать системе чужеродную информацию.

Интересная особенность  транспортного уровня системы RS-Payment. Так же, как он не монополизирует сетевую подложку, оставляя возможность наряду с информацией ВПС по тем же каналам отправлять и другую информацию, точно так же он сам открыт для использования не только средствами прикладного уровня ВПС, но и другими приложениями. И на информацию, передаваемую таким образом, будут распространяться те же гарантии, что и на информацию собственно ВПС [56,24].

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

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

Рассмотрим пример несколько  упрощенной схемы выполнения начального межфилиального платежа в двухуровневой  платежной системе топологии  «звезда» с использованием бухгалтерской модели «на расхождение».

Таблица 1

Схемы выполнения начального межфилиального платежа

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

В сущности, в приведенной  выше таблице отражен алгоритм распределенного  пошагового выполнения платежа.

Именно на реализации такого алгоритма, быть может, достаточно сложного, и построено функционирование системы RS-Payment [56,23].

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