Я продолжаю разбирать курс, в котором показывают базу 1С:Комплексная автоматизация и объясняют, как в ней реализована методика управленческого учета. На этот раз дошла до подсистемы бюджетирования. Открыла настройки, модели, статьи, виды бюджетов — и это как раз тот случай, когда внешне все выглядит прилично, но чем глубже смотришь, тем больше хочется задавать вопросы.
Сразу зафиксирую важную вещь. Для меня на первом месте всегда стоит методология. Сначала должна быть разработана методология бюджетирования. И только после этого настраивается программа.
Поэтому в этой статье я не обсуждаю методологию курса в целом — это отдельный разговор. Здесь я смотрю именно на техническую реализацию бюджетирования в базе, но оцениваю ее, конечно, через методологическую призму. Иначе технический разбор сам по себе ничего не стоит.
С чего я начинаю технический анализ подсистемы бюджетирования
Если методология уже разработана, то первое, что технически нужно смотреть в программе, — это параметры программы в части подсистемы бюджетирования и планирования.
Именно там включаются и определяются базовые возможности системы: активирована ли подсистема бюджетирования, используется ли бюджетный процесс, применяются ли лимиты, какие механизмы вообще доступны в этой базе. Это очень важный слой настройки, потому что он определяет, какие объекты и сценарии в принципе могут работать в программе.
Но в рассматриваемой учебной базе доступа к параметрам программы у меня нет. А это важно. Значит, напрямую проверить этот слой настройки я не могу и могу делать выводы только косвенно — по тем объектам, которые мне доступны в самой подсистеме бюджетирования.
Поэтому первое, что я открываю уже в доступной части базы, — это модели бюджетирования.
Почему у меня сразу возник вопрос к моделям бюджетирования
На уровне модели бюджетирования задается верхний уровень логики бюджетного контура: в каких измерениях ведется бюджет, определяется функциональная валюта, включен ли учет по организациям и подразделениям, определены бюджетные процессы и правила контроля лимитов.
И вот здесь я вижу, что в базе курса используются две действующие модели бюджетирования: отдельно под БДДС и отдельно под БДР.
Для меня это уже странный сигнал.
Потому что БДР и БДДС — это действительно разные бюджетные формы, но из этого не следует автоматически, что их нужно разводить по разным моделям бюджетирования.
Модель — это логика бюджетного контура.
Вид бюджета — это форма, в которой данные показываются пользователю и используются для ввода, анализа или отчета.
И здесь мой вопрос не в том, можно ли так настроить технически. Технически, конечно, можно.
Мой вопрос в другом: какую управленческую и техническую задачу решает такое разделение?
Если бы речь шла о действительно разных независимых контурах управления, разных принципах учета, разных процессах согласования, разных правилах лимитирования — это можно было бы обсуждать.
Но если БДР и БДДС просто разнесены по двум моделям, то возникает закономерный вопрос: а что будет дальше? На каждую бюджетную форму делать отдельную модель? А если форм не две, а десять? А если у каждой модели свой бюджетный процесс? Тогда вместо единого бюджетного контура мы получаем набор разрозненных настроек, которые между собой живут отдельно.
А это неудобно уже не только методологически, но и технически.
Поэтому мой первый вопрос к разработчикам курса звучит так:
какую именно задачу решает разнесение БДР и БДДС по разным моделям бюджетирования?
Пока для меня это выглядит не как сильная архитектура, а как спорное решение, которое усложняет дальнейшую логику настройки и сопровождения.
Самая частая ошибка, с которой я сталкиваюсь на проектах: дублирование справочников в статьях бюджетов
Дальше я открываю статьи бюджетов и вижу как раз тот подход, с которым очень часто сталкиваюсь, когда прихожу на проект уже на доработку бюджетирования.
Это одна из самых типовых проблем.
В базе курса сделано следующее:
- для БДДС статьи бюджетов фактически дублируют справочник статей движения денежных средств;
- для БДР статьи бюджетов фактически дублируют справочник статей расходов.
И вот это, на мой взгляд, неправильный подход.
То есть вместо того, чтобы строить бюджетную модель на более укрупненной и управляемой логике статей бюджетов и использовать аналитику, в систему фактически переносят справочники один в один:
- статьи движения денег — в статьи бюджетов для БДДС;
- статьи расходов — в статьи бюджетов для БДР.
На старте это может даже производить хорошее впечатление. Видно, что люди старались, все детально разложили, не поленились, аккуратно перенесли структуру в новый справочник. Работа трудоемкая, это правда.
Но проблема начинается потом — в живой эксплуатации.
Допустим, в компании появляется новая статья движения денежных средств или новая статья расходов. Что происходит дальше?
Нужно:
- добавить ее в исходный оперативный справочник;
- отдельно добавить ее в статьи бюджетов;
- настроить для нее правила получения факта;
- настроить связи этой статьи с показателями бюджетов, если она влияет на остатки;
- проверить, в каких видах бюджетов эта статья должна появиться;
- внести изменения в эти виды бюджетов;
- затем проверить, не сломалась ли логика форм и отчетов после донастройки.
То есть любое изменение в живом бизнесе превращается в цепочку ручных действий по нескольким объектам системы.
И вот это уже проблема.
Потому что статьи бюджетов не должны дублировать оперативные справочники. Наоборот, их обычно стараются делать более устойчивыми и более управляемыми.
Для БДДС в ряде проектных решений вполне может быть достаточно одной-двух укрупненных статей, например:
- поступление денег;
- расход денег,
а детализацию уже раскрывать через аналитику по статьям движения денежных средств.
То же самое и по БДР: логика бюджетных статей должна строиться не по принципу «перенесем весь справочник расходов в бюджет», а по принципу «оставим в бюджете тот уровень агрегирования, который реально нужен для управления».
И здесь у меня следующий вопрос к курсу:
почему выбран именно путь дублирования справочников в статьях бюджетов, а не путь более устойчивой бюджетной модели с аналитическим раскрытием?
Потому что именно такой дубляж на практике потом очень тяжело сопровождать.
Что происходит дальше: избыточная детализация статей быстро переползает в виды бюджетов
Когда статьи бюджетов делают слишком детальными, эта проблема почти сразу начинает жить дальше — в видах бюджетов.
И в базе курса это тоже видно.
Вид бюджета начинает строиться как форма, где строки жестко завязаны на конкретные статьи: выручка, себестоимость, дальше отдельные строки под расходы маркетплейсов, комиссии, кроссдокинг, логистику, платную приемку, хранение, штрафы и так далее.
На учебном примере это выглядит аккуратно. Все знакомо, все разложено по строкам, форма кажется понятной.
Но это ощущение держится ровно до того момента, пока бизнес не начинает меняться.
Как только появляется новая статья расхода или новое движение денег, выясняется, что вид бюджета у нас — это уже не просто форма, а форма, жестко пришитая к текущему набору статей.
А значит, изменения надо вносить не только в справочники и правила факта, но еще и в сами виды бюджетов.
То есть форма становится негибкой.
А это уже прямая архитектурная проблема.
Вид бюджета должен быть устойчивой формой управления, а не списком всех существующих статей, который нужно постоянно переписывать.
Вот почему я считаю, что проблема здесь не только в детализации статей, но и в том, что эта детализация потом тащит за собой всю остальную настройку.
Отдельная проблема — правила получения факта под каждую статью
Следующий слой, который в такой архитектуре неизбежно страдает, — это правила получения фактических данных.
Сам по себе механизм правил получения факта в 1С гибкий. Но вопрос не в том, есть ли такая возможность. Вопрос в том, как именно ее используют.
В рассматриваемой базе под каждую детальную статью бюджета фактически настраиваются похожие правила получения факта с разными отборами.
И это как раз та история, которая на коротком учебном примере может выглядеть терпимо, а на реальном проекте начинает создавать проблемы:
- растет объем настройки;
- усложняется сопровождение;
- замедляется формирование отчетов;
- возрастает риск ошибок при появлении новых статей;
- приходится поддерживать актуальность не одной логики, а множества похожих правил.
То есть система становится тяжелой не потому, что в ней есть бюджетирование, а потому, что сама архитектура настройки делает ее тяжелой.
И вот здесь для меня уже вопрос не к механизму 1С, а к проектному решению:
зачем изначально строить модель так, чтобы потом факт приходилось поддерживать по слишком детализированной и трудоемкой схеме?
Ручное планирование почти по каждой статье — тоже плохой сигнал
Еще один момент, который меня смущает в этой базе: складывается ощущение, что планирование по статьям в значительной степени выполняется вручную — без драйверов, без заметной расчетной логики, без опоры на более автоматизированные способы формирования плана.
И это тоже важный момент.
Потому что если подсистема бюджетирования в программе сводится к тому, что пользователь просто руками заносит значения в формы, то технически это, конечно, работает. Но управленческая ценность такой настройки уже под вопросом.
Система должна не только хранить бюджет, но и помогать его формировать.
Да, не в каждом проекте все можно и нужно автоматизировать. Да, не везде нужны сложные драйверные модели. Но когда почти каждая статья живет в ручном режиме, это уже не выглядит как сильная рабочая подсистема бюджетирования.
Это выглядит как форма для ручного ввода, просто в аккуратном интерфейсе.
Бытовой пример, почему такая архитектура быстро начинает мешать
Представьте шкаф. Можно сделать нормальную систему хранения: несколько крупных секций, внутри — понятная детализация. А можно сделать отдельный ящик под каждый тип вещей, а потом к каждому ящику еще отдельную инструкцию, подпись и правило, как его открывать.
Пока вещей мало, все выглядит даже аккуратно.
Но как только появляется что-то новое, выясняется, что вы не храните вещи — вы обслуживаете шкаф.
Вот здесь с бюджетированием то же самое. Если мы начинаем дублировать справочники в статьях бюджетов, затем фиксировать эти статьи в видах бюджетов, а потом под каждую из них поддерживать отдельные правила факта, то в какой-то момент команда уже не бюджетирует бизнес, а обслуживает конструкцию, которую сама же и усложнила.
Какие вопросы у меня возникают к разработчикам курса
Если собрать мои замечания в короткий перечень, то вопросы такие.
1. Почему БДР и БДДС разведены по разным моделям бюджетирования?
Какую задачу это решает с точки зрения управления, настройки и дальнейшего сопровождения?
2. Почему для БДДС статьи бюджетов дублируют статьи движения денежных средств?
Почему не выбрана более устойчивая модель с укрупненными бюджетными статьями и аналитическим раскрытием?
3. Почему для БДР статьи бюджетов дублируют статьи расходов?
Какой в этом управленческий смысл, если это усложняет сопровождение и делает бюджет зависимым от детализации оперативного справочника?
4. Почему виды бюджетов жестко завязаны на фиксированные строки?
Как система должна сопровождаться при появлении новых статей?
5. Почему факт по статьям собирается через множественные похожие правила с отборами?
Не приводит ли это к ненужному усложнению и утяжелению модели?
6. Почему планирование в базе выглядит в значительной степени ручным?
Это действительно целевая рабочая логика или просто упрощение для учебного примера?
Что я бы рекомендовала коллегам не делать в своих проектах
Если вы настраиваете бюджетирование в 1С:КА или 1С:ERP, я бы не рекомендовала:
- разводить разные бюджетные формы по разным моделям без очень четкого основания;
- дублировать оперативные справочники в статьях бюджетов;
- делать виды бюджетов зависимыми от полного перечня детальных статей;
- строить архитектуру, в которой любая новая статья требует изменения сразу в нескольких объектах системы;
- плодить правила получения факта вслед за чрезмерной детализацией статей;
- подменять подсистему бюджетирования обычным ручным вводом цифр.
Потому что все это в сумме делает систему не сильнее, а тяжелее.
Мой вывод по этому примеру
На текущем этапе мой вывод такой: в базе курса подсистема бюджетирования выглядит технически собранной, но архитектурно и методологически спорной.
Главная проблема для меня не в одной отдельной настройке, а в самом подходе:
- модели разведены сомнительным образом;
- статьи бюджетов дублируют оперативные справочники;
- виды бюджетов становятся зависимыми от этой детализации;
- правила факта утяжеляются;
- планирование выглядит слишком ручным.
Именно поэтому я бы рассматривала этот пример не как образец для копирования, а скорее как хороший материал для профессионального разбора: на нем очень хорошо видно, какие решения потом создают проблемы в реальном проекте.
Финал
Я еще буду смотреть следующие уроки курса, и, возможно, часть решений дальше раскроется полнее. Но на текущем этапе у меня вопросов к этой подсистеме больше, чем доверия к ней как к образцу рабочего проектного решения.
И, честно говоря, это тоже полезный результат обучения. Потому что иногда курс хорош не тем, что ты потом дословно повторяешь у себя в проекте, а тем, что после него ты гораздо увереннее понимаешь, как делать не надо.
А это, для бюджетирования, тоже вполне практический результат.
