A Django site.
July 21, 2008

Peter Abilla
no nic
shmula
» Maintain Forward Tension

One principle in Wing Chun is the maintaining of forward tension.  To explain, I’ll draw the distinction between Tension and Energy and show how this principle in Wing Chun can be applied to Change Management.

Tension is a type of Energy

A Wing Chun maxim goes as follows:

soft and relaxed strength will put your opponent in jeopardy

That maxim means that forward tension is not necessarily using force, or forcing through a barrier or “pushing through”.  But, there is soft force, or tension, such that when a gap presents itself, then the hand or arm shoots forward like a spring.  The “shooting forward” is not done with force, but is an unleashing of potential energy.

Using that definition, then, Forward Tension is much different than the overly-used business term “Breakthrough.”  In the context of Forward Tension, the notion of “breakthrough” is ridiculous, because it connotes a forcing of oneself or of one’s ideas.  Forcing anything only invites resistance and rebellion, not conversion.

So, in sum, tension is really potential energy and when a gap presents itself, that potential energy becomes kinetic energy.  Forward Tension works with the current context in such a way that does not invite rebellion or resistance or eventual back-biting.  It is open, but straightforward.

Application to Change Management

Don’t force things on people.  The most humane approach to change management is to treat those involved in the change as human beings; this means having a dialogue — listen, speak, listen some more, argue a little, and steadily deposit goodwill.

As much as I like love data, I also fully understand that data does not soften hearts or change people’s minds: true change happens when people feel heard, have given their opinion, are willing to try something new, and are part of the change.  The challenge in change management is largely an emotional one; a psychological one; a relational one.

Hold The Tension

Without forcing or pushing of people, maintaining the tension encourages discussion, debate, and invites people to inquire and become curious about the topic of change.  That is the key: behave in such a way that it invites people to learn, argue, debate, and eventually try it out.

Tension in Wing Chun

The video below shows Sifu Grados in Chi Sao (Sticky Hands).  This sensitivity exercise demonstrates the principle of holding the tension and visually explains the principle of transformation of potential energy to kinetic energy very well.

NOTE: none of the movements are rehearsed.  What is taught and practiced are the principles and how those principles are applied during Chi Sao depends on the situation.


Articles on Ethnography and Design:

  1. Feature? What Feature?
  2. Simplify The Product
  3. Ask Aza Raskin
  4. Aza Raskin on Poka-Yoke & The Humane Interface
  5. Aza Raskin on Quasimodal Design and The ATM
  6. Aza on Feature-Bloat and Site Clutter
  7. Aza on Google Search Results Page
  8. Aza on Cooperation and Team Size
  9. Design Thinking in Medicine
  10. On Designing a Watering Can for Little Hands
  11. Queueing Theory and Visual Management
  12. An Interview with the Inventor of “Clocky”
  13. Bad Breath but Good Design
  14. What is Ethnography

Articles on Leadership:

  1. Overmanaged and Underled
  2. Colin Powell on Leadership
  3. Team or Staff?
  4. Tipping-Point Leadership
  5. Abraham Lincoln on Leadership
  6. How to transform an Organization: Chime-in Before Buy-in

Articles on Queueing Theory:

Articles on Operations, lean and six sigma:

July 9, 2008

Peter Abilla
no nic
shmula
» Fast Food Congestion

Every system has constraints — sometimes several — minor bottlenecks and major bottlenecks.  What makes managing constraints even more challenging is that bottlenecks move: up-and-down the process paths.

I saw this phenomenon recently during a visit to a fast food restaurant, which I discuss in this post — but, my application of the Theory of Constraints, Lean Manufacturing, and Six Sigma as applied to a Restaurant can be applied to any Dynamic System.

One of the key lessons in The Theory of Constraints is that the contraint or the bottleneck determines the throughput for the entire system.  This means, then, that if we optimize and improve a non-bottleneck, then those efforts have almost zero impact on the overall throughput of the system.  It is only when we improve and optimize the contraint that we will see improvement in the throughput of the entire system.

Every system has a constraint — that is neither good nor bad — but just a fact of dynamic systems.  Once you’ve identified the constraints in your system, then the next step is to manage it.

I was able to obtain some empirical volume data for a Burger King.  The data below is taken from one Burger King restaurant.  I imagine the numbers would be significantly different if we were to average the volume by geography, restaurant size, or by other factors.  Now, consider the following process map for a typical Burger King:

Click on the image for a larger view.

For this restaurant, over the course of an average month, Burger King produces 34227 sandwiches.  This means, then, that for an average hour, Burger King produces 198 sandwiches per hour during normal hours.

