valerysemenov

 Производство – это такая область деятельности, которая может оказаться "черной дырой", если не наладить жесткий контроль использования сырья.

Почему так? Если в торговле чаще всего материальный вход бизнес-процесса = выход бизнес-процесса (что купил то и отгрузил) и равенство легче поддается контролю, то в производстве вход и выход отличаются по составу.

Часть сырья или продукции ("неучтенный выпуск") будет уходить в эту "черную дыру", отяжеляя карманы нечистоплотных менеджеров. Мудрят с нормами расхода, заменами, пересортицей, отходами, браком и т.д. – приемы известны, и здесь перечислять их не будем.

У одного из наших клиентов месячные потери сырья составляли 5-8% (!) от оборота.

Казалось бы, что проще – внедрить автоматизированную систему, определить жесткие нормативы расхода, контролировать вход сырья на производстве, выход продукции и НЗП. Выявлять отклонения потребления от норм и спрашивать с виновных.

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

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

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

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

Равенство веса входа и выхода в производстве принято называть материальным или весовым балансом. Заказчик покупает типовое решение в полной уверенности, что получит материальный баланс. Потому что в типовом решении «Все есть для производства». Все ли?

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

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



Вывод.

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

Как известно, в MRP-методологии есть ключевое понятие "Номенклатура". Используется оно для классификации товаров, сырья, продукции, услуг. Казалось бы, справочник номенклатуры – этот тот же велосипед, и изобретать тут нечего.

На одном из проектов в конце 90-х при внедрении типового решения возникла следующая проблема. Предприятие производит обувь 1000 наименований, 20 размеров. Итого получается 1000х20=20000 номенклатурных позиций в справочнике.

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

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

Ознакомившись с результатами тестового прогона, Заказчик остался удовлетворен. Интерфейс ввода практически не изменился, по сравнению со старой системой.

На опытной эксплуатации выяснились особенности, которым поначалу не придали значения.
Если нужного размера для выбранного наименования в справочнике не оказывалось – этот размер приходилось добавлять в справочник заново. Пользователи недоумевали – зачем такие сложности, зачем например, вводить 39-й размер каждый раз заново для каждого наименования обуви? В старой программе справочник размеров был введен один раз при начале работы системы, и его не нужно было пополнять каждый раз, когда создавалась новая модель обуви.
Зачем при вводе нового размера для каждого наименования номенклатуры нужно еще указывать дополнительно для этого размера из особого справочника свойств, что это действительно 39-й размер? Ведь это двойной ввод данных!
Анализ справочника размеров показал, что в нем те же самые 20000 записей. Плюс тысяча записей в справочнике Номенклатуры. За корректностью данных в этих 20000 записей должен был ктото следить. Ведь у каждой записи должна быть настройка – к какому размеру из справочника свойств она относится!
В старой системе справочник размеров состоял из 13 позиций, и его не нужно было постоянно пополнять и контролировать. Старая система была простой и удобной, новая – громоздкой, требовала дополнительного администрирования. Хотя решала ту же самую, простейшую задачу составления позиции документа из двух позиций – номенклатуры и размера.

В чем причина? Это плата за универсальность и типовой подход? Нет. Это плата за методологию построения НСИ. Очевидное и эффективное решение в таком случае – два независимых справочника:
Номенклатура (1000 позиций);
Характеристики номенклатуры (исполнения номенклатуры) (13 позиций).

Вывод

Типовое решение должно поддерживать возможность составления номенклатурной позиции их двух независимых частей – номенклатуры и ее характеристики (исполнения). Эта независимость позволяет на несколько порядков сократить количество записей в справочнике характеристик и упростить работ у пользователей.

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

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

…на предприятии Х было внедрено типовое решение – автоматизирован бухгалтерский учет.

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

Например, с лодки снимали весла и устанавливали мотор. Из мотора и лодки с веслами получались отдельно весла и лодка с мотором.

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

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

