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

Профессиональный рынок ценных бумаг является непростой предметной областью для разработчика компьютерных систем. И важно знать, какие требования предъявляются к автоматизации этого бизнеса западными и российскими финансовыми организациями, какие функции должна предоставить пользователям любая система, предназначенная для данного рынка, как эти функции влияют на архитектуру систем, а также какие существуют подходы к проектированию и реализации систем.
Чубров Евгений Владимирович, технический директор компании «АртСофт». С ним можно связаться по электронной почте: eugene@artsoft.ru

Для характеристики программного обеспечения, используемого профессиональными участниками рынка ценных бумаг, в последние годы все чаще применяется термин STP (straight-through processing). Это словосочетание обычно переводят как «автоматизированная обработка финансовых сообщений».

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

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

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

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

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

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

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

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

Что ждет от современных систем финансовая организация? В первую очередь — высокого уровня автоматизации, обработки больших объемов данных, скорости выполнения транзакций, удобного пользовательского интерфейса. Кроме того, разработчик обязан предоставить адекватную документацию — пользовательскую и техническую, организовать обучение и поддержку пользователей в предусмотренном лицензией объеме. Основные доходы профессионального участника рынка ЦБ формируются из комиссии за проведенные транзакции и платы за «хранение» портфелей. Поэтому окупаемость напрямую зависит от скорости и объемов.

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

Функции системы

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

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

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

  • информация о сделке получена в виде SWIFT-сообщения;
  • сделка инициируется системой (статус Trade Day);
  • сделка продвигается на следующий шаг (статус Settlement Day), автоматически выполняется бухгалтерская проводка, зачисляющая бумаги на счет "ожидаемые к получению"; посылаются два SWIFT-сообщения - клиенту (бенефициару), подтверждающее, что сделка принята к обработке, и в клиринговую компанию (например, DTCC или EuroClear) - заявка на перерегистрацию ЦБ;
  • приходит SWIFT-ответ из клиринговой организации (обычно на третий день), подтверждающий перерегистрацию бумаг на нового владельца; получение ответа инициирует продвижение сделки на следующий шаг (статус Clearing Down), в результате чего клиенту посылается подтверждение, а бухгалтерский модуль переводит бумаги из "ожидаемых к получению" на счет клиента;
  • на последнем шаге сделка переводится в статус Final, а бухгалтерский модуль завершает денежные расчеты с клиентом и брокером.

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

Каждый шаг сделки может выполняться как вручную, так и автоматически. Стимулом к автоматическому выполнению шага может стать получение финансового сообщения (SWIFT, FIX и т. п.) или наступление определенной даты (таймер). Все определяется настройками.

Идеалом (для западной организации) является система, работающая полностью автоматически, без вмешательства пользователя. Любое ручное действие — это потеря темпа, а значит, прибыли. Система превращается в своеобразный «завод-автомат по производству денег».

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

Второй ключевой функцией системы является обработка корпоративных действий.

К корпоративным действиям (КД) относятся разнообразные действия, производимые эмитентом ценной бумаги. Грубо их можно разбить на выплаты (дивиденды, проценты) и реорганизации компании-эмитента (новые выпуски, права, сплиты, банкротства и т. п.). Финансовая организация обязана собирать информацию о КД, оповещать о них держателей ЦБ, производить соответствующие изменения в портфеле инвестора, а также доводить мнение держателя до эмитента (в тех случаях, когда требуется ответ держателей).

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

Мне не известны аналогичные российские форматы. Например, НДЦ и АК&М предоставляют данные о КД в виде неформализованного текста. Поэтому отделы КД вынуждены вводить эти данные вручную.

В глобальной системе ежедневный объем сообщений составляет несколько тысяч, поэтому ручная обработка принципиально невозможна, особенно учитывая стоимость ручного труда. Функции пользователя должны быть сведены к контролю и корректировке автоматического процесса.

Обработку КД также можно представить в виде многошаговой транзакции3. Кроме того, отдельная транзакция отслеживает взаимоотношения с каждым держателем бумаги (платежи, SWIFT-переписка). Все операции ассоциированы с шагами этих транзакций, например:

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

Требования к системе и архитектуре

Сформулируем основные требования к STP-архитектуре.

  1. Практически все функции системы должны выполняться как автоматически, так и вручную, в зависимости от настройки.
  2. Вмешательство оператора должно быть ограничено нестандартными ситуациями, требующими принятия решения человеком (например, получено подтверждение о прохождении сделки, но система не может автоматически идентифицировать сделку). Все такие ситуации фиксируются в системном журнале, а пользователи немедленно оповещаются, например по e-mail.
  3. Система должна обрабатывать поток входящих финансовых сообщений в наиболее употребительных форматах, в первую очередь SWIFT, FIX, а также в форматах основных агентств-поставщиков финансовой информации - Reuter, Telekurs и т. п.
  4. Система должна автоматически генерировать и отправлять исходящие финансовые сообщения в различных форматах, а также по факсу и электронной почте.
  5. Система должна автоматически обновлять массив статических данных, в первую очередь список финансовых инструментов и их котировок.
  6. Архитектура системы должна обеспечивать хранение, обработку и быстрый доступ к очень большим массивам информации. Пользовательский интерфейс должен учитывать объемы данных. Например, бессмысленно выводить на экран список всех инструментов, если их число близко к миллиону. Вместо этого необходимы средства для быстрого поиска инструмента - по номеру, контексту, типу и т. п.

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

На мой взгляд, время «коробочного» ПО для рынка ЦБ еще не наступило. Поэтому при разработке и внедрении системы предлагается пользоваться такой последовательностью действий.

  1. Строится MASTER-система, то есть система, включающая в себя универсальное ядро и набор универсальных функций, в том числе интерпретаторов наиболее распространенных форматов финансовых данных. Такая система является системой 80-процентной готовности для большинства потребителей. Архитектура MASTER-системы должна быть как можно более гибкой и настраиваемой. Ядро системы должно включать общие механизмы, которые могут быть настроены (параметризированы) под требования заказчика.
  2. На начальном этапе реализации конкретной версии необходимо согласовывать бизнес-спецификации. Их цель - достижение одинакового понимания функций системы заказчиком и разработчиком. Недостаточное внимание к этому этапу часто приводит к конфликтам в дальнейшем, к необходимости перерабатывать большие фрагменты системы.
  3. Параметризация (настройка) MASTER-системы на основе бизнес-спецификаций дает 95-процентную готовность. Технически настройка сводится к заполнению определенных таблиц базы данных.
  4. Оставшиеся 5% - это кодирование функций, специфичных только для данного заказчика, реализация которых требует программирования (ненастраиваемые функции). Например, биржа SWX Swiss Exchange требует, чтобы сумма сделки была кратна 0,05 швейцарского франка. Специальная функция округления реализуется как ненастраиваемая. Архитектура системы предполагает, что все такие функции кодируются в виде небольших изолированных модулей, вызываемых ядром системы. Последнее важно для надежности системы.
  5. Сопровождение изменений в бизнес-спецификациях. На практике этот процесс совпадает со временем жизни системы. Технически он сводится к повторению пунктов 3 и 4. Кто должен настраивать систему? Иногда заказчик предпочитает, чтобы и после начала эксплуатации разработчик продолжал полное сопровождение. Наличие у заказчика квалифицированного штата ИТ-отдела позволяет со временем передать ему эту функцию. Разработчик обязан предоставить достаточно полную техническую документацию и провести обучение.

На этапе согласования бизнес-модели мы эффективно использовали Rational Rose (RR) как средство «полуформального» моделирования с достаточно развитыми средствами визуализации. Замечу, что представители заказчика имеют, как правило, иное восприятие формальной модели, нежели разработчики. Визуальное представление модели помогает найти общий язык. На рис.1 показана общая схема системы.

Примеры элементов архитектуры

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

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

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

Пример проверки: достаточно ли денег на счету для покупки лота?

Примеры действий: выполнение проводок real-time бухгалтерии, рассылка SWIFT-сообщений. Неудачное выполнение любой проверки или действия «откатывает» всю цепочку, сообщая причину неудачи пользователю на экран (при ручном выполнении шага) или по e-mail (при автоматическом). Многие ошибки фиксируются также в журнале системы.

Пример RR-модели «пути» сделки покупки лота приведен на рис. 2. Схема взята из реальных рабочих материалов проекта и показывает все возможные состояния транзакции; переходы между ними; воздействия, приводящие к переходам; входящие SWIFT-сообщения для каждого состояния; исходящие SWIFT-сообщения, вызываемые каждым переходом. Схема не отражает проверки, связанные с переходом; прочие действия, ассоциированные с переходом; бухгалтерские проводки.

Метод описания пути транзакции в виде конечного автомата с действиями очень удобен и гибок. Его реализация входит в ядро системы. Настройка автомата включает описание всех состояний, переходов, проверок и действий. К ненастраиваемым функциям относится кодирование экзотических проверок и действий.

