Correcting Goldratt's Cloud - We Are Doing It All Wrong: Part Two

Introduction

If you give people a theoretical justification, then they want practical examples. And if, you give people practical examples, then they want a theoretical justification. But it is never either ... or ..., it is always both ... and ..., and ultimately it is actually even more than ....; we have emergence at play. Here is a quote from Gregory Bateson that is fitting:

"I try to teach students ... that ... you start from two beginnings, each of which has its own kind of authority: the observations cannot be denied, and the fundamentals must be fitted. You must achieve a sort of pincers maneuver.”

It's from practical application, or in Bateson's terms; observations, that we derive this diagram:

This is a fundamental representation or explanation of a systemic cloud or a cloud of paradox. And what I said and described previously in Correcting Goldratt's Cloud - We Are Doing It All Wrong: Part One is that there are two new (for me) aspects to these fundamentals:

1. The location of the UDE's "under" the jeopardy arrows
2. The jeopardy arrows as a mechanism for stagnation or advancement.

So, as I have, you can do this for 25 years plus through observation and dare I say it - intuition - but also certainly from prior absorption from science, and yet still not actually know how to, or necessarily need to know how to, fully express the fundamentals. However, once those fundamentals are more fully expressed then we need to fit them back to the observations once more as check against reality. I'm going to use the following specific cloud to do that:

That's "my" rendition of a systemic cloud for the big batch/small batch issue. We know how to describe the problem, now we need to see how we can obtain a paradoxical solution from that; or at least show that one exists. This is Bateson's pincers at work.

I want to do this in 4 stages:

1. Show a suite of systemic clouds.
2. Show that we are dealing with stagnation not oscillation.
3. Describe some real-world applications of these types of clouds.
4. Work through the specific paradox of small batches.

Drawing-up a systemic cloud is like preparing for a public presentation. If the presentation looks like a piece of cake, it usually means a great deal of thought and practice, and further practice, and indeed time, has gone into it before you get to see the actual presentation. You are trying to communicate with an audience - sometimes hostile at that - using a graphical tool. And for me, at least, you are also trying to communicate a solution or the direction of the solution for which the audience will supply the details to your dynamics.

1. A Suite of Systemic Clouds

I took many of the systemic clouds from a PowerPoint that I produced and added to my website www.dbrmfg.co.nz around 2008. I've left a few off but haven't added any more here. There are definitely several more key ones that I use now that weren't on this list at the time.

This is perhaps the most basic expression of them all.

Although my convention used to be the other way around, I've settled for a long time on having the higher logical level in the upper arm and the lower logical level in the lower arm.

Here's another; it is set and subset, or indeed superset and set too.

One for the philosophers; us/we, I/me.

There's a refrain from North American practitioners of Theory of Constraints that goes along the lines of "what's in it for me?" a rhetorical question that is meant to represent the thoughts of the rank and file of a firm being asked to improve. It kind of gives lie to the so-called necessity of the necessary condition of "secure and satisfied employees now and in the future." Clearly there is some insecurity and some dissatisfaction present. But I am digressing and its only early in the piece. Well, maybe I have to point it out. In many other cultures around the world, the word "us" would be far more important. When we address a systemic solution, building the cohesion around us/we is paramount.

Here's the next one, long-term/short-term.

Whole and the parts.

Strategy and tactics.

Dynamic (simplicity) and detail (complexity).

Process and product.

Leadership and management.

Context and content.

Synthesis and Analysis.

Throughput and cost.

Professional and personal.

I hope that by listing these out as clouds rather than a list of word pairs, it might help you to see that the lower arm is (by my convention here) the lower logical level and the upper arm is the greater or higher logical level. The greater or higher logical level will always consist of the lower logical level and something else. That, after all, is why it is a higher logical level.

I also hope that if you scan through these again you might convince yourself that you, or certainly others, might, at first, stagnate on the lower logical level. If you sense that there is an oscillation instead, then I will say that you are dealing with a technical issue of some sort. If you have an adaptive issue, even though you might venture to entertain the higher logical level you will come back again to the lower logical level and stay there.

