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