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