Category Archives: Lean

Lean concepts. JIT, Kan ban, Kata, Pull, 5-S, A3, Problem Solving, 8 Wastes, Kaizen, Gemba, etc.

Random Thoughts: Communication, Projects and Problem Solving

I have been thinking about processes… We find something – communicate – interpret – execute then either approve or revisit (PDCA). Sometimes it is true project work and other times it is day-to-day operations. When I think of how we could fail, there is a cartoon that comes to mind that I was shown in one of my MBA classes. There are different iterations of this image but they all are fundamentally the same.

Communicating effectively can be a difficult one to tackle. Half of it is the sender and then you have a receiver that needs to translate what you just said. I know I struggle with this from time to time. I have met a few people in my lifetime that have done exceptionally well with this. The common thing they do is repeat the message back. “Here is what I heard you say…” in their own words. When we write emails or issue work a lot of this can be lost. For critical to success functions we need some sort of direct communication such as an office visit or a phone call to get and give that 360 communication cycle.

While heading down this topic path, I could not resist a comical approach to how the meetings take place. Imagine all of the meetings for projects that you have been a part of. The tasks that are asked and what we are capable of doing are two very different things. Along the same lines of the cartoon above, view the video below. It is easy to see how one idea can go so many different directions and the idea never gets fully realized.

Another topic that I have been thinking a lot about since my visit to Toyota is how we problem solve. Often we have an issue, then call a problem-solving meeting, identify several things it could be, and slap a whole list of action items against it. Sort of like buckshot when you hunt. I only need to get directionally correct and I should hit the target. Sometimes the root cause is not what we really want to hear. It may not be an ah-ha moment and is something as simple as we have good processes in place but didn’t follow them. The root cause may be self-inflicted. Through the solutions phase we need to address the root cause – own our mistakes – and correct that one. That does not mean we need a jillion checks to check our checks. That only creates more work and greater opportunity for us to miss something with the extra work we created just to cover the one thing we missed. Granted checks are not always bad and can be a good precursor or way to see something failing prior to it actually halting a process. When we see the problem at its root we need to fix why that item happened which leads to lots of other symptoms or results. That does not mean we should not create contingency plans for continuity; we just need to be cognoscente as to what we are really gaining. I know I have led events where I facilitated scattershot approaches to cover everything under the sun. I would challenge us (myself included) to simply, standardize, be accountable and repeat.

Leave a comment

Filed under Lean

improvement or diminishment

Consider that everything has a state. Think of a ball and gravity – once it is tossed in the air there is a point when the incline reverts to a decline. At one point, for a very brief moment, it will pause at transition. The moment, however, is so brief that you may not even realize it. Continuous improvement is the same way. Processes do not stay idle long – the status quo will falter and begin to erode. It is either in a process of growth or decay, improvement or diminishment.

Perhaps the reason is commitment or focus. When a process is being improved upon the energy is there. The process is being focused on. At the moment that the energy shifts the expectations to “maintain” kick in. At some point other burning platforms come into play and the focus, what was left, wanes. If that hurt – it should. How many meetings have you held year after year… You have probably been chasing after the same metrics forever and rehashing the same things over and over for periods of time. We need to get the OEE (a metric commonly used in manufacturing) 80% to 85%. Activity…activity…activity…focus…focus…focus… Success! Now think about your goals year after year… If we really continuously improved – wouldn’t we be near “100%” now? Yes, there are systems where we “raise the bar” and the capability changes so that the 80% yesterday is less throughput than 80% today – that is improvement and good inertia to go with! I bet though, you can think of one process where the earlier applies.

Bottom line… put things into place where they continue to move forward. Making short term unstable large leaps is not as effective as long term slow progress. It is either the ball raising… or falling, with a split second of being idle.
#post- .CPlase_panel display:none;

Business, CI, continuous improvement, Lean manufacturing, oee, Overall equipment effectiveness
Business: General, Lean
#Business, #CI, #ContinuousImprovement, #LeanManufacturing, #Oee, #OverallEquipmentEffectiveness

Leave a comment

Filed under Business: General, Lean

boots on the ground: the power of the gemba (genba)

I cannot count the number of times when I thought I knew… or was sure… how something transpired. “The employees are taking shortcuts…” Or you may have many other preconceived notions. I am sure if you have ever been in a problem solving event – many people have the real root cause even before the process has been investigated. The power of any investigation is to actually go to the scene of the crime, or where the action takes place (or took place). The Japanese term, modernized, is Gemba.

Genba (現場?, also romanized as gemba) is a Japanese term meaning “the real place.” ~Wikipedia.com

The embarrassing part is that I can recall many articles, events and stories that I have been made aware of where the employees were never talked to. No 5W+H (who, what, when, where, why and how) was ever taken from the employee perspective.  The facts though are made much clearer by actually going to the place where the action is happening. There is a reason, good or not, why things happened the way that they did. I also believe, from my experience, that people do the best with what they have and the most with what they know. Poor decisions are often result of inadequate tools, work environments or lack of training – not from deliberate attempts to “stick it to the man.” As hard as it may be to swallow, management often has a part of the problem, and it is not noticed until much later when we see symptoms. The root either grows, or the branches spread making it much more visible.

As you begin to form your hypothesis, involve team members from diverse areas including the actual people performing the work. Then go to the floor and see it for yourself; boots on the ground.

#post- .CPlase_panel display:none;

Business, gemba, genba, hypothesis, Investigation, MBWA, problem solving, Root cause
Business: General, Lean
#Business, #Gemba, #Genba, #Hypothesis, #Investigation, #MBWA, #ProblemSolving, #RootCause

Leave a comment

Filed under Business: General, Lean

the side of the majority – status quo

First – break all of the rules… what does that mean? I will have to pick up the text (book) and see what it means. However, a quote recently made me pause and reflect. Somewhere during “growing up” phrases like “stick it to the man” or “don’t conform” seem to come to mind. Yet, as one gets older, and does not work for a trendy Google or Facebook (etc.), the opposite can creep in.

“Whenever you find yourself on the side of the majority, it is time to pause and reflect.” Mark Twain

I would challenge you to consider seeking out the information and identify opportunity. The can’ts can be can’s and the don’ts may be do’s given that with time – knowledge, technology, and leaders change. By being on the side of the majority – are you really pushing everything to the next level, or is the status quo the right decision? There has to be a better way to improve the process either via waste reduction, cost of material change, or processing times…  A process is either in a state of improvement or decay. (Mike Rother, KATA)

Never settle. The moment that we do, we have began the undoing.
.CPlase_panel display:none;

continuous improvement, Google, lean, Mark Twain, mike rother, status quo
Business: General, Lean
#ContinuousImprovement, #Google, #Lean, #MarkTwain, #MikeRother, #StatusQuo

Leave a comment

Filed under Business: General, Lean

Watch that chart! (Special Cause and Common Cause “issues” SPC)

So, SPC, or statistical process control, is a very large and lengthy subject. In fact, there are many books authored on the subject alone. I never realized the impacts of actually studying statistics until I had a class with Dr. Davis Boothe. If you want to get a lot more detail about the subject, beyond what I will continue discussing in future blogs, you can order material here.

Today, I want to focus on the charts. Since most of use graph data I wanted to show you an example or two of how the charts actually tell a story. A chart has two main types of variation: special cause and common cause. Variation is the distant from point to point in the process or the range and comparison to the goal. When most of us create a run chart, we are looking at these things. Most people insert a trend line, and look for trends towards goals. The data can tell us so much more.

spcialcausevariationSpecial cause variation, is probably the most identifiable. There are points in the data which “spike” or cause the process to go out of control for intervals of time (or data points). What is happening that is unique while that data point was being collected – or timing in the process? If you correct the spikes, by correcting the process, the process will actually come back into control. For example, if ever truck was late for delivery on Wednesday’s during first shift. Through a problem solving type event you discover that the shift starts two hours late that day. So, adjust the times of the trucks or crew on Wednesday’s to fix the problem.

Common cause variation is when the process has normal variability based on the parameters (controls) of the process. Most commoncausevariaionof the time the process needs to be redefined so that you hit goal. So if the median is 5, and you are running 10 with common variation, the process needs problem solved to reduce the variation to the desired goal (target). Maybe the machine needs adjusted and that will solve the problem – by calibrating the machine to hit a true zero – you now have the same variation of the process but hitting the desired outcome.

Most of the time, we are presented with a combination. If you have a combination of both types, one has to be solved before the other can be. After you identify the unique “spikes” focus on shifting the process. Charts can also indicate different things… if the data runs high for 8 points, then low for 8 points and the trend continues – consider looking at shifts or operators.  Either way, it is important to study the chart and look for patterns. The data can give you indications as to where to focus.

photo

Leave a comment

Filed under Business: General, Lean

Who’s the in charge around here? (The RACI)

During a project, process or standardization there needs to be accountability. Not only should there be assignments, it should be made visible and accessible by anyone that needs to know. They may need to know so that they can seek assistance for a solution or who should be contacted. A good way to do that is called a RACI.

RACI is an acronym for responsible, accountable, consulted or informed. It is a matrix or diagram which lists tasks or functions and who is designated for area.

RACI diagram matrixResponsible – The person or group which is handling or manages the function or portion of the project. This person is the do-er.

Accountable – The person or group that is the process owner(s) and is ultimately accountable or person that has ownership. The success or failure will be held to this party.

Consulted – The person or group which is consulted before a process decision or action is taken.
Informed – The person or group that is provided information as to the status or progress.

It is possible that a person is tied to more than one function. This is usually within smaller groups, or when it makes sense; the business owner may be A and C, or A and I. The key is that as a part of finalizing your process and moving towards standardization this form is agreed upon and completed.

 

photo

 

 

 

 

Related posts:

Leave a comment

Filed under Business: General, Lean

Get to the roots. (Root Cause Problem Solving)

And there is the problem. We need to solve it.

Every business in existence has had a problem. Each one of the problems detour performance from optimal or desired results. So, what do
we do – try to solve the problem by some means. The approach we use can be the beginning of success or potentially failure. I am confident in this since I am going to fig1make a broad assessment – each of us have identified a problem, put something into place, observed success to only find out that later we are still experiencing the same problem. What happened? Well, either we did not solve the problem or we did not sustain the actions which remedied the problem. Those are the only two possibilities. If the problem came back, but in a different form then we have a new problem to solve. If the same problem with the same criteria exists then we go back to the later, a) we did not solve the problem, or b) we did not sustain the actionables determined at the time. So, in short, we need a solid plan of attack. To get a plan of attack we must understand the gap, or the distance from our current state to the desired state. Essentially, any problem solving is about identifying the gap, and steps needed to execute against to get there.

Identify the problem. What is the problem exactly? Specificity is critical at this point. X happens at Y for Z duration while Process A occurs. We want to have it detailed out so that anyone picking up this statement can understand the reason for this event and the impact to your business.

Assemble the team. This should be a group of people which can relate to the problem in some manner, but do not need to be directly involved. It is good to have a cross functional team, along with ad-hoc members. The team should have a leader, facilitator, subject matter experts and or operators (depending if they are one in the same), and a couple other team members that could provide insight but not necessarily a part of the home team or department. For example, I may include another department, another experienced manager, etc.  A team is not one person calling a group to the office to pound through the exercise to satisfy a required event. Many projects, such as a Six Sigma (Green or Black belt) use a team charter. The charter states the team members, the goal state, the current condition and rough time line (if applicable).

Research any history. This is not a common or traditional method for problem solving. Yet, I find it very beneficial. Remember earlier, when I mentioned issues that reappear or repeat? I have found that looking over previous problem solving data and events to be very rewarding. There have been times that I have switched the order up as well; I have performed this task upon identification of the problem.

During this step take a look at the history of this event. Has there been any problem solving or similar events around this problem? If so, look for the action items that were associated with the event. How many of the action items are still applicable – and are they still in place? What would it take to determine what it would take to put the items back into place or query as to what happened? Sometimes the solutions put into place are discontinued when new events take place. This could include, but not limited to: new crew members, new management staff, new machinery, lost standardized work, complacency since the problem “does not exist,” and so on. If you have a group formed present this data to the group for review. You may find that some of the steps of this “new” event will go quicker – but I encourage you to walk through the steps in case that the originating group was not able to correctly identify the true root cause or that the nature of the problem actually changed thus, creating a different problem.

