Lean principles & practices applied during an SAP roll-out (Part 1)

It has been quiet over the last year on my blog. Supporting the implementing of an SAP system has been keeping me really bussy at my pevious employer. Now, time has come to share some reflections. Three years ago, I was hired as a lean manager, a year before the company went life on SAP. Little did I expect that this event would offer so many opportunities for applying lean thinking and practices. This is what I'll be sharing with you in the next couple of articles.

In this first article, I will share how 1) "Process Thinking" was reflected in the roll-out approach, 2) how weekly whiteboards huddles made problems visible and engaged cross-process cooperation, and 3) how agile techniques helped us esp. in the testing phase.

The company subsidiary where I worked, was the second one to go live on the SAP system. Previous implementation experience had shown that major disconnects occured in the processes especially between departments. In an integrated ERP system, all processes are linked: a simple mistake in product master data can cause products not to be orderable from customers, not to purchaseable from vendors or not to be received in the warehouse. Hence, the way of looking at the organisation was enhanced from a solely departmental perspective to a process perspective as well. The additional conceptual layer, the process model, was put on top of the functional silo's. This layer introduced a new language -a new standard- e.g. Order to Cash covering the activities from creating a quotation and an order (sales), credit checking (finance), calculation of estimated delivery date, billing (finance) and collections (finance). This reflects the essence of the 2nd Lean Principle, that customer value is created by a value stream.

In theory this sounds logical and simple. In practice this had major consequences. The entire project organisation, for design and implementation of the SAP processes and solution, was organised in Process Teams e.g. Order to Cash, Procure to Pay, Receive to Ship. Supply chain folks were now teaming up not just with their own peers but also with the accounts payable folks and with the teams maintaining vendor master data. Process owners, supported by process leads, were assigned to own the design and functioning of the main end-to-end processes. In the design of an EPR functional solution, few decisions can be taken in isolation. [By the way, after dissolvement of the project organisation, the value stream specialist role remained.  It proved to be a challenge for these specialists, who always belonged to one functional organisation as well, to focus their efforts on the end-to-end proces they were responsible for. For example: a sales specialists was required to master the billing and credit processes as well.]

When replacing your existing processes and systems with an entirely new one, and the existing solutions in SAP are known to be incomplete, how do you keep overview of all issues and dependencies whilst preparing for a go-life. We introduced weekly boardwalks, where the process team leads were updating eachother on progress, were issues were raised to sponsors and dependencies between team and processes were managed.

PMO board

Project board - Order to Cash

Project board - Product Life Cycle

We experimented with some agile development practices, without having the true agile in place. Development was done in sprints, which allowed for better tracking of deliverables on time and useability. Burn down charts revealed that no development ever went according to plan. In some area's daily scrum meetings made problems visible between teams and had multi-disciplinary teams work together much better. During testing, simple visual management methods were used track the testing progress. Here are a couple of pictures.

Testing - Daily Production Board 

Example of testcases

Issues raised on today's tests.

Backlog of testscripts to be done

Scripts with defects

Data objects "in use" and hence reserved for ongoing tests. 

A visual plan with all milestones and activities was filling the wall.  Progress or delays were immediately visible with green and red dots. The visual plan helped us to "see, learn and act together as a team".

Visual Plan for SAP roll-out

Visual Plan detail - green = started / red = overdue / blank = not to be started yet.

 In the next articles, I will share e.g. how Lean principles were introduced in the "Training Approach", how "Standard Work" was introduced and how visual management techniques supported Incident Management.

Purpose of Kaizen Events

Kaizen Events are bursts of improvement activity, where typically employees from different departments participate in a one- or multiday workshop to solve a business problem.

In my experience, the purpose of these events is not limited to just solving a problem. By solving a problem together we also aim at building capabilities and trust.

What capabilities are we developping during Kaizen Events?

First, we develop process understanding; i.e. understand how my work relates to that of my colleagues and eventually to the customer.

Second, we train people in problem solving methods and lean practices such as A3, fishbone, process mapping, 5 why's.

Why and how do we develop trust and relationships during Kaizen Events?

Cooperation and trust between people (esp. from different departments) are at the foundation of continuous improvement. Without trust and teamwork, there can be no autonomous kaizen. In my experience, people who have solved a problem together during a Kaizen Event have build relationships. They have a betting understanding of eachother's work and concerns. Consequently, I find that whenever a new problem occurs, they'll contact eachother much easier.

Go See - understand the process at the gemba

Here are some tips that can help you work towards this purpose of Kaizen Events:

• Plan time to train employees in problem solving tools, before applying them
• Allow time for participants to share views and opinions. The benefit is in the dialogue, not in rushing to the solution.

Taking time to reflect with the team

It wasn't until reviewing this article, that I realised the summary of this article is the same as my slogan "Improving Performance, Growing Together": improve your process and business while developping people and fostering teamwork.

Lean appeals to mind, hands and heart

I just love lean! It appeals to my mind, my hands, and my heart. Somehow, since working from the lean source, I feel a more complete and balanced person.

Clearly, lean is a holistic management system, an integrated approach on how to run a company. But for today, I would like to zoom in on how lean is holistic in the way it engages people. My deep rooted belief and daily experience is that lean management appeals to the minds, hands, and hearts of people.

First, lean's preference for the scientific and socratic method appeals to our brain. Many of the traditional lean tools help in addressing business challenges from an analytical perspective, such as Value stream maps, SMED, KPI's, level scheduling, designing the ideal state value stream based on lean prinicples. The predominant lean school of thought in the West has been very much the analytical en technical one.

Secondly, lean has a strong preference for experiments and for incremental improvement action, especially in comparison with other improvement methodologies such as TQM or LSS. Lean emphasises the gemba where the action takes place. It's at the gemba that we learn by doing. A famous quote in this context is: "Learn with you hands, and see with your feet."

Thirdly, lean addresses the heart: respect for people is a core value of lean management. Lean is about developing and engaging people, about giving them a meaningful purpose (e.g., serving the customer, serving society, personal mastery), and about belonging and contributing to a team. It is also about giving people a sense of dignity and ownership, and about creating a physically and mentally safe workplace where people can develop to their full potential and experience a mental state of flow.

I'd love to hear if you have had similar experiences with lean practices addressing mind, hands, and heart.

Understanding complex problems with causal diagrams.

Some problems are just more complex than others. In some cases multiple causes and effects are re-enforcing or smoothing eachother. Typical tools such as 5why's or fishbone don't offer sufficient support to understand and visualise these problem. In my experience, this is when a causal diagram really helps out. A causal diagram is a graphical tool that enables the visualisation of causal relationships between multiple variables in a causal model.

Here is an example of a causal diagram I once made to understand challenges in a complex SAP development and roll-out program, where milestones were systematically not met. The white circles describe causes and effects, where the arrows indicate how one topic has a causal relationship to another. For example, running many projects in parallel causes competition for scarce resources.

Let's have a closer look at how this works using the above example, starting at the bottom right: running many interrelated projects in parallel is increasing the complexity and dependencies in each of the projects. This increased complexity made it hard to make a reliable overall plan. Furthermore, all these projects were competing for scarce resources. When an issue or delay in a high priority project pulled for more scarce resources than planned, other projects where these people originally were planned to work on, were delayed. As a quick fix, it was as a rule agreed that critical resources would only be allocated shortly in advance and for a short period of time; in other words to allow them to work on where the biggest fires were. Consequently, since nobody knew whether critical resources would be available as planned, the quality and relevance of (short term) planning of projects was getting poorer. Basically, people were thinking: "Why bother investing time in making a serious planning; I never get the people I need for my project anyway." As a result, there was no real commitment for any of the timelines of the projects that were on the table. Also, challenging project managers on not meeting their deadlines, systematically resulted in the answer: "I'm not getting a response or availability (from the critical resources)". Gradually, the local roll-out management stopped challenging their local project managers. So, the incentive for good planning and execution slowly diminished. All in all, this resulted in a self enforcing mechanism of constant project replanning, with deteriorating quality of planning, poor commited project managers and nobody who was really following up on realisation of plans.