But, on Friday and at 12:00PM, Burger King experiences higher-than-normal volume and so we add a “Peak Multiplier” of 18% and 17.9% to arrive at 256 sandwiches during Peak Hours.   The “Peak Multiplier” is not completely arbitrary, but a quasi-educated guess at the volume increase during those hours.  In both cases of Fridays and Lunch Hours, we add a ~20% multiplier.

Now, let’s take a look at the process map above.  We see the Assembly Step producing 200 sandwiches an hour.   We consider the Assembly to be the constraint in the system.  The upstream processes produces more than 200, but when we arrive at the Assembly, the capacity of that step is lower than its upstream processes.  So, the maximum throughput of the entire system above is 200 sandwiches per hour.

Under normal hours, the constraint functions reasonably well.  Since normal hour demand is 198 sandwiches per normal hour, the Assembly Step can produce at least at that amount — but, it’s cutting it close.  Under peak volume, the constraint is not able to fulfill demand. 

How To Manage a Constraint

Under normal hours, it appears that the Assembly Step can produce at expected demand.  But, there are several things that could put burden on the constraint and cause it to producing less than capacity.  Here are some of those items:

  • Rework: Having to Re-Assemble sandwiches adds undue burden on the system and exaggerates the effects of the constraint, leading to a potentially higher-than normal work-in-process, or build-up.
  • Set-up & Changeover: If all the parts aren’t immediately available in the Assembly step, then it could lead the operator to slow down which could lead to build-up and higher-than-normal work-in-process.

It’s easy enough to see that the Assembly Step needs some help.   Here are several things Burger King — or any system with constraints — can do to better manage the natural constraints that are in every system:

  • Eliminate Defects at the Constraint: This means that all waste is eliminated or reduced at the constraint.
  • Have the Quality Steps in Front of Constraint: In support of the first bullet, make sure that the parts entering the Assembly step are free of defects.
  • Support the Constraint: Add labor to the constraint or more lines, if that is prudent.
  • Appropriately use Buffers: Systems with Constraints exhibit a feast/famine phenomena.  To avoid having too much coming into the constraint or too little coming into the constraint, have a buffer of parts large enough that the constraint stays appropriately busy.  Put another way, reduce the variation in front of the constraint as much as is possible.  A Drum-Buffer-Rope system might be appropriate for some systems.
  • Evaluate the overall system: How much of the steps in the system are really value-add to the customer?  What is the process-cycle effeciency of the process?

Conclusion

All systems have constraints.  Identify what they are, quantify the effects, then manage it.  The above Burger King example shows how this can — with some effort — be done.  What are the constraints in your systems?  What can you do to better manage those constraints?

+++++

Articles on Ethnography and Design:

  1. Feature? What Feature?
  2. Simplify The Product
  3. Ask Aza Raskin
  4. Aza Raskin on Poka-Yoke & The Humane Interface
  5. Aza Raskin on Quasimodal Design and The ATM
  6. Aza on Feature-Bloat and Site Clutter
  7. Aza on Google Search Results Page
  8. Aza on Cooperation and Team Size
  9. Design Thinking in Medicine
  10. On Designing a Watering Can for Little Hands
  11. Queueing Theory and Visual Management
  12. An Interview with the Inventor of “Clocky”
  13. Bad Breath but Good Design
  14. What is Ethnography

Articles on Leadership:

  1. Overmanaged and Underled
  2. Colin Powell on Leadership
  3. Team or Staff?
  4. Tipping-Point Leadership
  5. Abraham Lincoln on Leadership
  6. How to transform an Organization: Chime-in Before Buy-in

Please articles on Queueing Theory below:

Articles on Operations, lean and six sigma, please visit the links below:

Advertisement: compnay formation by Jordans

May 27, 2008

Peter Abilla
no nic
shmula
» Reducing Customer Service Contacts

In some organizations, the Customer Service function is largely viewed as a cost center, draining resources of the firm. I maintain that this perspective is what less mature companies support. More mature companies and, subsequently the more successful ones, understand the strategic fit of Customer Service in the overall value chain and it’s functional role in the supply chain.

In what follows, I’ll take a hypothetical iPhone defect case and show how customer service in this example plays a pivotal role in the overall iPhone supply chain — a key player in the overall product value chain.

Strategic Fit of Customer Service in the Supply Chain

In a supply chain network, the Strategic Fit of Customer Service is often the voice-of-the-customer post-release of the service or product. The phrase “start with the customer and work backwards” is really a misnomer. Why? Well, in most products or services, it really starts with the customer and ends with the customer — that is, the customer’s voice is heard at the level of product design and then the voice-of-the-customer is heard at the market monitoring level, post-release of the product or service.

