1.1.2.2. Развитие автоматизированных систем дистанционного (удаленного) управления счетом

В сфере технологий определяющим фактором является Internet. Протоколы TCP/IP, как локомотив, увлекают за собой другие информационные технологии: электронную почту, базы данных, операционные системы, системы мультимедиа и многое другое.

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

Типовая услуга осуществления электронных платежей

Так выглядит процесс совершения покупки какого-либо товара или услуги в традиционной "бумажной" технологии.

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

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

3. Бухгалтерия готовит платежное поручение и передает его в банк.

4. Банк берет на себя обязательства перечислить необходимую сумму на счет продавца товара или услуги и в подтверждение этого оформляет квитанцию об оплате.

5. Организация-покупатель представляет квитанцию об оплате продавцу, на основании ее получает товар и соответствующим образом оформляет факт получения товара, например, ставит его на баланс организации.    Системы обмена электронными документами между организацией и банком успешно существуют уже много лет. Как правило, построение инфраструктуры для таких систем осуществлялось банками: большинство организаций не могли самостоятельно сформировать необходимую инфраструктуру для обмена сообщениями с партнерами.    До недавнего времени возможность обмена электронными документами между покупателем и продавцом отсутствовала. Сейчас организации активно подключаются к Internet, и ситуация стала меняться. Чтобы понять, как осуществляется обмен электронными документами в организациях, классифицируем их по двум признакам: использование систем "клиент-банк" и подключение к сети Internet.

1. Первая группа - организации, не имеющие ни доступа в Internet, ни системы "клиент-банк". Такие организации могут вообще не использовать в своей работе компьютеры, либо использовать компьютеры, не объединенные в сеть, либо использовать только локальную сеть. Для этой группы автоматизация, в лучшем случае, ограничится подготовкой и печатью документов на компьютере. Эту группу мы рассматривать не будем.

2. Вторая группа включает организации, не использующие системы "клиент-банк", но работающие с Internet. Эта группа не столь малочисленна. Неиспользование систем "клиент-банк" определяется, как правило, тем, что либо банк не предоставляет такой услуги, либо пользователя не удовлетворяет ее качество.

3. Третья группа - организации, не имеющие доступ к сети Internet (или не использующие Internet для обмена документами с партнерами), но использующие систему "клиент-банк". Эта группа включает значительную часть всех пользователей таких систем. Сейчас, оформляя сделку купли-продажи, после получения оригинала или "факсовой" копии счета сотрудник организации из этой группы должен осуществлять ручной ввод платежного поручения в систему "клиент-банк". После получения банком платежного поручения формируется квитанция об оплате. Для получения товара покупателю недостаточно распечатать подготовленную в системе "клиент-банк" квитанцию. Товар будет отпущен продавцом только на основании копии платежного поручения, заверенного банком.   Организации из третьей группы располагают как минимум одним персональным компьютером и модемом. Это означает, что они имеют необходимую техническую базу для того, чтобы полностью отказаться от традиционной "бумажной" технологии, при условии появления программных средств электронного документооборота.

4. Четвертая группа - организации, осуществляющие через Internet обмен электронными документами с партнерами и использующие системы "клиент-банк". Зачастую это достаточно крупные организации, имеющие несколько банковских счетов в различных банках. Технология работы в организациях этой группы практически такая же, как в организациях третьей группы. Получив счет (даже если он получен по электронной почте или с Web-сервера), сотрудник организации будет вынужден вручную ввести его в систему документооборота организации. Далее электронный документ проделает положенный ему путь и попадет в бухгалтерию. Там он, скорее всего, будет повторно введен в систему "клиент-банк". Далее процедура оформления платежа и получения товара или услуги будет та же, что и для организаций из третьей группы. Подготовленная системой "клиент-банк" квитанция не будет восприниматься продавцом в качестве подтверждения платежа.    Главным недостатком систем электронных платежей является то, что на сегодняшний день они не способны обеспечить полный цикл традиционного документооборота. Для перехода от "бумажных" технологий к электронным необходима организация единой системы взаимодействий между тремя основными участниками: продавцом, покупателем и банком. Задача осложняется тем, что покупателя и продавца обслуживают, как правило, разные банки. Если для использования системы "клиент-банк" достаточно двустороннего соглашения, то для полной замены "бумажного" документооборота требуется соглашение трех или четырех сторон, что практически невозможно без создания единого пространства, которое объединяло бы достаточное число банков и организаций, признающих электронные документы, создаваемые любым из участников такой системы. Как будет показано дальше, такое объединение, кроме обеспечения полноценного электронного документооборота, позволит решить и некоторые технологические задачи.

   Предоставляют ли системы "клиент-банк" необходимый сервис?    Системы "клиент-банк" бывают, как говорится, "хорошие и разные". Мне чаще доводилось сталкиваться именно с "разными". При разработке таких программ было принято ориентироваться на минимальные аппаратные требования (например, на компьютер с 286-м процессором). Разработчиков можно понять: они заинтересованы в том, чтобы их продукт приобрели как можно больше пользователей. Но в результате системы получаются слабыми. Большинство традиционных систем "клиент-банк" сделаны для MS-DOS, умеют работать только с одной базой данных, ориентированы на определенную систему электронной почты и определенную систему защиты информации.

Программу, которая разработана для процессора Intel x86 и операционной системы MS-DOS, можно запускать под Windows. Но спасибо за это следует говорить не ее разработчику, а фирмам Intel и Microsoft, столь бережно сохраняющим такую возможность в своих новых процессорах и операционных системах. Надолго ли?

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

Скорее всего, он столкнется с новой для себя системой управления базами данных. Это может быть Paradox, FoxPro, Clipper или что-то другое - не важно, все равно схема данных в системах "клиент-банк" обычно не документируется, и о какой-либо работе с ними средствами, отличными от предлагаемых разработчиком, говорить не приходится. Для использования электронной почты и коммуникационных программ наверняка потребуется их углубленное изучение. А настройка системы защиты информации вряд ли удастся без консультаций с разработчиком.

Новый класс систем, которые принято называть системами Internet banking, предоставляет услуги управления счетом с использованием сети Internet в основном в режиме online и, как правило, с использованием Web-технологии. Переход к Internet, решая одни проблемы, к сожалению, порождает другие. Как ни парадоксально, главные проблемы систем Internet banking связаны с работой в режиме online.

Во-первых, использование электронной почты обходится дешевле, чем работа через Web-сервер. Причем как для клиента, так и для банка. Являясь потребителем со стажем, я ни секунды не сомневаюсь в том, что все эксплуатационные расходы системы в конце концов придется оплачивать конечному пользователю.

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

В-третьих, если ваш компьютер напрямую подключен к Internet, вы не можете чувствовать себя в безопасности. Вызывают опасение не столько конфиденциальность и целостность информации при передаче ее в банк (предлагаемые разработчиками решения содержат необходимые средства защиты) - дело в другом. Пока ваш компьютер подключен к Internet, вы рискуете оказаться жертвой атаки с любого компьютера в Сети. Риск можно уменьшить, установив на компьютер операционную систему Unix или Windows NT, а в локальной сети - используя средства межсетевого экранирования.    Однако сегодня наибольшее распространение получили операционные системы Windows 95/98, не содержащие специальных средств защиты, а подключение происходит непосредственно к Internet-провайдеру, который средств межсетевого экранирования не предоставляет. Даже при использовании специальных средств защиты остается другая угроза. Нет гарантий, что у вас на компьютере не окажется программы - троянского коня, которая, используя стандартные протоколы, перешлет в Internet ключи и пароли системы "клиент-банк" или какую-либо другую информацию.

Общие проблемы систем электронных платежей

Существующие системы, конечно, полезны, так как решают определенный круг задач. Но они не могут обеспечить услугу электронного финансового документооборота в полном объеме. Независимо от того, будете ли вы использовать традиционную систему "клиент-банк" или воспользуетесь сервисом Internet banking, вы столкнетесь с общим набором проблем. Начав эксплуатировать любую такую систему, вы очень скоро поймете несколько печальных истин:

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

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

Ситуация для банков складывается не лучше, чем для их клиентов. Выбрав однажды систему "клиент-банк", банк получает все перечисленные проблемы, умноженные на число клиентов.

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

Отсутствие совместимости систем, единых форматов и протоколов взаимодействия создает объективные предпосылки для застоя в развитии качества программ и сдерживает технологии. Этот тезис многократно подтвержден развитием сети Internet. Internet -сообщество, объединившее набором протоколов TCP/IP множество разрозненных сетей, лучшее тому подтверждение. Как только несколько фирм начинают работать на одном секторе рынка, создают программное обеспечение, базирующееся на одних общедоступных стандартах, начинается развитие. Вслед за ними устремляются другие, растет конкуренция. Отмирают ошибочные решения, их заменяют новые, более полезные для конечного пользователя.

Возможные решения

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

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

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

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

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

Дело в том, что значительная часть необходимых протоколов уже определена в документах Internet Engineering Task Force (IETF), известных как стандарты Internet (Internet Standards, IS), проекты стандартов (Internet Drafts, ID), заявки на обсуждение (Requests for comments, RFC), а большинство разработанных для Internet программ удовлетворяют этим рекомендациям.    Основным протоколом, используемым в Internet для обмена сообщениями электронной почты, является Simple Mail Transfer Protocol (SMTP), определяемый RFC821. Использование в системах "клиент-банк" других средств передачи сообщений электронной почты, конечно, возможно, однако разработчики и пользователи таких систем должны отдавать себе отчет в том, что они неминуемо столкнутся с необходимостью интеграции с системами, использующими SMTP.

Доступ к документам, опубликованным в WWW, производится с помощью Hypertext Transfer Protocol (HTTP), определяемого RFC2068. Современные Web-серверы предоставляют мощные средства для разработки систем в архитектуре "клиент-сервер". Причем в качестве клиента может быть использован не только стандартный Web-браузер. Средства разработки позволяют встроить функции доступа к Web-серверам в любую программу. Единственным необходимым условием для разработки таких программ является документированность параметров запросов к Web-серверу.    Основным претендентом на формат электронного документа является расширение почтового протокола Multipurpose Internet Mail Extensions (MIME), описанное в RFC2046-RFC2049, которое специфицирует передачу нетекстовых данных электронной почтой.

В программах электронной почты MIME применяется для передачи простого или форматированного текста, документов в формате HTML, файлов программ, графической и другой информации. Спецификация MIME, обеспечивая совместимость с существующими почтовыми системами, расширяет их возможности, предоставляя средства обмена данными в произвольном формате. Протокол MIME используется не только в программах электронной почты, Web-браузеры умеют отображать стандартные данные в формате MIME и содержат средства для подключения внешних модулей, для отображения дополнительных MIME-типов.    Кроме того, спецификация Secure MIME (S/MIME) RFC 2311-RFC 2315 определяет порядок использования в сообщениях в формате MIME данных, заверенных цифровой подписью или зашифрованных. [6] Результатом криптопреобразования исходных данных в формате MIME также являются данные в формате MIME. Указанные спецификации не ограничиваются конкретным набором алгоритмов шифрования и цифровой подписи и не зависят от программ, реализующих эти алгоритмы.    Таким образом, сложились все объективные предпосылки для создания единой системы электронного финансового документооборота между организациями. Сумеют ли зарождающиеся системы электронного финансового документооборота в Internet предоставить такую услугу или же по-прежнему будут преобладать системы, выборочно объединяющие конкретный банк с конкретным клиентом и конкретного продавца с конкретным покупателем, покажет ближайшее будущее.

 /Компьютера: «Фактор Internet в развитии систем "клиент-банк"»/