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

Боюсь, мои опасения оправдались: панегирик ContentSaver скушал все отведенное «Голубятне» пространство, так что разговор об «Архивариусе 3000» вынужденно откладывается на неделю. Но нет худа без добра: программа Евгения Троицкого до того хороша и своевременна, что достойна отдельного разговора.

Линки, помянутые в «Голубятне», вы найдете на internettrading.net/guru.

Одна из отечественных компаний-разработчиков банковского ПО опубликовала среднестатистические показатели своих заказчиков. Оказывается, крупный российский банк, обслуживающий физических лиц, имеет в среднем двести одновременно работающих сотрудников, более двадцати филиалов, около двухсот тысяч клиентов, семьсот тысяч счетов и обрабатывает транзакции по тремстам тысячам пластиковым картам. А если учесть необходимость соответствия российской специфике, которая выражается, например, в чехарде нормативных документов от ЦБ, МНС и других уважаемых государственных структур[Так, год назад панику среди банкиров посеяло распоряжение контролирующих органов о переводе всей бухгалтерии на Международные стандарты финансовой отчетности (МСФО)], то на выходе получим техническое задание для разработки информационной системы, обеспечивающей работу отечественного банка. Очевидно, что стандартные варианты автоматизации, применяемые в промышленности или торговле (ERP, CRM), здесь не годятся. «Финансовые супермаркеты» нуждаются в особых системах, мультифункциональных монстрах, которые смогут обработать огромные потоки разноформатных данных, связать множество филиалов и дополнительных офисов в единый финансовый организм, исключить возможность малейшей ошибки (ведь речь идет о чужих деньгах!) и полностью адаптироваться к специфике конкретного банка.

Спрос рождает предложение, а потому в России уже существует рынок банковских программных комплексов. Зарубежные продукты (Midas DBA, Bankmaster, Olympics, Symbols, Globus и др.) популярностью у отечественных банков не пользуются, - во-первых, из-за высокой цены (до нескольких миллионов долларов за одно внедрение) и, во-вторых, из-за особенностей отечественной финансовой системы. Прежде всего, отличаются принципы формирования отчетности - одной из главных функций банковского ПО. Даже прошлогодний переход российских банков на МСФО не способствовал снижению пресловутой национальной «специфичности». Дело в том, что учет в организациях по-прежнему ведется по правилам Центробанка, а отчетность по МСФО составляется из отчетности ЦБ позднее - методом трансформации. Кроме того, западные продукты не рассчитаны на постоянное внесение изменений из-за обновления законодательства - ведь «у них» правила игры не меняются каждый год.

В России автоматизированные банковские системы (АБС) серийно выпускают десятки компаний, из которых можно выделить нескольких лидеров: R-Style Softlab, БИС, «Диасофт», «Инверсия», «Кворум», «ПрограмБанк», «Форс» и ЦФТ[Имена некоторых компаний представляют собой аббревиатуры. БИС - Банковские информационные системы, БИФИТ - Банковские и финансовые интернет-технологии, ЦФТ - Центр финансовых технологий]. Вышеперечисленные фирмы в основном оказывают услуги крупным и средним банкам. На уровне же малых и средних банков широко распространены собственные разработки, зачастую написанные «по подобию» серийных продуктов. Например, в 2004 году уникальные системы для кредитования физических лиц использовали 21,56% российских банков, а для работы с частными вкладами - 21,96%.

Максимальные доли серийного решения в этих сферах достигают только 14,06% и 15,64% соответственно[Данные исследования, проведенного «Аналитическим банковским журналом»]. О стоимости своих решений компании говорить не любят, так как слишком много факторов влияют на конкретное предложение: требуемая функциональность, характеристика банка, степень доработки системы под заказчика, объем консалтинговой поддержки и т. д. Можно лишь отметить, что стоимость одной лицензии на АБС в минимальной конфигурации, базирующейся на дешевой СУБД (промышленные системы вроде Oracle - самый дорогой вариант, используемый для автоматизации крупных организаций), колеблется от 300 до 1000 долларов.

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

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

обследование бизнес-процессов;

адаптация как системы (например, содержащихся в ней шаблонов отчетности) под специфику банка, так и ряда старых технологий банка под АБС;

конвертация данных в новую систему;

обучение персонала;

в ряде случаев необходимость разработки шлюзов для взаимодействия с другими ИТ банка (наличие приложений от разных производителей в рамках одного предприятия в фольклоре ИТ-специалистов называется «зоопарком ПО»);

тестовый период эксплуатации.

Понятно, что при одновременном внедрении всех модулей на банковский ИТ-департамент (да и на другие службы) обрушивается куча разнообразных проблем, могущих привести к катастрофическим последствиям, которые, кстати, ощутят на себе и клиенты. Кроме того, для автоматизации отдельных функций банки иногда прибегают к сторонним продуктам. Например, часто применяется специализированное решение для интернет-банкинга (вроде iBank 2 от БИФИТ) или для биржевой торговли («Инвестор» от «Инист»).

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

У отечественных банков, выходящих на региональные рынки (чем сегодня в той или иной степени озабочены все крупные финансовые организации), возникают еще и проблемы обеспечения совместимости ПО и обмена данными со своими филиалами. Самая частая причина несовместимости систем в головном и дополнительных офисах - политика продвижения на рынке путем поглощения мелких банков-аборигенов, работающих на другой АБС. Если руководство не стремится к централизации управления в головном офисе, то каждому филиалу достается собственная система (центр может просто разослать копии своей АБС[Обычно тиражируются небольшие АБС. Некоторые из продуктов даже позиционируются как оптимальные для распространения по филиалам (например, RS-Bank на платформе Pervasive)]), а обмен данными сводится к пересылке бумажных носителей или файлов. Такой способ требует наименьших затрат, и это, пожалуй, его единственное достоинство. Управляемость же банков в этом случае минимальная. Обслуживая клиентов, филиал даже не имеет сведений о реальном состоянии счетов, по крайней мере до очередного сеанса связи.