Nonetheless, I think this list, in fact I know from feedback, will help you to understand all clouds better. Maybe you can guess why we might stagnate at the lower logical level, but before we explore that further, let's present, or rather re-present two important matrices.

2. Stagnation, Not Oscillation

There are two particular matrices that I didn't know I was going to present here again, and they are developed in much more detail in earlier articles.

• Goldratt's resistance to change.
• Kegan's immunity to change.

Neither has been "converted" to a matrix anywhere else, goodness knows I've tried to raise awareness. That we can accommodate these different people and their ideas goes back to the fundamentals of this work that we can take (many) other people's approaches and "fit" them into this model (see for example Brené Brown's Numbing and Negation, Kegan's Contrary Actions, Big Batch Small Batch, Addiction and Suicide). In a circular way, or in a reinforcing way, that gives me confidence in this model. Okay, sometimes a quadrant is empty - but at least we know that it is unaddressed. Have a look.

This is Goldratt's resistance to change.

Regardless of how much or how little people might split the layers, they fall into one of the four quadrants. And I have to say it, we are very bad at, and in fact we have no tools for, developing the positive of the current reality - that's the quadrant that is bare here. Kegan in contrast (immediately below) does address that quadrant strongly. When I use this matrix, I make sure that I address this quadrant strongly. Goldratt sometimes said the stronger the foundation, the higher the jump. But Thinking Process does not address the positives of the foundation, so how do we jump? And more broadly, dilemma oscillates so there is no foundation to jump from in any case. Okay, I've made my point.

And talk about inertia (in the comments of the article on the Theory of Constraints is Obsessed with Dilemma and this is Wrong), I've always drawn the arrows in the matrix up until here as very board shapes because once upon a time they had text within them, the text is gone but the size of the arrows remains. Here, they are simple arrows to maintain consistency with the cloud.

How about Kegan's immunity to change then? Let's have a look.

Kegan starts with the future positive that we aspire to - the "New Year's Resolution" and notes how we drop back and continue with our prior contrary actions - doing what we should not do and not doing what we should do. This is, however, is consistent with our underlying commitments and to do otherwise gives rise (in the upper-right quadrant) to fear. That's not uncommon with Goldratt's approach in fact; he also places fear in the same place. But Kegan makes a point of bringing it out (in a device he calls the worry box). Here fear is verbalised as fear of starting something new (and different) or stopping something old (and familiar). And when we examine those fears, we get down to what Kegan calls the underlying big assumption(s). Note how Kegan ignores, and leaves bare, the negatives that we are seeking to avoid (the lower-right quadrant), this is the quadrant that Goldratt starts in.

Let's compare the two:

First take-away. Both are systemic. They are directional from lower logical level to higher logical level (and, regressively, back again.)

Second take-away. Goldratt starts at the problem and ignores the current positives. Kegan starts at the solution and ignores the current negatives.

Third take-away. Both have a propensity to stagnate - ah that was the point I was trying to get to - in the lower-left quadrant, the positives of the present (even if Goldratt leaves this quadrant blank - that is what the "fears" point back to). You "think" the future positive of diet and come back to the contrary action of the disappearing chocolate cake. And I know; it would dry out if it was left and now there is none left at all.

Of course, the two approaches fit together, as I have said elsewhere, like a hand and glove (see Kegan/Lahey Got it Right - Immunity to Change.)

I want you to have a mental model that there is no free and fair oscillation in either of these two approaches, there is only stagnation at the lower logical level of the positives in the lower-left. If you have ever had a successful New Year's resolution, one that was not simply technical, then please let me know.

Let's recap a bit. I've out laid a suite of various systemic clouds. Clouds that all have the same pattern but might address different aspects. I did that in 2008 because of my conviction that I was seeing something that others were not. And in fact, I repeated that theme in 2011 in New York and 2012 in Chicago. But this was simply formalising something that I had been naturally doing since 1998.

