Автоматизация обязательной отчетности в СМП Банке глазами главного бухгалтера

О результатах проекта автоматизации обязательной отчетности для Банка России и рецептах его успеха рассказала главный бухгалтер АО «СМП Банк» Вероника Дивид.

- Вероника, давайте начнем наш разговор с краткого подведения итогов. Расскажите о целях проекта и достигнутых на сегодняшний день результатах.

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

В итоге остановились на решении для автоматизации обязательной отчетности на хранилище данных (ХД) «Контур» от российской компании «Интерсофт Лаб». На сегодняшний день вендор внедрил 16 форм отчетности, в том числе 0409120, 0409122, 0409126, 0409129, 0409155, 0409157, 0409302, 0409303, 0409345, 4990-У, 0409401, 0409410, Приложение 4 (1) к Положению 753-П, 3462-У. Параллельно банк самостоятельно автоматизировал на ХД еще ряд форм, в частности 0409316, расчет показателей по нормативам ликвидности и не только.

Кроме того, на базе ХД реализованы витрины данных, в частности «Кредитный портфель» и «Витрина залогов». Отдел отчетности обращается к ним за данными при подготовке других форм, например 0409310.

Еще один важный итог проекта в том, что мы серьезно улучшили качество данных: не только в ХД, а, прежде всего, в системах-источниках.

- Чем вы руководствовались при выборе платформы для автоматизации регуляторной отчетности? Почему использовали решение на основе ХД, а не АБС?

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

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

- Значит выбор поставщика решения был предопределен?

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

К моменту тендера ХД от «Интерсофт Лаб» функционировало в банке уже пять лет, в него собирались данных из большинства банковских источников. Кроме того, из ХД уже выпускалась форма 0409120 для двух банков группы. Этот факт плюс репутация вендора внутри банка были весомыми аргументами.

Но мы все равно подстраховались, провели тендер, а затем пилотное внедрение формы 0409155, чтобы убедиться, что вендор обладает нужными компетенциями, специалистами, готов соблюдать сроки. И только после этого было принято решение идти с ним в масштабный проект.

- Какие сроки для реализации проекта были поставлены? Удалось ли их выдержать?

- В проектах автоматизации обязательной отчетности неправильно устанавливать один итоговый срок. Он будет или неприлично большим, или будет нарушен. И, главное, по нему сложно оценивать результаты. Этот вывод основан на моем опыте управления подобными проектами, который не ограничивается только СМП Банком.

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

- Расскажите, пожалуйста, подробнее о том, как правильно организовать проект.

- Во-первых, проект надо разбить на этапы. Каждый этап должен выполняться в обозримые сроки – от 3 до 5 месяцев - и включать не больше 4-5 форм. Это позволит обеспечить прозрачное управление проектом, быстрое реагирование на любые вопросы, даст возможность объективно судить о достижении целей и соблюдении сроков.

Во-вторых, нужно грамотно приоритизировать задачи. Не советую сразу браться за автоматизацию форм, которые требуют максимального набора первичных данных, например нормативов. Начинать стоит с отчетов, которые завязаны на обработку больших объемов данных из разных источников, чтобы сразу почувствовать эффект от автоматизации. Например, для первого проектного этапа мы взяли формы 0409122, 0409157, 0409302 и 0409401. Они используют сложные наборы первичных данных: данные о контрагентах, остатки по счетам и субсчетам контрагентов, данные оперативного учета, в том числе кредиты и депозиты ФЛ и ЮЛ, сделки МБК и пр. Все эти данные собираются в ХД из разных источников. Автоматизация только одного сбора данных ощутимо облегчила подготовку этих форм.

Замечу, что включение в этап нескольких форм, которые готовятся на одних и тех же данных, позволяет извлечь максимум выгоды из инвестиций в сбор данных. Хороший пример - это «Реестр обязательств перед вкладчиками» по 4990-У и отчетная форма 0409345. Оба отчета используют один и тот же набор детальных первичных данных и имеют общую разработочную таблицу. Еще в нашем решении все корректировки, которые бухгалтер вносит в форму детализации Реестра, применяются к последующему расчету формы 0409345 и сохраняются для будущих отчетных периодов.

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

Добавлю еще, что успех проекта зависит не только от его организации, но во многом определяется качеством данных в исходных системах, прежде всего в АБС банка.

- Как обеспечивалось качество данных в вашем проекте?

- Чтобы добиться приемлемого качества данных в системах-источниках, нужен комплексный подход. Мы это понимали и основательно подготовились к проекту.

Во-первых, еще до начала работ провели ГЭП-анализ, чтобы оценить, достаточно ли в источниках данных для подготовки форм, и убедиться, что в них присутствуют все необходимые для форм внешние и внутренние справочники/классификаторы. Мы выяснили, каких данных и справочников не хватает, и как их можно получить. И советуем всем делать это упражнение. Это позволяет идти в проект с открытыми глазами и объективно оценивать сроки и бюджет.

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

Отмечу, что в работе по выявлению и исправлению данных в системах-источниках нам очень помогали Департамент информационных технологий и Департамент сопровождения клиентских и банковских операций.

- Какие особенности организации управления проектом Вы можете отметить?

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

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

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

Проектные задачи были приоритизированы и сгруппированы в непродолжительные независимые этапы. Параллельно шла работа над внедрением 3-4 форм.

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

- Какой совет Вы могли бы дать банкам, инициирующим подобные проекты.

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

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

Источник: Банковское обозрение