Основы ТОС

Как строить процессы...

2026-01-12 14:27 Почитать
Если существуют какие-то давно известные и очевидные проблемы некоторой сферы, решение которых вроде бы понятно всем, но при этом проблемы до сих пор не решены, — значит, эти «очевидные» решения не работают. Например, потому что действительно эффективные решения вроде «мыть руки» — приживаются.
А значит проблемы, которые остаются нерешёнными, требуют иного подхода: разбираться с ними нужно не так, «как принято», а через научный подход, вместо логики «авторитетов». Теория ограничений — это именно такой управленческий подход.
В этой статье я расскажу про процессы и микроменеджмент. Про то, что такое процессы, зачем строить процесс, как строить процессы, как внедрять процессы, как контролировать… Вы всё ещё читаете? Что такое микроменеджмент, когда нужен микроменеджмент, когда не нужен микроменеджмент, а ещё дам инструкции… Вы уже конспектируете?
Надеюсь, кто-нибудь из тех, кто читает эту заметку, хихикнул, потому что именно так мы обычно подходим к построению процессов. Формально такой план звучит логично. Если последовательно ответить на эти вопросы, кажется, что можно разобраться с темой. Но, во-первых, это невероятно скучно. А во-вторых — куда важнее — такой подход не работает. Ведь всё это уже давно можно нагуглить (или спросить у ChatGPT). Перечисление фактов и правил не приводит к результату. Даже если я подробно расскажу вам всё это, вряд ли завтра вы вдруг начнёте строить процессы лучше, чем вчера.

А в чём цель?

В чём моя цель как рассказчика? Рассказать? Но зачем — ведь всё это можно найти и прочитать самостоятельно. Научить? Я не верю, что кого-то можно «научить». Можно только научиться. Заинтересовать? Возможно. Но глобально я пишу заметки и провожу обучения ради другого — чтобы помогать людям быстрее достигать своих целей. Но чтобы помогать быстрее достигать цели, нет смысла рассказывать какие-то прописные истины, есть смысл разрушить какие-то блокирующие убеждения и корневые проблемы.
Хорошо, а какая тогда цель у построения процессов? Зачем мы говорим, что нам нужно «наладить процессы»? Обычно ответ звучит так: «Чтобы ускориться». Но ускориться — куда? В каком направлении? А ещё: «Процессы позволят снизить нагрузку». На что? Или: «Чтобы избежать ошибок». Но зачем? Я спрашиваю не потому, что не могу придумать ответ. Я задаю эти вопросы, потому что чаще всего вдумчивый ответ на них оказывается совсем не очевидным.
Самый позитивный повод заняться процессами: «Чтобы быстрее достигать цели». Но тогда следующий вопрос: а какая у вас цель? Какую именно цель вы собираетесь достигать быстрее?

«Строить процессы» — это решение

Очень часто, когда мы начинаем говорить о процессах, звучат фразы вроде: «Надо строить процессы», «Нужно выстроить процессы», «Как построить процессы». Но строить процессы — это решение.
В Теории ограничений есть очень классный вопрос, который невероятно полезно задавать почаще — и в первую очередь самому себе:
Если это решение, то в чём проблема?
Слишком часто попытка «построить процессы» начинается примерно с такого списка «проблем»:
  • Процесса нет
  • Процесс не описан
  • Ответственные не определены
  • Нет регламентов…
Но всё это — не проблемы. Это снова решения. И если бы настоящая проблема действительно была в этом — что ж, отлично: возьмите и просто сделайте. Описать процесс, назначить ответственных, написать регламенты — звучит выполнимо. Если у вас этот пусть сработает — замечательно. Лучше тогда бросить чтение этой статьи и пойти работу работать.
Но часто так не получается. Часто, когда мы говорим: «Вот не описан процесс, сейчас мы нарисуем его на бумажке, внедрим — и всё поедет» — оно так не едет, или едет не туда, или не решает проблему, которую стоило бы решить.
Потому что проблема не в том, что «процесс не описан», «ответственные не определены» и «регламентов нет». Вы явно собирались решать что-то другое.

Эффективная формулировка проблемы