Real-time бухгалтерия — еще один пример универсальной функции ядра. Модели всех бухгалтерских операций, связанных с возможными шагами транзакции, заносятся в систему. Шаг транзакции активизирует бухгалтерское действие, которое подставляет в модельную проводку конкретные данные (номера счетов, количество бумаг, денежные суммы). Проводка заносится в бухгалтерский журнал, автоматически подсчитываются бегущие балансы, необходимые для бухгалтерских отчетов. Эта схема одинаково работает для GAAP и для российской схемы учета.

Проектирование и реализация

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

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

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

Erwin-модель можно и даже желательно использовать как средство автоматизации программирования. Erwin-модель строится вручную на базе RR-модели.

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

Для конечной реализации системы, удовлетворяющей перечисленным ранее требованиям, на сегодня нет альтернативы клиент-серверной архитектуре. Достаточную эффективность для серверного компонента могут обеспечить такие реляционные СУБД, как Oracle, Sybase и MS SQL. Здесь приходится следовать предпочтению заказчика. Что касается клиента, то выбор, как правило, за разработчиком. Наши последние системы создавались с использованием комбинации MS SQL 7.0 + Sybase Power Builder 7.0.3.

Переход от объектно-ориентированной (ОО) RR-модели к RDBMS-модели на самом деле не является тривиальным. На первый взгляд решение очевидно. Классы объектно-ориентированной модели отображаются в таблицы базы данных, атрибуты — в колонки таблиц и т. д. Такое «очевидное» решение позволяет попытаться использовать Rational Rose для автоматизации программирования, что и было сделано специалистами Rational для Oracle 8.

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

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

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

Не углубляясь в архитектуру, рассмотрим только вопрос представления класса «корпоративное действие» в ОО- и СУБД- моделях.

Telekurs предусматривает 94 вида сообщений о КД, в общей сложности используя почти 800 различных атрибутов — текстовых, числовых, дат, ссылок на десятки справочников. Информация о том, какой атрибут в каком типе сообщения может встретиться, присутствует на уровне «как правило».

Как в этой ситуации строить ОО-представление объекта? Один класс (таблица) с 800 атрибутами (полями)? Отметим, что в каждом объекте этого класса лишь 10-20 атрибутов будут иметь значения.

В «полуформальной» ОО-модели нет нужды перечислять все 800 атрибутов, достаточно ограничиться теми, которые необходимы для описания бизнес-прецедентов. Но как реализовать такой объект в СУБД-модели?

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

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

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

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

Data-driven-описание можно определить как такое описание, при котором существенные элементы бизнес-архитектуры задаются данными, то есть наполнением таблиц, а не их структурой. Такие таблицы мы называем настроечными (set-up tables).

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

Примеры описаний элементов бизнес-процессов, задаваемых data-driven-методом:

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

Последнее является весьма нетривиальным методом и представляет ноу-хау.

Проблемы внедрения

Решение о переходе на новую систему сводится к вопросу об окупаемости затрат на подобное программное обеспечение. Основные возражения можно свести к следующим.

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

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

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

  • Что дает система? В первую очередь - полный STP-цикл, надежно работающий при высоком объеме обрабатываемых сделок. STP-цикл включает возможность автоматического выполнения таких действий, как создание транзакции (сделки, корпоративного действия) при получении финансового сообщения, смена ее состояния при получении новых сообщений и по другим событиям, обновление информации о финансовых инструментах (включая котировки) из внешних источников, расчет комиссий, проведение бухгалтерских проводок, рассылка финансовых сообщений (о сделках, о состоянии счета), сверка портфелей с клиентами и кастодианами.
  • Нужна ли полная информация о ЦБ? Уровень этого сервиса должен зависеть от потребностей клиентов фирмы. Например, база данных ICIDPlus, предоставляемая Telekurs, содержит порядка полумиллиона ЦБ, причем подписка на ежедневное обновление стоит порядка 100 тыс. долл. в год. Здесь возможны более дешевые методы, например извлечение информации о новых инструментах из данных о ценах или сделках.
  • Какой уровень автоматизации выбрать? STP-архитектура не накладывает здесь ограничений. Любая операция может выполняться как автоматически, так и вручную. Все зависит от корпоративной политики заказчика.
  • Вопрос о том, кому поручить разработку системы - внутреннему информационному отделу или независимой организации, - возникает нередко. "Карманная" команда, возможно, дешевле, и с ней спокойнее - она никуда не денется. В России такая точка зрения поддерживается обилием программистских кадров.

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

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

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

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

Заключение

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

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

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

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

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

назад