Теория ограничений Голдратта: знакомство с концепцией, кейсы применения в IT и программа-симулятор управления

Базовый менеджмент в производстве и в ИТ сводится к четырем фреймворкам:

• Тойотовский Lean Management;

• Теория ограничений;

• Just in time;

• Total Quality Management.

Все остальное, что есть на рынке – это итерации того, что есть в этих дисциплинах.

Мало того, эти фреймворки друг друга процентов на 70 повторяют, но у них разные подходы.

• Toyota Lean Management считает, что нужно улучшать все маленькие этапы цепочки, а потом все будет идеально. И почему-то ни у кого, кроме как у Toyota, не получилось это полностью внедрить.

• Теория ограничений считает, что важнее всего – найти ключевое ограничение системы и основные ресурсы направить на него.

• Total quality management считает, что самое важное – это качество, даже если мы опаздываем.

• Just in Time считает, что главное – сделать вовремя, а качество можно грумить.

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

 

 

По итогам этого ролика я хочу донести до вас две идеи:

• Первое – в любой вашей системе есть ограничения. Здесь это был мяч, у вас будет что-то сильно сложнее. Чаще всего люди стараются это ограничение как-нибудь отбить: «Как-нибудь перекрутимся». Но пока вы не начнете использовать ограничение максимально эффективно, и учитывать его в своей системе, ситуация не улучшится. Например, «ВкусВилл» имеет концепцию того, что они второй магазин – человек заходит в «Перекресток» или «Магнит», а потом заходит во «ВкусВилл». Это позволило им стать одной из крупнейших сетей в России. Если бы они претендовали на место единственного магазина, у них бы это, наверное, не получилось.

• Вторая история, еще более важная – людям всегда мало. Я часто вижу, когда в компании запускается какой-то процесс улучшения, и появляются энтузиасты. «Мы сейчас всем поможем! У нас будет бирюза! Все будет хорошо!» Хорошо бы это где-то ограничить. Потому что в какой-то момент это становится неокупаемым. Вы не можете людям дать все, что они хотят. Нужно четко описать себе границы, которые вы хотите.

Книгу «Цель» Голдратта читали многие. Но многие ли смогли ее применить? В этом большая проблема всех теорий. Нам рассказывают кучу кейсов, но, к сожалению, рассказывают только успешные кейсы, а неуспешные не рассказывают. Поэтому применить это на практике не получается.

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

 

Знакомство с концепцией теории ограничений Голдратта

 

Вся суть теории ограничений сводится к пяти шагам:

1. Поиск ограничения.

2. Анализ того, как им эффективно пользоваться.

3. Подчинение системы ограничению (про это я еще один видеоролик покажу).

4. Расширение или расшивка ограничений – только на четвертом шаге мы докупаем какие-то ресурсы

5. Проверка, куда ограничение перепрыгнуло. Как только вы расширили ограничение, оно появилось в другом месте. Если вы заранее анализируете систему, вы обычно знаете, где оно проявится, и можете к этому подготовиться.

 

Есть три вводных теории ограничений:

1. Все составляющие системы связаны между собой – но очень часто вам эти связи не видны.

2. Сложная система неуправляема.

3. Сложных систем в реальности не существует.

Видимые противоречия этих тезисов объясняются очень просто.

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

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

 

Вот есть система А и система Б. Какая из них, по-вашему, сложнее?

Сложная система требует больше ресурсов для управления, чем простая. Если мы считаем, что все эти квадратики плюс-минус равнозначны по стоимости и ресурсам, то:

• в системе Б нам нужны ресурсы всего на два квадрата, потому что ими мы управляем всей системой;

• а в системе А нужны ресурсы на все четыре.

 

При управлении сложной системой главное – понять, в чем ее проблема

 

Люди, которые пришли на тренинг по TOC – это тоже в каком-то смысле сложная система. У каждого из них есть определенные ожидания. Сочетание этих ожиданий может иметь смысл. Для примера накидаю стандартные ответы от людей, которые в разное время приходили на мои тренинги, в основном, корпоративные.

 

«Решу все свои проблемы» – так бывает, человек приходит и говорит: «Я в ТОС искренне верю всей душой, 10 лет изучаю Голдратта, сейчас разберусь и решу все свои проблемы». Такое бывает, но редко.

 

