Обновление №7 для VOGBIT v.1.1.37841 - В производственном модуле внесен ряд изменений, направленных на упрощение работы с программой на «максимальном» уровне. В том числе: изменён порядок вывода на экран информации о количестве (запланированных/сданных деталей) – стало более наглядно и удобно

Последние темы на форумах VOGBIT

Расчёт комплектации - Прочее
Константин Чилингаров: рис.
Заявки на закупку - Новые возможности
Lexam: Для изготовления деталей на стороне создаем заявку на закупку. Соответственно, нужно выгрузить файлы из закупаемых позиций. Из закупки доступа к файлам нет вообще, также нельзя открыть позицию в номенклатуре. Предлагаю добавить в окно заявки на ...
Подключение к базе данных через API - Плагины
Сергей: [CODE var app = new Application(); app.Login(server, database, login, password);[/CODE
Максимальный уровень учета - Состав и технология
Константин Чилингаров: Здравствуйте, Да. Всё так и должно быть. При использовании, так называемого, метода "по комплектам" (настройка по умолчанию для производства строительных МК) использование "максимального" уровня для заданий, объединяющих в себ ...
Отображение кол-ва дней в графике загрузки по умолчанию - Прочее
Константин Чилингаров: Здравствуйте, Пётр, спасибо! Всё верно вы написали.
Невозможно запустить приложение в связи с недействительными данными активации - Активация, Деактивация, Лицензии
Елена Ковалева: Добрый день! Ответила на почту.
Комплект сборочных единиц - Производство
Алексей Пономарев: Здравствуйте, напоминаю про зависший вопрос.
Добавление колонки "Комментарий" - Интерфейс программы
Константин Чилингаров: Здравствуйте, Можно.  Запишу.
Движение материалов - Прочее
Константин Чилингаров: Здравствуйте, 18377 Saw-x написал: Я так понимаю что я не один в своих хотелках. Если брать точно такую постановку вопроса, то один. Хотелок много, но у всех разные. 18377 Saw-x написал: Потребность не только у меня, что бы программа все сама ...
Заявка покупателя - Прочее
Константин Чилингаров: Последнее сообщение /forum/messages/forum27/topic2401/message14962/2401#message14962 перенесено . /forum/messages/forum27/topic2401/message14962/2401-dvizhenie-materialov#message14962 Причина: несоответствие заявленной в заголовке теме (/forum/foru ...
невозможность редактирования - Состав и технология
Константин Чилингаров: Здравствуйте, Ну отредактировать то просто... Открываешь окно "Состав" (карту заказа) и редактируешь. Другое дело, что если задания уже сформированы, то в этих уже созданных заданиях то автоматом ничего не поменяется. Какое было количество ...
Формирование обозначений в генераторе - Состав и технология
Константин Чилингаров: Здравствуйте, Нужно к номенклатуре - шаблону добавить параметр "Шаблон обозначения" (идентификатор VGB_Notation_Mask). Это строковый параметр. В значение ему пишем строку-шаблон обозначения. В нужные места подставляем в квадратных скобк ...
Занесение на склад Вогбита - Плагины
Сергей: 18506 Bagrov40k написал: как вообще подключить модуль Csdn.Vogbit.Data корректно Подключить где\куда? Если речь про .net и студию, то Project -> Add Reference... Вообще, как обычную библиотеку. 
Возврат в окно - Интерфейс программы
Константин Чилингаров: Спасибо, Мы тоже уже выявили этот недостаток. Будем работать над устранением.
Vogbit & 1C - Экспорт импорт данных
Константин Чилингаров: Здравствуйте, Технически можно, в принципе, всё что угодно реализовать. Ну или почти всё. Путём написания соответствующих плагинов или служб, которые будут это делать. Считывать данные из указанного места, записывать туда, куда у них в коде написа ...
Отслеживание результатов выполнения работ на участках - Производство
Константин Чилингаров: Здравствуйте, 18511 Rudakov77 написал: Есть ли возможность формирования Оперативного плана производства для наглядного отслеживания выполнения Заданий на смену производственными участками? Да есть. В разных вариантах. Просто внешне в другом неско ...
Проблема со справочником "Номенклатура" - Общие вопросы
Елена Ковалева: Так же, я заметила, что в меню отсутствует кнопка "Выбрать категорию". По умолчанию используется категория "Основная", но это не обязательно. Для выбора категорий нужно "достать" кнопку. 1. На синем поле вызвать контекс ...
SolidWorks и Vogbit - Экспорт импорт данных
Константин Чилингаров: Здравствуйте, Штатной кнопки "импорт" нет встроенной. Поставляется дополнительно, как услуга. Плагин + настройка его, если нужно + консультации. От 15 т.р. и выше в зависимости от сложности. Потому что те же xml - они же все разные по соде ...
Обновление апрель 2019 - Обновление
Mariska17-17: Спасибо. Помогло!
Отсутствует операция в графике производства - Производство
Zms.komissarov: Спасибо!

Отслеживание результатов выполнения работ на участках

Всё, что связано с производством и вопросами применения программы в производстве - Производство - Работа с программой
Страницы: 1
Отслеживание результатов выполнения работ на участках
 
Считаю, что для получения сжатой и конкретной информации о выполнении производственных задач на предприятиях по выпуску металлоконструкций необходим отчет работы участков за период.
Форма отчета прилагается.
Прошу представителей ЗМК высказаться по этому поводу.
Необходимость, форма отчета, алгоритм его создания.
 
Цитата
Ростислав Осипов пишет:
Считаю, что для получения сжатой и конкретной информации о выполнении производственных задач на предприятиях по выпуску металлоконструкций необходим отчет работы участков за период.

Форма отчета прилагается.

Прошу представителей ЗМК высказаться по этому поводу.

Необходимость, форма отчета, алгоритм его создания.

Эта информация есть в графике производства. Нужна только при сдельной оплате стропальщиков и крановщиков.
Изменено: Дмитрий Гриншпон - 31.08.2018 13:58:14
 
Ну, да, вроде и вес складывается корректно даже на заготовке. Т.е. вес марки один раз считается.
Есть нюанс:
У нас некоторые конструкции в состоянии "Завершено", это когда часть большой партии отмечается, как принятые, задание завершается, а остаток переноситься на следующую смену.
Тогда не столь наглядно выходит
11.png (96.91 КБ)
Изменено: Ростислав Осипов - 02.09.2018 17:40:50
 
Цитата
Ростислав Осипов пишет:
Ну, да, вроде и вес складывается корректно даже на заготовке. Т.е. вес марки один раз считается.
Есть нюанс:
У нас некоторые конструкции в состоянии "Завершено", это когда часть большой партии отмечается, как принятые, задание завершается, а остаток переноситься на следующую смену.
Тогда не столь наглядно выходит

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

Просто в окошке "Производственные заказы" выделить так не получится. Т.к. там либо список "текущие", либо "выполненные".

Но можно выделить нужные карты заказов в справочнике "коллекции компонентов" (подробнее здесь). И нажать "График производства".
Так можно открыть "График производства" на любом наборе заказов, не важно закончились они уже, или нет.
Там же можно, кстати, и разложить карты заказов по папкам любым нужным образом, если хочется. Чтобы удобнее было искать, выделять и т.п.
 
Цитата
Константин Чилингаров пишет:
Там же можно, кстати, и разложить карты заказов по папкам любым нужным образом, если хочется. Чтобы удобнее было искать, выделять и т.п.
А можно в следедующем обновлении добавить наследование подраздела при делении на разные детали. К примеру я положил в одну папку отправочную марку, потом нач цеха решил разделить на несколько позиций. Нужно чтобы подраздел у созданных марок был тот-же что у оригинала.

И сделать как-то чтобы если была ранее нажата кнопка показать подразделы, при новом открытии показывались подразделы, чтобы не сбрасывалась при закрытии окна графика производства.
Изменено: Клим Серебренников - 06.09.2018 11:15:28
 
Складывать при "разделении партии" вновь созданные позиции в ту же папку, где была исходная - не сказать, что абсолютно, на 100%, логично, но своя логика в этом, безусловно, есть. И каких-то противоречий или технических трудностей не вижу. Можно и сделать будет, в принципе.

С папками при открытии окна - там сложнее несколько вопрос. Например, в момент следующего открытия окна те папки, которые были в момент закрытия окна в предыдущий раз, могут уже не существовать. И т.п.
Ну я в любом случае пожелание записал. Когда до него очередь дойдёт, обсудим с коллегами.
 
Цитата
Дмитрий Гриншпон пишет:
Цитата
Ростислав Осипов пишет:

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



Форма отчета прилагается.



Прошу представителей ЗМК высказаться по этому поводу.



Необходимость, форма отчета, алгоритм его создания.



Эта информация есть в графике производства.

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

Я думаю нужно именно разрабатывать отчет с статистики производства по дате выполнения.
 
И вот тут мы плавно подошли к вопросу, с которого, собственно, всё и началось. Ещё за пределами форума, до того, как эта тема здесь появилась.
Цитата
Клим Серебренников пишет:
атрибут дата запуска относится не к операции, а к изделию в целом.
Это, в общем, было понятно с самого начала.
Вопрос в том, как смотреть на этот «отчёт» из «Графика производства». Что это? Инструмент для оценки? Чтобы примерно посмотреть и прикинуть?
Если так, то и не важно. Плюс-минус примерно правильно общую картину и так показывает, понять можно.

Или вы хотите, чтобы это был инструмент, который абсолютно точно показывает цифры?
Вот тогда начинаются интересные вопросы…

Цитата
Клим Серебренников пишет:
Я думаю нужно именно разрабатывать отчет с статистики производства по дате выполнения
Ок. Давайте разберём подробно эту идею.

Начнём с общих вещей.
Вообще сама идея мерить работу отдельных участков тоннами достаточно спорная.
Есть, например, некая марка. Весит 1 тонну. Но на одном участке работ, относящихся к её изготовлению на пол часа, а на другом на 2 дня. А по отчёту такому получится, что один участок сделал 1 тонну, что другой – ту же 1 тонну.
Другой момент, что может марка весить, условно, 1 тонну, но при этом быть простейшей конструкции и состоять из 5 деталей, а может весить ту же условную 1 тонну, но состоять из кучи деталей и быть очень сложной конструкции. Первую делать легко и быстро, стоит она немного, вторую долго и сложно, стоит дорого. По отчёту опять же никакой разницы между ними нет.

В этом плане намного более объективным показателем были бы не тонны, а деньги. Но деньги в данном случае, если разобраться, по смыслу это те же нормо-часы. Есть некая марка, которую предприятие продаёт за определённую сумму. Т.е. все задействованные подразделения (участки) генерируют эту добавленную стоимость. Каждый свою часть. А в какой пропорции эта стоимость распределяется между участками, её создающими? Самый логичный способ деления – пропорционально объёму работ, выполняемых каждым участком. Есть заранее оговоренная цена, которая пропорциональна общим трудозатратам (= нормировка от веса и кол-ва деталей). Есть определённое распределение этой создаваемой ценности по участкам (= нормативное кол-во нормо-часов, которое закрывается при выполнении заданий участком). Если всё сделано по марке в выбранный период, то понятно вся стоимость попала в отчёт. Если часть только работ выполненных попала в выбранный период, то какая часть от стоимости попадает в отчёт? Логично та, которая от общей попала в выбранный период. То есть получаем в итоге тот же самый «сводный отчёт по участкам» за период в нормо-часах. А он и так есть!

Это было вступление-отступление. А теперь переходим, собственно, к вопросу:
Итак, ладно. Если отставляем вышеизложенные размышления.
Вы хотите получить таки отчёт по участкам, в тоннах и за период. Причём точный.
Ключевое слово тут ЗА ПЕРИОД.
Ибо, если к примеру, не за период, а просто по заказу, то тут то всё понятно. Все операции сделал участок, вес соответствующей марки включаем в отчёт. Не все сделал – не включаем.
Осмысленность и нужность отчёта именно по участкам в тоннах не рассматриваем, но по крайней мере понятно по какому принципу его строить.
Если же мы говорим «за период» то тут же наступаем на ситуацию, когда не все операции, выполняемые на участке, в границы выбранного периода попали.
То есть, строя отчёт, недостаточно взять просто выполненные на участке работы за период. Надо ещё по каждой из них отдельно(!) смотреть, а нет ли случайно где-то за границами этого периода работы какой-то, которая относится к той же марке и тому же участку? А она, такая работа, выполнена или нет, если она существует? А если выполнена, то она была выполнена до того, как указанный период начался, или после того, как он закончился? Ибо если до, то надо вес этой марки включать в отчёт, а если после, то не надо.
Теперь добавим к этому, что само определения «даты выполнения» этой «скрытой за границами периода» работы тоже не самое простое мероприятие. Потому что бывают, например всякие третьи смены, когда формально задание выполнялось после 00:00 то есть уже 01 числа, а относится оно по отчёту к 31 числу, потому что это, вроде как, 3-я смена 31-ого числа.
Я не говорю, что это невозможно всё учесть.
Возможно.
Но если это делать на уровне отчёта, то логика, как видите, будет весьма зубодробительная. Мало того, что её засунуть надо сначала в отчёт, потом проверять, как это работает всё – очень неординарное занятие…

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

Рассматривалась идея выделить на каждом участке некий «финишный пост». Если на нём задание выполнено, значит участок «закончил» и передал дальше. Но не вышло. Очень быстро нашли случаи, когда эта идея не работает.

Поэтому, так или иначе, если отталкиваться от «передачи» продукции с участка на участок, придётся именно этот факт передачи в программу вносить.

Казалось бы есть модуль "Склад". Одна из его функций, как раз фиксировать "движение" чего либо. Что оно было в неком подразделении "А" а потом из него ушло.

Я в своё время делал что-то подобное (не в VOGBIT ещё, в предыдущей программе) на основе "склада" для случая больших машиностроительных заводов с кучей цехов.
Идея там была такая. В каждом цехе есть склад свой. Цеховой. И детали после обработки сдаются на склад цеха всегда. Потом они по накладной передаются в следующий цех, где опять же попадают на склад. Со склада уже по требованиям выдаются рабочим и т их обрабатывают согласно техпроцессу. И после обработки опять сдают на склад своего цеха. Откуда по накладной они отправляются дальше. И т.д.
И в программе ровно так это и было реализовано. После выполнения работ, помимо отметки о закрытии задания нажималась кнопка сдачи на склад. Формировалась накладная, на складе цеха изделия приходовались. Оказывались на остатках склада цеха. Потом проводилось «перемещение» (учетная операция и, соответственно, электронный документ в программе) на склад следующего по маршруту цеха.  То есть из первого цеха со склада уходили эти детали, появлялись во втором в остатках склада. Потом оформлялся ордер (ещё одна учетная операция и, соответственно, электронный документ в программе) о выдаче со склада цеха работнику, который взял в обработку детали. Потом после обработки опять они сдавались на склад цеха и т.д.

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

Да, в этом случае нет потом вообще никаких проблем отследить по базе все перемещения за период и построить по ним какой-нибудь отчёт. Это пожалуйста. Кто когда что кому передавал – всё есть.
Правда другие проблемы и вопросы начинаются тут же, если вспомнить об отчёте по участкам в тоннах. Например, что делать с «петлями», когда маршрут типа «участок 1» -> «участок 2» -> «участок 1» -> «участок 2» -> «участок 3». И т.п.

Но самое главное даже не в этом.
А в том, кто будет эти все промежуточные сдачи на склад и передачи отмечать в программе? Тем более у вас, когда ни складов этих на каждом участке нет, ни кладовщиков?

Кроме того, если даже так реализовать, то это на корню разрушит простейшую, но надёжную и легкую в использовании технологию работы со складом ГП, которая применяется сейчас в настройке «металлолконструкции». И все отчёты и т.п. связанные с поступлением на склад ГП, отгрузкой, и т.д. придется пересматривать и переделывать. Потому что сейчас вся эта упрощённая технология зиждется на том, что сдаётся один раз на склад марка. Когда уже готова. А не на каждом участке по пути…

Можно ещё один альтернативный вариант рассмотреть в теории.
Как-нибудь придумать некий упрощённый способ фиксировать в программе именно «перемещение» изделий между операциями, но при этом не использовать вообще «тяжеловесную» складскую часть, с её сдачей на склад, перемещением, выдачей… Что-нибудь попроще придумать, чтобы вообще без «склада» обойтись.

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

1. Это надо реализовывать новую функциональность в программе для этого. Что не быстро. И не дёшево, соответственно. Это не отчёт настроить, пусть даже сложный.

2. Даже если реализовать. Никак не снимается вопрос, кто будет отмечать эти «перемещения» в программе. Пусть и несколько проще, чем через склад. Но так или иначе, отмечать то всё равно придётся.

У людей с машиной и двумя участками понятно. Им так и так нужна эта накладная. Они всё равно её составлять вынуждены. Так хотя бы, может быть, рутинную работу по деланию этих накладных можно им даже упростить.
А у вас?
Представьте в вашем производстве, если вменить дополнительно кому-то все перемещения чего бы то ни было с каждого участка на следующий заводить в программе некой «накладной». Будете это делать?
Каждый день. На каждом участке. По всем позициям графика производства, прошедшим через участок, делать накладные. Оно вам точно это надо?

-----------------------------
Заключение:

Теперь с учётом всего вышесказанного, начиная от неких сомнений в части объективности вообще отчёта за период по участкам в тоннах, просто по смыслу, и заканчивая размышлениями, во что в разных вариантах выливается его получение (не примерного, как Дмитрий предложил, а абсолютно точного, как вы хотите), возвращаемся к главному вопросу:

А реально так ли нужно? Именно в таком виде? Чтобы в тоннах, и по участкам, и за период, и точно?
Оно стоит того? Чтобы так заморачиваться ради такого отчёта в оконцовке?
 
Цитата
Константин Чилингаров пишет:
Начнём с общих вещей.
Вообще сама идея мерить работу отдельных участков тоннами достаточно спорная.
Есть, например, некая марка. Весит 1 тонну. Но на одном участке работ, относящихся к её изготовлению на пол часа, а на другом на 2 дня. А по отчёту такому получится, что один участок сделал 1 тонну, что другой – ту же 1 тонну.
Другой момент, что может марка весить, условно, 1 тонну, но при этом быть простейшей конструкции и состоять из 5 деталей, а может весить ту же условную 1 тонну, но состоять из кучи деталей и быть очень сложной конструкции. Первую делать легко и быстро, стоит она немного, вторую долго и сложно, стоит дорого. По отчёту опять же никакой разницы между ними нет.

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

Цитата
Константин Чилингаров пишет:
В этом плане намного более объективным показателем были бы не тонны, а деньги. Но деньги в данном случае, если разобраться, по смыслу это те же нормо-часы. Есть некая марка, которую предприятие продаёт за определённую сумму.

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

Соответственно скорее странно вести план-факт в нормочасах.
Директор: "Мы подписали договор на 100 тонн с такой то суммой. Ты сколько сделал?"
Работник: "500 нормочасов".
Директор: "Мы должны сделать 100 тонн боец... 100 тонн"

Цитата
Константин Чилингаров пишет:
Есть заранее оговоренная цена, которая пропорциональна общим трудозатратам (= нормировка от веса и кол-ва деталей).
Вот именно что она пропорциональна только тоннам, без деталей.
То есть, мы продаем заказчику здание весом 100 тонн. Не важно три детали за 80 т.р. а три за 40 т.р. - это его не волнует так как он платит за весь объем, поэтому мы определили 60 т.р. за тонну на весь объект (*не является публичной офертой).
При этом полностью цена всего здания будет определена после выполнения КМД, где детально отражено вся конструкция. За бугром кстати не так, они берут на себя риски и делают детализацию при проработке заказа, пусть даже в виде 3d модели, а потом подписывают заказ.
------------------------------------------------------------------
Это собственно про необходимость такого отчета, теперь про отчет.
Период – это фильтр, который применяется по собранным данным. Сначала нужно решить, как собрать данные. Опять же если посмотрим мою схему, то видно, что исключаем не последние операции.
То-есть логика, предлагаемая мной на приложенной блок-схеме.

Думаю, надо как-то взглянуть на все простым взглядом: Что нужно? – дата выполнения последнего задания на участке по отправочной марке,
Дальше я так понимаю базы под этот функционал нет не в одной существующей форме.
Может лучше создать какую-то форму, по типу статистики предприятия, назвать её статистика подразделения, куда марка должна попадать по описанной выше логике. Дальше фильтр по дате, и вуаля отчет с формы в красивой форме  :) , а еще отчет на период с разбиением по дням.
В общем я представляю, что это не пятиминутное дело, но потребность в нем есть и я думаю многие пользователи ко мне присоединятся.
Сейчас у нас на предприятии технолог часа 2-3 времени каждый день в экселе уделяет данному вопросу, это плохо.

PS

Цитата
Константин Чилингаров пишет:
Каждый день. На каждом участке. По всем позициям графика производства, прошедшим через участок, делать накладные. Оно вам точно это надо?  
Работал я на предприятии с такой сугубо бухгалтерской схемой слежения за производством,
и это жесть. Сейчас у нас на предприятии нет диспетчеров в цехе вообще, ну кроме вогбита. А у них 6 человек делают ту же работу без внятного эффекта. Даже предлагать это нельзя. Это верный метод свалиться на дно.
Только сменно суточные задания, только статистика производства.
 
Соглашусь с тем, что идея мерить деятельность "в продукции" со своей стороны тоже правильная. Что именно было изготовлено в выбранном периоде, причём не только вообще, но и в разрезе отдельных этапов производства. Какие именно изделия, в т.ч. по участкам.
Я уже думал тоже на эту тему.

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

Цитата
Клим Серебренников пишет:
Может лучше создать какую-то форму, по типу статистики предприятия, назвать её статистика подразделения
Была у меня такая идея.
Вполне возможно, так и нужно сделать.
Нужно ещё подумать эту мысль.

Есть ещё один положительный момент. Если так сделать, то можно строить такой отчёт за период в 1 день. И распечатать, какие именно изделия на выходе с участка должны быть по идее в конце дня.
А это может в какой-то мере помочь в решении извечной проблемы "как бороться с тем, что в программу ввели, что сделали 20, а по факту 18".
В этом тоже есть некая сермяжная правда, зачем нужны "накладные о передаче с участка на участок".

Я склоняюсь к деланию отдельной формы для получения такого рода информации.
Потому что "статистика":
- и так сильно уже перегружена;
- это несколько другое по смыслу;

В общем, "статистика" в её текущем виде - это штука полезная сама по себе и нужная, но она немного про другое. И навешивать на неё ещё и это - уже явно перебор. А идея на уровне отчёта делать мне не нравится. Сложно получится и нефункционально (мало гибкости и возможностей).

Поскольку, вы правильно говорите, это не пяти минут дело, нужно ещё подумать как следует. Но общий вектор понятен. Надо будет что-то подобное, наверно, сделать. Но наверное в виде отдельного режима как-то. И в следующих версиях уже.

Цитата
Клим Серебренников пишет:
Работал я на предприятии с такой сугубо бухгалтерской схемой слежения за производством,
и это жесть. Сейчас у нас на предприятии нет диспетчеров в цехе вообще, ну кроме вогбита. А у них 6 человек делают ту же работу без внятного эффекта. Даже предлагать это нельзя. Это верный метод свалиться на дно.
Только сменно суточные задания, только статистика производства.
Согласен. Мне тоже не нравится метод посадить операторов бездумно вводить кучу данных, чисто для получения конкретного отчёта. По моим наблюдениям, помимо усложнения всего процесса и большого объёма непонятной работы, такой подход, обычно, заканчивается тем, что отчёт желаемого вида то получается в итоге. Вот только к тому, что происходит в реальном производстве, он имеет весьма и весьма отделённое отношение.
 
Цитата
Константин Чилингаров пишет:
Поскольку, вы правильно говорите, это не пяти минут дело, нужно ещё подумать как следует. Но общий вектор понятен. Надо будет что-то подобное, наверно, сделать. Но наверное в виде отдельного режима как-то. И в следующих версиях уже.
То есть, через одно обновление? Есть ли возможность включить в выходящее обновление? Не то чтобы хочется поломать ваши планы, просто вдруг найдется вариант ...
 
Цитата
Клим Серебренников пишет:
Есть ли возможность включить в выходящее обновление?
Точно нет. Оно уже собрано. Заканчиваем тестирование. В него 100% уже больше ничего не добавится.

Теперь только в следующее, возможно.
Но ещё подумать нужно в любом случае, как делать. Чтобы потом не переделывать
 
Цитата
Константин Чилингаров пишет:
Теперь только в следующее, возможно.
Но ещё подумать нужно в любом случае, как делать. Чтобы потом не переделывать
Отлично, предлагаю обсуждать на стадии разработки, для получения максимально эффекта.
 
Ну, когда дело дойдет до этого, можно и обсудить... Когда будет что показать в каком-то виде хотя бы.
Пока на уровне общей идеи всё находится.
 
В связи с полной бесполезностью таких отчетов для производства м/к, а иногда и вредностью, если руководители подразделений будут гнаться за хорошими показателями в тн к совещанию, предлагаю выпустить специальный прибор-механизм для отчетов «наверх». Дизайн подобран специально для кабинетов руководителей с подобным мышлением.  На собственном опыте убедился в опасности таких отчетов – к совещанию задания выдаются, получается «нужный» директору отчет, после совещания задания отменяются и все довольны.
 
хм...
Мнения представителей разных заводов разошлись... Он "обязательно нужно" до "абсолютно бесполезно, даже вредно".
 
Есть в словах Дмитрия неприятная правда. Согласен что это скорее наследие плановой экономики чем грамотный подход к оценке эффективности. Но надо тогда работающую альтернативу, как тогда проанализировать выполненную работу? Как уйти от заказчиков мыслящих и требующих отчет в тоннах? Как грамотно поставить цель позволяющую вставать из окопов? Я понимаю что есть и другой ответ, кроме отчетов в тоннах. Но все же? как вы это видите?
 
Здесь по всей видимости путается понятие отчетности и мотивации. Никакая система управления производством не даст видимого результата роста производительности без «прикрученной» к ней отлаженной системы мотивации производственного персонала. Заказчик не оплачивает работу сотрудников на производственных участках какие бы отчеты вы ему не посылали. Это обязанность работодателя, и это в его интересах настроить производство так, чтобы работало как «часы», которые тоже нужно «чистить и смазывать». Общего критерия для мотивации производственных сотрудников быть не может, технология разная, одним - тонны, другим - кв.м, третьим – шт и т.д.
А для непроизводственных отчетов и предложен «отчетный механизм» - нажали нужную кнопку с названием участка, подкрутили ручку «больше-меньше» и готово. Главное не увлекаться и не использовать эти данные для реального управления.  https://www.youtube.com/watch?v=AtPgqBquMJ0
 
Цитата
Дмитрий Гриншпон пишет:
Здесь по всей видимости путается понятие отчетности и мотивации.
Предлагаю рассматривать по отдельности, мы говорим про отчет, конкретную форму отчета. Она нужна для отчетности. Для мотивации нужны выводы которые руководитель может сделать из этого отчета. Мы не успеваем - значит нам надо улучшиться, если мы все делаем в срок - значит методика правильная, нужно искать улучшения в другом месте.

Все правильно говорите в концепте, но на практике у меня человек сводит это каждый день по несколько часов. И руководителю очень сложно доказать, что это ненужно.
А теперь еще и сложно доказать Константину, что такая отчетность мне нужна от его программы...
Вам проще. Вы, сам лично не ставите таких задач перед сотрудниками и их не надо решать... и никакой ерунды, все работает. Но сейчас имея такой мощный инструмент как Vogbit, основываясь на исключительном подходе одного очень развитого завода отказываться от банальной формы, теряя при этом много человеческого ресурса на бесполезную работу. Для меня это так-же непонятно ...
Если вы не работодатель, то для вас концепт другой - видишь бред, сделай его как можно быстрее и с минимальными потерями. И тут превосходная идея с "отчетной машиною"...
Изменено: Клим Серебренников - 18.09.2018 16:02:46
 
Мне доказать то не сложно.
Я уже сказал, что определённую пользу вижу в возможности получать статистику в разрезе "готовности продукции по участкам". Если можно так выразиться. Причём в данном случае абсолютно всё равно в чём мерить. В штуках, в тоннах, в метрах...
Причём мне интересно это не только в плане измерения объёма, но и в плане автоматизации получения списка, что движется с участка на участок. В том числе. Тоже нужная задача. И можно её заодно порешать, как видится.

Концептуально да, можно сделать, наверное, и такое.
Просто, если делать, то надо ещё подумать в разрезе некоторых смежных вопросов. Чтобы потом не плодить ещё похожие режимы и не переделывать.

Что же касается концептуально вопроса нужности/ненужности, то я, если позволите, тоже чуть-чуть поучаствую.
Тут мне кажется вот в чем ещё дело. У Дмитрия производство выстроено и работает как "поток". В нем все постоянно движется с тактом в 1 день (может, быстрее). То, что порезали, завтра сваривают. Пока это сваривают, режут под то, что дальше будут варить. Завтра то, что сейчас на сварке попадёт на покраску, а то, что сегодня резали, будут дальше сваривать. И так в потоке постоянно всё движется. То есть раз в день (а может и чаще) весь этот поток +- синхронно перемещается. С заготовки на сборку, со сборки на окраску, с окраски на склад.

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

Если же такого "потока" нет, то возникает как раз вопрос, тесно связанный с мотивацией.

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

В итоге эффект получается зачастую прямо противоположный ожидаемому. Затраты растут. Нормочасов все больше вырабатывают. Цикл от материала до изделия на складе растёт. То есть работаем больше, в т.ч. по отчёности, а делаем продукции меньше.
Причина проста. Если механический цех и так делал не совсем те детали, которые нужны сейчас сборке, и не совсем тогда, когда нужны, то если этот вопрос никак не решили, а просто сказали "делать больше", то они и будут делать ещё больше не совсем того, и ещё более не совсем вовремя. Незавершённое производство растёт, трудоёмкость вырабатываемая растёт, сборке ещё сложнее становится что нужно вовремя собрать (т.к. ещё сложнее стало найти/добыть то, что на самом деле нужно).

Простыми словами, если у нас люди шли не совсем в одну сторону, а мы их принудительно заставляем идти быстрее, то они ещё быстрее расходятся в разные стороны. И ещё труднее, соответственно, в итоге всем вместе куда-то придти.

Возвращаясь к отчёту по участкам в тоннах.
Получается, что если есть "поток", то отчёт такой, вроде как, и не нужен, т.к. одно и то же в тоннах у всех получится. С небольшими отклонениями ото дня к дню.
А если нет постоянного движения, то ситуация, имхо, несколько напоминает описанную выше по смыслу.
Мы мотивируем каждого участника процесса делать как можно больше, не скоординировав общее движение (ибо если оно скоордирировано, то примерно одинаково у всех получится - зачем отчёт?). Получается что-то похожее на вышеописанный пример из машиностроения.
Один участок получается может сказать: "я д'Артаньян, я вон сколько тонн нарезал вам, а то что дальше вы там не можете сделать - не мои проблемы".
Что в плане общего результата не очень хорошо.
Тот же руководитель и спросит в итоге: "Мы программу купили, применили. Отчёты строим. А где результат? Где эффект?"

Я лично вот так данный вопрос понял.
Может, не прав. Вполне допускаю. Тогда поправьте, пожалуйста, где я не прав.

P.S.
Поймите правильно, к деланию/неделанию режима/отчёта это всё это не имеет прямого отношения.
Делать/не делать, когда и за какие деньги указанный режим/отчёт - это вообще из другой оперы совсем вопрос.
А вышесказанное - личное мнение в рамках концептуального обсуждения проблематики вообще. Для самообразования, можно так сказать.
 
Цитата
Константин Чилингаров пишет:
Возвращаясь к отчёту по участкам в тоннах.
Получается, что если есть "поток", то отчёт такой, вроде как, и не нужен, т.к. одно и то же в тоннах у всех получится. С небольшими отклонениями ото дня к дню.
А если нет постоянного движения, то ситуация, имхо, несколько напоминает описанную выше по смыслу.
Мы мотивируем каждого участника процесса делать как можно больше, не скоординировав общее движение (ибо если оно скоордирировано, то примерно одинаково у всех получится - зачем отчёт?). Получается что-то похожее на вышеописанный пример из машиностроения.
Один участок получается может сказать: "я д'Артаньян, я вон сколько тонн нарезал вам, а то что дальше вы там не можете сделать - не мои проблемы".
Что в плане общего результата не очень хорошо.
Тот же руководитель и спросит в итоге: "Мы программу купили, применили. Отчёты строим. А где результат? Где эффект?"

Мы уже ощутили на собственной шкуре правильность этих слов, и слов Дмитрия тоже.
И тут споры надо заканчивать, так как вы пишите очень верно.
 
Цитата
Дмитрий Гриншпон пишет:
На собственном опыте убедился в опасности таких отчетов – к совещанию задания выдаются, получается «нужный» директору отчет, после совещания задания отменяются и все довольны.
А при чем задания?
Отчет о ВЫПОЛНЕННОЙ работе, а не о ЗАПЛАНИРОВАННОЙ


Сменные задания - запланированный объем работ на посту определенного участка.
Отчет об отработанных нормочасах - количество отработанных нормочасов из запланированных.

Предлагаемый отчет по участкам - количество продукции, который участок выдал за период.

Пор моему он только в дополнение, но никак не в изменение предлагаемой системе управления производством выпуска металлоконструкций.
Цитата
Клим Серебренников пишет:
мы говорим про отчет, конкретную форму отчета. Она нужна для отчетности
Совершенно верно

Цитата
Клим Серебренников пишет:
Сейчас у нас на предприятии технолог часа 2-3 времени каждый день в экселе уделяет данному вопросу, это плохо

И у нас так же
Изменено: Ростислав Осипов - 19.09.2018 19:21:07
 
Добрый день.
Есть ли возможность формирования Оперативного плана производства для наглядного отслеживания выполнения Заданий на смену производственными участками?
Суть подобного отчета в наглядном представлении Заданий на смену (это план), того, что выполнено (это факт) и план-факт разницы.
Наше предприятие занимается производством металлической мебели: изготовление деталей, затем сборочные единицы из деталей, затем продукция из сборочных единиц. Оперативный план-факт анализ нужен для быстрой корректировки производственных сбоев, понимания причин задержки выполнения заказов.
 
Здравствуйте,

Цитата
Rudakov77 написал:
Есть ли возможность формирования Оперативного плана производства для наглядного отслеживания выполнения Заданий на смену производственными участками?
Да есть. В разных вариантах.
Просто внешне в другом несколько виде, не таком как на вашей картинке.
Примеры:

Вот здесь: рис. 1, 2 и др.
Вот здесь: рис. 2, 3, 6, 8, 12, 14 и др.
Вот здесь: рис. 32, 37, 39, 44 и др.


Цитата
Rudakov77 написал:
Наше предприятие занимается производством металлической мебели: изготовление деталей, затем сборочные единицы из деталей, затем продукция из сборочных единиц. Оперативный план-факт анализ нужен для быстрой корректировки производственных сбоев, понимания причин задержки выполнения заказов.
Знаем. Умеем подобную задачу решать. Если приедете как-нибудь в гости, можем рассказать и показать как. Только время нужно заранее согласовывать. С ним всегда самая главная сложность, его мало  :)
Страницы: 1
Сейчас на форуме (гостей: 18)
Всего зарегистрированных пользователей: 2722
Приняло участие в обсуждении: 325
Всего тем: 804
Всего сообщений: 6066

×
Вход на сайт