Во-первых, проблема должна регулярно повторяться. Потому что построение процесса — это довольно трудоёмкая задача: нужно тратить время и силы не только на его создание, и внедрение, но и на поддержку, чтобы он не развалился.
Во-вторых, формулировка проблемы не должна содержать решения. Иначе мы замыкаем себя в одном единственном варианте — том, который уже заложили прямо в формулировку.
В-третьих, формулировка проблемы не должна содержать обвинение. Почему это крайне важно, когда мы говорим про процессы? Процессы — это истории про контроль. Как мне кажется, чаще всего непреодолимая тяга всё контролировать появляется от ощущения, что вокруг все, ну как минимум, не очень сообразительны: «Люди вокруг недостаточно замотивированы», «Они ленятся», «Они тупят», «Они перекладывают ответственность» — и поэтому, якобы, нужен контроль: «Сейчас мы внедрим процессы и заставим всех работать как надо».
Но с точки зрения Теории ограничений (и теперь уже и с моей) — это плохое начало решения проблемы. Если проблема формулируется как «Кто-то не молодец», то пытаться зарегламентировать его в жесткую систему — это странное решение. А если проблема звучит как «Все вокруг не молодцы», то это уже абсурд: все одинаковые, а я нет.
Когда в формулировке проблемы есть обвинение, мы автоматически делаем проблему нерешаемой. Максимум, на который мы можем рассчитывать: превратить работу в детский сад и заняться тотальным присмотром. Но, надеюсь, это не то, чего вы хотите.
Да, понятно, что уйти от обвинений бывает сложно — особенно когда мы уже в который раз срываем сроки и обязательства. Но пока мы объясняем всё обвинениями, мы не сможем придумать качественное решение и продвинуться дальше.
Есть ещё одно важное правило: формулировка проблемы не должна требовать пояснений, какие негативные последствия она вызывает. Коротко — не должна вызывать вопрос «И чё?».
Допустим, проблема сформулирована как: «У нас не описаны процессы» — Ну и что, что они не описаны? Или: «У нас не разделены зоны ответственности» — Ну не разделены зоны ответственности и не разделены. Ну и что? Или: «Нам сложно найти ответственного» — Ну сложно найти ответственного, ну и что? «У нас есть ошибки» — Ну есть у вас ошибки, ну и что?
Как мы страдаем, как нам кажется, из-за того что у нас не описаны процессы? Крайне важно сформулировать проблему так, чтобы она была очевидно негативной. Только после этого имеет смысл переходить к её решению.
А в конце этой статьи есть ссылка на статью про инструмент ТОС для формулирования проблем (НЖЯ).
Допустим, мы разобрались, в чём именно проблема, понимаем, что именно хотим решать и почему. Теперь вроде бы можно переходить к придумыванию и построению процессов. Как это делать? Если честно — как угодно. Есть множество способов описать процесс: в виде схемы, текста, таблицы или картинки. Не вижу большого смысла подробно рассказывать об этом — это легко можно нагуглить. Вместо этого я расскажу, как гарантированно завалить построение процессов. Что именно нужно сделать, чтобы процесс точно не взлетел?

Как гарантированно завалить построение процесса

Вредный совет №1: Начать с обвинений

Во-первых — и я ещё не раз это повторю — худшее, что можно сделать, это начать с обвинений. Если вы начинаете выстраивать процессы, исходя из установки «кто-то у нас бракодел», ничего хорошего не выйдет, не будет вам счастья. Причём дело не только в том, что вы не найдёте решения. Когда обсуждение начинается с обвинений, становится невозможно докопаться до реальных проблем.
Люди моментально занимают оборонительную позицию. Почему? Потому что если вы ищете виноватого, значит, вы ищете того, кого можно наказать, пристыдить, уволить или повесить на него ответственность. В такой атмосфере никто не будет помогать. Они не будут участвовать ни в поиске проблем, ни в анализе причин, ни тем более в построении процессов. Лучшее, на что вы можете рассчитывать — эстафета по перекидыванию ответственности
Поэтому крайне важно не начинать с обвинений. Нам нужно искать реальную проблему, и для этого нам нужны союзники — люди, которые будут вовлечены и заинтересованы в решении. Без этого построение процессов с самого начала обречено на провал.

