Мария Строгонова Директор производственного центра «ПрограмБанк.БизнесАнализ»

Low-Code платформы позволяют сокращать объем программирования и быстрее адаптировать информационные системы под требования бизнеса. Но при выборе решения для финансового блока банка одного наличия визуального конструктора недостаточно. Финансовая аналитика, управленческий учет, бюджетирование и планирование работают со сложной предметной областью. Здесь важна возможность менять методики расчетов, структуру показателей и аналитические разрезы без постоянной передачи задач разработчикам. Поэтому при выборе Low-Code платформы для финансового блока полезно оценивать не только то, что система умеет делать, но и то, что банк сможет самостоятельно изменять после внедрения. Ниже собрали основные критерии.

Первый вопрос, который стоит задать поставщику: Что именно пользователь может изменить самостоятельно?
Low-code-платформа должна позволять настраивать предметную логику, а не только интерфейс.

Для финансового блока это могут быть:

· формулы показателей;
· правила расчета;
· условия отбора данных;
· классификация операций;
· правила распределения доходов и расходов;
· аналитические признаки;
· структуры отчетности;
· бизнес-процессы сбора и расчета данных.

Если изменение формулы показателя все равно требует изменения программного кода, возможности low-code используются лишь частично.

Финансовые показатели редко существуют изолированно. Например, один показатель может использоваться одновременно в управленческой отчетности, план-фактном анализе и расчете KPI. Поэтому важно понять, где находится единая логика расчета.

Стоит спросить:

· где хранится описание показателей;
· как задаются связи между ними;
· можно ли использовать один показатель в разных отчетах;
· как система предотвращает появление нескольких версий одного и того же показателя.

Чем меньше расчетная логика распределена по отдельным отчетам и запросам, тем проще поддерживать единообразие аналитики.

Банку редко достаточно анализа только по одному измерению.
Финансовый результат может потребоваться рассматривать одновременно:

· по бизнес-направлению;
· продукту;
· подразделению;
· клиентскому сегменту;
· региону;
· валюте;
· центру финансовой ответственности;
· периоду.

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

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

При выборе платформы стоит выяснить:

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

Особенно важно проверить это на реальном примере банка, а не на демонстрационном сценарии поставщика.

Финансовая методика может измениться с определенной даты.
Например, до 1 января показатель рассчитывался одним способом, а после этой даты - другим.
Система должна позволять учитывать такие изменения корректно.

Полезно проверить:

· можно ли хранить несколько версий методики;
· можно ли указать период ее действия;
· можно ли пересчитать исторические данные;
· можно ли сравнить результаты разных версий;
· сохраняется ли история изменений.

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

Это один из лучших вопросов для демонстрации платформы.
Попросите поставщика изменить показатель, который используется в нескольких отчетах.
Например: изменить формулу расчета финансового результата продукта.

После этого задайте вопросы:

· какие отчеты изменились;
· как можно определить, какие показатели и отчеты затронет изменение;
· требуется ли ручное изменение отчетов;
· как проверяется результат;
· можно ли посмотреть историю изменений.

Такой сценарий показывает реальную архитектуру системы гораздо лучше стандартной презентации возможностей.

Финансовая аналитика получает данные из множества источников. Поэтому важно оценить не только интеграционные возможности, но и инструменты подготовки данных.

Платформа должна позволять работать с:

· различными форматами и источниками данных;
· справочниками;
· классификаторами;
· правилами сопоставления;
· преобразованиями;
· контролем качества;
· ошибками загрузки.

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

Неверный показатель в управленческой отчетности может возникнуть еще до этапа расчета. Например, часть операций не загрузилась, изменился справочник или появились некорректные значения.

Поэтому при выборе платформы стоит проверить наличие механизмов:

· контроля полноты;
· проверки значений;
· контроля справочников;
· протоколирования ошибок;
· повторной обработки данных.

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

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

Например:
показатель → расчет → аналитика → исходные данные.
Для сложной финансовой аналитики такая трассируемость особенно важна.

Она позволяет ответить на вопросы:

· откуда взялся показатель;
· по какой методике он рассчитан;
· какие данные использовались;
· какие правила распределения применялись;
· когда и кем были изменены настройки.

Без этого поиск причины расхождения может превратиться в отдельное расследование.

Low-code для финансового блока должен давать возможность не только менять расчеты, но и быстро адаптировать представление результата.

Проверьте, может ли пользователь:

· создавать новые формы;
· менять состав показателей;
· добавлять аналитические разрезы;
· настраивать фильтры;
· изменять структуру отчета;
· формировать новые варианты представления данных.

