We love and hate e-mail. It has great importance in modern business communication. Every day, millions of e-mails are sent from companies to customers and suppliers, from employees to their managers and from one co-worker to another. E-mail is immediate, useful for record keeping- but not ideal, helps with reaching customers, and is relatively low cost.
From an IT point of view, we consider e-mail hosting on-site, using the “cloud” (think internet- based), how our e-mail system complies with our legal record keeping requirements, and when security patches and upgrades are required. IT thinks of e-mail as an existing, “legacy-type” commodity that it buys from commercial vendors and integrates with existing “in-house” systems that manage people records, finance and website communications.
It is easy for IT folks to forget about users and customers with respect to e-mail. After all, what you get in e-mail from vendors, is well – what you get. We tend to not customize our email systems. New features come from email vendors (think Microsoft, Google, IBM) and often take a few years of e-mail customer engagements.
Jeffrey Liker, author of “The Toyota Way,” provides an excellent example of an e-mail implementation and the application of Hansei (Relentless Reflection) and Kaizen (Continuous Improvement) – two foundation concepts behind Lean thinking. The manager of information systems within the Toyota Technical Centre developed a plan to convert the old e-mail system to one with new features. Through a bidding process, a product was purchased and installed. The IT manager sent out e-mail user manuals to all employees and asked each employee to sign a letter that they had received the manual.
One month later, the IT manager received complaints from employees that they did not understand the new functions and that the manual was too difficult to use. Training was provided, but another month later, complaints continued.
What was the real root cause of the e-mail problem?
At Toyota, a five-why analysis is often used as part of a larger process known as “practical problem solving.”
In this case, the surface problem appeared to be the e-mail system and the user manual. As they got deeper and deeper into the problem and asking why, they discovered that the IT manager had not done enough to go directly to the source and studying how people use e-mail and the manual. The IT manager did not develop a deep understanding of the situation (genchi gembutsu – management by walking around) and failed to pilot the process. Digging deeper and asking why again and again, they found that senior management failed to create a culture that supported the Toyota Way with respect to internal processes and change management.
Key takeaways for IT managers – keep asking why until the root cause is determined, see first hand what is happening with customers, and take counter measures at the deepest level of cause that is feasible and that will prevent reoccurrence of the problem.
For learn more, consider registering for our September workshop on Root Cause Analysis.
