Заказ звонка

Закрыть

*
*
*

Замена вспомогательного материала на допускаемый материал и ведение допускаемого материала

Страницы: 1
RSS
Замена вспомогательного материала на допускаемый материал и ведение допускаемого материала
В общем задача скорей звучит как, ведение альтернативных операций (и всего того, что на ней висит), а так же замена, при необходимости, в производстве ими основных операций.
Пример. Есть операция А (эл. сварка) ВМАТ на ней электроды, ну и соответствующие оборудование, но при этом, относительно именно ДАННОЙ СБ, можно еще применить операцию В (газо - сварка) ВМАТ аргон, проволока и т.д. и операцию С (газо – сварка) ВМАТ угле. газ, проволока и т.д. Технологи клянутся, что не знают заранее на каком маш. комплекте, что будет, это может решиться при планировании закупок ОМТС или в цеху в самый последний момент напр. от наличия на складе ВМАТ на текущею минуту. Поэтому технологи обязаны давать информацию о допустимых заменах, а в производстве (с точки зрения уже TCS) должен быть механизм по замене операций (и всех на нее ресурсов).
Конечно, я предполагаю, что вести альтернативные операции нужно версиями (я бы сказал «неполноценными» поскольку кроме одной операции и что в нее входит, не чего не будет), при этом в используемом ТП на операциях имеющие альтернативы должен стоять параметр указывающий на версии ТП содержащие альтернативы. Ну, а этим можно в принципе «рулить» как хочешь.
Если у кого то, есть еще мысли и опыт в решении данной задачи, поделитесь.
Цитата
juri пишет:
В общем задача скорей звучит как, ведение альтернативных операций (и всего того, что на ней висит), а так же замена, при необходимости, в производстве ими основных операций.

Такой опыт есть. Но из Вашего поста я не понял зачем Вам это надо.
Цитата
juri пишет:
Пример. Есть операция А (эл. сварка) ВМАТ на ней электроды, ну и соответствующие оборудование, но при этом, относительно именно ДАННОЙ СБ, можно еще применить операцию В (газо - сварка) ВМАТ аргон, проволока и т.д. и операцию С (газо – сварка) ВМАТ угле. газ, проволока и т.д.

Это всё понятно, довольно обычная ситуация.
Цитата
juri пишет:
Технологи клянутся, что не знают заранее на каком маш. комплекте, что будет,
Я им верю smile:) поэтому и разрешили в технологии различные варианты выполнения работ, раз это не критично.
Цитата
juri пишет:
Поэтому технологи обязаны давать информацию о допустимых заменах, а в производстве (с точки зрения уже TCS) должен быть механизм по замене операций (и всех на нее ресурсов).
Про технологов, понятно, такую информацию можно завести. Причём разными способами, начиная от просто комментариев, или использование специальных классов в ТП с типом обработки Комментарий, а можно и интереснее. Всё зависит от того - для какой задачи. А вот как раз это-то и не понятно. Зачем в TCS делать какие-то замены? для чего? проясните, пожалуйста?
Цитата
juri пишет:
... это может решиться при планировании закупок ОМТС или в цеху в самый последний момент напр. от наличия на складе ВМАТ на текущею минуту
Т.е. ОМТС уже сам решил, что покупать или уже купил и на склад положил. smile:) Зачем тогда эта информация в TCS нужна, для кого она теперь?

Объясню свои вопросы. На практике сталкивался как раз с другой ситуацией. Когда, наоборот, из различных вариантов выполнения работы, надо выбрать один (на стадии планирования), чтобы однозначно определились ресурсы под выбранную работу, чтобы затем получить сводные данные для службы закупки.
А у Вас получается, служба закупки сама знает и так, что покупать. Ну раз так, то какое принципиальное значение имеет то, что сейчас написано в TCS?
Вот с чем сталкивался:
По тех. требованиям необходимо утеплить кузов автотранспортного средства для транспортировки людей.
Нашли два утеплителя. Материал один и тот же, но вот исполнение разное. Первый вариант представляет собой просто пласт, который надо самостоятельно намазывать клеем и приклеивать, а второй вариант уже подготовлен. Т.е. надо просто защитный слой отделить и клеить.
Очевидно, что для первого варианта требуется куча дополнительных вспомогательных материалов начиная от самого клея, растворителя, обезжиривателя, до перчаток, салфеток и прочих расходников. Опять же трудоемкость для этих вариантов сильно отличается, не говоря уж про соблюдение условий труда.
С другой стороны всё это компенсируется различием в затратах на обеспечение материалами в том и в другом случае (в первом случае сумма закупки оказывается меньше). И опять же сами технологи говорят, что первый вариант надежнее.
Второй вариант существует для подстраховки.
Так вот, при планировании заказов и расчёте потребностей в материалах для их обеспечения в количественном и в денежном выражении, как раз и используется информация системы TCS.
То так посчитать, то эдак smile;)
Ситуация следующая. Пока задача посчитать, то так, то этак, не ставиться.
Начнем с ОМТС, есть материалы которые на данный момент ОМТС не может привести (по разным причинам), при этом не значит, что в дальнейшем эти материалы не будут поставляться. Поэтому с точки зрения ОМТС вопрос будет стоять – чем можно заменить и в каком количестве? Если применить использование специальных классов в ТП с типом обработки Комментарий, получиться куча бесполезной, сточки зрения обработки, информации. При этом не надо забывать, что это может повлечь (к ВМАТ и нормам расхода) не только замену оборудования и самой операции, а возможно и добавления новых операций, очень интересно в каких комментариях все это можно описать и как потом обработать. Далее цех, ему нужно в случае отсутствия ВМАТ или невозможности использования запланированного оборудования, как то использовать альтернативные решения (если это конечно возможно), как он может выполнить в срок задание не имея механизмов использования альтернатив, что он будет делать с комментариями? В ручную править операции и ресурсы? Ведь на основании этой информации нужно сформировать требование (с перечнем и нормами расхода) и получить другую информацию и документы.
С точки зрения планирования и производства, когда технология подразумевает несколько альтернативных вариантов (не важно, одна операция, две, три, с материалами и т.п. или без...), пожалуй, лучший способ - это делать конфигурируемые техпроцессы. По аналогии с конфигурируемыми спецификациями.

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

А если с точки зрения просто печатать документы (а-ля маршрутные карты, ведомости и т.п.) – всё равно как делать. При желании настроить можно почти всё что угодно на уровне отчёта.
Цитата
Константин Чилингаров пишет:

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


Подразумевается версиями ТП и ссылками на них через конфигурационные параметры или описывать все варианты в основном ТП и потом вычислять при загрузке или отчетах через конфигурационные параметры все нужное или ненужное?
Нее, версии плодить не надо. Зачем?

Цитата
juri пишет:
описывать все варианты в основном ТП и потом вычислять при загрузке или отчетах через конфигурационные параметры все нужное или ненужное?


именно так smile:)

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

С конфигурируемыми техпроцесами не на пустом месте придумали решение smile:).

Насчёт писать - кое-что то ведь есть на эту тему уже, причём проверено, т.к. в реальном производстве работает. Обращайтесь - можем показать. Посмотрите, может подойдёт и оно?
Страницы: 1
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)