Причем, себестоимость мотора должна полностью попасть в лодку с мотором, а себестоимость лодки с веслами должна разделиться – 5% уходит на весла и 95% уходит на ту же лодку с мотором. Да еще в себестоимость лодки с мотором нужно добавить зарплату работника, который занимался перекомплектацией, так как один из кладовщиков стал почти в течение целого дня заниматься этой работой.

Как выкрутились?

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

Система отрабатывала все правильно, если одно и то же изделие не проходило несколько перекомплектаций за месяц. Если же это происходило бухгалтерия методом "пляски с бубном" кое-как сводила результат ручными проводками после закрытия месяца и больше этот месяц не перезакрывали, чтобы не разрушить данные этих ручных проводок.

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

Сырье на складе наливается в чаны, и к этому сырью подмешиваются (там же, на складе) некие компоненты, в результате чего себестоимость сырья и объем возрастает за счет этих компонент. Иначе говоря, одна номенклатура списывается на другую номенклатуру. Себестоимость списанной номенклатуры увеличивает себестоимость номенклатуры – получателя.

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

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

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

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

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

Вывод

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


по  материалам http://www.semjonov.ru/projecthistory/size-reference.html

Еще на заре развития 1С был начат крупный проект на производственном предприятии. Первый этап – автоматизация учета материалов в стоимостном и количественном выражении. Есть несколько складов материалов, нужно отразить приход и расход на основе первичных документов. При расходе материалов программа рассчитывает себестоимость этого расхода по «средней скользящей цене». Другое название этого метода – средняя мгновенная себестоимость.

Объем операций – до тысячи документов в день. Номенклатура – десятки тысяч.

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

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

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

Руководство недоумевало – почему система требовательна к последовательности?

Ведь если за месяц пришло 10 шт, на 1000 руб (100 руб/штука), а израсходовали 2 шт в этом же месяце, то очевидно, что стоимость расхода 200 руб. О каких последовательностях можно говорить? Почему нельзя это посчитать – ведь для расчета есть все исходные данные!

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

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

И он был прав.

Методика была изменена. Пришлось доработать типовое решение и снять его с сопровождения. Теперь последовательность ввода для расчета себестоимости расхода не имела значения. Использован был метод средневзвешенной себестоимости. Все документы прихода за месяц рассматривались в совокупности, и определялось общее количество прихода и расхода. Согласно общему итоговому количеству расхода в целом за месяц, определялась стоимость израсходованных материалов за этот период.

Последствия – теперь себестоимость расхода рассчитывалась не в самом документе, а в отдельной регламентной процедуре «Закрытие месяца», которая определяла совокупный приход и расход за месяц по всем документам и на основании этих данных считала материальные затраты.

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

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

Решение, требовательное к последовательности ввода, имеет еще один недостаток.

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

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

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

Документов ТМЦ может быть очень много, например, десятки тысяч. Один документ проводится 2-3 секунды. Полное перепроведение занимает часы, в это время база перегружена транзакциями, и у других пользователей программа подвисает.

Хорошо, если полное перепроведение документов организационно можно делать ночью.

У одного из наших клиентов перепроведение документов занимает 6 часов, а закрытие месяца после перепроведение – полчаса. Каждая правка ошибки по ТМЦ в прошедшем месяце требует запуска перепроведения на 6 часов и только потом – перезакрытия месяца.

В результате того, что ошибки приходится править достаточно часто – бухгалтерия не успевает сдавать отчетность, т.к. перепроведение происходит ночью, соответственно, за месяц можно сделать только 30 раз закрытие месяца. Куда уж там говорить о закрытии месяца на 2-е число следующего…

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

Только уже из-за этого (о других проблемах умолчим) клиент начал проект по переходу на более совершенное типовое решение. Куда же он смотрел при выборе типового решения?

Как это ни удивительно, но подавляющее количество высокотиражных типовых решений по-прежнему основано на этой методе последовательностей.



