CC BY
125
УДК 336.71
О РЕАЛИЗАЦИИ ГС-ПРОЕКТА ВНЕДРЕНИЯ АВТОНОМНОЙ СИСТЕМЫ КОНТРОЛЯ ЗА ЛИМИТАМИ В УНИВЕРСАЛЬНОМ БАНКЕ
В статье рассматриваются проблемы, возникающие в ходе внедрения типовой автоматизированной системы контроля за лимитами инвестиционной деятельности универсального банка. Проанализированы основные составляющие подобных систем, их внешние и внутренние связи, основные этапы их внедрения. На основе проведенного анализа автором предлагаются практические рекомендации по разработке и внедрению автоматизированной системы контроля за лимитами.
Ключевые слова: автоматизированная система, программный комплекс, информационная система, контроль, риск, лимит, система, банк, кредитная организация, внедрение.
Неотъемлемым инструментом политики управления рисками любого банка является эффективно функционирующая система лимитов. Она призвана устанавливать определенные ограничения на принятие банком чрезмерных рисков. Целью системы является установление пороговых значений на различные показатели и характеристики с последующим контролем за достижением установленных ограничений. Как правило, превышение установленных лимитов не допускается. Для этого требуется специальное решение руководства банка. Главной задачей системы лимитов является формирование структуры активов и пассивов, адекватной основным целям деятельности и размерам капитала банка.
В настоящее время существует ряд программных комплексов контроля за инвестиционной деятельностью от различных разработчиков и поставщиков. Один из наиболее популярных - Calypso
Л. А. ЧЕРКУНОВ,
заместитель начальника отдела управления операционными рисками E-mail: cherkunov@gmail. com ОАО Банк ЗЕНИТ
- одноименной компании, отличительной особенностью которого является возможность проведения глубоких модификаций при отсутствии механизма поддержания обратной совместимости. На равных с ним конкурирует Kondor + KGR компании Misys, который характеризуется модульностью и наличием механизмов обратной совместимости при отсутствии отлаженных взаимосвязей между модулями. Автоматизированная банковская система АБС. СПО отечественной компании CSBI Group обладает открытым кодом, однако платной и непопулярной платформой. Существуют также другие, менее известные и распространенные, программные комплексы: Axiom, CorrTec, Polaris, IDEAL [6, 8]. Несмотря на достаточно большой выбор, все эти системы обладают схожим базовым функционалом. Как правило, сюда следует отнести функции организации торговли ценными бумагами и связи с торговыми системами, функции расчета стоимости различных инструментов, моделирование рыночных показателей.
В дальнейшем под понятием «система контроля за лимитами» будет пониматься именно программный комплекс, решающий данную задачу. Его основными функциями являются:
- сортировка сделок по заданным фильтрам;
- расчет влияния каждой сделки на лимит с помощью различных моделей и алгоритмов;
- вычисление итогового показателя использования лимита;
- сравнение этого показателя с контрольным значением и выполнение действий в зависимости от результата этого сравнения.
Потоки данных в системё"
Шлюзы внешних систем
Ядро системы, основой модуль
Внутренние шлюзы
Вспомогательные модули
Архитектура лимитной системы класса standalone
Представленные системы поддерживают набор перечисленных функций и, соответственно, включают модули, содержащие алгоритмы их реализации. Многие из этих систем обладают и схожими архитектурами. Следствием близости архитектур является то, что риски и ошибки, возникающие при внедрении и начальном периоде эксплуатации, являются типовыми.
В статье рассматриваются наиболее характерные для исследуемого класса систем проблемы, возникающие в ходе разработки, внедрения и начальных этапов сопровождения, а также способы их минимизации, и, как следствие, способы сокращения сроков внедрения и повышения эффективности функционирования систем.
Все представленные системы относятся к наиболее быстро развивающемуся классу автономных (standalone) систем, характерными особенностями которых являются:
- возможность адаптации к уже существующим банковским системам. Эти системы не требуют существенной переделки функционирующих банковских систем и используемых алгоритмов в процессе своего внедрения и эксплуатации [9];
- все необходимые для их функционирования элементы уже включены в набор программного обеспечения (ПО);
- при внедрении необходимо только настроить связи между уже существующими автоматизированными банковскими системами (АБС) и внедряемой, а также модифицировать логику алгоритмов в соответствии с поставленными требованиями;
- при внедрении автономных систем стараются минимизировать изменения в бизнес-процессах, связанных с автоматизируемыми. Архитектура рассматриваемых систем представлена на рисунке.
Архитектура автономных систем
Для каждого из модулей системы характерны свои специфические риски. Рассмотрим их, пред-
варительно проранжировав модули с точки зрения важности решаемых ими задач для функционирования лимитной системы: лимитный модуль, ядро системы, шлюзы внешние и внутренние.
Лимитный модуль. Основную функциональную нагрузку лимитной системы несет на себе лимитный модуль. Его функции заключаются в описании лимитов, их расчете, выявлении нарушений, сохранении истории и создании удобных отчетов для пользователей системы. Описание лимита включает в себя:
- набор фильтров на различные поля сделок, по которым в дальнейшем они будут отобраны для расчета;
- контрольное значение;
- срок действия лимита или контрольного значения;
- описание алгоритма расчета влияния сделок на лимит.
В силу наличия множества вариантов фильтрации механизм описания лимитов должен быть гибким, чтобы давать возможность создавать свободную совокупность признаков фильтрации и производить сортировку по ним. Такой механизм может быть реализован на основе хранимых процедур базы данных (БД). При этом для удобства конечного пользователя необходимо также предусмотреть уже готовые шаблоны (фильтры):
- на эмитентов или контрагентов по сделкам;
- на различные типы инструментов;
- на портфели ценных бумаг;
- на принадлежность различных элементов к определенным странам;
- на отрасли деятельности;
- на валюту сделки/бумаги;
- по рейтингу;
- по пользователям системы, они позволяют контролировать отдельных трейдеров. Следующим шагом в определении лимита
является выбор его вида и внесение контрольного значения. Основными видами лимитов являются:
- абсолютные;
- относительные;
- иерархические - в данном случае фильтры на сделки могут не учитываться, так как множество сделок лимита будет состоять из совокупности сделок других лимитов;
- динамические, когда контрольное значение изменяется во времени.
По отфильтрованной и отсортированной совокупности сделок необходимо произвести расчет их влияния на общую сумму использования лимита. Важную роль здесь играет скорость расчета. Днем, когда поток сделок наиболее интенсивен, необходимо обеспечить быстрый расчет показателей для контроля за лимитами в режиме реального времени. Бывает, что из-за сложности применяемых алгоритмов возникают незначительные ошибки, например из-за нештатного обновления уже рассчитанных сделок. В этом случае ночью, когда поток сделок отсутствует, необходимо пересчитать определенные лимиты для устранения возможных ошибок. При этом расчеты должны завершиться к моменту начала операционного дня.
Алгоритмы расчета целесообразно разделить на классические - те, которые рассчитывают влияние сделки на основе ее параметров, и алгоритмы с памятью. Такие алгоритмы учитывают не только параметры конкретной сделки, но и место в последовательности других сделок. При этом влияние предшествующих, уже рассчитанных сделок, также может меняться на основе текущего расчета.
Для того чтобы конечные пользователи могли легко воспользоваться рассчитанной информацией, предусматривается механизм составления отчетов об использовании лимитов. Поскольку требования к отдельным составляющим совокупности лимитов сильно разнятся в зависимости от банка, наилучшим вариантом реализации отчетов является наличие механизма их отображения на основе хранимых процедур в базе данных. Отчеты можно реализовать как доработку системы, предусмотрев группировку по типам, видам и внутреннему классификатору лимитов.
В случае выхода за пределы ограничений может производиться автоматическое действие, к примеру уведомление контролирующих подразделений или отсылка сигнала торговой системе. Механизм такого взаимодействия должен описываться с помощью встроенных инструментов.
Для последующего контроля и понимания изменений позиций во времени предусмотрен
механизм сохранения истории. Особое внимание следует уделять его реализации, поскольку объем исторических данных будет многократно превышать объем текущих данных, алгоритмы работы с историей должны обеспечивать быструю обработку большого количества информации.
Среди наиболее существенных и часто встречающихся недостатков функционала лимитного модуля следует выделить:
- отсутствие достаточного набора фильтров и способа их описания. Данная проблема может возникнуть из-за отсутствия в лимитном модуле необходимых данных, поскольку их передача не предусмотрена внутренними шлюзами, а, следовательно, и фильтрация по таким параметрам отсутствует. Отсутствие механизма описания дополнительных фильтров приводит к невозможности контроля за некоторыми лимитами;
- отсутствие необходимых видов лимитов и механизма их описания. Часто бывает, что лимитная система способна контролировать лишь классические лимиты, когда один параметр должен быть меньше другого;
- отсутствие возможности расчетов, которые учитывают порядок сделки в стеке, иными словами, отсутствие алгоритмов с памятью;
- недостаточная для контроля за лимитами в реальном времени скорость работы системы. В этом случае невозможно реализовать контроль за лимитами в режиме реального времени. Кроме того, при интенсивном потоке сделок возможна поломка системы;
- отсутствие механизмов контроля и коррекции текущих и исторических данных;
- ошибки расчетов и передачи данных из-за наличия неуправляемых шлюзов;
- отсутствие поддержки различных языков и кодировок. Дело не только в том, что конечным пользователям удобнее работать с ПО на родном языке. Если в иных АБС банка информация хранится на отличном (неподдерживаемом) языке, то, во-первых, конечному пользователю постоянно придется отвлекаться на перевод или транслитерацию текста для поиска информации, что существенно снижает эффективность работы. Во-вторых, при загрузке данных и автоматической транслитерации текст может совпасть с ранее транслитерированным или потерять смысловую нагрузку. В-третьих, описание некоторых
финансовых инструментов может содержать существенную нетранслитерируемую информацию (например код российских векселей содержит важные их характеристики, а вместе с тем состоит из кириллических символов);
- низкое качество документации и поддержки со стороны вендоров.
Для исправления описанных недочетов потребуется доработка системы. Некоторые проблемы, такие, например, как отсутствие необходимых видов лимитов и наборов фильтров, можно исправить, прибегнув к серьезным структурным изменениям. Первоначально следует произвести доработки следующих алгоритмов и подсистем:
- механизма контроля за целостностью данных. Как в режиме реального времени, так и в оййте-режиме целостность данных и правильность расчетов должны проверяться. Сверка может производиться с использованием эталонных показателей, а также с помощью алгоритмов, проверки расчета результата;
- алгоритмов расчета показателей. Алгоритмы, не предусмотренные изначально в системе контроля за лимитами, позволят организовать расчет недостающих параметров, а также могут существенно улучшить производительность системы в целом. Доработка существующих алгоритмов позволит улучшить производительность за счет тонкой настройки под текущие задачи;
- подсистемы передачи данных между модулями системы (в дополнение к существующим неуправляемым шлюзам). Она позволит передавать недостающие данные.
В ходе проведения доработок может оказаться, что вмешательство в систему стало столь сильным, и собственных алгоритмов стало так много, что проще написать новый лимитный модуль, который будет отвечать всем поставленным требованиям.
Ядро - базовый модуль системы. Хранением и первичной обработкой данных со стороны лимитной системы занимается ядро, или базовый модуль. К основным его функциям относится обеспечение базового функционала:
- работа с базой данных и поддержания целостности информации в ней;
- функции коррекции возникающих в БД ошибок;
- предоставление унифицированного пользовательского интерфейса;
- разграничение прав доступа пользователей;
- функции администрирования системы;
- функции сохранения истории действий пользователей.
Кроме того, ядро должно обеспечивать базовый финансовый функционал, а именно:
- хранение и обеспечение работы со справочниками финансовых инструментов;
- хранение списка сделок и дополнительной информации по ним;
- расчет финансовых показателей по хранимым инструментам (например накопленный купонный доход по облигациям, дельты опционов и т. д.).
Другой важной функцией ядра является отслеживание состояния системы и обработка исключительных ситуаций. Как правило, внезапные сбои в отлаженных информационных системах - явление довольно редкое. Большинству отказов предшествует аномальное поведение системы, которое можно отследить, что позволяет минимизировать последствия сбоя либо вовсе предотвратить его. К обязательным функциям основного модуля относится постоянный мониторинг состояния системы. В случае обнаружения аномалий или ошибок необходимо немедленно уведомить ответственных сотрудников, также записать четкий и понятный лог произошедшего в системе. Кроме того, некоторые сбои и ошибки могут быть устранены в автоматическом режиме. Все модули и надстройки системы должны использовать предоставляемые ядром алгоритмы обработки исключительных ситуаций.
Работоспособности основного модуля всегда уделяется особое внимание как со стороны вендора системы, так и со стороны конечного пользователя. В случае ее утери вся лимитная система будет неспособна выполнять свои функции. Следовательно, наиболее серьезный вид риска - это потеря работоспособности ядра, а следом и всей системы. Эта ситуация может иметь место в результате ошибок проектирования, ошибок, допущенных при внедрении и доработке. Кроме того, серьезным недостатком является недостаток гибкости настроек и отсутствие инструментов разработки, что может привести к невозможности реализации каких-либо дополнительных функций или настроек. Еще одним недостатком может явиться отсутствие поддержки различных языков, поскольку при транслитерации некоторые различные по смыслу русские названия могут превратиться в одно и то же английское слово. Помимо этого работа с русскими названиями в
одной системе и транслитерированными в другой является существенным затруднением для конечных пользователей. Для того чтобы избежать возникновения подобных ситуаций, на этапе предпроектного обследования следует особенно тщательно изучать внедряемую систему. Ошибки, допущенные при выборе архитектуры и настройке ядра, устраняются с большим трудом с помощью написания дополнительных надстроек при внедрении и последующей эксплуатации.
Шлюзы - подготовка и передача данных из внешних источников. Для решения задачи подготовки и передачи данных из внешних источников используется специальное программное обеспечение - шлюзы. При этом процесс подготовки и передачи данных состоит из следующих этапов:
- получение данных из всех внешних систем;
- фильтрация полученной информации;
- конвертация структуры данных;
- расчет производных параметров на основе полученных данных;
- запись подготовленных данных в базу или выполнение каких-либо иных действий, в том числе и с помощью прикладного программного интерфейса (API) иных систем.
При этом данные могут идти не только по маршруту от внешних АБС к лимитной системе. Может возникнуть потребность передать информацию назад или выполнить какие-либо действия. Например, при превышении лимита торговой системе может быть отдана команда на ликвидацию части позиции. Для передачи информации в обратную сторону (к сторонним системам) также используются шлюзы, при этом процесс подготовки и передачи данных аналогичен, он лишь направлен в другую сторону.
Помимо передачи данных шлюзы занимаются контролем за их целостностью. Они сравнивают данные между несколькими базами данных и устраняют расхождения. Некоторые действия по синхронизации информации должны совершаться вследствие какого-либо события, к примеру совершения сделки, иные же действия, такие, например, как сверка баз данных, должны выполняться по расписанию. Поэтому шлюз должен иметь планировщик заданий с гибкими правилами, использующий встроенный язык программирования, который позволяет гибко настраивать процесс передачи данных.
Возникающие в ходе работы шлюза риски сводятся к рискам работоспособности программного
обеспечения и рискам возникновения ошибок при разработке правил обработки данных. Для их минимизации в системе должен присутствовать отлаженный шлюз либо должно использоваться специализированное стороннее программное обеспечение. В любом случае встроенные в шлюз механизмы контроля снижают риски отказа или сокращают время его устранения. К правилам передачи данных предъявляются такие же требования, как и к любым другим доработкам: применение оптимизированных и понятных алгоритмов, написание качественного кода и составление исчерпывающей документации.
Внутренние шлюзы. Общее правило таково, что внутренние шлюзы не должны входить в архитектуру системы. К сожалению, часто встречаются системы, модули которых, в том числе и лимитные, отделены от ядра и работают в независимых базах данных. Сразу же возникает задача передачи данных между модулями. Для этого и предназначены внутренние шлюзы. Они, так же, как и внешние шлюзы, реализуют и двустороннюю передачу данных, и расчет некоторых параметров.
В случае применения архитектуры с внутренними шлюзами возникает проблема дублирования одних и тех же данных в разных модулях. Это, во-первых, приводит к росту требований к базам данных, во-вторых, поднимает проблему синхронизации данных и поддержания их целостности.
Зачастую в таких шлюзах отсутствуют какие-либо настройки, поскольку предполагается, что они обеспечивают все потребности по передаче данных между независимыми модулями системы. Как следствие, набор данных, который передается между модулями, фиксирован и не может быть изменен при необходимости доработки. В силу этого некоторые доработки оказываются труднореализуемыми, поскольку, несмотря на то, что необходимые данные хранятся в ином модуле, воспользоваться ими нельзя, так как шлюз не рассчитан на их передачу. При этом сбои в передаче данных внутренними шлюзами крайне сложно выявить и трудно устранить их причину.
Хотелось бы особенно предостеречь разработчиков и пользователей от использования рассмотренной схемы построения системы. Любой внутренний шлюз - это наиболее узкое место, которое может привести к нестабильной работе всей системы. Кроме того, наличие внутреннего шлюза ведет к нарушению принципа единого информационного пространства.
Внешние данные автономных систем
Для выполнения своих основных функций лимитная система должна получать различную информацию. Сюда следует отнести описания инструментов, например описания ценных бумаг, валют (финансовые центры, лоты, даты обновления, тип котировок), производных инструментов и некоторых других, которые используются в расчетах. Помимо этой информации, для различных расчетов требуется информация о ходе торгов, - как рыночные котировки, так и исторические данные: курсы валют, иные используемые в расчетах данные.
Некоторые данные, к примеру курсы валют, можно брать из стандартизированных источников. Поэтому в лимитных системах возможно наличие механизмов самостоятельного получения таких данных. Однако большая часть информации передается из иных АБС, которые могут являться и внутренними разработками банка. При использовании внешних данных возникает ряд проблем.
1. Несовпадение структур данных и баз данных. Для того чтобы передать данные из системы в систему, их необходимо предварительно подготовить.
2. Различные поставщики баз данных. У различных вендоров приемы работы с данными могут различаться, что также порождает дополните ль-ные сложности при обработке информации.
3. Проблема грязных данных. Нет никакой гарантии, что в поступающих данных отсутствуют ошибки. Следует проводить контроль за их корректностью, чтобы не вносить ошибок в расчеты.
4. В силу различной идеологии систем не все данные могут требоваться для расчетов. Их фильтрация - еще одна задача, которую нужно решать в процессе подготовки данных.
Как было сказано ранее, данные задачи решаются с помощью применения шлюзов.
Этапы внедрения
Несмотря на возможность адаптации к уже существующим АБС, принятие решения о приобретении standalone-системы вовсе не означает, что все действия по внедрению предполагают только установку необходимого оборудования и ПО. Процесс ее внедрения имеет достаточно продолжительный характер и содержит следующие этапы [2]:
- предпроектное исследование - подготовительные работы и предпроектное обследование;
- постановка задач и формирование технического задания (ТЗ);
- рабочее проектирование и адаптация ПО;
- создание пилотного проекта;
- внедрение системы;
- ввод в эксплуатацию;
- поддержка;
- автономное функционирование.
В связи с наличием операционных рисков, которые имеют место в ходе всего процесса, целесообразно сгруппировать описанные этапы следующим образом:
- предпроектное обследование с постановкой задач и формирование ТЗ;
- рабочее проектирование и адаптация ПО, создание пилотного проекта;
- внедрение системы и ввод ее в эксплуатацию, начало процесса поддержки и автономного функционирования.
В силу автономности систем рассматриваемого класса от каких-либо иных АБС их разработкой и внедрением обычно занимаются сторонние организации. Несомненное достоинство при этом заключается в том, что разработчик постоянно улучшает свою систему в соответствии с получаемым им опытом. Вместе с тем к недостаткам standalone-систем следует отнести необходимость наличия высококвалифицированных специалистов в банке, ведь в конечном итоге основная поддержка будет осуществляться ими.
Предпроектное обследование. Перед тем как начать внедрение, необходимо провести детальное обследование затрагиваемых бизнес-процессов и существующих АБС. Главной целью данного этапа является определение места будущей лимитной системы среди иных банковских систем. Наиболее тесно лимитные системы взаимодействуют с торговыми системами, получая оттуда необходимые данные: текущие котировки бумаг, объемы торгов, волатильности, информацию о совершенных сделках. Окончательный набор данных определяется требованиями к функционалу системы, типами сделок и видами лимитов. В обратную сторону к торговым системам идут команды на совершение сделок: на сокращение позиции при превышении лимита или при достижении контрольного уровня. Лимитные системы также тесно взаимодействуют с системами управления отчетностью, получая
данные о результатах деятельности в прошлом и представляя текущие финансовые отчеты. Из СЯМ-систем берутся данные о контрагентах для совершения сделок.
Результатом данного этапа должно стать формирование первоначального круга задач, отводимых для решения системе, информация о связях и взаимодействиях с существующими АБС. Следует определиться с набором операций, лимиты на которые будут устанавливаться. Чаще всего сюда относятся сделки с ценными бумагами, залоговые операции с ними, сделки Forex, сделки с производными инструментами и т. д.
Наиболее существенным риском рассматриваемого этапа является неправильное понимание роли системы и функций, которые она может выполнять. Необходимо подробно изучить затрагиваемые бизнес-процессы банка, а также предполагаемую к внедрению систему, для того чтобы избежать неправильного понимания ее роли и функций [3].
Первый этап внедрения системы. Начальный этап внедрения особенно важен, ведь некоторые ошибки, допущенные на этом этапе, в будущем могут привести к некорректной работе всей системы или невозможности реализации важных функций, а затраты на их устранение могут быть сопоставимы с ее стоимостью.
На данном этапе происходит окончательное определение роли внедряемой разработки среди иных АБС. Роль системы контроля за лимитами (СКЛ) заключается в распределении сделок по лимитам на основании фильтров, расчете объема использования лимитов по этим сделкам и сопоставлении результатов с эталонным показателем.
Необходимо очертить круг задач, решением которых должна в итоге заниматься система. По мнению автора, перед СКЛ стоят следующие основные задачи:
1) агрегация данных из внешних источников. К необходимым данным следует отнести сделки с финансовыми инструментами, из которых в дальнейшем будут составляться лимиты, описания этих инструментов, а также рыночную информацию, необходимую для проведения расчетов. Полностью составить список входных данных можно после изучения применяемых алгоритмов внедряемой СКЛ, а также алгоритмов, требующих дополнительной доработки. Поскольку архитектура исследуемой системы является автономной, то исходные данные будут
получаться извне, источниками могут являться торговые платформы, поставщики рыночных котировок, иные АБС. В силу большого числа возможных поставщиков, структура данных может существенно различаться. Из этого обстоятельства вытекает следующая функция;
2) подготовка данных от внешних поставщиков. Нужно отфильтровать, устранить ошибки, привести к заданной структуре и произвести первичные расчеты необходимых показателей;
3) обеспечение надежного хранения данных. Возможность утери или порчи данных должна быть исключена;
4) группировка и сортировка сделок или иных элементов, на которые устанавливаются лимиты;
5) расчет использования лимита. В состав инструментальных средств системы должны включаться наиболее популярные алгоритмы расчета, также должна быть предусмотрена возможность создания собственных механизмов;
6) сохранение исторических данных об использовании лимитов, а также об их составе;
7) наличие механизма создания и отображения отчетов об использовании различных показателей.
Зная задачи лимитной системы, можно сформулировать и основные требования, предъявляемые к
данному классу информационных систем:
- наличие дружественного интерфейса, легкость в освоении, наличие качественной документации, технической поддержки и другие стандартные требования, предъявляемые к современным информационным системам;
- повышенная отказоустойчивость (час простоя может обходиться в десятки и сотни тысяч денежных единиц). В инвестиционных банках отказоустойчивости рассматриваемых систем должно уделяться такое же внимание, как отказоустойчивости процессинга пластиковых карт;
- корректность применяемых алгоритмов расчета. В случае наличия ошибок в алгоритмах расчета ПО может работать стабильно, вместе с тем выдавать ошибочные результаты, что в конечном итоге может привести к серьезным потерям;
- расширяемость и гибкость. Чтобы соответствовать постоянно меняющимся требованиям, все элементы должны легко модифицироваться и обновляться, сохраняя при этом сделанные ранее наработки;
- сервисная пригодность. Обязательно должны
быть предусмотрены механизмы регламентного
и экстренного обслуживания.
Результатом начального этапа внедрения должно стать техническое задание, описывающее все особенности будущего бизнес-процесса и его алгоритмы. Имея сформированные требования, можно понять, насколько выбранная архитектура отвечает им, и какой объем доработок потребуется. Необходимые доработки лучше всего сгруппировать по схожести и тесноте связей. К примеру, изучив инвестиционный бизнес-процесс банка, можно оценить интенсивность операций с различными типами инструментов и сделать вывод о том, какие из них настраивать первыми. Может оказаться, что первоначально нужно настроить лимитную систему для работы с акциями и облигациями, а также со сделками РЕПО с ними, затем с производными инструментами, а затем со сделками Forex.
Наиболее серьезной проблемой данного этапа является отсутствие достаточных знаний об особенностях функционирования новой системы [1]. Вследствие этого, когда начальный опыт работы будет накоплен, может оказаться, что система неспособна к выполнению части возложенных на нее функций.
Следствием отсутствия знаний может также являться формирование ошибочных, а также неполных требований к набору выполняемых функций. Ошибочные требования могут привести к невозможности реализации некоторых алгоритмов либо к алгоритмам, работающим с ошибкой. Опасность использования таких алгоритмов заключается в сложности нахождения ошибки, ведь он может правильно работать для 95 % ситуаций и выдавать ошибку лишь для 5 % [7]. Поэтому следует как можно глубже изучить все возможности и тонкости функционирования алгоритмов системы перед ее внедрением. Помочь в этом могут доступ к оценочной копии, наличие хорошо подготовленной документации, а также тесное взаимодействие с разработчиками. Разработчики, в свою очередь, должны изучить поставленные в ТЗ требования и высказать рекомендации по их реализации. Кроме выдачи рекомендаций, разработчики, основываясь на своем опыте, могут высказать обоснованные соображения по срокам внедрения системы.
Рабочее проектирование и реализация. Следующим этапом внедрения является практическая реализация всех идей и требований, сформули-
рованных ранее. На этом этапе развертывается аппаратная часть и устанавливается базовое программное обеспечение для контроля за лимитами. При этом следует уделять особое внимание работоспособности аппаратного обеспечения. Заранее необходимо предусмотреть наличие резервных элементов или целой резервной копии системы. Для целей последующей разработки, в том числе и самостоятельной, наличие тестовой системы также является большим преимуществом. При наличии дополнительных экземпляров системы обязательно наличие механизма синхронизации данных между ними. И, если резервная система должна являться абсолютной копией «боевой», то синхронизацию тестовой системы необходимо проводить по требованию, чтобы не потерять еще не внедренных наработок. Современное аппаратное обеспечение обладает высокими показателями надежности и сервисной пригодности, однако заранее следует позаботиться о наличии достаточной резервной мощности аппаратного обеспечения. Исходя из предъявляемых требований и опыта разработчиков, следует заранее определить характеристики системы с учетом возрастания нагрузок во времени.
После установки программного обеспечения начинается его конфигурирование. Основные составляющие стандартного функционала уже присутствуют, однако необходима его тонкая настройка под конкретные нужды. Специфические функции также требуют доработок. При этом очень важно наличие встроенного инструментария, который позволил бы провести эти доработки. Таким инструментарием является встроенный язык программирования, возможность использования функций иных программ, пользовательские процедуры и таблицы БД. В результате должна получиться начальная версия будущей системы. С одной стороны, это уже не просто установленный дистрибутив, а с другой, - еще не конечный продукт. На данном этапе происходит большое количество настроек и доработок. Однако некоторые функции уже используются, с ними начинают взаимодействовать конечные пользователи. Вместе с тем-становится ясно, что еще необходимо реализовать или модифицировать. В процессе работы производится изменение требований с учетом полученного опыта внедрения и накопленных знаний. Сроки реализации проекта при этом также могут быть пересмотрены и скорректированы.
Недоработки всех предыдущих этапов здесь начинают проявляться в виде ошибок и сбоев
СКЛ. Особое внимание следует уделять качеству проводимых доработок, поскольку после внедрения дальнейшее развитие будет осуществляться самим банком. К источникам возможных проблем в первую очередь следует отнести ошибки при адаптации алгоритмов и реализации дополнительного функционала.
При разработке программного комплекса особое внимание следует уделять качеству кода, его документированию и легкости поддержки. Плохо написанный код в будущем будет трудно поддерживать [5].
Еще одной серьезной проблемой является отсутствие достаточной гибкости системы. Это может привести к тому, что невозможно будет реализовать необходимые, однако не предусмотренные стандартно функции, поскольку существующие механизмы расширения функционала не позволят этого сделать. Данная проблема является частым случаем ошибок при выборе архитектуры системы.
Поддержка и автономное функционирование. На данном этапе весь основной функционал уже сформирован. Осуществляется окончательная доработка и отладка. Производятся поиск и устранение допущенных при внедрении ошибок. Конечные пользователи проходят обучение, часть поддержки и разработки системы переходит к банку.
Параллельно с самостоятельной разработкой необходимо проводить оптимизацию и ревизию кода, как проводимых доработок, так и модулей, код которых открыт. Основные цели ревизии таковы [4]:
- уменьшение количества ошибок;
- улучшение производительности и совершенствование алгоритмов;
- обеспечение совместного владения кодом - недокументированный и непонятный код может поддерживать лишь разработчик, написавший его, если он не забыл, как код работает;
- удешевление сопровождения приложения как следствие обеспечения совместного владения кодом;
- обеспечение обмена опытом: специалисты должны учиться на опыте своих коллег, полученном в ходе проведении разработки.
В итоге должна получиться отлаженная, работоспособная система, отвечающая требованиям, которые были сформулированы в ТЗ и скорректированы в ходе реализации дальнейших этапов. Также должны быть отлажены процедуры технической поддержки пользователей. В дальнейшем подде-
ржкой системы и ее доработкой в основном должны заниматься сотрудники банка. Вместе с тем поддержка от разработчиков необходима для разрешения некоторых проблем. От ее качества также зависит, насколько стабильно в будущем будет работать программное обеспечение. Немаловажной характеристикой качества поддержки является наличие полной документации, как к основным модулям, так и к доработкам системы. При наличии документации низкого качества банк столкнется со сложностями при выявлении и устранении возникающих ошибок, поскольку придется сначала изучать исходные тексты программ. Разработка собственных дополнений также будет затруднена, поскольку взаимодействие существующих модулей будет трудно обеспечить. Вместе с тем некоторые элементы системы могут поддерживаться только разработчиками ввиду их сложности или закрытости. В случае отсутствия квалифицированной поддержки устранение ошибок в них является очень трудоемкой процедурой.
Перед подписанием документов о приемке необходимо убедиться в выполнении всех требований, оговоренных ранее. В случае выявления недостатков крайне не рекомендуется их устранение в рамках дополнительных соглашений после подписания основного договора. Лучшим вариантом является перенос сроков сдачи системы в эксплуатацию, что явно предпочтительнее варианта наличия неработоспособной системы, сданной в срок.
Выводы. Чтобы система контроля за лимитами отвечала возложенным на нее требованиям и процесс ее внедрения завершился успешно, нужно постоянно проводить мониторинг как самого процесса внедрения, так и всех компонентов системы. Основное внимание необходимо сосредоточить на следующих наиболее важных аспектах внедрения:
- формулировании требований к системе;
- выборе архитектуры системы;
- тщательном изучении особенностей построения и функционирования внедряемой системы;
- планировании процесса внедрения на основе знаний об особенностях внедряемой системы;
- контроле за качеством процесса внедрения на каждом этапе работ;
- контроле за качеством программного кода и документации внедряемой системы;
- контроле за поставляемыми компонентами системы;
- недопустимости переносов работ на последующие этапы;
- контроле за работоспособностью алгоритмов и адекватностью производимых дополнительных доработок системы.
И, что очень важно, не следует подписывать каких-либо документов, относящихся к внедрению системы и имеющих юридическую силу, на основании «доброй воли сторон».
Список литературы
1. Каштанов В. А. Теория надежности сложных систем. М.: Физматгиз, 2010.
2. Когаловский М. Р. Перспективные технологии информационных систем. М.: ДМК-Пресс, 2003.
3. ЮркевичВ. В., СхиртладзеА.Г. Надежность и диагностика технологических систем: учеб. для вузов. М.: Академия, 2011.
4. Arvind Doraiswamy, Sangita Pakala, Nilesh Kapoor. Security Testing Handbook for Banking Applications // IT Governance Publishing, 2009.
5. Corporation Essvale. Investment Banking Applications // Essvale Corporation Limited. 2011.
6. Financial Risk Management Software Programs. URL: http://www. capterra. com/financial-risk-management-software.
7. Hassan Gomaa. Software Modeling and Design // George Mason University, 2011.
8. Inntron Intelligence: Banking Back Office, Treasury, Trade, Asset, Risk Management Software -http://www. inntron. com/treasury. html.
9. Standalone software/ URL: http://en. wikipedia. org/wiki/Standalone_software.
Р^ШЯConferences
агентство маркетинговых коммуникаций
17 сентября 2013 г. в Москве CNews Conferences и CNews Analytics проведут конференцию
«Банковская информатизация 2013»
Информационная поддержка - Издательский дом «ФИНАНСЫ и КРЕДИТ» Основные вопросы конференции:
• какие задачи в сфере банковской информатизации требуют немедленного решения;
• как определить эффективность процессов;
• как повысить экономическую эффективность с помощью ИТ;
• какие новые решения предлагает рынок банковской информатизации;
• как вендоры реагируют на новые потребности банков.
За дополнительной информацией, а также по вопросам участия обращаться по телефонам: +7 (495) 363-11-11 (доб. 3141, 3435, 3477, 3439, 3478 либо e-mail: events@cnews.ru Армен Айвазов, Алексей Четеернин, Елена Забродина, Ольга Крысина, Наталья Теличееа
http://events.cnews.ru/
ФИНАНСОВАЯ АНАЛИТИКА
проблемы и решения ' 25
