Можно ли начинать автоматизацию управленческого учета без готовой методологии?

В прошлой статье я описал, из чего состоит функциональная модель управленческого учёта — документ, по которому систему можно настроить без интерпретаций. Самый частый вопрос после¹ таких текстов: «У нас этого нет и в ближайшие полгода не будет. Что, не начинать?»

Честный ответ: начинать можно. Но нужно понимать, что именно вы делаете и чем за это платите.

Готовой методологии нет почти ни у кого. Не потому, что финансисты ленивы, а потому, что управленческий учёт в большинстве компаний вырос эволюционно: сначала ДДС в Excel, потом подобие P&L, потом «а давайте по направлениям». Правила есть, но они размазаны по формулам, привычкам и голове одного человека. Чтобы их собрать и записать, нужно время, которого у финансового директора нет, и навык, которого у него может не быть — описывать учёт в терминах счетов, аналитик и мэппинга не то же самое, что уметь его вести.

Плюс есть ситуации, когда ждать нельзя: собственник требует отчётность «к следующему кварталу», готовится сделка, пришёл инвестор, таблица уже откровенно врёт. В таких условиях полгода писать модель — не вариант.

Метафора точнее, чем кажется. Дом без проекта строят — на дачах, в частном секторе, иногда вполне удачно. Но посмотрите, при каких условиях это получается:

• Бригада делала это много раз и знает, где обычно ошибаются. Она сама задаёт заказчику вопросы, которые тот не догадался бы задать.

• Заказчик присутствует на стройке и принимает решения быстро, а не раз в месяц на совещании.

• Конструкция допускает изменения: несущие стены определены сразу, а перегородки можно двигать.

• Все понимают, что сметы «точно» не будет, и закладывают резерв.

Уберите любое из этих условий — и получите либо недострой, либо дом, в котором кухня оказалась без окна, потому что «так уже залили».

С автоматизацией учёта то же самое. Переведу условия на язык проекта.

Если модели нет, кто-то должен создавать её параллельно с настройкой. Это не программист — программист реализует то, что ему сказали. Это методолог, который понимает и учёт, и систему, и умеет задавать правильные вопросы в правильный момент: «Вы хотите видеть маржу по направлениям — значит, в каждом документе реализации должно быть указано направление. Сейчас оно указано? В 40% документов нет. Кто будет заполнять и по какому правилу?»

Такой человек нужен и на стороне подрядчика, и на стороне заказчика — финансист, у которого есть полномочия принимать методологические решения и время их принимать. Если решения по каждому вопросу ждут финансового директора две недели, проект без модели превращается в проект без движения.

Признак правильной команды: она начинает с вопросов, а не с демонстрации. И фиксирует ответы письменно — то есть модель всё равно пишется, просто не до проекта, а во время него, кусками, по мере принятия решений.

Даже без полной модели есть решения, которые нужно принять до первой настройки, потому что потом их не изменить без пересборки. Это «несущие стены»:

·       Периметр и источники: какие юрлица, какие базы, что первично.

·       Учёт на плане счетов с двойной записью или «отчёт из регистров». Это архитектурное решение, обратного хода у него практически нет.

·       Валюта и сценарии (с НДС / без, факт / план).

·       Ключевые аналитики: ЦФО, направления, проекты. Не полный справочник, а принцип: что это такое и откуда берётся.

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

Это главное, ради чего я пишу эту статью. Когда методология есть, выбор системы — вопрос соответствия: смотрим требования, смотрим возможности, выбираем. Когда методологии нет, требования будут меняться по ходу. Значит, инструмент должен выдерживать изменения без доработок — а это свойство, которым системы отличаются радикально.

Я подробно разбирал это в статье об ограничениях типовой 1С:ERP в управленческом учёте, напомню суть. В ERP управленческий баланс в базовом варианте строится из оперативных регистров: нет двойной записи по управленческому плану счетов, методология отражения типовых операций фиксирована, одна управленческая валюта на базу, своя статья баланса наполняется только из предусмотренных источников. Это отличная архитектура для компании, которая знает свои требования и они совпадают с заложенной моделью. Но для проекта «разберёмся по ходу» это ловушка: каждое уточнение методологии, которое не укладывается в типовую модель, становится либо отказом от функции, либо доработкой.

И вот здесь дом без проекта становится дорогим. Решили на четвёртом месяце, что нужно видеть P&L «до» и «после»¹ распределения косвенных? В системе на произвольном плане счетов это настройка. В системе с фиксированной методологией — доработка отчётов и, возможно, механизма распределения. Поняли, что нужна консолидация по двум юрлицам с исключением ВГО? В одном случае — субсчета и признак у контрагента, в другом — отдельный контур или отдельный продукт.

Что я называю гибким инструментом для управленческого учёта:

• Произвольный управленческий план счетов с настраиваемыми аналитиками — чтобы новая аналитика или субсчёт добавлялись настройкой, а не кодом.

• Настраиваемый мэппинг операций источника в проводки — правила отнесения меняются в таблице, а не в модуле.

• Настраиваемые закрытие и распределения с произвольными базами.

• Отчёты, которые строятся формулами по оборотам и сальдо, а не зашиты в код.

• Ручные операции и корректировки с историей — потому что без модели их будет много, особенно в первые месяцы.

Это может быть специализированный финансовый контур поверх оперативной базы, может быть отдельный продукт, может быть 1С:УХ, если масштаб того требует. Принцип один: цена изменения правила должна быть низкой, потому что правил, которые изменятся, будет много.

Проект без модели нельзя оценить фиксированной ценой — потому что неизвестен объём. Любой подрядчик, который называет фикс на проект без методологии, либо заложил двойной резерв, либо планирует компенсировать разницу доработками по часам после¹ «приёмки». Нормальная форма здесь — этапы с переоценкой или “время-материалы” с понятным контролем.

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

Для баланса — ситуации, где «разберёмся по ходу» заканчивается плохо почти всегда:

• Инструмент уже выбран и куплен, и он негибкий. Тогда методология будет подстраиваться под систему, а не наоборот — и компания получит учёт, который умеет программа, а не тот, который ей нужен.

• На стороне заказчика нет человека с полномочиями принимать методологические решения. Без него каждый вопрос уходит «наверх» и возвращается через месяц.

• Проект с фиксированной ценой и фиксированным сроком. Это несовместимо с неизвестным объёмом.

• Группа компаний с консолидацией и несколькими валютами. Слишком много несущих стен, чтобы определять их по ходу.

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

Это даёт главное: дорогие ошибки отсекаются до настройки, а дешёвые — исправляются в процессе. И инструмент выбирается уже с пониманием, какие из требований точно не впишутся в типовую модель.

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

Если какого-то из трёх нет — лучше потратить месяц на каркас модели. Это дешевле, чем переставлять несущие стены в доме, который уже заселён.

А у вас как начинался проект: с модели, с системы или с «давайте уже что-нибудь настроим»? И чем закончилось?