Автоматизация банков
Автоматизация банков
Разработчики ПО заинтересованы в автоматизации небольших банков. Последние не могут себе позволить тратить на ИТ многомиллионные бюджеты, но стремятся получить тот же функционал, чтобы привлекать
клиентов современными продуктами. Как уверяют разработчики ПО, которые в последнее время стали активно предлагать рынку продукты, ориентированные именно на средние и малые банки, современные технологии
управления информацией вовсе не должны стоить дорого. Но сами банки отмечают «сырость» и несовершенство систем автоматизации банков, которые им предлагают.
За пределами Садового кольца
Если раньше усилия крупных банков были сосредоточены в основном в столичных регионах, то в последние два года из-за усиления конкуренции на этих рынках и роста благосостояния людей по России в целом
финансовые структуры стали гораздо более активно развивать свои филиальные сети за пределами «Садового кольца» и вытеснять небольшие региональные банки. Последние, пытаясь выстоять в конкурентной
борьбе, теперь вынуждены гораздо больше внимания, чем раньше, уделять ИТ-структуре. Как заявил «Бизнесу» руководитель отделения банковских технологий компании ФОРС Геннадий Заманский, стратегический
ответ должен быть асимметричным - переиграть «москвичей» в капитализации бизнеса и технической оснащенности региональным банкам вряд ли удастся.
Спрос, как известно, рождает предложение. Традиционно, по вполне понятным причинам, усилия большинства разработчиков автоматизированных систем были сосредоточены исключительно на работе с крупными
банками и финансово-промышленными группами. Но в прошлом году сразу несколько разработчиков предложили рынку продукты, ориентированные именно на средние и малые банки. Среди них можно назвать линейку RS
- Bank / Pervasive (компания R - Style Softlab ), «Ва-Банк ST »(компания ФОРС), «Центавр Омега» (компания «Програмбанк») и т. д.
Ориентированы такие решения на банки второго эшелона с объемом бизнеса существенно меньше 1% от рынка (то есть $50–150 млн). По оценкам EGAR Technology , объем средств, которые могут быть потрачены
таким банком на ИТ-технологии ( soft & 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 млн вошли в систему страхования вкладов и теперь должны вести реестры обязательств, рассчитывать и формировать страховые выплаты, готовить специализированную
отчетность. Новые требования контролирующих органов к отчетности - это и новые требования к системе автоматизации, которая пополнится дополнительными модулями, что не может не радовать разработчиков.
Сбой при внедрении
Выбор автоматизированной банковской системы - это только полдела. С основными трудностями банк сталкивается, когда эта система внедряется и начинает функционировать. Банк хочет побыстрее запустить новое
решение, а производитель -закончить проект и перейти к новому клиенту. В результате система внедряется в лучшем случае «некорректно» и не выполняет и половины заявленных функций.
По словам руководителя отделения банковских технологий компании ФОРС Геннадия Заманского, то, что небольшие банки выбирают АБС, исходя прежде всего из личных предпочтений руководителей, имеет свою
негативную сторону. Уже на стадии внедрения такого продукта часто выясняются интересные подробности - например, невозможность новой системы работать с уже установленными в банке решениями.
Как заявил «Бизнесу» генеральный директор компании ОТР Денис Крикунчик, как правило, внедрение новых продуктов в небольших банках «спихивается» на плечи ИТ-отдела. Другие отделы, которые занимаются
непосредственно банковским бизнесом, от процедуры самоустраняются, ссылаясь на занятость. Единственный, кто работает совместно с ИТ-отделом и разработчиками над проектом и наблюдает за процессом,-
главный бухгалтер, в компетенцию которого входит методика проведения операций. Поэтому автоматизированными оказываются области, близкие главному бухгалтеру,- само ядро системы, книга счетов, рабочее
место операциониста. Более сложные продукты, например кредитный модуль, остаются в виде «коробочки».
Поскольку ИТ-отдел, на который давит руководство, пытается быстрее внедрить проект, а разработчик - подписать акт приемки, о качестве и полноте внедрения они не слишком задумываются.
В результате, по словам Крикунчика, половина функций остается либо неавтоматизированной, либо продолжает работать на старой технологической базе, либо вообще не используется.
При внедрении достаточно часто возникает конфликт интересов между разработчиком и банком. Малый банк, стесненный в средствах, желает за небольшие деньги получить по максимуму, а разработчик не спешит
выполнять обещания по заявленному функционалу и стремится внедрить минимум.
Поэтому, считает генеральный директор компании «Платежные технологии» Игорь Голдовский, банк и разработчик должны еще на начальной стадии проекта точно прописать его концепцию и четко ей следовать, а не
полагаться на стандартизированное описание продукта.
Кроме чисто технологических проблем при поддержке и обновлении системы не менее остро стоит вопрос ее соответствия современному законодательству. Центральный банк постоянно усиливает требования и
контроль за деятельностью финансовых институтов, ужесточается общее финансовое законодательство РФ. Как отмечает руководитель проекта «Центавр» компании «Програмбанк» Степан Сокол, только за последнее
время серьезные проблемы доставили банкам изменения в валютном регулировании, в проведении банковских операций с наличной валютой, к тому же изменилось обеспечение системы финансового мониторинга, была
внедрена отчетность по МСФО, произошли изменения в обязательной отчетности для Банка России, была введена система страхования вкладов и многое другое. Например, при внедрении отчетности по МСФО банки
были вынуждены создавать у себя специализированные хранилища, которые функционировали параллельно с АБС. Создание одного такого хранилища обходится в несколько десятков тысяч долларов.
Если крупные структуры при постоянных изменениях законодательства могут вносить соответствующие коррективы в ИТ-структуру своими силами или привлекая внешних консультантов, то небольшим банкам жизненно
необходима поддержка разработчиков и оперативное обновление систем. Неудивительно, что в описаниях своих продуктов компании делают упор именно на соответствие всем самым свежим законодательным нормам.
Так, по словам брэнд-менеджера компании R - Style Softlab Ольги Гроздовой, задачи по поддержке действующего российского законодательства и оперативный учет его изменений - приоритетные направления для
разработчиков.
Но все же сопровождение и своевременное обновление систем остаются одними из самых болезненных вопросов для небольших банков. Разработчики говорят о том, что регулярно обновляют программное обеспечение,
консультируют в режиме «горячей линии» по телефону, факсу, электронной почте и даже создают специальные каналы консультаций через интернет. Например, R - Style разработала I - Support - технологию и
одновременно канал консультаций через интернет, средство получения оперативных ответов на вопросы, совмещающее в себе достоинства устных и письменных консультаций. Но представители банков говорят о
«сырости» АБС для малых банков. По словам начальника ИТ-департамента Спиритбанка (Тула) Александра Супрановича, сейчас сопровождение подобного рода систем «отвратительное», в решениях встречаются
«дыры», с которыми разработчики вынуждены долго заниматься. В результате внедрение АБС занимает около года. Напротив, системные интеграторы считают, что такие проблемы возникают у банков не из-за
недоработок ПО, а прежде всего из-за спешки, некорректно поставленных задач, недостаточного внимания к проекту. Крупные банки решают эту проблему, прибегая к услугам внешних ИТ-консультантов, которые
формулируют требования к функциональности системы, оценивают корректность ее внедрения и необходимость модернизации. Но со стороны небольших банков такая услуга пока практически не востребована, поэтому
для них эти функции исполняют разработчики, выступая в роли и консультантов, и системных интеграторов.
© Alti.ru