Вывод.

Типовое решение для крупного предприятия должно быть нетребовательно к последовательности ввода документов ТМЦ. Контроль текущего остатка при вводе документа расхода полезен, но он полезен на уровне оперативного учета, при учете в реальном режиме времени.

Неразумно переносить требования, предъявляемые к системам учета в режиме реального времени (он-лайн) на системы, по определению не ведущих такой учет (бухгалтерия, которая ведет учет офф-лайн). Особенно, если оперативный учет на данном этапе внедрения вообще не нужен.

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

http://www.semjonov.ru/projecthistory/sequence.html

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

Замечательно, если эти две функции удается совместить. Такой учет называется «Бухгалтерский управленческий учет«. Это бухгалтерский учет, который достаточно:

• ­достоверен (точно отражает реально совершившиеся события);
• оперативен и ­ детален для того, чтобы на его основе можно было принимать управленческие решения.

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

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

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

Еще одна причина – т.н. «черный учет». Не все операции отражаются в бухгалтерии, не все бухгалтерские операции реально имели место. Бухгалтерия рисует отчетность, предприятие живет своей жизнью…

Самая экзотическая причина (до настоящего времени) – правила бухгалтерского учета противоречат методике управленческого учета. Например, требуется вести управленческий учет по стандартам МСФО.

Читать далее www.semjonov.ru/projecthistory/management-balance/

На конкурентном рынке многое (если не всё), определяет, как поставлена работа с клиентами.

Особенно это важно, если предприятие работает с долговременными поставщиками, а процедура приемки и согласования заказа многоэтапная вследствие проектного характера работы предприятия. Заказ нужно утверждать, согласовывать параметры продукции, согласовывать с ПЭО цену, с технологами возможность его исполнения в сроки и т.д.

Пример – производство лифтов.

Предприятие может выпускать, например, всего две номенклатуры лифтов. Но в каждом заказе лифт конкретизируется специальными параметрами – количество этажей, наличие золотой ручки, высота зеркала в лифте и т.д. Всего мы насчитали около 50 параметров. Из-­за произвольных сочетаний множества этих параметров каждый лифт уникален.

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

Что характерно для таких производств?

1. Сложность приемки заказа. Ведь менеджеру продаж надо согласовать параметры, как с заказчиком, так и с собственным производством и экономистами (рассчитать отпускную цену, поскольку себестоимость заказного лифта уникальна).
2. Как следствие – пытка клиента волокитой и временем ожидания на утрясание его проекта. Четкость и скорость обработки заказа для такого предприятия становится серьезным конкурентным преимуществом. Если, конечно, покупатели не «одноразовые».

Предприятие Х по производству лифтов обратилось к консультантам с просьбой автоматизировать приемку заказа. На этом предприятии заказ обрабатывался 2 недели, а у конкурента – всего два дня.

Наблюдался постепенный отток постоянных клиентов к конкуренту.

Консультанты начали обследование предприятия X.
------
(полностью читайте http://www.semjonov.ru/projecthistory/torture-as-customer/)

 Онлайн-семинар "Интернет-реклама по-взрослому"
http://internetsales.pro/seminar2.html

Не секрет, что после переноса данных из конфигурации «1С:Бухгалтерия предприятия 1.6» в «1С:Бухгалтерия предприятия 2.0» возможно появление расхождений в остатках исходной и целевой баз данных. Причин для этого явления несколько и одна из них – некорректные данные в исходной БД. 

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

Подробнее >>

 Скачай 5 бесплатных лекций по бизнесу от Андрея Парабеллума на сайте infobusiness2.ru: http://infobusiness2.ru/BizDev2-Bonus

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

http://rmeit.ru/node/526 

В очередной раз энтузиасты известного ресурса infobusiness2.ru проводят очередной флэшмоб FM7 "7 инструментов продаж" http://infobusiness2.ru/FM7