Вредный совет №2: Создать конфликт интересов

Следующий способ гарантированно завалить построение процесса — создать конфликт интересов. И моё любимое — это использование KPI, но не в смысле показателей, а в смысле любых показателей, связанных с финансовой мотивацией.
Есть куча способов обойти систему «KPI+деньги» — и эта система ведет вообще не туда, куда мы думаем, что она должна привести. Но система «KPI+деньги» — не единственный способ, чтобы создать конфликт интересов, не обязательно сразу переходить к финансовой мотивации. Но надо очень чётко понимать, что как только вы кого-то мотивируете на достижение красивых цифр или на соблюдение каких-то метрик, и сотрудник начинает смотреть только на это, — вы опять в беде. Это всегда приводит к локальной оптимизации, и становится совершенно непонятно, что на самом деле происходит в вашей системе.
Ещё один популярный вариант — устроить конкуренцию, чтобы все старались лучше и были более замотивированными. Спойлер — вероятнее всего ваши люди и подразделения связаны, и конкуренция погубит кооперацию, а с ней и эффективность системы в целом.

Вредный совет №3: Забыть про систему обратной связи

Ещё один надежный способ завалить процесс — забыть про систему обратной связи. И здесь я говорю не про one-to-one встречи и не про «поговорить с людьми», а именно про обратную связь в техническом смысле: когда результат работы системы влияет на то, как она работает.
Если система не замкнута, то рано или поздно она начинает разваливаться. В какой-то момент она начинает выдавать не то, что нужно, и работать не туда, куда должна. При этом становится почти невозможно понять, что именно в ней происходит и почему.
Крайне важно, чтобы результат системы влиял на то, как система работает. И это не всегда бывает легко сделать, не всегда результат вашей работы на вас влияет. Но как минимум, вы не должны раньше времени снимать с себя ответственность. Например, когда получается такое: «Наша задача — написать технические требования. Мы их написали. А поняли вы их или нет — это уже не наша проблема, нам пора писать следующие требования».
Я приведу один пример, который мне кажется очень показательным. В производстве используются спецификации — перечень деталей, из которых состоит готовое изделие. В одной приборостроительной компании была сотня изделий, а в каждой спецификации — тысячи строк. Существовали отдельные процессы: внесение новых изделий, внесение изменений, обновление изменений и так далее. Всё это нужно было, чтобы поддерживать спецификации в актуальном состоянии.
Думаю, каждый сталкивался с задачей поддержания какого-либо перечня в порядке. Рано или поздно это превращается почти в невыполнимую задачу: КПД по наведению порядка стремительно падает.
Так было и у нас. Несмотря на усилия, спецификации содержали ошибки. Обычно мы узнавали об этом, когда оказывалось, что для сборки изделия чего-то не хватает — чего-то не купили. При этом мы скорее сталкивались с последствиями, чем узнавали о конкретной ошибке в спецификации. Мало ли почему не купили. А значит, последствия ошибки не всегда приводили к её исправлению.
Всё изменилось, когда случайно появилась система обратной связи — никто специально её не проектировал. Просто так вышло. Нам просто повезло.
В очередной версии самописной ERP (система управления производством) у нас появилась жёсткая зависимость между спецификациями и остатками деталей на производственных участках. Если, например, для сборки узла требовалось 10 болтов, бригада брала со склада 10 болтов. Но если в спецификации по ошибке было указано 12, то невозможно было поставить отметку о выполнении производственного задания на этот узел: формально не хватало двух болтов.
Первые пару недель работы новой системы — был ад! Бригадиры постоянно звонили и жаловались на расхождения спецификаций с реальной жизнью, точнее они жаловались на то, что наша система не работает. Но за две недели мы вычистили все основные спецификации — те, по которым были актуальные производственные заказы.
В итоге получилось, что результаты того, что выдаёт система, влияет на то, как потом работает система. Если в спецификациях есть ошибки, то мы не можем выполнить задание, что позволяет нам находить и исправлять ошибки.
Распространенный пример системы без обратной связи: когда вас просят писать отчеты, которые никто не читает и на их основании не принимается никаких решений. У нас на факультете ходила байка о том, что некоторые выпускники иногда добавляли в диплом фразы типа: «Кто дочитал до этого места, может зайти ко мне в кабинет и взять бутылку текилы».
Поэтому ещё раз: крайне важно, чтобы результаты вашей работы влияли на то, как вы работаете. И речь не только о метриках — речь о сути. Если в процессе есть обратная связь, он не устареет: он будет обновляться, оставаться актуальным и давать тот результат, ради которого задумывался.

