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

Однако, с повсеместной автоматизацией банковских учреждений; с появлением понятия «электронный документ», и, соответственно, возможности оперативно и конфиденциально передавать банковские документы между территориально отдаленными подразделениями банка; с повсеместным вхождением в обиход понятия «система электронных платежей» и, соответственно, с отказом от сопровождения платежа бумажным документом - с появлением этих новых факторов автономность филиала перестала быть неизбежностью и стала лишь общепринятой практикой. Что, впрочем, тоже немало [56,19].

Банкир - профессиональный консерватор. По определению. Для банкира появление новой возможности - само по себе отнюдь не повод отказываться от проверенной, «накатанной» технологии. Для этого нужны веские основания. Есть ли веские основания отказываться от привычной автономности балансового банковского подразделения?

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

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

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].

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

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

Во-первых, это топология информационной модели. Чаще всего встречается топология «звезда» (расчетный центр и филиалы, работающие с РЦ, без горизонтальных связей). Чуть менее распространена топология «дерево» (большой банк, три или более уровня «вертикального» подчинения, без горизонтальных и «наклонных» связей). Еще реже встречается топология «блин» (связь всех филиалов «каждый с каждым») или комбинация из топологий «блин» и «дерево» в каком-либо варианте («блин» региональных дирекций со «звездой» в каждом регионе, например). Топология платежной системы обычно повторяет топологию организационного построения банка, каждый банк выбирает свой вариант [57,21].

Во-вторых, это бухгалтерская модель. Есть две классические модели ведения корсчетом - это модель «на схождение» и модель «на расхождение». Работа «на схождение» подразумевает, что проводка по счету НОСТРО делается немедленно по получению оповещения о проводке по счету ЛОРО. Такая модель в реализации может иметь два варианта: либо в момент отправки платежа сумма списывается с клиентского счета и зачисляется на некоторый транзитный счет, а по получению подтверждения от корреспондента выполняется вторая проводка - списание средств с транзитного счета на счет НОСТРО; либо отправка платежа корреспонденту не сопровождается списанием средств со счета клиента вовсе, а эти средства блокируются на счете другим образом, и тогда после получения подтверждения от корреспондента выполняется сразу списание с клиентского счета на счет НОСТРО. Вторая модель - работа «на расхождение». Она предполагает выполнение проводки на счет НОСТРО в момент отправки платежа корреспондента, но требует ведения «ведомости расхождений» для учета реального положения вещей, к тому же требуется выполнение некоторых действий при закрытии/открытии опердня для недопущения «разрыва корсчетов» на конец дня. Каждая из моделей (и их комбинаций и разновидностей) имеет свои преимущества и недостатки, выбор бухгалтерской модели - исключительная прерогатива банка.

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

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

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

Глава 2. Анализ организации управления документооборотом в ОАО «УРСА Банк»