Типичные ошибки автоматизации управленческого учета

Привет, я руководитель проектов в компании Smart Process. Я больше 20 лет занимаюсь автоматизацией управленческого учета и расскажу про типичные ошибки, с которыми сталкиваюсь в своей практике.

Уточню, что в данном материале под управленческим учетом я имею ввиду финансовый контур учета: баланс, отчет о прибылях и убытках (P&L) и отчет о движении денежных средств (ДДС).

Все ошибки, которые я наблюдаю на проектах, можно условно разделить на два больших блока:

• ошибки методологии;

• ошибки в выборе и использовании софта.

Ошибки методологии

1. Автоматизировать учет без нормальной методологии

Очень часто малый и средний бизнес ведет учет в Excel: в разрозненных файлах, без четких правил, без контроля корректности данных и без внятных проверок.

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

2. Смешивать кассовый метод и метод начислений в одном отчете

Это одна из самых распространенных проблем.

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

На мой взгляд, это категорически неправильно.

Если компания хочет нормальный управленческий учет, нужно сразу строить полноценную модель, в которой:

• P&L ведется по методу начислений;

• ДДС ведется отдельно, по движению денег;

• баланс связывает все в единую систему.

3. Игнорировать баланс

Баланс недооценивают очень часто. Причем не только небольшие компании, но и достаточно крупный бизнес.

Обычно аргумент звучит так: «Нам нужен P&L и ДДС, а баланс — это что-то бухгалтерское, для формальности».

Но это ошибка. Баланс важен не только сам по себе, как источник информации об активах, обязательствах и капитале. Он еще и хороший инструмент проверки корректности учета - если прибыль в балансе не совпадает с прибылью в P&L, значит, где-то ошибка. А если баланс вообще не ведется, то обнаружить такие ошибки становится намного сложнее.

4. Пытаться «срезать углы» и заниматься самообманом

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

Приведу пару типичных примеров.

У одного клиента при вводе остатков просто проигнорировали склад с неликвидами: «считаем, что их нет». Но в реальности склад был, движения по нему были, и в результате это приводило к постоянным расхождениям и ошибкам.

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

Именно здесь начинается самообман. Формально цифры есть. Фактически — реальности они не отражают.

Самый распространенный вариант такого самообмана — оставлять затраты в балансе и не показывать их в P&L. Прибыль в этом случае выглядит лучше, отчет красивее, а руководству спокойнее. Но проблема в том, что реальное положение дел от этого не меняется. Меняется только качество управленческих решений — и, как правило, в худшую сторону.

5. Излишне увлекаться распределением затрат

Про распределение затрат сказано и написано уже очень много (что не надо распределять все и вся). Тем не менее, желание распределить буквально все — одна из самых живучих идей в управленческом учете.

Причем чем сложнее схема распределения, тем чаще кто-то считает ее «более правильной».

На практике в большинстве случаев сложная система распределения:

• ухудшает прозрачность;

• создает ложную точность;

• требует лишних трудозатрат;

• провоцирует неверные управленческие выводы.

Особенно печально, когда на основании искусственно распределенных накладных затрат начинают принимать решения о закрытии или развитии проектов. Например, считать проект убыточным только потому, что на него «размазали» слишком много общих расходов.

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

6. Излишняя детализация при отсутствии ресурсов

Во время внедрения новой системы очень хочется «сделать сразу идеально»: максимальную детализацию, аналитику до минут, граммов, штук, этапов и так далее.

Но ключевой вопрос здесь: сможет ли компания это обеспечить и поддерживать?

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

• данные должны поступать вовремя;

• данные должны быть достоверными;

• данные должны иметь необходимую точность.

• кто-то должен эти данные вводить в систему

Если хотя бы одно из этих условий не выполняется, смысла в такой детализации нет.

Однажды я видел ситуацию, когда компания хотела вести учет с точностью до 100 граммов, но при этом на складе стояли весы с дискретностью 10 килограммов. То есть физическая инфраструктура не позволяла получить те данные, которые требовались.

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

Ошибки в выборе софта

Следующий большой блок ошибок — отталкиваться от программного продукта, а не от задачи.

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

Правильная последовательность обратная: сначала — что именно вы хотите получить, потом — как это лучше реализовать.

Если делать наоборот, почти неизбежно возникают проблемы:

• неудобство в работе;

• лишние компромиссы;

• дорогие и бессмысленные доработки;

• завышенные ожидания и разочарования от неподходящего решения;

• ну и бессмысленно потраченные деньги

1. Пытаться использовать 1С:Бухгалтерию для управленческого учета

На первый взгляд идея кажется логичной. В 1С:Бухгалтерии есть план счетов, двойная запись, привычная логика учета. Кажется, что это хорошая база и для управленческой отчетности.

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

И здесь начинается самое неприятное. Чтобы адаптировать 1С:Бухгалтерию под управленческие задачи, почти всегда приходится менять аналитику. А это, как правило, означает доработки. Причем не самые простые и не самые дешевые.

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

• либо идти на большие компромиссы;

• либо делать значительные доработки, которые не всегда оправданы экономически.

Поэтому использовать 1С:БП как основу для управленческого учета можно далеко не всегда, и уж точно не стоит воспринимать это как универсальное решение. 

2.    Надеяться, что 1С:ERP автоматически даст полноценный управленческий учет

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

Формально — да, инструменты там есть. Но на практике есть важные нюансы.

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

Во-вторых, в 1С:ERP существует несколько способов вести управленческий учет, и у каждого из них есть свои ограничения.

1. Управленческий учет на регистрах

Для оперативной отчетности (продажи, закупки, складских движений) регистры действительно удобны. Но когда речь заходит о полноценной финансовой отчетности, начинаются сложности.

Основные проблемы здесь такие:

• сложно контролировать ошибки, потому что нет полноценной логики двойной записи;
  да, есть отдельные контрольные отчеты по активам и пассивам, но по удобству и надежности это не сравнимо с классическим Дт/Кт;

• ограничены возможности распределения и закрытия затрат;
  если компании нужна нестандартная логика, доработка обычно получается трудоемкой;

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

  
  2. Управленческий учет на плане счетов бух. учета.

Это еще более спорный вариант.

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

Например:

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

• в бухгалтерском учете объект идет как основное средство, а в управленческом — как материалы с последующим списанием на затраты

Как только возникают такие расхождение, типовая логика перестает нормально работать.

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

3. МСФО

Теоретически кажется, что этот механизм можно использовать для построения управленческой отчетности. На практике — тоже много ограничений.

Обычно проблемы возникают в двух местах:

• сложно и неудобно заполнять факт;

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

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

Что из этого следует

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

Чаще всего причина в другом:

1. компания сначала долго живет с неформализованным учетом;

2. потом пытается автоматизировать этот хаос без пересмотра методологии;

3. затем подбирает софт не под задачу, а по принципу «это же популярное решение»;

4. В итоге, вынуждена либо мириться с ограничениями, либо дорого дорабатывать систему, либо возвращаться в Excel.

Правильный путь выглядит иначе:

• сначала определить, какая отчетность действительно нужна бизнесу;

• затем выстроить методологию учета;

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

• и только после этого выбирать программный продукт и запускать проект автоматизации.