Context
In operations and process improvement, there is a constant pressure to get things done. The usual formula is “A task comes in, so we start working on it.” This approach feels productive because the progress is visible immediately.
But there is another kind of efficiency that is easy to overlook: The efficiency of stopping before execution and thinking about how the process or operations has to be re-designed.
The former optimizes for today's output. The latter for repeated execution of the process and operation, for as long as it exists.
A simple seven step checklist, that was inspired from some of my unfinished online coding courses during my college days, is the framework that I use, for this refinement of operation and process:
Do one instance Before trying to improve or automate a process or operation, do the work yourself at least once. Don't rely only on how someone describes the process. Take one real instance and do it from beginning to end.
For example,
This helps uncover things that aren't visible in a high level process description:
Observe & document exactly what you did Once you have completed an instance, document exactly how you completed it.
The process of "Formatted the data." would be broken down as below: Open the file → remove unnecessary data → rearrange fields → change data format and standardise→ validate the output → save the final file.
The level of detail matters. This step converts something that may exist as implicit knowledge, in someone's head, into something that can be examined.
And once the process is visible, we can start questioning it. Why is this step necessary? Why is it done this way? Does this always happen? Could this be simplified?
Identify the general process One example is not a process. It is just an instance of a process. So the next step is to look at what you did and determine what can be generalized. Which steps happen every time? Which decisions follow a rule? Which inputs change from case to case? Which activities are exceptions?
If we automate the operation, with one example, without understanding the general process, we may simply automate a special instance of the process. The objective is to identify the repeatable logic behind the process and operation. 4. Test the process Now take the generalized process and try it against different instances. Does the same sequence work? What happens when the input changes? What happens when information is missing? Are there exceptions? Does the decision and conditional rules still hold?
If the generalised process doesn't consistently accommodate the manual instances, automating it is premature. In such cases, we have to go back, refine the process, and test it again. Only when the logic is reasonably sound, should we move to the next step of implementation of automation for the process or operation. 5. Translate into automation The generalized and tested process becomes the specification for the technology or the flow to be built. 6. Evaluate the automation Now we test the implementation: Does it produce the expected result? Does it handle different inputs? Does it behave correctly when information is missing? Does it handle exceptions? Does it maintain the business rules identified earlier? 7. Solve and improve
When a test instance fails, there are two possibilities:
*The implementation could be wrong.
Or our understanding of the process could be wrong.*
If the automation fails because of a technical issue, fix the implementation.
But if it fails because we discovered an exception that wasn't considered when designing the process, we may need to go back to the process itself. This makes the framework iterative rather than linear**.**
**Mnemonic**
DO IT, TEST
D - Do one instance
O - Observe & document exactly what you did
I - Identify the general process
T - Test the process
T - Translate into automation
E - Evaluate the automation
S - Solve and improve