«В результате меня уволят» – это не шутка, так тоже бывает. Человек, наслушавшись каких-то обучений, приходит за повышением зарплаты, его увольняют, или он уходит сам.

 

«Я смогу доказать коллегам свою точку зрения» – у каждого из вас есть своя точка зрения. Ее очень часто бывает трудно донести и кого-то убедить ее принять.

 

«Мы поругаемся с коллегами в очередной раз» – это действительно часто случается, особенно с новым фреймворком.

 

«Придумаю новое решение для нынешних проблем» – такое ожидание встречается у тех, кто осознанно идет на тренинг.

 

«Пропущу рабочий день и не успею сделать важное» – это гарантированно касается всех, кто пришел на тренинг.

 

«Отвлекусь от рутины и отдохну».

 

«Нагрузят новыми нерешаемыми проблемами» – если мы проводим тренинг в корпорации, я обычно даю какую-то домашку, потом спрашиваю ее, и так далее.

 

Все это кажется очень разнородными проблемами, каждая из которых – отдельно стоящая.

Но по факту теория ограничений учит их увязывать между собой, например, так:

• Отвлекусь от рутины и отдохну.

• Появится энергия, придумаю новое решение для проблем.

• Докажу коллегам точку зрения.

• И решу все свои проблемы (или часть своих проблем).

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

 

Или негативная ветка.

• Пропущу рабочий день и не сделаю важное.

• Нагрузят новыми проблемами.

• Поругаюсь с коллегами.

• Меня уволят или сам уволюсь, потому что достало.

 

В целом вся теория ограничений учит:

• сначала находить точку приложения сил – понять, где проблема;

• и выстраивать логические цепи для разрешения этой проблемы.

Вторая часть – сложнее. Потому что «где проблема» вы чаще всего и так знаете. А качество решения проблем зависит от вашей когнитивной функции и насмотренности. Чем больше вы решали проблем, тем лучше вы решите их в будущем. И здесь ни одна известная мне система не помогает.

Нужно четко понимать ограничения теории ограничений:

• Она покажет вам, где проблема – возможно, это будет новое место, неожиданное для вас.

• Но готового решения проблемы не даст. Она попытается вас направить – там есть раздел «мыслительные процессы». Но это не работает, если человек сам по себе не обладает фантазией, воображением и опытом.

 

История Теории ограничений и взаимосвязь ресурсов в потоке

 

Теория ограничений появилась в конце 70-х годов и выросла из производственного управления.

В то время промышленные предприятия во всем мире управлялись точно так же, как в 20-х, когда они системно возникли – сначала возник конвейер Форда, потом его начали размножать, и к 20-м годам это стало стандартом.

Проблема только в том, что в 20-е годы на одном заводе номенклатуры было десятки, в редких случаях сотни изделий. А в 70-х на заводах были тысячи и десятки тысяч номенклатуры единиц изделий. И заводам приходилось решать, что и когда производить. Человеку удерживать в голове всю эту сложную схему было почти невозможно, поэтому на заводах появились компьютеры, но они справились тоже плохо.

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

 

Смотрите, у нас есть линия, в которой есть 6 станков. Они производят в час 15, 16, 14, 10, 12, 13 изделий. Каждый станок перерабатывает полуфабрикат от предыдущего – на выходе готовый продукт.

При этом проходная мощность этой линии – максимум 10 изделий в час.

Что нам нужно сделать, чтобы ее увеличить? Повысить мощность четвертого станка хотя бы до 12. Потом до 13, потом до 16 – в идеале у нас получится сбалансированная линия. Это то, что пытаются сделать многие управленцы.

 

Но у этой линии выходная мощность тоже 10 в час.

 

А как вы думаете, если производительность сбалансированной линии будет 90%, какой будет ее выходная мощность?

 

Выходная мощность такой линии будет от 58 до 90% в зависимости от конкретного времени, когда все эти станки 10% времени не работают.

 

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

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

 

Разбалансированная мощность – это то, от чего все пытаются избавиться. А на самом деле это то, чем нужно научиться управлять.

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

 

Детали: 5 шагов для выявления ограничения

 

Напомню пять шагов теории ограничений систем – так они выглядят для визуалов:

1. Мы находим ограничение системы

2. Решаем, как его использовать

3. Подчиняем ограничению работу всей системы

4. Расшиваем

