Планирование производства

Здравствуйте,

Нужно проверить настройки в базе для начала.

"Посты" должны быть привязаны, как "связанные объекты", к "участкам" (Рис.1). Тип связи "Производственный ресурс" (LT_Unit).
(указание программе, какой "пост" к какому "участку" относится)

"Участки" должны быть привязаны, как "связанные объекты" к настроечной номенклатурной позиции "VGB_SHIFT_PLANNING Настройки редактора смен" (Рис.2). Тип связи "Место выполнения" (LT_Place).
(Указание программе, какие из подразделений считать "производственными участками").

В этом конкретно графике - никак.
Этот показывает только общий расчётный объем невыполненных работ перед каждым "постом".
Можно теоретически использовать для планирования по загрузке "узкого места" (пример).
А вообще вещь эта получилась узко применимая (старая довольно уже).
Сейчас уже другие модули разрабатываем для долго- и средне-срочного планирования. Новые.
Как показал опыт, попытка определения сроков готовности через некую "плановую загрузку ресурсов" - в большинстве случаев (кроме совсем простых) нерабочий вариант получается, применимо к реальной жизни,
Более интересным по сегодняшнему нашему мироощущению выглядит вариант прогнозирования сроков, отталкиваясь от статистики по уже сделанным заказам.
Пример картинки из современной экспериментальной разработки (в стандартный дистрибутив пока не входит, опытный образец пока) - на рис.1.

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

Неправильно сформированы исходные данные. Может "связи" не включили при формировании заказа через "расчёт комплектации" (сами позиции заказа (детали-сборочные единицы) между собой никак не связаны получились), может быть, "последовательность" не включили при создании заданий в "Графике производства".(Задания созданные получились никак не связанные между собой).
Если всё правильно сделать, то будет все по порядку высвечиваться. Но нужно, правда, ещё, знать потом, конечно, как правильно посмотреть. А это от "уровня" зависит, в свою очередь.

При формировании карты заказа поставить "Сохранять связи" - рис.2.
В "Графике производства" при создании заданий поставить "последовательность" (например, "подряд") - рис.3.
Дальше последовательность действий, чтобы увидеть нужное, зависит от "уровня" выбранного, в первую очередь. Ну и от особенностей технологии.
Если нужно, можем провести обучение. Будет стоить денег. Но зато быстро всё расскажем и покажем.

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

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

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

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

А вот статистика то как раз поможет.
Статистика - вещь упрямая. Спорить с ней бесполезно.
Если вы в течение, например, последнего года делали заказы в среднем с определённой "скоростью" (а её можно измерить с помощью VOGBIT, и понятно как), то крайне маловероятно, что следующий 1, 2, N ближайших следующих, подобных в плане технологии заказов вы внезапно вдруг сделаете как-то принципиально быстрее.
Как ты полосочки на экране компьютера не переставляй, производство реальное работает так, как оно в реальности организовано. И внезапно, за день или неделю по другому оно работать не начнет (можно, безусловно, прикладывать постоянные усилия для того, чтобы эта скорость (производительность) постепенно увеличивалась, но это процесс не внезапный, а достаточно плавный и длительный, обычно, и изменения происходят совсем не мгновенно).
А вот вероятность, что следующий заказ вы сделаете приблизительно с такой же "скоростью" как и предыдущие (не сильно от неё отличающейся, с некоторыми допусками), она то, как раз, очень даже велика.

3750 р./час.
Количество часов может быть разным. Для первоначальных каких-то результатов можно отталкиваться где-нибудь от цифры 20-30 часов (для небольшого предприятия, для больших - больше однозначно выйдет) хотя бы для начала, ну и дальше по желанию. "Размазаны" эти часы будут, скорее всего, на несколько месяцев. Оплата по факту за месяц (без предоплаты и без необходимости в какой-то ограниченный срок эти "часы" выбрать все).
Если интересно, можно созвониться, расскажу, как это всё организуется, обычно.

Есть. В разных вариантах.

Есть "опытный образец" на основе статистики ранее выполненных заказов. Обкатываем с несколькими нашими клиентами пока его.

Тоже всё есть. В разных вариантах.

Непонятно, почему это "в будущем". При реализации предыдущих двух пунктов это, как бы, в моём понимании само собой получится, как один из побочных моментов.

Здравствуйте,