Вредный совет №4: Устроить локальную оптимизацию

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

Вредный совет №5: Не учесть ограничение

В продолжение разговора о локальной оптимизации важно затронуть ещё одну тему — тему ограничения. И это не только про ограничение всей системы в целом, которое может находиться за пределами вашей зоны ответственности.
Очень часто одно из главных ограничений системы — это управленческое внимание. Что бы вы ни придумали — какие бы процессы ни пытались выстроить, кого бы ни собирались обучить, что бы ни планировали улучшить — всё это неизбежно упрётся в ограничение вашего управленческого внимания. Больше, чем вы можете переварить, система не переварит. Это важный момент, который нельзя игнорировать: ваше время и ваше внимание — очень дорогой ресурс.
Ещё один момент, который стоит учитывать, когда мы оптимизируем процесс, — это помнить про ограничение мощности внутри системы. И чтобы ограничение найти, можно, конечно, нарисовать все процессы, которые у вас есть, посмотреть, какие у вас доступны ресурсы, посмотреть, кто у нас больше загружен, но чаще всего вы и так знаете, кто у вас в системе является ограничением. И когда вы выстраиваете процесс, крайне важно не сделать следующее.
Представьте: вы выбрали процесс для улучшения, в нем участвуют четыре ресурса: A, B, C и D (схема №1).
Вы нарисовали процесс, посмотрели на него и увидели, как много в нём переключений. В каждом из них участвует ваше управленческое внимание. А ещё весь процесс занимает очень много времени — целых 80 минут! Вы смогли придумать, как сократить время на 10 минут (схема №2). Уже неплохо, ещё и переключений стало почти в три раза меньше! Кажется, что это хорошее улучшение, правда ведь? Отличное!
Но ваш самый смышленый сотрудник предложил третий вариант (схема №3). На первый взгляд он кажется абсолютно безумным. Во-первых, он дольше — и дольше не только вашего варианта, но даже исходного процесса. А во-вторых, в нём в два раза больше переключений, чем в вашем варианте.
Как вы думаете, почему вариант оптимизации, предложенный сотрудником (схема №3), всё же лучше, чем тот, что предложили вы (схема №2)?
Дайте себе время поискать ответ...
Кстати, я забыла сказать: ресурс B является ограничением системы. В первом варианте он задействован 30 минут, во втором (вашем) — 35 минут, а в третьем — всего 20 минут. Поэтому, несмотря на то что формально процесс по схеме №3 получается более длинным, через такую систему мы можем пропустить гораздо больше работы, чем в исходном процессе или в процессе по схеме №2.
Конечно, не в каждой системе есть ограничение мощности, но в командах оно встречается довольно часто. Когда мы смотрим на компанию целиком, то мы говорим, что ограничение мощности есть, когда запрос от рынка больше, чем мы можем сделать. Чаще всего это не так. Мы мечтаем о новых заказах.
Но когда мы заглядываем внутрь системы, оказывается, что от отдельных команд мы почти всегда хотим больше, чем они физически могут дать. С одной стороны, мы верим в полезность тотальной занятости и поэтому стараемся загрузить команды по максимуму. С другой — идей и хотелок у нас бесконечно много, так что загрузить и загрузиться обычно не составляет труда.
Короче, когда вы пытаетесь оптимизировать процесс, важно делать это с точки зрения всей системы, а не с точки зрения отдельных локальных оптимумов.

Немного про поток

Когда мы говорим о выстраивании процессов, мы подразумеваем какую-то систематическую работу. Обычно мы решаем не единичную задачу, а что-то, что повторяется и образует поток. Под потоком я имею в виду движение: на вход приходят требования в систему, на выходе — результат, который мы считаем единицей цели.
И чтобы увидеть настоящую проблему в потоке, иногда помогает уменьшить количество задач в работе (WIP). Почему? Потому что часто бывает, что если у нас очень много переключений, очень много долгов, косяков, и вообще не понятно, что в системе происходит, сложно бывает увидеть, что сейчас на самом деле является проблемой, а что является «накопленными горами мусора».
Да, это страшно: уменьшить входящий поток задач, остановить новые инициативы хотя бы на неделю-две. И даже временно заморозить часть того, что уже в работе. Но часто это даёт возможность увидеть, как устроена система изнутри, и что действительно нам стоит решать.

Отсутствие уважения ↔ Отсутствие результата

В какой момент мы начинаем говорить: «Всё, нам срочно нужно строить процессы»? Как мне кажется, часто это происходит в тот момент, когда пропадает доверие и уважение. Мы думаем: «Всё плохо, люди не работают, их нужно ускорять, контролировать — и для этого нужны процессы».
На мой взгляд, основная причина отсутствия доверия и уважения — это отсутствие результата. И здесь круг замыкается. Если уже произошёл кризис доверия и уважения друг к другу, можно, конечно, сесть за стол и сказать: «Давайте придумаем процессы, договоримся их соблюдать и попробуем довериться друг другу». Да, можно попробовать сделать так.
Но по мне, эффективнее разорвать этот порочный круг через появление конкретного результата. Прежде чем придумывать процессы, которые якобы должны заставить людей работать, попробуйте вместе с ними что-то сделать и получить конкретный результат. Для этого важно выбрать понятную цель, короткие сроки и достижимый результат, за который можно порадоваться. Для этого вам скорее всего придётся временно заморозить часть задач и проектов (а если честно, то скорее всего большинство), но если у вас случился кризис доверия и вам действительно необходимо начать получать иные результаты, то в каком-то смысле у вас нет выбора. Альтернативный путь через обвинения и гиперконтроль вряд ли сработает. Ну и в целом, без контроля объема незавершенки реального роста эффективности достичь затруднительно.
На мой взгляд, сначала нужно начать получать результаты, а уже на их основе выстраивать процессы. Быстрые результаты, через которые мы начнём видеть в друг друге людей и работоспособных специалистов.

Немного про микроменеджмент

Полномочия VS Контроль

Всё это касается полномочий и контроля. Здесь нужен баланс. Чем больше мы можем дать полномочий — тем лучше. Чем больше смещаемся в сторону контроля — тем хуже. И это плавно подводит нас к теме микроменеджмента.
Во-первых, микроменеджмент — это инструмент. Он не может быть плохим или хорошим. Некорректно говорить: «Микроменеджмент — это плохо». Корректнее сказать, что он может соответствовать проблеме или не соответствовать ей.
Например, в случае тушения пожаров, когда что-то пошло не так, и мы буквально «Ведрами передаем воду», — это нормально. Можно конечно надеть белое пальто со словами: «Мы должны были подготовиться заранее». Понятно, что почти любое геройство — это провал в прошлом. Но всё же иногда нам приходится прибегать к микроменеджменту.
Но если мы слишком часто к нему прибегаем, это сигнал о том, что, скорее всего, мы где-то и правда недоработали. Скорее всего, есть проблемы в системе: либо мы не придумали, как действовать, и каждый раз импровизируем, хотя можно было уже давно стандартизировать, либо есть проблемы с доверием. Результат не выдается — доверия нет и «приходиться» всё контролировать.
При этом крайне важно не снимать с себя ответственность, думая: «Они все неправы, не выдают результат, а я Д’Артаньян — поменяю команду и всё станет хорошо». Так не работает. Если кто-то не может договориться: ответственность лежит на обеих сторонах.

Противоречие пожаров