So, let's take a step back before we take a step forward again. Goldratt "forbade" any Thinking Process in his Viable Vision efforts. I can appreciate why; I imagine he didn't want paralysis by analysis. But he did permit use of the cloud and in particular the consolidated or 3-cloud method or core conflict (as had been the case in his earlier 4 x 4 process). I can imagine that generating such a cloud had the purpose of building a consensus about the nature of the problem and the direction of the solution. And yet, when I asked people if this was systemic, I never got a satisfactory reply.

If we go back to Chad Smith's excellent Thinking Process appendix in Debra Smith's (2000) The Measurement Nightmare (the first St. Lucie Press/APICS series on constraints management that I ever read) we find an excellent diagram on deriving an organizational core conflict from local or functional conflicts (Figure A11). But here's the crux, my italics: "The core dilemma for the organization must be constructed and each member must agree that the dilemma at the functional level are a derivative of the organization's dilemma. This is done by the same process as the three-cloud technique ..." Now I use that quote from that source simply to illustrate what was the standard understanding at that time, it is definitely dilemma, not a paradox. If I fast forward a decade to 2010 and the Theory of Constraints Handbook then it still appears that we are dealing with dilemmas between people or functions within an organization, and not the person or function and the organization. It's always between parts and parts or local/local and not between parts and whole or local/global. Dilemmas oscillate and cause trepidation. Paradox stagnates and causes frustration!

3. Some Real-World Applications

The clouds above are explicit, and I far, far, prefer to use tacit methods; both in social settings and in manufacturing or process or project settings. But our society doesn't take such "play" seriously, it avoids the simple and direct, and embraces the complicated and indirect instead, and therefore we don't learn much at all. So, to be serious we have to start out with the explicit. I'm going to illustrate this explicit approach with predominantly healthcare examples in this section because that is a relatively new frontier; one where we might not necessarily presuppose a solution. And as someone once said to me; "all our clever people no longer go into healthcare, they go into software," I both rolled my eyes and tried not to smile; after all that's good for healthcare and really bad for software. You see clever people like to argue, especially explicit arguments; if someone can successfully challenge an explicit argument, then they don't have to ever test that challenge, or prove that challenge in reality; and so once again, we don't learn much. In essence if someone can argue against the details, they can immunise themselves and remain oblivious to the underlying dynamics and the fundamentals.

So, often you go into these meetings - which are really set up for you to fail and for some of "them" to at the least prevail - otherwise they would ask you first: "how do you want us to do this?" They are expecting platitudes, and you give them a paradox; a cloud no less, and despite themselves, they are engaged.

I'm going to give a couple of specific examples. But, once again, let me say you have to do your homework, your groundwork. You have to know their problem better than they do and you have to know the pattern; the pattern that connects.

That pattern is the lower logical order or need that gives rise to the problem and the higher logical order or need that gives rise to the solution. AND they know this. But no one will have ever mapped it out for them before and that's our job.

Let's have a look.

