Запуск в 1С:ERP регламентированного учета без оперативного контура
Автор статьи: Пикурен Вера Александровна
Работает в ВЦ «Раздолье» с 2005 года. В настоящее время – руководитель проектов. Начинала с внедрения конфигурации «1С:УПП», с 2015 года занимается внедрением 1С:ERP. За это время успешно запустила на 1С:ERP 6 заводов. Последний проект (АО НПО ЛЭМЗ) стал победителем Конкурса корпоративной автоматизации «1С:Проект года» в номинации «Лучший проект года в предметной области Бухгалтерский и налоговый учет» (https://eawards.1c.ru/projects/1200-rabochih-mest-na-1s-erp-41612/ ).
Сегодня я хочу обсудить вопрос, который в ИТ-сообществе вызывает очень много споров: можно ли запускать регламентированный учет в 1С:ERP без оперативного контура, нужно ли это делать и в каких случаях это не просто нужно, а необходимо.
Тема эта возникла не просто так. Многие специалисты 1С уверены, что начинать внедрение 1С:ERP нужно именно с оперативного контура, а после того, как будет отлажен оперативный контур, достаточно будет просто включить формирование проводок, и вот мы получим баланс, декларации и остальную бухгалтерскую отчетность.
Соответственно, в этом году к нам в фирму поступает очень много запросов как раз от заводов, которые начали внедрение именно по этой схеме: запустили склады, закупки, продажи, даже производство. Дошли до формирования проводок, закрытия месяца и ничего не получили в итоге.
Провозились месяц, два, три, но никаких нормальных проводок, которые принимает бухгалтерия, система не дает; расчет себестоимости либо не проходит вовсе, либо выдает что-то непонятное. Потеряв еще какое-то время, они обращаются к другим интеграторам, в частности, к нам. И когда ты начинаешь анализировать базу, выяснять, что именно хотела получить финансовая служба, то очень быстро понимаешь, что простыми настройками системы проблему не решить, требуется большое перевнедрение тех самых оперативных процессов. Документооборот был выстроен без оглядки на особенности расчета себестоимости, закрытия месяца, бухгалтерского учета и так далее. И теперь надо, во-первых, менять цепочки ввода документов, а во-вторых, скорее всего, пересматривать регламенты взаимодействия между разными службами.
Очень показательна здесь давальческая схема. Когда склады ведут учет отдельно от бухгалтерии, они могут в большинстве своем и не знать, что работают с давальческим сырьем. Они просто приходуют его и выдают в производство как обычные товарно-материальные ценности. А дальше уже бухгалтерия в своей отдельной программе разбирается, чье это и какие счета учета ставить. И, соответственно, если внедренцы при запуске складов не выяснили этот вопрос, то никаких нормальных проводок Вы, конечно же, не получите. Более того, данная проблема потребует повторного переноса остатков с разделением ТМЦ на собственное, давальческое, возможно, комиссионное и т.д.
Приведенный выше пример все-таки представляет собой локальную сложность, которую можно быстро исправить. Гораздо больше неприятных сюрпризов приносит блок учета затрат и расчета себестоимости. Это сложный механизм, в котором участвуют большое количество объектов системы. То есть если Вы чего-то в нем сразу не учли, то переделывать и перепроектировать, возможно, придется весь документооборот. К тому же, данный блок имеет ряд довольно неожиданных нюансов, которые должен знать архитектор. Данные «технологические особенности» в большинстве случаев нигде не описаны, то есть пока консультант сам о них «лбом не ударится», он их знать не будет, и, соответственно, не учтет при проектировании. При комплексном запуске такие проблемы сразу «всплывают», что позволяет оперативно исправить документооборот. Если же Вы оставляете закрытие месяца «на потом», то только очень опытный архитектор сможет сразу на входе спроектировать оперативный контур так, чтобы расчет себестоимости в итоге получился таким, как требует финансовая служба.
Мое мнение таково: если у Вас нет возможности сразу запустить комплексный проект, то стартуйте систему отдельными подсистемами, но только вкупе с соответствующими частями регламентированного учета. Я в своей практике никогда не запускаю просто оперативный контур в надежде на то, что когда-нибудь потом регламентированный учет «ляжет» на него сам собой. Слишком большие риски. Более того, мы сейчас вообще проектирование любой системы начинаем именно с блока затрат. Сначала определяем, что мы должны в него передать, чтобы получить требуемый результат, и спускаем требования к остальным смежным блокам: спецификации и заказы на производство могут быть любыми, но мы должны получить от производственной подсистемы вот такие этапы с такими настройками.
При этом бывают такие случаи, когда вообще лучше не лезть сразу в комплексный проект, а ограничится только регламентированным учетом. Причин может быть много, я выделила четыре основных. Обращаю внимание, что я не веду речь о том, чтобы предприятию запустить 1С:ERP только ради бухучета, а о том, чтобы начать с него, а дальше смотреть, как пойдет проект, и уже принимать решение о его продолжении.
Во-первых, это - очень большие заводы.
Под большими заводами я имею в виду предприятия с 4мя тысячами и более сотрудников. Их особенность в том, что по большинству оперативных блоков не будет человека, который знает нюансы всех подразделений. Для меня реально это было первым неприятным открытием, когда я столкнулась с такими заводами. Условно, берем начальника МТО, которому подчиняются 60 складов: он знает их специализацию, знает границы, в которых они работают, но вникнуть в таких масштабах в каждый процесс физически не может. И других людей, которые полностью знают учет на всех складах, тоже нет. То есть Вам придется на все эти 60 складов сходить своими ногами. Если там есть хоть какая-то программа, то Вам повезло: можно будет увидеть автоматизированные операции. Если же программы нет, то Вам надо будет поднять и посмотреть всю их документацию, отчеты, расчеты и так далее, собрать все это в одну «кучу», понять, что оно все абсолютно разное и попытаться свести в единую архитектуру системы. Например, я однажды на проекте наткнулась на то, что, хотя предприятие вело оценку ТМЦ по средней, но одном конкретном складе для конкретных типов дорогостоящих агрегатов велся учет по индивидуальным единицам. Никто этого не знал: ни главный бухгалтер, ни его заместители. Когда начали «копать», то обнаружили соответствующий приказ генерального директора пятнадцатилетней давности.
Данный процесс занимает очень-очень большое количество времени. И вот на таких заводах внедрения постепенно вырождаются в бесконечное согласование процессов и проектных решений. Сроки сдвигаются, все к этому уже привыкли, документация подписывается и переподписывается, Походу, пока вы это согласование сделали, у них уже меняются процессы, вы заходите на очередной круг и так далее. Если посмотреть на такие предприятия, то у них все время идут какие-то внедрения. Не обязательно 1Совские, некие PDM , PLM системы. Внедрение идет, реальных запусков нет.
Здесь на помощь приходит именно регламентированный учет, потому что там операции понятны, конкретны, ограничены и определены законодательством. Фантазировать там сложно (за что, наверное, и не любят внедрение бухучета многие архитекторы системы). Мы можем сразу четко определить границы проекта, его цели и, самое главное, результат: мы делаем то-то (что-то вносим сразу в 1С, что-то перезагружаем из других систем), вот такие-то расчеты делаем в системе, получаем такую-то отчетность за первый, второй квартал.
Здесь на фоне других внедрений информационных систем можно очень хорошо выиграть. Если Вы реально запустите бухучет, то сразу же получите большой ресурс доверия, который очень пригодится при внедрении оперативного контура. То есть когда, при запущенном регламентированном учете, МТО откажется вносить, к примеру, заказы поставщиками, и начнут шуметь «у нас нет людей, неудобно, сложно и т.д.», то генеральный директор будет уже относиться к их докладным запискам совсем по-другому.
Вторая причина подумать о запуске только регламентированного контура - это когда заказчиком выступает бухгалтерия или финансовая служба, а собственник или генеральный директор не участвуют в проекте.
Такие проекты встречаются довольно часто. В этом случае успех внедрения будет целиком зависеть от того, насколько далеко простираются полномочия финансовой службы. Вы должны как руководитель проекта, как консультант, сразу оценить риски, насколько вообще возглавляющий проект от заказчика человек сможет заставить, например, начальников цехов вбить в систему то, что вам нужно. Сразу это понять очень сложно, так что завязывать на ограниченные полномочия финансовой службы успех комплексного проекта я бы не рискнула. Если заказчик у вас бухгалтерия, то и начинайте с регламентированного учета. Повторюсь, это блок с понятным списком операций, которые предприятию нужно в систему завести. Вы можете сразу определить ответственных по каждой операции, и потом требовать их наличия в системе, потому что от первички зависит сдача бухгалтерской отчетности. То есть от того, что там, например, начальник МТО не вобьет план закупок, предприятие не оштрафуют. А вот за отсутствие декларации по налогу на прибыль или по НДС мы сразу «влетим» на соответствующие санкции.
Таким образом, бухгалтерия в любом случае будет вносить первичку. Там есть двигатель, есть потребность в том, чтобы внедрение шло. А вот если Вы сразу пойдете в оперативный контур, то всегда есть высокий риск того, что какие-то подразделения могут не хотеть, во-первых, увеличения нагрузки на своих сотрудников, а во-вторых, повышения прозрачности. Мы же все прекрасно понимаем, что на всех заводах у каждого отдела есть свои определенные интересы. Я сейчас говорю даже не про воровство, а скорее про то, что, например, каждый начальник отдела заинтересован, чтобы у него была меньше текучка кадров, чтобы его сотрудников не штрафовали за какие-то незначительные ошибки, а наоборот, начисляли премии, чтобы их зарплата была конкурентной по рынку. А как только появится сопоставление сделки с нормативами, как только программа покажет, что, к примеру, технологи вполне осмысленно загружают именно старые станки, потому что там плановая выработка рабочих больше, чем на новых, то со стороны людей, естественно, будет сопротивление внедрению системы. Сопротивление будет достаточно умное, достаточно грамотное. Вряд ли в стиле «мы не будем этого делать», а скорее «в принесенном на согласование документе допущены ошибки в названии наших станков…», и вопрос в том, насколько у финансовой службы хватит сил это сопротивление преодолеть.
А вот когда вы уже запустили какой-то большой кусок функциональности 1С: ERP , типа регламентированного учета, то Вам опять-таки будет гораздо проще потом преодолевать оборону остальных отделов. Вы показали, что умеете делать проекты, что в программе можно работать. И теперь уже можно подходить к генеральному директору с обсуждением конкретных проблем.
Третий тип проектов, когда я «захожу» именно с регламентированного учета – это внедрения без цели.
Бывает так, что приходишь на первую встречу, начинаешь выяснять, что люди хотят от новой системы, что не устраивает в текущих и получаешь примерно такой диалог:
- Вы где сейчас работаете?
- Ну вроде вот в excel работаем.
- Что не устраивает?
- Да все устраивает, все нормально.
- А вот если автоматические планирование будет в системе?
- Ну, вроде, звучит неплохо.
Начинаешь «копать» и понимаешь, что программу либо навязала сверху управляющая компания, либо собственник сходил на семинар, послушал, вернулся и заявил «хочу теперь, чтобы было так же, как у того завода». Сказать-то он сказал, а работать вам с людьми, которые непосредственно должны формировать требования к будущей системе и которые на данном этапе могут от нее вообще ничего не хотеть. Она в данный момент воспринимается ими как навязанная сверху «головная боль». И Вам, чтобы найти с ними контакт, надо как-то показать преимущества системы. И показать не на демо-примерах, а в реальной жизни. Соответственно, я в таких случаях всегда начинаю с регламентированного учета. Потому что дальше, видя возможности программы, другие отделы начинают довольно быстро втягиваться сами. Появляются потребности и реальные «плюшки», которые позволяют подразделениям решать какие-то свои проблемы. Тогда проект может вырулить во что-то реально функционирующее, соответствующее целям предприятия.
Если же сразу на таком предприятии пойти на комплексное внедрение, то да, возможно, что Вы продавите там какие-то куски планирования и т.д., но как только Вы с предприятия уйдете и перестанете их контролировать, то весь навязанный функционал постепенно отомрет. Программа останется на уровне регламентированного учета, потому что сдавать отчетность-то им все-таки нужно, а вот другие блоки без правильной и осмысленной цели не выживают.
Четвертый тип проектов, которых, кстати, сейчас становится все больше – это задача перевода учета из неких самописных систем в 1С:ERP.
Здесь Вашим главным врагом будет именно юзабилити. Самописные системы по удобству всегда на голову превосходят любые тиражные решения. Они пишутся под конкретных людей, под конкретные задачи, под конкретные процессы. Они удобные, работают быстро, работают хорошо, к ним редко бывают претензии. Приходишь смотришь что сделано, и понимаешь, что реально все круто. Но, чтобы сделать такую же вещь на 1С ERP , потребуется гигантское количество доработок, причем скорее не логики системы, а именно форм справочников, документов, помощников ввода, «защиты от дурака» и т.д.
Если вы сразу полезете во все области (договоры, планирование, закупки и т.д.), то после первого этапа обследования (или функционального моделирования, как оно называется в нашей компании), вы выйдете с тысячами часов доработок, которые принесете генеральному директору. Посмотрев на них, он скорее всего скажет «зачем мне в хлам переписанная система? Будет тоже самое, что и сейчас, только на другой платформе».
Соответственно, здесь я вижу тоже вариант заходить с регламентированного учета, потому что там основные операции уже автоматизированы. В зависимости от ситуации, первичку на таких заводах я оставляю в старых системах, забирая ее обменом.
И только показав работоспособность системы и свое умение ее внедрять, уже можно пытаться заходить в оперативный контур. Да, будет менее удобно. Да, пользователи будут массово писать докладные записки генеральному директору, но такое вот поэтапное внедрение позволит разделить реально необходимые доработки от «хотелок». Как показывает практика, 80% запросов на «бантики» отпадают после пары месяцев работы.
Что такое запуск регламен тированного учета без оперативного контура
Давайте теперь поговорим, о том, что я подразумеваю под запуском регламентированного учета без оперативного контура. Как известно, в ERP очень мало чисто бухгалтерских документов. Почти вся первичка так или иначе затрагивает как регламентированный, так и управленческий учет. Соответственно, запуская 1С:ERP для целей бухгалтерского учета, мы в любом случае захватываем куски оперативных блоков. Просто при таких внедрениях мы ориентируемся чисто на потребности бухгалтерии: нам достаточно, чтобы документ «Перемещение товаров» сформировал необходимые проводки, и нет необходимости лезть в планирование обеспечения, заказы на перемещение и т.д. Но как только придет время, мы легко «прикрутим» к отлаженной первичке управленческие блоки. Таким образом, мы сразу получаем каркас, на котором в дальнейшем будет развиваться система.
Давайте рассмотрим по разделам бухучета: насколько плотно они завязаны на оперативный контур.
Начнем с основных средств. Этот раздел как раз достаточно независим. Можно легко сначала запустить регламентированный учет ОС, а на более поздних этапах перейти к ремонту оборудования, инвестиционным бюджетам и так далее. Сначала из блока управления оборудованием нам потребуются только заказы на ремонт (для сбора затрат), которые вполне можно первое время делать вручную.
НДС, налог на прибыль и другие налоги – это вообще максимально регламентированная область. Да, тут мы зависим от того, какую информацию указали в первичных документах, но вот планирование производства, заказы на производство и т.д. на учет здесь никак не влияют.
Денежные средства. С точки зрения регламентированного учета это тоже достаточно самостоятельный блок. В оперативном контуре он обычно интегрируется с БДДС. Связующим звеном здесь являются заявки на расходование денежных средств. В принципе запустить данный раздел учета можно и без заявок, но мы обычно захватываем его на проектах сразу, потому что при минимальных трудозатратах с нашей стороны он запускается легко и дает предприятию реальную помощь в прогнозировании платежей.
Взаиморасчеты. Данный раздел учета более сложный. Он плотно связан с функциональностью оперативного контура, которую лучше прорабатывать сразу. Я имею в виду учет договоров, партнеров и контрагентов. Так что здесь желательно все-таки сразу понимать перспективы: насколько глубоко потом планируется внедрение в отделах продаж, закупок и т.д. При этом достаточно проработать именно указанную базовую НСИ, а вот сразу лезть в маркетинговые акции, скидки и CRM для запуска регламентированного учета нет необходимости. Более того, требования к детализации расчетов с контрагентами в любом случае будет определять именно бухгалтерия, потому что они напрямую влияют на зачеты авансов, и, как следствие, на НДС. При этом детализация взаиморасчетов «в целом по договору» и «по накладным» не требует участия смежных отделов, она вся базируется на существующей первичке. А вот если взаиморасчеты будут вестись по заказам, тогда да, у нас здесь появляется документ оперативного контура. Здесь на практике встречаются два варианта: либо сразу в этой части подключается отделы продаж и МТО, либо бухгалтерия сама вносит «фиктивные» заказы, которые нужны только для взаиморасчетов и к реальным заявкам никакого отношения не имеют.
Материалы, ТМЦ. Данный блок с точки зрения проработки архитектуры является самым сложным, потому что после начала ввода документов очень проблематично поменять, к примеру, виды номенклатуры, добавить использование серий или характеристик. То есть здесь на входе желательно знать ориентиры по будущей системе (учет по срокам годности, по серийным номерам и т.д.). К сожалению, не всегда это возможно. МТО может поначалу не идти на контакт. Ну, тогда мы обычно запускаем систему без оглядки на их возможные задачи, а уже позже, когда они подтянутся, начинаем думать, как повысить детализацию учета.
Напоследок обсудим блок управления затратами и расчет себестоимости. Есть такая иллюзия что затраты могут стартовать только вместе с полноценным производственным учетом. Что сначала надо отладить документооборот у мастеров, начальников цехов, а уже потом переходить к проводкам. Хочу возразить, что у меня на 1С:ERP работает несколько заводов, где до сих пор нет конструкторской документации в оцифрованном виде. Как следствие, нет спецификаций, нет автоматического формирования этапов и т.д. А учет затрат в программе запущен, и неплохо работает. Да, работает в упрощенном виде, да, нельзя отследить и проанализировать отклонения в себестоимости продукции, но для целей именно бухгалтерского учета предприятиям функционала вполне хватает. Еще раз обращу внимание, что никто не планирует на этом останавливаться, большинство заводов запустили проекты по внедрению PDM -систем, и когда-нибудь, когда они наконец-то оцифруют свои спецификации, мы пойдем там в производство. Но если бы мы сразу на входе ждали появления этой информации, то проект внедрения 1С:ERP нам пришлось бы отложить на несколько лет.
Подводя итог, хочу сказать, что запустить регламентированный учет отдельно от оперативного в 1С:ERP можно, а в некоторых случаях даже необходимо. На сложных проектах такие вот «кусочки» позволяют быстро запустить систему, получить отзыв, получить референс, получить кредит доверия от руководства предприятия. И уже с этим багажом двигаться дальше.
Подписывайтесь на наш YouTube-канал:
Запуск в 1С:ERP регламентированного учета без оперативного контура
