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

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

Что такое методика расчета в банковской аналитике

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

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

Почему изменение методики часто превращается в ИТ-проект

Рассмотрим типичную ситуацию.
Финансовое подразделение меняет правило расчета показателя.
Если логика расчета жестко зашита в код, процесс может выглядеть следующим образом:
финансовое подразделение → постановка задачи → аналитик → разработчик → изменение кода → тестирование → согласование → релиз → проверка результата.
При этом разработчику необходимо не только понять новое правило, но и убедиться, что изменение не повлияло на другие расчеты.
Чем больше связей между показателями, тем выше потенциальный объем тестирования.
В результате изменение методики, которое с точки зрения бизнеса может занимать несколько часов, превращается в задачу на несколько дней или недель.
Проблема здесь не обязательно в скорости работы разработчиков. Она в самой архитектуре решения: изменяемая бизнес-логика находится там, где ее изменение требует разработки.

Что можно вынести из программного кода

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

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

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

Пример: изменение правила распределения расходов

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

Еще одна типичная задача — новый аналитический разрез

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

Что происходит с отчетностью

Изменение методики обычно не заканчивается одним показателем.
Один расчетный показатель может использоваться в нескольких отчетах, план-факт анализе, KPI и других аналитических моделях.
Поэтому при изменении методики важно не просто быстро поменять формулу.
Необходимо понимать:
что изменится в результате этого изменения?
Хорошая аналитическая система должна обеспечивать прозрачность взаимосвязей между исходными данными, расчетами и итоговыми показателями.
Тогда финансовый специалист может оценить последствия изменения методики до того, как новые правила будут применены к рабочим расчетам.

Почему здесь важен No-Code

No-Code в финансовой аналитике имеет ценность не сам по себе.
Главное — не возможность отказаться от программирования вообще, а возможность не использовать разработку там, где изменяется предметная логика, а не функциональность самой платформы.
Это принципиальная разница.
Если необходимо изменить архитектуру системы, реализовать новый механизм обработки или подключить новый тип источника данных, участие разработчиков может быть совершенно оправданным.
Но если финансовому специалисту необходимо изменить правило расчета уже существующего показателя, ждать отдельного цикла разработки не всегда рационально.
Именно здесь No-Code становится инструментом сокращения времени изменений.

Как меняется роль ИТ и финансового подразделения

При таком подходе ответственность не исчезает — она перераспределяется.
Финансовое подразделение отвечает за методологию:
• какие показатели нужны;
• как они должны рассчитываться;
• какие правила применяются;
• какие аналитические разрезы необходимы.
ИТ обеспечивает:
• надежность платформы;
• интеграции;
• безопасность;
• производительность;
• контроль доступа;
• инфраструктуру;
• развитие базовых механизмов.
Это позволяет не использовать разработчиков для каждой методологической корректировки.
При этом важны разграничение прав, аудит изменений и возможность контролировать версии настроек. Без этого самостоятельная настройка финансовой модели может, наоборот, увеличить риски.

Скорость изменения — это не только скорость разработки

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

Где проходит граница между настройкой и разработкой

Важно не создавать ложного впечатления, что специализированная No-Code платформа позволяет решить абсолютно любую задачу без программирования.
Такая постановка была бы некорректной.
В любой сложной информационной системе остаются задачи, требующие разработки: новые интеграционные механизмы, изменения архитектуры, нестандартные алгоритмы обработки и другие технические изменения.
Ценность No-Code в другом.
Он позволяет максимально отделить изменяемую предметную методологию от программной реализации платформы.
И чем больше таких изменений можно выполнить средствами настройки, тем меньше зависимость финансового подразделения от цикла разработки.

От разовой доработки — к управляемому изменению методологии

Для банка это означает переход от модели:
«нам нужно изменить расчет → нужно поставить задачу разработчикам»
к модели:
«нам нужно изменить методику → меняем соответствующие настройки, тестируем результат и вводим новую версию».
Такой подход особенно важен в управленческом учете и финансовой аналитике, где изменения происходят регулярно и являются частью нормальной работы бизнеса.
Поэтому при выборе аналитической платформы стоит оценивать не только то, что она умеет рассчитывать сегодня, но и то, насколько быстро банк сможет изменить правила расчета завтра.
Именно возможность самостоятельно адаптировать методики, аналитические структуры и отчетность становится одним из ключевых преимуществ специализированных No-Code /Low-Code платформ для финансовой аналитики.
А для банка это уже не просто вопрос удобства разработки. Это вопрос скорости реакции финансовой системы на изменения бизнеса.

Серия «Архитектура банковской аналитики»

Следующая статья → Почему BI не заменяет аналитическую платформу банка
Изменение финансовой методики − одна из самых частых причин доработок аналитических систем. Но гибкость определяется не только скоростью разработки: важно, где именно хранится бизнес-логика и кто может ее изменять.

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

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