So I was working the eBay scene yesterday with the goal of a new phone, and I quickly remembered how much it sucks to try and track multiple bids, and time those last second bids. It surprised me that eBay.com still lacked any real Ajax (Live countdowns anyone?) anyways the long of the short is that I eventually stumbled across eBay Desktop Beta, one of the front runners utilizing adobe's new desktop runtime based on flash. Given Adobe's track record of promising Linux implementations, then half-delivering years later, I was about to just give up. On a whim I decided to give wine a shot at this, not only did AIR install painlessly, but the app was functionally complete, and only minor display issues (Ironically, these all seemed to be the WebKit components, all the html rendered by AIR was ugly and oddly formed).
Either way, I got my phone, and have already fallen in love with the application for all my ebay purchases, but whats more, wine is just really impressing me. With the new Mono integration pending, I think we can start to make a truely astounding claim... Linux supports Windows XP elements at least as well as Vista, if not better! ;)
Ok, so the above is a little exaggerated, but still, for that once in a blue moon when I stumble accross things like this (niche Windows apps) I really have a near-complete solution. I was thoroughly impressed.
So I was working the ebay scene yesterday with the goal of a new phone, and I quickly remembered how much it sucks to try and track multiple bids, and time those last second bids. It surprised me that ebay.com still lacked any real Ajax (Live countdowns anyone?) anyways the long of the short is that I eventually stumbled accross Ebay Desktop Beta, one of the frontrunners utilizing adobe's new desktop runtime based on flash.
A few months ago, I went to Dublin and Berlin for work. I loved the trip — it was so good to see co-workers, that have become dear friends, in-person. During my trip, I took a few pictures that I wish to share. Sadly, however, I wasn’t able to take any pictures while I was in Dublin, but the people there and the atmosphere was great. I loved Dublin, Ireland and am so sad to not have pictures to share. So, what I can share are just a few pictures from my visit in Berlin, Germany.
First, the food in Germany was amazing, fancy, and very affordable. One night, we ate at a restaurant in the Sony Center and here is what I ordered — roast, potato dumplings, and sauerkraut:
My dear friend and co-worker and I drove around in his Marcedes Smart Car. I loved riding around town in this little car. These cars are so small that you don’t have to parallel park — you can just drive these in the spot horizontally and it will fit! Seriously, living in Utah and driving next to huge gas guzzlers and environmentally unfriendly vehicles everywhere, it was refreshing to see a beautifully designed and eco-friendly automobile:
While driving in the center of town, we saw this — everywhere in the world, there is a Burger King!
Here is where the Wall used to be, which is now memorialized by a brick lining:
Here’s the Brandenburg Gate at night:
Here is a memorial to remember those that died swimming across the canal from East Berlin to West Berlin. This was very humbling and solemn –
It was a great trip to both Dublin and Berlin. My co-workers and friends were so nice and accommodating and I thank them sincerely for everything.
+++++
Articles on Queueing Theory
- Queueing Theory: Part 1
- Queueing Theory: Part 2
- Queueing Theory: Part 3
- Queueing Theory: Part 4
- What is Waste?
- On Time-Traps and Waste
- Call Centers as Queueing Systems
- Travel Time & Waste
- Little’s Law for Product Development
- YouTube’s Queueing Properties
- Psychology of Queueing and Disneyland
- Queueing, Disneyland, and FastPass
- Multi-Tasking Leads to Lower Productivity
- Queueing Theory and Terrorism
- On Queueing Theory and Elevator Mirrors
- Queueing Psychology at the Gas Pump
+++++
For articles on queueing theory, time-traps, operations, lean and six sigma, please visit the links below:
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.
Main Components of an Ishikawa Diagram
- At the head of the Fishbone is the defect or effect, stated in the form of a question.
- The major bones are the capstones, or main groupings of causes.
- The minor bones are detailed items under each capstone.
- 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:
A Few Helpful Hints
- 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.
- Keep asking “why” until you arrive at something atomic and actionable.
- The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
- 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: