Автоматизорованная система (АБС) ФОРС

Содержание Документооборот в АБС «Ва-Банк ХL»: межмодульные взаимодействия 3 Банки и электронное взаимодействие организаций-контрагентов 4 Технологии взаимодействия 7 Коммуникации 9 Реализация нового сервиса в RS Audio 10
Библиография 11 Документооборот в АБС «Ва-Банк ХL»: межмодульные взаимодействия При построении АБС, реализующих автоматизацию широкого круга банковских услуг, перед разработчиками неизбежно встает задача организации внутрисистемных каналов передачи данных. Такие каналы обычно используются как для передачи служебной информации, так и для организации внутрисистемного документооборота. В автоматизированной банковской системе компании «ФОРС» «Ва-Банк ХL», разработанной в среде Огасlе, организован единый настраиваемый внутрисистемный канал передачи данных, получивший название интерфейса межмодульных сообщений (ММС). Его функция — поддержка всего внутреннего документооборота, включая генерацию документов (в том числе служебных), их последовательную обработку и доставку адресату в системе. Интегрированная банковская система АБС «Ва-Банк XL» имеет модульную архитектуру. Модули "Ва-Банк XL» поддерживают отдельные бизнес-области банковской деятельности. Они реализованы как независимые клиент —серверные приложения, основанные на единых принципах и разрабатываемые параллельно. Бизнес-области разграничены естественным образом так, что большая часть информационных взаимодействий между программными компонентами остается внутри модуля. Прямые внешние обращения из модуля в модуль практически отсутствуют. Исключением является модуль Ядро содержащий картотеки клиентов, лицевые счета, архив проводок, курсы валют, процентные ставки и прочие справочники, необходимые всем модулям системы. «Ядро» — единственный в системе модуль, объекты которого используются другими модулями непосредственно. Модули в системе «Ва-Банк XI» взаимодействуют с помощью общесистемного механизма ММС. Межмодульные сообщения несут в себе как содержатель­ную бизнес-информацию, на основе которой создаются и изменяются электронные документы в модулях, так и сервисную информацию, необходимую для взаимодействия процедур обработки со стороны модуля-отправителя и модуля-получателя. Эти процедуры обработки в модулях реализованы как хранимые процедуры сервера базы данных. Интерфейс ММС содержит очередь сообщений, набор хранимых процедур для ее обслуживания, а также описание типов межмодульных сообщений, механизмы настройки и динамического исполнения процедур приема и передачи информации. Обычные типы ММС — это платежные документы в формате РКЦ, платежные документы в формате SWIFT, файлы различных форматов и т. д. Структуры данных и базовые процедуры исполнения обработки ММС расположены в ядре системы и доступны для обращения из любого модуля Ва-Банк XL, а реализованная гибкая настройка и динамическое исполнение процедур обработки ММС позволяет легко решать задачи конфигурирования и пополнения новыми функциональными модулями версии системы, установленные в банках-заказчиках.
Банки и электронное
взаимодействие организаций-контрагентов Будучи профессиональным разработчиком финансового программного обеспечения, компания RStyle Softlab внимательно следит за потребностями банковского сообщества. Постоянный мониторинг позволил нам сделать целый ряд наблюдений, касающихся взаимоотношений банков и их клиентов. Одним из них мне хотелось бы поделиться с читателями. Как известно, в настоящее время растет интерес банков к всевозможным электронным торговым площадкам, размещенным в Интернете, что связано в первую очередь с пожеланиями банковских клиентов, которые видят в таких структурах удобное средство ведения бизнеса. В то же время исследования показывают, что существует некое противоречие между держателями площадок, желающими завлечь к себе как можно большее число клиентов (как продавцов, так и покупателей) и в дальнейшем не отпускать их, и самих клиентов, которые хотят покупать и про­давать там, где это их устраивает, и тогда, когда им это нужно. К тому же свободная от всяческих границ Всемирная сеть напрочь отвергает идею ограничения деловой активности рамками какого-либо одного ресурса. Ведь реальный торговый ряд и виртуальная торговая площадка имеют важнейшее отличие — переместиться с одного Интернет-ресурса на другой гораздо легче, чем из Москвы поехать за товаром на Нижегородскую ярмарку, а потом, не договорившись с продавцами, завернуть, скажем, в Ростов. Более пристальное рассмотрение этого противоречия доказывает, что в целом участники торгов не настолько заинтересованы в полном цикле сервиса на площадке, чтобы предпочесть приверженность к одной-единственной из них свободе виртуального шопинга. Тем не менее организация торговых площадок — это очень полезное начинание, и в недалеком будущем их преимущества будут оценены в полной мере. На обсуждении недостатков и достоинств этого сервиса можно защитить десяток диссертаций, но в этой статье хотелось бы затронуть наиболее значимый аспект, определяющий интерес клиентов банка к подобным структурам. Даже если произвести беглый анализ интересов клиентов универсальной (не вертикальной, не отраслевой и не корпоративной) торговой площадки, наглядно видно, что большинство ее участников, которые время от времени либо покупают какой-то товар, либо продают другой, заинтересованы не только и не столько в технических преимуществах торговли, таких как: · каталог представлен­ных товаров и услуг (его эффективно использовать для получения стартовой информации, а затем, в силу ряда причин, лучше договориться по телефону или при личной встрече); · Механизм гарантированной оплаты сделок на площадке (к слову сказать, он не очень распространен и не вполне отлажен). Напротив — в первую очередь им нужна такая простая и несложно реализуемая, казалось бы, услуга, как оперативное оповещение получателя платежа (далее — «поставщик») о выдаче распоряжения на пе­ревод денег на его счет. Именно эти коммуникации между поставщиком и потребителем становятся главным фактором привлечения сторон на торговую площадку. Удобная форма оповещения здесь отнюдь не главное — гораздо важнее его оперативность, так как покупатель зачастую хочет получить товар немедленно, а поставщик не против как можно быстрее освободить собственный склад. Кстати, стремление ускорить движение товара можно наглядно увидеть на примере предприятий, занятых активной производственной деятельностью и контактирующих с большим числом контрагентов. Наши выводы подтверждают и банковские специалисты. Клиенты, подолгу работающие со своими контрагентами (как правило, основной набор контрагентов в любой фирме стабилен, случаи продажи сегодня самолетов, а завтра повидла нетипичны), в пер­вую очередь заинтересованы в оперативном информировании о факте осуществлений банковского перевода в адрес фирмы. Причем — и это хотелось бы отметить особо — информирование это должно исходить от банка (либо подтверждаться банком) как от третьей, независимой стороны, имеющей пусть внешнее, но отношение к сделке. С той же целью при заключении сделки прибегают к помощи свидетелей — независимых субъектов, владеющих определенной важной информацией о событии.
Итак, роль банков в таком процессе очевидна — ему будут доверять обе стороны, к тому же он располагает максимально оперативными и достоверными сведениями о движении средств на счету своего клиента. Остается открытым вопрос, захочет ли банк взваливать на себя дополнительную работу по реализации таких услуг либо предпочтет рекомендовать своим клиентам некую внешнюю торговую площадку. В первом случае банк должен самостоятельно выстроить некую коммуникативную среду между продавцами и покупателями, а во втором — осуществить плотную интеграцию с теми торговыми площадками, которые он выберет. Решение зависит от многих факторов, один из которых — технологический — хотелось бы рассмотреть подробно.

