Что такое ресурс ограниченной мощности (CCR)?


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52791 от Сергей Жаринов
Скопировал из ветки "ТОС и системная динамика", подсократил, лирику убрал.

Роману Пантелееву:

… Что касается частного формального вопроса …, вот что Вы выложили:

"capacity constrained resource (CCR) - Any resource that, if its capacity is not carefully managed, is likely to compromise the throughput of the organization."

Как требуют правила формальной логики, корректное определение любого понятия должно указывать на признаки, не нуждающиеся в определении и не содержащие двусмысленности. Здесь же что ни слово, то расплывчатое понятие! Что значит "carefully managed"? Кто определил, насколько "carefully" я управляю своим ресурсом? Вообще говоря, я могу сколь угодно плохо управлять любым ресурсом, даже если его загрузку вы определите в 1 (один) процент.

Что такое "compromise the throughput"? Общий выход уменьшится? По сравнению с чем? На каких характерных временах?

Ну и вишенка на торте в виде слова "likely". Правда, бывает ещё "highly likely" ...



Роман Пантелеев:

Я не могу комментировать словарь TOCICO, так как не общался ни с одним из авторов по этой теме. Могу только сказать, что он не противоречит по сути определениям данным Еленой и Одедом, но в словаре мне не хватает конкретики определений Елены и Одеда.
Главный вопрос - зачем нам иметь столько определений: constraint, bottleneck, CCR, non-CCR. Становится это понятно из областей их применения. (пишу собственное понимание).

Constraint - это термин имеющий отношение к системе в целом. Constraint - это то, добавление чего моментально положительно сказывается на результате системы. Точка прямого влияния на результат при добавлении Constraint.
Constraint используется в 5 фокусирующих шагах, а так же для выбора стратегии подчинения (не упускать ни одного клиента, зарабатывать максимум на времени ресурса и т.д.). Constraint может мигрировать из-за сезонности - это вызывает разную стратегию поведения в низкий и высокий сезон. Например в высокий сезон T/CU считается по отношению к ограниченной мощности, а в низкий по отношению к деньгам (или объему склада - в зависимости что является в этот момент ограничением).

Bottleneck - ресурс, работающий 24 часа 7 дней в неделю 365 дней (или минус праздники, общезаводские каникулы) в году. bottleneck всегда является Capacity Constraint, так как идеально сбалансировать спрос с мощностями не возможно - постоянно работающий ресурс не позволяет обслуживать весь спрос, проходящий через него. Понимание бутылочного горлышка (оно же узкое место) было стартовым моментом в создании OPT, а позднее привело к созданию теории ограничений. В то время термин constraint не использовался, использовалось бутылочное горлышко. Но когда случился нефтяной кризис 80-х бутылочные горлышки стали пропадать. Тогда Голдратт стал анализировать ситуацию и ввел термин constraint, который покрывал нехватку заказов (Market Constraint).

CCR - ресурс с ограниченной мощностью, загруженный более 70% времени (величину беру из опыта и определения Одеда и Елены). Поскольку в системе всегда присутствует вариабельность - ресурсы, имеющие недостаточную защитную мощность периодически будут становиться краткосрочным бутылочным горлышком. С определенной величины загрузки эта ситуация становится радикально частой, что не позволяет буферу эффективно защищать реальное бутылочное горлышко, которое в итоге может простоять. Если же бутылочного горлышка - нет, то CCR становится очень похожим по функционалу из-за частых превращений в локальное бутылочное горлышко. Ограниченность защитной мощности заставляет относиться к ресурсу иначе чем к non-CCR ресурсам. Он требует внимания, персонального управления и защиты. В 7-ой инъекции раздела POOGI решений MTO и MTA вводится постоянный контроль за CCR ресурсами. Так как в любой момент такой ресурс может превратиться в ограничение, что должно вызвать корректирующие воздействия, препятствующие перемещению текущего ограничения или появления двух интерактивных ограничений. Как рекомендуют эксперты-практики TOC ограничение при развертывании решений MTO/MTA не рекомендуется загружать более 80%, т.е. фактически мы получаем ситуацию CCR. Bottleneck так же является CCR - по определению. Понятие CCR используется в реализации DBR - для CCR необходимо составлять расписание и защищать его буфером. Анализ неудавшейся попытки управлять проектами через DBR привел к появлению еще одного типа ограничения Time Constraint, а позже к специальному решению для управления проектами - CCPM.

non-CCR - прочие ресурсы не требующие составления расписаний, особого внимания и защиты.

Примерно параллельно с появлением Time Constraint появился еще один тип ограничений Policy Constraint - как реакция на тот факт что анализ реальных систем показывал, что ни CCR, ни рынок не ограничивали напрямую результаты системы. Всегда существовали политики, которые "разбазаривали" то или иное. Ответом на явные проявления этих политик был 2 и 3 шаг в 5 фокусирующих шагах. Однако быстро пришло осознание, что политики не являются ограничением - они были лишь препятствием к максимальному использованию реальных ограничений. В итоге это вызвало появление мощнейшего инструментария Thinking Processes для работы с этими препятствиями. Современный консалтинг по TOC - это работа в области мыслительных процессов или развертывание логистических решений, разработанных и структурированных с помощью мыслительных процессов ТОС.


…………………………………………………………..

2Сергей: о CCR могу привести ещё аналогию дороги. Пробка организуется «взрывным» образом при превышении загрузки дороги выше 80%. В этот момент ранее независимые проезды машин начинают взаимодействовать между собой через буфер толерантности (не помню точный термин - это расстояние между машинами, комфортное для водителя). В итоге любое замедление машины начинает распространяться на другие через этот буфер. В этот момент падает скорость потока через это место дороги, а входящий поток продолжает двигаться с прежней. Образуется зона полной остановки, так как подъезжающие машины вынуждены остановиться полностью. Это начинает наращивать хвост пробки. Как видим дорога не была занята на 100% (полностью роботизированные автомобили, общающиеся между собой не вызвали бы при 80% загрузке образования пробки), однако она вызвала ситуацию бутылочного горлышка. В производстве роль буфера толерантности играет вариабельность тачтайм и транзакционные издержки логистики. 70% думаю предложены на основе опыта, чтобы надежно обеспечить контроль за ситуацией при 69% загрузке (когда специальные меры отсутствуют).

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52793 от Сергей Жаринов
Прежде всего, попробую откомментировать "аналогию дороги", поскольку такой пример часто приводят при обсуждении загрузки ресурсов. Пробки (или узкие места) образуются не из-за вариабельности, а только в том случае, когда нагрузка на ресурс превышает его максимальную пропускную способность. В противном случае при любом уровне вариабельности производительность (выход) в точности равна интенсивности входного потока. Даже если загрузка ресурса составляет 99%. Естественно, речь идёт об усреднении на характерных временах для статистически управляемых процессов.

В примере с дорогой имеется серьёзная проблема в постановке задачи, связанная с некорректностью определения понятия загрузка. Если - как Вы утверждаете - объективно существует "буфер толерантности", то его абсолютно необходимо учитывать. В таком случае предельная загрузка, которую следует принимать в расчёт при управлении дорогой, как раз и будет порядка 80% от номинальной.

Похожая ситуация имеет место с загрузкой производственных ресурсов. Есть станок с ЧПУ, машинное время обработки детали 1 час, значит максимальная производительность станка за 8 часов составляет 8 деталей. Правильно? Нет не правильно! Даже без учёта переналадок и подналадок, технологических перерывов и т.п. А снять-поставить? Если через барфидер, то всё равно чуть меньше (ваши роботизированные автомобили). А если вручную, то ещё меньше. И ещё куча факторов. Для управления нужно другое время - между началом обработки предыдущей и последующей детали (в определённом смысле аналог того, что в Lean называют takt time). Вполне возможно, что оно окажется не час, а полтора или даже два. То есть в основе рассуждений о предельном значении 70% или 80% лежит методологическая ошибка.

Скорее всего, речь идёт о путанице в понятиях. Дело в том, что 70-80% это важная величина, но для совсем других целей. При загрузке ресурса свыше этого порогового значения при любом уровне вариабельности резко нелинейно начинает расти размер очереди перед этим ресурсом, однако производительность (выход, throughput) самого ресурса остаётся той же самой, что и при загрузке 50% или 1 (один) процент.

P.S. Из сказанного выше, в частности, следует что формулировки (а тем более внесение в определение) типа "Bottleneck - ресурс, работающий 24 часа 7 дней в неделю 365 дней (или минус праздники, общезаводские каникулы) в году" вызваны либо небрежностью либо недоразумением.

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад #52801 от Роман Пантелеев
Я что то не понял - Вы всю вариабельность предложили в загрузке учитывать?!
Аналогия с дорогой конечно не 100% но не плохо показывающая динамику, происходящую на CCR. А буфер толерантности - это психологическая величина и между водителями различается. Кто то в 15 см может ехать от впереди идущей машины, а кто то за 3 метра держится. Загрузку по кому считать будете? Среднюю? Но если будет много 3-х метровщиков, то пустота между машинами будет как раз показателем такого CCR. Понятно что Вам не нравится определение bottleneck, а мне наоборот - быстро вправляет мозги о том, что боттлнеком не является

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52802 от Сергей Жаринов
Давайте для начала с дорогой разберёмся.

Роман Пантелеев пишет:

… Пробка организуется «взрывным» образом при превышении загрузки дороги выше 80%. ...


Скажите, пожалуйста, от чего Вы 80% отсчитываете?

P.S. А что касается определения батлнека, которое Вам "быстро вправляет мозги о том, что боттлнеком не является" … . Вы когда-нибудь видели "ресурс, работающий 24 часа 7 дней в неделю 365 дней (или минус праздники, общезаводские каникулы) в году"? Нет? Вот и я тоже никогда не видел. Значит - в соответствии с Вашим определением - батлнеков в природе не существует!

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52814 от Роман Пантелеев
Сергей Жаринов пишет:

Давайте для начала с дорогой разберёмся.Роман Пантелеев пишет:

… Пробка организуется «взрывным» образом при превышении загрузки дороги выше 80%. ...

Скажите, пожалуйста, от чего Вы 80% отсчитываете?


Я не отсчитывал - читал какое то исследование. Насколько понимаю они брали скорость потока на основании максимальной разрешенной скорости, средних габаритов автомобиля, установленного норматива на расстояние между автомобилями. Исходя из этого вычислялась пропускная способность участка дороги. Потом отслеживали ситуацию - при приближении к 80% от этой величины (по количеству автомобилей за определенный промежуток времени) происходили эффекты описанные мной. Реально может быть все было сложнее - подробных параметров эксперимента не приводилось.
Сергей Жаринов пишет:

P.S. А что касается определения батлнека, которое Вам "быстро вправляет мозги о том, что боттлнеком не является" … . Вы когда-нибудь видели "ресурс, работающий 24 часа 7 дней в неделю 365 дней (или минус праздники, общезаводские каникулы) в году"? Нет? Вот и я тоже никогда не видел. Значит - в соответствии с Вашим определением - батлнеков в природе не существует!


Я видел (надо понимать что время планового обслуживания тоже вычитаем из 365 дней) при чем в дискретке. А Голдратт по боттлнекам (непрерывное производство) кандидатскую писал (или как у них там работа на ученую степень зовется). Да на практике мы учитываем (закрываем глаза на) разрешенные потери в размере 8%, но это не потому что это не ботлнек, а потому что если загрузить на 100% - план никогда не выполнится. Но это дьявол в деталях, который не имеет отношения к крупной сути - что это bottleneck. Ресурс работает 24 часа 7 дней в неделю почти полный год при этом разбазаривая от 1 до 10% (изредка и больше) мощности.

Разница от CCR в том, что размещение спроса на ресурсе дает больше 100% загрузки, приходится урезать до 100% (а по практическим причинам до ~90-92%). А размещение спроса на CCR дает менее 100% - до 70%. В данном конкретном случае я бы загрузку 92-100% так же отнес бы к боттлнеку, так как знаю, что 5-8% будут гарантированно разбазарены. Но это практика применения (я всего лишь к CCR отношусь как к ботлнеку).

Скажу сразу и CCR видел, когда при смене продакт микса боттлнек уезжает на него. Что при планировании требует постоянного учета загрузки CCR

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52815 от Сергей Жаринов
Роман Пантелеев пишет:

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


То есть взяли с потолка какую-то цифру, а потом опытным путём выяснили, что максимальная пропускная способность конкретного участка дороги составляет от неё 80%? Просто прелесть! А нельзя было наоборот поступить? Сначала экспериментально определить максимальную пропускную способность, а потом - во избежание пробок - контролировать, чтобы интенсивность потока не превышала этой величины? Мне кажется, это и было бы настоящее управлением по ограничению.

Что касается соотношения батлнеков и CCR, то Вы меня окончательно запутали. С одной стороны, по Вашему, "bottleneck всегда является Capacity Constraint", а с другой - опять же по Вашему - "Bottleneck так же является CCR - по определению". У меня в голове это всё вместе не укладывается. Видимо, разная аксиоматика.

Лично я давно пользуюсь следующими определениями:

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

Bottleneck (узкое место) - это ресурс, потребность в котором превышает его возможности.

Естественно, оба понятия рассматриваются в статистическом смысле, то есть на характерных временах.

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

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52816 от Георгий Лейбович
Сергей Жаринов пишет:

...
Лично я давно пользуюсь следующими определениями:

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

Bottleneck (узкое место) - это ресурс, потребность в котором превышает его возможности. ...
.

Сергей, не надо ли для определённости добавить к твоим определениям:
CCR... это ресурс, определяющий максимальную производительность системы в единицах Т (а не просто в единицах продукции)

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад #52818 от Сергей Жаринов
Георгий Лейбович пишет:

Сергей, не надо ли для определённости добавить к твоим определениям:
CCR... это ресурс, определяющий максимальную производительность системы в единицах Т (а не просто в единицах продукции)


Думал, что это очевидно, но ты прав: на всякий случай лучше уточнить.

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52839 от Роман Пантелеев
Сергей Жаринов пишет:

Роман Пантелеев пишет:

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


То есть взяли с потолка какую-то цифру, а потом опытным путём выяснили, что максимальная пропускная способность конкретного участка дороги составляет от неё 80%? Просто прелесть! А нельзя было наоборот поступить? Сначала экспериментально определить максимальную пропускную способность, а потом - во избежание пробок - контролировать, чтобы интенсивность потока не превышала этой величины? Мне кажется, это и было бы настоящее управлением по ограничению.


Нельзя - надо четко понимать сколько мы теряем на ботлнеке. В Вашем подходе Вы закроете глаза на все потери (даже если это 50%) и на основе эксперимента определите 50% как 100%.
Сергей Жаринов пишет:

Что касается соотношения батлнеков и CCR, то Вы меня окончательно запутали. С одной стороны, по Вашему, "bottleneck всегда является Capacity Constraint", а с другой - опять же по Вашему - "Bottleneck так же является CCR - по определению". У меня в голове это всё вместе не укладывается. Видимо, разная аксиоматика.

Лично я давно пользуюсь следующими определениями:

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

Bottleneck (узкое место) - это ресурс, потребность в котором превышает его возможности.

Естественно, оба понятия рассматриваются в статистическом смысле, то есть на характерных временах.

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


Мой bottleneck - Ваш CCR и наоборот.
Видимо Вас к этому Constrained подталкивает. Я конечно попрошу Одеда рассказать историю возникновения термина CCR. Я же с ним познакомился в русском языке: РОМ. И никаких проблем с ним не было - это ресурс, которому не хватает _необходимой_ защитной мощности (отсюда «ограниченной). Ботлнек по определению тоже CCR потому что на нем отсутствует защитная мощность (ее не хватает).

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

Пожалуйста Войти , чтобы присоединиться к беседе.


1 мес. 2 нед. назад - 1 мес. 2 нед. назад #52840 от Сергей Жаринов
Роман Пантелеев пишет:

… Мой bottleneck - Ваш CCR и наоборот. ...


Хорошо, пусть у нас есть производство из двух станков (А и В) и в процессе последовательной обработки из сырья делаются изделия на продажу. Среднее время обработки на станке А составляет 1,0 час, на В - 0,8 часа. Пусть станок А работает по 24 часа 7 дней в неделю все 365 дней в году. С сырьём проблем нет. В соответствии с Вашими определениями, А - батлнек, В - ССR (загрузка 80%, то есть больше 70%). Объясните, пожалуйста, что такого особенного в станке В, что его нужно выделять в специальную категорию CCR? И что качественно изменится, если загрузка В будет, например, 50% (среднее время обработки 0,5 часа, то есть не-CCR по Вашей терминологии)?

Вложения:

Пожалуйста Войти , чтобы присоединиться к беседе.

Работает на Kunena форум