Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT

| |4/DECchip21164/400MHz | | |1.0 |

|HP |HP 9000 Model D370 |5822.23 |$148 |Sybase SQL Server |

| |2/PA-RISC 8000/160MHz | | |1.0 |

|HP |HP 9000 Model K460 |12321.87|$187 |Sybase SQL Server |

| |4/PA-RISC 8000/180MHz | | |1.0 |

|IBM |RS6000 Power PC Server |577.07 |$243 |Sybase SQL Server |

| |J40 8/Power PC | | |1.0 |

| |604/112MHz | | | |

|SGI |Challenge XL Server |6313.78 |$479 |Informix OnLine |

|Sun |Ultra Enterprise 4000 |11465.93|$189 |Sybase SQL Server |

| |12/UltraSPARC/167 MHz | | |v.11.0.2 |

|Sun |Ultra Enterprise 3000 |6662.47 |$152 |Sybase SQL |

Кроме того, оказалось, что новое программное обеспечение существенно

проще использовать. На пример, комбинация продуктов NT/Sybase обеспечивает

единообразный механизм доменов наименования и секретности, графический

интерфейс для администрирования и работы, а также современные

инструментальные средства разработки. Хранимые процедуры SQL, генераторы

приложений типа PowerBuilder, SQLWindows, Windows 4GL и другие средства

значительно упрощают построение TP-приложений клиент-сервер, поддерживающих

более сотни пользователей на каждом сервере. Правда, масштабирование

системы для обслуживания значительно большего числа пользователей требует

разделения задачи на несколько меньших серверов или использования

традиционных мониторов обработки транзакций типа Tuxedo, Encina, ACMSxp или

CICS. Программное обеспечение для автоматизации построения подобного рода

систем клиент-сервер может быть реализовано с помощью инструментальных

средств типа Ellipse и Forte.

Таким образом, времена изменились. Полным ходом идет процесс перевода на

массовую технологию систем, ранее базировавшихся на мэйнфреймах.

Программное обеспечение массового потребления установило и новые точки

отсчета в области ценообразования.

Системы управления базами данных (СУБД) являются одним из наиболее

распространенных классов прикладных систем для серверов, выпускаемых

большинством компаний-производителей компьютерной техники. Следует

отметить, что приложения, ориентированные на использование баз данных, и

сами СУБД сильно различаются по своей организации. Если системы на базе

файловых серверов сравнительно просто разделить по типу рабочей нагрузки на

два принципиально различных класса (с интенсивной обработкой атрибутов

файлов и с интенсивной обработкой самих данных), то провести подобную

классификацию среди приложений баз данных и СУБД просто невозможно.

Стандартный язык реляционных СУБД (SQL) намного богаче, чем набор операций

сетевой файловой системы.

Результаты испытаний многих систем на тестах TPC-A, TPC-B, TPC-C и TPC-D

продемонстрировали, что на сегодняшний день имеются все предпосылки

(необходимая производительность и соответствующее ПО) для полного переноса

приложений оперативной обработки транзакций и систем поддержки принятия

решений с мэйнфреймов на системы, построенные на базе микропроцессоров. При

этом одной из актуальных задач является выбор аппаратно-программной

платформы и конфигурации системы.

Оценка конфигурации все еще остается некоторым видом искусства, но к ней

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

система должна рассматриваться как ряд соединенных друг с другом

компонентов. Ограничения производительности некоторой конфигурации по

любому направлению (например, в части организации дискового ввода-вывода)

обычно могут быть предсказаны исходя из анализа наиболее слабых

компонентов.

Поскольку современные комплексы почти всегда включают несколько

работающих совместно систем, точная оценка полной конфигурации требует ее

рассмотрения как на макроскопическом уровне (уровне сети), так и на

микроскопическом (уровне компонентов или подсистем).

1.2 Исследование предметной области

В последние годы экономическая система нашей страны переживает бурное

развитие. Несмотря на существующие недостатки российского законодательства,

ситуация неуклонно меняется к лучшему. Прошли времена, когда можно было

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

Сегодня все больше банков делает ставку на профессионализм своих

