Author: everythingalfotm

13. Understanding the Business Process Architecture

~ everythingalfotm ~ Leave a comment

W. Edward Deming said, “If you can’t describe what you are doing as a process, then you don’t know what you are doing”. The fact of the matter is that process can be described at different levels of detail and organizations struggle with knowing which level is appropriate in a given situation. If we discuss process at too high a level, we fail to have the language that describes the actual work and our focus shifts from the process to the people. If we discuss process in too much detail, we might become too prescriptive and inflexible in the doing of the work. Our task, as process experts, is to develop both the sense and the know-how to navigate between the different levels of resolution that exist for a given process and to discern what level of detail is appropriate to help the business understand its work.

To develop this skill, we first need an awareness of the different levels of detail found in a process. Together, the “nested” levels are what is called “Business Process Architecture” (BPA).  The diagram here comes from Wikipedia (emphasis added) and is a good illustration of a basic BPA. In the rest of this blog, I will point out a few important points for your consideration. 

At the highest level, in this example, we want to “Make Breakfast”.  We can see the inputs needed and the resulting output of the [Making Breakfast] process. However, the description of the work at the highest level is not sufficient for us to actually understand the work. This means the highest-level step might need to be described in more resolution: Prepare Ingredients, Cook Ingredients, Serve Ingredients.

Observe, each of these steps can be further described by even more detailed steps.  For instance, the [Cook Ingredients] step is made up of: Cook bacon, cook eggs, toast bread, fry potatoes. Notice this diagram only expands the [Cook Ingredients] step, yet each of the steps can be explained in more detail. While not depicted here, even the most detailed steps can be further expanded. For example, [Heat Pan] can also be described in more resolution.

Language is important. Notice that all the process steps are actions.  In other words, each begins with a verb. Also notice that at the highest level, inputs are identified, and outputs are described.  An input can be a material or information needed to perform the process and is typically described as a noun. The outputs refer to what is the product of the process.  Said another way, what is the result of performing the process steps on the inputs. Often outputs are described using nouns along with adjectives. This is especially the case when describing knowledge work and/or transactional work.

In this diagram, Inputs/Outputs are described at the highest level.  Indeed, you might recognize some of the elements in a SIPOC diagram depicted here. However, if you take a moment to think of it, inputs and outputs can be identified for each process step at the more detailed description level.  In fact, not all the inputs are needed for every step in the process.  This is important because it is relevant to the process-mapping we do in the organizations we serve. Many times, we apply the SIPOC tool without actually linking the inputs to the point of work where it is actually needed. When we fail to make this linkage at the more granular level, we are left with gaps in our understanding. Inputs and outputs can be identified for each step in the process. In this diagram, for instance, bacon is only needed in the [cook bacon] step, similarly eggs and bread are only needed for those steps.

One last point I’d like to emphasize is, when describing process, we use the term “step” generically. Indeed, we use the term “step” to represent the work at each level of detail. This language can be confusing because the amount of work involved in each step might not be the same depending on the level within the BPA. In my next blog, I will introduce you to the KT process level structure which will give us a common framework and language to describe the process at the different levels of detail necessary to understand the work we do.

Process exists in different levels of detail within the BPA. It is important that we, as process experts, understand this and are equipped with the know-how to help the business work through the detail needed to understand and solve real business problems. Deming was right. In the absence of detailed process understanding we literally do not know what we are doing.

NOTE: For more on Process Design and Development, check out my course on Udemy. https://www.udemy.com/course/process-design-and-development/?referralCode=6D83C27A243FB023A413

12. The Importance of Language in Describing Process

~ everythingalfotm ~ Leave a comment

This blog is adapted from Appendix E in my book on “Process Design & Development”.

I would like to reflect with you on the writing of Dr. J. Mitchell Perry. In his book “The Road to Optimism: Change Your Language…Change Your Life”, Perry points out the importance of language and its effect on how we view and understand situations. Perry encourages using what he calls the “Language of Inclusion” and points out that the practice of positive language is inherent in children. That is to say that children naturally describe what something IS instead of describing what something IS NOT. When applied in the corporate setting, it has a positive effect on culture (1).

The purpose of language is to communicate clearly about thoughts, feelings, behaviors, ideas. Clarity of thought and speech facilitates understanding between actors. Indeed language, Logos if you like, is fundamental to civilization and people who live in community. Language matters.

Language matters also when we describe process. When we narrate the process using language that describes the work as it should be, we are expressing the “normal condition” for the process. The language is in the affirmative. The normal condition is how we expect the process to be when it is executed correctly the first time. Because the normal condition is articulated in the affirmative, it is language that is inclusive of building quality into the work as the work gets done. The normal condition can be about inputs/outputs, the action taken, and the total quality criteria for a given step.

In addition to using the “Language of Inclusion” when we describe our work, it is helpful to also pay attention to grammar. Grammar matters. Below are a few grammar-related guidelines I have found to be helpful when describing process:

  1. Because process actions represent work, the process actions usually begin with verbs
  2. Inputs needed to do the work are usually nouns
  3. Outputs that result from having done the work are usually nouns
  4. Who does the work at a given step is like the subject of a sentence and refers to who is doing the verb
  5. Total quality criteria (TQC) is a description of the output at a given step and is analogous to adjectives and adverbs that provide detail in a sentence

The word choice when describing inputs/outputs, process steps and TQC might need to be in the affirmative. That is to say the language needs to describe the unit as it is or as it should be as opposed to the negative alternatives. For example, if a client’s purchase order (PO) number is needed at a certain step in the process, then the language used at that step might be articulated positively. One way of expressing this positively might be “PO number confirmed in text field” instead of “PO number is not missing in text field”.

The language we use to describe process is important. It is specific and has an effect on our understanding of the work. When we choose to describe the work in the affirmative, that is to say describe what it IS instead of what it is NOT, the language sets an expectation and clarifies precisely what quality looks like as the work gets done.

11. What Actually Changes in the Process when an Organization Restructures?

~ everythingalfotm ~ Leave a comment

If you stay in business long enough, you might actually see the reorganization of a corporation. If you have experienced this type of change then you likely know just how significant is the undertaking. Sometimes this type of change is necessary. When it is necessary, we need to be clear-sighted about what actually changes related to the processes used to deliver value to the customers and within the organization.

Sometimes, as the organization structure changes some individuals move around. That shuffling around of resources introduces a sense of chaos and confusion at the process execution level. Sometimes this confusion leads people to think that the process itself has changed dramatically. Who-Does-What might have changed. What-Gets-Done, the actual work content, has likely stayed the same.

From a process documentation standpoint, the workflows that show which functions or departments do what work content might need to be updated to reflect the new organization design. However, to build those process maps with sufficient resolution to be helpful to the organization, I submit to you that the combination of two common tools might be used together to shed light on “who-does-what”. Then, based on that understanding the process flows can be updated at the action level with an understanding of who is responsible for what and where in the flow are the handoffs placed. Those two tools are the adapted-SIPOC and the RACI.

If your organization has used SIPOC in the past, then you have a detailed understanding of the work content at the action-event-task level of resolution. The level of resolution depends on how detailed you were when creating SIPOC. This variation in resolution is OK. The key is, you have the work content listed in the SIPOC and that becomes the starting point for RACI discussions with the leadership in your organization. Unless the process tools/technology has changed, it is likely that the action-event-tasks needed to fulfill the work are the same. What changes as a result of the organization design is who-does-what. To get a handle on that, the conversations need to be with the leadership.

The leadership, who have likely been a part of the design of the new organization structure, have a clear understanding of what work each department or function is responsible for in the new structure. This knowledge of the organization design needs to be coupled to the actions-events-tasks from the SIPOC diagram. I would suggest keeping the conversation at the “action” level of resolution and add to that elements of RACI. RACI stands for Responsible, Accountable, Consulted, Informed.

To navigate through understanding how the work gets done in the new organization, the process expert (belt or LEAN practitioner) needs to do five things. First, I suggest you develop a matrix in a spreadsheet with the Process Steps or Actions (from SIPOC) listed in a column and across the top include the function and departments (or sub-teams) that reflect the new organization structure. Second, once this matrix is created, then leadership can weigh in on which sub-teams are involved in the doing of each action. I would capture this information in the matrix using an “X” to identify the “who” needs to be a part of doing the work. Third, then I would ask the leadership (likely the Director or Manager level) to shed-light on who is “Responsible”, “Consulted”, “Informed” for each action in the list. I would capture that information by changing the “X” in the matrix to the appropriate letter in RACI (intentionally omitting “Accountable” as it is not helpful here). Fourth, I would ask the resources that actually do the work to validate the level of involvement from RACI. For this, sometimes you need to include resources who did the work in the past as well resources who do the work in the present. This collaborative discussion can enable knowledge transfer about the doing of the work as well a validate the level of involvement for the action in the process. Fifth, based on this combined understanding, the process flows can be updated to reflect who does what the new organization structure and where in the flow are the handoffs placed. The Supplier and Customer information in SIPOC might also need to be updated to reflect the new structure.

Change happens. When it happens, shifting the focus to the process enables clarity and better understanding for all actors involved. Knowing what process tools to use for the situation at hand is key. In this case, SIPOC and RACI come together to help enable the conversations and navigate through the changes related to organization restructuring.

10. Process Standardization, Quality Control AND Quality Assurance

~ everythingalfotm ~ Leave a comment

I did an online search recently on the ideas of “Quality Control” and “Quality Assurance” and I discovered that based on the information found online it seems there is not much difference between the practice of Quality Control and that of Quality Assurance. It seems to me that the terms might be used interchangeably in the Lean Logos today and therefore in the Lean Six Sigma practice. I am writing this blog because the idea that Quality Control and Quality Assurance practices are the same thing is false. The actual work involved in the practice of Quality Control is quite different from the actual work involved in the practice of Quality Assurance. Who does this work is also different and both practices rely on clearly defined process standards. I would like to unpack this idea for you today.

When I read the writings of Shigeo Shingo1 and John R. Costanza2, I found that there is a distinct difference in the work content for the practice of Quality Control and that of Quality Assurance. The work involved is not the same. I also found that each of these esteemed LEAN practitioners described the work content for the two practices yet referred to them by different names. What Costanza refers to as “Quality Control”, Shingo calls “Successive Checks”. What Costanza refers to as “Quality Assurance”, the monitoring of process performance using statistical process control, Shingo calls “Quality Control”. Yet the work involved is quite different. I think this history is important.

As you know, Shingo writes from his experience in the manufacturing environment. Costanza writes from his experience in the manufacturing environment that has a “mixed-model-flow”2. That is to say, that not every unit of work goes through the same sequence of steps in the facility. Yet, the ability to standardize process, to practice quality control in the process, and practice the monitoring of the process using statistical techniques is applicable. This is important for two reasons. Firstly, the technical competencies for the practice of Quality Control is different from that of Quality Assurance. The tools are different. The skills are different. The intentions are different. The second reason this is important is because LEAN has expanded beyond manufacturing. The need for process standards, quality control, and quality assurance exists in the service sector and transactional environments.

So what are the differences between Quality Control and Quality Assurance?

Quality Control happens at the point-of-work within the process flow in the operation. It relies on what Shingo calls “successive checks”. That is to say that the output from step-1 is evaluated for quality at step-2 by the person doing the work at step-2. This “successive check” happens within the flow of the process; it is not outsourced to a different department for formal inspection and quality check. This is how quality gets built into the process in the actual doing of the work. When the unit fails to meet the successive quality check, that is when the Andon gets triggered (1, p.32-35, p.44-48). Now, in his writing Costanza expands on Shingo’s idea of “successive checks”. Where Shingo left the interpretation of what “good” looks like up to the person at Step-2, Costanza clarifies that “Total Quality Control Criteria” (TQC) can be defined for the output at step-1 and then those specific TQC criteria is what constitutes the in-process-control check (IPC) that gets done at the point of work before more value is added to the unit (2, p.155, p.180). This is precisely how quality gets built into the doing of the work at the point of work within the operation.

Conceptually, if that is what makes up Quality Control, then what is the purpose of “Quality Assurance”? Shingo explains in his writing how his understanding of the purpose of “inspection” evolved with the science of statistical sampling and monitoring using statistical process control (SPC). The statistical sampling and monitoring of the process is needed for doing just that: monitoring the process performance. However, the use of control charts and statistical sampling cannot prevent the defect from moving downstream1. At best it can identify the existence of the defect after the fact (1, p.32-35, p.44-48). Costanza elaborates on this further in his writing. The purpose of random sampling and using SPC to monitor process performance is to keep track of process performance, identify areas where improvement might be needed, and adjust the takt-time for steps within the flow that might need to operate at a different pace until the defect problem is solved (2, p.54-58).

From this narrative, you can see the very nature of the practice of Quality Control is quite different from the practice of Quality Assurance. Both practices are needed. Both practices are related to the ability to define process standards for the work that gets done at each step and then build the quality into the process and then monitor the process performance. To be sure, these terms refer to technical practices and are not necessarily the names of organization departments (though some organizations might have departments by these names).

