For any process in any industry to be useful it needs to have three basic characteristics. First and foremost, the process needs to be scalable. In other words, the process needs to be designed in such a manner as to consider all of the possible ways the business could possibly evolve. What happens in the event of an acquisition or sale for example? What happens if orders triple?
Second, the process needs to be repeatable. Being repeatable means many things. It means of course that the process can support multiple transactions, whatever they may be. It also might mean that the process is designed and documented in such a way that different employees can run the process with the same exact result. Depending on the process, it might mean that the process can be “lifted” from one part of the business and applied elsewhere.
Lastly, any good workflow process needs to be sustainable. Sustainability has to do with the ability for the process to persist over a long period of time. It can be expensive and time consuming to implement new policies, practices and the processes that they support. Making sure that the manner in which a process is governed is robust enough to ensure its survival. When designing process, these three characteristics must always be not only considered, but must be factored into the designs and plans.
There is probably an entire library dedicated to workflow design alone. So, we will not address that here in great detail. With that said, good process design fails when it is not conceived at the appropriate level of detail. At the most basic level, process flows at too high a level will likely miss some important element that will bring the whole process down. Your process design should be considered the basis for your operations and should be documented in a run book. For new operations, it is your roadmap and the medium that you will use to help others understand the overall vison.
Though true operations managers tend to be pragmatic, most inexperienced managers tend to make hasty decisions based on a half-baked plan. This is the “ready, shoot, aim” trap that will always result in the abject failure of the initiative. Operations managers aim by designing good process. So, a detail level process will help mitigate risk and ensure success.
A good way to think about this is to extend the sandwich use case from earlier. The use case definitely covers all of the actors that need to play a role in the process. And can tell you what sub-processes need to be considered. Let’s take the specific example of the first part of the workflow supported by the use case. There are four core sub-processes to be designed:
1. Order sandwich
2. Make sandwich
3. Process transaction
4. Support menu
Where does the process design start? If we simply started with the logic first process flow “order sandwich” then we leave out the preconditions and other details that might cause the process to collapse in on itself. Consider the first three steps of the high-level approach:
The process seems intuitive. What can go wrong? Simply follow these steps and you should be able to exit the deli with a nicely wrapped sandwich. Or would you?
Is the first step in the process the real first step or did something have to happen before that step was taken? How did you get to the deli? How did you get into the deli? Did you have to wait in line before placing your order? Was there a menu? Were you offered sides? A drink? Was your sandwich pre-made or did you have to wait for it to be made? Was there an option to have the sandwich toasted? Where did the money come from to pay the deli owner? Could you pay with a credit card? How did you leave the deli? Could you eat in vs. take-away? Did the condiments come on the sandwich or did you have to go to a condiment bar?
All of these decisions needed to happen in order for you to successfully purchase the lunch that you wanted. In other words, had your workflow process not considered these decision points or conditions the outcome of your lunch order would have been disappointing or at the very least not all that it could have been. An alternative way to draw the same process for purchasing a sandwich might look like the following:
The above workflow diagram is obviously overkill for this process because anyone can order a sandwich successfully, but if the process was describing something more critical, say refueling a nuclear reactor, which level of detail would you prefer? Interestingly, the above “overkill” workflow is really still at a relatively high level. For example, if you picked any one box randomly, say “Provide credit card” there are many details behind that simple task. You would have to:
1. Locate your wallet
2. Pull wallet with appropriate hand
3. Open wallet
4. Locate credit cards
5. Select appropriate card for transaction
6. Hand card to cashier
Adding that level of detail to the process map would certainly be overkill and would make the diagram unwieldy. A better practice is to make sure that the workflow diagram is representative of each category of work. For example, providing credit card is a category of work that has a specific outcome in its own right. Because of that, you can design test cases and success criteria. In short, you can validate if your process is successful.
In most cases the additional details describing a category of work are provided in supplemental text either in paragraph or table form with appropriate labels aligning the text to the specific step within the workflow process. We will not get into the details here. Instead, as noted above, the operations manager should consider how to validate their process design. There are a number of ways to do this.
First and foremost, socialize the plan and solicit feedback from those that are closer to the details and those that will be responsible for execution. They will not only mitigate risk by helping you to identify gaps in your process, but will begin the process of getting buy-in to the new process design.
Second, is to design test cases and/or success criteria depending on the nature of the process. Either way, this basically boils down to documenting a positive outcome for each step outlined in the process. This is best done in table form with a corresponding code aligning the success criteria with the process step in question. There can be success criteria documented at the step and sub-process level as well as for the process as a whole depending on the level of complexity.
This is also the level where checklists can be applied. Checklists can be powerful governance tools to ensure that the process in question is operating to standard and any step controlled or applied by a human actor is verified.
The depth of workflow described above is very much targeted at operations managers dealing with typical business functions. It goes without saying that design process for a technical function, such as flows through a water treatment plant or landing a rover on Mars is quite a different story.
Assuming that you have a solid process flow, what do you do when it breaks down? Workflow designs are often the basis for full or partial workplace automation solutions that involve technology. Oftentimes where the human process and the technological process intersect is where things can go wrong. Besides, not all humans are as dependable as software and not all software works 100% of the time.
This means that in addition to spending considerable time thinking about success criteria, operations managers should spend a healthy amount of their time diagnosing all of the things that could go wrong. This should include an analysis of each actor in the process whether system or human, all of the hand-offs in the process and the nature of the infrastructure (i.e. the technology or method of control).
This level of analysis will form the basis for contingency planning. Suffice to say, successful processes take a while to design and implement. It is critical that operations managers take their time and not be pressured to do things fast as that will lead to sloppy processes. In the end, the more time taken up front for design, documentation, success criteria and contingency planning the short time it will take to implement a good and successful process.
For more information about this article or our services, reach out to us at info@coeurderoy.com.