Один из способов посмотреть на микроменеджмент и постоянное тушение пожаров: через противоречие.
Что такое тушение пожаров? Это ситуации, когда мы должны почему-то работать не по правилам, мы должны их как-то обходить и нарушать. Но мы же почему-то придумали эти правила, они появились не просто так. Когда мы тушим пожары и нарушаем правила, мы ставим какую-то потребность системы под угрозу, но в тот момент, когда всё начинает гореть слишком сильно, мы плюем на правила и пытаемся спасти нашу систему. А пока она горит не слишком сильно, мы продолжаем следовать правилам, потому что у нас есть какая-то важная потребность системы, ради которой мы эти правила придумали.
Чтобы уменьшить необходимость микроменеджмента, полезно выявлять такие противоречия и стараться находить WIN-WIN-решение, а не оставаться в неудовлетворительном компромиссе.
Как это делать — можно посмотреть вот в этом докладе. Если коротко: полезно задавать себе вопрос — почему мы защищаем потребности системы этими правилами? Почему мы всё же нарушаем их, когда ситуация обостряется? Как нужно доработать систему, чтобы изменить правила и способ тушения так, чтобы мы могли удовлетворять обе потребности, вместо метания между спасением одной за счёт другой.

Итого

«Выстраивание процессов» — может пойти по двум сценариям. Первый — гиперконтроль, отсутствие уважения и невозможность наделить людей полномочиями действовать самостоятельно. Второй — эффективно установленный порядок, который удобно зафиксировать и передавать тем, кто придёт после вас. Но, как мне кажется, важнее не то, как сделать процессы «правильно», а то, как их не сделать «неправильно».
Если говорить о практическом подходе, то первое, что стоит сделать перед построением процессов, — это разобраться с целью: чего мы хотим достичь? Какова цель нашего подразделения? Какова цель конкретного процесса? Причем важно не ограничиваться быстрым ответом, а дать себе время подумать и посмотреть по сторонам, что происходит за пределами вашего отдела.
Далее нужно определить и сформулировать проблемы, которые мешают достигать этой цели. Если процесс создается без учета этих проблем, он с большой вероятностью будет вреден. Бывают эффективные и неэффективные изменения, и если разработанный процесс не решает реальных проблем, он их может только создавать.
После этого важно посмотреть, есть ли у вас ограничение в системе, чтобы не допустить локальной оптимизации и не перегрузить систему.
Затем нужно действовать через гипотезы: не подходить с мыслью «сразу всё придумаем, внедрим, автоматизируем и оптимизируем», а работать циклом «гипотеза — проверка».
И всё это классно делать через заметные команде результаты — потому что без этого не будет доверия, а без доверия всё будет скатываться в микроменеджмент и гиперконтроль.
Я живу в Академгородке —это научный центр рядом с Новосибирском, он находится в лесу. Между институтами и жилыми домами тоже лес, и люди ходят через него. И вместо того чтобы сразу проложить тропинки, администрация подождала, пока жители протопчут эти тропинки, а потом только их забетонировали. А позже ещё и назвали в честь ученых)
Как мне кажется, когда мы говорим про процессы, не стоит торопиться. Важно избавляться от иллюзий и обвинений и идти не то чтобы совсем по чуть-чуть, но не стоит сразу же «бетонировать дорожки». Даже если кажется, что то, что выпридумали — это всё очевидно супер-правильно и железно, или уж тем более, если кто-то это придумал за вас и есть какие-то «правильные» фреймворки.

Полезные материалы

01/ Выступление Podlodka TeamLead Crew: как строить процессы... [посмотреть]
02/ Что такое эффективность? [почитать] [посмотреть]
03/ Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) [почитать] [посмотреть]
04/ Когда проблема — не проблема. НЖЯ — инструмент Теории ограничений [почитать] [посмотреть]
05/ У вас нет выбора. Либо вы управляете ограничением, либо оно управляет вами [почитать]
06/ Если это решение, то в чём проблема? Шесть слоев сопротивления изменениям [почитать]
07/ Решаем классическую задачку PQ и говорим про управленческий учет по ТОС [посмотреть]
08/ Финансовая мотивация от KPI [почитать]
Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими