Журнал «Компьютерра» №41 от 08 ноября 2005 года
Шрифт:
Максимальные доли серийного решения в этих сферах достигают только 14,06% и 15,64% соответственно[Данные исследования, проведенного «Аналитическим банковским журналом»]. О стоимости своих решений компании говорить не любят, так как слишком много факторов влияют на конкретное предложение: требуемая функциональность, характеристика банка, степень доработки системы под заказчика, объем консалтинговой поддержки и т. д. Можно лишь отметить, что стоимость одной лицензии на АБС в минимальной конфигурации, базирующейся на дешевой СУБД (промышленные системы вроде Oracle - самый дорогой вариант, используемый для автоматизации крупных организаций), колеблется от 300 до 1000 долларов.
Практически все АБС имеют
Во-вторых, постепенная интеграция отдельных модулей позволяет банку менее болезненно пережить автоматизацию, добавляя очередной программный компонент по мере необходимости. Установка такого ПО - не просто затраты времени и денег, но и
обследование бизнес-процессов;
адаптация как системы (например, содержащихся в ней шаблонов отчетности) под специфику банка, так и ряда старых технологий банка под АБС;
конвертация данных в новую систему;
обучение персонала;
в ряде случаев необходимость разработки шлюзов для взаимодействия с другими ИТ банка (наличие приложений от разных производителей в рамках одного предприятия в фольклоре ИТ-специалистов называется «зоопарком ПО»);
тестовый период эксплуатации.
Понятно, что при одновременном внедрении всех модулей на банковский ИТ-департамент (да и на другие службы) обрушивается куча разнообразных проблем, могущих привести к катастрофическим последствиям, которые, кстати, ощутят на себе и клиенты. Кроме того, для автоматизации отдельных функций банки иногда прибегают к сторонним продуктам. Например, часто применяется специализированное решение для интернет-банкинга (вроде iBank 2 от БИФИТ) или для биржевой торговли («Инвестор» от «Инист»).
В-третьих, политика лицензирования отдельных модулей повышает продажи разработчиков и дистрибьюторов. Покупать АБС в максимальной поставке, а значит, платить за невостребованные возможности банк просто не согласится. Да и количество банков в России, нуждающихся в суммарной функциональности современных систем, остается довольно скромным.
У отечественных банков, выходящих на региональные рынки (чем сегодня в той или иной степени озабочены все крупные финансовые организации), возникают еще и проблемы обеспечения совместимости ПО и обмена данными со своими филиалами. Самая частая причина несовместимости систем в головном и дополнительных офисах - политика продвижения на рынке путем поглощения мелких банков-аборигенов, работающих на другой АБС. Если руководство не стремится к централизации управления в головном офисе, то каждому филиалу достается собственная система (центр может просто разослать копии своей АБС[Обычно тиражируются небольшие АБС. Некоторые из продуктов даже позиционируются как оптимальные для распространения по филиалам (например, RS-Bank на платформе Pervasive)]), а обмен данными сводится к пересылке бумажных носителей или файлов. Такой способ требует наименьших затрат, и это, пожалуй, его единственное достоинство. Управляемость же банков в этом случае минимальная. Обслуживая клиентов, филиал даже не имеет сведений о реальном состоянии счетов, по крайней мере до очередного сеанса связи.
Более приемлемый (и часто используемый вариант) - наличие централизованной АБС (ЦАБС), под которой понимают как единый мощный комплекс, так и все системы филиалов, физически располагающиеся в головном офисе. В этом случае в системе используются развитые
Вариант «попроще» - с концентрацией филиальных АБС в одном месте. Филиалу достается программный клиент для удаленного доступа сотрудников к своей АБС и обмена данных с головным офисом. Для реализации этого варианта банку придется сформировать единый ВЦ и организовать дублируемые каналы широкополосной связи (чтобы филиалы имели доступ к собственным АБС).
Рассмотрим модульную структуру систем на примере 5NTe Bank (в частности, ее модулями пользуются Газпромбанк и Внешторгбанк), в которой весь спектр банковских операций разнесен по следующим блокам:
корпоративное обслуживание;
розничное обслуживание;
операции на финансовых рынках;
удаленное обслуживание;
обязательная и аналитическая отчетность;
управленческий учет и бюджетирование.
Подробно рассмотреть работу всех модулей в рамках одной статьи невозможно, так что на сей раз ограничимся более близкими большинству читателей функциями розничного блока, а с остальными познакомимся в следующих публикациях на эту тему.
Ритейл-модуль - один из самых сложных по структуре. Это связано с обилием разноплановых направлений, которые он призван автоматизировать: потребительские кредиты, депозиты, переводы, обмен валюты, коммунальные платежи и т. д. Если рассмотреть структуру на примере RS-Retail, то там каждому из предлагаемых финансовых продуктов соответствует отдельное приложение, автоматизирующее тот или иной набор операций.
Автоматизированное рабочее место (АРМ) сотрудника, обслуживающего физических лиц (контролера, кассира, бухгалтера), создается из нескольких приложений. То есть в АРМ сосредотачивается весь спектр возможностей, необходимых пользователю, и в этом случае сотрудник фронт-офиса (то есть корпоративного подразделения, взаимодействующего с клиентами[Другое подразделение - бэк-офис - отвечает за учет совершаемых операций]) может даже не знать, как именно осуществляется в его банке бухгалтерский учет. Он должен только уметь приветливо улыбаться и вносить данные в нужные поля (тут, впрочем, он может воспользоваться подсказками системы). Вообще, независимо от концепции системы, почти все розничные решения призваны свести труд оператора к минимуму.
Архитектура учета в системе розничного обслуживания у разных продуктов может быть разной. Например, в 5NTe RETAIL она построена на двух базовых элементах: договоре и операциях. Последние регламентируются понятиями жизненного цикла и календаря. Договора связывают со счетами, клиентами и друг с другом, и в них определяются все положения об оказании той или иной услуги. Операция - это элементарное, настраиваемое действие обработки документа сотрудником. Доступ к изменению настроек документов на разных этапах исполнения разграничен дополнительным элементом концепции - жизненным циклом операции. Данные о периодических операциях (таких как начисление процентов) записываются в другом элементе - календаре событий.