• Very early on, say 1998, when I didn't know that I couldn't do this, a gentleman who believed Goldratt's 3-cloud method or consolidated cloud or core-conflict cloud method was, well, suspect, sent me three local clouds. He wanted me to make a consolidated cloud out of those! And, because I didn't know you that you couldn't, that is exactly what I did. "How did you do that?" was his reply. And as I've said elsewhere, you apply a rule; you look for the higher logical level and flip individual clouds if necessary, so they are each aligned. So, I was applying a systemic or global or paradoxical test to these clouds. Go back to the 13 pro-forma clouds above, look at the B/C in your individual clouds, find one that matches. Do that for all three.
• With the senior management team of a provincial hospital, I presented a systemic cloud but not the assumptions and I "worked" that cloud until I got the reaction I was after. Someone shouted out, at me, the assumption. All that was missing from it was the exclamation of "stupid" at the end. But I wasn't stupid, and it wouldn't have worried me in any case. I was after that exact assumption, that exact phrase, and I had told the organizer of it beforehand. And note, it wasn't an erroneous assumption that I got, it was an enabling assumption. That is what systemic clouds do. You and me against the problem and towards the solution that you always knew anyhow.
• I have done the same with a very purposeful and oppositional group of emergency physicians at a national conference. No one could be as oppositional as emergency physicians, except maybe a room full of anaesthetists or maybe orthopods. In essence I was invited and set up to hang out to dry - but it didn't work. No one but emergency physicians could understand emergency physician's problems - right? Wrong. They expected platitudes from someone from the "outside" and instead, once again, someone shouted out the missing piece. Perfect.
• I took a systemic cloud and presented that to the Minister of Health - it was called the Minister's conflict. I did it again with a different minister at a different time along with the Director General of Health and his senior team. They are expecting you to tell them to spend more money and you suggest something paradoxical instead.
• I have done this with the most dysfunction service within an acute regional hospital using three clouds. One of those was the Copernican revolution - and I am too lazy to check the other two. What the hell has Copernicus got to do with a dysfunctional service (and I mean dysfunctional) in healthcare. Well, in a word, everything. We are confronting our local individual instinctfulness with our greater and better common thoughtfulness.

So, let's break out for a minute and ask what is happening here. The Copernican paradox is a pattern. So, you give one pattern, its abstract, there can be no defensiveness about Copernicus' problem - it was his problem - and by-the-way we know he was right. And even today, just watching a sunset or a moon rise we step back into the exact problem. And then you give them another pattern which they can't deny, and by that stage you have the dynamics bedded in. They know their problem by the time you get to the third pattern. This is called abduction - and not by the aliens in your imagination (I've had the good fortune to be "diverted" - over Roswell by summer weather systems and, no, I didn't see anything). Rather we abduce when we make a logical jump, often from a metaphor or a general pattern to the specifics of our own situations. Strong as the weakest link, flow like a river, for instance are similes rather than metaphor, but they also allow us to make these same mental leaps.

Two more examples.

• A group of 64 area committees in a national ambulance association. We are kinda rural and the topography is such that many regions are geographically isolated from one another - hence resources have always been very provincial, very localised. Half these committees were from one old administrative (autonomous) area and the other half from another. You can guess, someone decided it was more efficient to amalgamate these into one central administration. Except for several years people just kicked that can down the road. Solution? Matrix this time. Small group facilitation around a matrix on a flip chart. A couple of reps per committee, several committees per group, 4 groups at a regional session, four sessions, and you have your 64 covered. But here's the magic. Each group at each session starts to present their matrix to the others. The first explanation is always detailed. The second is a little self-conscious that they too (strangely) found very similar things, the third is apologetic at the similarities and shorter, and by the fourth, well, we have the pattern. We all have the same problems AND we all have the same solutions. AND we are in agreement. Imagine that!

