Салют, Хабр.

Зачем предприятия ведут учёт? Отчётность перед ФНС? Или может воронка клиентов? Сотни ответов российского рынка учётных систем на этот простой вопрос.

• 1С говорит владельцам: мы дадим вам идеальную, вылизанную до последней проводки отчётность перед налоговой.

• Битрикс24, Amo… говорят: мы поможем вам сохранить каждого клиента, ведь не будет клиента - не будет денег.

Притянуто за уши, но картина понятна - среди учётных систем можно выделить два лагеря:

• БУХ-центричные;

• CRM-центричные.

Вместо начала

Меня зовут Серафим Недошивин, я скромный Go разработчик, и меня всегда тревожил один вопрос: разве не финансы как таковые должны являться центром учёта предприятий?

Какой толк от зелёной воронки лидов, каждый из которых в сухом остатке является убыточным? Какой смысл в причесанной отчётности без банального понимания рентабельности вашего дела?

Год назад я невольно стал заложником терзающих мой разум раздумий о смысле учётных систем. Так был написан первый, второй… пятый модуль мультитенантной ERP-подобной системы для малого бизнеса (Go + pgx | Next.js + TS), вопреки рынку ставящей именно модуль финансов в центр всей системы.

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

Об этом и пойдёт речь в этой статье. Прогнозирование, Theta, Holt-Winters, SES модели и где заканчивается точность?

Kroncl | Github - Разработчикам | Apache 2.0 client+server

База

Начнём с базы - структуры данных финансового модуля. В Kroncl реализована транзакционная модель учёта: каждая операция - отдельная запись в базе данных с привязкой к направлению - трата / доход. Удаление операций невозможно (ибо грех), только сторнирование.

Финансовый модуль тесно интегрирован со всеми остальными модулями: например, каждая конкретная сделка имеет свою историю трат / доходов, льющихся в единую базу операций.

Таким образом, каждая операция (транзакция) характеризуется прежде всего:

• суммой;

• направлением;

• временной меткой.

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

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

Итак, мы знаем, с чем работаем, теперь задача попроще - как прогнозировать?

Прогнозирование

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

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

Большинство моделей опираются на три основных компонента:

• уровень (среднее значение ряда в данный момент);

• тренд (устойчивый рост или падение);

• сезонность (повторяющийся паттерн фиксированной длины).

Давайте взглянем на фаворитов:

1. Простое экспоненциальное сглаживание (SES) (только уровень)

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

прогноз = α × сегодняшнее_фактическое + (1-α) × вчерашний_прогноз

Казалось бы, просто и делать 2 минуты, но даже здесь мы нехотя будем перебирать коэффициент сглаживания (α), минимизирующий ошибку прогноза.

2. Holt-Winters (старая гвардия)

Три компонента: уровень, тренд, сезонность. Для каждого компонента свой коэффициент сглаживания соответственно: α, β, γ. Каждый рассчитывается по своей формуле.

Не будем расписывать все формулы. Можно почитать тут.

Просто заметим, что для нормальной работы модели нужно как минимум:

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

• минимум 2 сезона: в случае с недельным сезоном - 14 дней, в случае с месячным - 60. Хотите, чтобы работало? - ведите учёт минимум N дней;

• перебор 3 параметров (α, β, γ) или использование стандартных -> снижение точности.

3. Theta (спасибо)

Разложение временного ряда на две линии:

• первую сглаживаем и экстраполируем (консервативная): простое экспоненциальное сглаживание. Берём исходный ряд и прогоняем через SES (первая модель) с коэффициентом α = 0.3 (начальное приближение в большинстве библиотек). После этого считаем тренд - на сколько в среднем росла или падала эта плавная кривая. Экстраполируем: SES_прогноз = последнее_значение + тренд × h;

• вторую экстраполируем без сглаживания (агрессивная): проводим прямую через все точки методом наименьших квадратов. Считаем наклон (slope) и пересечение (intercept). Экстраполируем: регрессия_прогноз = slope × (n + h) + intercept.

Итоговый прогноз - среднее между двумя полученными линиями:

прогноз = (SES_прогноз + (θ - 1) × регрессия_прогноз) / θ

Стандарт θ = 2, тогда:

прогноз = (SES_прогноз + регрессия_прогноз) / 2

У модели Theta есть одна очень важная в случае с Kroncl особенность: прогнозирование возможно уже начиная со второй точки, то есть достаточно 2 дней ведения финансовой отчётности. Для малого бизнеса - это слишком хорошо. Да, мы теряем сезонность, да, точность прогнозирования всё ещё напрямую зависит от количества точек анализа, но это решается добавлением уровня точности в ответ клиенту.

Существуют методы вроде Prophet, добавляющих дополнительные параметры при расчёте прогноза, но, повторюсь, в случае с Kroncl именно Theta даёт разумную точность на коротких рядах без ручного конфигурирования сезонности.

Снова пишем

Замечу, что кодовая база сервера Kroncl превысила 40 тысяч строк кода, включая конфигурации разрешений и прочего добра, но интегрировать forecast_ подсистему в модуль fm (управление финансами) не составило большого труда.

Сделаем два базовых метода:

• forecast/timeline - базовое получение ряда прогноза, полученного с помощью Theta;

• forecast/summary - агрегация поверх timeline, динамический подсчёт баланса, трат, доходов, чистого потока к концу горизонта прогноза.

Реализация расчётов упакована здесь.

Ограничиваем возможный горизонт прогноза для сохранения точности: горизонт <= 2 × кол-во точек анализа.

Оппа

И конечно, испытаем оргазм от результата, рассмотрим прогноз на 1400 операциях (около 200 точек анализа), преимущественно траты, с горизонтом в 100 дней. Автор лентяй и не будет проводить детальное сравнение рядов разной длины, думаю, принцип понятен.

В итоге, достаточно 2(!) точек для построения минимально точного прогноза. В идеале, прогнать аналогичные ряды через все три модели: SES, Theta, Holt-Winters и сравнить степень сглаживания и точность. Если вам нечем заняться - вперёд.

В заключение

В заключение ничего не будет. Просто Theta прогнозирование финансового модуля на Go. Kroncl - облачная ERP система для малого бизнеса. Физическая изоляция данных, ролевая модель на 70+ разрешениях, 5 модулей, 130 тысяч кода.

Kroncl | Github - Разработчикам | Документация