5. И если ограничение перепрыгнуло, смотрим, где оно появилось.

Шаг «Найти ограничение» выполняется эмпирически. Если вы управляете людьми, найти ограничение системы обычно не очень сложно. Просто посмотрите, у кого больше задач в работе. У кого больше всего – он обычно и ограничение. Больше – это не на 3-4 задачи больше. Это обычно 10, 15, 18, 80.

И в российском ИТ эти 80 задач у какой-нибудь девочки. Я никогда не понимал, почему так. Но есть какая-нибудь трудолюбивая женщина, у которой есть 80 задач, а у мужиков рядом – по 15-18. Эти 15-18 может быть сложнее. Но очевидно, что на звене перед ограничением запас количества задач всегда будет высоким. Вы систему так выстроили, что перед ограничением скапливаются запасы.

ТОС выстроен чисто эмпирически. Там нет формул, хотя Голдратт пытался их придумать. Вы назначаете кого-то ограничением и пытаетесь его расшить. Если система не улучшает свою работу, вы говорите: «Ошибся, иду к другому».

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

 

Что значит шаг «Решить, как полностью использовать ограничение»?

Первое место, где я внедрял ТОС – компания IT Construct, которая продает дорогие сайты на Битрикс. Очень быстро выяснилось, что у них ограничением является технический директор. Интеграция 1С с Битрикс – вещь непростая, но он это умел. А они одновременно делали от 5 до 12 сайтов. И в каждый момент времени все упиралась в него, и он должен был эту интеграцию завершить, оптимизировать или проверить ошибки.

Они сделали очень просто – договорились с ним, что он работает весь день. Ему разрешили курить на рабочем месте, ему приносили еду, с него сняли все другие задачи, хотя он был зам. генерального. Он приходил с утра, садился в 10 и в 18 вставал. Он был трудоголик, ему нравились сложные технические задачи. И в итоге через месяц оборот компании увеличился на 40 процентов.

ТОС всегда дает очень быстрый результат, если вы его используете верно. Или не дает, если используете неверно или вас плохо научили.

Про шаг «Подчинить ограничению работу всей системы» – я вам покажу видео.

А шаг «Расширить ограничение» – очевидно. Они в итоге наняли второго человека, который это умеет делать и т.д. Но сначала они сделали так, что он за день пропускал через себя не две задачи, а восемь. И это помогло.

 

Подчинить ограничению работу всей системы – не значит подчиняться ему

Посмотрите видео и скажите, что в нем является ограничением:

 

 

Ограничение в этой системе – гитара. Это означает, что всем пятерым – неудобно.

Но идея не в том, что ограничение – это плохо. Нужно понимать, что мы ограничение не устраняем. Ограничение – это то, что требуется для достижения цели.

Бывает так, что расшить ограничение – либо дорого и не окупится. Либо так прикольнее – если бы у них было 5 гитар, им никто бы 15 миллионов просмотров не накидал.

Но я вам сейчас хочу рассказать про то, что значит подчинить систему ограничению. Когда мы говорим «подчинить систему какому-то вашему подчиненному» – это не значит, что это ограничение вами командует.

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

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

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

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

 

Причины опозданий проектов и методы повышения эффективности

 

Расскажу некоторые вводные по теории ограничений.

Сколько вы знаете причин опозданий проектов? Вам нужно понимать, что опоздание – это следствие каких-то причин. Время кончилось – это следствие, а не причина. И планирование плохое – это следствие чего-то. Есть предпосылки и корневые причины такому факту.

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

Причины опозданий проектов называются:

• Студенческий синдром

• Кто громче крикнет

• Караван

 

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

Что делает нормальный человек, у которого есть другие дела?

• 60 слов за 60 дней – 3 минуты в день на слово, вообще не проблема. И откладывает этот вопрос, потому что есть чем заняться.

• Через 30 дней у самого дисциплинированного звонит будильник – через месяц экзамен. Он такой: 60 слов через 30 дней – тоже не проблема.

• За две недели до экзамена он открывает список, выучивает за три минуты пять слов, говорит: «Это оказалось быстрее, чем я думал» и откладывает.

• Вечером перед экзаменом он запоминает 25 слов – за вечер больше выучить не получается – идет сдает экзамен на тройку, и счастливый уходит.

 

