Is it a Cake or is it Clean? (A Litmus Test for Process)

Kathy A.  Long
Kathy A. Long Global Upstream Process Architect, Shell Oil Read Author Bio || Read All Articles by Kathy A. Long

Do you really know your processes?

Do you have difficulty articulating them in ways that people understand?

Process delivers value in an organization.  Until an organization understands process, it cannot manage the value delivery to its customers or the quality of that delivery.  Organizations in the service sector have far greater difficulty in defining and managing process.  This is caused by a concept called 'tangibility'.  Manufacturing has it, but service doesn't.  For example, if asked to define the "Make Product" (bake cake) process most people could describe the process with a fairly clear understanding.  However, if asked to define "Provide Product Support" (clean kitchen) or any other type of "service," most people would struggle to describe in any definitive manner what that process looks like.  The first one has a very well-defined product as well as a very well-defined beginning and end.  However, the second is somewhat difficult from the beginning. For example, when do you start?  And when is it finished?  The concept of 'clean' can be very different for different people.  Remember the odd couple, Oscar and Felix?  For one, clean meant that you could walk through the room without tripping over anything large.  For the other, clean meant that everything was put in its pre-defined place and every surface sterilized.  The fact that one process represents something tangible, a cake, and the other represents something intangible, clean, is the dilemma faced by service organizations trying to manage intangible services.

The dilemma faced by the service sector is that it's much easier to think about and work on the activities that comprise the process, rather than trying to define the overall process.  The danger in this approach is that improvement of activities will often sub-optimize the overall process.

In order to overcome this dilemma it's necessary to develop a set of characteristics that can be used as criteria for distinguishing between process and activity.  There are seven characteristics that can help identify and define process.  The purpose of these characteristics is to provide a litmus test for distinguishing between process and activity.  The seven characteristics are listed in the table below.

Characteristics
 

Process

Activity

1.

What — High Level

How — Detail — Competitive Advantage

2.

Cross-Functional

Functional/Departmental — 1-2

3.

Same Stakeholder — start to end

Different Stakeholder — possibly

4.

Predictable/Repeatable

Exceptions — different paths

5.

Value-Add

??? Value

6.

Multiple Capabilities

Roles / Job Related

7.

IGOEs — complete

Always- Guides/Enablers (Input/Output?)

What — High Level

First, a process is a set of activities that describes, in a typically conceptual manner, "what" happens in the organization.  The conceptual aspect of describing process is one of the major reasons it's possible to use "process frameworks" as a starting point when defining the processes of an organization.  The detail of the activities represents more of the potential competitive advantage of a company.

Cross-Functional

Second, processes are cross-functional in the sense that the activities within a process will occur in multiple silos/functions/departments within an organization.  For this reason, it's frequently useful to create what are called swimlane diagrams showing the flow of the activities.  Each lane would represent a different silo or function in the organization.  The exception would, of course, be if those silos are process silos.  Figure 1 is an example of the swimlane concept, with each of the rows representing different areas in the organization, such as:  finance, sales, and accounting.

Figure 1.  An Example of the Swimlane Concept  

Same Stakeholder — End to End

Third, processes most commonly have the same stakeholder/stakeholder group at the beginning and end of a process — for example, from the point that a stakeholder recognizes a need, to the point where that need is fulfilled by the organization.  For another example, billing a company for its cell phone usage and getting paid for that usage.  The importance of defining process in this manner influences several factors.  How the process is measured will be determined by how the start and end points are defined.  It's relatively easy to measure efficiency at several levels from the process down to the step.  However, it becomes much more difficult to measure effectiveness and adaptability unless the end-to-end process is considered.  For example, in an order process, an organization could easily measure the efficiency of the payment of bill or creation of a purchase order, but to know whether the whole process works there must be a measure of effectiveness — e.g., did the stakeholder receive the goods that have been paid for?

Predictable/Repeatable

Fourth, process will be predictable and repeatable.  It's common for people to associate process with predictability.  Unfortunately, although "good process" may be repeatable and predictable, it is not a requirement of good process to be predictable.  For example a risk assessment process will only occur when a perceived risk has been identified.  Normally, an organization would not know in advance when an identified risk will occur; otherwise they would attempt to prevent such an occurrence.  Normally this assumption is easily made because process describes what an organization does at a conceptual level.  The distinction at the activity level is commonly represented by a decision diamond indicating the various paths of the process flow.  It is at the activity level that the exception processing becomes almost immediately evident.

Value-Add