сотрудников и новые технологии.

Трудно представить себе более благодатную почву для внедрения новых

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

задачи, которые возникают в ходе работы банка достаточно легко поддаются

автоматизации. Быстрая и бесперебойная обработка значительных потоков

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

организации. В соответствии с этим очевидна необходимость обладания

вычислительной сетью, позволяющей обрабатывать все возрастающие

информационные потоки. Кроме того, именно банки обладают достаточными

финансовыми возможностями для использования самой современной техники.

Однако не следует считать, что средний банк готов тратить огромные суммы на

компьютеризацию. Банк является прежде всего финансовой организацией,

предназначенной для получения прибыли, поэтому затраты на модернизацию

должны быть сопоставимы с предполагаемой пользой от ее проведения. В

соответствии с общемировой практикой в среднем банке расходы на

компьютеризацию составляют не менее 17% от общей сметы годовых расходов.

Интерес к развитию компьютеризированных банковских систем определяется не

желанием извлечь сиюминутную выгоду, а, главным образом, стратегическими

интересами. Как показывает практика, инвестиции в такие проекты начинают

приносить прибыль лишь через определенный период времени, необходимый для

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

средства в программное обеспечение, компьютерное и телекоммуникационное

оборудование и создание базы для перехода к новым вычислительным

платформам, банки, в первую очередь, стремятся к удешевлению и ускорению

своей рутинной работы и победе в конкурентной борьбе.

Информатизация банка не может быть успешной и без предварительного

анализа и моделирования. Даже покупка готового продукта предполагает

понимание особенностей своего банка и информационных возможностей

приобретаемой системы.

Создавая информационную модель банка, следует прежде всего обратить

внимание на объекты (сущности) системы и их отношения, направление и

характер потоков информации, которыми обмениваются эти объекты (а также на

вид и характер носителей этой информации – бумажные документы, телефонные и

электронные сообщения и пр.), и на операции, которые производятся над

информационными потоками, порождая, поглощая и видоизменяя их.

Информационная система банка – настолько сложная и переменчивая

структура, что изначально ставить задачу точного и однозначного ее описании

и моделирования не только нереалистично, но и методически неверно.

Необходимо с самого начала ориентироваться на создание гибкой модели в

условиях частичной неопределенности. Гибкость и легкость перестраивания

модели согласно ежедневно выявляющимся требованиям банковской системы –

свидетельство высокого качества разработки, залог ее успешного внедрения и

долгой жизни.

Современные технические средства сделали вполне реализуемой давнюю мечту

специалистов о создании систем, действующих по «безбумажной» технологии. Но

переход на такую технологию обработки информации не означает полного отказа

от бумажных документов. Для нужд обмена с партнерами, для работы с

аудиторами и контролирующими организациями, для документарной фиксации

внутрибанковского оборота подготовка твердых копий, заверенных подписями

ответственных лиц, остается необходимой и сейчас. Тем не менее происходит

смена акцентов, и становым хребтом информационной системы становятся данные

в электронной форме, а необходимая документация продуцируется как отражение

электронных данных на бумажных носителях. Только в отдельных случаях

(например, при введении "электронной подписи"), когда юридический статус

электронного сообщения равен статусу бумажного документа, удается полностью

отказаться от бумажного документооборота. Преимущества безбумажной

технологии всегда были достаточно очевидны, а сегодня стали практически

реализуемыми и экономически эффективными.

Применение безбумажных технологий ставит проблему оптимизации

распределения информации между бумажными и электронными носителями. С этих

позиций банковскую информацию можно разделить на три класса:

- данные, участвующие в расчетах (они обязательно должны быть представлены

в электронной форме);

- часто используемая и поддающаяся формализации дополнительная информация

(ее также целесообразно хранить в электронной форме);

- детальная и трудно формализуемая, в частности текстовая, информация (ее

лучше хранить на бумажных носителях).

При одновременном хранении документов как в бумажной, так и в электронной

форме существенным становится вопрос аутентичности формализованного и

общеупотребительного способов представления информации в соответствующих