The defining of process standards, the practice of quality control at the point of work, and the practice of quality assurance are each practical and tactical and technical. Knowledge, skill, and competence are key. To learn more about the tools applied in each area, refer to Chapter-1 from my book The Art & Science of Applied Lean for Operations TM: Lean Sigma Practice Beyond Certification and Chapter-3 and Appendix-C from my second book Applied Lean for Operations: Process Design and Development Methodology TM. The Anatomy & Physiology of Process.

References:

  1. Shingo, Shigeo. Fundamentals Principles of Lean Manufacturing. WA: Enna Products Corporation and PCS Inc. English translation 2009
  2. Costanza, John R. The Quantum Leap. In Speed to Market. CO: John Costanza Institute of Technology, Inc. 1996
  3. Constantinescu, Azizeh E. The Art & Science of Applied Lean for Operations TM: Lean Sigma Practice Beyond Certification. The Oakley Press. 2017
  4. Constantinescu, Azizeh E. Applied Lean for Operations: Process Design and Development TM. The Anatomy & Physiology of Process. The Oakley Press. 2020

9. Lead With Lean: Courageous Conversations

~ everythingalfotm ~ Leave a comment

The title of this blog/article is “Lead with Lean: Courageous Conversations” and I write it in light of the unprecedented circumstances we have seen unfold in 2020.  As our organizations and communities seek to understand the experience of its employees and members through courageous conversations, I think that what we know from LEAN practice might be helpful.  I submit to you three points for your consideration.

The first point is related to what LEAN practitioners refer to as “Respect for the Individual”.  In my experience, this pillar of LEAN is often introduced in our organizations as “Respect for People”. Respect for the individual is not the same thing as respect for people. The latter is general while the former is specific. I submit to you that anytime we categorize an individual human being, the mere act of categorizing the individual is in itself disrespectful.  We stop seeing the individual for who he/she is as a being and instead we see the category.  Sometimes organizations, academics, and governments categorize individuals in order to study and understand various situations based in fact.  I do appreciate that effort and recognize that it does have a purpose.  However, I have found that respect for the individual is different from that.

In my experience, respect for the individual plays itself out in every interaction we have with another human being.  Respect for the individual is a recognition that each individual is inherently important and valuable for his/her unique experiences and human perspective.  Respect is given because of the unique spark in each human life.  I have come to understand that respect is given, not earned.  Trust is earned.  Respect is action.  It takes place within human interactions that are face-to-face, behind-the-back, and sometimes even remotely and online.  Respect for the individual is the ability to hear another person’s perspective even if it is different from my own with neither vilifying nor victimizing the other individual.  Respect for each individual is a skill to learn.  It involves practice.  Because it involves practice, it means that each of us is learning and will likely fail along the way.  If we approach these courageous conversations with the spirit and action of respect for each individual then I think we can empathize with and understand one another, learn from one another, and come together to improve the world in which we live.

The second point is related to the “Process Improvement” pillar of LEAN.  The world in which we live is made up of systems and processes.  Like in organizations where we work, when we are not proactive about the design of process, the continuous improvement of process, the monitoring and risk mitigation needed for process, and the operationalizing of process, then waste, chaos and harm creep in.  In the absence of this effort, deep process discussion, and supporting actions, we might easily fall into the trap of blaming, victimizing, and vilifying the individuals in the system.  We know this from our practical experience in business.  I think the same concept might apply to government and crucial community conversations.

Lastly, I would like to point out that with many process improvement efforts in our organizations, we discuss “what might success look like?”  The spirit of this conversation is usually around being able to recognize success if-and-when it presents itself.  As part of courageous conversations within our corporations and communities, when the time is right, it might be important to discuss “what is justice?” and “what might justice look like?”.  It is important to try to put language to this concept and to discern the difference between justice, retribution, and revenge.  Justice by its definition is not the same thing as retribution and revenge.  Admittedly, and based on my experience, when I have been wronged and hurt deeply, the seduction of retribution and revenge might feel like what I imagine justice to be.  This emotion is valid and understandable.  Yet, justice might actually play itself out in ways that is nothing like retribution and revenge.  Like the conversation about “success” in our organizations, can we see and discern justice when it presents itself?  I do not claim to have an answer to this very important question.  I simply think that, when the time is right, it might need to be part of the courageous conversation.

In the spirit of LEAN, I do think that what we know works in business might also be relevant and applicable in enabling the world to become a better place for each and every one of us.  I am interested in hearing your perspective.

NOTE: The thoughts presented here are my own and might not represent the opinion of UL or any other organization with whom I am affiliated.