<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
	<channel>
		<title>Six Sigma Blogs at the iSixSigma Blogosphere</title>
		<link>http://blogs.isixsigma.com/RSS2.asp?action=full</link>
		<description>Six Sigma Blogs at the iSixSigma Blogosphere</description>
		<language>en-us</language>
		<copyright>Copyright 2004-2009 iSixSigma</copyright>
		<managingEditor>blogosphere@isixsigma.com</managingEditor>
		<webMaster>blogosphere@isixsigma.com</webMaster>
		<generator>iSixSigma Blog 1.0.5</generator>
		<lastBuildDate>Fri, 20 Nov 2009 14:42:30 -0800</lastBuildDate>
    	<ttl>60</ttl>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Ultimate Organization?]]></title>
			<link>http://blogs.isixsigma.com/archive/the_ultimate_organization.html</link>
			<description><![CDATA[

I’m going to go out on a limb and open up a discussion on the "Ultimate Organization" here.  In my last two posts, I talked a little bit about integrating the 6S culture in an organization (vs keeping it at a specialist level only) and organizational fear.  I figured a logical progression of the overall discussion would be to open up a thread to talk about what the ultimate organization would look like.  

Take a minute to reflect on your experiences (good and bad) on your involvement in 6S.  Then, if you can find the best scenario for success, fast forward a few years to the end game.  What does it look like (from president to the front line)?

There are a few motivations behind why I’m asking the question. The main one is that a lot of times we talk about what doesn’t work, or challenges that we face, but in the grand scheme, I have yet to see a discussion around what "utopia" looks like from a 6S standpoint.  Based on the varying experiences and industry affiliations of the readership here, I am really looking forward to the diverse possibilities of answers, as well as some great dialog.

Happy daydreaming!

-K

]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Tue, 20 Oct 2009 18:05:19 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Culture Change and Fear]]></title>
			<link>http://blogs.isixsigma.com/archive/culture_change_and_fear.html</link>
			<description><![CDATA[

There’s no doubt that fear can prevent an organization to be what it could be, but what can be done about it...how many times have you been in a situation where there were problems to solve, but no one stepped up to the plate to solve them because of fear? Piggy-backing on my previous posting, this could be another inhibitor to making 6S truly mainstream.  Take for example the following:
A defect is identified, and there is no clear root cause.  Short term fixes are employed.  A person is nominated to handle the problem solving, and as analysis is performed, the exercise becomes one of self-protection.  Groups that are involved begin to work on proving that they are NOT the root cause.  The activity becomes so muddy that no clear root cause is ever found.  Whatever band-aid that was put in place becomes the solution, and the cycle starts again...
What is the bottom line here?  To me - fear.  Fear of being the guy or gal that stands up to say their department owns the root cause...just like fear shuts down dialog, fear can also shut down team problem solving.

So the question is, how do we foster change so that we overcome fear?  How do we create a safe environment for problem solving effectively with free expression?   

]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Thu, 01 Oct 2009 18:27:50 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Is There A Place For Six Sigma As We Know It In The Future]]></title>
			<link>http://blogs.isixsigma.com/archive/is_there_a_place_for_six_sigma_as_we_know_it_in_the_future.html</link>
			<description><![CDATA[I have been thinking about various topics regarding Six Sigma recently, and I keep coming back to a question that is hard to answer...if we "do Six Sigma" right, is there even a place for Six Sigma as we know it ten or twenty years down the road?Consider this.....ten years from now, do you really want to have Black Belts doing project work? Or...do you want Six Sigma tools to be the status quo of how the business is operated by everyone? To me the latter is the end game, but does the "classical" approach to Six Sigma (Black Belts doing projects) fit the end game??...I’m not so sure.How do we structure Six Sigma in general to better fit the end game of real culture change, instead of creating a bunch of "super problem solvers"?]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Sat, 26 Sep 2009 20:27:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Why is Quality Planning So Much of an Afterthought?]]></title>
			<link>http://blogs.isixsigma.com/archive/why_is_quality_planning_so_much_of_an_afterthought.html</link>
			<description><![CDATA[


It’s really interesting for me to look back and think about how many times quality planning has come up as an afterthought.  It is staggering for me to think about what could have happened if quality planning was done the proper way.


Here’s an example....one time I was involved with a new product introduction, and one of the major milestones in the quality planning protocol was for gage repeatability to be assessed and acceptable by a certain date.  Sounds fine and dandy right?  Well, the exercise turned into a frustrating one, as discussions turned into something like "did the gage r&amp;r’s get done today?", without even considering why they were being done in the first place.  Moreover, people who didn’t know the first thing about what a grr was were asking the questions.....


I’ve seen this phenomenon across several industries, and it makes me wonder if up-front quality planning generally is really taken seriously at all.....

]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Sun, 26 Jul 2009 20:06:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Practical Use of Control Plans]]></title>
			<link>http://blogs.isixsigma.com/archive/practical_use_of_control_plans.html</link>
			<description><![CDATA[
Now more than ever, the development and use of control plans play a critical role in succesfully implementing a new process. In my past, I have seen varying ways that control plans have been implemented, but I still struggle a little when I try to find a really good example of control plan development.

To me, control plans need to be developed upfront in the development process. This is really important so that key product attributes (ctq’s) are constantly aligned with process control parameters. Some may think that developing control plans this early is a waste of time (since processes typically don’t get defined so early), but why not let the process itself be defined by the control plan?

So how do your organizations use control plans... I’d love to know...
]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Sat, 09 May 2009 11:04:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Leadership - Important Now More Than Ever]]></title>
			<link>http://blogs.isixsigma.com/archive/leadership_important_now_more_than_ever.html</link>
			<description><![CDATA[Recently James Considine and Stephen Crate have posted about management styles....and their posts have really made me think about management and leadership in general, especially during these challenging times...
From my perspective, you have to lead people to achieve results.  If you are a manager, indeed your job is to manage the business, but to lead and support people as well, rather than manage them.  Given the right amount of coaching and "rope" if you will, your employees may surprise you in what they are capable of achieving.
I reported to a manager at one point in my career that I would do anything for.  He really led me to higher performance and really coached me in my own management skills - and the things I learned I still use to this day.  He always made clear what my objectives were and basically followed-up on progress on an as-needed basis, rather than telling me which discrete tasks to perform.  It was my responsibility to come up with my own checkpoints and milestones in order to accomplish my goals, and with his input, I would execute the plan.  Granted, there were times that demanded a direct order, but those were in crisis situations which demanded that style.
There are a lot of advantages to leading people to performance - but the biggest advantage is the teaching that occurs during the process.  As a leader, a major responsibility that you have is to teach your employees how to plan and how to achieve goals.  By doing this, you effectively raise the competence level of them, and better prepare them for more responsibility.  This dramatically helps with succession planning for sure, and creates depth in your organization.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Management]]>
			</category>
			<pubDate>Mon, 27 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Statistical Significance vs. Practical Significance - There Is a Difference]]></title>
			<link>http://blogs.isixsigma.com/archive/statistical_significance_vs_practical_significance_there_is_a_difference.html</link>
			<description><![CDATA[Today I was reflecting on a potential topic that could come up in a traditional project involving any test or DOE utilizing a 'p-value' criterion - it actually did for me a few times in the past.
Hypothetically, say for example there is a process that has very low inherent process variation (process s is very low), with a very high Cp or Pp (depends on how you define s, but say 2.0 or greater), yet has a very low Cpk or Ppk (or Z for that matter - basically the process is hugging or is outside either the upper or lower customer acceptance limits, but very stable at this level), so the situation is characterized as a classical optimization problem.
A black belt performs a DOE, and finds a factor that has a P-value of 0.05 or less on the output.  Using the information, the new factor setting is applied to the process, and the new Z value has barely improved.  The black belt is frustrated, because the factor was 'supposed' to be significant.  What gives?
In this case, the effect of the factor was much smaller than the level of optimization needed to make a real difference.  But the effect was large enough to make a statistical difference based on the low inherent variation level of the process.  A quick check of the main-effects plot (and the coefficients in the analysis for that matter) compared with what's needed to achieve the required optimization would confirm the situation.
So why would this happen anyway?  I've seen some black belts "go by the numbers" (specifically p-values) without looking at the graphics....and without looking at the real picture of what's needed at the output side of the project.
A great teacher once told me to look at the graphs first....he was right.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 22 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Crucial Conversations: Tools For Talking When Stakes Are High - A Review]]></title>
			<link>http://blogs.isixsigma.com/archive/crucial_conversations_tools_for_talking_when_stakes_are_high_a_review.html</link>
			<description><![CDATA[Every once in a while, I'd like to share some reviews of key books that I've read so far in my career that have been particularly useful.  For my first review, I'd like to reflect upon Crucial Conversations: Tools For Talking When Stakes Are High - by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler and Steven Covey.
This book has been really key for me in my career thus far (although I still read it cover-to-cover for a refresher).  Having a former position as a Master Black Belt, and now as a manager, now more than ever it's been important to work on my communication skills in difficult situations.  In Six Sigma, we are all change agents of some type or another, so there are always going to be people that resist change or that want to run interference to making progress.  Most likely you have found yourself in a position to have a crucial conversation with these people.  Maybe this book can help.
First, this book is copyrighted 2002, so it has been on the market a while - but -  the information contained is timeless.  The book starts by describing what a crucial conversation is - basically a difficult discussion with the potential for emotion.  After this introduction, the first few chapters afterword describe the mechanics and psychology about emotions and dialog.  I was really shocked at some of the inner workings on how discussions become heated while going through these middle chapters (like I said before, I use some of this material as a critical reference sometimes),   Around chapter 9  or 10, the book moves into practical application of the process of constructive dialog, and in chapter 11, some 'what if' scenarios are presented, which I find very useful to refer to sometimes.
I haven't given any real detail regarding book content in this post, but since I have a few crucial conversations coming up myself, I figured I'd share this gem with you.  It's a simple read, and I really believe you'll get a lot out of the book.
Here's an Amazon link
 ]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Book Review]]>
			</category>
			<pubDate>Mon, 20 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Innovation Gone Bad - Here We Go Again]]></title>
			<link>http://blogs.isixsigma.com/archive/innovation_gone_bad_here_we_go_again.html</link>
			<description><![CDATA[Over the weekend, I happened to stumble upon this news link on Yahoo.
The L.A. Times apparently published a front page advertisement that looked very much like a regular news ad.  Of course upon inspection, the advertisement disclaimer was there.  According to AFP:
"Publisher Eddy Hartenstein told the Times he had decided to run the ad despite protests from the newsroom because he was trying to ensure the newspaper's survival.
'Because of the times that we're in, we have to look at all sorts of different -- and some would say innovative -- new solutions for our advertising clients,' he said."
Here is another example of innovation gone bad in my opinion.  Clearly, revenue has taken a front seat to customer value in this case, with a potential long-term impact to customers and reputation.
 
I'm starting to see a trend here....]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Innovation]]>
			</category>
			<pubDate>Wed, 15 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Does It Get Easier As You Get Better? - It Shouldn't]]></title>
			<link>http://blogs.isixsigma.com/archive/does_it_get_easier_as_you_get_better_it_shouldnt.html</link>
			<description><![CDATA[Throughout my career I’ve had the pleasure of meeting colleagues from a very large variety of manufacturing cultures.  Sometimes I talk to people that work in a "mass" environment with poor performance, and I hear about how good it must be to work in an efficient workplace, with relatively good performance.  I always get the questions about how easy it is.
Let me tell you...it’s not easy, and by the way - it shouldn’t be.
You might ask me why....and here are some reasons.
The name of the game is continuous improvement.  If your organization doesn’t get better, then you aren’t  going anywhere.  You maintain your improvements be continuously revising your metrics to reflect your improvements.  Your plant may start at 50% production efficiency, then move to 75%, then to 90%, then to 95%, 97%, 99%, 99.5%, etc...how hard do you think it is to go from 99% to 99.5% production efficiency?  It’s very difficult - probably more difficult than going from 50 to 75%.  No doubt, you’re doing much better at 99% than you were at 50%...but then again, the 50% number doesn’t matter anymore, since your system has grown to be much more capable than that.
Now, imagine what it’s like to have this approach with all of the organizational metrics.  The unique part about all of this is that this type of culture grooms people into constantly thinking of how to get better every day.  That’s a powerful element.  
Any people out there living through this type of culture?  What are your challenges and how do you get through them?]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Lean]]>
			</category>
			<pubDate>Mon, 13 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Financing Six Sigma Training During Difficult Times - An Option]]></title>
			<link>http://blogs.isixsigma.com/archive/financing_six_sigma_training_during_difficult_times_an_option.html</link>
			<description><![CDATA[During difficult times like we’re facing today, some of the first things that get cut are the "non-essential" items not related to core business.  Of course, the paradox here is that some items that are deemed "non-essential" are actually huge enablers to a company.  Take for instance Six Sigma....definitely an enabler, but if your program is in its infancy, it may be easy for it to be placed on the chopping block.
If you fear that your program is getting the ax, an option that you can consider is tapping into a training budget.  Many states (and maybe even other countries - but I’m not sure about that) offer training funding that is independent of operating budget.  You’ll have to check with your appropriate department at your company for the particular rules around this topic, but it may be a feasible option.
Be aware, you will most likely have to separate training from consulting services, but usually it’s just a matter of having your Six Sigma partner separate their quote accordingly.  
You could potentially lessen the blow to your operating budget, which is absolutely sacred in our current operating environment.
Has anyone found other creative ways to finance Six Sigma activity?  I’m always looking for them...;)]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 09 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Let Them Be Lean! - Um, What Does Lean Mean?]]></title>
			<link>http://blogs.isixsigma.com/archive/let_them_be_lean_um_what_does_lean_mean.html</link>
			<description><![CDATA[Over the years, I’ve come in contact with several different companies that say that they are "lean".  Yes, TPS (the Toyota Production System) is a great framework for production, with its teachings of one-piece flow, kanban, etc...but what about the actual implementation of the lean concepts at other companies besides Toyota?
I’ve seen desks with outlines of where the stapler and the computer monitor should go, yet with no sense of continuous improvement in the culture.  I’ve also seen kanban implemented with min and max levels clearly marked, yet with no safety stock even left due to variation in production downtime.  On the other hand, I have seen a really good "lean" production system operating every day as well, but that has been the exception.  
What’s up here?  It seems like that it is almost impossible to get to real ’lean’ operations unless you actually start up with a lean philosophy.
So here’s a burning question--
Overall, is "lean" a concept that is being actively implemented with success at "mass production", or is it something that is being attempted by doing all of the easy things first while putting off the hard stuff?
As always, your input is always appreciated!]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Lean]]>
			</category>
			<pubDate>Tue, 07 Apr 2009 20:11:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Financial Crisis - When Profits Win Over Building Customer Value]]></title>
			<link>http://blogs.isixsigma.com/archive/the_financial_crisis_when_profits_win_over_building_customer_value.html</link>
			<description><![CDATA[One of the aspects of Six Sigma that makes the process so great is the focus on the customer, and the gathering of the VOC (voice of the customer).  Using the VOC information a company can begin designing ways to improve customer value, by designing products and processes that are centered around customer requirements.  Doing this effectively maximizes profits while adding value to customers.  In addition to these things, the company begins to build a solid foundation based on business principles that are aligned with customer expectations.  The real advantage gained is the link between the customer and the company.
However, what happens when a company (or an entire industry for that matter) places the highest priority on maximizing profits, even at the expense of customer value?  My opinion is that the current financial crisis is a direct result of mortgage companies doing this very practice.
Let's look at the "pre-bubble explosion" state of affairs in mortgages in general.  How easy was it to obtain an interest-only loan from lenders in the United States?  Virtually anyone could.  How does an interest-only loan add value to the customer?  Short-term, the customer has a lower monthly payment... but is that real value added when the customer's monthly payments balloon in a few years, and the mathematics between annual income and amount borrowed doesn't even make sense?  Since I don't work in the financial sector, I'm not sure, but I have a feeling that there was some hedging going on based on projected property values....
Innovation without regard to real customer value is a disaster waiting to happen, especially when customers perceive that they are getting value.
I will say that the whole interest-only mortgage design is very innovative and for sure is designed to maximize profits.....but ultimately, who is paying the price for all of that "short term" innovation?]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Innovation&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Sun, 05 Apr 2009 10:10:14 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Can We Use Six Sigma Tools Outside of Projects?]]></title>
			<link>http://blogs.isixsigma.com/archive/can_we_use_six_sigma_tools_outside_of_projects.html</link>
			<description><![CDATA[One of the things that I see as a challenge to companies that grapple with a Six Sigma implementation is effective use of tools in "live" situations. By "live", I mean in a normal operations context, not in a project context. When looking at the use of Six Sigma tools, using them in a project mode in my opinion is an easier affair. A project leader can plan in a project context which tools to use, based on the DMAIC project model.But what about "live" application of tools? For example, why can’t DOE used to diagnose problems on the factory floor outside of the DMAIC formal context? Consider this:A product is defective, and it is composed of 4 parts. Run a four-factor DOE with the factors being part presence (yes/no) and find the potential contributor(s) and contributing interactions. This will at least give you an idea if the component part inputs are influencing the defective condition, and will get you at least half way to problem resolution.
Most of the time in the case above I’ve seen engineers "measure their way" into a guess of a root cause to the problem, which can be inefficient to say the least.
My opinion is that the real power of Six Sigma comes once culture change sets in and real problem solving occurs as part of the business, and NOT in the form of Six Sigma projects only.  It seems like common sense to me that advanced tools would be used anyway to solve problems, but in most of the different companies I’ve been involved with, I can honestly say that I have not seen much use of the statistical tools in "mainstream" use.
What restrains companies from using Six Sigma tools beyond the DMAIC project scope?
 ]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 03 Apr 2009 11:57:02 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: How Many Sigmas Does It Take to Solve a Problem Around Here?]]></title>
			<link>http://blogs.isixsigma.com/archive/how_many_sigmas_does_it_take_to_solve_a_problem_around_here.html</link>
			<description><![CDATA[Tonight I was thinking about some of my experiences since being involved with Six Sigma.  One experience came to mind that when looking back, was so funny in the context of the situation, that I can’t resist sharing it.
I was working on a project that was to improve quality of parts arriving to a particular customer.  This customer was very critical of our shipping quality, and rightfully so - we had some challenges with the product that we were making for that particular customer.  The project had all the essentials of a great project - a clear problem definition, a good scope, variable data to analyze, with process controls that were adjustable (perfect for DOE’s, etc).
I was called into a meeting where we were discussing this product at the customer’s campus, and I (as the project leader of the problem) had to speak on project status.  My audience consisted of various managers, and a senior manager who was running the meeting.  There were probably ten or so people at the meeting, and I was the lowest organizational level person there.  So after a few minutes of initial discussion, I started to give status.  I started explaining how we framed the problem, and how our team established good measurement repeatability through the "Measure" phase.  I stated that our team was in the "Analyze" phase, and I explained our analysis plan.  As I was explaining, I noticed that the senior manager was squirming around in his chair, he seemed to become more and more uncomfortable as I kept explaining.
Finally, he couldn’t resist anymore, and cutting me off he said:
"I don’t care if it takes one sigma, two sigmas, five sigmas or twelve sigmas!  I just want the problem fixed...how many sigmas is it going to take!?"
I was completely taken back by this statement, and all of the managers’ eyes turned to me for my answer.. I was at a loss for words until I managed to muster up a response.  I said:
"A lot"
What else could I say??]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Wed, 01 Apr 2009 16:49:36 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The 1.5 Shift - Time For A Paradigm Shift?]]></title>
			<link>http://blogs.isixsigma.com/archive/the_15_shift_time_for_a_paradigm_shift.html</link>
			<description><![CDATA[Years ago (almost ten now!) when I was going through Black Belt training, I remember seeing the famous slide describing what a three-sigma world would look like.  The presentation slide described how three-sigma aircraft landing performance would mean two long or short landings per day, and that 20,000 articles of mail would be lost per day at a three-sigma level.  After completing the presentation, an astute participant in the class asked why 3.4 DPMO was described as six-sigma performance...to him, it seemed like a high level of defects for a true six-sigma process.  
All statistical purists know this is the case, but the instructor started describing how the 1.5 shift and drift effect degrades performance over time, and that this number was used based on historical performance, etc....
Since I've been in a position to coach various individuals in six sigma concepts for some time now, I have to admit that each time I describe the 1.5 shift it gets more and more frustrating.  Here's why:

The 1.5 shift doesn't really hold over time in all cases, so it can be a poor approximation.  I've seen long-term performance influenced by much less than a 1.5 shift and drift factor (sometimes maybe more like 0.5).  Likewise, I've seen much worse (maybe at 2 or 2.5). 
I can't honestly say that from my experience the shift factor distribution is normal, so therefore I can't predict it ;).
Based on this, here's my proposal:

Get rid of the 1.5 shift factor in training, and explain only what long term shifts in the processes do to process performance.  
As a second step, explain how to calculate a short-term and long-term sigma value from a process.
Lastly, make a "continuous improvement" metric out of getting the long-term process sigma value closer to short-term sigma performance levels (minimizing process shifts).
At the very least, the above methodology should make the concept of "long-term shift" more understandable to new practitioners, and make it a practical tool as well.
 ]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Tue, 31 Mar 2009 18:10:08 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Good Evening, Would You Like Some Nimawashi With That?]]></title>
			<link>http://blogs.isixsigma.com/archive/good_evening_would_you_like_some_nimawashi_with_that.html</link>
			<description><![CDATA[Well, let me start by saying - its GREAT to be back!  After two years, a LOT can change from both a professional and personal standpoint, and I am really happy to contribute again!
To kick the conversation off, I'd like to talk a little bit about a concept called Nimawashi, which in the Toyota context means building consensus before taking definite action.  Seems like common sense, right?  Well, not always.  Let's look at a case study.
You have a major concept or breakthrough that you need upper management approval on, and you have to present at a decision meeting two weeks from now.  What process do you follow in order to be successful at selling your idea?  You decide to slave over a detailed presentation for the two weeks, sweating the event the whole time leading up to the actual meeting.  The meeting comes, and you present your idea.  At the end of your presentation, the questions start.  VP number 1 asks you a doosy, but you get by with a good answer.  VP number 2 asks you a another question that came out of nowhere, and you weren't prepared for it.  You say the "I'll get back to you on that, sir" line, and in the background you see the president looking at you with a skeptical look.
Needless to say...it didn't go that well - you get the idea.
So how can Nimawashi help you in the above circumstance?  The key enabler of Nimawashi is to allow you to build consensus on a topic before the major decision point.  In this case, the decision point is the meeting.  Using the concept of Nimawashi in the above example, before even beginning the presentation, your first priority is to make appointments with the key VP's one-on-one well ahead of the meeting so that you can present your ideas.  It's a lot easier to convey a new concept on a person-to-person basis instead of a whole audience, and you can also take advantage of the time to allow for questions one-on-one as well.  After a week of brief meetings with the VP's, you now have a week to answer any new questions or tweak your presentation in order to make it perfect for the meeting.  Now, when the event comes along, you have already "pre-aligned" your concepts with the key decision makers, and most likely they have already aligned with the boss (president in this case) as well.  At the end of the presentation, it's most likely that you will get a "rubber stamp" of approval - WHEW!
Now go ahead and implement that great idea!]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Innovation&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Mon, 30 Mar 2009 18:09:55 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Heres To A Great 2007!]]></title>
			<link>http://blogs.isixsigma.com/archive/heres_to_a_great_2007.html</link>
			<description><![CDATA[(Continued from "Lean Journeys - Part 2")
Another year is upon us, and it’s time to look forward to new challenges and frontiers. It has been a while, and I will finally finish my thought on going lean from back in October! (Thanks for bearing with me - please refer back to "Lean Journeys - Part 2" as a refresher).
Bottom line - by proper batch-sizing, the stamping operation went from being a 7 day operation to a 5.5 day operation. This allowed us to concentrate our focus on continuous improvements as far as changeover time, and uptime, without shorting our customers. Of course, by doing the batch sizing optimization, we weren’t lean. We were in a better position to get lean. As we made improvements in changeover, we reduced our min-max levels gradually. We found that that was the optimum way to go, while still supplying our customer (assembly area) with componenets.
There was resistance in expanding the batch sizes, as this was counterintuitive to lean thinking. It was a little bit of a struggle to show how this short term "hit" could be the means to the end (of being leaner). I really tried to show how important it was to keep the customer supplied in the short-term, while making improvements to help the long term.
Best of luck to everyone. Have a safe and prosperous 2007!]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Mon, 01 Jan 2007 22:15:39 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Lean Journeys - Part 2]]></title>
			<link>http://blogs.isixsigma.com/archive/lean_journeys_part_2.html</link>
			<description><![CDATA[(Continued from "Lean Journeys - Part 1")
There were two departments in the plant, and the press area served both with most of their raw material.  After about two weeks on the job, I found that my area was shutting down one assembly cell per day on average.  As you could imagine, my stress level was getting very high in a short time.  I started making daily schedules of what I wanted to run and when I wanted to run it.  I tried scheduling by piece count and by run time, but nothing I did worked.  I knew that I had considerable downtime, and my changeover times were considerable, but I was in a constant state of firefighting for weeks.
After consulting many references, I started to take a six-sigma approach to the dilemma.  What were the inputs?  Obviously changeover time was an input.  Running downtime was another....but what was the "Y" here?  I initially went with assembly stock-outs per day, since if I could keep the plant running, I could buy time to make the press area more efficient.
First, I had to figure out what my average customer demand was (takt time), and weather the demand was leveled.  Leveling of demand is very important, since this makes the production signals of a pull system stable and predictable.  As it turned out, my highest demand product was shipped as an assembly in one week quantities to Europe by boat with a two-week lead time....not good, but I considered it system noise since there was no way to immediately control that factor.  Luckily, the weekly demand for the product was stable.
As it turned out, taking a hard look at the operations, I found both good news and bad news.
The good news:
I had more capacity than I thought…on average I could run more pieces than my demand required.
The bad news: 1) My changeover times were astronomical.2) My unplanned downtime was also too high.
What was happening was that the min-max levels for the pull systems were so low, that the average press was almost spending more time changing over than actually running parts!  This was causing sheer chaos in the operation.
The improvement plan consisted of:
1) Re-setting min-max levels to reflect operations characteristics (aka “Take the initial hit”).2) Improve changeover times/reduce unplanned downtime using conventional problem solving.3) Lower min-max levels to the improved operations characteristics.4) Repeat the problem-solving process.
My next blog will discuss the before and after results of the activity, and will also discuss some of the conventional stumbling blocks for “going lean”. 
Please take a look at the following as they are really excellent references:
Kaizen for Quick Changeover: Going Beyond Smed by Kenichi Sekine, Keisuke Arai, and Bruce Talbot
Factory Physics Second Edition by Wallace Hopp and Mark Spearman]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 17 Oct 2006 17:58:18 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Lean Journeys – Part 1]]></title>
			<link>http://blogs.isixsigma.com/archive/lean_journeys__part_1.html</link>
			<description><![CDATA[Deciding to go lean is very popular in today’s business climate.  Eliminating overproduction and reducing excessive inventory (along with waste) is a must.  If you’re a black-belt, you’re role may be central to the lean transformation (depending on the organization).   Although there are many benefits to leaning-out operations, especially in a batch processing operation, there are also many growing pains that go with it.  The important question to ask is weather or not your operation is ready for them.
Today I have been thinking about some of my past experiences with lean implementation.  I will always remember my first day on the job as an operations supervisor in a stamping shop.  Since I only worked in an MRP (scheduled) environment before that, I was impressed at the kanban areas and the visual min-max levels.  I remember being somewhat perplexed that day though.  The problem was that all of the kanban areas were empty!  I remember thinking that I could schedule my way out of the issue without any problems.  I was absolutely wrong, and the following months proved to be some of the most challenging yet rewarding in my career.  Check back in a couple of days as I continue with this story, but for now, what are some of your experiences in implementing "lean"?  Please feel free to share them!
Lean Journeys – Part 2]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Thu, 12 Oct 2006 23:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Data Collection in the Factory]]></title>
			<link>http://blogs.isixsigma.com/archive/data_collection_in_the_factory.html</link>
			<description><![CDATA[One of the toughest challenges that a manufacturing black-belt faces is institutionalizing data collection systems that yield project-critical information.  Whether the needed data is attribute or variable, it is still a tough challenge to implement the system.  Once the GR&amp;R issues are resolved, it doesn’t get any easier.  At this point, the black-belt has to “make it happen” on the floor.  Many of us have been there, standing on the line for hours training the personnel on the proper measurement procedures required. 
If you are an integrated black-belt, you have even less time to dedicate to the system implementation, yet the need for the system still exists.  I’ve found that in this case, it helps to obtain maximum leverage from resources at your disposal.
Some of the best sources of leverage are the front-line data collectors.  These people are typically team leaders or production team members that actually make the products on the shop floor.  They have a wealth of practical knowledge of the production process, and are, in most cases, willing to help improve the process in any way possible.  However, I’ve seen cases where data collection sheets are pushed onto the data collectors, without any input from them, without giving them any insight as to where the data is going, or how it will be used.  Naturally, the response from the data collector is less than enthusiastic, and since the system depends heavily on him/her, the system is likely to fail.
Here are some ways that I’ve found to leverage these very important team members to ensure data collection success:
1) Involve the people that build the product at the very start of your implementation.  In this way, they are involved and realize why the need for the data is important.  Remember, physically taking the data can be more of a burden to them, so it is absolutely important that they realize how important it really is.
2) Give the team members a chance to make the data collection system successful before going to their supervisor.  It may be very tempting when activities seem to stall to go to the supervisor for support.  Support the team members, and they will support you in most cases.  Of course, there will be cases where you will need supervision to help.
3) Let the team member collecting the data be a part of the data “report-out”.  Eventually, the data has to be reported on or used in an analysis.  Giving the team member the opportunity to see how it is used and analyzed is a learning opportunity for him/her, and will also give a feeling of being a part of the business. 
I’d really like to hear how your organizations’ have handled data collection at the front-line.  I look forward to hearing about your experiences.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 10 Oct 2006 23:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Bringing Engineers Together]]></title>
			<link>http://blogs.isixsigma.com/archive/bringing_engineers_together.html</link>
			<description><![CDATA[To a black-belt, looking at problems from a SIPOC point of view comes naturally...creating process flow maps, identifying potential inputs, identifying internal and external customers, etc.  These activities are (or should be) core to implementing a given black-belt project.  To an engineer that has not been though six-sigma training, many times these processes are not explicitly followed, but rather the inputs are assumed in some way.  These inputs could be assumed based on experience, process knowledge, or even only by what data is available.  To the integrated black-belt, these assumptions can lead to frustration when interfacing with an engineering problem-solving team.
In order to bring the team together, its important for the integrated black-belt to let his/her leadership get the team past these assumptions.   One way to do this is to challenge the assumptions brought forth by team forcefully, yet eloquently. 
A typical conversation between a product engineer and an IBB (integrated black-belt in manufacturing) may start like this:
Product Engineer: The design allows a +/-1 mm deviation from nominal and currently the widgets are out of tolerance we all know that this is causing the problem with the final widget assemblies.
How the IBB responds to this concern is dependent on the circumstances, however there are two basic ways: immediately defensive or immediately inquisitive.  A defensive reaction in this case almost always builds a wall between team members, and gives the impression that you're not a team player.  However, this reaction is natural, since as an IBB, you immediately question weather or not your product development colleague has considered the pertinent inputs to the problem.
Ive found that the inquisitive approach almost always yields better results.  Your colleague may be absolutely right.  Build a mutual trust with your colleague based on the fact that you will investigate the issue from the process side and give an update at the next meeting.  Before then, perform your analysis if solid data is available using the appropriate tools (tolerance stack-up analysis, ANOVA, etc) to isolate the potential causes and bring those to the table.  If solid data is not available (poor R&amp;R, etc), then bring that fact to the table.  In either case, take the time to illustrate the methods you used to draw the conclusion(s).  This will allow the whole team to learn new methods of root cause identification.
And above all else, if your colleagues statement is correct, then begin activities to improve the process as soon as possible without delay.  This will build even more trust and the beginning of a good working relationship with your colleague.
I'd like to hear about some of your experiences with IBBs and how the interface works with the non-trained population.  Please share your thoughts.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Mon, 09 Oct 2006 16:15:01 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: About Blogger: Kosta Chingas]]></title>
			<link>http://blogs.isixsigma.com/archive/about_blogger_kosta_chingas.html</link>
			<description><![CDATA[Kosta Chingas began his career with Ford Motor Company in production supervision.  In May 2000, he joined the first wave of black-belt candidates at his facility.  He became a certified black-belt by Ford in September, 2001.  In 2002, he joined BorgWarner automotive as press area operations supervisor where he optimized kanban min-max levels and introduced team-leaders into the press area.  In 2003, he returned to Ford and was selected to become the facility master black-belt, coaching the facility black-belts and delivering green-belt training to roughly 200 total hourly employees.  He also co-delivered one of the first waves of manufacturing black-belt training in the Chicago area for regional candidates.
In 2005, Kosta moved on to another OEM auto manufacturer and is responsible for dimensional quality as well as his plant’s Six Sigma implementation.
Kosta obtained a B.S. Mechanical Engineering degree from Northern Illinois University in December, 1999.
Please note that any information provided in the blog is not necessarily the opinion of any company or organization, but is soley the opinion of the blogger.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Blogger Bios]]>
			</category>
			<pubDate>Mon, 09 Oct 2006 16:14:33 -0800</pubDate>
		</item>

	</channel>
</rss>
