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

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

Отчет задание на пилу - Отчёты
Виктор Левушкин: ВОпрос! Выбрал для себя на начальном этапе Средний уровень. Тип терминала 2. Задание формирую по среднему уровню методом "По комплекта ...
Ошибка печати отчета - Отчёты
Виктор Левушкин: Спасибо. Вроде уже разобрался. Веду теперь блокнот по каждой операции пишу последовательность, т.к. пока нет опыта, но уже много чего запу ...
Одно задание для нескольких работников и совместное выполнение - Обновление
Константин Чилингаров: Здравствуйте, Совместное выполнение отмечать через терминал "Тип 2" и раньше было можно. Вот пример - краткое пояснение на эту тему ...
Нормы расхода на окраску - Состав и технология
Lyovushkin: Спасибо буду пробовать
VOGBIT Онлайн - Общие вопросы
Константин Чилингаров: Здравствуйте, Клиентское приложение VOGBIT в данном случае ставится не на ваш конечный компьютер, а на сервер. А вы работаете с ним через и ...
Планирование производства - Демо версия
Константин Чилингаров: API есть. Описания базы данных нет (и вряд ли будем делать в ближайшее время). Есть /forum/forum35/ раздел на форуме . Там примеры использования AP ...
Как отслеживать все детали, входящие в заказ? - Прочее
Константин Чилингаров: Чуть добавлю: Ответ кратко: Да, можно будет продолжать работать с тем, что ввели в "демо-версии". Дополнение к предыдущему сообщен ...
Ошибка при открытии спецификации - Прочее
Константин Чилингаров: Здравствуйте! Версия программы старовата. Хорошо бы обновить. Когда-то, давным-давно, кажется, была такая ошибка, но её быстро починил ...
Учет материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Вкладка меню "Складской учёт" -> Алгоритм списания -> FIFO.
Обороты по складу - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Это какими-то настройками или ещё как-то самостоятельно не решается, к сожалению. Нужно форму экранную саму поменять нем ...
Удаление позиции из номенклатуры - Прочее
mansur: Доброе утро, спасибо, все сделал по второму варианту. 
Ошибка при входе в Vogbit - Прочее
Григорий Клеков: написал: Здравствуйте. ...
Установка Демо версии - Демо версия
Amg: Спасибо большое за ответ. Демо-версию установил на ноутбук, если руководство решит перейти на ваш продукт, то думаю видеоконференция буд ...
Хранение файлов в БД - Общие вопросы
Константин Чилингаров: Если при этом вы хотите потом использовать штатные возможности VOGBIT (например, просматривать эти прикрепленные к операциям файлы в окне ...
Предварительные заявки, ЛЗК, Требования - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте! Периодически возникают похожие вопросы по "Предварительным заявкам", "ЛЗК", "Требованиям". В чём разница, ...
Конструктор фильтра - Прочее
Kochurova.av: Спасибо Вам большое!  Всё как всегда оказалось проще простого)
Свои поля для справочников и вывод их в список. - Общие вопросы
Константин Чилингаров: Здравствуйте, В "Номенклатуре" стандартно есть свойство "Комментарий" и соответствующая колонка в современных версиях VOGBIT ( ...
Список работников поста - Общие вопросы
Константин Чилингаров: Пожалуйста! Пользуйтесь)) Нет. Ссылку не нужно выкладывать. Потом, когда общее обновление соберем, выложим его на сайт, и все смогут ска ...
Вопрос по импорту - Экспорт импорт данных
mansur: Нашел, залил и все работает теперь, спаибо.
Ошибка при запуске приложения - Прочее
Сергей: написал: Если на другое железо переставить Вогбит, как лицензию нам перекинуть? на mailto:info@vogbit.ru info@vogbit.ru  напишите со ссылкой на эту тем ...

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

Вопросы по работе с демо версией - Демо версия - Вопросы новичков
Страницы: 1
Планирование производства, Для планирования доступны не все ресурсы
 
Добрый день.

Почему у меня не все производственные ресурсы доступны для рассчета планирования? Что я делаю не так?
Вогбит2.png (230.07 КБ)
 
Здравствуйте,

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

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

"Участки" должны быть привязаны, как "связанные объекты" к настроечной номенклатурной позиции "VGB_SHIFT_PLANNING Настройки редактора смен" (Рис.2). Тип связи "Место выполнения" (LT_Place).
(Указание программе, какие из подразделений считать "производственными участками").
1.png (81.4 КБ)
2.png (96.55 КБ)
 
Отлично! Помогло.
Теперь вот планирую производство. У меня в заказе сложное устройство, где общая сварка выполняется только после фрезеровки. В рассчитанном графике загрузки я вижу суммарную загрузу по всем постам.
1. Как учесть в этом графике, что варить мы сможем только после завершения всей фрезерки? Как сделать план с учетом последовательности выполнения взаимозависимых операций?
2. При выдаче заданий в производство, почему выдаются задания по сварке тех деталей, которые еще не готовы? Как  автоматизировать выдачу заданий с учетом последовательности изготовления деталей, например если фланец не готов - патрубок на сварку не отправляем и сообщаем об этом мастеру?
Вогбит3.png (216.81 КБ)
Изменено: Stas Frang - 05.09.2021 19:55:37
 
Цитата
Stas Frang написал:
Как учесть в этом графике, что варить мы сможем только после завершения всей фрезерки
В этом конкретно графике - никак.
Этот показывает только общий расчётный объем невыполненных работ перед каждым "постом".
Можно теоретически использовать для планирования по загрузке "узкого места" (пример).
А вообще вещь эта получилась узко применимая (старая довольно уже).
Сейчас уже другие модули разрабатываем для долго- и средне-срочного планирования. Новые.
Как показал опыт, попытка определения сроков готовности через некую "плановую загрузку ресурсов" - в большинстве случаев (кроме совсем простых) нерабочий вариант получается, применимо к реальной жизни,
Более интересным по сегодняшнему нашему мироощущению выглядит вариант прогнозирования сроков, отталкиваясь от статистики по уже сделанным заказам.
Пример картинки из современной экспериментальной разработки (в стандартный дистрибутив пока не входит, опытный образец пока) - на рис.1.

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

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

Цитата
Stas Frang написал:
Как  автоматизировать выдачу заданий с учетом последовательности изготовления деталей
При формировании карты заказа поставить "Сохранять связи" - рис.2.
В "Графике производства" при создании заданий поставить "последовательность" (например, "подряд") - рис.3.
Дальше последовательность действий, чтобы увидеть нужное, зависит от "уровня" выбранного, в первую очередь. Ну и от особенностей технологии.
Если нужно, можем провести обучение. Будет стоить денег. Но зато быстро всё расскажем и покажем.
1.png (299.08 КБ)
2.png (58.46 КБ)
3.png (112.27 КБ)
 
Если все операции по заказам пронормированы и связаны правильной последовательностью - то можно строить диаграмму ганта орпераций по заказу. Имея несколько таких заказов - можно было бы прогнозировать сроки выполнения заказов с точностью процентов 20-30 наверно.
Конечно всегда будут технологи ошибаться, работники болеть и ходить в отпуска, увольняться и устраиваться, будут вклиниваться срочные заказы от постоянных клиентов, материал не будут привозить вовремя и будет случаться все, что еще обычно случается в наших производствах... Как статистика тут поможет? :)

В целом мне программа нравится. Сколько стоит и длится обучение?

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

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

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

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

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

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

Цитата
Stas Frang написал:
для реал-тайм получения среза по готовности заказов на производстве
Есть. В разных вариантах.

Цитата
Stas Frang написал:
прогнозированию сроков выполнения текщих и новых заказов
Есть "опытный образец" на основе статистики ранее выполненных заказов. Обкатываем с несколькими нашими клиентами пока его.

Цитата
Stas Frang написал:
сбору данных для мотивации персонала - кто сколько и когда сделал, кто перегружен, кто не догружен
Тоже всё есть. В разных вариантах.

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

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

Как статистика будет работать при условии совсем разнотипных заказов? Ну например мы делаем то подъемник гидравлический, то конвеер, то вакуумную камеру, то плазмотрон какой-нибудь - это все металлообработка, но разная. Статистика на основе трудоемкостей, материалоемкости или денег строится? Или штук деталей?
 
Цитата
Stas Frang написал:
То есть, у большинства единичных производств...

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

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

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

Есть и "противоположные" примеры.

Есть у нас клиент, например, у которого в порядке вещей, когда детали (партия) уже физически режутся в цехе, в то время как подробно «просчитаны» там только 1-2 первые операции из 10 в данный момент. Остальные очень примерно и уточняются уже по ходу дела. И ничего… Нормально себя чувствуют абсолютно.

Есть предприятие, где люди вообще в VOGBIT заводят только название изделия и общую трудоёмкость приблизительно. Типа «Установка «Иволга-2» - 1800 н/ч». И всё. И отмечают потом фактические человеко-часы потраченные разными работниками на этот заказ. Какие там операции, станки… Даже узлы и детали не расписывают в базе данных. При этом изделия вполне себе «машиностроительные» и достаточно сложные. Но при всём при том, при таком максимально возможном упрощении, люди используют это в т.ч. как раз для прогнозирования примерного сроков по своим заказам. Приблизительно. И вполне довольны результатами.

Знаю несколько примеров, когда предварительный «просчёт» делают укрупненно. Не расписывая пока по каждой детали подробно. Ориентируясь на быстро доступные характеристики вроде веса, кол-ва деталей, периметра общего их и т.п. Сама методика такого «просчёта» разная конечно, у каждого свои know how. И некоторые, знаю, весьма преуспели на этой ниве. У них получается считать очень быстро и достаточно точно. Потом, уже перед запуском непосредственно в производство, расписывают в программе поподробнее. Но то же нормирование не все используют пооперационное. Некоторые укрупненное нормирование используют.

Есть более тяжелые случаи. Когда на этапе, когда нужно что-то сказать по срокам и цене, при всем желании нечего пока «расписывать» с точки зрения технолога и нормировщика в классическом понимании этого слова. Потому что ни КД нет, ни 3D модели хотя бы. В лучшем случае есть только ТЗ. А то и его нормального нет. Так, «наброски». Тут уж не знаю, как люди прикидывают. Кто по опыту, наверное, кто по аналогу…

В общем, по-разному всё на самом деле у всех.

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

Цитата
Stas Frang написал:
Как статистика будет работать при условии совсем разнотипных заказов? ...

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

Из опыта работы с нашими клиентами я лично могу сделать такое обобщение для себя:

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

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

Например, есть у людей листовой и трубный лазер, гибочники, некоторое количество сварщиков и соответствующее оборудование, окрасочная камера. Вот они и делают всевозможные разные вещи, что на такой "технологической базе" можно сделать. Могут скамейки делать, могут трансформаторные будки, могут остановки автобусные, могут 1000 каких-нибудь железных коробок небольших условно и т.д. и т.п. – какие заказы найдут, то и делают. Всевозможные вещи. Сегодня одно, завтра другое...

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

Но никогда они не будут делать, к примеру, гидроцилиндр. Где технология совсем другая. Другое оборудование нужно, другие компетенции.

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

Или вот другой пример: есть у людей пила, штук 6 токарных центров с ЧПУ, 4 фрезерных, несколько универсальных станочков, несколько слесарей (есть и другое такое же по смыслу примерно предприятие, среди наших тоже клиентов, только раз в 5 побольше). И они делают на них детали различные, сборки небольшие из этих деталей. В основном для других заводов. Но и сторонние разовые заказы тоже берут.

Но опять же, при большой номенклатуре «изделий» (у первых – сотни, у вторых – тысячи разных), всё +- делается технологически одинаково: трубу/прокат режем, точим, если есть необходимость фрезеруем. Могут на термообработку свозить. Могут на фосфатирование какое-нибудь. Да, изделия, а уж тем более детали – разные все. Но делаются все примерно, как выше описано, они.

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

Если предприятия побольше (хотя также встречаются и маленькие, опять же, совсем), то обычно, у них компетенции сосредоточены вокруг какого-то определенного вида продукции. Кто-то медицинское оборудование делает определенного типа. Кто-то краны и подъемные механизмы, кто-то приборы отопления, кто-то металлоконструкции. Бывает, что несколько цехов есть с разной специализацией. Например, у изготовителей торговой мебели если «металлический» цех и «деревянный» (первый: резка проката, трубы, гибка, сварка, окраска; второй: раскрой, кромление, присадка). Те же краны – там есть часть, которая делает большие балки (металлоконструкции, по сути), а есть чисто «машиностроительная» часть, которая делает барабаны, тали и т.п.

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

Никогда, к примеру, производитель больших металлоконструкций не будет делать пресс-форму. Как и наоборот.

Поэтому в плане управления, статистики, прогнозирования и т.п. не так важно ЧТО именно сейчас вы делаете. Конвейер или подъемник, или ещё что-то. Важнее, КАК вы его делаете.

Цитата
Stas Frang написал:
Статистика на основе трудоемкостей, материалоемкости или денег строится? Или штук деталей?

Если говорить о сроках, то на основе трудоемкости.

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

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

Имеем такие сущности, вложенные:

Изделие/Проект -> Деталь -> Операция  -> Станок/Пост -> Исполнитель

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

Почему нельзя всю эту структуру накинуть на календарь, чтобы автоматически получилась диаграмма как в MS Project, какое изделие первое начали производить - те операции и в приоритете? См. вложения. - я для примера картинки создал.  

Да, хвост диаграммы будет скакать, задачи будут сдвигаться, но хоть какая-то картина будет.  Можно планировать.  
Изменено: stas.frang - 13.02.2024 10:15:09
 
Здравствуйте,

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

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

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

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

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

Цитата
написал:
хоть какая-то картина будет.  Можно планировать
Что планировать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как-то так…
 
Спасибо за развернутый ответ.

 
Цитата
Потому что серьезная статистическая база нужна – т.е. полностью внедренная и на 100% хорошо используемая «Производственная часть» программы хотя бы несколько лет.
 Ваш программный продукт я как раз и решил использовать как базу, где мы собираем наш прошлый опыт. За пару лет я набрал статистику, по которой могу оценивать похожие детали с точки зрения фактической длительности операций при изготовлении, и как следствие правильно или неправильно мы их оценили при продаже / плановой оценке трудоемкости. Где мы сильно выбились из цены - мы смотрим почему так случилось и как этого избежать. В итоге получилось крайне полезно, за что вам спасибо большое. :)
 Мы продаем не детали, а ОПЕРАЦИИ, поэтому я наладил их учет... что-то в этом роде.

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

 Проблема планирования в моем производстве стоит достаточно остро, потому что мы делаем индивидуальные изделия или комплекты, то есть у нас как бы проекты по изготовлению, требующие проектного управления. При этом изготовление длится 2-4, а то и 6 месяцев. Новые заказы затыкают свободные мощности сегодня, и в ближайшем будущем. То есть не обязательно, что если вы закажете сегодня, получите заказ миниму через 2 месяца от текущей даты. Скорее всего какую-то мелочь мы сделаем между делом.
  Поэтому я хочу наглядно видеть некую очередь, которая в реальном времени от поступивших заказов как-то живет. Понятно что куда сдвинулось, что недогружено, что перегружено. Что изменилось если мы вклинили новый мелкий заказ какой-то... и т.д.
  Более того - на основе этого можно сделать уже систему мотивации персонала, привязанную к результатам.
  Не знаю, может кто-то из сообщества тоже выскажет свое мнение, хорошая это возможность или нет? :)

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

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

Есть раздел на форуме. Там примеры использования API.
Если будете писать сами, и вопрос в том, как добыть нужные данные, то пишите туда. Подскажем, где что лежит в терминах базовых объектов VOGBIT (номенклатура, параметры, связанные объекты, коллекции, компоненты, task'и и т.п.). А дальше уже через API добывайте это и обрабатывайте своей программой.
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 4000
Приняло участие в обсуждении: 415
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт