Достаточно часто на проектах автоматизации заказчик говорит, что хотел бы работать по этапам через заказы на производство, но это не всегда возможно, потому что есть направления производства, которые производят что-то сыпучее в больших объемах, и это идет постоянно – производство и обогащение песка, обогащение цемента, обогащение угля и так далее. Отражать такие виды производства через этапы – сомнительное занятие.
Но для того, чтобы поставить корректный учет по этим видам производства, необходимо доработать систему, чтобы она была понятна для всех – в том числе, чтобы в ней отражался технологический процесс в понятном для технологов виде.
Как выбрать и не допустить ошибку
Хочу обсудить преимущества и недостатки двух подходов к отражению операций: «Производство без заказа» и «Этапы производства» через «Заказы на производство».
-
«Производство без заказа» можно сравнить с простой и эффективной роборукой, которая выполняет свою задачу качественно и в нужном формате.
-
А «Этапы производства» представляют собой более сложный андроид, который требует значительных усилий для обучения, управления и доработки. Для некоторых типов производства этот вариант не подходит, поэтому не всегда стоит сосредотачиваться именно на нем.
На слайде перечислены достоинства и недостатки варианта отражения операций через «Заказ на производство». Достоинства я перечислять не буду, расскажу подробнее о недостатках.
-
Для производства и обработки (обогащения) сыпучих материалов, пункты достоинств 2, 3 и 4 являются недостатками, потому что нам будет тяжело организовать отражение такого производственного процесса в системе учета. Особенно, если мы его хотим отображать этапы производства посменно либо посуточно. В этом случае как такового «Заказа на производство» нет, нам не от чего отталкиваться – есть просто объем, который мы должны произвести и отгрузить по общему плану. Кому отгрузить – неважно. У нас просто идет процесс производства и отгрузки продукции.
-
Следующий недостаток – это сложность в управлении документами «Этап производства», их нужно постоянно переформировать для того, чтобы они отражали действительность.
-
И высокий уровень готовности НСИ. Заказы на производство, как правило, предполагают сборку из различных деталей и размещение готовой продукции на складе для конкретного клиента. В этом случае проработка НСИ, в частности, ресурсных спецификаций, очень важна. Но для некоторых типов производства ресурсная спецификация – это просто перечень материалов и трудозатрат, которые должны будут отобразиться в производственных документах, не более того.
Теперь о достоинствах и недостатках варианта отражения операций через «Производство без заказа». Его достоинства:
-
Документ «Производство без заказа» – это документ-конструктор. Он похож на «Отчет производства за смену» в УПП, но у него гораздо бОльшая функциональность.
-
Документ «Производство без заказа» отличается простотой в использовании и доработке. Несмотря на то, что в нем нет возможности указать рабочие центры и другие важные аспекты технологического процесса, необходимые для производственного учета, мы все это можем туда запросто добавить. При этом обновления на его доработках практически не скажутся, потому что функциональность документа «Производство без заказа» развивается с меньшей интенсивностью, чем этапы и заказы.
-
Документ «Производство без заказа» подходит для учета потокового производства – когда у нас идет производство цемента, обогащение угля, обогащение песка и так далее.
Недостатки:
-
Никаких отчетов по документу «Производство без заказа» нет, все придется писать с нуля. Этот документ никак нельзя проконтролировать, он просто отображает факт того, что уже случилось.
-
Для организации того учета, который вы хотите построить у себя на предприятии, документ «Производство без заказа» необходимо дорабатывать.
Внутри «Производства без заказа» мы дорабатывали:
-
учет материалов по влаге;
-
учет по рабочим центрам – выработка и простои;
-
учет дополнительных параметров, которые нам необходимы.
Причем это можно либо вносить вручную, либо рассчитывать, исходя из каких-то данных, либо получать со SCADA-систем.
Кейс №1. Учет производства с датчиками. Интеграция с системами SCADA
Если мы хотим построить учет производственных процессов через SCADA, то нам в случае со строительными материалами или с тем же самым углем идеально может подойти сбор данных со SCADA и загрузка их в ПБЗ.
Но есть ряд нюансов, которые важно учитывать для успешного запуска системы.
В первую очередь стоит проанализировать возможности датчиков – что они вам могут показать, и будут ли они вам врать. Предположим, у нас есть емкость с установленным датчиком для определения объема наполнения. Если в емкости что-то пыльное или сыпучее, датчик будет врать – в этом случае получать эту информацию с датчика объема не актуально, заполнение емкости все равно будет фиксироваться через отвесы.
Мы можем получить количество выпущенной продукции или полуфабрикатов расчетным путем. Условно, мы добыли в карьере песок, но сколько экскаваторы нагрузили этого песка – мы не знаем. С помощью датчиков мы можем определить, сколько песка у нас пришло на комбинат уже обогащенного, и от обратного расчетным путем получить выработку экскаваторов – выпуск именно предыдущего этапа.
Это как раз одна из причин, почему мы не можем использовать документы «Этап производства» – у нас само производство строится таким образом, что необходимо выпуски фиксировать от обратного: от потребления либо от отгрузки.
Мы можем фиксировать в ПБЗ простои рабочих центров – получить данные по времени работы оборудования с датчиков и рассчитать простой, вычитая полученное время из 24 часов. Нам нужно будет только указать в документе, к какому типу простоя это относится. Правда, без небольшой адаптации здесь не обойтись, но через «Заказ на производство» это будет реализовать сложнее.
Кроме этого, мы можем фиксировать параметры конкретных рабочих центров – простой по энергетической части, коэффициент простоя по ТОИР, коэффициент выработки и так далее. Анализ этих параметров позволит принимать решения на производстве – оптимизировать производственный процесс или определить необходимость ремонта оборудования.
При интеграции с системами SCADA необходимо делать загрузчики универсальными – мы должны иметь возможность управлять правилами получения данных в пользовательском режиме, потому что параметры самих технико-экономических показателей меняются.
Кроме этого, у нас должна быть возможность проверки корректности полученных данных в виде отчета с контрольными суммами. Мы должны быть уверены, что датчики, с которых мы снимаем показатели, не дают большой погрешности, и им можно доверять. Это важно, потому что документ «Производство без заказа» сразу отражает информацию в бухгалтерском учете.
Итог по интеграции с системами SCADA – автоматизируем все с умом.
-
Не стоит заморачиваться с получением данных из SCADA всего и вся – все зафиксировать в системе мы все равно не сможем.
-
Датчики очень часто врут, поэтому какие-то показатели мы все равно должны рассчитывать.
-
Для загруженных данных важно контролировать корректность – для этого можно использовать различные методики: многоуровневую проверку остатков, отчеты по материальному балансу выпуска с передела и т.д.
Кейс № 2. «Книжный учет» – производство с рассчитываемыми данными
Следующий кейс – это учет производственных процессов через «книжный учет».
«Книжный учет» – это учет, построенный на нормативах, исходя из измеряемых показателей, снимаемых в процессе производства. Когда на предприятии нет физической возможности получать данные с датчиков, но информацию о процессе производства необходимо все-таки как-то завести в систему.
Проблема «книжного учета» в том, что он практически везде строится на методиках, разработанных еще во советские времена. И современной литературы, позволяющей адаптировать эти методики под автоматизированные системы, не существует. Поэтому полученные данные обычно сначала обрабатывают в Excel.
Например, методика «книжного учета» позволяет рассчитать расход материалов с учетом объема выпуска, влажности сырья и необходимого количества сухого вещества. И под эту задачу мы как раз можем адаптировать документ «Производство без заказа» – вносить эти данные в систему.
Но при этом показатели расчета в зависимости от различных факторов будут постоянно меняться – а это значит, что нормативы по спецификациям нам не подойдут.
В большинстве случаев в книжном учете выпуск продукции определяется на основе или потребления – мы определяем фактический объем выпуска, сравнивая изменение остатков в силосах с объемом отправленной продукции. Снимаем остатки отвесом либо фиксируем изменение остатков продукции по отрезкам внутри емкости, учитывая объем каждой емкости.
Чтобы мы могли оперативно отреагировать, когда формулы «книжного учета» дают сбой, необходимо организовать контроль корректности введенной информации. Для этого можно использовать несколько видов отчетов.
-
Отчеты по материальному балансу. Основная проблема контроля материального баланса, которую я встречал в процессе автоматизации «книжного учета» – это то, что сама методика рассчитана на учет расхода в целочисленных значениях при том, что отгрузка всегда указывается с точностью до сотых. Здесь придется либо подстраиваться под процессы округления и учитывать их в отчетах и документах выпуска продукции, либо все-таки пытаться переубедить заказчика, что указывать расход с запятыми – это нормально.
-
Сводка для технологов – отчет для управления процессом производства, который мы можем получить по данным документа «Производство без заказа». Он показывает расход материалов, объем выпущенной продукции или полуфабрикатов, а также информацию о простоях рабочих центров и их причины.
-
Акт инвентаризации – финальный отчет, который отображает, насколько расходятся данные «книжного учета» с реальными остатками. Маркшейдеры в конце месяца проводят замеры, и далее комиссия принимает решение, что с этим делать – изменять остаток в учете или оставлять все как есть. Стоит учитывать, что корректировать данные в системе для любых отклонений нецелесообразно – они будут всегда, потому что учет ведется вместе с влагой, и добиться нуля при разнице натурального и книжного учета практически невозможно.
Итоги по книжному учету:
-
Автоматизируйте, но с умом. Обязательно разработайте отчеты для контроля соблюдения материального баланса – чтобы можно было оперативно выявлять расхождения, учитывать как влажное сырье, так и сухое, видеть баланс между выпуском и расходом.
-
Все расчеты должны опираться на количество именно сухого вещества, а не сырого – без учета влажности точные вычисления вообще невозможны, все формулы в существующих советских методичках рассчитаны на использование сухого вещества.
-
Учитывайте параметры производства – без их ввода в формулы системе также не будет неработоспособна. Вы просто будете отражать какой-то факт и ничего интересного оттуда получить не сможете.
-
Огромная проблема при проверке корректности учета – это округление. Лучше всего – отучить технологов и производство от контроля только целочисленных значений и перейти на запятые. Такая проблема достаточно часто встречается, во всяком случае, у меня в проектах она была частой.
-
Разработайте отчеты для контроля результатов работы: как отработали рабочие центры, как отработали смены и так далее.
Что еще можно автоматизировать с помощью ПБЗ
С помощью «Производства без заказа» (ПБЗ) можно реализовать еще несколько полезных функций:
-
Выпускать и распределять энергоресурсы между подразделениями.
-
Выпускать внутренние услуги для их дальнейшего учета и распределения на затраты конкретных подразделений.
-
И выпускать сдельные работы. Например, если в процессе производства продукт находится печи в течение нескольких дней, но зарплату нужно начислять своевременно, это тоже можно решить через ПБЗ – без перехода на поэтапное отражение производства. Но без доработок здесь, скорее всего, не обойтись.
Вопросы и ответы
Чем принципиально отличается учет через «Заказ на производство» от учета через документ «Производство без заказа»?
Отличается в сложности учета. Для отражения выпуска через «Заказы на производство» требуется глубокая проработка нормативно-справочной информации. В этом варианте невозможно организовать некоторые процессы учета – например, если необходимо отразить выпуск по результатам отгрузки. Вы не можете переставить операции выпуска и отгрузки местами – сначала нужно обязательно что-то добыть, а потом это добытое уже обогатить.
А «Производство без заказа» применятся на таких типах производства, где производством управляет не учетная система ERP, а SCADA или другие системы, которые помогают это организовать. В учетной системе вы должны отразить факт и этот факт контролировать, если вам это интересно. Но бывают такие случаи, когда это просто можно отразить в конце месяца и не париться.
Можно ли в документе «Производство без заказа» учитывать переделы?
Вполне возможно. Например, сейчас мы автоматизируем многопередельное производство, где есть передел приготовления моношихты, за которым следует передел обжига.
Так вот этот передел обжига длится в течение пяти дней, и при его расчете нужно учитывать сдельные наряды. Для этого я переработал функциональность ПБЗ так, чтобы трудозатраты писались в мой регистр – на основании этого ПБЗ я создаю еще один ПБЗ, который отражает сдельную заработную плату для выработки. И дальше идут следующие переделы: разборка, сортировка, помол и рассев – их тоже можно фиксировать.
Вопрос в другом: если учитывать переделы через «Этапы производства», то чем именно там управлять? Приготовление моношихты идет по конвейеру, материал просто насыпается туда. Что именно контролировать в этом случае с помощью этапов – непонятно. Поэтому для нас «Производство без заказа» оказалось более удобным решением.
Еще один пример работ со сдельной оплатой – монтаж. Допустим, предприятие выпускает промышленное оборудование. После выпуска продукции она отправляется на склад в виде готовых сборочных единиц. А когда площадка под оборудование у клиента готова, выезжает монтажная бригада, устанавливает продукцию, расходует трудозатраты и небольшое количество материалов. В этом случае ПБЗ отлично подходит, поскольку нет фиксированной спецификации – есть определенные комплектующие со склада и четкие затраты труда, которые можно зафиксировать в системе.
И таких примеров много. Например, в типовом «Управлении автотранспортом» отражение затрат идет через документ «Прочие расходы», но их можно переделать на ПБЗ – выпускать часы работы техники. В этом случае вы фиксируете только количество отработанного времени, без учета сумм. Это делает управление процессом проще и нагляднее.
Я так понял, что в вашем кейсе как такового производственного планирования не требовалось. Вам не требовалось формировать сменно-суточные задания, вы просто настраивали отражение факта, в том числе с датчиков.
При производстве цемента, обогащении песка, обогащении угля планирование ведется иначе – там не требуется формировать сменно-суточные задания.
Были ли у вас кейсы, где факт отражался через «Производство без заказа», а с точки зрения оперативного планирования использовался другой инструмент, не «Заказ на производство»?
Да, у меня сейчас есть такой кейс. Мы в дополнение к документу «Производству без заказа» сделали доработку – простенький документ «Сменно-суточное задание», чтобы люди просто понимали, какую моношихту им нужно приготовить, в какую печь им нужно направить ячейку для обжига, и какую печь им необходимо передать на охлаждение.
Вы в докладе рассматривали варианты применения документа ПБЗ для непрерывного производства, а есть ли примеры его использования на штучных производствах? Например, можно ли использовать ПБЗ для того же ТОИР, когда много оборудования на заводе? Сейчас мы учитываем это через «Заказ на ремонт», к которому привязываем «Заказ на производство» и далее через «Этапы» отражаем потребление материалов и выработку. Можно ли упростить учет и управление этими заказами через ПБЗ?
Можно, но зачем? Есть «Заказ на производство», там плюс-минус все готово.
У меня тоже сейчас есть проект, в котором клиент не может определиться. У него производство всю жизнь все отражало в УПП через «Отчеты производства за смену», и когда мы сейчас их заставляем перейти на заказы, они к такому контролю оказались не готовы.
Здесь, мне кажется, нужно подходить с другой стороны.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.