Необходимо сравнить эти два решения в таком разрезе:
- бухгалтерский и налоговый учет
- бюджетирование
- планирование (в т.ч. производства)
- поддержка разработчиком при изменениях налогового законодательства и ПБУ
Есть те, кто знаком одновременно с двумя этими решениями?

Ты б для начала уточнил, какое решение ИТРП

(1)+ И что (какое предприятие) автоматизировать будем

бери УПП. Там ошибок меньше.

#1 ИТРП: Производственное предприятие 8 Стандарт
#2 Производство

(0) [Есть те, кто знаком одновременно с двумя этими решениями]
разве что Игорь Бурьяненко

(4) Производство чего???

(0) У ИТРП есть бухия + бюджетирования на основе БП 2.0 - намного круче, чем то же самое в УПП. В остальном - смотря какое производство...

(6) машиностроение, многопеределка

(7) интересует сравнение ИТРП:Производственное предприятие 8 Стандарт vs. 1С:Управление производственным предприятием
причем из "коробки"

есть еще 1с:Машиностроение

(8) Тогда однозначно ИТРП. ИТРП и писалась как система под Машиностроение

(10)в курсе, но не все оттуда нужно
(11)вопрос про бухгалтерию, бюджетирование и поддержку остается открытым

УПП тестируют тысячи, ИТРП десятки - разница есть ?

(13) Фариту раскажи, какое ИТРП г-но)).

(13) дело в том что я имел опыт работы с ИТРП. У меня есть мнение - очень негативное.

(15) Я тоже имел неоднократное, еще начиная с семерошного в 2002 году. Весьма неплохое за некоторых видов производств

а можно без холивара?
насколько хорошо реализованы бухгалтерия и бюджетирование в ИТРП:"Производственное предприятие 8 Стандарт" из коробки?
если уж производство разбирать по полочкам, то где очевидные преимущества в функционале у ИТРП:"Производственное предприятие 8 Стандарт" перед 1С:УПП 8.2, и опять таки, из коробки?

(17) Хорошо реализованы

(17) в ИТРП РАУЗа нет. Производство какое ?

(18) Никаких плюсов ИТРП перед УПП не вижу. Просвятите...

ИТРП процессное производство не особо качественный продукт. Функционала море, но и глюков много.

(19) Гораздо "легче"
(20) Разговор не о этой конфиге

(14) а что там Фарит ? Имеет какие то связи с ИТРП ? Хвалит или ругает ... я не понял

(22) Вообщето он долгое время работал в ИТРП. Я у него на курсах был в 2003 годупо ИТРП:ПРОФ, еще семерошном.

(23) 7.7 ИТРП вроде как был качественный продукт, а вот 8ка...

(24) Восьмерошный тож весьма, в 2007 серьезно думали что внедрять, семорошный или восьмерошный, в итоге правда выбрали семерошный, но лишь потому что он был уже куплен

(18) именно в конфигурации  ИТРП:"Производственное предприятие 8?

(26) Да. Процессное производство не видел вообще, поэтому его комментировать не могу

Сначала выбираем автоматизатора. он предлагает инструмент. Если автоматизатор внутренний отдел АСУП, то я бы вместо флуда на мисте предложил попросить вебинар по каждому из продуктов. Вот и все

(28) У кого просить собрался? По УПП у 1С? Пошлют в пешое эротическое. Да и ИТРП немногие "автоматизаторы" знают

(29) ИТРП - у разработчика. УПП- у того ЦКП, кто имеет подобные внедрения

(30) ИТРП вроде как не делает такого - просили в свое время

(31) Не делают- посылать. Я делаю, а им в лом? Я слушал ИТРП, правда на мероприятии

(32) Ну у тебя видимо не такое количество клиентов, как у ИТРП)

(18) не совсем понятно, на чем основано мнение
мнение пользователей говорит, что решение из коробки жутко сырое, полноценного бухучета нет, бюджетирования нет вообще
в чем проблема: само решение такое или автоматизаторы от ИТРП?
(33) у ИТРП автоматизированных мест на порядок меньше, чем у УПП
еще раз вопрос: что такового супер в ИТРП, что стоит париться с ней?

(34) Парится будешь с УПП, ибо потворюсь УПП более громозкий и неповоротливый

(34)у ИТРП автоматизированных мест меньше даже на два-три порядка, чем у УПП

(36) Это типа показатель? Только сегодня слышал фразу от одного из франчей - "с партнерскими решениями не работаем по определению". Может изза этого?

(35) "громозкий и неповоротливый" не аргумент, функционал важен

(37) показатель - это функционал
перечислите важные различия, что бы можно было проверить на обеих системах
насчет бухучета и бюджетирования (34) опровержения будут?

(37) Некоррректно! ИТРП позиционирует свои решения как альтернативу УПП, например. Они плывут против течения. Это одна из причин, почему мы никогда не будем это внедрять. Хотя они мне симпатичны. Но так уже не танцуют. Неумно

(37) партнерские решения это 1с:Совместимо имеются в виду?

(39) Мнение каких пользователей? Бухучет он и в африке бухучет, все для этого есть. А бюджетирование - связка ИТРП Стандарт и ИТРП:Бюджетирование и финансы.
(40) Ниче что ИТРП стопроцентная дочка 1С? Сидят в одном дворе.
(41) Да

(0) Порядок есть на предприятии?
Технология (станки, производственные линии, операции и тех.карты есть? Учет в цехах налажен? Нормативы потребления есть? Планирование помесячное? Выполнение плана на сколько (60-70)?
Если на все ответы да, то пофиг что брать, если чего-то нет, то возьмите сначала БП или КА и наведите порядок, а потом уже бюджеты и т.д.

(42)Адрес - это веский аргумент, но насколько мне известно, все партнеры, в которых есть доля 1с имеют в своем имени это название. Таковые Рарус, ВДГБ и прочие. Но даже если это действительно так, все равно Процессное производство - это попытка альтернативы УПП.
(41) И Совместно. Причем Совместно много серьезнее.

(43) все нормально, производство относительно несложное, все и так без всяких ИТРП и УПП работает)

(44) Это типа партнеры долей 1С, теперь все за 1С пропорционально доли делают?

Странный холивар

>>
УПП - В проектировании и разработке конфигурации участвовали специалисты компаний "ИТРП" (управление производством) и "1С-Рарус" (учет по МСФО).

УПП как раз и было продолжением семерочного ИТРП

(47) Это медицинский факт. И тем не менее

(42) "Бухучет он и в африке бухучет, все для этого есть"
все, что есть в УПП по бухучету, есть ли в ИТРП? как быстро приходят обновления при изменениях НК и ПБУ?

(50) http://forum.itrp.ru/viewforum.php?f=2&sid=465ce4539f781b2b9df16f05aba9f9d2

(50) Учитывайте, что и в УПП и в ИТРП бух.учет является второстепенной сущностью, т.е. никакой, то лучший бух.учет в БП. Если нужны БП и бюджетирование и фин.планирование - то ИТРП:Бюджетирование и финансы самое то...

(51) это в достоинства или в недостатки, я затрудняюсь
(52) насчет вторичности бухучета в ИТРП мнение сложилось, насчет УПП вы однозначно неправы

(53) Насчет вторичности БУ в ИТРП 8 пожалуй таки соглашусь.
П.С. Недавно узнал, что как минимум в двух крупных конторах ИТРП 7.7 жив. И в обоих для бухучета, при том что разработчиком не поддерживается лет 6

(54) про 7.7 никто не говорит

надо понимать, что "ИТРП:Производственное предприятие 8 Стандарт" из коробки все таки голый и для полноценного бухучета и бюджетирования надо ставить дополнительные конфигурации?
походу возникает вопрос: а что в этом ИТРП лучше тогда по сравнению с УПП в части производства? что конкретно позволяет решать ИТРП из коробки по сравнению с тем же коробочным УПП?

(56)*речь про последние версии ИТРП:Производственное предприятие и 1С:УПП

(56)
1.вы на предприятии кто? программист?
2.Что именно вы ожидаете от программы
3.см (11)

(58)
1.Сторонний наблюдатель
2.Что бы работала и все сотрудники были довольны результатом без постоянного подкручивания отваливающихся частей при обновлениях или переделках.
3.Насчет однозначности про ИТРП есть большие сомнения, ибо:
-из коробки сырой
-нормального бухучета нет
-бюджетирования нет совсем
*установлено опытным путем и в ходе обсуждения
если 1С:Машиностроение (допускаю опечатку в ссылке), то вариант рассматривается под №3

(59) Что мешает позвать авторитетный ЦКП для презентации 1С:Машиностроения??

(60) религия)

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

А по производству есть мнение, что в УПП оно списывалось с ИТРП с обкаткой на клиентах с машиностроительной отраслевой спецификой. Насколько они сейчас "разбежались" - сейчас не сравнивал.

(61) Тогда я догадываюсь, кто вы. Мдя!!!

(63)о как, ну, догадываться не запрещено)
ошибаться тоже

(64) Я думаю, что вы внешний автоматизатор. А это может быть фри или мелкий франч.

(65) хоть это и офф, но правильные слова "фри" и "мелкий", остальное неверно)

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

(67)  считается, что они обладают достаточной квалификацией
- Это фантастика :-)

(68) если сотрудники выполняют свою работу без "распальцованных" учеток типа ИТРП или УПП, бизнес развивается, надо думать, что они все же достаточно квалифицированы
это учетки для пользователей, а не пользователи для учеток, вообще то

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

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

(70)очень часто автоматизаторы преувеличивают возможности систем из коробки, декларируя что там есть все что нужно, во тогда точно внедреж саботируется

По опыту работы с ИТРП на 8.
(42) "ИТРП:Производственное предприятие стандарт" - бюджетирования нет!
"ИТРП:Процессное производство" - бюджетирование есть, такое же как в ИТРП:Бюджетирование и финансы.
Это абсолютно разные конфигурации по задачам и функционалу, и нет смысла обсуждать просто "ИТРП".
Бухгалтерия в Проц.пр-ве не лучше и не хуже чем в УПП. Но несколько другая, в ней много чего есть для управленческого учета а не только для бухгалтерии.
Бухи работают и особых претензий не имеют, сначала жаловались на сложный интерфейс, после БП8. Насчет ИТРП-Стандарта не знаю.
Регламентированная отчетность от Бухгалтерии 1.6 и от УПП, адаптированная.
Обновления регл.учета выходят на неделю позже чем в УПП.
Ошибки встречаются как и в любом продукте, но исправляются за 10 дней максимум. Сейчас ошибок стало гораздо меньше. Скорость работы повыше чем в УПП.
(19)Насчет функциональности Проц.пр-ва - есть много того что нет в УПП. В т.ч. нормальное планирование производства. На сайте ИТРП вся инфа, проникнитесь.

(72) про "ИТРП:Процессное производство" речь не заходила, про эту конфигурацию в курсе, про заявленный функционал тоже в курсе, хотя иметь дело напрямую не приходилось в отличии от "ИТРП:Производственное предприятие стандарт", которая вызвала недоумение
планирование - отдельная песня, надо смотреть, лучше на демке, а не просто инфу на сайте, тогда и проникнусь

Если интересует функционал ИТРП:ПП Стандарт 8, закажите презентацию в фирме (на нашем сайте есть контакты www.itrp.ru).
Бухгалтерия в этой конфигурации есть (в полном объеме, до получения рег.отчнтности), но если нужна просто бухгалтерия, то покупайте типовую бухгалтерию 1С  - это и проще, и дешевле.
Бюджетирования нет, кроме документов по планированию ДС (заявки на расход, закрытие заявок, платежный календарь и кое-что еще). Есть вариант конфигурации с подключенным бюджетированием из Процессного, но вариант сырой.
ИТРП:Стандарт - это производственная программа. Могут работать конструкторы, технологи, диспетчера - ввод спецификаций, маршрутов изготовления, тарифов и т.д; нарядов заданий и др. производственных документов. Плюс учет заводских номеров, переработка, планирование потребностей в ТМЦ, оборудовании, профессиях и т.д.

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

Был на днях на курсах по внедрению брикетирования у Абрамовой - она с точки зрения финансиста из 1С-ских поделок рекомендовала ИТАН и ИТРП.

брикетирования = бюджетирования ))

Можем дать контакты клиентов, которые работают на ИТРП, естественно, с их разрешения.

(76) Мне кажется все таки у ИТПР и у Итана  разные достаточно продукты, хотя бы потому, что они являются партнерами, причем близкими, рах пиарят друг друга на своих сайтах. Если бы бы были б конкурентами - не пиарили б

В ИТРП бюджетирование - нельзя подключаться к внешним базам в отличие от Итана. Факт берется только из той базы в которую встроена конфа. А Итан больше для сбора данных с любых разнородных баз, консолидации и упр. учета, а ИТРП - для бюджетирования в одной базе.

(78) да, интересно, как решаются задачи бухучета, бюджетирования и планирования в "ИТРП:Производственное предприятие стандарт" из коробки

Бухгалтерия в ИТРП:Стандарт похожа на типовую, по крайней мере внешне. Но в ИТРП 3 плана счетов: БУ, НУ,УУ. Документы могут проводиться или по БУ +НУ, либо только по УУ. Можно отключить НУ. Взаиморасчеты - автоматически определяются субсчета (есть регистры взаиморасчетов), НДС  - 2 регистра НДС покупки, НДС продажи. Есть документы "Формирование записей книги покупок" и "... продаж". Рег.отчетность - берем из типовой.
Бюджетирование - см.выше.
Планирование - только расчет потребностей. Без оптимизации загрузки оборудования. Исходные данные - маршруты (список ТМЦ, любое количество уровней, из практики - обычно около 10), плюс нормы времени и количество исполнителей с указанием их тарифов (для дальнейшего расчета сдельно ЗП); остатки на складах и в производстве, страховые запасы и заделы, заказы поставщикам, графики работы оборудования, графики работы подразделений.
План производства - объемнокалендарный - операция планировани-перепланирования(разузловка). Т.е. планирование фактически это постоянное перепланирование. Поэтому еще есть внешние обработки по планированию, т.е. расчет аварийного дефицита с учетом текущих остатков.

(82) а в "ИТРП:Процессное производство" есть возможность выполнять планирование с учетом загрузки ресурсов? есть возможность приостановить выпуск одних изделий что бы освободить ресурс для выпуска других?можно сверхрочную загрузку временно вводить и проводить выравнивание загрузки ресурсов?
и еще: есть в ИТРП:Производственное предприятие стандарт возможность фактическую себестоимость изделий считать с учетом всех фактически понесенных затрат?

ИТРП, УПП , херня . Берите "CRM: Росатом".

(0) В свое время у одного клиента столкнулся с ИТРП на 7.7. Оставило тягостное ощущение по сравнению с ПУБ. НУ там практически не было, глючков было многовато. Но решение как таковое понравилось, подход интересен. Думаю, что сравнение осталось качественно тем же, т.е. УПП v ИТРП. Я бы выбрал УПП и взяв его за основу, не спеша допиливал бы под свои требования.

В "ИТРП:Процессное производство" планирование более функционально, чем в Стандарте. Сейчас разрабатывается новая версия с учетом опыта внедрений. Что войдет в коробку, пока не могу сказать. Но отменять выполнение каких-то заказов можно было и в текущей версии.
В конце декабря можно будет посмотреть на демо-базе.
Загрузка оборудования в Стандарте тоже учитывается: есть график работы оборудования (или группы), есть норма времени на каждую техоперацию, есть привязка каждой техоперации к оборудованию (или группе), есть план. Операция планирования рассчитывает загрузку по текущему плану (или заказу) на данное оборудование (или группу) и сколько есть по графику. И выдает отчет  - "по данной группе дефицит столько-то". Управленческое решение принимается диспетчером.

По поводу Росатома. Тоже не все есть. Особеннно в плане маршрутов (спецификаций).

(86) планирование в Стандарте есть с учетом загрузки или нет (82)? или нет оптимизации?

(86)Насколько я знаю в Стандарте можно посмотреть в отчете - какая загрузка оборудования требуется для выполнения плана. Какя получилась перегрузка по мощностям.  План разузловывается только с учетом времени операций без оптимизации загрузки и без поиска свободного времени оборудования.
(83)В Процессном при разузловке присходит поиск свободного времени и задания назначаются только на еще незанятое время, при этом идет оптимизация по времени переналадки. Остановка выпуска одних изделий для запуска других это уже блок диспетчеризации который позволяет запускать любые отклонения от начального плана

В Стандарте можно рассчитать  загрузку оборудования.
График запуска-выпуска тоже есть. Но при создании этого алгоритма сразу было задано условие - как именно распределить потребность по конкретным станкам должен определить диспетчер. С учетом  поломанного, заболевшего, не вышедшего на работу , или наоборот, не дозагруженного.

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

(89) т.е. если я ставлю в очередь на производство новые позиции, мне надо самостоятельно определить, когда возможен запуск, а когда завершение, Стандарт мне это не посчитает?

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

(91) что то не совсем понятно, поясню, что требуется:
- поступил новый заказ из нескольких позиций
- нужно рассчитать возможные дату и сроки выпуска продукции в заказе
- если не устраивают рассчитанные сроки, то подвигать открытые позиции уже размещенных заказов и рассчитать сроки заново
- и так далее, пока все не устроит
такие возможности есть в ИТРП:Стандарт или надо что то другое смотреть?

(91) что то не совсем понятно, поясню, что требуется:
- поступил новый заказ из нескольких позиций
- нужно рассчитать возможные дату и сроки выпуска
- если не устраивают рассчитанные сроки, то "подвигать" открытые позиции уже размещенных заказов и рассчитать сроки заново
- и так далее, пока все не устроит
такие возможности есть в ИТРП:Стандарт или надо что то другое смотреть?

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

(94) что же все так грустно с ресурсным планированием в решениях на 1С?
вручную то хоть можно двигать заказы или отдельные производственные этапы внутри заказов с онлайн пересчетом сроков с учетом загрузки ресурсов (трудовые и оборудование)?

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

(91),(96) а как в ИТРП обстоят дела с визуализацией плана производства и загрузки ресурсов? это таблица или графика? можно где нибудь скриншот посмотреть?
желательно, конечно, видеть план в разрезе открытых заказов и детально по каждой позиции заказа, что бы можно было прямо из этого интерфейса "двигать"

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

Это 2 практически одинаковых продукта. УПП для 1С пишет ИТРП. Так что брать вопрос религии.

(100)!

(99)[Это 2 практически одинаковых продукта. УПП для 1С пишет ИТРП.]
думаешь шеф-повар кормит своих друзей тем же, чем травит посетителей ресторации ?

(98) "ИТРП Процессное производство есть диаграмма ганта загрузки оборудования"
в УПП тоже такая шняга есть, только толку мало, проще заказ в MS Project кидать и там крутить
(98) "Скриншоты наверное есть на сайте ИТРП"
чета нету, может искал плохо? *задумался*
(98) "ИТРП давно обещают вторую версию планирования"
интересно было бы посмотреть
(99) неодинаковые, проверялось

(99)УПП и ИТРП даже близко не похожи, ни одной формой, ни одним регистром. Разве что регламетированая отчетность и отчеты по бухрегистру.
(101) Кто там для кого пишет хз, мож индусы пишут какая разница. А откуда такие домыслы что ИТРП пишет УПП?

(102) так толку мало потому что двигать нельзя, в ИТРП тоже нельзя. Можно только посмотреть что программа сгенерила, красивая картинка. Но в ИТРП она более информативная чем в УПП.

(104) ох уж эти движения регистров....
а картинку хочется посмотреть, особенно, если можно фильтры устанавливать и разворачивать ака MS Project

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

ИТРП Процессное производство:
http://itrp.ru/downloads/itrp8proc/request.php?frompage1='http://www.itrp.ru/content/production/proc8.php'

Стандарт:
http://itrp.ru/downloads/stand80/request.php?frompage1='http://www.itrp.ru/content/production/proc8.php'

(103) Это не домыслы, а так сказать ситуация де-факто.

(106) о, точно, надо анкету заполнять
непонятно, что там прятать то?

раньше там методички и видеоуроки бесплатные были для своих клиентов

(107) чеит сильно ИТРП и УПП различаются чтоб поверить в это

(109) старенький материал какой то и примеры гастрономические... (((

котлеты и салаты?

(112)ага
интереснее было бы синхронизацию производства основной продукции и полуфабрикатов в планировании увидеть в таких примерах

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

(114) посменный план есть и в УПП, только он странно формируется:
если есть, к примеру, 9 женщин, то на выходе через 9 месяцев можно ожидать 9 младенцев
а УПП же считает, что эти 9 женщин каждый месяц по младенцу приносить будут )))
все, конечно, переписывается, но в решении из коробки такой вот подход

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

(116) "В УПП планирование производства работает по видимому только на специально подогнанной демке, при вводе реальных данных система в нашем случае обрушилась и выдала хрень. Так было год назад, сейчас не знаю"
в "ИТРП:Стандарт" даже под руководством спецов из ИТРП планирование не завелось, увы )))

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

(117) Что планировали то?

(117) производство запланировать пытались, мелкосерийное, заказное

(118) не факт, что в ИТРП:Стандарт планирование правильное, ибо прочих ошибок "в коробке" было прилично
по крайней мере, результат получен не был, а в его отсутствии сложно что то обсуждать

Я знаю SAP пытались внедрять на нефтехимии, так у них планирование не заработало и переписали все нафиг. Правда после этого тоже не заработало, чем закончился проект неизвестно (. Что значит результат не был получен? Неправильный результат выдавала в рамках заявленной функциональности, не понравилась юзерам, или валилась из-за ошибок?

"не факт, что в ИТРП:Стандарт планирование правильное"

Что понимать под правильным планированием? В Стандарте планируется правильно, т.е. программа правильно выполнит разузлование, учтет остатки на складе и в производстве, страховые запасы и заделы. Правильно рассчитает потребности.
Управлять этими "правильно рассчитанными" потребностями придется вручную.
Механизма, который позволяет "передвигать" загрузку оборудования, нет.

На практике часто используют внешние обработки, которые анализируют текущие остатки и рассчитывают потребности по конкретному заказу. Так называемый "аварийный дефицит". Уже при оформлении заказа можно получить дефицит по материалам и общую потребность в профессиях и оборудовании. Данные разузловки выводятся в табличную часть (можно сортировать, отбирать по любой колонке). Например, можно отобрать все техоперации с одинаковым названием и увидеть общую трудоемкость по этой ТО.

(122) план выпуска исходя из загрузки ресурсов получен не был, как выяснилось из темы, этого и предусмотрено не было в ИТРП:Стандарт
(123) разузловывание и расчет страховых запасов есть и в УПП, к тому же, там есть еще и полноценная бухгалтерия, и какое никакое бюджетирование
без учета загрузки планирования нет, это уже "недопланирование" какое то

Планирование производства не сводится к просто разузловке, это и пионер может сделать на уроке информатики. Расчет страховых запасов это вообще сервис, можно это в екселе делать,  и к базовым механизмам не относится. Для того чтобы план был реальный и корректный надо учитывать множество производственных параметров. Например, входящие остатки и неснижаемый остаток, переналадки, совыпуски, связки оборудования трудопроводами, время переходов между техпроцессами и время стабилизации до выхода на нужное качество продукта, цикличность работы оборудования, переменную мощность оборудования, разные единицы учета на складе и в производстве и еще кучу всего. А в УПП даже понятия расцеховки нет и марщрутов обработки по цехам. Что в ней есть из вышеперечисленного? Попробуйте это технологам на машиностроении/приборке впарить, без допиливания.
(124) Стандарт показывает загрузку оборудования которая получилась при планирования но не оптимизирует ее. Это обычный MRP, и для простейших задач. Сравнивать УПП и Стандарт все равно что самолет с автомобилем, имхо некорректно. Хотя лучше потихоньку ездить чем взлететь и убиться )
Сравнивать надо с Проц.пр-вом, здесь весовые категории одинаковые.

(124) Расчет плана выпуска исходя из наличия имеющихся ресурсов, их загрузки - эта задача обратная MRP, и точного решения не имеет ибо в ней действует много неопределенностей.
Автокорректировка уже заданного плана выпуска исходя из доступности ресурсов - это APS, и никак не MRP и уж тем более не Стандарт и не УПП. APS есть в самых крутых западных системах, 1С-у еще дорасти до этого.
Хотя, допиливанием опять же много частных задач в этом направлении можно решить, главное чтобы в системе была корректная производственнная модель и расчет графиков был  корректным в рамках той функциональности которая заявлена.

"Планирование производства не сводится к просто разузловке, это и пионер может сделать на уроке информатики"

В Стандарте как раз и учитывается множество факторов при разузловке: текущие остатки, страховые запасы и заделы, партии запуска/выпуска, нормы времени, подготовительно-заключительное время, графики работы оборудования и т.д.
Причем остатки учитываются на каждом переделе - текущий остаток по любой позиции постоянно меняется с учетом уже "распланированной потребности" (также с уже "распланированной загрузкой оборудования").
Например, на складе есть 100 шт. "болт d15". Эта позиция используется при сборе детали Д1 (35 * 2 = 70 шт.) и полуфабриката ПФ10 (5 * 10 = 50 шт). При разузловке программа учтет остатки Д1, ПФ10 и Болт D15. Если остаток по Д1 = 0, то программа "зарезервирует" все 70 шт болтов под выпуск 2 шт Д1. Отсаток по болтам в этот момент станет = 30 шт.
Далее планируем выпуск ПФ10. Если остаток по этой позиции  = 5 шт, то программа вообще не будет резервировать болты для этого ПФ, так как еге нужно выпускать. Если остаток ПФ10 = 0, то дефицит по болтам составит 20 шт.

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

"без учета загрузки планирования нет, это уже "недопланирование" какое т0"

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

(125) "Стандарт показывает загрузку оборудования которая получилась при планирования"
(129) "В Стандарте есть учет загрузки оборудования"
а что тогда тут? (94):
"Стандарт - это обычная MRP система без наворотов. Расчет срока выполнения заказов можно в такой системе дописать, при условии что все плановые операции планируются в разрезе заказов."
мне же итоговая загрузка не сильно нужна, нужна ожидаемая рассчитанная дата начала и завершения производства нового заказа с учетом загрузки имеющегося оборудования и людей!
если не устраивает, использую APS

(130) Это издержки русского языка.
"Учет загрузки оборудования" - значит что в процессе планирования программа смотрит на оборудование и если оно загружено в некоторую смену то планирует загрузку на другую смену. Это есть в ИТРП Процессном и УПП и этого нет в Стандарте. Это часть методологии APS.
И во всех системах "есть определение потребности посменно в рабочем времени оборудования" Это то что в (125). Это MRP (или что-то типа RCP не помню но часть MRP).
Расчет срока выполнения заказа в APS - сразу при вводе заказа, онлайн. При этом программа сразу планирует всю разузловку от заказа, накладывая ее на уже имеющиеся операции. Если натыкается на ограничения (нет свободного времени оборудования, материалов и т.д.) то двигает заказ вперед и снова разузловывает и т.д. пока все ограничения производства не будут сняты. Как пример ortems, на сайте хорошо все расписано.
Но и в MRP системе такой бизнес-процесс можно выстроить. Менеджер принимает заказ, ставит у него статус "Проект". ПДО один раз в день делает полное перепланирование и смотрит возникла ли перегрузка по заказам принятым сегодня в статусе "проект". Если возникла - двигает заказы вперед (у нас для этого есть обработка которая сообщает какие заказы и на сколько надо подвинуть) и снова планирует. И так несколько раз пока перегрузка не изчезнет. После этого заказы переводятся ПДО в статус "Открыт", и менеджер продаж сообщает клиентам дату отгрузки открытых заказов.
Итого ПДО решает когда делать заказы а не система или менеджер продаж. Клиент получает дату отгрузки не мгновенно а например через день. Это правильно потому что есть неформализованные моменты которые знает только ПДО. Не факт что ПДО согласится чтобы система сама раскидывала по производству заказы без их ведома.

(131) иными словами, диспетчер ручками двигает заказ вперед, проводит полное перепланирование, и так до тех пор, пока система не выдаст, что перегрузки отсутствуют?

да, только не один заказ а сразу все размещает предположительно по рекомендациям системы. Не ручками а флажками подтверждает что рекомендация системы (новая дата заказа) принята, или если захочет - сам корректирует дату заказа. Потом перепланирует и смотрит результат. Если перегрузка то система снова предлагает такие-то заказы подвинуть. Обычно хватает 2-3 итерации. Можно пойти дальше и сделать так что система сама себе будет подтверждать и перепланировать. Но до такого творчества не дошло.

(133) "Не ручками а флажками подтверждает что рекомендация системы (новая дата заказа) принята, или если захочет - сам корректирует дату заказа"
но это, надо понимать, ваша обработка уже делает, не штатный функционал?

наша обработка

(135) спасибо за обсуждение
в общем то, что и требовалось понять

"в процессе планирования программа смотрит на оборудование и если оно загружено в некоторую смену то планирует загрузку на другую смену. Это есть в ИТРП Процессном и УПП и этого нет в Стандарте."

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

(137) а как будет происходить планирование в ИТРП:Стандарт в таком случае?:
- есть производственный план
- пришел новый производственный заказ
- необходимо рассчитать сроки производства по этому заказу с учетом загрузки оборудования
варианты (упрощенно):
1) предыдущий производственный план будет удален и планирование будет выполнено заново, и так каждый день
2) будут рассчитаны сроки освобождения оборудования, необходимого для выполнения каждой позиции в заказе исходя из маршрута и затем будет выполнено назначение оборудования позициям заказа в каких то там регистрах

Планирование в Стандарте работает не по производственному плану, а по объемно-календарному (ОКП), т.е. по плану, в котором уже указаны сроки выпуска продукции.
В случае нового производственного заказа можно скорретировать объемно-календарный план (есть спец.документ), затем сформировать очередной документ "Операция планирования /перепланирования", в котором задать новую дату планирования (дата начала периода остается прежней). С этой даты произойдет перепланирование (т.е. расчет потребностей), до этой даты все останется без изменения.
Можно не создавать новую операцию планирования. Изменить сам ОКП и перепровести операцию планирования. Тогда план пересчитает потребности на весь период.
Напомню, последовательность:
производственный план -> ОКП(один или с корректирующими документами) -> Операция планирования/перепланирования(одна или несколько) ()

(139) и какой результат в итоге будет получен:
- реальная дата завершения производства по новому заказу без перегрузок оборудования?
- какая то дата завершения производства и перегрузки оборудования?

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

Насколько я понял Стандарт ищет свободное время оборудования под любую потребность в нескольких сменах. Поиск ведется от даты потребности назад по времени до тех пор пока требуемое время операции не распределится по сменам, по ставшемуся свободному времени работы оборудования?

Кстати, существуют специальные примочки к УПП в части планирования производства. Партнерская разработка "Инфолектика: План производства" например.

(143) Реально знаю контору, где ее довольно успешно используют для оперативного планирования

Да, любопытный продукт. Вопрос насколько он универсален и подходит для разных отраслей. Часто бывает так что делают под конкретного заказчика со всеми его заморочками, но не универсально.
Таких примочек много, и все в основном сделаны под конкретного клиента - ЦБТ, оптипром, фарма-систем. Кстати есть еще 1С:Процессное производство от того же ИТРП - по сути УПП только доработанное в части оперучета ТМЦ и планирование производства все перетащено (судя по картинкам) из ИТРП:Проц.производства.

Да, можно использовать внешние обработки и другие "прибамбасы" для решения разных задач производственного планирования. На сегодняшнем этапе развития этого процесса в программах 1С это, возможно, наиболее оптимальный путь накопления опыта, "чернозема" так сказать. На котором в дальнейшем может вырасти красивое решение.

"...Стандарт ищет свободное время оборудования под любую потребность..."
Да.
Но задача не только в том, чтобы распределить всю потребность по свободным ресурсам, а в том, чтобы сделать это оптимально. Т.е. с минимальными переналадками, с расчетом оптимального времени запуска (что раньше запускать - ПФ1 или ПФ2?), с учетом параллельно-последовательного запуска (запустить 1000 шт на 2 станках или на одном?) и т.д.. Эти проблемы пока в Стандарте не решены.

(84) в росатоме УПП внедряют

(99) надо же :)

(147) для меня было бы оптимальным, что бы вся продукция собралась на складе к некоторой дате отгрузки, которая установлена, например, в соответствии с договором
т.е. продукция с длительным и с коротким циклом производства должна поступить на склад ГП одновременно к этой дате (в идеале)
можно какими то средствами распланировать такой сценарий в 1С подобных продуктах?

(150) см.(143)

(151) спасибо, буду смотреть

(150) Это делает простейший алгоритм MRP, значит любой продукт из вышеперечисленных.

(153) не все так просто
надо заложить два ограничения: ограничения производственных мощностей и ограничения сроков выполнения всех заказов
еще неявно заложить сроки поставок сырья и материалов
так что может у меня руки кривые, но не выходит

(154) и не выйдет стандартными средствами

(155) Инфолектика: План производства спасет положение?

(154)Учет ограничений позволяет сделать реально выполнимый план производства. Это нужно если мощности ограничены. Бывает так что мощности ограничены только на одном/нескольких участках. Тогда эти узкие места можно расшивать вручную, скорректитровав полученный план. В любом случае Mrp обеспечивает готовность продуккции (заказа) к нужному сроку, если мощностей хватает. Это расчет от потребностей назад по времени.

(151) Инфолектика - скачал демку, там нужна внешняя компонента. Значит, система закрытая? компоненты нет, ничего не работает. какое отношение она имеет к ortems? Более подробной документации тоже нет, одна реклама.

(151)В инфолектике есть конекторы для подключения своих алгоритмов оптимизации?

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

(160) ответы по (158) есть?

(160) ответы по (158) - есть инфа?

Почему-то из всех адонов к УПП внятная инфа есть только по ЦБТ, все остальное только реклама.

(162) сам расчет действительно осуществляет внешняя компонента, но моделирование осуществляется путем настройки входных шлюзов.

(163) смотря что имеется в виду под внятной инфой

(165) не описание что делает программа, а хотя бы бизнес-процесс - что на входе, что на выходе. Чтобы можно было понять это то что мне нужно или нет. А то получается "это что-то на чем можно передвигаться" но не понятно автомобиль или самолет.
Цена пугающая - 25 тр за максимальную поставку. Позор западным системам, хе-хе.

(164) "моделирование осуществляется путем настройки входных шлюзов" - шлюзов с чем? С какой-то внешней системой? Почему на закачке демки ссылка на выполненные проекты на ortems - западную мега-APS-систему?

(165) присоединяюсь к вопросу (158)
непонятно, как можно посмотреть систему в действии

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

(168) насчет системы в действии наверное нужно обратиться в компанию, разработавшую систему

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

Вот нашел: Инфолектика - это модуль планирования из продукта:
http://www.3dnews.ru/software/616858
пристыкованный к УПП

(171) а что тогда "тру" маршруты, на уровне настоящих промышленных систем? хотя бы скриншоты глянуть...

(171),(173) в том то и дело, что Инфолектика "подстроится" под любую нормативку через шлюзы входной информации, как для детского сада так и для промышленного масштаба

(172) это не совсем то, по моему, тут нет блока оперативного планирования вообще

http://www.ilect.ru/demo-8/ Дофига чего написано. Таки не понял есть миним изация времени переналадок или нет?
(175) это из отзыва:
"План производства - один из модулей программно-методического комплекса КИС:Бюджетирование cis2000 ru/ProductionPlan/
КИС:Бюджетирование - I место в конкурсе Microsoft Россия "Лучшие приложения для Windows 7" 3dnews ru/msapps/?filter=0&order=4" За что купил за то продаю...

(176) по-моему это просто спам :) обычная раскрутка...

(176) насколько я знаю, опция "расчет с минимальными переналадками" входит в версию ПРОФ

(176) сейчас связался с разработчиками Инфолектики - сказали, что их продукт запатентован, будут разбираться с этим случаем

Еще не понятно есть ли расчеты графиков в разрезе заказов клиентов. У нас без этого никак.

Уж раз такой базар то есть еще Гольфстрим
http://www.cadreview.ru/files/u2/Ascon2011.pdf
По крайней мере она увязано с PDM Лоцман, весьма популярной.
Читаем и вдохновляемся.

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

Доступное время рабочих центров, выходные, пересменки, ремонты учитываются? Расписание формируется посекундно или в целом задания на смену?

Вот полный список учитываемых факторов (как декларируется):
•    Независимый спрос (заказы) и внутренние потребности;
•    Производственные мощности;
•    Минимальная партия и кратность производства;
•    Группы заменяемости рабочих центров;
•    Время переналадки рабочих центров;
•    Время и периодичность вспомогательных операций;
•    Пооперационные маршруты;
•    Спецификации изготовления;
•    Альтернативность маршрутов и спецификаций изготовления;
•    Сроки обеспечения производственного процесса;
•    Возможные потери, брак, замена материалов и технологии;
•    Графики ремонтов и плановых простоев оборудования;
•    Остатки ТМЦ на складах и в незавершенном производстве;
•    Резервы на складах;
•    Уровень страховых (неснижаемых) запасов;
•    Графики поставок ТМЦ;
•    Графики работы оборудования и персонала;
•    Специализация персонала;
•    Оперативная доступность трудовых ресурсов;
•    Минимальная партия и срок поставки;
•    Сроки хранения ТМЦ

(184) а как реально дела обстоят?

Задекларировано хорошо, вопрос с демкой. Демка нерабочая.
Системы которые учитывают все это - ближе к MES, теории расписаний, а это уже академическая наука и на разработку и обкатку таких систем уходят многие годы. А здесь за год появилась система и стоит 25 тр. Офигеть.

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

(186) Думаю, если раскрутятся, цена возрастет в разы.

(188) когда сделают как надо, тогда и вырастет в разы
а пока за то, что есть, 25 тыр недорого
хотя и это не пощупать судя по (186)

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

(190)Вот именно, планирование это не MS office. Поэтому тем и сильна 1С - возможностью кастомизации ибо код открыт что в УПП что в ИТРП. А в инфолектике код закрыт, раз это компонента, и что, если чего-то не хватает в коробке (или что-то чуть-чуть но не так как надо) то жди когда разработчики соизволят доработать? Предположим будет 100 проектов - для всех 100 будут доработывать, это ж сколько разработчиков нужно знающих Си или на чем она там написана. А в 1С просто, франчи сильно рукастые и головастые, любой каприз за ваши деньги и на месте дешево студентами. В УПП франчи планирование с нуля переписывают но под задачу клиента (это намного проще чем сделать универсально) и еще на этом зарабатывают.

(191) в ИТРП разве весь код открыт для изменения?

Получается качество решения <> тиражируемость решения. Но на конкретном предприятии с разработчиками под боком можно достичь выдающихся успехов.

(192) В ИТРП все открыто как и в УПП

(193) Опять согласен. Но в то же время есть конкретное решение, оно имеет определенные функциональные характеристики, и если они подходят конкретному потребителю, то почему ими не воспользоваться? Когда я говорил о внедрении данного продукта, я не имел в виду допиливание самого расчетного модуля, который закрыт. Речь шла об интеграции продукта в информационную систему предприятия, настройки шлюзов входных-выходных данных, добавления объектов необходимых исходных данных (например специализация рабочих или инструменты и оснастка для учета переналадок или время доп.операций и т.д.). А функционал расчетного модуля сам по себе достаточно универсален, как я понимаю, и изначально готов проглотить информацию определенных видов, и выдать рассчитанные с учетом этой информации планы.

Фишка в том что требования к системе могут меняться с течением времени. Сегодня одно а завтра новый вид продукции освоили или технологию, и потребовалась корректировка функционала. Действующая система на предприятии особенно если это система  управления постоянно дорабатывается если есть такая возможность. а если нет - то система становится тормозом для бизнеса. Пока окончательно не развалится и тогда система заменяется. Предложите клиенту избалованному гибкостью 1С что система фиксирована и чуть что - на поклон к разработчикам и сам он проблему не решит - то - то будет...
Я таких закрытых систем много видел, и неплохо были сделаны, кончалось тем что клиент брал разработчиков к себе в штат на мегазарплату  и на этом все заканчивалось. А если не брал то через 5 лет отказывался и переходил на 1С.

Насчет шлюзов на dbf, не будет ли ограничение на количество записей? детальный график производства может содержать предположительно до миллиарда записей за один месяц, если это крупное машиностроительное предприятие и планирование позаказно-пооперационное. dbf как-то стремно.

(195) неправда, ПП 8 на ключе и ДЛЛ. Правда модуль планирования действительно полностью открыт.
Ща с ней как раз ковыряюсь, изучаю планирование.

(198) к (194)

(198) ИТРП обещают вторую версию скоро, имхо зря потраченное время.

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

(200)я в курсе, но мне надо людям дать ответ на вопрос, заменит ли ИТРП ортемс в нашем случае, надо как всегда вчера..

(198) В ИТРП закрыта в конфе одна обработка которая что-то там инициализирует и в ней нет никаких алгоритмов. Все что может потребовать модификации - открыто.

(203) я не знаю про какое итрп ты говоришь, в ИТРП ПП 8 без ключа даже форму нового дока не откроешь.

к (204) хотя в коде я не ковырялся, возможно что так и есть.

(202) Это смотря что клиенту надо. В ИТРП нет рабочих центров типа "танк" и "печь". Остальные 2 есть.  Если  это критично то дорабатывать однозначно. В остальном надо моделировать. В любом случае, если брать 1С то есть стратегическое преимущество - возможность своих доработок.

(204) Форма документа не открывается без ключа, но модуль формы и объекта  полностью открыт и делай что хочешь. Там защита хитро устроена.

(197) ограничение для ДБФ насколько я знаю 1 млрд записей.

(206) у нас планирование представляет собой колхоз с истериками менеджеров и клиентов, когда план меняется по 3 раза в день. Поэтому все очень прониклись фишкой ортемса - можно тыкнуть мышкой и сразу все перепланируется, можно все онлайн перекраивать руками. ПП этого не даст. правда всех расстроила стоимость внедрения ортемса - 2,5 млн.

(196) В любом случае, тиражируемое решение - дешевле, а если оно многофункционально, то это то, что доктор прописал. Остальное дело моделирования. Писать свою систему планирования с 0, да еще на 1С это жестко. Я говорю про быстродействие, особенно если требуется обрабатывать массивы до 1 млрд. записей.

(209) Начинать надо с реинжиниринга бизнес-процессов а не автоматизировать бардак. Это называется "нервозность" (неритмичность) производства и никакой ортемс не спасет. В ИТРП:ПП8 можно делать полное перепланирование правда не мгновеннно. На приличной базе полная регенерация пооперационного плана 1-2 часа. Если по нескольку раз в день перепланировать надо то это что-то не так с предприятием... Всегда есть некая зона заморозки заказов с небольшим горизонтом планирования чтобы производство могло спокойно работать. В ИТРП ПП8 так и построено. Может вам MES-система больше нужна?

(210)Решение задачи пооперационного разузлования с расчетом потребностей всех видов по участкам - это не так уж жестко. Жестко - это оптимизация и учет множества параметров. Только идеала все равно нет и диспетчера после получения такого приблизительного плана ручками двигают как им надо, ибо мозг опытного диспетчера совершеннее любого алгоритма. Многие этим ограничиваются. Близки к идеалу MES-системы, но это уже полный онлайн.
Миллиард записей для 1С не проблема если SQL. В Конечном итоге из инфолектики тоже попадет этот миллиард в 1С.

(212) попасть то попадет, только сам расчет осуществляется не средствами 1С, что по самым скромным оценкам на порядок увеличивает скорость расчетной обработки данных. Даже если брать просто перебор таблицы.

(209) "правда всех расстроила стоимость внедрения ортемса - 2,5 млн"
в какой валюте?
(212) миллиард записей перезаписывать при перепланировании - у программистов все правильно с алгоритмизацией?

В 1С таблицы индексируются, там нет никакого перебора. Беда 1С - арифметические операции, они медленные. Конечно не на 1С расчеты быстрее на порядок. Мы тоже подумываем весь алгоритм перенести во внешнюю компоненту, алгоритм в ИТРП:ПП8 это позволяет. Но пока терпимо.

(215) извне считать не проблема, но надо найти готовое решение, и из 1С подобных систем

(214) Это умозрительно. Считай - 100 номенклатур продукции х 3000 строк в спецификации (полное разузлование) в среднем х 100 заказов х 20 дней = 600 млн. Может и меньше, не знаю. Это не считая отдельных операций, заходов, потребностей в труде, разбивки операции по сменам и т.д. У нас получается около 300 тысяч, но спецификации гораздо проще, не по 3000 а по 50 максимум и заказов меньше

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

(217) так и надо считать последние заказы, зачем позиции, которые в производстве уже, пересчитывать?

(219) Наверное от каждого заказа и каждой даты выпуска продукции в системе растет свое дерево операций, которые накладываются друг на друга и борются за ресурсы, да еще все в разрезе заказов клиентов...

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

(220) если заказ распланировался, то чего его трогать то?
если дерево выросло, то зачем его пилить, а потом заново растить?  *про дерево операций
когда все распланировано, должны быть видны "окошки" в графике загрузки ресурсов, и в эти окошки с ведома диспетчера система должна вставлять позиции из нового заказа с учетом всех переналадок и "неожиданных" ситуаций

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

не наблюдалось

(223) тогда откуда рассуждения об 1 млрд. строк перезаписываемых строк для планирования одного нового заказа к уже имеющимся?

1 млрд записей всего по всему плану пр-ва по всем уровням, заказам, датам приполное регенерации плана. не перезаписываемых строк.

1 млрд перебор, в реальности все же меньше если считать от кол-ва рабочих центров (100) х колво смен (60) х кол-во операций в смену (10) х кол-во заказов (100) = 6 млн. Но это только операции а еще есть потребности на материалы на самом нижнем уровне по каждой операции,  поэтому можно умножить еще на 10. уже 60 млн. В таком расчете много условностей и оценка даже порядка цифры приблизительная.

(227)для 100 рабочих центров, наверное, надо что нибудь покруче брать, не на 1С

(150)-(228) Прочитал ветку. Осознал весь ужас полного производственного планирования. Снова порадовался тому, что познакомился с Теорией ограничений систем (ТОС).
Крайне рекомендую, чтобы не заморачиваться с миллиардами записей, перепланированием и т.д.

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

(229) "Не имеет смысла загружать ресурсы работой сейчас, которая понадобится через некоторое время, так как выполняя не ту работу расходуем материалы и ресурсы оборудования вместо того, чтобы делать то что нужно или вообще ничего не делать!!!"
т.е. нет нужды готовить сани летом, если они все равно нужны зимой?

(230) Если сани можешь сделать за месяц, то смысла делать их на 6 месяцев раньше нет. А если сделал сани в октябре, а в декабре +5 и снега нет, то зачем ты их сделал?

(231) на сани зимой сезонный спрос, так что учитывая метеоусловия, дифицит материалов и т.п. можно конкретно пролететь

Теперь про планирование: сделал план, назавтра станок сломался, какие заказы будут работать, какие нет, что выдать работникам, что навернется по срокам для заказов клиенту и т.д.
Геморроя больше и план не выполнен... Планируй, Форрест, планируй )))

(233) риски тоже планировать надо, особенно, что бы простой не рос как снежный ком из-за поломки одного станка

Их не надо планировать, от них нужно защищаться...

(235) планирование рисков - одно из средств защиты
если софтина позволяет эти риски учитывать и быстро перепланировать при возникновении, то просто супер

(235) расскажи как с помощью твоей TOC дать клиенту ответ когда будет готов заказ.

Мы даем точность 10 дней, но скорее заказ выполнится раньше. Сделан буфер времени для производства, когда заказ расходует свой буфер его приоритет возрастает и он сам "перепланируется" на более ранний срок, поэтому в работе всегда будут заказы с максимальным приоритетом. Если делать нечего, то сиди и отдыхай, есть работа работай с максимальным приоритетом.

Просто представь, что хранишь не только ПФ и материалы, но и время заказа. Сделал часть время израсходовал, добавил еще забрал и т.д.

Новый заказ в производство запускаем после выхода старого, количество внутри в производстве ограничено.
Операция закончилась, значит попадает на полку следующего РЦ и так по цепочке...

Получается что-то от JIT, что-то от "канбан", что-то от APS/MES.

(238) "Мы даем точность 10 дней, но скорее заказ выполнится раньше"
это и есть планирование рисков

Это время за которое заказ будет выполнен с вероятностью 95%.

(239) "Новый заказ в производство запускаем после выхода старого"
пока последнюю позицию из старого заказа на склад ГП не разместите, новый заказ не запустите?

ТОС - интересная система.
Не совсем понятно, что делать с длительными и срочными заказами . Например, есть производственный план на месяц. Распланирован, все работают, при возникновении непредвиденных обстоятельств (например, срочный заказ) корректируют план. Как в этом случае сработает система ТОС?

(242) Да, тогда персонал заинтересован сделать весь заказ целиком. Ему просто нечем заниматься, кроме текущего заказа. Зато сделанный заказ сразу же отгружается и получаются деньги, а не так когда внутри 50 заказов и все готовы на 15%.

(243) Мало данных для разговора, если скажу что нужно менять подходы ко всему планированию вы же мне не поверите?)))

Заказу всё равно, какого он  типа срочный или нет. У заказа есть приоритет, есть буфер времени. Приоритет зависит от израсходованного буфера времени. Если заказ заведомо опаздывает (буфер израсходован), то зачем говорить нереальные сроки клиенту? Вы попадаете в ловушку обещаний и срываете сроки и условия поставки. Следовательно, клиент в следующий раз может просто не заказать у вас изготовление.
Если вы готовы брать с клиента за срочность дополнительную плату и ваш план производства не влияет на сроки текущих заказов (буфер позволяет), то вы беретесь за заказ, если не позволяет, то не беретесь.

(244)
"Мы даем точность 10 дней, но скорее заказ выполнится раньше"

на послезавтра нам для доставки продукции заказчику на урюпинск надо 2 фуры. а может и полгазели хватит. А может это не послезавтра, а завтра надо будет.

Как-то так?

(245) Для услуг логистики, алгоритм работы немного другой )))

т.е. алгоритм рассчитан только на работу по заказам, которые то ли будут, то ли нет? Прогнозные планы вообще не рассматриваются? Например, предприятие планирует реализовать в январе 1000 шт, в феврале - 1500 шт, в марте - 900 шт. Эти прогнозные планы корректируются в зависимости от выполнения текущего. Например, в январе реализовали 1100, и скорректировали февральский до 1700. Внеплановые заказы пока не трогаем.

(229) У каждого предприятия своя специфика. Кому-то подходит такая методология, кому-то нет. В планировании нет универсальных рецептов. Надо разделять методологию, концепцию планирования и функционал типового решения. Это разные оси измерений.
Типовой функционал MRP, APS, CRP может позволить использовать разные методологии. Например при позаказном производстве никакого среднего темпа потребления на комплектующие быть не может и заказывается все индивидуально под клиента. А у типовых комплектующих пригодных для любых заказов может быть стабильный темп потребления. Соответственно, система должна поддерживать управление запасами по точке заказа и по точным данным о потребности вплоть до специфических характеристик нужных клиенту.
Чем шире функционал системы, тем больше методологий планирования она поддерживает.
Например, MRP система при соответствующих настройках может поддерживать ТОС, не идеально но приемлемо. Теория ограничений тоже имеет ограничения в применении. Те же пресловутые мигрирующие узкие места.
Поэтому порядок действий должен быть такой:
1)Понять какая методология планирования производства и диспетчеризации на предприятии будет наиболее эффективной.
2)Определить возможности типового решения по поддержке этой методологии.
Например, в ИТРП можно для узких рабочих центров ("барабанов") настроить наиболее жесткий режим планирования с полной оптимизацией, и с помощью страховых заделов создавать буфера на их входе.

Еще надо четко отделять планирование от диспетчеризации. Диспетчеризация - это отдельная песня, и ни в одном типовом решении такого законченного функционала нет.  
В системе диспетчеризации источником потребности является не план, а запрашивающее подразделение и станки в онлайне.
(239) Все правильно, нельзя противопоставлять диспетчеризацию и планирование,  они должны работать вместе. Поэтому что-то от APS (планирование) что то от канбан (диспетчеризация).

Существует несколько способов управления:
1. Я тут напланировал - нате выполняйте, вот тут я перепланировал - снова делайте, но уже другое и т.д.
2. Тут система по алгоритму насчитала, нам вот такой запас нужен по точке  заказа, вот такое расписание работы станков, что значит не можете сделать? Ах, непредвиденные обстоятельства и случайные события, а дисперсия в план не заложена.
3. Думать не надо, работаем по алгоритму: есть приоритетный заказ делай, если приоритет одинаковый, то делай заказ с наименьшим номером, если выполняешь заказ с меньшим приоритетом и можешь закончить техоперацию в течение часа, то доделывай техоперацию для текущего заказа, иначе отложи текущий заказ и делай более приоритетный.
(249) Как считаете, какой вариант будет работать лучше?


(248) [Теория ограничений тоже имеет ограничения в применении. Те же пресловутые мигрирующие узкие места.] - Значит узкое место определено НЕВЕРНО,
если оно мигрирует. Все почему-то считают, что это обязательно станок или участок, а это может быть служба продаж или отдел снабжения или план производства или техпроцесс или вообще ошибка разработчика изделия. Есть внедрения ТОС на предприятии, когда узкое место сначала было вообще непонятно есть ли оно? Начали работать по ТОС - нашли узкое место. И постоянный процесс совершенствования нужен на каждом предприятии, расшили одно узкое место - перешли к другому и так по цепочке пяти шагов.

"...есть приоритетный заказ делай, если приоритет одинаковый, то делай заказ с наименьшим номером,..."
А кто рассчитывает приоритеты? Каким образом? Что вообще понимается под "приоритетом заказа"? Приоритет всего заказа, или одной техоперации в заказе?
Одновременно выполняются несколько заказов, в нескольких заказах есть одинаковые операции, которые  желательно объединить, чтобы сократить время переналадки. Более того, партия запуска таких деталей больше. чем потребность по всем заказам. Так что отмена одного или нескольких заказов, ничего не меняет - все равно сделаем минимальную партию.

(250) теория ограничений - это философия, образ мышления или иными словами словоблудие.
Для работы нужны реальные инструменты - методики с формулами и мат.методами.

(252) методики с формулами сами по себе дефицит ресурсов не устраняют, так что потом опять начинается "словоблудие" типа "строгость методик компенсируется ..."

(251) Это уже алгоритм расчета, в каждом производстве он будет разный, могу посоветовать прочитать труд Детмера и Шрагенхайма "Производство с невероятной скоростью".

(252) Это ваша точка зрения, так как вы мало с ТОС знакомы. На самом деле, есть и алгоритмы, есть и мат.методики ТОС.

Вот только почему-то, от некоторых мат.методик MES/ARP экономического эффекта мало. Нет планы есть, очереди и потребности рассчитаны безупречно, загрузка рабочих центров максимальна, все обеспечено и все довольны. Но вот выпуск, правда, составляет обычно 60% от запланированного, а если это так, то зачем рвать пупок учитывая всё и вся.

(253) т.е. необходимо, что бы следование методикам помогало работе
если методика, даже и правильная, работу только осложняет, значит не та область применения для этой методики

(250)(254) Не надо противопоставлять планирование и диспетчеризацию. Не надо противопоставлять проталкивающую и вытягивающую систему. Они должны работать в гармонии. Если система смогла просчитать на месяц, неделю вперед все производство то это расписание  еще не догма. Но по крайней мере руководство к действию с той детализацией которая нужна.
Одного плана мало, если нет инструментов управления потоками ресурсов в онлайне то планирование без этого мертво, ибо "план умирает в момент начала его выполнения". А диспетчеризация - инструмент выполнения плана, как вытягивающая система, это инструмент стыковки текущей ситуации с целевыми ориентирами которые задает план. Если забыли про диспетчеризацию то толку от MRP будет мало.
ТОС (имхо) не панацея, а очень эффективная концепция в подходящих для этого случаях. Диспетчеризация не обязательно должна быть основана на ТОС.
[Но вот выпуск, правда, составляет обычно 60% от запланированного]. Это значит что проблема лежит не в области системы планирования а в области оперативного управления производством. Это поломки оборудования, брак, прогулы, срывы поставок и т.д. Если бардак то от планирования толку не будет.

"труд Детмера и Шрагенхайма"
Опять импорт. Интересно, конечно, в общеобразовательных целях. Но практика российского производства немного отличается от зарубежных аналогов. И это нужно учитывать при разработке системы планирования. В Стандарте 8 планирование как раз и ориентировано на сегодняшние трудовые будни дискретного производства.

"А диспетчеризация - инструмент выполнения плана"

Да, планирование + диспетчеризация. Стандарт 8 на это ориентирован.

[труд Детмера и Шрагенхайма] отличная книга, эту философию ТОС можно применять в любых областях, например, в личной жизни :)

(256) Бардак ёмкое понятие, но не оно является причиной. Вернее сказать не оно является основной причиной, это скорее всего следствие, а причина - это незаинтересованность исполнителей в результате или нацеленность на локальные оптимумы.
(259) Согласен, из ТОС к личной жизни любая часть может подойти)))

(257) Откуда такое неверие? Вы пробовали?
А слова [практика российского производства немного отличается от зарубежных аналогов] можно услышать и по отношению к ERP/MRP/MES/APS и т.д.

К сожалению не могу ничего сказать про "ИТРП: ПП Стандарт 8", но думаю раз у него все хорошо с ориентацией, то и беспокоиться нечего)))

(260) +100

Спасибо за ссылку на книгу. Будет что почитать на выходных - оглавление  интересное.

(263)
Тогда уж начните с классики:
Э.Голдратт (6 книг) - Цель, Цель-2, Цель-3, Критическая цепь, Я так и знал, Выбор.
Потом уже работы Деттмера, Шрагенхайма, Гаредаги, Кендалла, Корбетта, Лича и других.

Если заинтересуетесь, тогда набирайте в поиске(Theory of constraints Goldratt) и добро пожаловать в прекрасный мир ТОС.

off. Сдается, что если строго следовать теории ограничений то она выведет на голову генерального как узкое место... А ТОС гласит что пока не устранили очередное ограничение нет смысла браться за следующее. Значит, пока не заменили генерального нет смысла оптимизировать производство.

все равно бестолковое руководство похерит оргвопросы

(266) Мог бы привести примеры и "За" и "Против", но у ТОС есть методики убеждения.

(257) "практика российского производства немного отличается от зарубежных аналогов"
эта практика позволяет получить результат лучше или за меньшие затраты?

"практика российского производства немного отличается от зарубежных аналогов"
эта практика позволяет получить результат лучше или за меньшие затраты?

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

"Э.Голдратт (6 книг) - Цель, Цель-2, Цель-3, Критическая цепь, Я так и знал, Выбор.
Потом уже работы Деттмера, Шрагенхайма, Гаредаги, Кендалла, Корбетта, Лича и других".

Ну, спасибо! Это сколько в человеко-днях будет?

Пока пролистала "Производство с невероятной скоростью".
По образованию я инженер-системотехник и лет 30 тому назад нас уже учили рассматривать мир как систему, состоящую из других подсистем. Так что ничего особо нового в этой книге не нашла. Более того, почему только ограничения? Законы функционирования любой системы нельзя "ограничить" только ограничениями. На мой взгляд. Нужно вывести общие законы отдельно взятой системы, в том числе и систему ограничений.

(269) "Все-таки наше производство пока еще перестраивается от планового к рыночному"
рыночное производство сейчас более плановое, чем было когда то в СССР более 20 лет тому назад

Социалистическое планирование отличается от рыночного как день от ночи.
В СССР планы сверху спускались. Т.е. планы разрабатывались с учетом взаимосвязей не только отдельных предприятий, но и целых отраслей.
Главная задача - выполнить план любой ценой (причем даже если и на склад).
А сейчас планы диктует рынок, которой зависит от многих причин. Главное - правильно этот план рассчитать (да хоть угадать!), а уже потом выполнить.
Неправильно рассчитал - и в полном пролете. Склад забит, оборотных средств нет, ЗП платить нечем, кредиты обрастают процентами - ну и т.д.

(272) если 40 лет перестраиваться, то можно дальше и не продолжать, дальше придется только мучительно больно уходить
перестраиваться надо быстрее, кто не успел, тот опоздал
потому и не стоит изобретать велосипед со своими особенностями (о планировании), надо использовать готовые проверенные решения

"... перестраиваться надо быстрее..., ...надо использовать готовые проверенные решения"

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

Тем не менее автоматизация наступает. И Стандарт худо-бедно, но планирует. Клиенты, правда, жалуются, что медленно - 40 минут разузловывается объемно-календарный план на 500 позиций (15000 закупаемых ТМЦ, 3500 производимых ТМЦ). Тем не менее результат положительный.
Интересно, сколько такой план будет разузловывться на SAP?

"...не стоит изобретать велосипед , ...перестраиваться надо быстрее... "

Мысли правильные, но трудно реализуемые, к сожалению. Пока работают станки прошлого века, пока на них работают люди старой закалки, тем более руководят, до тех пор будет переходный период.
Тем не менее автоматизация наступает, и Стандарт худо-бедно, но планирует. Клиенты жалуются, что медленно - 40 минут разузловывается объемно-календарный план на 500 позиций (3500 производимых, 15000 закупаемых). Стандарт быстрее не сможет, но результат все-таки положительный и вполне приемлемый.
Интересно, сколько такой план будет разузловываться на SAP?

(274) На временных таблицах с использованием закэшированной разузловки из регистра сведений, планирование на 6 месяцев, для  150 позиций на семи уровнях(переделах) производства, с 8000 ТМЦ и около 1000 полуфабрикатов занимает меньше одной минуты. Правда тип спецификаций только сборочные.
Планируется: Объем загрузки РЦ во времени, потребности в ТМЦ, потребности в производстве, план производства ПФ на склад и план ГП. Если указать время, то можно посчитать и буферы заказов.

Для недельного объема около 15-20 позиций пересчет приоритетов заказов занимает около 15 секунд. Самое большое время тратиться на вывод результатов из таблиц в документ планирования. Думаю отказаться от них.

(270) Мне месяца хватило...

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

(275) А можно выгрузить куда-нибудь данные, я бы прогнал их на своей системе, чтобы время сравнить. Желательно бы спецификации+техкарты в формате УПП. А то я уже давно не в курсе Стандарта.
Я их сначала закэширую, думаю это максимум минуты три будет в зависимости от вложенности переделов, а потом спланирую.

Кстати потребность в профессии при правильных техкартах будет храниться уже готовая на единицу продукции, только перемножь на количество по месяцам и проверь на мощность РЦ.

Потребностей по сменам это цепочку выстраивать? Я отказался от него...

Из-за причино следственных связей, будет нужда все переделывать каждую смену....

(278) В ИТРП Стандарте данные для расчета кэшируются?

"Мне месяца хватило"

Завидую. Переварить за месяц информацию, выстраданную авторами за несколько лет, не каждому дано.
Хотя... осталось смутное впечатление, что авторский гонорар зависел от количества печатных знаков. Можно было бы и покороче.

(284) Просто глубоко полез в тему, сам не знаю почему. Наверное "Цель" сильно по голове проехала)))

"Потребностей по сменам это цепочку выстраивать? Я отказался от него..."

Да, собственно, и наши клиенты этот функционал не используют. Действительно, разбивка по сменам в Стандарте неудачная.

"Цель" - она сейчас в голове у многих. Планирование - это один из актуальных вопросов на сегодняшний день. Я имею ввиду автоматизацию производственных процессов.

(282) Не переделывание а непрерывная актуализациия графика (перепланирование). Задача посложнее чем MRP.
(286) Если точнее не неудачная а основанная на допущениях, которые работают не на всех производствах. Сам алгоритм ведь работает.

"В ИТРП Стандарте данные для расчета кэшируются?"

Да, естественно.
Но, нужно помнить, что Стандарт в принципе создавался под небольшие и средние предприятия. Соответственно, предполагалось, что базы гигантскими не будут.

"Если точнее не неудачная а основанная на допущениях, которые работают не на всех производствах. Сам алгоритм ведь работает."

Да, алгоритм работает, но не для всех подходит.

"А можно выгрузить куда-нибудь данные, я бы прогнал их на своей системе, чтобы время сравнить. Желательно бы спецификации+техкарты в формате УПП."

Выгрузить можно, но вот насчет формата УПП - есть проблемы. Дело в том, что в Стандарте есть такое понятие как "Заход". Понятие актуально для машиностроительного производства, но в УПП такого нет. Поэтому получить однозначное соответствие не получится.
Поясню, заход - одна из стадий изготовления продукции. Например, редуктор  имеет 3 захода - сборка, испытания, упаковка.

У меня все спецификации+техкарты раскладывабтся в три регистра сведений:
Потребности ТМЦ
Потребности РЦ
Полная многоуровневая разузловка ТМЦ+РЦ+Операции.
Потом на основе этих данных все считается "мгновеннно", Зато запись спецификации сначала в справочник, потом в кэш может идти сек 5-15.

(291) Это чтобы не плодить номенклатуру (Редуктор+Сборка, Редуктор+Испытания, Редуктор+Упаковка)???

Да.

(292) Третий регистр - многоуровневая разузловка - как и в какой момент получается?

Так они все три пишутся при записи спецификации или при изменении техкарты.
Постоянно не пересчитывается, зато можно видеть срез на каждую дату, посмотреть потребности по периодам и т.д. и т.п.  
Можно рассчитать входимость ТМЦ, даже решена задача, что из остатков на складе можно сделать ГП. Правда список ограничен )))

Это по времени дешевле, чем сразу сотню номенклатур разузловывать на 7-10 уровней...

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

(296)(297)И какого же размера будет этот регистр? Если учесть, что спецификации могут иметь несколько вариантов, а каждый вариант - несколько десятков (хотя бы) позиций?
Считаем, одна спецификация - в среднем 50 позиций; 3 варианта - 150; 5000 наименований производимых ТМЦ по 150 = 750000 записей в регистре.

ой, триста... (300) ;)

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

Интересно рассмотреть разные алгоритмы, И типовые, и не типовые.
Вчера обсуждали с клиентом типовой алгоритм планирования, который используется в ИТРП. Клиент предлагает задавать не только минимальную партию запуска, которая в ИТРП есть, но и максимальную, которой нет. Через этот параметр можно регулировать загрузку оборудования.

В ИТРП Процессное производство есть максимальная партия запуска, устанавливается через максимальный объем одного цикла Рабочего центра. Или это другое?

(301)-(303) Ага, а еще можно задавать парный запуск (по 2-4-6-8 единиц), потому, что система работает именно так и тестируется только попарно. Таких условий может быть много.

По поводу планирования производства, оглядываясь на свой опыт (свыше 20 лет), лучший результат получился у DBR/S-DBR, а вот симплекс-метод, генетический алгоритм расписаний, давали результат лучше, но от жизни дальше. Они так уплотняют загрузку оборудования, что срыв плана на одном участке вызывает принцип домино. Вроде бы и план хорош, и затрат мало, а в результате ничего не сделано по факту. А в DBR размером партии рулишь, загрузку участков мониторишь - в результате народ без  всякого надрыва повышает производительность в 2-3 раза, а обычно раз в 5-20. Потом другая проблема встаёт со сбытом продукции))).

(299) Нормальные регистры получаются около 150-250 тыс записей. Вот с нуля их заполнять тяжело наверное будут минут 10 заполняться, а потом выборка с множителем.

Если вы занимались анализом спецификаций, то принцип Парето никто не отменял: есть менее 20% спецификаций с большим количеством комплектующих > 10, а 80% будут состоять из 2-10 деталей. Так же и трудоемкость учитывается. Есть детали которых можно за час произвести 100 шт, а есть те которые те же 100 штук делаются два-три месяца. Можно применять и АБС/XYZ анализ, тоже картинки даёт интересные. А ведь всё это необходимо для определения ограничений и управления по ним.

Вот не может ваше производство сделать необходимое количество, а вы его планируете, тратите свои ресурсы, а может стоит поискать исполнителя на стороне, или упростить деталь. Вспомните первый автомобиль Форда (Т-1), выпускался 30 лет, и каждый год упрощался до безобразия.
А теперь функций налепят, а они не работают, новые лепят и т.д. В магазин заходишь, а там 40 сортов шампуня, а мне может нужен всего один... Но чтобы мыл, а не укреплял, лечил перхоть, снимал зуд и шелушение и т.д.

(302) Я бы попробовал бы поулучшать алгоритм. Оптимизация у меня почти всегда получалась лучше всего...

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

(307) В DBR нет как такового планирования, есть пулл заказов на производство, и в соответствии с целью увеличения продаж обеспечивается просто максимально быстрое прохождение  заказа в системе. Есть конечно планирование обеспечения поставок, есть временные диапазоны буфера на удары Мерфи, но все само регулируется, так как каждый знает что ему нужно делать, в каком порядке и не бывает такого, что все сделали, а что-то забыли...

(303) Нет, тут имеется ввиду немного другое - параметр "максимально-оптимальная партия" как антипод параметру "время переналадки". Если только время переналадки сокращать, то можно загрузить РЦ только одним видом ТО и гнать его до победы. Что не всегда правильно с точки зрения общего результата. Оптимальнее было бы выпустить максимальную партию, достаточную для запуска следующего передела.

(305) А как же с остатками быть? В ИТРП остатки анализируются на каждом переделе. Это значит, что каких-то веток разузловки может и не быть (если остатков на складе или в НЗП достаточно). А в этом третьем регистре все ветки будут обязательно.

(310) Да всё так и есть, вы правильно поняли, но при планировании остатки вычитаются один раз для всех переделов, то есть имеем снизу вверх потребность с учетом остатков попередельно за один проход, причем остатки забираются снизу вверх до тех пока хватит. Сначала на полуфабрикаты, потом на готовую продукцию.

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

(306) Интересное предложение. Очень в тему. А на чем пишете?

(312) Наполовину серийное, полуфабрикаты почти все серийные, а ГП зависит от заказа...
(313) Так на ней же "родимой" и пишу)))
1С + Язык запросов и соответствия, массивы, структуры. Очень сильно от структуры данных зависит, можно составной индекс сделать, а можно и поле в один индекс целочисленный. Ну и что, что избыточно, зато скорость в соединениях может вырасти в 5-10 раз.

(313) Часто одно решение убирает кучу проблем с производительностью

(312) Если в ИТРП:Стандарт под продукцию, выпускаемую 10 числа потребуется полуфабрикат 8-го числа, а под продукцию, выпускаемую 15 числа, потребуется этот же полуфабрикат 5-го числа, причем 5-го будет запущена минимальная партия покрывающая также  потребность 8-го числа то в конечном итоге будет ли выпущена 5-го числа только минимальная партия, а 8-го выпуска пф не будет?

(316) В ИТРП:Стандарт учитывается прогноз поступления как закупаемых, так и производимых ТМЦ. Таким образом минимальная партия ПФ, выпущенная 5 чмсла, изменит остатки в НЗП и будет учтена при расчете потребности на 8 число.  
Но возможна и  другая ситуация.
Такого рода проблемы решаются как раз расчетом общей потребности в ПФ. Имея общую потребность, можно распределить ее по РЦ с какой-то степенью оптимизации. Конечно, точного решения нет. Тут может быть несколько решений с установкой разных приоритетов. Например, "минимизировать время переналадок", или "минимизировать время исполнения конкретного заказа" , или "сбалансировать план на период" и т.д.

(317) Что дает использование приоритетов:
1) минимизировать время переналадок;
2) сбалансировать план на период; ????

К  "минимизировать время исполнения конкретного заказа" вопросов нет, есть вопрос, а "минимизировать время выполнения всех заказов" у вас есть?

Как происходит изменение плана выпуска, если ПФ 5-го числа не выпустился или выпустился с браком?
Если не хватает частей ПФ на 8-е число?
Как считается скорость потребления ПФ со склада, как задается точка заказа?
А если срочному заказу понадобятся ПФ из других заказов он их сможет забрать?
Что вы балансируете в своем планировании затраты, время, материалы, загрузку рабочих центров?

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

(319) Не понятно зачем нужны два плана? Если первый можно уточнять и менять, а второй должен выполняться. Что с чем сравниваем потом.

Готов начать с определений.
1. Что такое план? "Объем и последовательность выпуска ГП и ПФ".
2. Если уникальные заказы, то спецификации+ТехКарты+(статистики длительности) по ним нет - раз не знаем время, не можем планировать?  "Вы, с этим согласны?"
3. Если серийное производство, то знаем спецификации+ТехКарты+(статистики длительности) и тогда планировать можем и можем знать скорость потребления и точку заказа? "Вы с этим согласны?"
4. Отсюда вывод: "План должен позволять определить выполнимость заданного объема ГП и ПФ в заданном объеме времени, а следовательно определить объем и расписание использования ресурсов (материалов, персонала, машин, методов)." И как следствие нужно максимизировать скорость прохождения заказов в системе, которая не можэет быть больше ограничения.

Я вам уже почти все рассказал...

(320)
1. Упрощенно говоря да
2. Заказы уникальные, техпроцессы типовые с вариациями, время знаем. Если совсем не типовые то делаются рабочие техкарты и запускаются в производство. Без спецификаций работают только мастера народного промысла в порыве вдохновения.
3.Скорость потребления может скакать между сменами. в одну смену 100 щт за час в другою 0 шт за час. План может делаться вперед на несколько смен, не обязательно на месяц. Что дает скорость потребления рассчитанная на 3 дня вперед? Например, 3 кг за смену в среднем? Но эти три кг в первую смену все нужны иначе план не выполнится?
4. [План должен позволять определить выполнимость заданного объема ГП и ПФ в заданном объеме времени, а следовательно определить объем и расписание использования ресурсов (материалов, персонала, машин, методов)]. Это не отсюда вывод, а классическая задача планирования производства, решаемая в MRP и APS. План должен быть рассчитан так чтобы выполнить заказы в срок заявленный клиенту, с оптимальной загрузкой РЦ и план должен быть реально выполним, для чего можно делать временные буфера на рабочих центрах. Скорость прохождения заказов в системе - величина комплексная, время обработки заказа включакт согласование условий с клиентом и прочие бодания. Если заказ размещен в производстве на некую дату выпуска (не обязательно как можно раньше, не всегда клиенту продукция нужна срочно)- производство должно его выполнить и точка, а с какой скоростью он пройдет в производстве это производство решает. С такой скоростью чтобы загрузка  РЦ была оптимальной.
Мы похоже говорим о разных концепциях управления производством.

(320) Отклонения между первым и вторым планом позволяют делать выводы о "нервозности" и неритмичности производства и принимать соответствующие решения.

[оптимальной загрузкой РЦ] и [С такой скоростью чтобы загрузка  РЦ была оптимальной.]
Что Вы под этим понимате? Что такое оптимальность?  И что такое загрузка РЦ?

(321)
3. Скорость поребления дает возможность управления буфером запаса, если сожрали быстрее чем было значит пополнять нужно на большую величину.  Буфер считается так, чтобы не было дефицита, и размер буфера позволяет его избежать.
4. Первое, время бодания с клиентом на скорость заказа не влияют, второе размещение заказа в производство раньше необходимого срока уменьшает ваши свободные средства и увеличивает связанный капитал (запасы и НЗП), третье - производство показывает вам то, как вы его собираетесь измерять:
- по оптимальной загрузке оборудования, значит увидите оптимальную загрузку;
- по минимальному количеству переналадок - увидите большие партии в обработке (а зачем меньше делать? Мне ведь нужно уменьшить число переналадок!);
- по минимальному простою, значит буду выпускать фигню на пару месяцев вперед, чтобы только не простаивать;
- по дате отгрузки - производство постарается выполнить его к нужной дате, но в 90-х случаев опоздает ("синдром студента" слышали);

Отсюда и вопросы заданные вам в (323).

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

(318) (319) На предприятиях дискретного производства так и планируют. Есть два плана - прогнозный (составляется числа 20, если период - месяц) и оперативный, в котором отслеживаются все отклонения.
Управление отклонениями в ИТРП осуществляется в системе диспетчеризации. Выдаются производственные задания на цех/участок, на их основе выписываются наряды-задания на конкретного исполнителя/бригаду. Наряды-задания выдаются не на месяц, а на смену.

(320)
1. Есть производственный план (что и в каком объеме), есть объемно-календарный - что, в каком количестве и КОГДА.
2. Нет, не согласна. Если заказ уникальный, то спецификация тоже уникальная. Например, состоит из 1000 позиций. Нужно знать остатки по ним, длительность производства и доставки - все как и для серийных, только работы больше и она дороже, так как уникальна. Выполнять такой заказ можно не один период.
3. Скорость потребления - параметр в ИТРП не учитывается, учитываются потребности без скорости. Потребность - параметр более определенный, чем скорость потребления.  Можно планировать без этого параметра? - Да, можно. Лучше и хуже? - трудно сказать.
4. Зацикливаться на одном алгоритме планирования не стоит. Всегда есть несколько решений. Какое из них верное - время покажет.

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

(327) 3 - как это? А планирование по точке заказа???
4 - не стоит потому что для каждого производства свое лучшее решение. Время ни при чем.

(323) Оптимальная загрузка РЦ. Что это такое? - если ответим на этот вопрос, то, считай, и задачу планирования решим.
На мой взгляд, оптимальной загрузки "вообще" не может быть. Только оптимальная с какой-нибудь точки зрения, вернее, с точки зрения какого-нибудь параметра. Например, загрузить РЦ с минимизацией времени переналадок РЦ. (Уже выше говорили об этом). Или с точки зрения более-менее равномерной загрузки всех РЦ.

(328) Совершенно верно, 20- это частный случай. Пусть не 20, но смысл именно в двух планах.

(329) Для определенного вида ТМЦ - так называемых материалах общего применения, т.е. используются на данном предприятие практически на всех заказах - можно и по точке заказа. Но это наиболее простой способ планирования, легко реализуемый. Не для всех ТМЦ подходит.

(329) "Время ни при чем"...
Согласна, что от бизнес-процессов конкретного производства очень много зависит.
Я имею ввиду (опять повторюсь), пока супер-решений в планировании нет, только зреют.

(326) непонятно, зачем два плана составлять, тем более на какое то число?
если длительность выпуска меньше календарного месяца, а после 20-го числа (условно) поступают новые заказы, использующие, например, полуфабрикаты, запланированные к выпуску до 20-го, то как будет осуществляться перепланирование?

(334) Два плана с разным горизонтом планирования могут быть, на ближнюю неделю - по утвержденным и неизменяемым заказам, и на дальше на месяц - прогноз по приемке заказов, но по нему уже надо планировать закупки хотя бы.
И с другой стороны - могут быть два плана - первичный (принятый например 20-го) и больше не меняемый, и оперативный, которые ежедневно перепланируется исходя из текущей ситуации. Разница между этими двумя планами показывает качество планирования и в некоторой степени ритмичность производства.

никакой пользы от хранения производственного плана "на 20 число" не вижу для заказного производства, если производство способно выполнить заказ за несколько дней
в чем моя ошибка?

(336) Если производство выполняет заказ за несколько дней и материалы не нужно покупать под конкретный заказ то план можно делать не на 20-е число а в пт, или  в день, предшествующий условной производственной неделе (например, в среду). Первичный план не нужен если не требуется анализ отклонений оперативного плана от первичного, либо перепланирование не выполняется в связи с тем что оперативный план на неделю замораживается после его утверждения и новые заказы в него не добавляются. А добавляются только на следующую неделю после утвержденной недели.

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

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

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

Вот не заходил пару дней, а вы тут столько понаписали: Всех с Наступающим теперь по ответам на вопросы.
(325) С РЦ понятно, теперь просто представьте себе что у РЦ есть перечень работ, который он должен сделать, и есть последовательность этих работ, кроме этого РЦ видит те работы которые делают предыдущие РЦ, которые делаются для него. При этом в списке видны только те работы которые обеспечены потребностью ТМЦ или инструмент. Времени на переналадку у РЦ нет совсем. Как хочет так и делает. Если работа выполнена в зеленой зоне, то он получает 1 бал, если в желтой то получает 0 балов, если в красной  то -1 бал, если просрочили заказ, то -5. Из балов складывается премия всего предприятия. И от вклада всех зависит получат её или нет. Нет отдельно премии продажникам, HRам  или  производственникам, премия зависит целиком от работы всего предприятия как одного целого. При этом каждый видит косяки других и знает, что ему нужно сделать заранее и планирует свою работу. Если один человек, постоянно загоняет операции в минуса, то его или учат или посылают.  Как таковых планов РЦ и заданий по сменам нет. Если заказ появился в системе, то по нему формируется маршрут, приоритет, заявки на обеспечение и он попадает в список работ. Каждый РЦ сам решает что и когда он должен сделать. Это лучший план производства, отгрузки и продажи.
(325) Про управление буферами - лучше почитать у первоисточников, у них более подробно, не так как у вас. Сама цель буфера не в объемах запасов сырья, а в защите сроков производства, они исключают сроки доставки или простои ограничения системы!!! Соответственно поток производств идет максимальным всегда.
(326) Знакомая картина с заказами-нарядами, когда за тебя решили что и как сделать, но потом или кирпича нет или раствор кончился, а если есть и то и это, то тебе надо в контору сбегать и т.д. Это все идет из мира затрат, когда вам нужно точно посчитать себестоимость изделия, время работы, материалы и т.д. Но никто не может сказать наверняка, что цена продажи и сумма затрат не зависят друг от друга.  Если вы делаете за 10 рублей, то продавать можете и за 20 и за 500. ТАк зачем вам нужно обязательно знать сколько стоит каждое изделие?

(327)-(328)-(329) и далее. Забавно было прочитать. Вам следить за всеми участками и вам это не тяжело?
У меня диспетчеру только следить за заказами и работой одного или двух центров с максимальной загрузкой, так как работа остальных на скорость прохождения заказа не влияет, мощности избыточные.

Ну вот как то так мне всё и видится. Ещё раз с наступаюшим))

(341) я о том же. Каждый РЦ сам решает что и когда он должен сделать исходя из текущей ситуации, ЧТОБЫ КАК МОЖНо МЕНЬШЕ ОТКЛОНИТЬСЯ От ПЛАНА И ОБЕСПЕЧИТЬ ВОВРЕМЯ ПОТРЕБИТЕЛЕЙ. Это и есть диспетчеризация на уровне РЦ, и на участок система должна оперативно давать всю нужную информацию. У нас по крайней мере так. Может сказывается то что переделов 10-20, то есть очень много взаимозависимостей в производстве а узкие места выражены не очень сильно. Один передел встал - все развалилось, поэтому уложиться в общий план по участкам  а план качественно спланировать - важно.
[У меня диспетчеру только следить за заказами и работой одного или двух центров]-само собой, но как быть если именно в не узком месте возникла проблема и пошел расход страхового задела или буфера, а за ним встанет и "узкий" РЦ потому что не обеспечен? Не правильнее ли присматривать за всей цепочкой?

(341)[ТАк зачем вам нужно обязательно знать сколько стоит каждое изделие]
при высокорентабельном производстве и отсутствии конкурентов может и не надо. Можно и за воровством не следить и устроить полный бардак все равно будешь в жирном плюсе. А при цивилизованном производстве и на конкурентном рынке и изобилии предложения - надо все считать. Иначе те кто считают тебя раздавят.

(342) Потери на неузком звене это мираж (Э.М. Голдратт) Буфер узкого звена позволяет работать до тех пор, пока не починят неузкое звено.
(343) [Иначе те кто считают тебя раздавят.] - Наоборот ))) Нужно тоже считать уметь...

[Буфер узкого звена позволяет работать до тех пор, пока не починят неузкое звено]. Ага, а потом нагонять размер буфера узкого звена, что потребует опять контроль неузкого звена.  А если узкое место на 5% более узкое чем неузкое тогда тоже неузкое не требует внимания? Тогда если неузкое не контролировать слишком большой буфер получится на узком, а это уже НЗП и замораживание оборотных средств.

(345) Уважаемый Fank, в этом случае количество одновременно обрабатываемых заказов будет являться ограничением системы. Вы книгу прочитайте "Цель". Там в  39-й главе есть ответ на ваш вопрос  и даже решение.

Прежде чем обсуждать 39-ю главу прошу дать строгое определение "Заказа". Насчет 39-й - понятно что разбалансировка производственной системы происходит при увеличении нагрузки и узкое место начинает мигрировать туда где раньшще было не узко потому что надо не просто делать а еще и скорей наращивать буфера. Хорошо сказано про такие "волны" нагрузки. Но узкое место - это по по смыслу ограничение производственной системы (в ее структуре) а количество одновременно обрабатываемых заказов - это результат деятельности системы. Правильно ли говорить о результате деятельности как об узком месте?

(347) Заказ - это продажа клиенту, которая выполняется в определенный срок, с определенным объемом номенклатуры(продукция, материал или услуга), с необходимым клиенту качеством, по приемлемой для клиента рыночной цене.

[Правильно ли говорить о результате деятельности как об узком месте?]  Нет, неправильно. Правильно говорить об ограничении потока, об ограничении скорости зарабатывания денег.

Количество заказов, которые могут менять приоритеты других заказов, должно быть ограничено. Например, вы обещаете выполнение заказов 10 дней, а есть клиент который хочет заплатить в 3 раза больше но за срок три дня.
Если принять все заказы, то они не будут выполнены в срок три дня, значит такие заказы нужно ограничить.

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

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

Вот что нашел.
http://old.e-xecutive.ru/discussions/forum_21648/msg_139059_1071318/showall/
Особенно развеселила фраза, высказанная одним из первооснователей росиийских MES-систем:
Полагаю, что "узким местом" можно было бы считать просто отсутствие соответствующих профессиональных знаний у лиц, приступающих к рещению упомянутых производственных задач. ТОС - отдыхает... :)

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

(352) На каких предприятих в России внедрено ТОС?
Сами учавствовали в подобном внедрении?

(352) Есть понятие "Приказ на производство", "Производственный заказ". Вопрос - кто его оплачивает?
ATP  может точно так же как ТОС учитывать временные буфера.
ТОС это идея управления, которая вполне ложится на алгоритмы MRP, и на это указано во многих источниках по ТОС.
ТОС можно противопоставлять MRP и APS, а MES, как онлайн система, вообще тут ни причем.
Евгений приводит серьезные аргументы, понятные мне и основанные на реальной жизни, а его противники кроме мантр ничего привести не могут, как увлеченные идеей фанатики-революционеры. Типа есть идея, а все что было этого - отстой, ТОС - это панацея от всех проблем. Но при этом сразу сами признают что ТОС не применима на мелкосерийных позаказных производствах. Где логика?
Если почитать труды по ТОС то сразу у любого специалиста видевшего реальное производство возникает куча вопросов, т.к. допущения очень серьезные и видно что это не везде будет работать. Но на эти вопросы, увы, ответов в трудах нет, а сами эти труды отдают попсовостью и гуманитарностью, если сравнивать с серьезными трудами по MES, теории расписаний и т.д.
Обратите внимание что сами консультанты по ТОС признают что они прежде чем внедрять ТОС исследуют предприятие на применимость ТОС. В литературе встречались упоминания о проектах по внедрению ТОС и что внедрения были неудачны и клиенты судились.
Но надо признать - если ТОС применима то дает очень хороший эффект.
Привлекательность ТОС для специалистов по видимому в том что она позволяет накрыть все сложности и многообразие реальной жизни одной красивой и простой идеей, не утруждая себя в разборе деталей и даже не зная реального производства. Иначе говоря - лень двигатель прогресса)
Присоединяюсь к вопросу - где реальные внедрения, и каких именно продуктов? Как говорится,практика - критерий истины.

(352)С философской точки зрения, чем проще модель тем меньше она учитывает реальность, тем менее точна, тем менее ее результаты согласуются с действительностью.
Не в этом ли суть разногласий, заманчивость ТОС, что ТОС претендует на опрокидывание этого постулата?

(355) [С философской точки зрения, чем проще модель, тем меньше она учитывает реальность] (Это откуда? Источник есть?)
Опыт показывает обратное. Чем сложнее модель, тем дальше она от жизни.
ТОС говорит только следующее:
1. Все события имеют причинно-следственные связи.
2. Есть в последовательности событий звено ограничивающее пропускную способность цепочки событий. Такое звено всегда одно!
3. Следовательно "Результат" полученный в конце цепочки событий, ограничен одной причиной.

НЕ вижу ни одного противоречия в таком понимании модели системы...

(356) сложность модели сама по себе не коррелирует с жизнью. Коррелирует с жизнью ее точность, а уже сложность коррелирует с точностью. Какой прогноз прогоды точнее - по народным приметам или рассчитанный на суперкомпьютере?
1) Ничего себе открытие сделала ТОС. Это еще в средние века открыли.
2) Звено-то одно, но во первых только в некоторый момент времени одно, а в разные моменты времени это могут быть разные звенья. Из очевидного факта что звено одно, делать далеко идущие выводы об универсальности методик ТОС - это, повторю, неочевидное допущение.
3) В данный момент времени одной причиной, завтра - другой причиной. Пока работаем с одной причиной начнет действовать другая причина. Производственная система переменчива во времени, в общем случае. Образно говоря, не всегда производственную систему можно представить себе как поток воды проходящий через узкое место в трубе как это рисуют в популярных книгах. Но иногда можно, и тогда ТОС работает. Представьте себе трубу которая по всей длине непрерывно меняет сечение в разные стороны. Система постоянного перепланирования (MES, ERP, MRP и т.д.) с заданным временным интервалом максимально точно учитывает (как сможет) новые условия и строит новый актуальный план, а ТОС исходит из допущения о временной стабильности состояния узких мест. Традиционной MRP такие допущения не нужны.

Присоединяюсь к поздравлениям от П.М. С прошедшими и надвигающимися!
Пару слов по поводу двух планов.
(336)"никакой пользы от хранения производственного плана "на 20 число" не вижу ".
Попробую объяснить. Рассмотрим молокозавод. На январь у него было два заказа: первый - 300кг масла, 200 кг сметаны, 200 кг творога; второй-100 кг масла, 300 кг сметаны, 300 кг творога.
На февраль есть три заказа: первый - 200кг сметаны, 200 кг творога; второй - 100 кг масла, 200 кг сметаны, 200 кг творога; третий - 250 кг масла, 100 сметаны и 100 творога.
Пакет заказов на январь и февраль разный, а производственный план на январь (400,500,500) очень похож на пр.план на февраль (350,500,500).
Отличие только по маслу(-50 кг). И производству все равно по какому заказу производить масло или сметану. Главное, чтобы сбыт не ошибся с отгрузкой!
Первый план - прогнозный, тот самый на 20 число. Он нужен во-первых, для анализа остатков ТМЦ и принятия решений о закупке того, чего не хватает. Во-вторых, он нужен для баланса потребностей и ресурсов. Именно этот план решает проблему узких мест, т.е. равномерно распределяет потребности между ресурсами. От того, насколько грамотно он составлен, зависит ритмичность производства (вот вам связь MRP и ERP). Т.е. "узкие места" производства рождаются в отделе сбыта. Пакет заказов должен быть составлен так, чтобы все заказы можно было выполнить в срок, и при этом производственные ресурсы были загружены по максимуму.
А внеплановые заказы, которые нужно "распихивать", говорят о проблемах в отделе сбыта. И разрабатывать систему планирования под них - все равно, что автоматизировать лопату (опять извиняюсь за повтор).

(357) Про точность разговор идет или про сложность коррелируемую к точности.
Что важнее напрягаться прыгая с 10 метров и стараться попасть в воронку диаметром метр или можно прыгнуть с вышки 2метра в квадрат со стороной 5 метров.
1) Угу, еще раньше в античные века во времена Сократа, Аристотеля и Пифагора.
2) Звено одно? - Одно. Вам легче управлять сразу же многими звеньями - управляйте ими, хотите управлять всем - измеряйте всё, контролируйте всё, планируйте всё и управляйте!!! Мне проще когда внимание уделяется одному звену, и по показаниям одного звена я могу управлять остальными, тем более моего времени на все звенья не хватает.
3) Вы понимаете под причиной, совсем не то же что я. Это не объяснить в двух словах. ТОС вам дает механизмы определения узкого места.

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

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

По поводу фанатизма? Если работает, то почему в это не верить?

По поводу внедрения. ТОС ПОМОЖЕТ вам, если:
- во-первых, вы производите то, что продается (продукция востребована).
- во-вторых, вы понимаете, что текущая эффективность вас не устраивает и готовы изменяться.

Если вы решили внедрять ТОС, то вам нужно:
1) Понять как система документируется сейчас.
2) Какие решения принимаются и почему.
3) Статистика.

Ну а дальше уже анализ ограничений->внедрение изменений->оценка результата-> новый цикл и т.д.
Про программные продукты смотрите те, что уже есть в организации, на первом этапе вообще не рекомендуется вносить изменения в систему.  Т.е. сначала понимаем чем болеет организация, потом выбираем лекарство,  затем уже лечим.
Без эти шагов увы никуда... Так что, если есть УПП - работаем с УПП; есть БП или КА - работаем с ними, или с Excel. У кого что...

Если ТОС - это идея управления которую стоит попробовать на имеющихся продуктах (которые уже работают на предприятии), проанализировав полезность ТОС на данном предприятии, ресурсы, подготовку персонала то это нормально. Не получилось - работаем как раньше. Есть ведь правило - не ломай то что работает.
А если ТОС - это программный продукт (либо переработка действующей системы) которые решили внедрять, загоревшись самой идеей, не проанализировав все риски сейчас и в будущем, в т.ч. применимость ТОС и ее полезность, снести все что до этого худо-бедно работало - это ненормально.
[ТОС Вам ПОМОЖЕТ] - критерии приведены такие что можно сказать "ТОС вам поможет всегда и везде". У всех продукция востребована, все хотят изменяться, всех не устраивает эффективность. Значит, бросаемся все внедрять ТОС? Эта типичная позиция проповедников ТОС.
Но я бы добавил еще один критерий. "Если структура производства такова, что ТОС принесет реальную пользу".
ТОС ведь можно внедрять не по всему производству, а в отдельном участке или подразделении, так? Поэтому вопрос применения ТОС - комплексный. Нужно/не нужно, где, в каком объеме, как, в какой системе. А возведение ТОС в абсолют, который должен захватить все и вся на предприятии - это религия а не практика.

(363)
1) Согласен.
2) Согласен, но мало верю в такой исход (что ТОС не помогла ))))) .
3) Согласен, можно внедрить ТОС и в одном подразделении, но лучше на всё предприятие целиком: если продали продукцию - значит заработали, нет - значит нет. Ваше подразделение может не быть узким звеном, зачем вам заниматься субоптимизацией? Например вы делаете полозья для саней 50 штук в час. Вы подумали, придумали и можете делать 100 полозьев в час. А на сборке могут собирать и паять только 15 саней в час. Зачем вам делать 100? Если максимум вы делаете и продаете 15 санок( а значит и 30 полозьев в час). Вы должны быть загружены на 60% от своей мощности.  Это простой пример с санями. А если вы делаете разную кучу профилей металлопроката из собственного сырья, после выплавки в конвертерной печи, то можете ли вы утверждать, что 50 тон руды которые вы засыпали сегодня пойдут именно на производство швелера 20, а не уголка 20 или рельсы трамвайной. Таких примеров можно привести много.
4) Что в вашем понимании означает внедрять?   Слово методика или методология вам должно говорить  о чем-нибудь? ТОС это процесс постоянный и циклический, такой же как настоящий TQM, вы встраиваете качество в процесс, а тут вы встраиваете процесс управления по ограничениям. Вы же читали книги Голдратта? Детмера? Начните применять. Вот даже у вас на предприятии тоже есть что улучшать, начинайте действовать.

Мне не хотелось бы выглядеть в ваших глазах воинствующим фанатиком ТОС )))

(353) В Новосибирске есть одно предприятие, где уже внедрен ТОС (лет 5) и одно где сейчас пилотный проект внедряется. Результаты впечатляют. Все находятся в технопарке Академгородка.

(364) (3) Почему бы не заняться субоптимизацией для повышения эффективности отдельного подразделения? Например, снижению расходов в этом подразделении. Оно может иметь избыточную мощность и не быть узким звеном, а из-за избыточной мощности несем допрасходы которые можно избежать. Что вы скажете финансистам - давайте держать избыточную мощность, нести ненужные расходы лишь бы это подразделение не превратилось в узкое место? При сокращении расходов подразделение может приблизиться к порогу на котором оно само станет узким звеном. ТОС утверждает что не надо снижать лишние расходы при избыточной мощности?
(4) Внедрять значит насаждать чуждую предприятию систему ))) Противно поначалу, но потом полезно.
(366) Параметры предприятия какие, отрасль и т.д., ведь не ларек же?

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

Не секрет - Электроника и приборостроение, свыше 200 человек в каждом.

Гляньте, что может УПП делать с людьми
http://www.tocpractice.com/node/113

Читаю про ТОС и не догоняю. Если задача ТОС последовательно выявлять и расширять узкие места, то что означает фраза:
(341)"У меня диспетчеру только следить за заказами и работой одного или двух центров с максимальной загрузкой..."
Т.е. этот один или два центра и есть узкие места, которые не расшиваются, никогда не будут расшиты и за которыми постоянно нужно следить?

А если последовательно расшить все узкие места, то в приложении к цеху дискретного производства получим уже давно выведенный коэффициент загрузки РЦ приблизительно равный 50% от максимальной мощности каждого РЦ. Такой коэффициент обеспечивает нормальную работу подразделения даже в случае возникновения пробки на любом РЦ. Опять же нужно постоянно следить за каждым РЦ, так как "сломался/брак/заболел/запил" предугадать невозможно!  А такую слежку обеспечивает диспетчеризация производства. Ну и при чем тут ТОС?

(370) Как в 2-х словах рассказать то, чем занимаешься уже почти полгода...
Почитайте ещё, Голдратт говорит максимально используйте ограничения, что и делаем....

Одно из них и так расширили в два раза...

(371) В таком случае планирование в ИТРП также можно отнести к ТОС, так как наш алгоритм выявляет дефицит потребностей, который нужно "расшить".

Попытался объяснить, но наверное на расстоянии не получается объяснить.
Планирование и ББК (DBR) они на разное направлены. Вот у вас вся продукция имеет разное время производства, а в ББК рекомендуется иметь одинаковое время на разные товары.

(370) Насколько я понимаю, ТОС говорит что даже если пропускная способность системы более чем достаточно - однажды появившееся отклонение уже никогда не компенсируется пр наличии множества связей. т.е. оставание от графика будет только нарастать, и страховой задел времени в 50% будет полностью рано или поздно поглощен. Поэтому быть абсолютно уверенным что 50% плановой загрузки оборудования обеспечивает 100% выполнение графика - нельзя.

(375) О, вы начинаете немного мыслить по ТОС и думать как в мире прохода. В общем ТОС рекомендует 200% запас по времени и 15% запас по мощности.

(375) Моё искреннее уважение к вам, мне кажется вы на верном пути...

(375) Хорошо, 50% - это в среднем. Для каждого производства будет свой коэффициент. Возможно, кому-то  и 15 хватит.
Является ли такой коэффициент ограничением с точки зрения ТОС?

По ТОС "Ограничение" - это не "место".

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

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

Существует три основных типа ограничений:
Ограничение мощности (Capacity Constraint)– ресурс, который не в состоянии предоставить в необходимое время тот объем мощности, который система от него требует.
Ограничение рынка (Market Constraint)– количества получаемых фирмой заказов недостаточно для поддержания требуемого роста системы.
Ограничение времени (Time Constraint)– время реагирования системы на потребности рынка слишком долго, что ставит под угрозу способность системы выполнить взятые на себя обязательства перед клиентами, а также расширить свой бизнес.

Нам не хватало КОНТРОЛЯ за работой двух рабочих мест. Стали контролировать и скорость возросла сначала в 1,5 раза, а потом в 4-е раза. За два месяца.
Сделали входной контроль качества и стали следить, чтобы загрузка была постоянной без простоев.

"Нам не хватало КОНТРОЛЯ..."
Так, спасибо, что-то забрезжило.
Но то, что Вы описываете, напоминает и бюджетирование, и систему менеджмента качества (СМК). т.е. некоторую систему управления. То, что Вы в ТОС называете "ограничением", в бюджетирование называется "параметром", в СМК - "критерием".
ТОС - это система управления. Вернее попытка формализовать управленческие методы и навыки, которыми, кстати,  некоторые люди награждаются  при рождении. Например, Форд, или наш Третьяков (Третьяковская галерея).

И результативность внедрения как всегда зависит не от самой системы, а от того, кто внедряет. От того, кто сумеет выделить "ограничения", "параметры", "критерии" и т.д. Выделить и управлять ими.
Похоже на "Деньги-товар-деньги". Цепочка известная, но... не всем дано.

Вы опять про параметры и критерии? Параметров много, критериев тоже на каждый процесс их как грязи.  А нужно следить за одним. Например прошел заказ через ограничение, запускаем новые материалы, балансируем поток. Поток это рубль в час, тыс рулей в день, миллион в месяц. Оборачиваемость это тоже оттуда, объем запасов, объем буфера и т.д.

ТОС еще говорит, что "ограничение" всегда одно. Поэтому управлять по нему легче.

Одно? Или "главное" из многих?

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

(385) Одно, до тех пор пока не расшили.

(386) Почитайте ещё раз про метод DBR. Тут "Ограничение" это барабан, который позволяет идти всем в ногу с одним темпом.

Когда расшили, "ограничение" стало в другом, но тоже одно...

Дурацкий вопрос но в нем намек)
Можно ли ТОС использовать для составления расписаний уроков в школе или номеров в гостинице?
Думаю что нет. Ученики и постояльцы - это не обрабатываемые детали)
А раз так то откуда следует что аналогичные задачи по составлению точного расписания не могут появиться в производстве, когда ТОС отпадает?

(389)
Можно, можно. Согласен, что не детали, но ресурсы ограничены и поток есть (гостей и учеников), а следовательно ими нужно управлять. Согласитесь трудно учиться в школе когда математика и русский ставятся в конец дня...

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

Вот у вас в ИТРП много клиентов, значит много расписаний и составленных планов. Попросите их проверить выполнение планов и расписаний по факту. Могу сразу сказать ответ: средний процент полного (100%) выполнения плана будет меньше 50%, около 30-35%. Отсюда вывод, либо планировать, либо не планировать, разницы никакой. Так для внутреннего успокоения...

Никак нет.
Понятно что планы никогда выполняются.
Надо планировать и ежедневно актуализировать - перепланировать.
Тогда система будет содержать текущее руководство к действию - все видят что надо делать сегодня, завтра.
ТОС хороша если узким местом бизнеса является производство, причем за счет явно выраженных узких мест. А их еще поискать надо. Или специально создать, как учит ТОС потому что производство не бывает и недолжно быть синхронным.
Хотя признаю что идеология ТОС должна быть в ERP-системах хотя бы как опция, ибо при ее применимости дает мощныйй эффект. А вот лечить любые болезни с помощью ТОС - мне это напоминает как гербалайфом в свое время пытались лечить все - от насморка до инсульта.
Идти ведь надо не от методологии, а от реальной проблемы на предприятии?
У ТОС есть единичные внедрения, причем речь шла больше не о ПО а об организационных мерах которые дали эффект.
ТОС известна в нашей стране с 2000 г как минимум, но что-то на практике слабое получила распространение, может у нас в стране манагеры недалекие?

(391)
[Надо планировать и ежедневно актуализировать - перепланировать.] - А что это даёт? Новые планы могут также не выполняться, а время будет потеряно.

Лично мне ТОС дало самый главный инструмент "Процесс мышления" (Thinking process) и описание этого инструмента (ДТР, ДБР, Тучи разрешения конфликтов и т.д.) Сильная вещь!!! Рекомендую...

Но даже они не смогут помочь тем, кто не хочет меняться, у кого и так всё "хорошо".

Я сейчас на 100% уверен, что ТОС очень сильно недооценен, совместно с другими методиками менеджмента: 6сигм, JIT, TPS, Деминга  она может создать такой "запас горючего", что предприятие стартует как ракета - вертикально вверх.
Если РосАТОМ сейчас займется кроме Lean ещё и ТОС, то боюсь представить последствия такого развития.

А про ТОС я понимаю, что она панацея, есть разные стили и методы управления, просто пока наяву вижу, если выбрать ТОС как основную методику управления, то мало кто догонит и перегонит.

Бывают внедрения ТОС, которые прекращаются после первых результатов... Всё зависит от того как куда и зачем ведёт руководитель предприятие.

К (392) По сути в ТОС нового почти нет, но то что не в деньгах правда они мне подтвердили на все 1000%.

это я про производственный учет затрат и производственный

[ТОС известна в нашей стране с 2000 г как минимум, но что-то на практике слабое получила распространение, может у нас в стране манагеры недалекие?]

Далекие , просто книжек не читают

Мы за прошлый год автоматизировали три производственных предприятия ( не связанных с друг другом ) - металлообработка , машиностроение

Посменное планирование не использовали , у каждого был свой подход к управлению производством - сильно проще , чем в УПП

А на каникулах я прочитала по наводке ILM " Производство на warp " , спасибо , кстати !

Так вот все три завода все делают почти так , как написано в этой толстой книжке . Но вряд ли кто - то на предприятиях называет это " ТОС "

(392) Текущий оперативный план (после перепланирования) - это инструкция для всех исполнителей что надо делать сейчас, сегодня, завтра. Невыполнение инструкции не разрушает систему, в которой выполняется постоянное перепланирование исходя из текущей ситуации. Это обычный цикл управления - собрал данные, проанализировал, принял решение,  управленческое воздействие, и т.д.
Если в рассчитанном плане узкий рабочий центр загружен наиболее оптимально, и ведется жесткий контроль за его загрузкой (как того требует ТОС), и материалы отпускаются в производство согласно плану, (т.е. согласно плану по загрузке узкого места в т.ч.), то получается та же самая "веревка" (только "расчетная").
Получается, что ТОС можно использовать в MRP, но для ТОС необязательна MRP. Отсюда следует что MRP/APS более универсальный механизм. Хотя бы потому что MRP/APS работает при миграции узких мест в отличие от ТОС.
(395) В УПП посменное планирование в любом случае использовать нереально, таким образом УПП способствует внедрению ТОС.
Кстати что примечательно - на некоторых проектах наблюдалась плавная миграция от MRP к ТОС в виде сводного планирования (в ИТРП реализовано) когда клиент осознает что высокая детальность в плане в некоторых местах излишня и что многие потребности удобно подтягивать "веревками" оперативно. Но до этого клиент еще должен созреть, сила инерции велика.

*закладка*

(395) Прочитайте обязательно Цель-2 " Дело не в везенье". Там основы того, что используется в "Производство с невероятной скоростью...".

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

Особенно ценны замечания Голдратта о стратегии фирмы в виде сегментирования рынка:
[ Про кризис...
-Просто дело в том, что люди привыкли винить внешние обстоятельства, которые в данный момент нельзя изменить, вместо того чтобы винить себя за то, что заранее к ним не подготовились. Это что-то вроде того, как сверчок винит зиму, в то время как муравью
тепло и сытно.
- Мне даже детские сравнения не помогают, - смеется она. – А как ты сможешь предотвратить
падение рынка?
- Не смогу. Но при правильной стратегии я смогу предотвратить падение рынка моей фирмы ниже той черты, за которой не будет хватать работы всем моим людям.
- И как это можно сделать?
- Просто. Путем создания достаточного уровня гибкости. Первое, о чем надо позаботиться, - это чтобы каждый работник обслуживал не один сегмент рынка, а несколько. Ты согласна, что при тщательном планировании деятельности фирмы это возможно? Например, я могу внимательно следить за тем, чтобы разрабатывать такие новые продукты, которые, за незначительным исключением, потребуют тех ресурсов,которые у меня уже есть.
Просто дело в том, что люди привыкли винить внешние
обстоятельства, которые в данный момент нельзя изменить, вместо того чтобы винить себя за то, что
заранее к ним не подготовились. Это что-то вроде того, как сверчок винит зиму, в то время как муравью
тепло и сытно.
- Мне даже детские сравнения не помогают, - смеется она. – А как ты сможешь предотвратить
падение рынка?
- Не смогу. Но при правильной стратегии я смогу предотвратить падение рынка моей фирмы ниже той черты, за которой не будет хватать работы всем моим людям.
- И как это можно сделать?
- Просто. Путем создания достаточного уровня гибкости. Первое, о чем надо позаботиться, - это чтобы каждый работник обслуживал не один сегмент рынка, а несколько. Ты согласна, что при тщательном планировании деятельности фирмы это возможно? Например, я могу внимательно следить за тем, чтобы разрабатывать такие новые продукты, которые, за незначительным исключением, потребуют тех ресурсов, которые у меня уже есть. ]

Да простят меня копирайтеры

(396) [Если в рассчитанном плане узкий рабочий центр загружен наиболее оптимально, и ведется жесткий контроль за его загрузкой (как того требует ТОС), и материалы отпускаются в производство согласно плану, (т.е. согласно плану по загрузке узкого места в т.ч.), то получается та же самая "веревка" (только "расчетная").]
Здесь ошибка в выражении "т.е. согласно плану по загрузке узкого места в т.ч." Не в том числе, а ТОЛЬКО по загрузке узкого места.
Остальное оборудование нужно планировать не с точки зрения максимальной загрузки или минимального времени перенастройки, а только с целью обеспечения непрерывной работы ресурса ограниченной мощности "узкого горлышка". Сейчас имеется в виду производственное планировнаие.

[Получается, что ТОС можно использовать в MRP, но для ТОС необязательна MRP. Отсюда следует что MRP/APS более универсальный механизм. Хотя бы потому что MRP/APS работает при миграции узких мест в отличие от ТОС.] Из чего такая логика? Если ТОС можно использовать независимо от того, есть МРП или его нет, то разве следует что МРП/АПС более универсальна?
МРП/АПС это мир затрат. Они считают затраты и управляют предприятием по затратам, а ТОС это мир скорости дохода, скорости зарабатывания денег, для него решения принимаются не на том вырастут затраты или нет, а на том куда и как будем двигаться вперёд к прибыли или назад к убыткам.  ТОС это динамика, а МРП/АПС статика. Это как разница между постоянной скоростью и скоростью с ускорением. Вот коэффициент ускорения это и есть ТОС.

(400)

(399)не так. Ничего не мешает по некоторым рабочим центрам (не узким) не формировать расписание, мы так и делаем. Считается что у него неограниченная мощность. Но потребности считаются по всей цепочке до материалов через дерево структуры изделия - и каждый участок получает данные - что он должен сделать из чего в какие сроки и кому передать. Далее на неузких местах дается некоторая свобода, ограничение одно - переставлять задания только если нет входящих ресурсов. Потребность в материалах посменно - в результате соответствует загрузке узких РЦ. Может получиться так что из-за изменения ассортимента выпуска узкое место перемещается в другой РЦ. Поэтому узкими считаются несколько ключевых РЦ. Буфера перед узкими РЦ тоже настраиваются.
МРП/АПС более универсальна потому что ее можно использовать без ТОС всегда (как "тупой" просчет производственных потоков исходя из структуры производства), а вот ТОС можно использовать без МРП/АПС не всегда, и это сами сторонники ТОС признают.
Мир затрат или не затрат в МРП - решает не система планирования производства а учетная политика предприятия.
В ИТРП идеология финансовых показателей максимально приближена к ТОС. Есть генерируемый доход T по продажам с учетом коммерческих расходов (по нашему это маржа), а все остальное - OE, I это в любой системе есть - элементарные вещи. Ничего не мешает анализировать в МРП, как управленческое решение влияет на эти три показателя ТОС. (по сути I и OE очевидны, а вот T как раз важно).
Вот то что сдельная ЗП не включается (категорично) по ТОС в переменную себестоимость продукции - это перебор. Для многих производств количество работников легко масштабируемо в зависимости от объема производства. Особенно если низкоквалифицированный труд.  У нас не Америка и не профсоюзы. Проще говоря, надо производить - нагнали таджиков, не надо - выгнали.
Статика или динамика в МРП - зависит от того, применяется ли ТОС. МРП - это расчетный механизм и не более, а ТОС - это управленческая идеология более высокого уровня. Нельзя сравнивать мышь со слоном.

http://www.ortems.ru/news/68.html
Вот здесь последователи APS пишут о ТОС

(402) А я и не сомневаюсь в работоспособности ИТРП. Все равно данные обрабатываются людьми и они принимают решения. Вот в какую сторону они двигаются люди решают сами.
Приведите если не сложно цифры ваших пользователей ИТРП. Например табличку в колонках  Наименование, Прибыль, Маржинальнальная прибыль, Сумма продаж
и в строках данные по годам 2007, 2008, 2009, 2010, 2011. Покажите рост в связи с приобретением ИТРП. Хочется оценить выгодность приобретения и применения ИТРП с точки зрения покупателя.

В нашем случае с 2009 по 2011 рост прибыли где-то на 25% но это наверное связано не столько с применением ИТРП сколько с расширением рынка и окончанием кризиса. Хотя расширение рынка произошло отчасти с помощью ИТРП, кто знает...
А у другого клиента которому внедряли прибыль упала после внедрения, но это не ERP виновата а то что его выселяют из МСК за город и потребовались расходы на реструктуризацию производства.
Проводить корреляцию между внедрением продукта и изменением показателей это все равно что корреляция между количеством снега на улице и количеством листьев на деревьях. Вроде, есть а на самом деле причина в другом - смена времени года.
Вы наверное ожидали что на 300% повысились показатели? Такие сказки обещают внедренцы ТОС?

А ну да, да..

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

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

(406) Тогда в чем выгода ИТРП и его методик планирования?

Вопрос можно переформулировать "А в чем выгода ERP системы?"
Выгода состоит из двух компонент:
1. выгода конкретной ERP по сравнению с другими ERP системами - это функциональность, гибкость, качество, реальная а не надуманная бизнес-модель. Вы знаете что в некоторых системах с бизнес-моделью производства не все в порядке (не будем "показывать пальцем", понятно о чем речь).
2. выгода ERP Системы как таковой. А на эту тему есть множество источников информации. Наберите в поиске "Эффект от внедрения ERP".

(409) В книге  Цель-3 "Критическая цепь", Голдратт пишет о том, что консультанты  ERP захватили мир, они предоставили кучу показателей для собственников и в результате организовали рынок своих услуг, а люди перестали думать, и стали доверять цифрам. Эдвард Деминг тоже писал про это же в книге "Выход из кризиса" и призывал всех к глубинному знанию, к пониманию причин и истоков проблем производства, к статистическим отклонениям, к учету отклонений сигма, именно они помогают определять системные проблемы от единичных. Знаете какой лозунг должен быть у внедренцев? Ни в коем случае, не "Измеряй, Анализируй, Контролируй, Управляй!", а "Изучай, Стабилизируй, Думай, Изменяй!".

А выгода ERP только в том, что есть цифры о предприятии, и эти цифры лучше, чем их отсутствие.


Уважаемый fank, мы с вами одногодки, и я 20 лет внедрял ERP и СУБД. Еще год назад у меня была такая же убежденность как и у вас. Я занимался и планированием, и расписаниями, и учетом себестоимости в производстве, но теперь для меня это пройденный этап, я изменился после ТОС, надеюсь что в лучшую сторону.

(410)Да, ТОС крайне заразительна, в хорошем смысле.
(407) Не хотят пользоваться потому что считать выгоду от внедрения eRP это все равно что считать выгоду при принятия в штат хорошего управленца. Посчитали, а какие управленческие решения можно будет принять на основе данной информации, какие воздействия на предприятия оказать? Управленца хоть выгнать можно (это и есть решение и воздействие), если будет обнаружена корреляция. А если не выливается в воздействия с целью улучшения то нафига тратить время на эти анализы? Из любопытства, если своего времени не жалко.
(410) Фразы "консультанты захватили мир, марсиане захватили мир" это все популизм и игра на эмоциях. Конечно, думают только консультанты ТОС а другие доверяют каким-то цифрам и не думают. Вот очень подозрительна безапелляционность и категоричность. В свое время распространителя гербалайфа были сами на нем помешаны и ходили с круглыми значками "Хочешь похудеть - спроси меня как". Все прочие методы категорично объявлялись полной фигней.
Я не против ТОС, я против крайностей и категоричности, противопоставления.
Лозунг приведенный Вами очень хорош (изучай, стабилизируй и т.д.). Но похоже на игру слов. Чем думай отличается от анализируй, а изучай от измеряй, управляй от изменяй? Проще сказать - вникай в суть происходящего, и на основании этого принимай решения но к этому стремится любой нормальный менеджер без всякой ТОС.
Чтобы воздействовать на процессы в правильном направлении все-таки недостаточно медитации в позе лотоса ))) нужно иметь под руками хотя бы иногда конкретные показатели о происходящем чтобы делать выводы. Иначе решения по управлению будут приниматься не на основе реальных фактов а на основе какого-то там думания.

Неплохая дискуссия развернулась! Если ТОС - более высокий уровень управления по сравнению с обычной ERP, то нужны механизмы "взбирания" на этот уровень. Если начинающего лыжника поставить на горные лыжи, ничего хорошего не получим. И далеко не каждый сможет тройной тулуп прыгнуть. Можно и шею сломать. Тогда вопрос - а кому вообще под силу внедрить ТОС? Так сказать, огласите, пожалуйста, список необходимых и достаточных условий.

ТОС - это все таки прежде всего уровень компании... ИМХО.