A good use case will help you apply context and frame all of the activities of each process or inter-related series of processes. It can also be a good way of uncovering dependencies and events that will trigger a sub-process and can help the operational manager understand which activities are more mission critical.
An operational “use case” is really nothing more than a description of the relationship between all of the “actors” who play a role in a given process. The actors work together in order to achieve a specific outcome. Use cases are often used in system engineering, but can be extremely useful tools for operations managers to begin to understand their operating environment. This is where planning starts.
The ability to successfully document all of the actors and their respective relationships increases the likelihood that your process, or your “machine”, will be defined completely. This is because you will by definition understand all of the moving parts and all of the transition points if you fully understand the operational use cases in a given function.
An actor can be a human or a system. For example, for someone to successfully purchase a sandwich from a deli, there are both human and system actors. In this example, human actors will include the guy that makes the sandwich, the person buying the sandwich and the person ringing the sale up on the cash register. The non-human actors would include the cash register, the scale used to weigh the deli meat, the refrigerator case that holds the meat and maybe a griddle if the sandwich is a hot sandwich.
Any person or any system that plays a role in the use case needs to be included in the analysis even if only to acknowledge a dependency. This reflects the fact that if you remove any one of these actors from the process the outcome will change or be sub-optimal in some way. If you remove a human actor then the sandwich does not get made at all or a different actor will need to provide coverage thereby impacting the overall efficiency of the process. If you remove the scale then the sandwich might have too much or too little meat and this may impact the profitability of the transaction for the deli owner or the satisfaction of the client. Most importantly, each pairing of actors produces a desired outcome and includes a specific transaction. Each transaction can be measured or otherwise controlled via a series of checklists or other criteria to ensure completeness or quality levels.
Use cases are most often utilized by business analysts when defining requirements for a software solution. But the reality is that they should be the starting point for defining the boundaries of any business process whether software tools are involved or not. There are many different frameworks for creating use cases and they all have their place. Operations managers need a lighter version focused on actors, dependencies and relationships. A systems architect may need to be at a lower level of detail.
To begin the use case design process for our example from an operational perspective, the process leader should consider the general requirements for the process in order to achieve a good outcome. This includes identifying of all of the individual variables that a successful purchase of a sandwich is dependent on. This will help set the stage by identifying all preconditions, triggers, dependencies, etc. For buying a roast beef sandwich from a deli at lunch hour, the following basic requirements might exist:
1. There needs to be a deli nearby the office.
2. The deli needs to be open.
3. The purchaser needs to be aware of the deli’s location.
4. The deli needs to be fully supplied with cold cuts, bread and other materials.
5. The purchaser needs to have time during his lunch hour to get to the deli and back.
6. The purchaser needs to be hungry enough to justify going out to buy a sandwich.
7. The purchaser needs to have money to buy a sandwich.
If any one of the above conditions is not met then the sandwich will not be purchased and the process will have failed. In other words, the outcome will be sub-optimal or the process will not kick off at all (in the case of “The purchaser needs to be hungry”).
Walking through a use case description is a great starting point. In some cases, if one of the conditions cannot be met during the process of brainstorming the use case, then a new condition must be included. For example, if the purchaser is not aware of the deli’s location as listed in condition #3 then a new actor and relationship might be introduced in order to close the knowledge gap. In this case, we could add a GPS into the equation as a new system actor to help the purchaser find the deli.
The below example of a use case for purchasing a roast beef sandwich is clearly over-kill in the sense that most people can successfully purchase a sandwich without the need to design a formal process. With that said, it is an easy and simplistic example to illustrate how everything we do can be “proceduralized” in order to ensure the best possible outcome.
If the above actors are all in place and the preconditions and dependencies have been met then when the triggering event happens the process should have all of the components to be successful. But the above does not describe the relationships between the actors yet. It represents the raw materials for the use case only. The relationships are best described in a diagram as depicted below:
In this use case, there are four distinct processes that have been identified, but not documented. There is a process for ordering a sandwich. There are only two actors involved with the ordering process. There is a separate process for making a sandwich. This process is kicked off by the receipt of an order from the purchaser. The sandwich maker leverages a scale to weigh the meat in support of the process to make a sandwich. Once the sandwich is made then there is a transaction to be processed. The cashier uses the cash register to facilitate the processing of the transaction. Lastly, the deli owner supports the menu by ensuring that inventory is available and the lights are kept on in the deli.
The use case diagram allows the operations manager to see all of the relationships between the actors and makes it easy to identify the interconnectivity between disparate processes. The use case can make it easier to identify triggering events, dependencies and pre-conditions as well.
If someone was tasked with documenting the full scope of a machine for ordering sandwiches they could use this use case as a guideline for defining how many unique processes were involved, who played what role, how the various parties interacted with each other, where the failure points were, what decisions needed to be made and when, what outside dependencies existed, etc. By taking the time to understand the use cases involved with an operation the operations manager will more likely design supporting processes that are complete.
For more information about this article or our services, reach out to us at info@coeurderoy.com.