Used almost interchangeably, these two terms have become synonymous to the ears of the masses. That doesn’t mean they are right. There are fundamental differences between what each term implies, and the results which should be attained when attempting to improve one or the other. There is a lot of overlap between the two, and it can only be expected that with that level of similarity some of the details would end up lost in translation.

Most notably, when analyzing a process you should never look at how something is being done, rather you should focus on what needs to be achieved. Contrary to this, analyzing a workflow does involve looking at how something is being done, as you need to identify the entire series of actions required to complete the workflow. A workflow takes place in what is generally only a small subset of a process.

Here is a breakdown of what you should be investigating when looking to improve upon any process or workflow:

Respect the process

Without getting extremely granular (although in the case of continuous improvement initiatives or process documentation you definitely should be as granular as is feasible), you are looking to identify the core activities required to accomplish one large task. You are doing this without involving any system, person, location, or object in your analysis. Right there you may be wondering what is left to analyse? Well friends, it’s all in the actions.

It may be difficult to isolate at first, but once you wrap your head around it the idea is simple enough. Take the following example:

Whenever a package is delivered to the office, after making sure that the package is meant for us, I sign for the delivery and then go to the computer and compare the box manifest to my on-order spreadsheet. If there are no discrepancies I put the stock away as is, if there are discrepancies I scan in all the inventory manually before putting it away.

Let’s break it down into what it would look like in process form (less the DFD style diagrams that should go with it).

• External input: Package enters - Manifest enters - order number enters

• Compare address on package to local address

  • If address matches, accept delivery

    • Internal input: on-order enters

    • Locate on-order for package with order number

    • Compare package contents against unfulfilled orders

      • If order balances, place stock in inventory. End of process.

      • If order does not balance, detail receive inventory

        • Place stock in inventory. End of process.

  • If address does not match, refuse delivery. End of process.

Every action that is taken is put into place and linked to the action or input that precedes it, and the ones which follows it. In this type of analysis the fact that the unfulfilled order information is on the company computer is irrelevant to the fact that an on-order list exists and needs to be validated against. Let’s now take a look at this same example but in terms of a workflow analysis.

Recognize the workflow

When building a workflow, you take into account how you will accomplish a series of tasks, and not just what those tasks are. Workflows will generally be adapted and updated more frequently than their underlying processes. They incorporate the key elements of how a task is completed, including at times the system, person, location, or objects required to complete them.

Using the same example as above, try to notice the slight differences in the definition of each step in our workflow, as well as what they imply:

• External Input: Delivery man enters - Package enters

• Validate shipping label for company address/information

  • If address matches, accept delivery

    • Internal Input: on-order worksheet

    • Scan order number into system to retrieve the unique order confirmation

    • Compare quantities on shipping manifest and unique order confirmation

      • If order balances, mark order as delivered and place stock in inventory. End of workflow

      • If order does not balance, scan UPC’s of all products into the inventory system and confirm quantities received

        • Place stock in inventory. End of workflow.

  • If address does not match, refuse delivery. End of workflow.

The core steps are all the exact same, the true differences lie in the small details which transform the entire process from being a conceptual map into a series of instructions which can be used to train and educate others. The change from stating that someone needs to “compare the contents of the package against unfulfilled orders” to “Compare the shipping manifest to the unique order confirmation” removes the ambiguity of the statement, and gives new users a much more tangible idea of what they need to do to succeed.

Realize the potential

As a business expands and new tasks are required for operation, processes need to be defined. At first, they are usually very loosely defined and somewhat ambiguous in the sense that they are rarely documented. It is much more likely that when you needed someone taking care of accounting in-house, you didn’t stop to plan out every little task or rule before hiring someone to join your team, but rather you onboard someone who already has the skills and knowledge to accomplish these tasks using the workflows they have developed for themselves.

This doesn’t mean it is too late to define or redefine the important processes and workflows. While not feasible to comb through every business function you have, significant improvements to efficiency and productivity can be found by isolating specific subsets of workflows to identify areas which have become inefficient. Chances are, a process or workflow defined even a few years ago before you had access to certain pieces of equipment, software, or services is outdated.

Sourcing ideas for improvement from users who deal with specific tasks on a frequent basis is one of the best ways to mitigate the initial cost of any process improvement initiative. Asking questions like “If you could take away any part of this task, what would it be?” or “What tasks take up the majority of your time?” can return the points of tension on your overall process.

I believe that as a general rule, the response to the question “Why do we do things this way?” should never be “Because that’s how we have always done it.” and if it is, those are the first tasks which should be put under the microscope.