Здравствуйте!
Здесь нужно понимать некоторые моменты. Поясню:
Первое и самое важное – что данные механизмы: что «дерево» для навигации по производственному заказу, что различные фильтры, построенные на существующих между разными позициями производственного заказа зависимостях (типа «текущие работы» и т.п.) – все они не являются абсолютно точными инструментами, которые корректно и точно будут отражать картину происходящего абсолютно в любой ситуации.
Скажем так, «точно» они будут всё «показывать» в простых случаях. Что я понимаю в данном контексте под «простыми случаями»: когда одинаковые детали, хотя и идут в «заказе» в разные места, делаются все одной партией, то изготавливается сразу вся партия целиком, всё количество. Когда опускаем за скобки всякие возможные нюансы, связанные, например, с возникновением неисправимого брака в процессе изготовления партии деталей. И т.п. Вот в таких «простых» условиях и «дерево» и фильтры (типа «текущие работы») будут всё «точно» показывать.
В более сложных случаях – они какую-то информацию будут давать, но нужно её творчески интерпретировать. Понимая, что программа в условиях крайне ограниченного набора исходных данных, которые в неё вводят, просто не может в неоднозначной ситуации сама «разобраться», что реально происходит «на земле», и показывает картину только «примерно». А дальше уже нужно, частично опираясь на эту информацию, действовать по ситуации самому.
А чтобы программа во всех случаях показывала строго «точную» картину происходящего, тут нужно другие средства применять. В первую очередь, касательно самой организации процесса, и затем уже соответственно и отражения происходящего в программе. Об этом пару слов ниже скажу. Пока давайте поясню некоторые особенности работы «простых» инструментов на примере «дерева» и фильтра «текущие работы».
Что касается «дерева»:
Оно, в первую очередь, делалось для навигации и выборок при работе с «большими» заказами (множество сборочных единиц друг в друга входящих, деталей, много разных исполнителей работ (участков, мастеров)), чтобы как-то попроще ориентироваться в таком большом массиве информации. Попутно само это «окно» (с «деревом») некоторую информацию показывает с определёнными допущениями. В частности, если одни и те же детали идут во много разных мест (узлов) в «дереве» и изготавливаются одной партией, то для отражения на какие узлы «хватает» готовых уже деталей, а на какие нет – программа определяет это условно, по принципу распределения количества «готовых» деталей по тем местам, где такие детали есть в «дереве», просто «сверху вниз» (по прядку следования в «дереве»).
Понятно, что это не точно. Тут, так-то, нужна ещё последовательность комплектования соответствующих узлов. Как минимум. А не просто по порядку сверху вниз. Но в тот момент, когда мы этот механизм делали, те товарищи, которым тогда он был в первую очередь нужен, сказали, что такие тонкости не актуальны, т.к. «мы детали, если делаем одной партией, то сразу делаем всё количество». И поразмыслив, мы решили действительно не стоит усложнять данный инструмент (т.к. там, если начать закатываться в детали, как и что может быть, то нюансов сразу море вылезет) и оставить так. Если все детали из партии делаются сразу, то оно и так всё показывает правильно. Если партия частично изготовлена, то онлайн, прямо в данный момент, что начинать или не начинать уже собирать из тех деталей, которые изготовлены из партии на текущий момент – решать человеку. Само «дерево», повторюсь, в таком случае условно «распределяет» количество «готовых» на текущий момент деталей просто «сверху вниз».
Теперь про фильтр «Текущие работы»:
Это тоже инструмент приблизительный. Автоматически точно он всё показывает, как я уже говорил, в простых случаях: если делать детали в партии сразу всё количество и пренебречь всякими возможными в теории нюансами типа «разветвления» партии по ходу обработки, возникновением неисправимого брака и т.п.
Если детали из одной и той же партии идут в разные узлы и в разном количестве, то в рамках «упрощённой картины мира» у программы просто нет точной информации, на какие именно узлы следует в моменте использовать те детали, которые «готовы», если готовы они не все, а только часть И при подсчёте значения «в работе» (а фильтр «текущие работы» ориентируется именно по этой колонке – сколько изделий сейчас можно в теории сейчас обрабатывать на данной операции), если от изготовления партии деталей зависит дальнейшее изготовления разных узлов, то программа пытается, если можно так выразится, «наполнять все корзинки равномерно». Поясню на примере:
Допустим, есть какое-то количество сборочных единиц «СБ1», для каждой из которых нужна деталь «ДЕ1» в количестве 1 шт. Но при этом в этом же заказе есть такое же количество сборочных единиц «СБ2», в каждую из которых нужно по 2 шт. деталей «ДЕ1». И есть ещё в этом же заказе сборочные единицы «СБ3», в которые в каждую нужно по 3 шт. деталей «ДЕ1» в каждую.
В такой ситуации в колонке «в работе» программа поставит по «1» сразу для «СБ1», «СБ2» и «СБ3» в тот момент, когда из партии деталей «ДЕ1» будет числится «готовыми» 6 шт. (или больше). То есть, с точки зрения возможности дальнейшего «движения заказа» все «корзинки наполнены равномерно». Пока же «готовых» деталей «ДЕ1» из всего количества меньше 6 шт. программа сама «в работе» ничего подставлять не будет ни для «СБ1», ни для «СБ2», ни для «СБ3», т.к. она просто не знает, а что сейчас начнём собирать реально, если готово, например, только 3 шт. «ДЕ1». Понятно, что в случае готовности всех деталей «ДЕ1», всё отобразится правильно в «текущих» работах. Когда часть деталей «ДЕ1» готова, часть нет – плюс/минус, с учётом такой упрощённой логики.
Побочным эффектом в данном случае, как можно заметить, является то, что если какой-то из этих сборочных единиц будет 1 шт, то пока вся партия деталей не будет изготовлена, программа сама «в работе» никуда не поставит, т.к. эта «корзинка» будет «тормозить» всех остальных в плане «равномерности заполнения».
Но это неизбежно в условиях «дефицита» исходной информации. Когда в программе отражаем только небольшую часть информации, описывающей реальный процесс. И когда сам по себе этот процесс предсказуем весьма примерно…
Если нужно прямо точно понимать в моменте, какая именно сборочная единица закомплектована, а какая пока нет, то это, насколько я понимаю, нужно немного по-другому сам процесс в первую очередь организовывать. И тогда в программе его соответственно и отражать.
Один из вариантов – это не запускать детали сразу на много сборок, но при этом по факту делать и использовать их частями, а изготавливать детали изначально «целевым образом». То есть запускать в работу не всё количество, сколько вообще во всех местах есть в «заказе», а только часть из общего количества сейчас, и при этом сразу изначально понимая, для каких именно сборочных единиц мы сейчас конкретно эти детали делаем и будем использовать. Как в программе такую схему работы отразить технически – тут разные варианты можно попробовать. Разные «карты заказа» делать, например. Или постепенно добавлять частями позиции в одну и ту же «карту» и разделять их «очередями», допустим. В производстве каркасных строительных металлоконструкций, в рамках такой общей концепции «целевого изготовления деталей», мы в свое время отлично обкатали, так называемый, метод «по комплектам» - когда вообще не отслеживается движение каждого конкретного наименования деталей, а детали по стадиям обработки (резка, сверловка, фрезеровка) физически движутся сразу «комплектами» под определенный набор марок, которые следующие будут собирать, и так же отмечается и контролируется это движение в программе. На практике работает просто великолепно в плане общей производительности труда на предприятии в пересчёте количества выпущенной продукции на одного человека в производстве (опыт реального использования у людей скоро будет уже 15 лет примерно, и всё очень даже здорово), но при одном условии – что само производство именно так и работает.
Другой вариант – это просто делать детали в любом количестве, каком удобно, а для точного понимания их дальнейшего использования сдавать готовые детали на склад. Параллельно со стороны сборочных подразделений формировать запросы (ЛЗК, Требования) на получение нужного количества деталей отдельно под каждую конкретную сборочную единицу (партию), выстраивать очередность (например, с помощью плановых дат), в каком порядке эти запросы на детали удовлетворять, отмечать факт выдачи деталей со склада под определенную сборочную единицу (партию) (причем реальный порядок комплектации сборок совсем не обязан совпадать с изначально запланированным). Вот тогда будет абсолютно точная «картина мира» по закомплектованности узлов, по дальнейшему движению деталей после того, как они изготовлены. Потому что точно будет четко понятно, подо что конкретно те или иные детали по плану должны пойти в соответствии с установленной очередностью комплектации, подо что реально на сейчас уже пошло то, что сделано было.
Понятно, что оба этих варианта требуют усилий, в первую очередь, в плане именно организации самого физического процесса. Понятно, что они для разных случаев. Например, первый вариант («целевое» изготовление деталей) хорошо работает в производствах, где сами детали очень простые, а цикл производства их очень короткий. Вроде строительных каркасных металлоконструкций, изготовления блоков остекления и т.п. Второй вариант (через «склад») больше подходит для «классического» машиностроительного производства, где встречаются как простые в изготовлении детали, так и сложные, причём в одном и том же узле, где цикл изготовления деталей может быть длинным и сильно разным для разных деталей.
Наверное, можно и ещё что-то придумать, но факт в том, что чтобы программа точно показывала, какую именно сборочную единицу сейчас можно собирать из имеющихся деталей, нужно чтобы сам процесс подразумевал, что это достаточно точно и чётко регламентировано. Если же мы просто оперируем общими данными, что есть N деталей, которые нужны на K разных сборочных единиц и X из этих деталей сейчас готовы, и на этом всё – то пока все N деталей не готовы, «картину мира» мы можем иметь только приблизительно-условную. Например, с учётом тех допущений, что я описал выше.,
