To differentiate a Lean-Technical blog from a Lean-Leadership blog, I will name blogs about leadership with “Lead with Lean”.

As I reflect on current events and the state of our nation, I can not help but wonder if there might be a place in government for what Lean Leaders know is the practice of Servant Leadership.

We know in Lean that the voice of the customer (VOC) is of utmost importance.  Organizations that proactively seek to understand the VOC and then develop product/service to meet the need of the customer and then develop the technical competency of the employee population to deliver delightful service to the customer, remain relevant overtime.  We know this practice works in the marketplace.  As business leaders, we know it.

What about with government and elected officials?

Once in office, don’t the politicians need to seek to understand the voice of the constituents on practical and tactical matters (not just high level political ideology) so that he/she might actually represent the people in the work of government?

My observation is:  As an adult, I have lived in seven states across our great nation.  In each state, I observed candidates for public office “go to the gemba” so to speak.  The candidates campaign, go door to door, meet-n-greet at the grocery store, hand out fliers all aimed to convince me as a constituent to vote for them.  Once in office, however, those same individuals no longer seek out my voice as a constituent.  Once in power, they no longer go to the gemba to seek to understand the needs of the people that they represent.  It is up to the constituent to seek out the elected official to make his voice be heard and understood.  In my adult experience, I have observed only one elected official, who happened to be at the national level, consistently seek out the voice of the constituent over the course of his tenure.  Regardless of political views, there seems to me to be a gap in the practice of the elected officials in seeking out the voice of the constituent.  The lack of this proactive practice seems backwards to me, especially in today’s day and age with the reach and accessibility of technology.

In business, we would recognize the lack of practice as complacency and if we were hired to lead and transform a corporation we would be proactive in seeking out the voice of the customer.  We would be proactive in understanding the stakeholder landscape holistically.  We would be proactive about designing systems that enable value to be delivered consistently to the customer.  We would be proactive about being good stewards towards our customers, employees, and communities.  To deliver value, we would need to collaborate across the organization with appreciation for our different experiences and perspectives.  We would be respectful of one another.

I simply think that what we know works in business might also be relevant in government.  The electoral college was designed to represent the constituent on practical and tactical matters that impacts American lives in the communities in which we live.  It is not only philosophy or ideology.  Without the voice of the constituent proactively being heard and sought out on a regular cadence, how do the actions taken on the Hill actually represent the will and need of the people in the community “gemba”?

Might the voice of the constituent matter not only at the polls but more importantly after the polls?

 

I was asked recently if I know of a one-page write up on the use of SIPOC and specifically how-to lead a team through its application.  I have in mind to share with you a slide and its corresponding narrative that I used at the ASQ Chicago Section Continuing Professional Development Seminar delivered on August 14, 2019.  The name of that talk was “The Paradox of Process Standardization”.

We looked at some of the tools that might enable process standardization dialogue within our organizations.  SIPOC was one of those tools.   You know SIPOC.  It stands for:  Suppliers-Inputs-Process Steps-Outputs-Customers.

When it comes to process description and process understanding, SIPOC is your friend.  However, when filling out a SIPOC diagram, I have found that it is not so easy to-do when you begin with Suppliers.  As a belt practitioner, your team will look to you to lead them through a thought-process that results in SIPOC being filled in as a reflection of the teams’ understanding of the process.  The process your team is mapping is in itself dynamic and so is our understanding of it.  SIPOC helps us fill in the details that are “rich” like the nutrients in an apple.  Like the dynamic process itself, the thought-process I have found to be helpful in filling out SIPOC is also dynamic.

Let’s take a look at the diagram below as our focal point for the rest of this blog.  You might notice a couple of details.  Firstly, this template is a basic spreadsheet.  Secondly, the example I am using here is a simple one.  We are making a sandwich because it is easy to follow.  Thirdly, you might notice I have more than five columns in the spreadsheet.  I will explain these adaptations to SIPOC in a moment.

To think through SIPOC, begin with describing the Process Steps.  The process steps refers to actions or activities that are taken in order to “Make a Sandwich”.  List these actions in sequence to the best of your knowledge.  Use verbs.  Process steps are actions.  Be concise, precise, and complete to the extent that you can.

Then, for each process action, answer the question “what inputs are needed in order take this action or to-do this work?”.  Inputs can be material or information or both.  Inputs are usually described as nouns.  The answer to this question goes in the INPUTS column.

Next, for each input answer the question “From where does this input come?”.  The answer to this question goes in the SUPPLIER column.  If you look closely at the  example above,  you will see that we are looking for inputs that are found in a kitchen, but think of your organizations.  A supplier might be external to the organization, it might be a department or technical function within the organization, it might be physical location, or a website, or an IT system.

Now, that you have thought through (and hopefully documented) the first half of SIPOC, return your mind’s eye to the [Process Steps] column.  From there, for each action taken answer the question “What output(s) result from having taken this action?”  Like inputs, outputs can be materials or information or even forms.  Sometimes there might be more than one output that results from taking the actions in a step; sometimes an output that results might become an input to the next step and sometimes an output that results upstream might be an input to an action several steps downstream.  This is important to understand and to work through in your discussions with your teammates.

