Два действия вместо сотен и тысяч: лечим боль смены периода в финансовой модели

[exploitick]

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[krestjanka]

Добрый день. Какова стоимость миграции с «координатной» модели на «параметрическую»? Сколько человеко-часов потребуется на рефакторинг, если в компании уже есть 50 моделей в Excel? И как этот TCO (совокупная стоимость владения) сравнивается с затратами на внедрение OLAP-куба или Python-решения?

[ideavi]

Приветствую! Перекидать статьи затрат в новый формат занимает несколько минут на лист, потому что это просто копипаст. Формулы — это тоже минуты.
Из практики, самое сложное будет выбить логику из заказчика и продумать архитектуру хранения для первой модели, чтобы она вас устраивала и была расширяема на будущее. Тут можно будет несколько раз сделать с нуля, экспериментировать, тратя на итерацию от получаса до двух часов.
Итого: полдня-день на первую модель, ещё 16-40 часов на отладку, потом на остальные по 2-4 часа на перенос с нуля или адаптацию копии — выбор по ситуации.

На сопровождение такой работы — обучение людей, поддержка и перенос их руками — я бы заложил месяц на все 50 штук. Самому браться крайне рискованно.

[ideavi]

И как этот TCO (совокупная стоимость владения) сравнивается с затратами на внедрение OLAP-куба или Python-решения?

Конструктор как веб-сервис или самодельное приложение с таким подходом сравнимо с одним-двумя месяцами работы внедренцев OLAP-куба или Python-решения, дальше начинается чистая экономия, примерно как стоимость владения экселем — 20-30 тысяч в год в облаке.

[krestjanka]

А как вы планируете отлаживать цепочки смещений, когда модель разрастется до 10 листов и 150 строк? Что вы предложите, чтобы финансист не запутался в «ссылках на соседей», подсветка, трассировка?

[ideavi]

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

[krestjanka]

А как вы обеспечите безопасность и производительность произвольных SQL-запросов от пользователей? Что мешает финансисту написать запрос, который «уронит» базу данных? Какой слой валидации и песочницы вы предусмотрите?

[ideavi]

Это больше вопрос про особенности платформы, но сам по себе он очень острый.
Отвечу про пример в Интеграме: пользователь ограничен только теми таблицами, куда у него есть доступ, поэтому запросы на выборку он может делать только к ним. Сами запросы (аналог SQL) тоже с ограниченным доступом: это основано на префиксе (в простых случаях) и на ролях/группах (в более сложных системах).

По производительности у всех стандартно: порог (таймаут) на уровне системы не даст её сколько-нибудь сильно ущемить. SQL-инъекции тоже вещь, защищаемая стандартно, любой конструктор должен иметь блокер на это.

[economist75]

Проблему подтверждаю. Параметризация периодов в формулах Excel - хорошее решение, но не единственное и возможно не лучшее. Поясню позицию:

ФинМодель должна ответить всего на один вопрос “Есть ли смысл на горизонте провидения сделать то-то, или нет?”. Для этого есть хорошо известная троица критериев: NPV > 0, IRR > Ключ+риск 0-5%, PI > 1. А значит нам нужно просто сделать таблицу в Excel пошире, не на 5-7 лет, а на 50 (протянуть формулы вправо). И менять параметром только левый край (начало), скрывая уже прошедшие периоды. А правый край пусть будет бесконечно далеко.

Для холдинга с 1B выручки в Excel таблице придется указать “всего лишь” 30-50 текущих параметров и принять 3-5 типовых динамик (инфляции, курса USD, ключа ЦБ и дисконтирования денежных потоков - в текущих фиксированных ценах или динамических цен). Типовые динамики часто уже готовы стараниями ЦБ, МВФ, РБК, а значит Excel вполне потянет такие расчеты. Которые можно на любом месяце “перебить”, реализовав любую управленческую блашь.

Но вот тут-то и наступает прозрение. Excel с его реактивным программированием формулами - быстро становится непозволительно тяжел. Пересчет формул начинает занимать секунды. Совместная работа становится игрой в “Сапера” - вылетит/не вылетит. Диспетчер сценариев очевидно неудобен и не нагляден. Нарисовать диалоги на VBA легко, но программирование событий форм оказывается бесконечно сложным.

И насколько же правильнее и проще становится финмоделинг при использовании абстрактных классов на том же Python/Pandas, когда все денежные и товарные потоки рассчитываются динамически, единообразно. На входе единственнный abs-класс получает всего несколько параметров (что это, старт/стоп, нач/кон цена, модель роста), и он сразу готов выдать значение любой статьи Финмодели, на любой будущий период. Любое нестандартное поведение ООП тут порешает наследованием и переопределением. Excel остается нужен лишь как самый привычный отображатель таблиц, так как Pandas с его df.styler() не позволяет сделать “корпоративно-красиво”, не убив половину времени на “украшалости”.

Этот ООП-подход сборки финмоделек отличается от Excel и другого мега-популярного решения (ProjectExpert), хотя дает тот же арифметический результат. Но при многократном пересчете (тысячи раз) он оказывается самым удобным. Конечно, полученные сценарии модели нужно сохранять в БД или в “паркетах” (а не в листах Excel). И всю разработку надо вести сразу в Jupyter-блокноте, в режиме collaborate, но это уже технические детали. Главное уйти от формул Excel в том самом месте, где они становятся “тугими” и без удобного интерфейса для смены параметров (сценарии и желтые ячейки, разбросанные по громадному листу - неудобны, а VBA-диалоги с валидацией и правда сложны даже с вайбкодом из-за множества неопределенных состояний от действий пользователей).

[ideavi]

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

С Jupyter-блокнотами, ETL и хадупами работали мои ML-коллеги, и бизнесу это ну никак не заходило. В компании часто было 1-2 чела, кто мог это постичь, но они не могли работать сообща с коллегами, потому что возня с подготовкой инфраструктуры занимает месяцы. Эти месяцы пролетают незаметно для энтузиастов, но простым сотрудникам порог входа высокий и его преодоление не выглядит выгодно.

Пока делал первый проект по модели, не отпускала мысль: почему люди так мучаются? Можно же сделать по-хорошему: период параметром, колонки по периоду, у значения дата вместо места. Звучит настолько естественно, что даже подозрительно.