[When you do an affinity diagram before you start to do a current reality tree - you get exactly the same thing - a small group of 10-12 common UDE's and a few individual outliers from a list of a hundred or more individual but similar expressions. You do this - right?]

• I was asked to facilitate some strategy in the style of Bill Dettmer's Strategic Navigation. This was within an agency of the Government's Department of Social Welfare; an agency with all the responsibility but none of the (funding) authority - if that makes sense. I didn't have a cloud; I was expecting to hear theirs. There were UDE's on post-its for China - going up all the walls. But no cloud in sight, and nothing I did would elicit one. We went to grab a bite to eat. I took a pad. And there in the space of 20 minutes, in the midst of some earnest conversation, I got three separate clouds - I didn't say anything, I just wrote them down. And when we got back and I wrote those out on a wall; well, a generic cloud, a systemic cloud emerged from that and served as the basis for a communication current reality tree going forward. What's my point? Well, sometimes you just have to know the pattern and exercise a little bit of patience. People are frustrated that they or their process is stuck where it is. You can't be frustrated unless you have some inkling of the resolution at the end of the current tension that you experience. Properly formulating the problem is, to paraphrase, half of the solution.

Now, I've laboured those examples. You could say that every problem is unique, the participants in all of those examples would have said so. Our national health system is clearly unique - or actually it's not, it's about the size in totality of a single large city in some other places in the world! Well, there goes our local ego. But the solutions are generic - and we know them already.

I gave you some fundamentals - the suite of systemic clouds and two general matrices; one for Goldratt's resistance to change, and one for Kegan's immunity to change. Then we proceeded to examine, albeit briefly, some real-world examples where I have used either systemic clouds or systemic matrices - in fact theory and practice, fundamentals and observations working in unison. Let's now build on that with the specific example of big batch/small batch. Remember it has to have a paradoxical solution; and one that is easy and one that is simple. In fact, one that you can implement the very next day.

4. The Specific Paradox of Small Batches

Goldratt's original solution to the big batch/small batch dilemma, as included in The Goal, applies to make-to-order (MTO) environments. And in that sense, the solution is technical; it is a technical response to a technical challenge. Nothing wrong with that whatsoever, it's just that I couldn't have told you that before. Let me explain. When we think "small batch" we naturally and automatically expect that there will be more setups as a consequence - and people naturally enough - or should I say instinctfully enough - react to and resist that quite strongly for a number of economic and personal reasons. Goldratt invalidated that resistance by creating small batches as transfer batches of an existing larger and original process batch. Thus, there are no additional setups where transfer batches are concerned.

In the rules of OPT (optimised production technology) as say, in The Race, this is expressed as: "The transfer batch may not and many times should not be equal to the process batch." But even more importantly: "The process batch should be variable not fixed." So, in the case of the process batch itself, you could have more setups on non-constraining workstations, and fewer setups on constraining or near constraining workstations. Overall, in terms of the original big batch - a singular process batch - you may generate small transfer batches, but you are very much less inclined to produce smaller process batches. That is why I say smaller transfer batches are technical; it worked "around" the problem.

And for it to work well, you have to decrease the total work-in-process, or you have to expedite in the first instance. And of course, reducing the work-in-process, and thus the overall lead-time, is an important objective that we will return to.

Let's compare this to make-to-stock (MTS) environments.

In make-to-stock, or at least as I do it, you do produce more process batches and there are no transfer batches. Every process batch becomes its own transfer batch. We no longer work "around" the problem of additional setups, but instead face it head on, and that is an adaptive challenge. You must produce smaller batches and more batches at that.

Okay, that is the paradoxical solution staring at us; paradoxical because we have more batches not fewer, paradoxical because it will require more setups not less, paradoxical because it should make work harder not easier. Such an action should kill our productivity, right? The additional setups will eat into our productive time. Sorry, wrong! You are thinking local, I'm thinking global. Let's have a look.

Let's start on the lower arm. We know that big batches work - right? Careful, that's a trap - I've set you up. We think that we know that they work. We think that they work because of the positives. The DE's simply put are that with fewer setups we have more productive machine time, more uptime, and we have less anxiety and hassle of doing a setup ("the only laptop for the setup is over the other side of the building and it won't be free until ...." - I kid you not), and so on. And while we are at it, we can imagine the UDE's, the negatives of, smaller batches; we'd introduce twice as many set-ups, so, more downtime, we would have to stagger them and that would require more planning, and sometimes we would have to do two at the same time, we would create additional variability, and planning and doing; yada, yada, yada.

Now, mark my words; we stagnate at the lower arm of the cloud. Maybe I said in the previous part, no one ever died in a ditch fighting for smaller batches and more setups. But it shouldn't stagnate like that - surely. Why does it happen. Oh, let's see.

All of those decisions are local based upon the benefits to the local area, not the impact upon the whole. We will come to the damage soon enough. These are local decisions made locally by those who enact those decisions. Remember Goldratt said: "... talk to any practitioner and you'll find out that batch sizes are determined almost off the cuff and nobody in the plants is overly concerned about it." And he didn't mean that people make batches smaller, quite the opposite; he meant they make them larger! Except we should be concerned, we consequently over-produce, we are too busy, we don't see the utility to the customer, we might never even see a customer at all. Well, you can add those as UDE's to the big batch jeopardy.

But it's more than that too. We instinctfully reinforce our instinctfulness (how do you like that) with measurements, local measurements. Remember: "How long can we continue to reward stupidity and punish the right actions? How much money, time, and effort is devoted today to gather data for local performance measurements, just so that the end result will distort the behaviour of the people we are measuring." Okay I might not have chosen to use the word "stupidity" but let's substitute instinctfulness instead and you are very much closer to the truth.

[For those of a Deming frame-of-mind, local measures are simply tampering at its worse, making the process way more variable than it fundamentally is. And this has important ramifications. I've said in several other places that this is the single greatest lesson that the West never learnt from W. Edwards Deming and the quality movement. The West is obsessed with product quality and almost totally ignorant of process quality. Improve the process quality and the output goes up, even though unit capacity remains exactly the same.]

Instinctfulness; local instinctfulness, simply leads us to make work harder.

We reward busyness because of that new-world problem of believing we still live in a pre-industrial or pre-modern world where each individual appears to operate with a great deal of independence in an ironically rich and interdependent social network. It's only because there are so many alternative "routes" that we can fool ourselves that we are independent. The more independent we feel in, say, a city, the more interdependent we actually are. When we port that notion to the more restrictive case of linear serial dependencies - your and my everyday working environment - it all goes to custard. We can't be locally efficient; we can't be locally busy all of the time. Well, we can, but that leads to over-production (and over-production leads to long lead-times, and long lead-times lead to even bigger batches, and so it goes.)

So, how do we get out of this, how do we stop digging and start climbing out of the rabbit hole? Well, look at the cloud above - we have to do something paradoxical; we have to back up a bit and make work easier. And we have to do so thoughtfully. We have to think it, not instinct it. We do it thoughtfully by keeping in mind a couple of those key systemic clouds from earlier on. We need to look at the whole not the parts, and we need to look at the long-term not the short-term, we need to look at the global not the local.

Now, for some irony from Goldratt. He claimed, and I subscribe to the notion, that if we examine a system in crisis, we will find the correct way to operate it. Sound crazy - right. Surely that is when instinct would be paramount, and thoughtfulness has gone out the door. Not so. During a crisis we tend to look at the whole, we tend to look at the global, we tend to invoke a (Fritzian) senior organizing principle, or a goal, and we tend to subordinate to that. We exploit the constraints to the whole and subordinate the non-constraining parts to the whole as well. On a small scale isn't that what expediting of the crucial orders in The Goal was about, a crisis? Not just the exploitation, but also the subordination. On a larger scale isn't that the shortening of the timeline for building the oil platform that critical chain was developed from? Once again, not just the exploitation, but also the subordination.

So, how do we solve this? Do we need the divine intervention of the leadership. Well, intervention no, guidance yes. You see "the guys" on the floor, often feel compelled to continue to do things that they know will only make matters worse, make work harder, not easier. They know from experience that doing more of the same makes things worse. Compelled by measures in place, compelled by knowledge that say, we are already out of stock of particular items and against their own "feelings" they will decide "just this one time" to increase a batch to accommodate that shortage, and with the best of intents we have dug a little deeper.

To get ourselves out we have to do the opposite. At least at first, at least until we are sure that is incorrect. But usually, it isn't incorrect. And usually, we know this in any case. I said "compelled" above, because scratch the surface and that thoughtful, crisis driven, global, whole, long-term solution is hanging around from last time. How many times have I heard: "Oh we've done this before then we reverted back."

Let's explore this a little further in two steps. Here's the first.

If we get rid of large batches, then we have the DE's of more batches; small batches, BUT we still have the UDE's as well. In fact, we have more downtime, more planning, more hassle. We HAVE TO invalidate those. And this is where a system's view comes into play (not that the local individuals don't know this as I've said). For make-to-stock we can't go reducing each and every batch, indeed that would kill us. But do we need to reduce every batch? Are the mirid of small batches - all the rats and mice - the ones that are causing us issues, or is it just the big ones? And if it is just the big ones, just how many do we actually have?

As I've said elsewhere that 19th century Italian engineer (I thought he was an economist! - I apologise to all engineers) Vilfredo Pareto's 80:20 power law applies here. In make-to-stock around 80% of the volume will be processed in about 20% of the batches (and 20% of the work will be in 80% of the batches and that is just a FOL - fact of life). Add plus or minus 10% either way. If you only address the largest batches, you only get to double 20% of the total setups and the setup duration is not usually large in most cases, and so the additional downtime is small compared to the total setup time for all the other batches. And here's the thing. Things begin to FLOW as a consequence.

So, let's stop there, and back up a bit. Things begin to flow as a consequence. We've just nipped a vicious cycle in the bud (to mix my metaphors) and turned it virtuous instead (actually that is what notching a bud does - it induces a dormant bud to develop). Other things start to happen in concert: work-in-process goes down in proportion, process variability goes down, product quality goes up, all manner of problems previous hidden by the work-in-process come to the surface and can be addressed, and within weeks the situation begins to look like this. This is our second step.

The UDE's of the cloud one above become the new DE's of the cloud immediately above. The things that we must not do in the past - small batches; because of all of the (old) negative effects, rapidly become things that we must do instead; because of all of the (new) positive effects - because we simply, and easily addressed just the largest batches. Call that a leverage point if you like. And you know that additional downtime that we were so afraid of creating, well, it's a small proportion of all the downtime (not just the setup downtime) that everything else was creating and which is now released. Cast your mind to Toyota for a moment. The ultimate is Taiichi Ohno who had more and more batches until he had no batches at all. How's that for a paradox?

And for the record, Ohno's last significant setup reduction was not in stamping or casting (they had been done long ago) but in forgings, and wait for it, in Brazil. And he reckoned he wouldn't have got that done in Japan because his people would have pushed back (pp 63- 67 Taichi Ohno's Workplace Management).

In general, this is what we are doing. Look at D.

We are making things easier. Sure, we make more batches on 20% of the cases, but on a global scale we make everything else easier and that is far more important. Deming knew a bit about this:

"The obligation of any component is to contribute its best to the system, not to maximize its own production, profit, or sales, nor any other competitive measure."

What would we call that? We would call that subordination.

In these sorts of scenarios, the hidden productivity, the unrealised prosperity, the emergent properties, are humungous.

Even today, most people think that, say, drum buffer rope, is some sort of mechanistic - um - mechanism. One that locates some sort of magical unrecognised and underutilized physical constraint and maximises this - as though getting 90 or 95% of this "constraining" resource instead of say, 60 or 70% is the holy grail. Codswallop.

One or two times around the plant (it is true that constraints move and so does our focus) and it's out the door and into the market. And now, what are we going to do? Most people don't know how to subordinate so now we are really screwed. We can't touch the constraint; its outside of our span of control, and we don't know how to subordinate anything (in fact everything) that is still within our span of control.

Let me say it once again: in these sorts of scenarios, the hidden productivity, the unrealised prosperity is humungous. The constraint is in our heads.

Just 3-4 Simple, Easy, Paradoxical, Realignments

There are to my mind just 3 or 4 simple, easy, paradoxical realignments that we need to make; whether that be in drum-buffer-rope make-to-order or drum-buffer-rope make-to-stock, or critical chain or demand-driven replenishment. You can find these addressed in Goldratt, or Ohno, or even Ford's system. Even if you have a physical constraint - and I am not disparaging such a notion - if you don't recognise your instinctful policy constraints that cause the physical constraints in the first place, then you have simply scratched the surface and you will most likely regress.

How do we exploit these instinctful policy constraints? What is the scarcity that we must address? The scarcity is a lack of (global) thoughtfulness and an abundance of (local) instinctfulness. We can exploit and overcome that problem by subordinating our own abundance of (global) thoughtfulness to the problem. Creating a few more batches is one of those thoughtful actions; there are a couple more.

Now, one more thing.

The Fundamentals

Productivity is emergent. I'm sure I've said it before, but I have seen a 45% increase in productivity (can you imagine what that did to the profit?) where to a man I was told that it was impossible to produce one iota more. And they would have been correct given the way they were operating their process at the time. But I was very careful to poll everyone after they had reached this new stage and ask in as an unbiased, or as unloaded a way as possible, and no one felt they were working harder, most felt work was easier and yet they were collectively producing 45% more. AND we halved our largest batches, and then quartered them, and then "they" insisted that we go to an eighth. You've got to see and understand the "swing" you can bring to a process by generating such a flow. In a word, large batches are soul destroying. Small batches give people purpose.

And I watch the dialogues on, say, LinkedIn and I understand that people talk but don't know how to walk this stuff - in essence many people don't know the basic fundamentals. And although people will push back and say they do (especially in a moment after reading them) the evidence in practice is to the contrary. People argue detail ad nauseum but don't understand the dynamics.

But I said we need to make things easier, so here we go.

The fundamentals of:

• The organization: cooperation, specialization, and innovation.
• The firm: productivity, utility, and commonality.
• The process: dependency, variability, unit capacity.
• The logistics: rate, gate, and off-set.

Everything we do - each alignment - such as the example of reducing the largest batches only - each step that we make easier (and there usually only a handful or less) will be consistent within the fundamentals at the particular level at which they operate, and all the other levels above and below as well.

Strewth, people are most often; (1) identify the physical constraint, then (2) jump to immediately elevate it. Wrong - and that's step 4 in any case, so you've missed out two steps in the process. The constraints are in our head. The constraints are in our instinctful thinking.

Redux

I'll add one more fundamental that might override all of the above and it comes from Elliott Jaques:

"People do not have to love each other, or even to like each other, to work together effectively.? But they do have to be able to trust each other in order to do so."

He goes on:

"Trust between people is the basic social glue:?suspicion and mistrust are the prime enemies of reasonable human relationships."

What causes suspicion and mistrust? A lack of understanding of the very fundamentals that I outlined above!

Why do you think Goldratt said: don't blame? Why do you think Deming said: "it is not enough to do your best, you must know what to do, and then do your best." Or Ohno: "... and the parts were made."

Applying our instinctfulness to our modern thoughtful industrial endeavours (and software is an industrial endeavour - simply replacing mind with machine rather than muscle with machine) without an understanding of the fundamentals makes work harder.

One more time, people feel compelled to work harder and to make things worse, which requires that they work harder still until some sort of limit - um - constrains the system. But people also know the way out. They very likely have done this before or know of instances where others have.

We keep looking at the parts instead of whole, the short-term instead of the long-term, the local instead of the global, I/me instead of us/we, the detail instead of the dynamics.

The whole point of this exercise is that we are not dealing with a dilemma. We are not trying to frustrate the living hell out of people with two equivalent choices both with costs and benefits. We are showing or leading the way to a simple, easy, and paradoxical solution - one that is contrary to what we are doing at the moment. One that is thoughtful, one that is full of thought.

Summary

Let's be generous and say that 9 out of 10 people treat clouds or change or improvement as "conflict" or as dilemma. That may be how literature and law and the arts work, it may also ultimately be how we train our businesspeople as well (MBAs are based upon the Harvard law school model), but it is not how science works and it is not a way forward.

We are trying to solve problems, problems about prosperity really, and a systemic cloud always shows both the nature of the problem and the direction of the solution in one place.