Problem Solving Then and Now

“Curmudge, were you involved in problem solving in your earlier life?”

“Lives, Jaded Julie. I had several of them. I was a chemist, and problem solving was what scientists and engineers did. If we weren’t fairly good at it, the men became mill workers and the women home economics teachers.”

“Tell me how you solved problems back in the last century. It sounds as if it were the exclusive purview (purview; did I say that?) of professionals.”

“Like management in those days, problem solving was essentially a seat-of-the-pants endeavor. For problems requiring research, we followed a sequence sort of like this: Define the problem. Learn what was already known by studying the literature, sometimes in a foreign language. Plan the investigation, and then do it. We didn’t know Plan, Do, Check, Act, although we probably did it intuitively. Dr. Deming may have still been in Japan.”

“That sounds difficult, Curmudge, especially the foreign language part. It’s pretty evident why the Toyota Production System had to be developed if they wanted everyone to become a problem solver. On January 25 and 31 we talked about some general aspects of the TPS; perhaps it’s time to tackle the specifics.”

“I agree, Julie. To sum up the two approaches to problem solving, let’s call the old way ‘seat-of-the-pants for scientists and engineers’ and the new way ‘organized common sense, i.e., Lean tools, for the people in gemba.’ The beauty of Lean tools is that everyone can use them.”

“My brain is in gear. When do we start?”

“We already did. On January 18 we used The Five Why’s to identify the root cause of a problem. More recently, on July 10, we introduced 5S, and on August 14 we talked about The Eight Wastes of Health Care. Although the Eight Wastes is not really a tool, it helps guide our thinking. Recall once again, however, that in a blog we can only introduce a concept. Taking a workshop, studying a dedicated text, or working with an experienced person will be necessary before one can rigorously apply a Lean tool.”

“Curmudge, I believe you once said that one of the principles of a Lean transformation is continuous improvement of processes. If we are going to solve problems in processes, we’d better understand the difference between a process and a procedure.”

“Okay, here it is, courtesy of an international standard (ISO 9000) and a seminar at SEH by Lucia Berte on 10/12/06. A process is a sequence of activities involving more than one person (usually) across a span of time. A process description defines who does what in the proper sequence (when). Typically, a process involves several procedures. Thus, the process description, outline, or flow chart is the tie that binds the procedures into a coordinated effort to achieve the desired outcome. A procedure tells how to do something. It is a set of instructions that describe the stepwise actions taken to complete an activity identified in a process. It usually involves just one person. Here is a simple example: Getting up and going to work is a process; brushing one’s teeth is a procedure.”

“The definitions sound reasonable to me, Curmudge. I think the term, ‘procedure,’ is overworked. It is too often used to refer to processes as well as procedures, and we throw in surgical procedures for good measure. Is it really important for us to differentiate between processes and procedures?”

“If people become too absorbed in performing their own procedures, they are apt to acquire a ‘silo’ mentality. In a Lean transformation we need to remove the boundaries between silos and think about how we are going to move patients through processes efficiently.”

“Curmudge, for an old chemist, you’ve covered a lot of ground in two pages. I noticed that you mentioned using a flow chart to describe a process. Does that mean that we’ll talk about value stream mapping sometime soon?”

“Of course, Julie. You can depend on me to be here. After 40 years of getting up and going to work, I’ve hardwired the process.”

Affinity’s Kaizen Curmudgeon