Тщательно взвесьте пользу от автоматизации и зафиксируйте целевую архитектуру

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

Существует и более весомое основание критиковать описанный подход. Как правило, банки выбирают платформу для автоматизации обязательной отчетности между АБС и хранилищем данных (ХД). Ошибка в том, что для всех форм ищут единую программную платформу, не учитывая, что IT-инструмент должен быть адекватен каждой решаемой задаче по функциональной готовности, трудоемкости использования и финансовым вложениям. Например, форму 0409101 можно сформировать в любой АБС одним нажатием кнопки, а перенос ее выпуска на ХД-платформу потребует дополнительно наладить загрузку данных из АБС, настроить проверки качества данных и выполнять эти операции на регулярной основе. Другой пример: расчет расшифровок для обязательных нормативов, который включает несколько этапов обработки данных из разных учетных модулей. Задача эффективно решается на базе ХД, а выполнение такого расчета в АБС приведет к существенному замедлению работы пользователей.

Чтобы снизить необоснованные издержки и риски эксплуатации, оптимально сочетать в целевом решении возможности обеих платформ — АБС и ХД. На базе ХД целесообразно строить формы со сложной предварительной обработкой данных, включая консолидацию данных из разных источников, их историзацию, обогащение аналитикой, сложные ресурсоемкие расчеты, на базе АБС — выпускать оперативную отчетность на основе Главной книги. Финальный тюнинг форм, а также подготовку ряда отчетов по данным внесистемного учета рационально имеет смысл оставить в зоне ответственности специалистов банка.

Чтобы снизить необоснованные издержки и риски эксплуатации, оптимально сочетать в целевом решении возможности обеих платформ — АБС и ХД

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

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

Коммерческие предложения вендоров и отбор программных платформ при таких вводных будут более взвешенными и соответствующими целям проекта.

Организуйте проект так, будто его исполняет банк

Слабое место IT-проектов для регуляторной отчетности — сроки. Известно про срывы сроков автоматизации разных форм в отдельных банках от трех месяцев до двух лет.

Основные причины нарушений, за исключением откровенно неисполнимых планов:

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

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

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

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

Управляйте финансовой неопределенностью

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

Тем не менее эту неопределенность следует учесть в проектном бюджете. Для этого можно включить в оценку резервные этапы, например:

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

Проверяйте результаты трижды

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

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