При этом изменение отчета не должно нарушать единую финансовую модель.

Если платформа используется не только для анализа факта, но и для финансового планирования, появляются дополнительные требования.

Например:

· плановые значения;
· сценарии;
· версии планов;
· корректировки;
· план-фактный анализ;
· прогнозирование.

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

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

Полезно выяснить:

· какие банковские задачи уже поддерживаются;
· есть ли готовые финансовые модели;
· реализованы ли механизмы управленческого учета;
· поддерживаются ли ALM и финансовое планирование;
· какие аналитические структуры уже предусмотрены;
· сколько предметной логики банк должен создавать самостоятельно.

Здесь возникает простой вопрос:
Сколько нужно построить с нуля, прежде чем платформой можно будет пользоваться для реальной финансовой аналитики?

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

Поэтому при выборе платформы стоит проверить:

· можно ли разграничивать доступ по ролям пользователей;
· можно ли ограничивать доступ к данным по аналитическим разрезам, например ЦФО или статьям;
· можно ли отдельно определять права на просмотр, ввод и изменение данных;
· можно ли ограничивать права на изменение расчетных моделей и настроек;
· поддерживаются ли бизнес-процессы с распределением задач между участниками;
· можно ли настраивать согласование и последовательность выполнения этапов;
· сохраняется ли история действий пользователей.

Low-code должен давать финансовому блоку самостоятельность в изменении моделей, не отменяя управляемость процесса и разграничение ответственности между его участниками.

Вместо длинной презентации возможностей можно предложить поставщику несколько реальных задач из вашего банка.
Например:
Задача 1. Добавить новый финансовый показатель.
Задача 2. Изменить формулу существующего показателя.
Задача 3. Добавить новое аналитическое измерение.
Задача 4. Изменить правило распределения расходов.
Задача 5. Создать новый управленческий отчет на основе существующей модели.
Задача 6. Проверить, как изменение показателя отразилось на связанных расчетах и отчетах.
Задача 7. Настроить разные права доступа к данным и действиям для двух ролей пользователей.

А затем зафиксировать:

· сколько действий выполнил пользователь;
· сколько времени заняла настройка;
· потребовалось ли программирование;
· потребовалось ли участие ИТ;
· как проверялся результат;
· сохранилась ли история изменений.

Такой тест дает гораздо больше информации о реальной гибкости платформы, чем перечень функций в презентации.

Для финансового блока важно не только то, как быстро можно внедрить систему.
Не менее важен вопрос: Как быстро банк сможет изменить ее через год?

Финансовая методология продолжает развиваться после запуска системы. Появляются новые показатели, продукты, аналитические разрезы и правила.

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

Технология
Насколько платформа гибкая, производительная и интегрируемая.

Предметная модель
Насколько глубоко в ней учтена специфика финансовой аналитики и управленческого учета.

Самостоятельность пользователя
Какие изменения финансовый специалист действительно может выполнить без программирования и привлечения разработчиков.

Только сочетание этих трех составляющих позволяет получить систему, которая будет адаптироваться вместе с банком.

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

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

Компания «ПрограмБанк» посвятила цикл статей «Архитектура банковской аналитики», в которых последовательно рассматриваются особенности автоматизации финансовой аналитики, возможности и ограничения Low-Code /No-Code подходов, построение аналитической архитектуры банка и вопросы автоматизации управленческого учета.

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

Следующая статья → Почему изменение одного показателя в управленческом учете может затронуть десятки отчетов

В серии:
1.	Low-Code в банках: почему универсальные платформы подходят не для всех задач — почему универсальные платформы подходят не для всех банковских задач.
2.	Почему финансовая аналитика — одна из самых сложных областей для Low-Code — какие особенности финансовых моделей делают эту область сложной для автоматизации.
3.	Как банки сокращают время изменения методик расчета без доработки программного кода — как сделать изменение финансовой логики быстрее и управляемее.
4.	Почему BI не заменяет аналитическую платформу банка — чем расчетный аналитический слой отличается от визуализации данных.
5.	От витрины данных до управленческой отчетности: как устроена аналитическая архитектура современного банка — о том, как выстроить весь путь от исходных данных до управленческой отчетности.
6.	Что должен уметь Low-Code для финансового блока банка: чек-лист для выбора платформы — вы читаете эту статью.
7.	Почему изменение одного показателя в управленческом учете может затронуть десятки отчетов — о том, почему изменение одной части финансовой модели может повлиять на множество отчетов.

Источник публикации: https://www.programbank.ru/articles/site/article-10092026