It took me a while to understand what was really going on. Mapping the interdependencies in a causal diagram helped in analysing the problems and finally defining the countermeasures.

Characteristics of work instructions

Have a look at these work instructions posted at a work station in the picking area.
What stories about standards does it tell us ?

Here's what I found interesting :

- they are posted at the workstation and visible for all, not filed away in a folder.

- work instructions (left) are supported with pictures

- employees working at the station must sign for accepting the new standards (right)

- work instructions have a limited validity (on the picture 17-8-2010) and must be reviewed by the station owner at fixed intervals.

- should the work instruction be removed, the label above signals the missing document

Use problem solving boards to monitor Lean culture

Recently, I visited the Scandinavian Solar subsidiaries and came across an interesting way to monitor the progress of lean culture throughout the company.

Traditionally, the adoption of the Solar Lean Way is measured in the annual employee survey. The survey measures the Lean awareness and employees' belief that the Solar Lean way contributes to serving the customers better and achieving the company's goals. Furthermore the survey includes questions on the lean leadership style of management. These are great measures at the start of a lean journey. However, these measures do not reflect the extend to which improvement activities are taking place throughout the company.

Let me describe how Solar is tracking the amount of continuous improvement activities as a proxy for "lean culture". Incremental improvements or point-kaizens take place on the gemba during meetings at the "lean problem solving boards". Here, teams discuss performance gaps and improvement opportunities on a weekly basis. Performance is measured and compared against goals. Any deviation from target (1) is addressed with rootcause problem finding and/or improvement suggestions (2). As the problem solving progresses (3,4,5), the boards keep track of the number of improvement actions in progress and the number of improvement actions closed (6,7).
( The number between brackets, refer to the numbers on the image below )

On a monthly basis, the number of improvement actions implemented (6) across all departments are aggregated on the regional lean board or country management lean board. Thus, an overview of the overall continuous improvement realisation is made visible and compared to target. On the image below, the red indicates that the continuous improvement goals within a particular location are not met. Hence, they are subject of a problem solving cycle on this board.

I'd love to hear if you have similar or other examples on how continuous improvement culture is tracked.

How to use influence to get things done

I enjoyed reading this article by Strategy+Business on how to use influence to get things done.
http://www.strategy-business.com/media/file/sb62_11104.pdf

Here are the five factors to use influence well:
1. Build up the courage to raise difficult problems
2. Leave your personal agenda at the door
3. Rise above the game, but don't ignore it
4. Engage the group using emotional intelligence
5. Be tenacious, because decisions do not guarantee actions

Should managers know the content of work?

In a reaction to my previous post "No Problem is problem", Marco van Katwijk asked if  “a manager should have (the skills to acquire) an understanding of the actual work content, with the purpose of learning to see if problems are hidden?”  Marco, thank you for your question! I believe managers absolutely need an understanding of the actual work content. Here are my thoughts.

First, managing based on facts and observation is a key competency for supervisors and managers. This means managers go and study (genchi genbutsu) facts on the workfloor to support the team's problem solving processes. In my opinion, this behaviour requires an intrinsic interest in the actual work. By practising genchi genbutsu, a manager's understanding of the actual work content will naturally increase over time.

From my personal experience as a manager, I have always dug into the actual work content of problems critical to my team's performance. I kept involved in the actual work content to verify that my team members were building:

1. understanding of their work and how it relates to that of others
2. the capability to see problems
3. skills to find true root-causes
4. skills and discipline to verify that countermeasures were working

I believe that digging into the actual work content together with a team member during problem solving, is an opportunity for teaching and coaching them on these competencies. As over time, team members gradually develop these competencies, my involvement with their actual work content decreased.

The purpose of understanding the actual work content is to support the problem solving process and develop the competencies of the team. 

Secondly, by showing an interest in the actual work of the team and their problems, a manager demonstrates respect, builds a mutual understanding and a basis for trust. Building a work environment of mutual trust and support is probably the most important element to prevent people from "building walls to hide problems".

Showing interest in the work content builds mutual understanding and trust.

In summary, for a manager it is essential to understand the actual work content to a sufficient level of detail. The purpose of understanding the work content is one of supporting the problem solving process, developing competencies and building mutual trust.

Characteristics of effective goals ( in Dutch )

Source and background reading:
http://123management.nl/0/070_methode/a720_methode_06_doelen.html

No problem is problem

I just love the following image !  It's great for discussing some lean concepts with your team: e.g. the role of the manager, the mental model of "problems are gold", the importance of visualizing problems, the importance of continuous improvement.

Here are some questions to trigger people's thinking:

1. Why does the person on the right (R) say there is no problem ?
2. Why does the person on the left (L) accept his 'No problems!' answer ?
3. Assuming that (L) is the manager, what does he do right ?
4. What happens after the third image ? What culture and behavior are fostered ?

Here are some possible anwers:

1. The wall hides (R)'s problems; (R) cannot see his problems. Maybe (R) has learned that it is better to hide problems because e.g. the messenger usually gets shot or gets instructions on what to do about ( i.e. get more work).  Maybe (R) even built that wall for that purpose ?
2. (L) has no way of verifying that there no problems, as the problems are not visible.
3. (L) is at the gemba and inviting (R) to talk about his problems. ( Note: Consider asking "What are your problems?" instead of  "Do you have any problems?" The first questions sets the expectation that there always are problems. )
4. Everybody is firefighting everywhere, everyday.  Consequently, there is less and less time to prevent problems by eliminating root-causes.  The prevailing mindset becomes:  "our hero's are the firefighters" instead of "our hero's are the fire prevention team".

What additional learnings do you find in this picture ?

Source of image : unknown - pls. inform me if you know the author.

Lean Leadership Behaviour and Actions

Here is a simple pocket card which reminds us of lean management behaviour and actions.
Click image for quality viewing or printing.

Source : Lean Leadership - The Invisible Force  by Thomas Thorsted & Peter Knorst

Why do we need continuous improvement ?

Our business processes are constantly exposed to changes in the environment. These changes impact and deteriorate the effectiveness our company's processes. I like the analogy of a spider web: constant exposure to wind and rain causes filaments to break. (1)

Without continuous improvement.
If our staff is not trained on properly addressing the changes and their impact on our processes, they may not take any action or at best create workarounds to fix the problems (instead of addressing the root causes). Over time, problems and/or workarounds accumulate with increasing complexity and decreasing overall process performance as a result. It becomes more and more likely that another 'improvement project' will be required. Back to the analogy of the spider web: if the spider fails to repair the broken filaments frequently and systematically, big wholes will emerge in the web which render the web useless and leave the spider without food.

With continuous improvement.
Now take the scenario where staff is trained in continuous improvement and supported by their manager to address these problems on a daily basis. First, problems caused by changes in the environment will surface earlier because staff has 'learned to see' problems and is supported by visual management tools (e.g. visual process adherence, visual process performance). Second, the continuous improvement mindset encourages staff to bring up problems. ( cf. mental model "problems are gold" ) Thirdly, staff will address the problems using structured problem solving ( cf. A3 Thinking ). Not only will they identify and fix root causes, but also implement improved standards and monitoring. These problem solving activities can take place during stand-up meetings, quality circles and individual coaching by supervisors. Here's how continuous improvement fits the analogy of the spider: she repairs broken filaments on a daily basis to ensure that the quality of her food collection process is maintained. Last but not least, by implementing a system of continuous improvement, the performance of processes will not just be maintained to but also improved.

A spider repairs broken filaments in her web on a daily basis to ensure the quality of her food collection process is maintained

(1) Source of this analogy: "The Remedy", Pascal Dennis

Four building blocks for driving effective change.

Here's a nice visual representation of four building blocks for driving effective change. I particularly like the description of what happens when one of the building blocks is missing.

Source: unknown

The iceberg of sustainable lean management

Here's a great visual representation of the elements of sustainable lean management.

Lean Principles as Generic Target Condition

Today I was thinking about how Womack's five lean principles ( Customer Value, Value Stream, Flow, Pull, Perfection ) fit in the overall concept of the improvement Kata as described by Mike Rother. In summary, my conclusion is that the five lean principles set a generic target condition for any improvement activity in an organisation.

Before becoming a lean thinker, I was educated in the Six Sigma school of thought. What struck me when first learning about lean was that it gave me guiding principles on how to optimize processes. These principles are Customer Value, Value Stream, Flow, Pull and Perfection (1). In my experience until then, Six Sigma had no such thing, other then a CTQ tree which designs customer expectations and CPk's (process capability) which measure the extend of meeting these expectations.(2) Clearly I'm not a master black belt, but having mentored many six sigma projects, I found that depending on the team I worked with, solutions to the same problems could be radically different. (3)

Even without fully grasping the real meaning and potential of these lean principles, they provided a lot of guidance for designing solutions. Honestly, I experienced it as a relief! Come on ... the solution chosen to be implemented could not just be determined by who was in the team (or which voting system was used) ...

Then I learned about the Improvement Kata in Mike Rother's book. Any improvement activity should start not only with a (measurable) problem statement, but also with a target condition. A target condition describes not only the measurable process indicators ( or target outcome) but also the ideal process design to give guidance to the solutions that should be developed. As I understood the importance of the target condition, I suddenly realised why an ideal state VSM was so important ...

Now let's fit the Lean Principles and the Improvement Kata together. For any (point or system) Kaizen I engage in, I will use the improvement Kata approach and design an ideal state which represents my target condition. In designing the ideal state and target condition, I will always use the Lean Principles as generic guidelines.

Imagine that all improvement activity within your organisation is using this approach ... -isn't that what the principles are meant for?-. Basically the lean principles will function as a generic target condition for any improvement activity in an organisation.

The summary of my lean learning for today: The five lean principles set a generic target condition for any improvement activity in an organisation.


-----

(1) I'm using Womack's five principles, but I could as wel refer to the 14 Toyota Way principles.

(2) I agree that by having added lean tools to the Six Sigma portfolio (turning it into Lean Six Sigma), some of guiding principles are now included.


(3) Here is an example to illustrate this. In trying to reduce lead time of refunding customers for credit notes issued, a six sigma team decided to move processing of refunds to India. This solution allowed to use a lot of cheap labor for fast refund processing, in a process with more muda which was less flexible ( due to e.g. language and distance) and not capable of communicating with front line teams or customers. The CPk objectives ( 60% lead time reduction) and required cost reduction (!) were achieved. Now, imagine what the solution would have looked like if this team would have used lean principles in designing the future state ...

Learning the difference between goals and standards

From past experience, I know how difficult it is to set good goals. In this article I will share some of my experiences and learnings in setting goals for managing and improving processes on the gemba.

As a manager of a customer care back-office department, I set overall daily productivity goals just to challenge and push my team of agents for improvement. In fact, after an initial start-up fase, the team members set their own goals for the day and my role was to challenge these goals. We discussed actual performance compared to the goals on a daily basis during 15 minute stand-up whiteboard meetings. This PDCA approach was a good basis for discussing deviation from plan and identify issues and improvement actions. However, these goals were not based on anything really ... Honestly, I didn't know if these goals were realistic and achievable, but I just pushed for little baby improvement steps every day.

Then, I had a big insight whilst working as lean consultant for a central heating installation company. Based on an analysis of McKinsey, the suggestion was to improve productivity of individual installation mechanics to the performance of the 75th percentile. I was a bit shocked, as my thinking was "Why don't we just focus on getting the performance of the bottom half up to the performance of the median." I then realised that my approach, which really meant making the mean performance the goal for everyone, resulted in no incentive for improvement for half of the installation mechanics workforce ...

Yesterday, as I was reading through "The Lean Manager" of Michael Balle, my understanding of setting goals went yet another step further. Of course I realised that "Problems are defined as gaps between standards and actuals. And yes, "A standard is the best known performance". But what new was to me, was the true understanding that a (measurable) standard should be set "based on observation of actual work content over multiple cycles". Referring to the customer care back-office example, this would be e.g. the best observed performance in cycle time to complete the administrative steps for re-ordering and picking up incorrectly delivered products to customers. The significance of this is tremendous! First, everybody understands the goal is achievable. And second, everybody - not just the bottom half performers- in the team is challenged to improve.

Now, how realistic is it to expect people to maintain that "standard" performance in cycle time for one hour or one day straight? That's the whole point of Kaizen. We should ask ourselves: How can we reach our best cycle time every cycle? This doesn't mean that the improvement is just for individual customer care agents or mechanics to achieve. It's an objective for the entire team: agents, mechanics, supervisors and managers.

By definition we should never beat the standard. For, if it is possible to beat the standard, the standard does not represent the best known performance and we should change the standard. When we outperform the standard, we must have included waste in the definition of the standard. If we include waste in our standards, there is absolutely no incentive for the team to solve any of these problems.

Summary. A big difference between a goal and a standard is that standards are based on the best observed and measured performance. This turns a standard into a realistic and achievable goal. A standard should not include any waste and should never be outperformed, as it is intended to constantly engage everyone in improvement activities.

The Toyota Way - 14 principles in relation

Here's an interesting representation of the 14 principles from The Toyota Way and how they relate to each other.

Source:
http://www.agilecoach.net/wp-content/uploads/2009/05/toyota-way-handout.pdf

From Kaizen Events to Kaizen Culture

I found a great article on the Gemba Tales blog on how to move from a Kaizen Event driven improvement approach to a Daily Kaizen approach. Here's an extract, I'm saving in my blog for future reference.

Most folks are practicing system-driven kaizen – organized kaizen, mostly directed by value stream improvement plans. While this isn’t terrible, it’s only a stepping stone to real lean. You should be crossing the bridge to the other side, the side of principal driven kaizen – system-driven kaizen, plus daily (mostly voluntary) kaizen. Only then will the enterprise and the culture be truly transformed!

Here are 15 challenges to address when moving from a Kaizen Event Improvement approach towards a Kaizen culture:

1. Have all of your employees been trained in basic problem-solving methods and are they coached how and encouraged to use them?
2. Is the environment one of problem-solving or problem-hiding?
3. Has the organization developed good PDCA rigor through the proper application of kaizen events and has virtually everyone participated in multiple events?
4. Do you have an effective lean management system that employs: a) leader standard work, b) visual controls, and c) cascading tiered performance metrics?
5. Have you implemented a pragmatic suggestion system that emphasizes quick implementation of true incremental improvement (kaizen teian), typically by the person who suggests the improvement?
6. Do you broadly and virally share improvement ideas?
7. Do you apply the 5 why’s or the 5 who’s?
8. Do the lean leaders promote A3 thinking?
9. Has the organization sufficiently resourced the kaizen promotion office (a.k.a. lean function) to help teach, coach and facilitate improvement activities?
10. Is the focus of improvement such that the order of importance is a) easier, b) better, c) faster, and d) cheaper?
11. Are folks fearful of failure or do they, and leadership, see it as a necessary means of learning and improving?
12. Are you internally capable (or at least getting there) or are you suffering from consultant dependency?
13. Do folks know what “True North” is and how they can do their part to get there?
14. Is the culture one of humility and respect for the individual?
15. Is lean applied within the context of a holistic lean business system?

Extract from Gemba Tales. Source: http://kaizenfieldbook.com/marksblog/archives/1948

Checklists cut surgery deaths by 50% in the Netherlands

Lean thinkers are advocates of the use of standards. Standards are the currently best known way of handling a task. A standards eliminates the need to think while executing the task, so attention can be paid to improvement work.

Professionals such as lawyers, doctors, accountants, who spend years studying to qualify for their profession, often resent standards. They claim standards cannot be applied to their intellectual work.

The typical example of how standards can be applied for intellectual professions are the checklists a pilot uses when preparing for a flight. Now there is another great example: the use of checklists in surgery.

Using an exhaustive hospital checklist prevents errors and cuts the risk of death nearly in half for patients who come in for surgery, researchers reported in 2010.The system also reduced the number of complications by one-third, they reported in the New England Journal of Medicine. The study adds to growing evidence that checklists can save trouble, lives and money in hospitals.

The study in the New England Journal of Medicine involved 11 hospitals in the Netherlands, six of which adopted a system that required everyone caring for a surgery patient to mark whether they had checked a key factor in the process. The rate of complications at the hospitals using checklists dropped by 31 per cent per patient and the death rate fell from 1.5 per cent to 0.8 per cent. The rates were unchanged at the five control hospitals.

"The Checklist Manifesto: How to Get Things Right" is a book by Atul Gawande on this topic. Gawande begins by making a distinction between errors of ignorance (mistakes we make because we don't know enough), and errors of ineptitude (mistakes we made because we don’t make proper use of what we know). Failure in the modern world, he writes, is really about the second of these errors, and he walks us through a series of examples from medicine showing how the routine tasks of surgeons have now become so incredibly complicated that mistakes of one kind or another are virtually inevitable: it's just too easy for an otherwise competent doctor to miss a step, or forget to ask a key question or, in the stress and pressure of the moment, to fail to plan properly for every eventuality.

I'm excited about the progression medicine is making and believe we can apply the learning in our own professional environment.


Resources:
- Video interview with Atul Gawande.
- Research findings from New England Journal of Medicine

Closed Loop Corrective Action

Q: What do you do when something goes (seriously) wrong in your day to day operations?

A: Use a standard Closed Loop Corrective Action (CLCA) process. CLCA characterizes the problem, contains the problem, implements corrective action, identifies and addresses root cause, and verifies problem resolution.

In times when things in my operations don't go as expected, I rely on this standard approach for reacting fast and effectively. This CLCA process is part of my standard work as a manager and an add-on to standard A3 problem solving. The attached image includes a simple CLCA template. Here are the "5C" steps in the CLCA process:

1. Characterise the problem and get the right team together
To start with, establish a small group of people with the process and/or product knowledge, allocated time, authority, and skills to address the issue.
Now the problem or issue needs to be carefully defined and bounded by describing the issue and its impact. Tips for describing the problem are: analyse existing data, observe the place where the problem occurred (gemba), establish an operational definition, use 5WH (who, what, when, where, why, how), be specific, establish the extend of the problem (measurable).

Example 1: You have suffered a severe sun burn
Example 2: A number of PC's with a wrong configuration has been shipped to customers

2. Contain the issue
Once a problem becomes apparent there has already been some loss suffered, either by a customer or internally by one or more departments. Immediate action needs to be taken to 1) prevent harm (economic or physical) to additional customers or departments and 2) correct the mistakes that have been made. Containment action planning must begin as soon as a problem becomes known.

Example 1: Getting out of the hot sun and going to the doctor for treatment of a severe sun burn, and cool the skin with water.
Example 2: Stop shipping more PC's with incorrect configuration and ensure the impacted customers will receive the correct PC.

3. Identify the Root Cause
While it's desirable that corrective action be taken as quickly as possible, it's just as important that the true root cause of the problem is identified and fixed. Sufficient time should be spent in causal analysis so that the problem is fixed once, and stays fixed.

Example 1: Extended exposure to direct sun light caused severe sun burn
Example 2: The PC product configuration information on marketing material and on the online store feed from different data sources which are manually synchronized. The manual work is prone to error.

4. Corrective and preventive action
In this phase, interim and permanent actions are taken to deal with all of the problems that a) have occurred and b) similar problems that can be prevented. Corrective action is the implementation of a solution believed to eliminate the root cause of an observed problem, defect or failure. Preventive action means applying the solution to prevent a similar problem from happening in similar processes and products. In cases where the problem impact is high and the permanent solution complex, a Kaizen event or BPI project can be initiated.

Example 1: Putting on sun screen on yourself to prevent sun burn and putting on sunscreen on your children.
Example 2: Use one source for product configuration data to feed the marketing material and webstore.

5. Closure
Closure means verifying by means of data and observations that the problem has been solved and improvement are standardized and sustainable.