Технологиявзаимодействия Для начала опишем, как обычно происходит процесс оплаты и последующих коммуникаций контрагентов. Покупатель находит поставщика и договаривается о сделке (форма договора в данном случае неважна). Он же в соответствии с выставленным счетом на оплату (лихие времена начала 90-х миновали, и теперь уже не надо ехать в офис фирмы для того, чтобы убедиться, существует ли она, — достаточно запросить счет по факсу) оформляет платежное поручение и относит его в свой банк, который устанавливает на поступивший документ штамп о приеме и чуть позже — штамп об исполнении поручения. Наконец, банк предоставляет покупателю выписку по счету, в которой заверено списание указанной суммы. В зависимости от степени дружественности и проверенности отношений поставщика и потребителя, отгрузка товаров происходит по факту предоставления платежки с отметкой о приеме документа банком либо с отметкой об исполнении. И то и другое может передаваться по факсу. Если в движении средств происходит какой-то сбой, стороны инспектируют банковские выписки с целью найти перечисленную сумму. Чаще всего эта методика используется в организациях, отправляющих разовые платежи различным контрагентам. Для крупных и постоянных постав­щиков и потребителей могут применяться иные схемы, например сверка объемов поставок и сумм платежей через определенный период (скажем, раз в квартал). Несложно заметить, что процесс изобилует вполне рутинными операциями наподобие «отправить выписку по факсу», «отнести документ в банк». В итоге половина рабочего дня бухгалтера небольшой фирмы уходит на подобные разъезды и рассылки. И по такой схеме сейчас функционирует подавляющее число небольших организаций! К счастью, системы класса «Клиент—Банк» не­сколько облегчили труд сотрудников бухгалтерий — в банк можно уже не ездить, а отправлять платежи и получать выписки по электронной почте. Но на сле­дующем этапе все же приходится посетить банк, чтобы забрать платежное поручение со штампом и подписью, дабы поскорее подтвердить оплату и получить товар. Тем самым эффект от применения полезной программы фактически сведен на нет. Можно ли реализовать оповещение поставщиков о перечислении им средств потребителей с помощью той же системы «Клиент—Банк»? Да, но только в том случае, если у поставщика установлена такая же программа с предусмотренным сервисом оповещения. Но это, скорее, исключение из правил. Нельзя же, в конце концов, у каждого поставщика установить все программы «Клиент—Банка», с которыми могут работать его потребители! Системы класса «Интернет—Клиент» зарекомендовали себя как более универсальные решения. Впрочем, такая характеристика относится лишь к тем из них, которые действительно являются «тонкими» и используют стандартный НТМL-интерфейс без установки на компьютер поставщика каких-либо дополнительных программ, будь то АсtiveХ-компоненты или Java-аплеты (и те, и другие — разновидность так называемых толстых программ «Клиент—Банк»). И поскольку большинство существующих разработок «Клиент—Банк» такой сервис не реализуют, за него берутся торговые площадки, становясь не только деловыми, но и технологическими посредниками между потребителями и поставщиками товаров и услуг. Очевидно, что как только банки начнут использовать некоторые несложные механизмы оповещений, значительное число их клиентов вообще перестанет обращаться к сервису торговых площадок. Ну не нужен фирме из десяти человек, срочно заказывающей тонер для единственного принтера, механизм гарантирования сделок!






