The "Invisible" Process

(Where are Your Processes?)

by Kathy A. Long

I've been writing articles about modeling business process and rules.  Then I realized, what if an organization doesn't even know the process exists because to them it's invisible?  If a process is invisible to an organization, it doesn't really matter what modeling technique is adopted.

So, what makes process invisible to organizations?

Most of us have experienced the frustration of looking for our glasses only to discover they are on our head, or our car keys that are in our hand.  So, it shouldn't really come as a surprise that processes are invisible to organizations even though they are right in front of them, happening daily, delivering to customers.

What is it about process that makes it so hard to see/discover and define?

One major contributor is a concept called "tangibility."  Fundamentally, there is a dramatic difference between how well defined and understood process is in the manufacturing sector vs. the service sector.  It's much easier to associate concepts of ownership, boundaries, control points, measurements, and corrective action with "things" than it is with "ideas" or services.  "Tangible" is described in the dictionary as "capable of being understood and evaluated and therefore regarded as real."  From this definition, we may finally understand why defining service processes is so difficult.  In fact, many organizations either give up, or content themselves with only understanding and/or attempting to understand and improve portions of process.

It's critical that organizations realize the importance of understanding what a process is and what it isn't.  First, not everything is a process!  This is one of the most common mistakes made by an organization embarking upon the process improvement path.  Second, it's important to be able to articulate a definition of 'process' in order to minimize the occurrence of comments like, "We don't have a process for that."  Service process is usually conceptual.  It's often difficult for individuals to associate what they "do" on a daily basis with the conceptual level.  So, because there isn't an exact match or the process doesn't describe their version, they think they're doing something different or that what they do "can't" be described and therefore "there isn't a process."

This conceptual aspect of describing service process provides one major benefit.  It enables organizations to use process frameworks to help them define their own process structure.  For example, a name like "develop product" is so conceptual and generic that it allows many organizations to describe what they do as "develop product" even if what they ultimately sell is a service.

However, if an organization is documenting process in order to improve it, then a "conceptual" definition/model isn't going to help.  In order to compensate for this, the process is often documented at a "very" detailed level.  For example, in the diagram below, instead of modeling top-down (i.e., from process to activity to task, etc.), some aspects of work within an organization will be modeled at a process level but most of the work that is documented will be defined at the step or workflow level.  Normally there won't be any documentation at the activity or task levels.  These workflow models will contain far more information about the process than is required for creating a more efficient, effective, and adaptable solution.  In fact, the overwhelming level of detail in a workflow model does not result in clarity but rather confusion.  In addition, all this detail makes it very difficult to find the real problems in the process.

Therefore, visibility into the middle ground must be created to understand the process.  By creating the right level of visibility into the process, the process can be improved not by 10–100% but by 100–1,000%.  What organizations require to create process "visibility" is a way of consistently identifying and defining process.

For example, when trying to find your glasses, if you ask someone to help you, one of the first questions they will ask is, "What do they look like?"

Organizations are facing the same question, "What does a process look like?"

Whether it's a public, private, or even an educational organization, this is a common theme.  Therefore, organizations must be able to consistently articulate a definition of process.  This starts by asking the question, "What does the process deliver?"  The next question should be, "How will I recognize the deliverable?"  The basic information required from a process can be obtained by using a standard set of characteristics for process and applying them as consistently as possible.  In addition, just like looking for glasses, it will be extremely helpful to establish a standard graphical approach to clarify that definition.

If someone were trying to help you find your glasses, you would start by describing a set of characteristics related to them.  However, one of the best ways to explain "glasses" would be to draw a picture.  From the picture, you both now have a common frame of reference.  Otherwise, you might find "eye glasses" while the other person finds "drinking glasses."  Both are useful but not helpful if you're trying to get a drink of water.

Process visibility starts with understanding that regardless of the level of detail, there are four elements that are common to "all" processes.  They are Inputs, Guides, Outputs, and Enablers.  These will be referred to using the acronym 'IGOE'.  In order to use these concepts properly, consistent definitions must be acknowledged and applied.

An input is defined as something that is transformed or consumed.  So the inputs are not just things that flow through process/activity but that change or undergo a transformation.  Hopefully, that transformation in some way adds value.  Transformation types include physical, locational, and informational.  Physical transformation occurs when something is changed in a literal, physical manner — for example, taking raw materials and transforming them into finished goods.  Locational transformation occurs when the physical location of something is changed — for example, moving goods in a warehouse or moving goods from one warehouse to another location.  Informational transformation occurs when the information is changed — for example, when information is created, updated, or deleted.

Guides are defined as anything that describes the when, why, or how a process or activity occurs.  Therefore the events that determine when a process begins or when it ends are classified as guides as well as all the policies, regulations, and any standards requirements.  In addition, any reference information or data is considered to be a guide, and also any knowledge or experience used to help determine how the process/activity should occur.

Outputs are normally straightforward.  Outputs are the product or result of the change that occurs to the inputs or the result of the creation of something based on the guides.

Finally, enablers are the resources or assets required to transform an input into an output or to create outputs.  These resources include the people, systems, and tools and facilitates utilized by an activity or process.

It's critical for a complete understanding and analysis of process that these definitions are consistently applied.  Without consistency, the understanding and accuracy of the analysis of the process will be compromised.

Just as in the example of looking for "glasses," organizations can't utilize or manage processes if they are invisible.  To create visibility, processes must be defined by a common set of criteria or characteristics that are applied consistently so everyone in the organization can easily identify, document, and improve processes.  Identifying and documenting the IGOEs is a fundamental starting point.  It's also important to understand the concept of "tangibility."  It's the lack of tangibility in service processes that make them so difficult for people to define.  Processes shouldn't be "invisible."  Processes do exist whether we see them today or not.  Processes are delivering to our customers.  We must create "visibility" into these processes in order to be able to improve, manage, and control them.

In the next column, I will propose a set of criteria that can be used to further assist with the definition and visibility of processes.

Until then, "keep it simple."