Другой пример – у нас есть девушка, к ней приходит молодой человек. ИТ-шник, хорошо зарабатывающий. Говорит: «Дорогая, я получил премию 10 тысяч евро. Через два месяца мы с тобой летим в Дубай и все эти деньги потратим тебе на одежду. Я могу либо сжечь эти деньги, либо потратить так – переубедить меня невозможно».

Как будет реагировать девушка?

• Посмотрит магазины, где скидки. Может быть, нужно перенести поездку на февраль, когда в Дубае сезон скидок.

• Маршрут построит.

• Гостиницу забронирует.

• Узнает, какая в Дубае через два месяца будет погода, хотя прогнозу погоды в Питере она на неделю вперед не верит

• Купит одежду получше, потому что не поедет же она в Дубай непонятно в чем.

 

Две задачи, обе – через 60 дней. Почему такая разная реакция?

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

Бороться с ней очень просто. В случае английского языка вы говорите – у тебя через три дня экзамен профессиональный по английскому языку, нужно всего лишь 60 новых слов выучить. Предупредить не мог, так сложились обстоятельства.

Он учит-учит-учит, три дня – нормальный срок, чтобы выучить. А потом вы говорите: «Перенеслось, через 57 дней экзамен будет».

Шутки-шутками, но если у вас человек часто опаздывает с задачами, прекратите ставить ему три задачи на неделю. Ставьте ему по задаче на полтора дня. И контролируйте это.

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

Поэтому не пять задач на две недели, а одна задача на полтора дня.

И у меня есть хороший референс того, что человек начал делать задачу, которую я ему поставил. Это если он ко мне в тот же день приходит с вопросом. Если не пришел, я к вечеру понимаю, что он ничего не делал. Спрыгиваю к нему и спрашиваю: «Что сделал?»

Это, конечно, микроменеджмент, и он нужен не со всеми сотрудниками. Но если вы не увольняете человека со студенческим синдромом, это решается так – вы ставите ему одну задачу на короткое время и контролируете.

 

Другая причина опозданий – кто громче крикнет.

Допустим, есть веб-студия, которая делает сайты-визитки – 10 дней на один сайт. А деньги с заказчика они берут за аренду, а не за изготовление – по доллару в день с момента изготовления сайта.

И вот к ним приходит три заказчика и заказывают три сайта. Для каждого сайт делать – по 10 дней.

• Через 10 дней будет готов первый,

• через 20 – второй,

• через 30 – третий.

И они за этот месяц заработают 20 долларов с первого сайта, и 10 – со второго. 30 долларов.

 

А как происходит в реальной профессиональной жизни?

• На пятый день приходит второй заказчик, говорит: «У меня гендир уезжает за границу, давай ты мне сделаешь хотя бы первый экран, а дальше – хоть месяц делай, мне уже неважно. Я с ним только дизайн согласую».

• Клиента жалко терять, мы идем ему навстречу, начинаем делать. На 10 день приходит третий заказчик, говорит: «У вас на сайте написано, что изготовление сайта – 10 дней, а у вас ничего не сделано. Либо я деньги забираю, либо делайте». Деньги еще жальче терять, и мы начинаем делать для третьего.

• На пятнадцатый день приходит первый заказчик, говорит: «Вы мне сказали, что я первый. У меня склады запущены, логисты наняты, все работает. Реклама запущена, сайта нет. Вы обалдели что ли?»

Мы делаем первый сайт к 20-му дню. Второй – к 25-му и третий – к 30-му. И все это – очевидная история.

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

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

В той самой компании, где техдира приковали цепями к столу – они сделали три вещи.