документах. Одним из способов решения этой проблемы является

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

документ должен пройти автоматизированную регистрацию, а подготовка всех

исходящих документов дня, особенно связанных с переводом средств, должна

происходить только через и после внесения необходимых изменений в базы

данных.

Проблема надежности информационной системы в банковском деле имеет особое

значение. Неполнота или недостоверность информации, несвоевременность и

ошибки при ее обработке оборачиваются не только немедленными финансовыми

потерями, но и утратой доверия к банку.

Выбор АБС. Самой главной задачей компьютерного департамента банка

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

вариантов АБС или выбор стратегии разработки или модернизации существующей

АБС. Рассмотрим критерии такого выбора.

Требования к сложной банковской системе существенно зависят от объема

операций, проводимых банком. Целью является создание АБС, которая

обеспечивала бы персонал и клиентов банка необходимыми видами услуг, при

условии, что расходы на создание и эксплуатацию не превышают доходов от

внедрения АБС. Для выбора наиболее удачного решения необходимо учитывать:

Стоимость АБС. Здесь следует обратить внимание на выбор вычислительной

платформы, сетевого оборудования и ПО. Немаловажна и стоимость обслуживания

и сопровождения системы. Важно учитывать стандартность платформы и число

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

поставщиков увеличивает шансы найти более дешевое решение.

Возможность Масштабирования. В случае роста банка стоимость модернизации

при неудачном выборе резко возрастает. Необходимо, чтобы выбранная

вычислительная платформа допускала бы постепенное наращивание ресурсов в

тех частях системы, где это требуется.

Использование существующих ресурсов. От эффективности использования уже

имеющихся компьютеров, сетей и каналов связи существенно зависят и затраты

на построение АБС.

Наличие системы защиты информации. Безопасность данных является одним из

главных требований к АБС. Должна быть предусмотрена как устойчивость работы

при неправильных действиях персонала, так и специализированные системы

защиты от преднамеренного взлома АБС с корыстными или иными целями. На

сегодняшний день безопасность АБС так важна, что мы рассмотрим этот вопрос

подробнее. Система защиты и безопасности информации в АБС предполагает

наличие:

1) Средства физического ограничения доступа к компьютерам АБС

(идентификационные карточки, съемные блокирующие устройства и т.п.).

2) Предоставление полномочий, привилегий и прав доступа к АБС на уровне

отдельного пользователя (сотрудника или клиента банка).

3) Средства централизованного обнаружения несанкционированных попыток

проникнуть к ресурсам АБС, дающие возможность своевременно принять

соответствующие меры.

4) Защита данных при их передаче по каналам связи (особенно актуально при

использовании открытых каналов связи, например сети Internet). Здесь

возможно использование "цифровой электронной подписи" и других

криптографических методов.

5) Надежность системы. Отказы отдельных элементов АБС не должны приводить к

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

устойчивость работы АБС в условиях дестабилизирующих факторов (например

помех в линиях связи или ошибочных действий персонала банка).

6) Наличие средств восстановления при сбоях. В АБС должны быть

предусмотрены средства для прогноза, фиксации и локализации различных

нештатных ситуаций и отказов оборудования (таких как: повреждений и

перегрузок каналов связи; перегрузок устройств внешней памяти; нарушения

целостности БД; попыток несанкционированного доступа в систему и т.д.)

7) Возможность адаптации к изменениям финансового законодательства или

структуры банка и другим событиям.

8) Возможность работы в режиме реального времени. В настоящее время системы

типа OLTP (On-line Transaction Processing) становятся все более

распространенными при создании АБС. Внедрение систем OLTP требует от

банка весьма больших инвестиций, но преимущества таких систем

оправдывают все затраты.

Программные Платформы и Базы Данных. Среди операционных систем для АБС

лидирует связка DOS + Novell (в качестве программной платформы DOS на

рабочих станциях и операционная система Novell NetWare на файл-серверах) –

47,5% банков предпочитают именно такую, наиболее доступную в финансовом

отношении конфигурацию. На втором месте среди операционных систем, в