We know — through pretty accurate anecdotal evidence — that the supply chain of the iPhone looks like the following:

From a high-level, we speculate that the following are the material suppliers of the Apple iPhone:

  1. Samsung: The Singapore facility manufactures CPU and Video processing chips.
  2. Infineon: The Singapore facility manufactures Baseband Communications hardware.
  3. Primax Electronics: The Taiwan facility manufactures Digital Camera Modules.
  4. Foxconn International: The Taiwan facility manufactures internal circuitry.
  5. Entery Industrial: The Taiwan facility manufactures connectors.
  6. Cambridge Silicon: The Taiwan facility manufactures bluetooth chipsets.
  7. Umicron Technology: The Taiwan facility manufactures printed circuit boards.
  8. Catcher Technology: The Taiwan facility manufactures stainless metal casings.
  9. Broadcomm: The U.S. based facility builds touch screen controllers.
  10. Marvell: The U.S. based facility builds 802.11 specific parts.
  11. The Apple Shenzhen, China facility assembles the hardware, holds inventory, and handles the pick, pack, and ship steps of the fulfillment process.

If I am correct in any of my research and assertions above, it’s easy to see that if there is any disruption in material flow of any supplier into the Apple Shenzhen, China facility, then production either slows or halts altogether.

We also know that the Austin, Texas Apple Operation is largely where Apple Care physically sits, with another office just outside of Sacramento, California. So, for any contacts into their Call Center, then that is most likely where the contacts will enter (they also have, we understand, outsourcing partners, but Texas Apple Care is the headquarters).

So, more completely, then, the high-level iphone supply chain may represented like this:

Market Monitoring, Defect Data

When a product is released into the market, there can be many channels of market monitoring of the health of the product. In the medical device or pharmaceutical industry, where I once worked, the Market Monitoring phase of the product lifecycle represents a large portion of the product, especially in how it meets regulatory concerns, etc. Marketing and Public Relations also have an especial interest in market monitoring since the voice-of-the-customer post-release can and, usually does, help the firm improve their product or service.

Let us assume the following:

  1. Apple Care (Apple iPhone Customer Service) has a program for collecting product health, post-release, of the product. These can be from inbound contacts to the Apple Customer Service or through blogs or through message boards.
  2. In this program, Apple has a simple and elegant way of making that information actionable, involving collecting data, stratifying of the data, root cause analysis, then practical countermeasures to improve the iPhone through upcoming releases of the product.

iPhone Defect Data

Extending this hypothetical iPhone case, let’s say that Apple Customer Service collects inbound iPhone Defect Data using a very simple check sheet, like the following:

The first column shows very broad defects as reported by the iPhone customers. On the right column are the simple counts. This is called a check sheet. Other variants of this simple quality tool are to collect by day, time, shift, product color, version, etc.

The next step to make this data actionable is to visually render it in a way that points to an healthy area of opprotunity. Below might be a picture that can help us — an iPhone Pareto of Defects:

The above picture is a Pareto Chart, showing the check sheet data, in visual format. As a consumer of this data, the Apple Customer Service folks might want to pay closer attention to the first and second bars of the Pareto, because those two bars represent “iPhone Touch Screen” defects.

The Pareto above naturally leads the consumer of this data to ask “Why?” — “What’s going on with the Apple iPhone Touch Screen?”

The next step, then, in the lifecycle of product monitoring and improvement is to conduct a Root Cause Analysis, focused on areas where the opportunity trade-off is good. In other words, to truly get-to-the-heart of Touch Screen defects, Apple must meet with the suppliers of the iPhone Touch Screen technologies. Based on the Supply Chain network drawn above, Apple should meet with BroadComm, the supplier of the iPhone Touch Screen technologies.

In that meeting, both Apple and the supplier can look over the data, go to the Gemba, and conduct root cause analysis on what’s going on with the Touch Screen.

iPhone Defects Root Cause Analysis

There are several tools that can aid in the process of Root Cause Analysis. Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these names.

ishikawa diagram

Main Components of an Ishikawa Diagram

  1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
  2. The major bones are the capstones, or main groupings of causes.
  3. The minor bones are detailed items under each capstone.
  4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:
  • People
  • Equipment
  • Material
  • Information
  • Methods/Procedures
  • Measurement
  • Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

ishikawa, fishbone, shmula.com

