Рифы очень просто вводятся в расчет аргументами. Вот у меня была та же проблема, никто из яхтсменов не мог объяснить почему они так делают. Я сперва поучился у них, а когда начал хоть как то чувствовать — выразил это математически. Вот тогда все понял и теперь могу объяснить.
:-) неправда! для каждой лодки углы свои. Парус 11.25 значит у него малый аэродинамический коэфф. Ау<=3. Это значит что мачта низкая. Корпус 22.5 значит яхта узкая и длинная — наверно спортивная. И похоже, что это швертбот.
Конечно сравнивал — зачем же писать непроверенные теории?.. Мало того — написал приложение для телефона, которое как раз реализует этот алгоритм. Для измерений используется компас и gps для определения скорости и реального направления. Телефон ориентируется в направлении ощущаемого ветра (вымпельного). Далее вычисляется оптимальный курс, установка парусов и прочее. Но тут все испортила точность гражданского gps — но это отдельная история. И история неудачная — потому о ней не пишу.
Почти полностью согласен с Вашим мнением! Именно академический интерес и отсутствие бюджета в тот момент, как я и написал, было основной причиной. Сейчас идет модернизация — об этом будет скоро отдельная статья. И про подвесник там тоже будет — в моем случае это не вариант. Уже пробовали.
Класс! Уже читал где-то про подобную. Примерно на эту тему будет статья, это будет «третий сезон». Не успеваю сразу много писать. Но, в любом случае, во-первых, у меня не лаборатория и нужна свободная обитаемая поверхность. Солнечные батареи очень горячие — не полежишь на них. А во-вторых, парус это очень интересно, об этом будет статья «второй сезон». Только ошибочки поправлю и в публикацию.
Да, яхту строили на верфи под моим пристальным приглядом. Научный подход — так я же физик, и мои навыки в современной России не востребованы. Вот и приходится развлекать себя самому. Ради этого все и делается. Вот на новогодние праздники запланировал написать серию из четырех связанных статей. Это первая. Вторая будет чисто физическая, про цифровую модель яхты. Третья про модернизацию. И четвертую я отдал соавтору — дочке. Она напишет о новом яхтенном контроллере солнечных батарей.
Вы пишите интересные комментарии, но они выходят за рамки статьи. Ваши вопросы на тему как мы это сделали. Это тема отдельной статьи или разговора. Если это действительно интересно, может лучше в личку? А то мы в комментариях напишем еще одну статью :-) Возможно документ по этой ссылке ответит Вам на многие вопросы, остальное готов ответить сам.
Готов согласится, что я плохой писатель. Не смог донести мысль. Поддержка руководства как раз есть, как и все остальное. И синхронизация, и планирование, и обеспеченность заказов, и покрытие всех участков. И эффект не в ускорении локальных участков, а изменении принципа работы всего завода от «на склад, а потом продавать» до «сперва продать, а потом производить и точно в срок»
Наличие неконтролируемого запаса полуфабрикатов в цеху позволяет некоторым лицам в любой момент выпускать небольшие партии продукции «налево». Не могу утверждать, но мне кажется, что именно для этой цели было отменено прослеживание и именно это стало главной точкой противодействия внедрению со стороны среднего менеджерского звена.
Вы правы! Я нарочно назвал ПДОшника планировщиком, потому что в текущем бизнес-процессе на заводе планированием занимается мастер в цеху. Заказчику ПДО так и не удалось создать за время внедрения mes :-(.
Технолог… ага! только он в цеху не был ни разу.
Только не путайте компанию-внедренца и завод. Мы не можем создать на заводе подразделения и новые штатные единицы, если их нет.
Все именно так и сделано. Это и есть основное разочарование Заказчика. Они то думали, когда начинали проект, что нажмут кнопку «УПРАВЛЯЙ» и все остальное система будет делать сама. А оказалось, чт надо как минимум раз в день, а то и чаще заниматься корректировкой планов :-). На заводе просто нет людей, которые могут это делать.
1. время операций действительно можно указать до секунд, но вижу в этом смысла — согласен с Вами. Это время указывается для планирования, но в системе есть обратная связь — мы видим факт и комментарии отклонения от плана.
2. mes, в отличие от erp, планирует детально, но на небольшой промежуток времени (дни). Это делается как раз для того, чтобы не планировать на месяц, а работать под заказ с короткими заказами (длительностью от часа до суток). Именно для этого система и внедрялась. конечно процесс управления производством тут меняется в корне.
3. Переналадка не длительная, максимум несколько часов. Объединение заказов происходит не по этой причине. Тут так логически построено производство, что есть детали общего назначения, есть имеющие одно измерение (длина), есть имеющие два (длина и бренд или ширина), и есть имеющие более двух. У каждого типа деталей своя переналадка — не синхронно. Если время переналадки примерно соизмеримо прохождению короткого заказа, то логично объединять заказы для уменьшения таких переналадок раздельно.
В статье указано, что выбрали СКАЗ — продукт разработан нами на основе польской qcadoo с открытым кодом, но рассматривались для внедрения честно очень многие. продукт выбрали не потому что он был наш, а именно потому что можно организовать полный цикл управления с обратной связью.
По 1С, просто на предприятии в 1С нормального классификатора не было — его сделали, полуфабрикаты можно — но нужно ли?
Технолог… ага! только он в цеху не был ни разу.
Только не путайте компанию-внедренца и завод. Мы не можем создать на заводе подразделения и новые штатные единицы, если их нет.
2. mes, в отличие от erp, планирует детально, но на небольшой промежуток времени (дни). Это делается как раз для того, чтобы не планировать на месяц, а работать под заказ с короткими заказами (длительностью от часа до суток). Именно для этого система и внедрялась. конечно процесс управления производством тут меняется в корне.
3. Переналадка не длительная, максимум несколько часов. Объединение заказов происходит не по этой причине. Тут так логически построено производство, что есть детали общего назначения, есть имеющие одно измерение (длина), есть имеющие два (длина и бренд или ширина), и есть имеющие более двух. У каждого типа деталей своя переналадка — не синхронно. Если время переналадки примерно соизмеримо прохождению короткого заказа, то логично объединять заказы для уменьшения таких переналадок раздельно.
По 1С, просто на предприятии в 1С нормального классификатора не было — его сделали, полуфабрикаты можно — но нужно ли?