«угрожающей близости» к Novell NetWare находится Windows NT, ее

предпочитают 43,7% банков. Поскольку третье место занимает связки

операционных систем Windows/Windows'95 - 32,2%, то здесь явно заметен

качественный рост влияния продуктов фирмы Microsoft на развитие банковских

технологий. Всего лишь четвертое место с показателем 29,0% занимает ОС

UNIX. Хотя по динамике изменений в 1994 – 1996 гг. казалось, что разрыв

между вторым местом UNIX и бессменно лидирующей связкой DOS + Novell

NetWare неизбежно сократится.

Собственно эта тройка (четверка) операционных систем – Novell, Windows

(NT), UNIX – и составляет большинство программных платформ в российских

банках, поскольку идущие на пятом-шестом местах OS/400 (на аппаратных

средствах AS/400) и ОS/2 занимают незначительные доли рынка: 4,9 и 3,3%

соответственно. На последнем, седьмом месте находится VAX/VMS с минимальной

долей – 0,5%.

Соответственно распределению предпочтений по ОС среди СУБД лидирует

«родной» для Novell NetWare менеджер записей Btrieve – 42,6% банков

предпочитают именно эти технологии. Второе место с небольшим отрывом

занимает профессиональная СУБД Oracle – 35,5%.

Два явных лидера среди СУБД Btrieve и Oracle – опережают в три-четыре

раза идущую на третьем месте Sybase (11,5%) и в пять-шесть раз занимающую

четвертое место Informix (7,7%).

Эти соотношения позволяют сделать грубую оценку возможного перехода

банков пользователей технологий на основе Btrieve на банковские системы

нового поколения на основе СУБД Sybase без замены фирмы-разработчика. Так,

«новые Sybase-АБС» подготавливаются к промышленному внедрению в основном

тремя фирмами – лидерами рынка: «Диасофт», «R-Style Software Lab.» и

«Кворум», чьи базовые системы сегодня реализованы на основе Btrieve.

Соотношение 42,6% против 11,5% говорит о том, что примерно одна пятая часть

банков – пользователей Btrieve-AБC в перспективе может перейти на Sybase-

АБС.

Особого комментария заслуживает пятое место Microsoft SQL Server с

небольшим показателем 4,9%. Огромная популярность операционной среды

Windows в сфере банковских технологий, казалось бы, могла обеспечить этой

«дочерней СУБД» более высокие цифры. Но здесь важно следующее: сам

инструментарий MS SQL так интенсивно модернизируется и меняется, что

серьезные финансовые системы типа АБС, требующие высокой надежности и

сделанные на его основе, просто не успевают пройти необходимый цикл

тестирования, отладки и обкатки. Конечно же, это существенно сдерживает

возможности распространения финансовых приложений на основе Microsoft SQL

Server.

Шестое место занимает СУБД Progress – ее предпочитают 3,8% банков, далее

с малыми значениями идут Interbase – 2,2%, Gupta/Centura – 1,6%, DB/2 –

1,1%, Ingress – 0,5%.

Примерно один из девяти банков предпочитает работать сразу на нескольких

СУБД. Если Windows NT и Windows'95 считать как одну и ту же ОС, то выходит,

что примерно каждый третий российский банк работает в гетерогенных

программных средах.

Известность фирм-разработчиков. Расчет рейтинговой известности фирм давно

известен и неоднократно публиковался. И хотя его методика не совсем

совершенна, только ее постоянство и неизменность позволяют корректно

сравнивать показатели, полученные в разное время.

Основой расчета рейтинга известности и других сравнительных показателей

являются ответы банков на вопросы анкеты об используемых программных

продуктах, планах по модернизации АБС и мнения отдельных банкиров о

состоянии и развитии рынка банковских программных технологий.

(по материалам третьего форума разработчиков)

|АБС |ьзуют|тност|я |ектив|и бы |купит|нг |

| | |ь | |ная |узнат|ь |Извес|

| | | | | |ь | |тност|

| | | | | | | |и |

|0 |1 |2 |3 |4 |5 |6 |7 |

|R-Style Soft. |37 |141 |37 |22 |19 |14 |380 |

|Lab. | | | | | | | |

|Диасофт |22 |153 |31 |13 |11 |12 |320 |

|ФОРС |6 |58 |21 |19 |10 |5 |170 |

|ПрограмБанк |13 |69 |4 |4 |2 |2 |117 |

|ЦФТ |10 |37 |9 |9 |5 |7 |112 |

|Кворум |13 |37 |6 |3 |1 |5 |92 |

|Инверсия |9 |38 |3 |2 |0 |1 |68 |

|Асофт |4 |19 |2 |0 |0 |0 |31 |

|МИМ-Технология |6 |3 |3 |1 |1 |1 |26 |

|Midas-Kapiti |3 |7 |3 |1 |4 |0 |25 |

|CSBI EE |2 |9 |1 |1 |2 |1 |21 |

|Temenos Systems|0 |1 |1 |3 |3 |0 |12 |

|Мебиус |4 |1 |0 |0 |0 |0 |9 |

|Канопус |2 |2 |1 |0 |0 |0 |8 |

|Киевский ОДБ |4 |0 |0 |0 |0 |0 |8 |

|БИС |1 |4 |0 |0 |0 |0 |6 |

|Сибирский Банк |0 |1 |1 |0 |0 |1 |5 |

|UniSAB |1 |1 |1 |0 |0 |0 |5 |

Примечания:

Рейтинг известности = “2” + “5” + 2*(“1” + “3” + “4” + “6”);

Заметно первое изменение на Олимпе банковской автоматизации; поколеблено

единоличное лидерство фирмы «Диасофт», длившееся с начала 1994 г. до первой

половины 1997 г. включительно (завидное постоянство!). Теперь она занимает

второе место. Первую строчку с отрывом в 15,8% от второго места (380 баллов

против 320) заняла «R-Style Software Lab.». Каждая из этих лидирующих фирм

почти вдвое опережает идущую на третьем месте фирму ФОРС (170 баллов) и

почти втрое следующих за ними – фирму «ПрограмБанк» (117 баллов – 4 место)

и ЦФТ (112 баллов – 5 место).

Еще три фирмы – «МИМ-Технология», «Канопус», БИС – занимают неплохие

места; девятое, четырнадцатое и шестнадцатое соответственно. Всего банкиры

при ответах на вопросы называли 41 фирму.

Понятно, что абсолютная известность определяется как маркетинговой

активностью фирмы, так и распространенностью и перспективностью ее

программных технологий. Для характеристики потенциала фирм к расширению

бизнеса, был введен дополнительный показатель – «Относительный рейтинг

известности», показывающий усредненные (в пересчете на один банк)

показатели известности фирмы.

|АБС |ьзуют|тност|я |ектив|и бы |купит|нг |

| | |ь | |ная |узнат|ь |Извес|

| | | | | |ь | |тност|

| | | | | | | |и |

|0 |1 |2 |3 |4 |5 |6 |7 |

|ФОРС |100% |9,67 |3,50 |3,17 |1,67 |0,83 |18,83|

|Диасофт |100% |6,95 |1,41 |0,59 |0,50 |0,55 |10,00|

|ЦФТ |100% |3,70 |0,90 |0,90 |0,50 |0,70 |6,70 |

|R-Style |100% |3,81 |1,00 |0,59 |0,51 |0,38 |6,30 |

|ПрограмБанк |100% |5,31 |0,31 |0,31 |0,15 |0,15 |6,23 |

|Инверсия |100% |4,22 |0,33 |0,22 |0,00 |0,11 |4,89 |

|Кворум |100% |2,85 |0,46 |0,23 |0,08 |0,38 |4,00 |

|МИМ |100% |0,5 |0,5 |0,17 |0,17 |0,17 |1,50 |

В относительном рейтинге картина значительно изменилась – на первое место

с большим отрывом от других вышла фирма ФОРС (18,83 балла). Вторую строчку

очень уверенно занимает «Диасофт» (10,00), далее идет весьма плотная по

показателям группа – ЦФТ (6,70), «R-Style Software Lab.» (6,30) и

«ПрограмБанк» (6,23).

Привлекательность АБС. Такой показатель, как «коэффициент

привлекательности» рассчитывается по результатам опроса банков –

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

вопросы: «Удовлетворяет ли Ваш банк используемая автоматизированная

банковская система?» и «Собирается ли Ваш банк и ближайшее время менять или

модернизировать используемую АБС (отметьте и при необходимости расшифруйте

нужные строки)?» – с вариантами ответов. В расчетах также учитывались

значения графы “6” табл. 1 (число банков, собирающихся перейти на АВС

каждой из фирм).

Поскольку разные представители одного и того же банка могли отвечать на

один и тот же вопрос по разному, а в одной анкете респондент отметил даже

несколько позиций, то для устранения некорректности вычислений по каждой

фирме были рассчитаны максимальное и минимальное значения коэффициента.

При расчете максимального коэффициента все «многозначности» в ответах

представителей одного банка трактовались «в пользу» фирмы-разработчика, а

при расчете минимального – «против».

Вычисление такого диапазона значений, пожалуй, более корректно, чем

вычисление методической погрешности по одному Банку. Поскольку величина

расчетной погрешности по большинству показателей меньше, чем разница

минимального и максимального значений, введение диапазона значений

позволяет более корректно учитывать многозначные ответы.

Смысл этого коэффициента относительно несложен. Если все пользователи

какой-либо АБС вполне удовлетворены этой системой, собираются обновлять

версии или ни чего не собираются в ней менять, то эта АБС еще будет жить на

рынке и ее «коэффициент привлекательности» равен единице. Если же какие-

либо банки собираются переходить на эту ЛБС, то у нее есть перспективы

дополнительного развития, и ее «коэффициент привлекательности» выше

единицы. А если все пользователи отрицательно оценивают удовлетворенность

системой и собираются закупать другую российскую или зарубежную разработку,

то данная АБС морально устаревает и ее «коэффициент привлекательности»

близок к минус единице.

Значения коэффициента, близкие к плюс единице, можно считать признаком

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

в частности. Любые положительные значения «коэффициента привлекательности»

считаются вполне приемлемыми, а отрицательные – служат сигналом

неблагополучия. Близкие к нулю значения позволяют говорить о некотором

снижении числа банков-пользователей.

|и |п|ли АБС? |АБС |ательно|

| |р| | |сть |

| |о| | | |

| |ш| | | |

| |е| | | |

| |н| | | |

| |о| | | |

| | |Да|Ск|Не|Ск|Не|Не|Но|Др|За|До|До|Ку|мах|min|

| | | |ор|по|ор|т |т |ву|уг|ру|ра|ра|пи| | |

| | | |ее|лн|ее| | |ю |ую|бе|бо|бо|ть| | |

| | | |Да|ос|не| | |ве|ро|ж.|тк|тк|эт| | |

| | | | |ть|т | | |рс|с.|АБ|а |а |у | | |

| | | | |ю | | | |ию|АБ|С |мо|АБ|АБ| | |

| | | | | | | | | |С | |ду|С |С | | |

| | | | | | | | | | | |ле| | | | |

| | | | | | | | | | | |й | | | | |

|0 |1|2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14 |15 |

|Форс |6|1 |3 |3 |0 |3 |1 |4 |0 |0 |3 |0 |5 |1,4|1,2|

| | | | | | | | | | | | | | |0 |0 |

|ЦФТ |1|1 |5 |3 |1 |1 |2 |6 |1 |1 |2 |0 |7 |1,1|0,9|

| |0| | | | | | | | | | | | |8 |7 |

|R-Style |3|2 |17|16|1 |1 |3 |34|2 |2 |11|1 |14|1,0|0,8|

| |7| | | | | | | | | | | | |0 |6 |

|Midas-Kapit|3|2 |0 |1 |0 |0 |0 |2 |0 |0 |1 |0 |0 |1,0|0,8|

|i | | | | | | | | | | | | | |0 |8 |

|Кворум |1|0 |8 |4 |2 |0 |5 |6 |0 |0 |3 |0 |5 |0,9|0,9|

| |3| | | | | | | | | | | | |9 |0 |

|Диасофт |2|2 |8 |9 |2 |1 |6 |13|3 |1 |7 |2 |12|0,9|0,8|

| |2| | | | | | | | | | | | |8 |2 |

|МИМ |6|1 |3 |2 |0 |0 |0 |4 |0 |0 |1 |0 |1 |0,9|0,9|

| | | | | | | | | | | | | | |0 |0 |

|Мебиус |4|0 |1 |3 |0 |0 |2 |2 |0 |0 |0 |0 |0 |0,6|0,6|

| | | | | | | | | | | | | | |3 |3 |

|ПрограмБанк|1|0 |5 |5 |2 |2 |4 |7 |3 |0 |1 |0 |2 |0,5|0,3|

| |3| | | | | | | | | | | | |0 |2 |

|Инверсия |9|0 |3 |4 |1 |1 |0 |6 |5 |0 |2 |0 |1 |0,2|-0,|

| | | | | | | | | | | | | | |5 |01 |

|АСофт |4|0 |1 |2 |0 |1 |0 |3 |2 |1 |0 |0 |0 |0,1|-0,|

| | | | | | | | | | | | | | |3 |13 |

|Собственная|5|5 |10|30|8 |6 |7 |8 |15|1 |19|21|0 |- |- |

| |9| | | | | | | | | | | | | | |

|Киевский |4|0 |0 |0 |4 |0 |0 |0 |3 |0 |0 |1 |0 |-0,|-0,|

|ОДБ | | | | | | | | | | | | | |91 |91 |

В первую очередь обращает внимание высокая плотность семи верхних

результатов. Формально третье место «R-Style Software Lab.» и формально

шестое место фирмы «Диасофт» разделяют всего 0,02 по максимальному значению

и 0,04 – по минимальному; при этом пересечение диапазонов для этих фирм –

0,12. Кроме того, заметим, что среднее по всем фирмам значение

«коэффициента привлекательности» весьма велико. Следовательно, можно

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

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

проблемы со своими разработчиками, а не заменять АБС на «самую мощную и

полно функциональную».

Стратегии развития АБС. Семилетняя история автоматизации российских

банков позволяет узнать: есть ли общие черты в путях автоматизации

российских банков. При описании базовых стратегий технологического развития

банков (в части программных решений) удобно использовать классификацию,

предложенную В. Колсаноным (в прошлом – начальник управления банковских

технологий Тверьуниверсалбанка). Любая стратегия технологического развития

банка подразумевает формулирование функциональных и экономических

требований (с различной степенью детальности) к системе автоматизации и

соответствующую реализацию этих требовании.

Собственная разработка. Этот этап в развитии автоматизированных

технологий в разное время был пройден подавляющим большинством российских

банков, поэтому ему стоит уделить внимание. В этот же сегмент включены так

называемые «эксклюзивные» разработки, выполненные под заказ одного банка и

не поддающиеся тиражированию. Основные признаки подобной стратегии:

- первыми автоматизируются исторически «базовые» функции банковской

системы – бухгалтерия и расчетно-кассовое обслуживание, существующие по

крайней мере в двух-трех десятках тиражируемых российских систем;

- не разделены служба разработки и служба эксплуатации банковской системы,

не выделены моменты передачи версий банковской системы в эксплуатацию,

и, как правило, понятие «версия АБС» вообще не приемлемо;

- неполноценное документирование системы (частичное наличие проектной и

эксплутационной документации) либо полное отсутствие документации.

- С точки зрения специалистов, имеющих опыт создания и внедрения АБС в

крупных и средних банках, разумными основаниями для собственной

разработки могут являться:

- интеграция нескольких систем при числе автоматизированных рабочих мест в

банке более 200;

- разработка целых модулей системы при числе автоматизированных рабочих

мест в банке более 500;

- наличие у банка уникальных бизнес требований и уникальной стратегии

информатизации, удовлетворить которые не в состоянии ни

специализированные системные интеграторы, ни разработчики промышленных

тиражируемых решений. В этом случае требования и стратегия должны быть

явно сформулированы во внутренних документах банка с соответствующим

контролем (аудитом) их реализации;

- столь динамичное развитие банка, что бизнес требования не могут быть

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

является только макетом будущей информационной системы. Сегодня это уже

в прошлом: наступает этап стабильного развития банковской системы.

С точки зрения специалистов, имеющих опыт профессионального банковского

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

может быть оправдана:

- для небольшого по количеству персонала одно-филиального банка с

небольшим количеством ежедневных операций – «домашнего» банка крупной

промышленной либо торговой компании, консорциума, холдинга (примеров

тому довольно много);

- как связующее звено для автоматизации головного офиса многофилиального

банка при установке однотипных тиражируемых решений в филиалах и

отделениях;

- для узкоспециализированного банка со значительным преобладанием

операций, не характерных для банковского сообщества в целом;

- для крупного универсального банка в части автоматизации передовых

финансовых технологий, пока еще недостаточно освоенных российским

банковским рынком. При отсутствии адекватного предложения на рынке

тиражируемых решений такая разработка бывает оправданной в части

указанных финансовых технологий вплоть до их сопряжения с основной AБC.

Эта причина становится все менее определяющей, поскольку промышленные

решения ведущих российских разработчиков быстро развиваются в

функциональном отношении;

- для среднего банка, имеющего целью стать «законодателем технологической

моды» в области автоматизации финансовых операций при сильной динамике

развития банковского рынка в целом (например, Инком банк, Кредо банк,

Сибирский Торговый банк, Оптимум-банк). Однако и эта причина осталась в

прошлом как из-за нынешней стабилизации банковского рынка, так и из-за

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

что правильнее изначально ставить задачу создания «отчуждаемых

технологий», а не «технологий для себя».

Основным недостатком собственной разработки является сложность интеграции

консолидированных технологий в получаемые проектные или программные

решения. Кроме того, обычно собственные разработки характеризуются низким

(в большинстве случаев) качеством закладываемых проектных проработок,

которые позволяют получить решение проблемы лишь «на сегодня», но не дают

возможности оперативно отслеживать изменение внешних условий в будущем

(отчетность, развитие финансового рынка, введение новых банковских

операций, развитие информационных технологий вообще).

Еще одна опасность заключена в неоправданном завышении приоритетов

системных требований (аппаратное обеспечение, операционная среда,

инструментарий разработки, коммуникации) перед бизнес-требованиями

(функциональность, надежность, безопасность, поддержание и развитие

технологий).

Одним из негативных последствий этого преобладания является то, что в

банке могут более или менее успешно решаться только текущие проблемы

автоматизации типа «не проводится документ», «потерян клиентский платеж»,

«требуется более мощный компьютер», «нет связи с филиалом/отделением».

Кроме того, хотя все пользователи знают, что в далеком будущем банк будет

работать на «самой лучшей» программно-аппаратной платформе типа Sun +

Oracle или Hewlett-Packard + Informix, никто не знает, как будет

развиваться автоматизированная система в среднесрочной перспективе и какие

финансовые технологии «завтрашнего дня» можно использовать «уже сегодня»,

хотя бы в ограниченном объеме.

Замеченная еще в 1995 – 1996 гг. тенденция к снижению относительного

качества и количества собственных разработок сегодня получает дальнейшее

развитие. В 1997 г. существенно сузится тот сегмент технологий банковской

автоматизации, где представлены собственные разработки. В дальнейшем, на

рынке останутся лишь те, которые выполнены по законам классической

программной инженерии: Техническое задание > Технический проект >

Информационная модель > Прототип АБС > Система комплексной автоматизации.

Корпоративно-субъективная. Цель такой стратегии состоит в реализации

любых требований всех (или почти всех) банковских пользователей.

Финансирование стратегии ведется в зависимости от возможностей банка и

искусства руководителя управления (департамента, отдела) автоматизации,

Страницы: 1, 2, 3, 4, 5, 6, 7

Рефераты

Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT