1. Какой в целом бизнес-эффект оказывает автоматизация бизнес-процессов в банке?

Спектр возможных бизнес-эффектов от автоматизации очень велик – от снижения операционных затрат до эффектов «управления знаниями». Возможные эффекты зависят как от размера банка и уровня зрелости ИТ.
По нашему опыту, для средних банков решаемые задачи определяются от ситуацией на рынке. В периоды роста это расширение продуктового ряда, повышение скорости обслуживания клиентов, новые каналы взаимодействия с ними. В периоды спада это – снижение операционных затрат.

Крупные банки, в первую очередь, стремятся с помощью ИТ эффективно управлять взаимоотношениями с клиентами (CRM-технологии), повысить качество принятия управленческих решений (автоматизация управленческих бизнес-процессов, внедрение инструментов бизнес-анализа).

Помимо текущих бизнес-задач, есть стратегические цели банка, которые можно достичь с помощью полномасштабной автоматизации бизнес-процессов. Например, высокий уровень автоматизации позволяет банку функционировать как единое целое. Это охватывает и обслуживание клиентов, и стандартизацию процессов, и оптимальное управления ресурсами (не только финансовыми!). Другой стратегический эффект — снижение зависимости от конкретных сотрудников, уменьшение требований к квалификации персонала.

2. Автоматизация каких именно бизнес-процессов банка приносит наиболее ощутимый краткосрочный эффект, и каких долгосрочный?

В периоды роста наиболее ощутимый краткосрочный эффект приносит автоматизация продаж. ИТ-проекты построения кредитного конвейера в «жирные годы» окупались менее, чем за полгода с начал внедрения. В текущей, кризисной ситуации быстрый финансовый результат приносит, например, автоматизация сбора просроченной задолженности.
Долгосрочный эффект дает автоматизация управленческих бизнес-процессов, т.к., чем дольше используется система, тем больше накоплено информации и, соответственно, больше эффект от ее эксплуатации.

В качестве примера рассмотрим систему контроля операций на финансовых рынках, которую построила компания построенная «ПрограмБанком» финансовых группах, ВТБ Капитал и Ренессанс Капитал.
На первом этапе стояла задача расчета ряда синтетических показателей для оценки качества работы персонала.

Далее, на основе собранных первичных данных, появилась возможность формирования аналитической отчетности по прибылям и убыткам, охватывающей более 1000 финансовых инструментов и более 40 членов группы. Затем с помощью этих данных были рассчитаны допустимые диапазоны финансовых показателей, выход за пределы которых желательно контролировать. Этот инструмент позволил увеличить качество управления активами.

Потом контроль отклонений был включен в документооборот банка. Руководство стало получать информацию о выявленных отклонениях с обязательным пояснением ответственных менеджеров о причинах и предполагаемых мерах по их устранению, и т.д. А это уже переход к новому уровню зрелости управленческих процессов в банке: снижается зависимость от исполнителей, руководство гарантированно получает информацию и др.

3. Какие риски порождает автоматизация в банке?
Как банку следует подходить к автоматизации, чтобы уменьшить или избежать риски?

Сейчас 99% банковского бизнеса не существует вне ИТ-системы. Поэтому, риски для информационной системы это и есть риски для банка.
Первая группа рисков связана с безопасностью информации. Именно поэтому информационная безопасность – отрасль, создающая инструменты уменьшения и предотвращения данных рисков, последние 10 лет растет быстрее рынка ИТ в целом.

Другая группа рисков, связанная с банковской автоматизацией – это зависимость от ИТ-команды или от поставщика решения. Увы, часть компаний в кризис перекладывает свои риски на заказчиков. Как же можно избежать рисов, связанных с зависимостью от ИТ-поставщика:

• Проанализируйте историю ценовой политики Вашего поставщика. Насколько часто выпускались новые версии, и на каких условиях эти версии предоставлялись клиентам? Менялась ли ценовая политика поставщика и насколько часто? Заметим, что речь идет не только о повышении цен, но и об изменении структуры, например, о разделении бэк-офисов на более мелкие. Сами повышения – насколько они были регулярны и как коррелировали с инфляцией? В случае если банк принимал решение о сокращении поля сотрудничества с разработчиком (как вариант, планировал внедрение решений других поставщиков), как происходил «развод» (полный или частичный)?
• Юридической службе стоит проанализировать договора. Предусматривает ли договор какие-то регулярные платежи, не связанные с предоставлением услуг? Есть ли у банка обязательства по оплате в том случае, когда уменьшается масштаб эксплуатации системы (не используются те или иные бэк-офисы, уменьшается число рабочих мест и др.)? Есть ли у банка возможность расторгнуть договор на предоставление услуг в одностороннем порядке, за какой срок он должен уведомить об этом разработчика? Какие возможности существуют у банка в том случае, когда его не устраивает качество предоставляемых услуг?
• Проведите техническую экспертизу. В первую очередь она касается возможностей использовать решения других вендоров. Предоставляет ли разработчик API к своей системе? Есть ли возможность реализации собственных бизнес-процессов? Насколько удобно создавать собственные отчеты и выгружать информацию в сторонние системы?
  
  

4. Коробочное решение по автоматизации против заказной разработки.
Каковы плюсы и минусы обоих подходов?

С одной стороны, использование полностью заказного решение связано с очевидными затратами и рисками. «Экономии на масштабе» в этом случае нет и банк фактически оплачивает все: себестоимость работ, прибыль ИТ-компании, транзакционные издержки взаимодействия между клиентом и исполнителем и т.д.
Риски ниже, если банк «относительно велик» по сравнению с разработчиком – это обеспечивает ему сильную позицию на переговорах.

При этом если заказанная система достаточно локальна, открыта, и не слишком зависит от законодательных изменений, то банк может взять ее на собственное сопровождение.
В этом случае вариант заказного решения вполне имеет смысл.
Плюсы заказного решения понятны: быстрое получение результата, соответствующего специфическим задачам банка.
С другой стороны, именно «коробочное решение» встречается сейчас все реже.

Опыт отрасли , показывает, что в 90% случаев оптимальным является тиражное, но при этом полностью открытое решение. В нем реализовано большое количество бизнес-процессов, первичных и отчетных форм, банковских продуктов и клиентских сервисов, актуальных для большинства банков. Специфические бизнес-процессы реализуются в рамках внедрения с параллельным обучением ИТ-команды банка. А далее, все необходимые изменения во внедренную ИТ-систему могут вноситься программистами банка самостоятельно.

При этом размер специфических требований банка зависит от предметной области. РКО юридических лиц достаточно стандартно, розничные продукты банка часто построены на схожих принципах, но «изюминка» есть у каждого, например, схемы взыскания просроченной задолженности часто являются ноу-хау банка.
Но при использовании тиражного и, при этом, открытого решения, перед банком встают новые серьезные проблемы.

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

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

Анна Чернобыльская - Банкир.Ру, май 2016.pdf