Once the Apple folks and the Apple iPhone Touch Screen supplier arrive at the root causes of the iPhone Touch Screen defects, then the supplier needs to put-in-place countermeasures so that the next shipment of the Touch Screen — perhaps in the next version of the iPhone — won’t have this defect anymore.

In fact, there can be much Public Relations and Marketing campaigns from this effort: Apple can show the public that it has listened the concerns of the market; Apple has done this by fixing the defects that most pains that market, in relation to the iPhone product. There can be much branding from an effort like this.

Conclusion

Customer Service plays a key role in the value chain of a product or service. Some firms view and, consequently behave, as if Customer Service were simply a cost center. These firms miss the point altogether: Customer Service is a major vehicle for hearing and learning about what the market is perceiving and feeling and experiencing from our products or services. This data and information can be made actionable through the strategic and smart utilization of Customer Service.

Disclosure

The data above is only hypothetical. The process above works and, if done strategically and with an eye toward the customer, then Customer Service can be a major player in how our products and services can be improved and how we can shape the signals we send to the market and, consequently, how the market can begin to perceive the firm.

I love Apple, but I don’t own an iPhone. I would love an iPhone and would gladly accept a free iPhone from Apple and/or other free Apple products. Apple can join the other companies that have sent me free stuff here.

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

ShareThis

February 19, 2008

Peter Abilla
no nic
shmula
» 2007 Year-in-Review

I meant to post about site metrics for shmula.com in 2007, but am obviously very late.  In what follows, I’ll summarize the shmula.com blog traffic, reader demographics including gender, household income, and geolocation, feed subscribers, and also other site metric items.

2007 was a good year, though a much slower year in terms of posts written.  I was quite busy with work and family but, all in all, it was a good year for shmula.com in terms of traffic.  Keep in mind, that shmula.com is a personal blog; in other words, I write about stuff that I’m interested in and passionate about.  I don’t claim to be an expert in anything nor do I claim that shmula.com is a blog about anything specific.  In sum, shmula.com will contain content on stuff that I care about. 

2007 Traffic

Compared to 2006 traffic, shmula.com received more unique visitors and more pagevies.  Shmula.com received 172,432 unique visitors and 286,917 pageviews, with an average monthly unique visitor count of 14,369 and 23,876 average monthly pageviews.

Below is a picture of shmula.com monthly visitors and pageviews (also click on chart image on shmula.com):

Below is a year-over-year comparison of 2006 versus 2007:

Geolocation & Traffic Source

Blog traffic was primarily concentrated in North America and the United Kingdom. 

Traffic to shmula.com was primarily from unpaid key words on Google.  This indicates that Shmula.com is indexed well.

Below were the top keywords that brought traffic to shmula.com:

It is clear from the number of occurrences that my Rejection of Google’s Job Offer remains the top visited page on shmula.com, followed by my timeline of acquisitions made by Microsoft, Google, Yahoo, and Amazon.  Shmula.com ranks well also on a number of Lean Manufacturing, Operations, Queueing Theory, and Six Sigma keywords.

Demographics

Based on Quantcast estimated reader demographic data, below are some facts (click here for more details):

  • Gender: 62% Male, 38% Female
  • Household Income: 26% earn $100K+, 30% earn $60K - $100K, 29% earn $30K - $60K
  • Reader Education: 20% of shmula.com readers have a graduate degree; 54% have graduated from college.

More demographic information on Households:

Below is a demographic summary:

Feed Subscribers & Rankings

On average, shmula.com has 1,093 Feed Subscribers.  The most subscribers shmula.com has had is 1,426. 

On Technorati, shmula.com is ranked 60,932 and has an authority of 107.  It has inbound links from The Wall Street Journal, The New York Times, Freakonomics (Fellow U. of Chicago brethren), TechCrunch. Google Blogoscoped, 37Signals,  Marketing Pilgrim, ReadWriteWeb, and numerous other smaller sites.  Shmula.com has 25,330 inbound links using Yahoo’s! Site Explorer Tool.   As of today, shmula.com has a PageRank of 5. 

Plans for 2008

I’ll continue to write about Lean Manufacturing, Six Sigma, Software, Technology, Operations, and business-y stuff.  You’ll see bits of family and everyday observations too, especially on ethnography and product development and industrial engineering and topics about the Customer. 

If you are interested in advertising on shmula.com, please contact me.

Thank you for reading shmula.com; Please let me know how I can better serve your reading consumption needs.

January 23, 2008

Peter Abilla
no nic
shmula
» I’m Nobody Special, But I’m Speaking Anyway

