iSixSigma

How Do You Identify a Problem?

Six Sigma – iSixSigma Forums General Forums Methodology How Do You Identify a Problem?

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #55385

    Zineb
    Participant

    Hello everyone,

    I have a question about the define phase of Lean Six Sigma,

    How to identify a problem? by asking the internal/external customer or by analyzing data ?

    I did not get this point well, can someone help me please ?

    Thank you

    0
    #199764

    Chris Seider
    Participant

    A good consultant listens, gathers data to confirm the extent and existence of the problem and BEGINS improving with the clients on FOCUSED projects that don’t try to “boil the ocean”. However, shortly after, a system to gather losses and prioritize projects must exist.

    0
    #199765

    Strayer
    Participant

    Good question. First off, since lean six sigma concerns quality and efficiency some problems are out of scope. Some may disagree but I say it’s like the old adage that if you have a hammer everything looks like a nail. If it isn’t a nail you should use a more appropriate tool.

    Initial problem identification occurs before the Define phase. Recognition of a problem can come from various sources. It could be data, or customer complaints, or failure to achieve goals or objectives, or just consensus that things aren’t working as well as they should. In any case you need to write a clear problem statement before you start the project. I advise that a problem statement should SPARC. Specific, Proven (data), Assessable (you can measure it), Relevant (to business goals and objectives) and Controllable (you can do something about it). If it SPARCs it should light a fire to do something about it.

    0
    #199768

    Alex Pamatat
    Participant

    In my organization this is fairly easy although many engineers still get it wrong. A majority of the green belts I mentor come to me with projects which are “just go and do it projects”, low level projects for which you can already see line of sight and require simple execution to complete (exactly what @Strayer is describing when you have a hammer everything looks like a nail). I advise them to review the highest level company goal and then work their way down from there to their organization or factory’s highest level goals and keep working their way down to determine how they can impact these high level goals. The company I work for has very clear goals which are delivered to the organization at the same time each year, you’re always promised many things you can work on!

    For example, if one of your company’s goals for 2016 is to increase profit margin from 52% to 56%, one of your organization’s goals may be to reduce cost. Ideally up to this point someone in your factory has a firm understanding of factory spend by process area or manufacturing operation, in this case let’s say that 68% of your overall factory spend is on chemicals and gases used to manufacture widgets, this could be where you stop and begin your DMAIC which would be to reduce overall spend on chemicals and gases. Depending on the magnitude of this project you may decide to go one level lower, pareto out the cost by chemical/gas and select one of the top (2-5) chem/gases to build a DMAIC around. Make sense?

    Whatever you select, I consider one of the major deliverable from the define phase is a review by management of your project charter. Your organization needs to agree, at a high level, that your DMAIC will be resourced and that the project you’ve selected ties directly into company/customer goals.

    0
    #199770

    Chris Seider
    Participant

    @notoriousapp

    I hope rationalization of sales pricing, product selection, product/process design are also part of the company goal. Supply chain/manufacturing is only part of that price impact.

    My two cents.

    0
    #199771

    Alex Pamatat
    Participant

    @cseider: Yes, most definitely. There are non-supply chain organizations in the company trying to figure out how they can increase top level sales, determine which parts to end-of-life due to low profit margins, develop new products and/or develop new markets for our products, use external manufacturing where possible to reduce costs, etc. My example was just to outline the thought process for one aspect of my company, obviously (at least to you and I) that the applications are nearly endless.

    0
    #199773

    MBBinWI
    Participant

    You will find a problem in any circumstance where there is less than the ideal situation. Thus, you can well imagine, there are problems everywhere! The real key is not in finding problems, but in selecting the right problems to fix.

    I would suggest you do some reading on Theory of Constraints (TOC) – start with the book “The Goal” by Eli Goldratt. From this you will find that the key to improvement is to identify the constraint in the system. By identifying the constraint, you find where to apply improvement, for if you can improve the constraint, you will truly improve the output of the system. I have seen too many projects go after “problems” that didn’t address the constraint. They did fantastic jobs in reducing downtime, quality rejects, etc., but because they didn’t improve the constraint, these improvements failed to improve the overall system.

    Good luck.

    0
    #199775

    Mike Carnell
    Participant

    @ga,zineb Just a little clarity. How do I identify a problem or how do I identify a project. They are very different questions. Since you have asked about detecting a problem then I will start there. Normally the problem detection is at the Executive level, When they are setting the goals/strategy for a company they have to determine what that company needs fixed. One of the most successful deployments we have done the Leadership Team asked us for “$98M in EBIT improvement over the next 2 years.” Obviously they had done some financial analysis and decided there was a financial issue and our part of fixing that problem was to increase the value of EBIT. Once they identify that issue then it is pretty simple. There is a very old thing called a Dupont chart – basically a tree diagram. There are large consulting companies out there that market this as a cost driver tree but there is nothing new about this concept since DuPont started using it in the 1920’s. If I start with EBIT there is no project specifically at the EBIT level because it is a calculation from several factors but primarily Revenue and Expense. Since Revenue and Expense are calculations they are not going to have specific projects but the inputs to those numbers may. Basically you chase it back until you no longer have a calculation and you have potential projects.

    Going back to the concept of a “Problem” there is no real formula. It has to do with the basic condition of the company. Most people who begin SS want a bunch of people doing projects and getting savings. That is a stupid and primarily lazy strategy. Nobody is putting the effort into the company to understand where the issues are. Let’s say a mining company has had 20 fatalities in the last year. There is a problem in safety. If a company is having issues paying down debt. There is probably an issue with Free Cash Flow. Companies that lost market share in the recession and haven’t gotten it back could have a lot of different issues so you look at marketing, quality, OTD, etc.

    You asked specifically about talking to customers. It is always a good idea to speak to customers. What you do with that is a whole different idea. You can run around and try to keep up with whatever is their issue for the day. When you use data and have those conversations then you can get them past whatever issue they have had in the last 48 hours and onto the chronic issues. This whole idea of interviewing people to either learn their issues or operators to learn their issues and walking in with no information of your own is stupid. Lets say you are running a process at 3 sigma capability. They might see 3 defects in 1000 operations. How likely is it that anyone saw it, understood what they saw and understand how to fix it? That is a low probability conversation.

    Just my opinion.

    0
    #199777

    Landry Iragi
    Participant

    @Mike-Carnell, How would you now identify a Project?

    0
    #199783

    Mike Carnell
    Participant

    @Landragi You are going to get the infamous “it depends.” If you have a well defined system for managing your SS deployment then as a belt you should be given a project that has a rough problem statement and has been approved by some type of steering committee (the management team)and some very rough financial data. From there you gather data get a high level process map, build a financial model (it should have some type of analysis from management so they can make a decision on ROI when they approve it). Generally it is a drill down process that should be taught in Define as a multiple level Pareto Analysis. You have a top level Pareto and then you take the bars that represent to top 80% and create a Pareto for each of those bars and so on. Personally I prefer the tree diagram because when you present to management they don’t seem to be able to remember how you got to where you are once you begin to flip between Pareto charts. At some point you cannot drill down any further and generally that is the level where the project exists. From that point it becomes MSA and capability studies to get you focused. Just remember that Capability might help your level of understanding but it won’t do a thing to move towards a solution. If you start throwing around the term Cpk, Cp, Ppk, Pp you will lose most of the people on your team.

    If you do not have a well defined system which, most don’t then you get to wander around and pick a project. This in general is going to irritate the Process Owners who do not want projects identified in their are particularly large ones. Let’s assume you at least have a problem identified by a leadership team then you begin the drill down process there. Again you keep going until you get to an actionable level.

    If you are in the second situation then you have some basic problems. Your deployment is in the hands of people who do not really understand how to determine what does and does not have an impact. More likely than not they are more inclined to do project reviews and give you a bunch of crap about how you used a tool or how you analyzed data. If you look at Bloom’s Taxonomy you will see that the top level is named various things these days but the basic skill is to be able to take various projects and put them together to solve a large problem. Somewhere that skill has escaped the MBB’s of today and they seem to want to operate more as counterfeit academics that want to impress you with their knowledge of stats as opposed to their ability to solve problems and deliver results.

    The short answer is a drill down process. Now understand that people consider 5 Why as a drill down process. I can be if you use data as you jump from one level to the next. If you just want to sit around a campfire singing Kumbaya and let the “experts” deliver their opinions on the next cause then you might as well just do a brainstorming session and throw away all your analysis skills (The Winston Churchill quote “these gentlemen, are the opinions on which I base my facts.)

    How well you do is going to have a lot to do with how well you drive people to use data. This was meant to be a data driven approach and we continue to allow non-data techniques creep in using names that make them sound as if they used data i.e. heat maps, Pugh matrix, etc. They are just tools to group opinions without any substance. Your call.

    Just my opinion.

    0
Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.