Fifth, process adds value. Again, due to the fact that processes describe what an organization does in a conceptual way, the grouping of processes is often referred to as the value chain.  The idea of a value chain implies in itself that the processes it contains add value.  Because there are inefficiencies in organization, it's common sense that not all of the activities add value.  It's at the activity level that it's appropriate to assess the value of what people are doing.  It's important to remember that there are three basic categories of value.  One is "Value-Add."  These are activities performed in the organization that add value to the process from a customer perspective.  Another is "Business Value-Add" or "Necessary Non-Value Add."  These activities are normally ones that don't add value from a customer perspective but are simply things that must happen for the company to remain in business from a regulatory, compliance, or legal perspective.  Lastly, there is "Non-Value Add."  These activities don't add any value from a customer perspective or a business perspective but are simply part of the culture of the organization.  When asked why they perform these types of activities, people will normally say, "We have always done it this way."  These are cultural non-value add activities.

Multiple Capabilities

Sixth, processes will require people with multiple capabilities to participate in order to complete the activities from starting event through ending event.  This usually means that these people work in different functional areas in the company.  So, this is very similar to (if not just another way of) saying that processes are cross-functional.  By contrast, activities are the things people are doing in these specific functional areas.  So, activities are more role or job related.

IGOE's — Complete Set

Finally, seventh, at the process level all of the IGOE components (Inputs, Guides, Outputs, and Enablers) will exist.  This means that "processes" will always have inputs, guides, outputs, and enablers.  However, at the activity level there will always be guides and enablers, but there may not always be both input and outputs.  For example, create a report.  In this activity, the very name of the activity should invoke some suspicions around inputs (things that get transformed) because the name create implies that there is something new happening.  There will probably be a lot of guides (reference material, knowledge, policies, etc.) which will set the criteria and provide the information necessary to create this new report, along with sufficient enablers (tools, resources, etc.) to use the guides appropriately, ultimately concluding in the output of a report.

Create Report Activity

In addition, it might be possible to have an activity without an output, such as Archive Report.  This is a very straightforward activity that simply represents taking a report in some format and archiving that report for storage or future use.  In this case there will probably be several criteria (guides) for how long the report is kept and perhaps what format.  There will be a type of (enabler) mechanism for archiving the report, such as digitizing/imaging, or it may just be file cabinets or labeled boxes.  There will be a report shown as an Input (things that transform or change) but potentially nothing as an Output.  This of course assumes that there are no reports being produced — there is no record indicating where everything is archived.  While this might seem impossible, it does happen.

Because processes are conceptual, at the highest level, they will always have inputs and outputs.  However, as more of the detail of the "how" the process works gets documented, there is more of a need to be specific about "what" transformations occur and where they do not.  The majority of process models are being created with the idea of using that knowledge about the process to improve the process.  If improvement is the purpose of a "model" then it is essential to have a model with enough specific details that good decisions can be made regarding what needs to be improved and should be changed.  For example, in diagram of the activity "Archive Report" there are no outputs represented.  So, when an analyst begins to review this, the lack of an output brings immediate attention to this aspect of the process.  In fact, until the diagram was drawn in this manner, no one was aware that reports did not exist about what was archived and the location of the archive records.  The organization had a great activity for archiving information but no way of ever finding the information again.  Therefore, because of the way the activity model was drawn, an organization was able to identify and prevent what might have been a potentially serious problem if it had been discovered by regulatory auditors or if they really needed retrieve the information but couldn't find it.

Archive Report Activity

The most important concept to learn from these examples is that it is very important to be able to distinguish between process and the activities that compose the process in order to analyze a process thoroughly.

Commonly, organizations who are trying to manage and improve their processes are struggling with a standard, meaningful, adequate manner in which to communicate process within organizations.  Whether it's public or private organizations or even educational organizations, there is a common theme.  Everyone would like to have a standard mechanism for documenting process.   However, most service organizations struggle with the definition of process and process should not be documented until it's been properly defined.  Hopefully, these seven tests will facilitate better decisions regarding process improvement work in organizations.

# # #

Standard citation for this article:


citations icon
Kathy A. Long , "Is it a Cake or is it Clean? (A Litmus Test for Process)" Business Rules Journal Vol. 10, No. 11, (Nov. 2009)
URL: http://www.brcommunity.com/a2009/b508.html

About our Contributor:


Kathy  A. Long
Kathy A. Long Global Upstream Process Architect, Shell Oil

Ms. Long has twenty-five plus years of experience in all aspects of BPM as well as Continuous Improvement and Lean. She is certified as a Lean Office practitioner as well as a Kaizen facilitator. She is currently in the role of Global Process Architect responsible for Upstream Process Architecture. During past two years at Shell Kathy has managed projects which implemented a new Business Management System for the upstream business as well as designed and documented the majority of core business processes. Working closely with the Global Process Owners, Leads and Architects to create quality standards and fit for purpose processes.

Read All Articles by Kathy A. Long
Subscribe to the eBRJ Newsletter
In The Spotlight
 Ronald G. Ross
 Silvie  Spreeuwenberg

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.