Банковское обозрение (Б.О принт, BestPractice-онлайн (40 кейсов в год) + доступ к архиву FinLegal-онлайн)
FinLegal ( FinLegal (раз в полугодие) принт и онлайн (60 кейсов в год) + доступ к архиву (БанкНадзор)
Несмотря на иммунитет к кризисам, проекты регуляторной направленности не защищены от неудач. Успеха добиваются лишь в каждом третьем банке. Рассмотрим четыре основанных на опыте принципа, которые помогут привести проект автоматизации обязательной отчетности к успеху
Потенциальными заказчиками автоматизации надзорной отчетности выступают банки разного масштаба. При этом примерно 90% обращений к вендорам содержат требование обеспечить подготовку всех форм регуляторной отчетности, в крайнем случае 40–50 отчетов. В таком требовании кроется причина, по которой большинство проектов не доживают даже до старта: бюджет и сроки реализации задачи подобного масштаба редко получают одобрение у лиц, принимающих решения.
Существует и более весомое основание критиковать описанный подход. Как правило, банки выбирают платформу для автоматизации обязательной отчетности между АБС и хранилищем данных (ХД). Ошибка в том, что для всех форм ищут единую программную платформу, не учитывая, что IT-инструмент должен быть адекватен каждой решаемой задаче по функциональной готовности, трудоемкости использования и финансовым вложениям. Например, форму 0409101 можно сформировать в любой АБС одним нажатием кнопки, а перенос ее выпуска на ХД-платформу потребует дополнительно наладить загрузку данных из АБС, настроить проверки качества данных и выполнять эти операции на регулярной основе. Другой пример: расчет расшифровок для обязательных нормативов, который включает несколько этапов обработки данных из разных учетных модулей. Задача эффективно решается на базе ХД, а выполнение такого расчета в АБС приведет к существенному замедлению работы пользователей.
Чтобы снизить необоснованные издержки и риски эксплуатации, оптимально сочетать в целевом решении возможности обеих платформ — АБС и ХД. На базе ХД целесообразно строить формы со сложной предварительной обработкой данных, включая консолидацию данных из разных источников, их историзацию, обогащение аналитикой, сложные ресурсоемкие расчеты, на базе АБС — выпускать оперативную отчетность на основе Главной книги. Финальный тюнинг форм, а также подготовку ряда отчетов по данным внесистемного учета рационально имеет смысл оставить в зоне ответственности специалистов банка.
Чтобы снизить необоснованные издержки и риски эксплуатации, оптимально сочетать в целевом решении возможности обеих платформ — АБС и ХД
На сложность подготовки регуляторной отчетности также влияют особенности бизнеса банка, его оргструктура, IT-ландшафт и ресурсный потенциал. Все эти факторы необходимо учитывать уже на предпроектном этапе, соотнося потенциальную пользу от автоматизации каждого отчета с возможными затратами ресурсов и времени на его подготовку с помощью разных инструментов. Выполнение этой работы позволит:
Коммерческие предложения вендоров и отбор программных платформ при таких вводных будут более взвешенными и соответствующими целям проекта.
Слабое место IT-проектов для регуляторной отчетности — сроки. Известно про срывы сроков автоматизации разных форм в отдельных банках от трех месяцев до двух лет.
Основные причины нарушений, за исключением откровенно неисполнимых планов:
В обоих случаях корень зла кроется в слабой управляемости проектом со стороны заказчика и низкой мотивации его персонала, привлекаемого к проектным работам.
Ситуация принципиально отличается от описанной в банках, где реализация проекта поручена сотрудникам, освобожденным от других задач. Некоторые заказчики выделяют для этого технологические подразделения в составе департамента отчетности либо внутри IT-службы. Их сотрудники — технологи по банковской отчетности — одинаково хорошо ориентируются в регуляторных требованиях, технологиях подготовки разных форм и инструментах автоматизации. В проектах автоматизации регуляторной отчетности они берут на себя бОльшую часть задач по разработке целевой архитектуры, выбору вендоров, подготовке бизнес-требований, согласованию технических заданий, тестированию функционала, анализу ошибок в данных, а также управляют их исправлением. Специалисты по подготовке отчетности привлекаются к проекту для узконаправленных консультаций и на этапе финальной проверки результатов.
По опыту, технологи организуют проект так, будто сам банк является его исполнителем. Их стопроцентная вовлеченность, понимание технологических процессов и влияние внутри банка не позволяют проекту буксовать. В результате исключаются задержки информационного обмена между заказчиком и подрядчиком, ускоряется исправление ошибок в данных в подразделениях банка, оперативно корректируются выявленные проблемы ведения бухгалтерского учета.
Даже самая глубокая проработка бизнес-требований не избавляет от появления в ходе проекта непредусмотренных доработок. Если же для подготовки формы планируется консолидировать данные из разных источников, то, наоборот, предсказать необходимость разработки дополнительных проверок качества данных легко. А вот конкретика по их составу и сложности выявится только в ходе проекта. Встречаются и другие проектные задачи, трудоемкость которых трудно оценить до старта работ.
Тем не менее эту неопределенность следует учесть в проектном бюджете. Для этого можно включить в оценку резервные этапы, например:
Приемо-сдаточные испытания (ПСИ) — важная часть любого проекта. Но независимо от методики ПСИ, протестировать выпуск отчетов и свериться с «эталоном» можно только на данных прошлых периодов. Каждый следующий месяц или квартал добавят в данные что-то новое, в том числе новые ошибки их качества. Столкнувшись с ними впервые в новой системе, пользователи могут необоснованно сформировать негативное впечатление о ней.
Чтобы удостовериться, что внедренная IT-платформа умеет обрабатывать самые разные ситуации, а служба технической поддержки обеспечивать необходимый сервис, полезно включить в проект опытно-промышленную эксплуатацию выпуска каждой отчетной формы для нескольких (оптимально трех) периодов с расширенной поддержкой вендора. Каждый раз сотрудники банка будут действовать самостоятельно согласно регламенту подготовки формы. Но при выявлении сложностей — в данных, расчетных алгоритмах и прочем — исполнитель окажет банку любую помощь, чтобы своевременно выпустить и отправить форму регулятору. Каждая найденная в рамках вендорского сопровождения проблема будет проанализирована, а причины ее появления будут устранены. Одновременно заказчик освоит подготовку отчетности с помощью нового ПО, чтобы уверенно эксплуатировать его в дальнейшем.
Об истории российских цифровых кредитных сервисов для МСБ, их преимуществах для небольших магазинов, кофеен и медицинских клиник, а также о перспективах их развития «Б.О» рассказала Елена Будник, CEO и идейный вдохновитель финтех-платформы «Папа Финанс»