Математически – можно. Вопрос целесообразности (количество времени и денег на это потраченное/результат на выходе).
Прямо сейчас, если честно, просто не до того.
На ближайшие несколько месяцев, у нас сейчас уже расписана очередь по разработке, и это время точно будет занято теми вещами, которые точно дадут результат, понятно как, какой и кому.
Поясню для понимания: у нас идёт постоянная обратная связь от пользователей, активно использующих программу, с проектов, где мы сами принимаем участие во внедрении (соответственно, знаем реальную ситуацию), и из этого мы понимаем, чего им сильно не хватает для работы, где реально неудобно сделано и т.п. Исходя из этого расставляем приоритеты работ по улучшению и развитию программы (не считая некоторых стратегических, системных, вещей, но это отдельная тема).
Разработанные по такой схеме новшества первым делом в «закрытом порядке» идут в 1,2,3 места – кому реально это очень нужно (чаще всего, они же и частично в минимальном хотя бы объеме и принимают участи в софинансировании этих доработок, как самые заинтересованные). Проходят обкатку в реальных условиях. С год примерно в среднем. Потом, обычно, попадают в общую версию, которая лежит на сайте и доступна всем. И почти все очень быстро начинают широко использоваться. Из серии «Как здесь всегда и было. Как же раньше то без этого мы жили?».

Для примера:
Вещи, которые уже прошли этот цикл и сейчас уже в общей версии:
- настройка цветов, сохранение именованных вариантов настройки экрана и быстрое переключение между ними (в «Графике производства», например).
- функции и методика работы с заданиями (и интеграции с программами раскроя) для предприятий, где много ЧПУ резки листа (лазер, плазма). Недавно, кстати, их же задействовали успешно и на предприятии, где очень много резки алюминиевого профиля.
- расчет и контроль обеспеченности с учетом последовательности выполнения «заказов», требуемых сроков и ожидаемых сроков поступления тех или иных позиций. С визуализацией для снабжения не только «что» нужно, но и «когда». Для производства – не только чего на сегодня не хватает, но и когда оно будет. С автоматическим поиском и подсветкой «проблемных позиций» (не успевает к сроку или не заказано) и др.
- и многое другое.

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

Так вот… Это, что уже прошло «цикл».
На сейчас у нас уже на несколько месяцев вперед расписаны следующие подобного рода доработки по результатам применения программы у клиентов. Которые нам точно понятно зачем нужны, как будут использоваться, и точно увеличат количество пользователей в перспективе. Они в приоритете. Если вдруг бы образовалось свободное время (в чем я лично начинаю сомневаться, глядя на последние несколько лет), то технически можно было бы и заняться, в принципе, «теоретической» задачей наложения некой «работы» на календарь. Иногда возвращаемся к идеям на эту тему. Но пока сильно заняты «вещами» более приземленными, и с нашей точки зрении, более полезными (на текущем этапе, по крайней мере).

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

Что планировать?

Попробую объяснить свою позицию простыми словами и кратко:
Реальный производственный процесс представляет из себя некий, назовем его так «макро-процесс». Который помимо обработки деталей на токарном станке, плазморезе и т.п. включает в себя ещё множество «около производственных» факторов и событий, которые непосредственно, и часто очень сильно, влияют на срок достижения конечного результата. В том числе:
- всевозможные «рядом лежащие» события и мероприятия: уборка снега, вентиляция, отопление, вопросы связанные с расширением производства и т.п.
- мотивация людей
- различные решения принимаемые в процессе людьми (сделать так, или иначе)
- различного рода конструктивные и технологические сложности, возникающие по ходу, про которые заранее никто не знал/не подумал, но теперь их как-то надо решать.
- ошибки и исправление «косяков».
- решения директора - пообещать кому-то что-то или нет, взять ту или иную работу по каким-то своим причинам или нет и т.п.
- и ещё много-много всего.

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

Ну да Бог с ним…  Даже если и на это «забить» и считать, что пусть будем отталкиваться только от времени обработки, пусть завышенного несколько…
Даже если так. Никто не отменял значительных изменений реальных показателей в результате того, что возникли некие проблемы, которые нужно порешать, и в результате мы сильно отклонились от изначального «графика». Никто не отменял решений директора что-то срочно сделать, поменять и т.п. И все это ведет к изменению этого графика. А значит что то, что мы нарисовали на своём «графике» до того как (условно, вчера) – никакой практической ценности сегодня с учётом этих изменений уже не имеет.
И самое то главное в этом то, что в момент, когда вы строите эту «модель», то вы в принципе не можете эти факторы никак учесть. Потому что то, что сильно повлияет (до неузнаваемости, возможно), на ваш такой график, оно ещё просто не произошло сейчас, когда вы его строите. Проблема пока не возникла. Директор пока не принял решения, и ещё даже не возникла та ситуация, в которой ему пришлось его принимать. Этого ничего ещё НЕ произошло. И вы не знаете, что именно, и когда именно произойдёт. Но оно точно произойдёт… )))

Исходя из всего выше сказанного, получается:
Допустим, мы отложим все другие дела, потратим время (=деньги) на то, что напишем некую такую «раскладывалку» - автоматическую рисовалку графика. Что дальше?

Вычислить с её помощью реальные сроки, когда что будет на самом деле готово – невозможно (обоснование см. выше). Даже если вы будете каждый день «пересчитывать» (и каждый день «расчётные сроки заказов» будут меняться – тут сразу вопрос – а зачем мы предыдущие все разы их считали? И зачем сегодня считаем, если завтра все равно другие получатся, а эти будут неправильные?), всё равно в получившиеся «сроки» готовности «заказов» на этом графике вы не попадете. Что-то раньше будет готово, что-то позже. Но НЕ в те сроки, какие получались «на графике».
Получается, внутри «графика» в плане сроков и последовательности в реальности по факту всё перемешается (тогда, по большому счёту, какая разница в каком порядке там полосочки нарисовались на графике, если все равно всё «перемешается» и будет не так).

Определить, успеем сделать/не успеем? Для горизонта планирования несколько дней – слишком грубо. Тут у нас есть инструмент подходящий – «высокий» уровень с детальным планированием выполнения задания в перспективе день-несколько. На таком коротком отрезке принципиально не просто «разложить», а именно так и сделать, как «разложил». Для средне и долго срочной перспективы – горизонта недели и месяцы – тоже не пойдёт. Слишком много неопределенности. Учитываем меньше факторов, чем не учитываем.

Для некоего объемного планирования - т.е. прогнозирования возможности в принципе сделать указанный общий объем итого в какие-то желаемые сроки, такой график тоже не особо поможет. Если только при любых раскладах на этом «графике» не прибавлять в конце ещё (условно) 2 недели «про запас, на непредвиденные обстоятельства». А сколько брать тот самый запас? Построенный по такой постановке график ответов на этот вопрос тоже не даёт.

Чтобы к последним двум вопросам подступиться (объемное планирование, определение успеваем/не успеваем при "длинных" заказах), нужно с моей точки зрения оперировать как раз не «микро-действиями», а некими усредненными измеримыми показателями «макро-процесса». Вроде средней суточной выработки (в н/ч) итого по всему производству, пределов её отклонения по статистике, усредненной «скорости движения» (в н/ч в день) заказов по производству и пределов её отклонения по статистике. Некоторые наработки сейчас в этом вопросе у нас есть уже, но опыт пока маленький. Потому что серьезная статистическая база нужна – т.е. полностью внедренная и на 100% хорошо используемая «Производственная часть» программы хотя бы несколько лет.

Вопрос планирования текущих работ, что кому сейчас непосредственно делать – тоже такой график не нужен (не решает задачу). Это как раз нормально решается и текущими средствами: очередь текущих заданий, рассортированная по приоритетам или датам или для тех, кто хочет уж совсем точно – «высокий/максимальный» уровень и точные задания на смену по постам.

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

И ещё есть один момент, который косвенно подтверждает ход моих мыслей.
Как-то примерно лет 10 назад, когда я уже примерно лет 10 к тому времени был так или иначе «в теме» или около того, я высказал такую мысль: если это действительно такая хорошая идея строить програмно такие графики по такой логике, то почему за 10 лет программы, которые пропагандируют такой подход (а они были уже и 20 и 10 лет назад) не то что массово не используются – их вообще нет в реальных производствах? Почему? Если это так здорово, как они рекламируют?
Прошло с тех пор ещё 10 лет. Ситуация никак в этой части не поменялась. Пор крайней мере, из того, что я вижу. Вопрос «так всё таки почему этого нет, если это так «перспективно»?» остался…

Наводит на мысли… ))

Итого получается:
Это, по сути, ответ на вопрос

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

То есть, по сути, получается изыскательская работа на тему «Давайте попробуем, может что-то интересное и получится. А может и нет».

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

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

Как-то так…

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

А у вас нет какого-то API или описания базы данных?
Может мы сами напишем с кем-нибудь такой отччет, напрямую к базе обращаясь?