Коммуникации Что же требуется для поддержания необходимых коммуникаций между поставщиками и потребителями в обход сервиса торговых площадок? Как уже было сказано выше, традиционные системы «Клиент—Банк» здесь практически бессильны. Если же взглянуть повнимательнее на системы класса «Интернет—Клиент—банка», то здесь ситуация следующая. Поставщик хочет получать оповещения об оплате от всех своих потребителей с минимальными для себя усилиями, иначе он просто откажется от этой идеи и будет дожидаться реального зачисления средств на свой счет. Устанавливать для этого специальное программное обеспечение поставщика уж точно не заставишь, поэтому остается уповать на возможности стандартного офисного ПО. Неоспоримое преимущество здесь приобретают действительно «тонкие» НТМL-системы, для которых достаточно стандартного браузера и встроенных в операционную систему криптографических средств, обеспечивающих безопасность. Схема работы при этом должна быть такой: покупатель с помощью системы удаленного обслуживания осуществляет платеж в банке, затем формирует или выбирает временный пароль для получения доступа к конкретному документу или выписке и передает этот пароль поставщику (это можно сделать прямо в процессе оформления платежа, воспользовавшись электронной почтой или SMS). Поставщик товара входит в Интернет-систему банка по полученному паролю (разумеется, с установленным SSL-соединеиием) и видит на своем экране интересующий его документ — например, выписку с подписью банка (при этом доступ к другой информации для него закрыт). Тот факт, что информация верна, подтверждается источником ее получения — официальным сайтом банка. Кроме того, документ заверен подписью. Можно отправить такой документ с электронной подписью банка по электронной почте. В сравнении с получением документа непосредственно с сайта бан­ка такой метод выглядит менее надежным, и наверня­ка возникнут проблемы с совместимостью электронно-цифровых подписей. Но как вариант и такое уведомление правомочно. На первый взгляд, процесс кажется немного заорганизованным с технологической точки зрения, но его исполнение вполне реально и действенно. Аналогичный режим планируется реализовать в рамках комплекса удаленного банковского обслуживания Inter- Bank.
РеализацияновогосервисавRS-Аudio Однако, спустившись с небес на землю, мы обнаруживаем, что роскошь работы в Интернете на просторах нашей страны доступна далеко не всем и не везде. Сказываются не только проблемы со связью, но и банальная нехватка квалификации сотрудников или да­же невозможность найти специалиста для начальной настройки Интернет-соединения. Вместе с тем в рек­визитах большинства организаций можно увидеть факсимильный номер — найти организацию без факс-аппарата сейчас практически невозможно. Этот способ связи технологичен, прост и привычен всем. Почему бы не использовать его для оповещения поставщика?
Именно так мы и поступили. В одной из новых систем R-Style Softlab – RS -Audio — мы постарались максимально облегчить работу всех участников взаиморасчетов. Так, например, реализована возможность отправки информации о платежах на факс контрагента. Теперь и плательщик, и получатель могут оперативно предоставлять друг другу информацию, подтверждающую либо опровергающую факт платежа. Причем для этого достаточно наличия обычного кнопочного телефонного аппарата у отправителя и факсимильного аппарата у получателя информации. Даже находясь в командировке, бизнесмен с любого ближайшего телефона может прослушать отчет о движении денег по своему счету, а также заказать отправ­ку информации своим контрагентам по факсу. Соответственно контрагент при возникновении спорной ситуации сможет предоставить отправителю средств выписки со своего счета, подтверждающие, что деньги еще не получены. Пространственно-временных ограничений такая технология общения не имеет — ее могут осуществлять сколь угодно удаленные предприятия в любое время суток. Требования к коммуникационной аппаратуре при этом не превосходят требований к оснащению даже самого небольшого со­временного офиса, а польза весьма ощутима.
Остается добавить, что для удобства контрагентов пересылаемая информация может заверяться штампом банка. Тогда пересылаемые документы будут выглядеть точно так же, как и их бумажные аналоги. Помимо этого, в RS-Audio реализован режим, позволяющий искать интересующий клиента платеж по телефону. Как известно, зачастую фирмы ждут прихода какого-то конкретного, важного по тем или иным соображениям платежа. В этом случае их сотрудники часто звонят в банк либо регулярно заказывают выписки через системы «Клиент—Банк». В RS-Studio предусмотрен поиск конкретного платежа — для этого клиент просто указывает разыскиваемую сумму и длительность периода, за который надо произвести поиск, и в ответ либо получает отчет со всеми подходящими по описанию платежами в факсимильной форме, либо прослушивает их в голосовом исполнении. Таким образом, для получения максимально полной информации затрачивается минимум усилий. Подводя итог, отметим, что выяснение финансовых отношений с контрагентами по телефону и факсу уже не кажется фантастичным. Подкупает простота и де­шевизна такой технологии — банку не потребуется приобретать дорогостоящие телефонные средства на­подобие многоканальных телефонных плат — достаточно обычного голосового факс-модема. А раз затраты банка на развертывание и дальнейшее обслужива­ние системы невелики, то и стоимость ее использова­ния для клиентов будет невысокой. Выходит, что сервис оповещения не только исключительно удобен, но и дешев для всех заинтересованных сторон. Так что надо полагать, что в скором времени он будет широко востребован как банками, так и их клиентами.
БИБЛИОГРАФИЯ Журнал “Банковские технологии”. 07/1998 1) Клиринговые расчеты, с. 82 2) Микропроцессорные карточки для России, с. 87 08/1998 3) Криптография в электронном документообороте, с. 68 4) Открытые АБС, с. 38 5) Семейство архитектур клиент-сервер. Преимущества и недостатки, с. 42 6) АБС и розничные услуги: комплексный подход, с. 48 7) Удаленное обслуживание: концепция и реализация, с. 54 8) Криптография в электронном документообороте, с. 68 9) BS7799. Информационная безопасность начинается с менеджмента, с. 73 10) Автоматизация торговли акциями, с. 80 11) Региональные системы безналичных платежей, с. 92 12) Аппаратная защита электронных платежей, с. 97 13) АБС-рейтинги и объективная реальность с. 105 09/1998 14) Телекоммуникации на “карточном рынке”, с. 52 15) Системы управления ресурсами банка, с. 60 16) Идентификация по клавиатурному почерку, с. 68 17) Банковские услуги через Интернет, с. 95 10/1998 18) Электронные кассиры в банке, с. 22 19) Биометрия: новые технологии идентификации личности, с. 35 20) Новая система электронных расчетов Расчетной палаты ММВБ 21) Кабельные системы категории 6, с. 51 11-12/1998 22) Информационные технологии на банковском рынке, с. 14 23) Банковский CALL-центр как средство сервиса и маркетинга, с. 29 24) Обзор рынка зарубежных АБС, с. 54 25) Основные возможности и характеристики торгово-депозитарной системы ММВБ, с. 87 12/ 1999 26) Зарубежные рынки и антропологии Интернет - трейдинга, с. 43 Специализация поставщиков финансовой информации, сайты специального назначения, тенденции развития информационного бизнеса. Электронные Коммуникационные Сети (ECN) – Electronic Communication Network. 27) APACS – основа интегральной системы безопасности, с. 52 Программный комплекс, разработанный отечественной компанией “ААМ Системз”, является интеллектуальной основой Интегрированной Системы Безопасности (ИСБ), строящейся на основе оборудования APOLLO (США). Основные модификации APACS. Приложения “Конфигуратор”, “Картотека” “Учет рабочего времени”. 28) Мобильные банковские услуги, с. 65 WAP – протокол мобильных приложений для банков, технология реализации (используется WAP-шлюз); лидеры использования мобильных услуг. 12/ 2000 29) Анализ состояния банка с помощью средств автоматизации, с. 31 30) Автоматизация управленческого учета, с. 36 31) Автоматизированные банковские системы 32) Автоматизация банковского обслуживания юридических лиц – Клиент-Банк, ABBYY Fine Reader Банк. 12/ 2001 33) Технологии ABBYY в российских банках, с. 68. Система автоматического ввода платежных документов Fine Reader Банк. Интеграция с наиболее распространенными БИС и СУБД. 34) Многопортфельное управление, с. 54. Портфель, принцип отбора стратегий, класс стратегий, система MultiPortfolio. 6/2002 33) Электронные банковские услуги, с. 20. 7-8/2002 36) Выбор АБС, с. 27. Анализ целесообразности (Feasibility Study), функциональные требования (Functional Requirements), организация процесса выбора системы (Package Selection Framework), проведение тендера (Tender execution). 37) Реализация обработки SWIFT-сообщений по ценным бумагам в АБС “Ва-Банк XL”, с. 46. SWIFT – международная сеть обмена данными между финансовыми организациями. Соответствие стандарту ISO 15022 .Основные принципы обработки сообщений по ценным бумагам в АБС “Ва-Банк XL”. Переход к новому стандарту ISO 15022 XML. 38) Автоматизация налогового учета в кредитных организациях, с. 52. Проблемы и варианты решения автоматизации налогового учета. Как параллельно ведется бухгалтерский и налоговый учет в программном продукте фирмы “Кворум” “Налоговый учет” – всесторонняя автоматизация. В системе присутствует возможность сверки налогового и бухгалтерского учетов в любой момент времени. 9/2002 34) Новый взгляд на В2В и В2С от “Киберплат.ком”, с. 52. Интернет-компания “Киберплат.ком” объявила о запуске универсальной платежной схемы В2В2С, построенной на основе собственной технологии Cyber Check. (Преимущество: независимость от механизма приема платежей).
10/2002 35) Видеоконференц-связь, с. 36. Компания North -West Group – оптовый дистрибьютор оборудования Avaya, Ericsson, Alcatel, Siemens, Nokia, Polycom - лидер этой отрасли, 70% общего выпуска. 36) Что такое Портал управления знаниями, с. 32. Информационно-техническое решение, использующее технологии корпоративного информационного портала для управления взаимодействием на уровне знаний.
37) Автоматизация розничных операций в многофилиальном банке, с. 15. Требования к технологии обслуживания пластиковых карт, трехуровневая система обслуживания розничных операций. Классический пример – INVOCARD; необходимость интеграции бэк-офиса и ритейла. Головной банк и филиалы: преимущества работы с единой базы данных. Особености обслуживания банковских операций. 38) “Мелочи” банковской репутации, с. 26. Выбор почтовой системы. Удаленное банковское обслуживание, требования к корпоративной сети. 39) Ascential Data Stage XE – построение хранилищ данных. И не только . с. 56. Программный продукт Data Stage XE компании Ascential Software. В его состав входят модуль Meta Stage (метаданные – это данные о данных). Модуль Quality Manager – позволяет проводить аудит исходных данных и контролировать данные в приемниках; улучшает процесс преобразования. 11/2002 40) Банки и электронное взаимодействие организаций – контрагентов, с. 39. Разработка финансового программного обеспечения компанией R-Style Softlab. Система RS-Audio – автоматизация работы всех участников взаиморасчетов. 41) Документооборот в АБС “Ва-Банк XL”, c. 28. ПО разработано в среде Oracle. Организован единый настраиваемый внутрисистемный канал передачи данных, получивший название интерфейса межмодульных сообщений (ММС). Основой ММС является очередь межмодульных сообщений, выполненная в виде двухуровневой табличной структуры (“мастер - деталь” в терминологии Oracle). 12/2002 42) Наша система FORPOST максимально ориентирована на бизнес банков, с. 38. Первые инсталяции в России датируются 1992 г. Система базируется на ОС Linux, обязательна связка СУБД Oracle – АБС FORPOST. Установка отдельных модулей невозможна. Система полностью устанавливается на 6-12 серверах; для сервера банка на 800 пользователей характеристики Intel Pentium 1,3 GHz CPU*8, RAM10 Gb, HDD 30 Gb.