Appreciating Systems

Appreciating Systems for Genuine Efficiency
Home » Page 41

Lean and Systems Thinking

November 29th, 2010 Posted in Lean, Systems Thinking Tags: ,

Here is a repost of some ideas I posted in a discussion group on LinkedIn regarding Systems Thinking and Lean. I hope to say more in specific articles on this blog, but… let’s deliver some value right now and improve later! The group is Systems Thinking World. Please note that this post does not address the Vanguard Method (advertised as systems thinking mostly in UK), but systems thinking as one can discover it for instance on Gene Bellinger wonderful web site Systems Wiki.

I can read a lot of comments about Lean toolset. Lean is IMO far more than this, for waving a tool without mastering the environment where you’d like to apply it, you risk hurting someone.

Lean does not advocates systems thinking, though I personnaly feel, when “properly” applied, it helps employees and management build a holistic view of their organization. I agree that all lean tools are reductionistic. But the approach, IMO, is not.

When you start transforming your organization toward Lean (that means for me changing to the new Lean business model, not just applying tools), you need to change the whole organization, not just parts of it. Because when you start to identify the value streams across your departments, you’re considering the whole system. Then, pulling from the customer’s point of view, you need to constantly adapt to what they’re going to buy (quality, delay, costs, etc.) and the pulling impacts the whole company (or should as some people limit it to some parts of the company, which is an error for me). So, yes, Lean only applies to the closed system of the enterprise (or the extended enterprise as advocated by Womack & Jones in “Lean Solutions”), but with a strong eye on the environment so as to constantly adapt the organization to the clients (=environment). From a Viable System Model, that’s decentralizing System 4 throughout the organization.

Then, speaking of continuous improvement which is usually done using the “A3 tool”, the process mandates that the one in charge of the A3 speaks to all involved and do that by going to the real place to see things by himself. Then talk to the people, get their ideas, get their approval, and then only propose the solution for the management and for all to try & improve later. The more you “do A3”, the more you build a systemic view of your company.

Should I need to speak of hoshin kanri, where a direction is set by management and all company hierarchy levels are asked to contribute with the specifics of their respective departments? Isn’t this a description of System 5 and the way it impacts sub-systems 1 as in Viable System Model?

Why multitasking is bad for productivity (Little’s law)

November 23rd, 2010 Posted in Lean Tags: ,

Some while ago, a colleague and myself made a presentation illustrating Little’s law. That law states that the Lead time of any process (the time it takes to go through it from beginning to end) equals the number of things in that process (also known as Work In Process) divided by the mean time of the process.

That’s not really visual said this way, so here is a Microsoft PowerPoint presentation (I did the first version and a colleague of mine animated it). Enjoy!

Download file here: Illustration of Little’s law

Training Within Industry : Lean foundations, use it for teaching Systems Thinking?

November 16th, 2010 Posted in Lean, Systems Thinking Tags: , ,

I would like here to just make some quick notes about what are probably the origins of Lean (apart from Taiichi Ohno’s own ideas, of course).

First of all, there’s a great mailing-list on Yahoo: Training_Within_Industry. The list just awoken a few days ago and it’s always some great contributions. Mark Warren is the group’s main contributor as he’s regularly investigating US Defense archives to recover TWI documents.

What is TWI? Or, more precisely, what was it?

During World War II, a US agency named “War Manpower Commission” created a department called “Training Within Industry” whose objective was to devise some ways to improve manufacturing efficiency during war time. Indeed, because of most manpower being sent to the front in Europe, few people were available to run home-based plants, for civil and military production. And so it was sought for a way to train people not used to work in manufacturing plants (it is said such a population was mainly composed of women and black people). Moreover, with the lack of people and the need for increased production (some plants needing to produce both for civil and defense ends), a way to improve plants efficiency was also needed. Lastly, as management too had been sent to the front, newly appointed managers need to quickly learn how to manage people and keep good job relations. That was the basis of the TWI program.

Origins of the TWI program itself come from the work of Charles R. Allen, mainly his book “The instructor, the man and the job“.

And so the TWI service was created and devise four methods:

  • Job Instruction Training (JIT) that allows quick and efficient instruction of someone to a new job
  • Job Methods Training (JMT) that explains how to improve any job
  • Job Relations Training (JRT) that explains how to build and maintain good working relations between management and frontline operators
  • Program Development (PD) which details how to set up a training program to improve a plant efficiency, based on the first three methods (JIT, JMT, JRT).

(It should also be noted for completeness that another method was also designed: Job Union Relations Training, an adaptation of JRT for improved Unions/management relations).

I am not going to detail these methods here: they are all available on Internet (PDF scans of the original manuals – see my delicious TWI links for instance), but I just would like to note that Job Instruction is almost used word for word at Toyota for instructing new hires on their job. Also, Mark Warren created two books (related to Job Instruction) out of them after deep analysis of all available TWI documents (including internal reports). See the bookstore page on Mark Warren web site.

Now, what if we could design a way to teach some form of Systems Thinking using JIT, maybe that could ease its mainstream diffusion?

Why I think Lean is (also) strength-based

November 10th, 2010 Posted in Appreciative Inquiry, Change, Lean Tags: , ,

A lot of people from the strength movement (Appreciative Inquiry, Solution Focus, etc.) view Lean as a deficit-based only approach to change. I disagree. Or at least I’d like to temper this idea.

Although it’s mainly presented that way in most litterature, I do view it as a very positive approach to change. Only often the positive future is mainly in the senseï‘s head (term for a Lean coach). When “doing Lean” in an organization, what the Lean coach is trying to achieve is have people (and management) make more of what works in other organizations. That’s what so-called “Lean tools” are: demonstrated best practices principles to improve an organization. Management and collaborators should always devise their way of improving their own jobs (because that creates more engagement), it’s sometimes quicker to reuse and adapt best practices that worked elsewhere.

Lean tools (with accompanying management model) are designed to show a gap between what’s wanted (a better view of the future) and what’s currently happening. And this gap may be a deficit OR a strength as reality could be better than what was intended at the beginning. Hence, collaborators have the opportunity to detect strengths and replicate them (we call this “standardize” in Lean terms).

Now I’m not saying Lean isn’t also deficit based. It does look at under-performance and ask collaborators to solve problems but only in order to achieve excellence (very positive vision).

Of course, all that I talked about above is true when Lean is “properly” done, which means that some policy deployment (“hoshin kanri“) has been done and that all collaborators had the opportunity to imagine a better future and ways to achieve it. Though Appreciative Inquiry is not mentioned in that part of Lean, I view policy deployement as a way to Dream about a better future. The Discovery (Inquiry) part may be missing in policy deployment, but it surely is present in day to day operations (or should be, and that’s the role of management of ensuring that both problems AND strengths are discovered – problems get fixed and strengths replicated).

Oh, and strengths (or solutions to problems) need also to be discussed with other team members, so collective inquiry into improving / replicating strengths is indeed present. This is done through creation of “A3” (named after the size of the paper on which that activity is done) where a situation is collectively discussed and ways of improving it (possibly by replicating what others may be already doing) collected and shared.

To end this article, I’d like to advocate people that would like to reinforce the strength-based approach of Lean to participate in the LinkedIn group “Strength-Based Lean Thinking / Six Sigma

The difference between lean and systems thinking

November 9th, 2010 Posted in Lean, Systems Thinking Tags:

Here is a short article from John Seddon about The difference between lean and systems thinking.

I think the article falls short of explaining that very difference. Yet, John makes a point against “lean tool heads”, which is a good thing IMHO. But not all Lean consultants/senseïs are tool heads.

Even if TPS is well known as “Toyota Production System”, Taiichi Ohno (the one that brought this management system altogether) kept calling it “Thinking Production system”, because it is a management system intended to make people think.

Tools are not more than ways of discovering problems, which people have to solve to make things better. And the tools mainly do that by making the processes always more sensitive to problems.

Of course, should management feel they have enough problems (but are they the most urgent problems to solve?) they won’t want more of them. It’s a pity since people usually love to solve problems and improve things (especially if it’s interesting for them, the customers and make their bosses happier!).

But do we still have managers interested in their people?

Back to the Vanguard method: a very good introduction (148p) is available here

Mindmap: Solution Focus

November 4th, 2010 Posted in Change Tags: , ,

Out of the strength-based approaches to change, there is one which is called “Solution Focus”. Out of a book written by Paul Z Jackson and Mark McKergow, the approach focuses on finding solutions that had, are and would work to solve the problem at hand.

The typical process goes something as follow:

  • Establish a platform: convert the problem or issue to an image of what already once worked (kind of similar to Discovery of Appreciative Inquiry)
  • Future Perfect: using the miracle question, imagine the perfect future in the case where the issue disappeared overnight.
  • Scale: if 10 is Future Perfect and 1 is the opposite, where are you now?
  • Look at counters: what resources, knowledge, skills and experience from the Future Perfect is already present today?
  • Affirm: affirm current & present counters that can help you move forward.
  • Small Actions: what can you do today to move to next step (+1) on the scale and collect more counters?

I did a mindmap out of the material I found on the net and uploaded it onto BiggerPlate. Go check it out!

Mindmap : Positive Deviance Approach

November 4th, 2010 Posted in Change Tags: , ,

Positive Deviance is a strength-based approach that tries to identify people which, despite the same conditions and limitations, get to strive in a particular context and then have the community replicate their successful behaviors. Very participative, the approach uses lots of open questions and whole system involvement to help communities fix their problems byidentifying and replicating on what some of their members (the so called “positive deviants”) are doing.

The PD Initiative has some very good guides (including a Basic starting guide) available to download along with stories and other interesting resources: go check by yourself!

I just created a mindmap out of the guides available on the Positive Deviance Initiative web site and uploaded it onto BiggerPlate.

Risk of Commoditization when deploying Lean

November 3rd, 2010 Posted in Change, Lean Tags: , , ,

I’ve been thinking lately about the very low success rate of Lean turnover. Rumors has it that it’s as low as only 2% of organizations trying to transform themselves into a Lean system to successfully achieve this. Why is it so?

Apart from putting this onto top managers and other collaborators’ change resistance, I’d be thinking that people trying to introduce Lean may be the very root cause of that failure (2% success is a failure for me and the approach should be changed!).

So, being interested in Systems Thinking (all because of Michaël Ballé as I’ve tried to follow what he wrote and writes; he notably wrote “Managing with Systems Thinking“) I started to investigate using that line of thought. Which threw me into the world of archetypes and frozen situations where “the more you change, the more it’s the same” (in french: “plus ça change, plus c’est la même chose“). The archetype that kept coming back over and over in this case was “Shifting the Burden“.

Using consultants is a bad thing

First, the archetype appears in it’s most evident form: most consultants trying to introduce Lean in organizations do so from, well, that consultant posture which more than often triggers the “Shifting the Burden” systems archetype:

The archetype is the part delimited by the bold arrows. Other arrows are decorations (additions) of mine:

  • R3 shows what the organization is missing: collaborators development that allows them to become better at doing Lean. Should the top manager conduct the Lean transformation herself, she could learn as well.
  • R4 shows that the more someone else does the work, the less one can do it oneself (hence the less one learns and the less one will be able to do it later)
  • finally, R5 shows why organizations keep contracting consultants: because they get short term results!

The problem being that since nobody usually learns during the consultants’ contracting phase (often too short for people to have learned themselves), the transformation is not sustained after the contractors leave.

Commoditizing Lean is also a bad thing

The next appearance of our Shifting the Burden archetype may not be that evident (it wasn’t for me). We often see Lean advertised as a toolbox and/or a succession of so called “kaizen workshops”. That’s what I call “commoditizing Lean”. When you select a few parts of method and turn it into something easily usable, well, you’ll make people use it. Moreover, you allow for a manager to give that commodity (or tool, or package) to a team to use it and to deploy it in the company. The consequence is that the team may learn from applying the tool, but the manager doesn’t. The team becomes the “someone else does the work”, and because it gets results, it gets management support to continue using it. Yet, in the end, should the management leave and the Lean initiative be stopped, there’s nothing left, Lean won’t be sustained.

From a constructivism point of view (Wikipedia definition: Constructivism is a theory of knowledge (epistemology) which argues that humans generate knowledge and meaning from their experiences) management has not learned (and the team probably has only learned to apply the tools).

What  works

So, given that two traps into which lots of people fall (I’ve been the “someone else” myself!), what works for deploying Lean? I’m not going to be original because it’s been said before: find a coach/senseï  you (as a top manager) can work with and do what he tells you to do. You’ll learn by doing, you’ll model behavior, your people will feel appreciated and motivation for “doing Lean” should raise as a consequence.

Of all the “lean workshops” I’ve done when being the “someone else”, only two had a lasting effect after me going away. These were the workshop where middle management participated and worked to improve things along with their collaborators. I guess they probably understood some Lean things since they continued during many monthes after the workshop to visually manage their performance and solve problems to continue improvements. A great lesson for me. Alone.

There’s obviously a lot more to say, I’ll come back to that topic in other articles. Meanwhile, I’m eager to listen to your opinions on that topic, below.

Viable Systems Model useful for Change Management

It just occurs to me that Ross Ashby’s law of requisite variety as operationally described in the Viable System Model (Checkland – See my delicious links about VSM here) might be a very good model for what consultants refer to as “Change Management”.

I’m talking here of “big changes”, the kind of which that mandates communication plans, sponsor involvement, a full blown CM toolbox… and of which it is usually expected a high resistance in reaction.

The fact is that most (if not all) organizations are both hierarchical and, well, big. By big, I refer to the capacity of anyone to devise ways of implementing the change in all of the impacted parts of the organization: if no one can hold that in their mind, then it’s “big”.

Now, I can see that most Change Management approaches (try Googling it to see for yourself!) try to deploy heavy guns for big changes. That encompasses talking and listening deeply to impacted people as well as driving out fear, devising very precise and specific agendas for change adapted to the part of the organization undergoing change, etc.

My question is: what’s the point of exhausting (paying) some consultants to imagine (necessarily incomplete and unadapted) actions plans for all impacted parts of the organization, when the very same work can be better done from these parts themselves? And with more engagement since they will be involved in the work and everybody knows that we’re more willing to engage with what we’ve helped design?

Now, when one’s looking at the VSM model (open up some external picture from these links), we can imagine the purpose of the change initiative being System 5 (policy), which informs relations between System 4 (external monitoring of change conditions for instance) and system 3 (management). Then system 3, management, has the role of taking care of relations between Operational Units (Systems 1) through information brought up by System 2 (conflict management).

Using the preceding model, one can envision Management (S3) being informed of the change to be done and then “configuring” dashboards (S2) to follow attainment of the change outcome as defined in S5. The way the outcome needs to be attained is then let up to each and every  OU (all of impacted S1s). As autonomous entities (as per the VSM model), they are the ones to know best what needs to be done and how it could be best done to achieve the expected outcome.

I understand that what I’m describing above is related to “complexity management” and post-modern approaches to change. It’s mentioned in a back issue of the AI Practitioner (Appreciative Inquiry online magazine): see november 2008 introduction. You can buy that issue on the AI Practitioner web site. Now, AI is a way to involve the whole system further than what can probably be done using more traditional “policy deployement” as suggested by the VSM. But that’s another story (I’ll write on this soon).

Do you have some stories to share of “cascading change management” as described here (probably without the VSM reference!) ?

Mail List

Join the mailing list

Check your email and confirm the subscription