Yes, my face is on the front cover of the brochure (PDF Download).  But, little does the audience know that that picture (I’m the second, from the left, but better viewed in the PDF brochure) was taken while I was sitting on a fake sheep during a family trip to the animal farm at Thanksgiving Point in Utah.  I cropped just my face for submission to the event organizers, but the "real" picture is of me, at the insistence of my kids, sitting on a fake sheep. 

I’m speaking at an event, but I’m not boasting

In the grand scheme of things or in the local minutia of our lives, I’m pretty much nobody.  Gratefully, though, I am somebody in the eyes of my children and my wife.  That is what matters to me.  And, when my head gets big, worldly and prideful, for some unfounded reason or other, I’m reminded by my 1-year old and 9-week old, as I change their dirty diapers, of what is really and truly important in life: it’s certainly not notoriety or money, but that I matter to my children and wife, that I’ve nurtured and build relationships with people, and that I am adding value to the world in my own little way. 

If you are still reading this post, unannoyed and with dry eyes, let me make an announcement and an invitation:

You are cordially invited to a pretty cool Lean Six Sigma Summit (PDF Brochure Download) to be held on April 28 - May 2, 2008.   I’ll be speaking at the event, along with other, much-more distinguished folks, whose names are below:

Richard P. Miller
President and CEO
VIRTUA HEALTH

Lee Cockerell
Former Executive Vice
President of Operations
THE WALT DISNEY WORLD RESORT

Russell W. Ford
President and CEO
PRESTOLITE ELECTRIC INCORPORATED

Craig Long
Vice President, Quality and Six Sigma
MILLIKEN AND COMPANY

Roger Myers
Vice President Process Improvement (GIS)
COMPUTER SCIENCES CORPORATION

Nancy Pratt
Senior Vice President, Clinical Effectiveness
SHARP HEALTHCARE

Michael G. Winston
Managing Director and Chief Leadership Officer
COUNTRYWIDE FINANCIAL

Ellen Domb
Founding Editor
THE TRIZ JOURNAL

Debra Levantrosser
Executive Director, Lean/Supply Chain
JOHNSON & JOHNSON

Pete Abilla
Head of Process Improvement for Customer Service, North America
EBAY

Betsi Harris Ehrlich
Director of Six Sigma and Master Black Belt
TYCO INTERNATIONAL

Adam Hjerpe
Senior Director of Quality, Programme Management
UNITED HEALTH GROUP

Gregory Robertson
Director of Six Sigma
BLACK & VEATCH CORPORATION

Martina Kuhlmeyer
Executive Vice President of Six Sigma
TEXTRON FINANCIAL

Jeff Johnson
Master Black Belt
TEXTRON FINANCIAL

Anthony Orzechowski
Director of R&D Quality Engineering
ABBOTT DIAGNOSTICS

Bruce Bryant
Senior Management Analyst and Lean Six Sigma Master Black Belt
DEFENCE INTELLIGENCE AGENCY

Brian Geschwindt
Managing Master Black Belt
QUEST DIAGNOSTICS

Nathan Guerdet
Operations Manager
WELLS FARGO FINANCIAL

Praveen Gupta
Six Sigma Author & President
ACCELPER CONSULTING

Alex Bellabarba
Head of Process Improvement for Customer Service, Europe
EBAY

James Warner, P.E
Director Industrial Division
MINNESOTA POLLUTION CONTROL AGENCY

Tony Coomer
Vice President of Continuous Improvement
LEAR CORPORATION

Dr Stephen Hoover
Vice President Xerox Research Center
XEROX CORPORATION

Patricia Atkins
Lean Six Sigma Director
SHARP HEALTHCARE

Teresa Hay McMahon
Performance Results Director
STATE OF IOWA DEPARTMENT OF MANAGEMENT

Paul Pfeiffenberger
Master Black Belt and Global Continuous
Improvement Manager
AIR PRODUCTS & CHEMICALS

Steven Lesser
Vice President, Supply Chain North America
ORICA

Mike Shuck
Manufacturing Specialist
CHICAGO MANUFACTURING CENTER

Brent Tadsen
Master Black Belt - Lean
GE RAILCAR

Ronnie Pate
Director of Six Sigma Initiatives, Global Supply Chain
CINTAS CORPORATION

Jerry Bussell
Vice President of Global Operations
MEDTRONIC ENT/NT

Dr Michael O’Connor
Director of Global Lean Deployment and Master Black Belt
UNISYS

Richard Lam
Lean Six Sigma Corporate Deployment Leader
BMO FINANCIAL GROUP

James Wasiloff
Master Black Belt and Lead Deployment Advisor, TACOM Life
Cycle Management Command US ARMY

Srisu Subrahmanyam
Vice President, Continuous Improvement
UNITED AIRLINES

Prof. Deborah J. Nightingale
Director
LEAN ADVANCEMENT
INITIATIVE, LAI

Please come.  It should be a fun event.  There will also be a behind-the-scenes tour of United Airlines and a peek into their Lean Deployment.  I’m really looking forward to that.

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

December 12, 2007

Peter Abilla
no nic
shmula
» Cost of Poor Quality & Poka-Yoke

There is wisdom in the definition of Six Sigma, which is 3.4 defects per one million opportunities (DPMO), allowing for a 1.5 Sigma shift.  But, some companies subscribe to sloganeering such as "Zero Defects".  The "Zero Defects" sloganeering is counterproductive, unhelpful, statistically impossible, and completely cost prohibitive.

Statistically, zero defects means a defect level of infinity sigma, which is not possible.  What most people mean, is an attitude toward process improvement — relentlessly improving the way we do things, the product or service we produce, in order to continually delight the customer.  That is really what people mean.  But, but the "zero defects" sloganeering gets in the way. 

Are All Defects The Same?

The "Zero Defects" movement has an implicit assumption that all defects are equal.  This is not true.  In fact, for most firms and products, defects must be identified and prioritized, and attacked and treated from most important to least important.  For the defects at the bottom of that prioritized list, it might even make sense to move on and not eliminate or reduce those.  The point here is an attitude toward perfection, but fully understanding that perfection is not possible.  The attitude and efforts are valuable and the customer will feel and appreciate it.  Shareholders will benefit, and the firm will be better for it. 

Types of Costs

There are three types of costs that comprise the cost of quality: Appraisal, Preventative, and Failure costs.

Appraisal Costs

The costs in this category includes any and all activities in identifying and assessing for errors or defects in products.  For example, testing is an activity that falls in this category; a department that might fall in this category is the Quality Assurance department — this department’s burden would fall under the Appraisal Costs category.

Preventative Costs

The activities that fall under this cost category are training, and any and all activities the encourage prevention or discourages introduction of defects.  Establishing processes, procedures, and systems prior to the product being built is typically found in this category.  Money spent in this category is money well-spent!

Failure Costs

Failure costs can be both Internal and External.  Internal Failure Costs can be money spent to fix defects caught within the firm.  For a software firm, money spent on fixing bugs caught prior to shipping a product can fall in the internal failure costs category.  For External Failure Costs, these are activities that involve refunds, complaints, call center functions (not outbound sales, but inbound complaints), concessions to the customer for poor service, and warrantees. 

Zero Defects and Costs

I present below what I believe to be the relationship between costs and defects:

On the X-axis, we see the costs category (just use a dollar multiplier for the X tick marks).  On the Y-axis, we see defects, by count.  So, we see that as defects approach zero, costs increases exponentially and hovers asymptotically on the x-axis, and never reaches zero. 

Footnote:  The costs to a firm where there is no effort to identify and reduce errors or defects can also be exponential.  For example, imagine a firm where there was no inspection, appraisal, or prevention of faulty, defective, or harmful medical devices or drugs.  The external failure costs alone could bring the firm to bankruptcy.   I recognize this fact, but wanted to make a point above regarding zero defects. 

Why is the above Graph True?

As defects are identified and eliminated, there will be theoretically few defects.  But, this means that identifying defects will require more effort and will become more and more difficult, thus increasing the costs of this activity, along with the subsequent costs to fix the defects identified: The costs to inspect and test increases as there are fewer and fewer defects.

A Caveat & Poka-Yoke

As defects are reduced, the Appraisal cost increase — that is, the cost to detect a defect grows.  There is a trade-off.  One very effective way is to implement Poka-Yoke: to mistake-proof our processes and prevent service or product defects all-together.

Conclusion

Sloganeering doesn’t help, especially if the slogan makes no sense.  "Zero Defects" as a mantra has a nice cumbaya ring to it, but doesn’t really help or motivate a crew to do better.  Moreover, "Zero Defects" is statistically impossible as well as cost prohibitive. 

Regarding defects: not all defects are equal.  It is important to identify the defects that impact the customer, prioritize those, then respond in a prudent way in improving the product or process.  Going after all defects is not prudent. 

The key takeaway here is the following: strive to be better everyday; strive to make the customer happy.  The Firm’s efforts to make the customer happy will be felt, a culture of improvement will be created, and the firm and shareholders will benefit from it.

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

November 18, 2007

Peter Abilla
no nic
shmula
» Bottlenecks and Fast Food

One of the key lessons in The Theory of Constraints is that the contraint or the bottleneck determines the throughput for the entire system.  This means, then, that if we optimize and improve a non-bottleneck, then those efforts have almost zero impact on the overall throughput of the system.  It is only when we improve and optimize the contraint that we will see improvement in the throughput of the entire system.  Every system has a constraint — that is neither good nor bad — but just a fact of dynamic systems.  Once you’ve identified the constraints in your system, then the next step is to manage it.

I was able to obtain some empirical volume data for a Burger King.  The data below is taken from one Burger King restaurant.  I imagine the numbers would be significantly different if we were to average the volume by geography, restaurant size, or by other factors.  Now, consider the following process map for a typical Burger King:

Over the course of an average month, Burger King produces 34227 sandwiches.  This means, then, that for an average hour, Burger King produces 198 sandwiches per hour during normal hours.  But, on Friday and at 12:00PM, Burger King experiences higher-than-normal volume and so we add a "Peak Multiplier" of 18% and 17.9% to arrive at 256 sandwiches during Peak Hours.   The "Peak Multiplier" is not completely arbitrary, but a quasi-educated guess at the volume increase during those hours.  In both cases of Fridays and Lunch Hours, we add a ~20% multiplier.

Now, let’s take a look at the process map.  We see the Assembly Step producing 200 sandwiches an hour.   We consider the Assembly to be the constraint in the system.  The upstream processes produces more than 200, but when we arrive at the Assembly, the capacity of that step is lower than its upstream processes.  So, the maximum throughput of the entire system above is 200 sandwiches per hour.  

Under normal hours, the constraint functions reasonably well.  Since normal hour demand is 198 sandwiches per normal hour, the Assembly Step can produce at least at that amount — but, it’s cutting it close.  Under peak volume, the constraint is not able to fulfill demand. 

How To Manage a Constraint

Under normal hours, it appears that the Assembly Step can produce at expected demand.  But, there are several things that could put burden on the constraint and cause it to producing less than capacity.  Here are some of those items:

  • Rework: Having to Re-Assemble sandwiches adds undue burden on the system and exaggerates the effects of the constraint, leading to a potentially higher-than normal work-in-process, or build-up.
  • Set-up & Changeover: If all the parts aren’t immediately available in the Assembly step, then it could lead the operator to slow down which could lead to build-up and higher-than-normal work-in-process.

It’s easy enough to see that the Assembly Step needs some help.   Here are several things Burger King — or any system with constraints — can do to better manage the natural constraints that are in every system:

  • Eliminate Defects at the Constraint: This means that all waste is eliminated or reduced at the constraint.
  • Have the Quality Steps in Front of Constraint: In support of the first bullet, make sure that the parts entering the Assembly step are free of defects.
  • Support the Constraint: Add labor to the constraint or more lines, if that is prudent. 
  • Appropriately use Buffers: Systems with Constraints exhibit a feast/famine phenomena.  To avoid having too much coming into the constraint or too little coming into the constraint, have a buffer of parts large enough that the constraint stays appropriately busy.  Put another way, reduce the variation in front of the constraint as much as is possible.  A Drum-Buffer-Rope system might be appropriate for some systems.
  • Evaluate the overall system: How much of the steps in the system are really value-add to the customer?  What is the process-cycle effeciency of the process?

Conclusion

All systems have constraints.  Identify what they are, quantify the effects, then manage it.  The above Burger King example shows how this can easily be done.  What are the constraints in your systems?  What can you do to better manage those constraints?

+++++

Please find originally-written articles on Queueing Theory below:

For a few articles on Operations, lean and six sigma, please visit the links below:

October 19, 2007

Peter Abilla
no nic
shmula
» Hacking at Branches or Striking at the Root?

Henry David Thoreau said "There are a thousand hacking at the branches of evil for every one striking at the root."  His statement was a commentary on the human condition but, I believe, describes quite well the state of most companies: companies launch initiatives that don’t actually attack root causes of business problems, instead their aim is on the branches — we need to pay Taiichi Ohno’s 5-Why’s a visit and remember that surgically attacking statistically validated root causes is the only way to solve problems, improve the customer experience, and improve the enterprise.

Taiichi Ohno is known to have said that "having no problems is the biggest problem of all."  He viewed problems not as a negative but as a "Kaizen opportunity in disguise."  Whenever problems arose, he encouraged his staff to investigate the problem at the source and to as "ask ‘why’ five times about every matter (src)."

In a series of events, where people are involved, mistakes happen.  Functional areas such software engineering, industrial engineering or more general areas such as medicine, law, or sociology — these areas are composed by a series of events, involving people, process, machines, environment, and other items.  Undoubtedly, mistakes will happen. What typically happens in response to mistakes is that blame is thrown around, which builds resistance, then communication fails which could lead to project failure. The better approach is to identify the root causes of mistakes and attacking that, instead of what might be perceived as the cause: Perceived causes are most likely symptoms and not the root cause, in which case the problem was never really solved. This, more rigorous and long-lasting, approach to solving problems is called Root Cause Analysis.

Ohno was fond of using the following example to illustrate Root Cause Analysis:

1. "Why did the robot stop?"
The circuit has overloaded, causing a fuse to blow.
2. "Why is the circuit overloaded?"
There was insufficient lubrication on the bearings, so they locked up.
3. "Why was there insufficient lubrication on the bearings?"
The oil pump on the robot is not circulating sufficient oil.
4. "Why is the pump not circulating sufficient oil?"
The pump intake is clogged with metal shavings.
5. "Why is the intake clogged with metal shavings?"
Because there is no filter on the pump.

There are several tools that can aid in the process of Root Cause Analysis.  Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these.

ishikawa diagram

Main Components of an Ishikawa Diagram

  1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
  2. The major bones are the capstones, or main groupings of causes.
  3. The minor bones are detailed items under each capstone.
  4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:
  • People
  • Equipment
  • Material
  • Information
  • Methods/Procedures
  • Measurement
  • Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

ishikawa, fishbone, shmula.com

A Few Helpful Hints

  1. It is helpful to pull many people into the construction of these diagrams, as this ensures enough diversity of thought to make sure you get the righ potential root causes.
  2. Keep asking “why” until you arrive at something atomic and actionable.
  3. The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
  4. Getting more people involved will give them a sense of ownership — and that sense of ownership is very important because now that they feel part of the process, resistance to change will likely be less of a problem.

Real-World Example of Root Cause Analysis

I once helped a large healthcare organization save several million dollars. This organization had the largest call center in California, handling over 8 million calls per year. These were mostly inbound calls, resulting from some internal mistake that caused people to call. My job was to identify the largest opportunity (call type), why are people calling, and eliminating or reducing the root causes.

After pulling log file data and running this enormous data set against my handy-dandy, home-grown regular expression engine (written in Python), we stratified the data into logical stratifications and identified that the largest number of calls into the call center were calls related to a specific product. This discovery naturally begs the question “why” — i.e., this question forms the head of our fishbone: “Why are x% of calls related to x product type?”

We got a cross-functional team together and proceeded with the Ishikawa excercise and identified several root causes. After running the root causes against a prioritization matrix, we went after the low hanging fruit, then the more difficult root causes after that. The result? We demonstrated a quantifiable reduction of inbound calls of this specific type — a reduction of ~8%, which amounted to over $2 Million Dollars in cost savings.

Facts Versus Data

Ohno seems to see a difference in the two.  In his words,

"The root cause of any problem is the key to a lasting solution," Ohno used to say.  He constantly emphasized the importance of genchi genbutsu, or ‘going to the source,’ and clarifying the problem with one’s own eyes. "‘Data’ is of course important in manufacturing," he often remarked, "but I place greatest emphasis on ‘facts.’"

I believe what he means is that data, is a degree removed from the actual place where the phenomena is happening.  He placed a greater value on being where the work is done and where value is added.  Whereas data is often on a computer screen or on paper.  He preferred to be at the source of the phenomena.

More Fish To Go Around

Root Cause Analysis can be used anywhere. In software engineering, it can be used to identify the root causes of bugs in code; in industrial engineering, root cause analysis can be used to identify defects in design; in medicine, root cause analysis can be used to arrive at the reasons for mistakes or lack of patient satisfaction.

Root Cause Analysis is a helpful business tool with application to all areas of business and technology. Eliminating or reducing the root cause is much more effective than fixing a symptom. Involving people in the process will ensure buy-in and the elimination of resistance.

Creating an Improvement Culture

Ohno believed that by empowering each associate to have ownership and improve their work and the Gemba, that is how innovation is achieved and a culture of improvement is created — it is empowering your people to make the right changes using the tools that work — Root Cause Analysis is one of the tools that can help empower your employees and help to create a culture of improvement throughout your enterprise.  One item missed by most people is that Toyota doesn’t just build cars, but it also builds people.  Root Cause Analysis is an effective tool that helps associates feel empowered to make their everyday work better. 

+++++

For articles on queueing theory, time-traps, operations, lean and six sigma, please visit the links below: