Что такое ограничение (ключевое понятие TOC)?


6 года 5 мес. назад - 6 года 5 мес. назад #46837 от Сергей Жаринов
Дмитрий Стукалов: Выделил обсуждение понятия "Ограничение" в отдельную ветку. Тема образовалась в ходе обсуждения " Как улучшал небольшое производство, и что в итоге получилось ".

Роман Пантелеев пишет: ... Ограничение - это одновременно то что не дает нам поднять результаты системы, но и то что обеспечивает (подняло) их до текущего уровня. ...


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

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

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


6 года 5 мес. назад - 6 года 5 мес. назад #46838 от Роман Пантелеев

Сергей Жаринов пишет:

Роман Пантелеев пишет: ... Ограничение - это одновременно то что не дает нам поднять результаты системы, но и то что обеспечивает (подняло) их до текущего уровня. ...


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

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


Определение ограничения системы:
www.tocico.org/?page=toc_systems

CONSTRAINTS – factors or elements that determine how much the system can accomplish.
Внимательно смотреть на рисунок, на Block и Lift - они не просто так там нарисованы. Есть факторы, которые Block, а есть которые Lift. И это все ограничение.

И чуть ниже - policy constraint нет (исключен примерно в 2000). Policy constraint не выдерживает 5 фокусирующих шагов - это obstacle (препятствие). А еще есть треугольник ограничений - они перетекают (связаны) друг в друга (это ограничение прохода). Но вот квадрата не получится - policy не перетекает в time, capacity, market. Есть ограничение поведения (не видел правда англоязычного термина) и в нем как раз требуется получение согласия на изменения. Согласие, а не смена формы оплаты! Да может быть для согласия понадобится изменить форму оплаты/распределения доходов, но совершенно не обязательно, и не обязательно на какую то одну заранее придуманную.

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

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


6 года 5 мес. назад - 6 года 5 мес. назад #46839 от Александр Филонов

Роман Пантелеев пишет:
CONSTRAINTS – factors or elements that determine how much the system can accomplish.
Внимательно смотреть на рисунок, на Block и Lift - они не просто так там нарисованы. Есть факторы, которые Block, а есть которые Lift. И это все ограничение.

И чуть ниже - policy constraint нет (исключен примерно в 2000).
Policy constraint не выдерживает 5 фокусирующих шагов - это obstacle (препятствие). А еще есть треугольник ограничений - они перетекают (связаны) друг в друга (это ограничение прохода). Но вот квадрата не получится - policy не перетекает в time, capacity, market.


А чего же рельсы не убрали?:laugh:

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


en.wikipedia.org/wiki/Theory_of_constraints

Или секта Одеда еще туда не добралась?:laugh:

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


6 года 5 мес. назад #46840 от Сергей Жаринов

Александр Филонов пишет: ... Или секта Одеда еще туда не добралась?


Похоже на то.

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


6 года 5 мес. назад - 6 года 5 мес. назад #46841 от Роман Пантелеев

Александр Филонов пишет: А чего же рельсы не убрали?:laugh:

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


en.wikipedia.org/wiki/Theory_of_constraints

Или секта Одеда еще туда не добралась?:laugh:


Че уж тогда секта - Одеда? Тогда секта Голдратта - Одед классическому ТОС учит, который через Голдратта прошёл. А у Деттмера получается своя секта? Вы из которой будете?

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


6 года 5 мес. назад - 6 года 5 мес. назад #46871 от Сергей Жаринов

Роман Пантелеев пишет: ... Внимательно смотреть на рисунок, на Block и Lift - они не просто так там нарисованы. ... И чуть ниже - policy constraint нет (исключен примерно в 2000). ... А еще есть треугольник ... .


Роман, в соответствии с Вашим указанием внимательно смотрел на рисунок. Вероятно, должен был увидеть там какую-то сакральную истину. К сожалению, не увидел. Если кто-то откуда-то исключил policy constraint, то это было, скорее всего, гораздо позже 2000 года. Дело в том, что у меня есть около десятка более свежих серьёзных книг, в которых это понятие активно используется. Но это не принципиально. Хоть горшком назовите (хоть ограничением, хоть элементом, хоть фактором, хоть препятствием), - суть от этого не меняется. В любом случае ЭТО сегодня мешает системе двигаться к её цели (правда, возможно, "цель" тоже уже "исключена"). И устранение ЭТОГО (не важно - за 5, 4, 3, 2 или даже 1 шаг) позволит повысить общую результативность системы.

P.S. А что касается треугольника, то он, как известно, рано или поздно всё равно "будет выпит - будь он хоть параллепипед, будь он круг, едрёна вошь".

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


6 года 5 мес. назад - 6 года 5 мес. назад #46872 от Роман Пантелеев
Не знаю что Вы там без меня пьете (я лично Ботукаль), но... Вы все таки используете негативную коннотацию, хоть и говорите что ограничение это что то хорошее. Как это может быть хорошим, если Вы встретив policy constraint тут же стремитесь его по-решить? Зачем уничтожать что то хорошее? На настоящем ограничении делают бизнес. Как можно делать бизнес на неправильной политике? Ну теоретически конечно можно - но практически задача не тривиальная. И да конечно раньше в ТОС так считали. Видимо кто то продолжает так считать. Даже книжки пишет. Правда не знаю как они собираются максимально использовать не правильную политику, а потом подчинять этому решению всю систему. А если это не возможно - наверное стоит признать, что это другая сущность, с иными свойствами?

Допустим у нас боттлнек - супер-мега-станок. Однако есть тупая политика, которая заставляет сотрудника этого боттл нека ходить на обед. В итоге мы теряем примерно 12% прохода. Вы всерьез полагаете, что эта политика - ограничение?! Ну прекрасно.
1.Identify constraint - нашли.
2.Exploit constraint - уже круто... размышляем как бы нам так ловко максимально использовать обед сотрудника.
3. Subordinate constraint - подчиним ка мы всю систему обеду сотрудника (святое че...).
4. Elevate constraint - а теперь давайте увеличим наше ограничение - даешь побольше обедов!!!

Поспорите с 5 фокусирующими? Или скажете, что на каком то волшебном основании мы в этом случае не должны 5 focusing steps использовать? Если будете тыкать пальцем в книгу (пожалуйста ФИО автора и название книги)

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


6 года 5 мес. назад #46873 от Роман Пантелеев

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


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

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


6 года 5 мес. назад #46874 от Aлександр Вьюшин
Роман, особенностям и потребностям ограничения?

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


6 года 5 мес. назад - 6 года 5 мес. назад #46876 от Александр Филонов

Роман Пантелеев пишет:
Допустим у нас боттлнек - супер-мега-станок. Однако есть тупая политика, которая заставляет сотрудника этого боттл нека ходить на обед. В итоге мы теряем примерно 12% прохода. Вы всерьез полагаете, что эта политика - ограничение?! Ну прекрасно.
1.Identify constraint - нашли.
2.Exploit constraint - уже круто... размышляем как бы нам так ловко максимально использовать обед сотрудника.
3. Subordinate constraint - подчиним ка мы всю систему обеду сотрудника (святое че...).
4. Elevate constraint - а теперь давайте увеличим наше ограничение - даешь побольше обедов!!!


Хороший пример, Роман!

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


1. Рельсы не убрали, а трамваи ночью не ходят. - Это пример ограничения в политике. Метро тоже не работает. В советское время магазины открывались в 10 утра (все на работе), обед в магазине с 13 до 14 (у всех обед на работе и в магазине обед), закрывались в 18. У всех окончание работы и у магазина тоже.:laugh: Политика.

2. Порт. Судно пришло в порт. Простой судна - десятки тысяч долларов убытков для судна и его клиентов (ждут материалы для батутов:laugh:) . А у порта пересменка (обед) каждые четыре часа. И три раза в сутки по 2 часа смена.

3. Рабочий ушел на обед (Ваш пример). Если это ограничение, то может его товарищ в другое время пообедает?;)

Подчиним ка всю систему "обеду"? А какой смысл спешить заводить судно в порт - если у вас потом обед? Или выходной? Или праздничный загул на 10 дней - новый год? Чему работа у вас подчинена - то что ее надо сделать или то что надо отдохнуть? Пообедать?;)


Elevate the constraint - я всегда переводил в смысле элеватор, подняться выше, на другой этаж (ограничение), на новую позицию :)

Если вы ликвидировали обеды (устранили ограничения низкого уровня, собрали низковисящие фрукты) - вам ничего не остается делать как elevate - заниматься устранением ожиданий в более сложных уровнях - внутри процесса работы (остановки, переналадки и пр), устранением муды (waste) в секундах, а не часах... и т.д. Это работа гораздо сложнее, и требует более высокого интеллекта.:laugh:

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

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