After identifying the outputs, then answer the question “What is critical to quality about the output(s) at this step?”  This is important.  It is an adaptation to SIPOC.  I will refer to what John R. Costanza calls “Total Quality Control Criteria” which is captured in the sequence of events tool (1).  I have found in my practice that is helpful to include this very rich description in the SIPOC tool and practice this regularly.  To answer the question “what is critical to quality about the output(s) at this step?” you might wish to think about the following:  if this attribute is NOT done right the first time, then the transaction/process stalls OR poor quality moves downstream.  Describe the attribute(s) that is critical to quality; then, write it down in the TQC column.  There might be more than one attribute about the output that is critical to quality.

Now, returning your mind’s eye to the output column, answer the question “Who gets this output downstream?”  Put the answer into the Customer column.  Sometimes it is helpful to identify if there is a critical interaction point between functions or departments or experts at a given step.  the “Customer” column can be used to do that if it makes sense to do so for your process.

Lastly, notice that in the diagram above I have included two additional columns.  The first is for the L0 process bucket or ‘high level’ phase in the business process architecture (BPA).  The second refers to an alpha-numeric numbering scheme (ID) for the process steps in the SIPOC.  The SIPOC process steps are describing the L1 level of detail within the BPA.  This is important because process exists within a business process architecture and so the level of detail that we discuss and map might vary depending on what we are trying to understand.

In closing, I have found the adapted SIPOC to be extremely useful both practically and tactically to enable very rich process understanding.  SIPOC is rich in detail like an apple is rich in nutrients.  W. Edward Deming said “if you can’t understand what you are doing in terms of process, then you don’t know what you are doing (2)”.  The adapted SIPOC enables us to understand the work in a very rich and meaningful way.

NOTE:  I use SIPOC to understand and document process as a foundational process tool.  Once we have that level of understanding about the process, we might depict the process using other tools that might be more effective in letting folks know what they need-to-know and what they need-to-do.  For more on that, refer to Chapter 2 called “Fundamentals of Process Understanding and Development” in a book called “The Art & Science of Applied Lean for Operations.  Lean Sigma Practice Beyond Certification”.

Blog-7 References:

(1) Costanza, John R. The Quantum Leap. In Speed to Market. CO: John Costanza Institute of Technology, Inc. 1996

(2) https://www.goodreads.com/author/quotes/310261.W_Edwards_Deming

My observation is that in the transaction-based service sector,  people are not really used to describing the process in terms of the work that gets done.  When asked to describe the process, I typically hear a description of the work routing from the IT Tool and the phase or status of transactions (such as active or inactive or on-hold).  My observation is the actual mechanics of what gets done is missing from the lexicon.  With a little bit of probing, people begin to describe the actual work.  This distinction is important.

W. Edward Deming said “if you can’t describe what you are doing in terms of process then you don’t know what you are doing”.   While work-routing is important, it is not enough to actually standardize process at the point of work.  Process standardization is actually based on four basic elements that make up the anatomy of process.  Those elements are:

1. Work Content
2. Inputs/Outputs
3. Work Content Time
4. Total Quality Control Criteria

The term “work content” refers to the actual work that gets done in each step of the process.  The work content itself is made up of the actions that are taken; it is the steps involved with doing the work.  It contains value-add, business value-add and even actions that might be considered waste.  The key here is to define the actual work that gets done at the step.  Since the work content describes work, it is action-based and it is usually articulated using verbs.

The second element that we need to understand in order to standardize process is related to the inputs and outputs.  What inputs are needed to-do each step of the process?   An input can be a material or information.  Inputs are usually nouns.

Similarly, we need to be able to describe the output that gets generated.  What output or outputs result from having taken those actions described in the work content?  Further, there might be more than one output generated at a given step; not all the outputs generated upstream move to the next step downstream.  Sometimes an output generated upstream might not be used until well downstream in the process.  Like inputs, outputs are usually described as nouns.

The third element that we need to understand in order to standardize process is related to time.  As you know, time is very important in the practice of LEAN.  So it is no surprise that we need to understand the time it takes to do the work described in the work content.  This is called the work content time.  Sometimes this is called the touch time.  Sometimes it is called the effective processing time.  It includes the time for value-add, business-value-add, and non-value add work.

The fourth basic element that we need to understand in order to standardize process is what John R. Costanza calls Total Quality Control Criteria (TQC). Sometimes in practice this is referred to as critical to quality criteria.  What is critical to quality about the output that is generated at a given step?  It is a question that needs to be answered.  Sometimes TQC might be related to inputs also.  Critical to quality criteria need to be defined.

These four elements make up the basic anatomy of the process.  In order to standardize process, we need to understand these basic elements.  The savvy LSS practitioner will recognize that some of these elements are found in the SIPOC diagram, in the Sequence of Events diagram, and even in the Operating Method Sheet.  Which tool to use to capture the basic anatomy of the process depends on what you are trying to do.

For now, let us simply introduce the basic building blocks to understanding the anatomy of the process.  It is on these building blocks that process can be standardized at the point of work.

Blog-6 References & Recommended Reading:

Costanza, John R. The Quantum Leap. In Speed to Market.  CO: John Costanza Institute of Technology, Inc. 1996

As a LSS practitioner, it is important to understand the concept of Process Standardization (the what and the how).  What is process standardization?  Not only does the LSS practitioner need to understand what is process standardization in the affirmative, we also need to understand what process standardization is not?  In this blog post, I will address the latter topic first.  In future blogs, I will move on to describe process standardization in the affirmative.

My observation is, the concept of process standardization is really not clear in many organizations (even organizations that have been on a quality journey for quite some time).  While the jargon is there, clarity on what that means  on a practical and tactical level is missing.   Further, the concept of “process standardization” means different things to different people.  In industry, I have seen the following be used to answer the question “what is process standardization?”:

• Use of the same workflow tool(s)
• The same workflow through the organization for each transaction
• Verifying resources performing a task are doing that task exactly the same way
• Standard Operating Procedure (SOP)
• Leadership Standard Work procedure
• Standard behaviors

In organizations where the above is what is meant by “process standardization”, when interacting with employees inquiring about the process, I get a description of the phases of the process that are defined by the workflow tool.  The people describe phases and stages and status (such as “On Hold” or “Inactive”) but they do not describe the actual activities or work that needs to be done in that phase or at that step.   They do not describe inputs needed to do the work nor do they describe the output that results from having done the work.  The description of the work itself is missing from the lexicon. 

In the name of process standardization, I have seen people debate who is doing the work “right” and who is doing the work “wrong” at a given step.  The intent of this type of dialogue is not the training and practical application needed to develop competency in a given skill to be applied at a step in the process.  The intent is usually to claim fame as the best way to do something and everyone else is wrong.  Again, I have seen organizations attempt to shift from standardizing tools to standardizing behaviors.  Unintentionally, sometimes behavior standardization seeks to eliminate any individuality among employees because the focus is on personality traits instead of the actions needed and the competency to do the work.

Another failed approach to standardizing process that I have seen is to remove creativity and thought in the actual doing of the work.  The thought here is that every person doing the job needs to do it exactly the same way.  We actually teach measurement system analysis tools in LSS training to be able to discern if the variation in measurement is due to the part or to the measurement system (which includes the man).  While these tools have a purpose, process standardization is not that purpose.  Further, trying to standardize how individuals do a particular activity or task leaves little room for experimenting and actually developing best practice.  It fosters rigidity and compliance as opposed to agility, innovation, and continuous improvement.

If we take a moment to reflect on these examples, we discern that while being done in the name of process standardization,  these attempts are more about the people doing the work than about the process itself.  Further, none of these examples is about understanding the work content nor building competency in the execution of that work content.  I submit to you that some of the examples listed above are examples of what process standardization is not.  

To be sure, organizations that try to standardize in the manners listed above are not doomed.  I believe it is a natural evolution in the maturity of the organization as it pertains to the process lifecycle and applied LEAN for operations.  If you see this where you work, do not despair.  The organization might need to go through these learning pains as it evolves in maturity.  As the LSS practitioner, however, your understanding of what might need to be discussed needs to be clear so that you can enable the organization when it is ready for the work involved in truly standardizing the process.  

Stay tuned for my next blog on: The Anatomy of Process Standardization

 

 

In business, the Product Development Cycle and the Employee Lifecycle are common terms and concepts in the business lexicon.  What about the concept of the Process Lifecycle?

Such a concept is not commonly discussed among quality circles, traditional LEAN practitioners, nor Six Sigma advocates.  The fact of the matter is most Lean Six Sigma Belt practitioners join a company and improve existing process.  In fact, employees can experience their own employee lifecycle inside a company practicing continuous improvement on processes that have been in place for years (maybe even decades) without giving much thought to the Process Lifecycle itself.

I have given some thought to this topic.  The diagram below is my understanding of what I call the Process Lifecycle.  Like a product or an employee, the process itself has a lifecycle.

The Process Lifecycle begins with process design.  Process Design might be triggered by a new service/product offering or it might be triggered by improvements in the technology used to deliver existing service/product.  Either way, the process itself gets designed.  Once the process is designed, then it must be developed.  Once the process is developed it gets put into operations; it is scaled for operations and deployed to the various locations where it might need to operate.  Then the process itself gets managed as service/product moves through it.  The same process is then studied and improved continuously.  Though not depicted here, process itself can also retire.

The Lean Practitioner knows that the process tools in the Lean toolbox can be used at different points in the process lifecycle to develop sound process understanding and enable excellent performance.  I refer to this as Process Design and Development Methodology (TM) and will speak to it in future blog posts.