Вслед за крупными автоматизацией занялись и небольшие банки. Они не могут себе позволить тратить на ИТ многомиллионные бюджеты, но стремятся получить тот же функционал, чтобы привлекать клиентов современными продуктами. Как уверяют разработчики ПО, которые в последнее время стали активно предлагать рынку продукты, ориентированные именно на средние и малые банки, современные технологии управления информацией вовсе не должны стоить дорого. Но сами банки отмечают «сырость» и несовершенство систем, которые им предлагают.
За пределами Садового кольца
Если раньше усилия крупных банков были сосредоточены в основном в столичных регионах, то в последние два года
Спрос, как известно, рождает предложение. Традиционно, по вполне понятным причинам, усилия большинства разработчиков автоматизированных систем были сосредоточены исключительно на работе с крупными банками и финансово-промышленными группами. Но в прошлом году сразу несколько разработчиков предложили рынку продукты, ориентированные именно на средние и малые банки. Среди них можно назвать линейку RS-Bank/Pervasive (компания R-Style Softla), «Ва-Банк ST» (компания ФОРС), «Центавр Омега» (компания «Програмбанк») и т. д.
Ориентированы такие решения на банки второго эшелона с объемом бизнеса существенно меньше 1% от рынка (то есть 50—150 млн. долларов). По оценкам EGAR Technology, объем средств, которые могут быть потрачены таким банком на ИТ-технологии (oft & hard), колеблется в пределах — от 50 тыс. до 250 тыс. долларов. При этом стоимость приобретения системы в ряде случаев может составлять всего 30—50% от общей стоимости самого проекта.
В среднем небольшие банки тратят на приобретение автоматизированной системы около 20—100 тыс. долларов (со стоимостью рабочего места в пределах 100—200 долларов). По словам начальника ИТ-департамента Спиритбанка (Тула) Александра Супрановича, расходы среднего регионального банка на ИТ за последние пару лет не превышают 500 тыс. рублей.
Упражнение на гибкость
Как утверждают компании, при разработке систем, ориентированных на небольшие банки, они не снижали требовательность к существующим решениям, а создавали принципиально новые продукты. По словам руководителя проекта «Центавр» компании «Програмбанк» Степана Сокола, большие и сложные системы практически невозможно упростить, если не ставить такую задачу на самом раннем этапе ее проектирования. «Попробуйте использовать «большую» ритейловую систему на Oracle в небольшой операционной кассе или обменном пункте! — говорит он.— Даже если компания-разработчик продаст такую систему со скидками, урежет ненужный функционал, сократит до минимума оплату своих услуг по ее обслуживанию, банку все равно придется решать проблему неадекватных затрат по эксплуатации системы». Поэтому разработчики предпочитают использовать более недорогие и простые платформы, например СУБД Pervasive.SQL или MS SQL 2000 Desktop Engine.
Главное, на чем может сыграть небольшой банк при формировании своей ИТ-архитектуры,— ее гибкость. Но реализуют эту самую гибкость в своих продуктах разработчики совершенно по-разному. По мнению руководителя отдела маркетинга EGAR Technology Михаила Талантова, лучше всего вписываются в ограниченные финансовые возможности небольших банков решения, которые позволяют организовать рабочие места на базе «тонкого клиента». В этом случае основной массив информации сосредоточен на централизованном сервере хранения, и рабочие места на удаленных точках продаж организуются за счет недорогих лицензий и связаны с главным офисом через онлайн. Специалисты R-Style полагают, что архитектура решений для малых банков должна отвечать принципам стандартизации. Процедуры и операции в такой системе строятся по одним и тем же алгоритмам и поэтому совершенно прозрачны для управления и анализа. А система работает по принципу конвейера, то есть каждая процедура разбивается на ряд отдельных операций, каждую из которых выполняет либо отдельное подразделение, либо отдельный операционист.
Но Заманский уверен, что в региональных банках люди важнее процедур, поэтому АБС прежде всего должна быть удобной для персонала и даже нравиться ему. Численность банка сравнительно невелика, и поэтому конвейер неэффективен, поскольку на каждую операцию невозможно назначить отдельного человека. Каждый сотрудник регионального банка неминуемо оказывается «мастером на все руки». С точки зрения ИТ это подразумевает наличие у АБС функции так называемого «сквозного видения» всей деятельности банка с каждого рабочего места. Это позволяет операционисту проводить весь спектр операций по одному клиенту — от проводки счетов до оформления кредита. Такая «универсальность» служащих небольшого банка, по мнению Заманского, требует преимущественно горизонтального разделения доступа, когда сотрудники одного отдела имеют полный доступ к информации по определенной группе клиентов.
Без зоопарка
По-настоящему критичным условием является, уверен он, просто сама возможность эксплуатации данной АБС в филиале без технологических «костылей», предоставляемых из центра в том числе и на установку отдельного сервера. Здесь банк вынужден тратиться на покупку дополнительного мощного оборудования для филиалов, но в то же время может сэкономить на снижении производительности центрального офиса. Тогда у банка пропадает необходимость создавать широкие и надежные каналы постоянной связи между отделениями и филиалами. Поскольку вся информация по операциям хранится в самом филиале, региональные банки могут работать на очень узких и абсолютно ненадежных каналах связи (вплоть до коммутируемых линий).
По словам Александра Супрановича, главное, на что обращает внимание малый банк при покупке новой АБС,— ее функциональная наполненность. АБС, несмотря на «небольшой» размер, должна уметь работать и с потребительскими кредитами, и с коммунальными платежами. Для такого банка принципиально важно иметь возможность работать с одним поставщиком, наращивать систему. Как правило, сначала небольшие банки устанавливают ядро системы и несколько основных модулей (книга счетов, бухучет, кредитование юридических лиц, отчетность ЦБ) и потом постепенно докупают остальные. Поскольку ни одна система из существующих на рынке, по признанию банковских специалистов, не удовлетворяет все потребности крупных структур, при развертывании системы они предпочитают брать лучшее от разных производителей и затем собственными силами интегрировать разрозненные части в одну систему. Небольшие банки не могут позволить себе такой технологический «зоопарк»
Все в одном
Поэтому продукты, ориентированные на малые банки, построены именно на модульном принципе, когда каждый технологический «блок» отвечает за определенную функцию или отдельный банковский продукт. Например, существуют так называемые розничные модули, включающие в себя решения по кредитованию физических лиц и скорингу (системы оценки кредитоспособности заемщика). Или модуль коммунальных платежей. Как заявила «Бизнесу» брэнд-менеджер компании R-Style Softlab Ольга Гроздова, при покупке продукта из линейки компании, банк получает решение по принципу «все в одном»: от автоматизации работы с вкладами и платежными картами до ипотеки и кредитования. Специалисты EGAR Technology также говорят о том, что наиболее привлекательными для банков в решении EGAR Loans является модульность решения, которая позволяет рационально расходовать средства на ее развертывание и развитие.
По мнению Гроздовой, за последний год небольшие банки изменили приоритеты при формировании своего ИТ-портфеля. С начала этого года вырос интерес к системе автоматизации традиционных розничных банковских услуг RS-Retail (работа с вкладами, платежами, переводами, пластиковыми картами и т. д.). По сравнению с прошлым годом именно это направление выросло на 70%. Талантов также говорит о новом всплеске интереса к розничным решениям со стороны небольших и средних банков.
Кроме того, региональные банки, которые раньше ориентировались исключительно на обслуживание юрлиц, приобретают и внедряют розничные решения для обслуживания сотрудников компаний. В первую очередь речь идет о модулях, обеспечивающих ведение зарплатных проектов, корпоративных карт и т. д.
Почти все небольшие банки с оборотом до 100 млн. долларов вошли в систему страхования вкладов и теперь должны вести реестры обязательств, рассчитывать и формировать страховые выплаты, готовить специализированную отчетность. Новые требования контролирующих органов к отчетности — это и новые требования к системе автоматизации, которая пополнится дополнительными модулями, что не может не радовать разработчиков.
Ксения БОЛЕЦКАЯ