• Во-первых, когда они расшили ограничение в виде технического директора, оно перепрыгнуло на отдел дизайна. Это очевидно, потому что заказчики сайтов, особенно бизнесовые, в технологиях понимают мало, в математике понимают мало, в 1С понимают еще меньше. Но в дизайне – все понимают. И это приводит к тому, что у них на изменение дизайна сайта запланировано 15-18 итераций, но ни разу меньше 80-ти не получилось. Потому что заказчик показал своему главбуху, та показала своему мужу, показали секретарше, любовнице – у каждого есть мнение про дизайн. И страдал от этого отдел дизайна, потому что все остальные департаменты были им радикально недовольны.
  Всего в компании было четыре департамента – это большая студия, человек 30 или 40. Они договорились, что у любого департамента есть право дважды в месяц внезапно ставить задачу дизайнеру, не согласовывая. Но с третьего раза человек, который пришел к дизайнеру, должен из своего кармана отдать дизайнеру 1000 рублей за это. Дизайнеры заработали за месяц 6 тысяч, из них пять – дал гендир.
  И внезапно все изменилось. Потому что аккаунты, когда им звонил клиент и предлагал что-нибудь изменить, совершенно изменили свою риторику. Они говорили: «Мы сейчас сходим к дизайнерам, поговорим с ними о том, могут ли они это взять и когда. И скажем вам, когда мы эти изменения сделаем».
  Они шли к дизайнерам, дизайнеры говорили: «Ближайшие четыре дня мы делаем срочный проект, а это задачка на два дня. Давай через полторы недели это сделаем».
  Аккаунты возвращались к заказчикам и говорили: «Это изменение мы готовы сделать через полторы недели. Денег мы с вас за это не берем, но договор удлиняем на полторы недели. Согласны вы на это или нет?» И обычно заказчики не соглашались. Такого рода отдельные хаки работают, уменьшая влияние таких форс-мажорных обстоятельств.

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

• У них на спинке стула висит «Не дергайте меня до 14:00» или «Не трогайте меня за плечо, лучше напишите мне в Телеграм».

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

 

Третья история – караван.

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

• Первая занимает два дня.

• Вторая – шесть.

• Третья – четыре.

Через сколько весь проект будет выполнен? От 6 дней до бесконечности. Я обычно закладываю 8-9 дней.

Какие здесь ошибки бывают?

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

А теперь давайте предположим, что это не задача, а департаменты. Первый – юристы, вторые – продажники, а третьи – бухгалтерия. Сотрудники каждого из этих департаментов хотят премию, хотят заработать больше, чем им по штатке положено. Возможно, им даже премия согласована, и они ее хотят получить. Но им же нужно обосновать, что они премию заслуживают. И каждый из них отделу ИТ рассказывает: «Ребята, внедрите нам такую вещь, мы будем делать это быстрее».

Но внедрять любые улучшения в Задачу №1 и в Задачу №3 не имеет никакого смысла, потому что проект закончится только после окончания Задачи №2. Любые инвестиции и ускорения процессов, которые не являются ограничением в системе – это просто сжигание денег. Но каждый из этих людей имеет волю и доступ к ушам генерального.

Когда вам прилетают такого рода задачи, нужно уметь доказывать, что здесь оптимизация ради оптимизации не нужна. Если система не упирается в это ограничение, то это делается зря, потому что процесс изменится, и станет хуже всем остальным окружающим. Денег вся система больше не заработает. Если эти люди получат премию, система еще и потратит больше. Зачем это нужно? Непонятно.

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

В этой ситуации я прошу его поменять субъектность. Я ему говорю: «Давай ты переформулируешь это от себя – не система так хочет, а я так не могу».

И он начинает: «Я не могу это доказать». Я говорю: «Хорошо, скажи, какими аргументами ты доказывал то, что можешь». Обычно там не много аргументов: «Я не знаю», «Я не умею», «Я не знаком с каким-то человеком». Если я – не проблема, вы точно можете ее исправить. Если они – злодеи, опускайте руки, это не работает. Вам любую проблему, с которой вы сталкиваетесь и не можете решить, нужно переформулировать в «Я не могу/не умею/не знаю» и узнать, смочь, суметь.

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

С отдельным: «Это нужно/это не нужно, это стоит 8 тысяч, а это – 8 миллионов» спорить гораздо проще. Когда у вас есть систематизированный подход к тому, почему что-то получается, а что-то нет, с вами приходится вступать в дискуссию. И вам нужно учиться системно-гуманитарно обосновывать то, что вы считаете верным. ТОС в этом сильно помогает.

 

Показатели ТОС и их связь с традиционными операционными показателями

 

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

Два традиционных операционных показателя:

• Прибыль.

• Возврат на инвестиции.

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

Почему их два – тоже понятно.

• Если у вас прибыль – миллион долларов, и вы вложили миллион долларов, это одна история.

• А если у вас прибыль – миллион долларов, и вы вложили сто миллионов долларов – совершенно другая.

Но в целом стратегически этих двух показателей достаточно.

 

А в теории ограничений – три показателя, они другие:

• Проход

• Инвестиции

• Операционные затраты

Сейчас я каждый из них объясню.

 

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

Но нужно четко понимать, что маржа считается по-разному, а ТОС – одинаковым образом.

 

На примере телефона, проход – это стоимость изготовления деталей и сборки. Эта стоимость вычитается из цены.

В проходе мы учитываем только переменные расходы, относящиеся к единице товара.

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

 

Инвестиции – это все деньги, связанные внутри организации.

Инвестиции – это стоимость активов по цене покупки минус амортизация плюс все товарно-материальные ценности.

А в ИТ все незаконченные задачи – это тоже инвестиции. Это мало кто осознает, но, пытаясь запихнуть как можно больше задач, вы грузите компанию. Если у вас в процессе 18 проектов, они закончатся в полтора раза дольше, чем если бы вы их делали по отдельности.

Инвестиции в теории ограничений – это все связанные на складах товары и незаконченные задачи, оцененные по цене продажи.

 

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

 

Как у нас связываются показатели ТОС с традиционными показателями?

• Обычно прибыль считается по формуле:
  Прибыль это Доходы минус Затраты.

• А в случае теории ограничений:
  Прибыль это Проход минус Операционные затраты.
  Где Проход – это Доход минус Полностью Переменные Расходы.

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

 

Практическая задача: какой продукт выпускать заводу?

 

Пример:

• У нас есть завод, на котором есть четыре станка – A, B, C, D.

• Каждый станок работает пять дней в неделю, восемь часов в день – это 2400 минутная рабочая неделя.

• Есть товарные материалы, которые закупаются для сборки – ТМ1, ТМ2, ТМ3. Все они стоят по 20 долларов.

• И есть два вида продуктов – P и Q.

  • P мы продаем по 90 долларов за штуку, 100 штук в неделю.

  • Q мы продаем по 100 долларов за штуку, 50 штук в неделю, больше рынок не покупает.

• Каждый станок может использоваться и для продукта P и для продукта Q – в звеньях видно, что станок сначала работает здесь 15 минут, а потом здесь – 10.

Что приоритетнее производить для максимальной прибыли:

• Все 100 P и сколько-то Q (меньше, чем 50)?

• Или все 50 Q и меньше, чем 100 P?

Напоминаю, я вас учу теории ограничений – не зная, что в системе является ограничением, мы управленческие решения принимать не можем.

Мы не знаем, что выгоднее – P или Q. Но я вам сейчас покажу, как это считается.

 

Проход (маржа) для P считается очень просто: мы берем 90 долларов, по которым он продается и отнимаем себестоимость материалов – для P используется TM1, TM2 по 20 долларов и купленная деталь за 5 долларов.

Tp = 90 – (20 + 20 + 5) = 45

Получается, что проход для P = 45 долларов.

Считаем проход для Q – там используется TM2 и ТМ3 по 20 долларов.

Tq = 100 – (20 + 20) = 60

В рамках этой логики многие решают, что теперь делаем Q – маржа больше

Но первый шаг теории ограничений – найти в системе ограничение. А ограничением является всегда один из станков. У нас, напоминаю, доступно только 2400 минут каждого станка в неделю.

И мы смотрим, является ли станок А ограничением?

• P мы можем продать 100 штук. Чтобы сделать P на A, нам нужно 15 минут. Для 100 штук P мы должны 15 * 100 = 1500 минут.

• Для Q нам нужно 10 минут станка A. Для 50 деталей Q нам нужно 10 * 50 = 500 минут.

Итого, нам нужно 2000 минут станка A, чтобы выпустить и 100 P, и 50 Q. А у нас 2400 минут. Это означает, что станок A ограничением не является.

Теперь посчитаем, сколько минут B нужно, чтобы все сделать?

• Для P снова нужно 15 * 100 = 1500 минут

• Для Q нам нужно 15 * 50 = 750 минут для ТМ2 и 15 * 50 = 750 минут для ТМ3.

Итого 3000 минут. А у нас 2400 минут. Итак, станок B становится ограничением нашей системы. Сейчас мы это узнали. Станки C и D ограничениями не являются, можете, если не верите, пересчитать.

Мы сейчас узнали проход, мы узнали, что является ограничением. А сейчас – хитрый фокус: что нам делать – P или Q? Мы должны выбрать то, что при изготовлении с ограничением приносит максимум денег. Как мы это считаем?

• У нас проход для P = 45 долларов. Обрабатывая P на станке мы тратим 15 минут. Мы делим 45 долларов на 15 минут и выясняем, что мы зарабатываем 3 доллара в минуту, когда изготавливаем P на B.

• А Q нам нужно 30 минут для каждой единицы. А зарабатываем мы 60. Мы 60 долларов делим на 30, получаем 2 доллара в минуту.

Так мы принимаем быстрое управленческое решение, что нужно делать все P, а потом Q, потому что 3 доллара в минуту – гораздо круче, чем 2.

Логика такая – мы находим ограничение в системе. Чаще всего – эмпирически или очень простым расчетом.

Причем с людьми это работает. Мы смотрим, где ограничение – где человек зарабатывает максимум денег. И фигачим этого как можно больше – сколько купит рынок. Вот и все. У нас всегда есть проблема очень долгого согласования принятия решений. Если в компании внедрены такого рода подходы, вам можно очень быстро принять решение, сколько мы продаем.

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

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

 

Работа с программой-симулятором управления

 

Программа Goldratt Simulator разработана в 1995 году – ее в свое время придумал для обучения институт Голдратта.

Вам нужно запустить GSim.exe и там открыть Params.310.

 

 

Это завод с кучей станков, на котором зарабатывают деньги.

Мы производим три вида товаров – они называются по линиям, на которых стоят – A, D и F. Они продаются по 180, 240 и 180 долларов – это можно увидеть, если нажать кнопку INFO. Будет видно, сколько стоит сырье за штуку, и цена товара.

Верхняя строчка – 40, 50, 40 – это недельный спрос. Если вы сделаете больше, рынок все равно не купит.

В начале недели у каждого 10000 долларов. Чтобы продать товар, нужно купить сырье и дотащить его до верхнего голубого станка. Как только голубой станок перерабатывает деталь, у вас Cash прибавляется.

Чтобы купить сырье, мы на нижний овал кликаем – у нас возникает количество, которое мы можем купить. Например, мы вписываем 5, жмем ОК, у нас появляется 5 единиц сырья и списались деньги. Поэтому не закупайте сразу все, покупайте понемногу.

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

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

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

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

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

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

И последняя цифра, которая все усложняет – при установке на новое место станок настраивается столько секунд, сколько написано слева от него.

Если на квадрате станка слева написано setup, он настраивается столько секунд, сколько здесь написано. idle – станок простаивает, перед ним нет сырья, prod – это он производит. Вы увидите, когда до этого дойдет.

Имея все эти данные, вам нужно решить, что вы сначала делаете – А, D или F, закупить сырье и расставить все станки.

Мы играем пять дней. Один день – 8 минут. В конце каждого дня будет выскакивать диалоговое окно, в нем будет записан проход за день.

 

Физическая природа ограничения

 

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

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

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

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

Часто ИТ-отделы делают что-то, что рынку не нужно. Но ограничение в данном случае – не внутри производительности программиста, а внутри того, кто им ставит задачи. Нужно понять, почему он это делает так. Он же не злодей обычно, у него есть какая-то логика.

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

И последнее видео, которое касается ограничений системы:

 

Виды ограничений

 

Ограничения бывают четырех видов:

• Ограничение внутреннего ресурса – я вам рассказывал именно про него. С ним более-менее понятно, как справляться, хотя бы теоретически. И с этим можно жить.

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

• Ограничения времени. Это когда вам нужно за период времени сделать что-то, и это намного важнее, чем сделать на максимальном качестве. Пожарные, МЧС, Скорая, армия – это все про ограничения времени.

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

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

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

 

Выводы

 

В России любят Lean, а ТОС используют в основном только на производстве, в ИТ мало где. Потому что ТОС – не интуитивная вещь, его сложно объяснять. Мне проще всего объяснить ТОС с помощью GSim.

К сожалению, в ТОС сложно разобраться за день или за месяц, этим придется заниматься полгода-год. Но если для вас ТОС применим, попробуйте его, объясните коллегам, почитайте «Цель» Голдратта или его «Теорию ограничений».

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.

Мастер-класс "Вводный практикум по Теории ограничений ТОС".