Identify potential contributors. For each problem there are cause and effects. Many times, at this point, we are not certain which levers control which outcomes so we have several items that need to be listed out here. Some people like to use the fishbone diagram. This cause and effect diagram (which sort of resembles fish bones) allows a group of people to list potential contributors. Many diagrams use the 6M criteria galley_fishbone_01to categorize the ideas into buckets. These categories include: Man, Material, Method, Machine, Measurement, and Mother Nature (Environment). Although many issues have a root cause, it is possible that there are a sequence of events that lead to one problem. In statistics we would use multi-vary testing to identify correlation. (I will look at this in another entry coming soon.)If you have data collected, you could also use the Pareto Principle (80/20 rule) to isolate some of the key drivers. Having data at this point, will only benefit the process. It allows your potential contributors to become more of a hypothesis, or educated guess. In addition, quantity is the key. There are no “wrong” answers and the less than ideal ideas will phase themselves out over time. You have to consider that most people will not propose ridiculous ideas for fear that they will be critiqued.

Identify potential solutionsThere are several methods which can be used to identify potential solutions for the problem(s) listed. I have found that it depends on the group. I know, that is very helpful, right? Let me explain. If the group is an outspoken group, or one which has quickly moved through the phases of assembly (forming, storming, norming etc.) I will let the brainstorming take place on a white board with an open discussion. If the group is slow to respond then I would propose taking sticky notes (Post-it notes) and give everyone a stack. Tell the group to write down as many ideas for solutions as they can which come to mind. Quantity over quality, again, at this point. We want to get the creative juices flowing. After the group has listed out items, start allowing ideas to be suggested from the notes and place the notes on the board. Try to categorize them as well while posting to the board. Many good ideas will “piggy back” another idea, or come to mind from another idea.

Rank the potential solutions. There are several different methods for ranking as well. Some of the ideas could be voted on one by one, or everyone rates their “top three,” or by combining ideas you may be able to narrow down the group to a select few. After this task is completed – 2x2 matrixwe need to move to a way to attack the ideas. For this, I prefer using a 2 X 2 matrix. For this we draw out a large square with 4 sections. They have X and Y axises ranking from low to high. It could be for lowest to highest cost, length of time to implement, ease of implementation, impact to problem or area… The criteria really depends on the actual situation. Once, this is created list the ideas that have made the cut beside the 2X2. With the group’s direction place the ideas into the matrix. The goal would be to have solutions end up in the upper right quadrant. These ideas are the ones that the group will go after first. The lower left are the costly or difficult solutions. It could be the solution – but less likely if you are truly critiqued the ideas.

Pause and reflect. Now, I usually pause and address the group. I summarize where we are at, with the problem solving event. We have identified the problem, researched the problem, identified potential causes and solutions as well as rank the solutions in a priority order based on group consensus. So if we solve all the items within the 2X2, which should correlate to potential contributors, does the group believe the problem will be solved; have we nailed problems/solutions that are likely to be the root cause(s)? As the leader, it may need to be revised a bit at this point before we proceed. Once the group is in agreement, we can move forward. Let us be clear, though, that you are dealing with an experiment if you will. You have likely causes, effects, and educated guesses to solutions. Failure should be considered acceptable, if learned from, and the PDCA cycle (plan, do, check, act) may come into play. That is, we may need to come back together as a group and revisit some of the steps. The key is to document, and be sure that we are executing against what has been agreed upon.

Identify Action itemsSo at this point we have things designed so that we can take action steps. Activities have been mapped out, and now we need to assign SMART goals to the potential solutions. Smart goals are specific, measurable, assignable, relevant, and time bound. List out steps that need to take place so that solutions identified can be put into place. They may include meetings, trainings, setting up tests with parameters for test and control, setting a regroup time, just to name a few. The list should include the ACTION STEP, WHO is accountable, and what date the task is expected to be completed by. The dates may be moving targets and if something needs to change be sure to update the group. Thinking in terms of a Gantt Chart format – others may need to know that the dates have moved due to … so that any dependencies can be adjusted accordingly. Set a time and date for a quick regroup to make sure that the project is still on task, and if anything new has come up. Revisit prior steps as needed.

Regroup for validation Go over the test results as to what was observed. Did the tasks get completed, and did the data indicate your steps provided favorable results? Were you able to see the “light on off” when testing your solution(s)? If process A was changed did the independent variable (test) show desired results compared to the dependent variable (control)? If you add and take away the new process – does the data support that?

As you identify working solutions it is important to start he standardization process. To change a process it is not always just as easy as “go do it.” People like to know the why of the what… they want to know the reasons for the change and the importance of the newly developed strategy defined by your team. I believe it was Covey which stated that it takes 21 days to make a habit and you are dealing, most likely, with a culture that will need to be aware and adopt the new process which will eventually lead to ownership.

ImplementationIt is important that during the standardization process all the operators have input do the creation of the living document. Some documents are called standardized work, OIF’s, job aids, work instructions, just to name a few. During this time train the operators, and allow multiple sessions for everyone to cover the new materials. A recent white paper study SIStem shown that it takes 6+ times of repetition and failure for the process to be adopted successfully by 90%+ of the people.

Create a status check. This is the MOST IMPORTANT step of any of the project steps.  For your problem to be sustained and adopted then follow up events to evaluate the status need to take place. This is both for the operators to provide any feedback for suggestions and to ensure that the root cause was really identified, solution implemented, and sustained.  One of the best ways to validate a process is to audit. Audits can come in the shape of a form, verbal and physical walk through, and examination of recent history data. I would propose that the group plans on auditing the process at 30 days, 60 days, 90 days and then on some form of longer interval. Reminders can come from systems (if you have something in place for tasks – possibly the same a many mechanics use for timely mechanical checks or PM’s). This could be as simple as an Outlook calendar reminder.

Report out of event. Once you have completed this event, determined solutions, and have observed success, a report out of the event should take place. Invite the department managers, supervisors, other management, some team mates (as applicable) and walk through the process of how you identified the problem – determined the gap and put steps in place to close the gap. Report out events are important for several reasons. It is good to show that the money tied into the resources for the test were valuable, allows other departments to consider learning from your events, as well as an opportunity to show professional growth.

LearnigsLastly, I wanted to take a moment to share a few things that I have noticed over time, in no particular order.

  1. If you give people the chance to be quiet while working in a group that is less than engaged, they will be. Call people out for idea suggestions to create or sustain momentum. Many “piggyback” ideas come from other ideas and could be lost if not captured in the group setting.
  2. A couple smaller meetings to gather the group while going over the problem solving steps is often better than one larger meeting. People will tend to get distracted with longer meetings, as most are busy outside of the current tasks you share for the project. In addition, many of the steps could require “homework” and the group will come to a stalemate without the information to proceed.
  3. Take Maxwell’s advice – it is ok to fail as long as you are “failing forward.” During the exercise it is OK to have to take steps backwards and rethink the strategy. If it was an easy problem to fix – you would not be enlisting a team for hours in a formal event setting. Be sure to document any learning that take place for history purposes. They can be put into an appendix and do not have to be shared publicly but will be accessible if the event needs to be revisiting down the road.
  4. The PDCA cycle is a process where we plan for an activity to take place, perform against the activity, check the results and act or refine based on them. The CHECK and ACT (or Status check, above) allows you to continually verify the root cause was identified and sustained.

In conclusion, I could go over this topic for hours. It is important to understand that the tools used are simply that: tools. The real work comes from the dynamics of the team to define and act. We are simply trying to close the gap for to achieve a desired state. If you have any further questions or need help walking through a process please feel free to reach out to me. You can post in the comments below, or visit the contact link within the blog.

To download the Template that I have assembled: ProblemSolvingTemplate

Best Wishes,

photo

1 Comment

Filed under Business: General, Lean, Uncategorized