I’ve been part of a lot of discovery efforts and have found a few ways to increase the chances of identifying all the relevant factors. I plan to discuss these only informally. Volumes of ink and electrons have been spilled describing formal methods like UML, Model-Driven Engineering, and Business Process Notation, but I’m not talking about implementing systems based on what is discovered, only making sure the discovery process itself is thorough.
That said, discovery begins with an idea of what you’re trying to accomplish. You have to discover the factors relevant to your end goals. When I worked on training simulators for nuclear power plants the main rule guiding discovery was whether an element affected the readings on the operator panels or were affected by the controls on the operator panels. Sample ports, bypasses, and elements used only for maintenance were not included.
The goal of the card game Set is to identify groups of three cards from those that are turned face up in the playing area. Each card has a figure with four possible characteristics: shape (diamond, oval, or squiggle),color (red, green, or purple),fill (open, hashed, or solid), and count (one, two, or three items). A valid set is one where each card is either the same in any of the characteristics or where each card is different in any one of the characteristics. The following three cards would be a valid set:
- one purple open oval
- one purple hashed diamond
- one purple solid squiggle
This set is valid because the three shapes are different, the three fills are different, the three colors are the same, and the three counts are the same. When scanning the cards you might try to just stare and hope a set jumps out at you (like the one-, two-, and three-count red open ovals), but if that doesn’t happen quickly you would take a more systematic approach, right? And how would you do that?
You might look at all the cards of each color, check to see if there are any groups of three that have the same or different number of shapes (a one, a two, and a three or three threes), then see if any of those groupings are still valid after looking at the shapes themselves (all squiggles or one of each), then see if the fill patterns work (one of each or all the same). If you don’t find anything you might start with a different characteristic. On the next pass you’d start by looking at all the cards with three shapes, then look at the shapes, then the colors, and then the fills. On the third pass you might try looking at every pair of cards, figuring out what a valid third card would have to be, and then see if any such card is available.
The point is to be sure you examine the characteristics of the cards in a systematic way. With a little practice you get faster. The person who taught me the game was downright scary at it, which inspired me to buy a version for my phone. I got faster all right, but the game was too much fun so I had to delete it!
Performing process discovery in the wild is almost easier than finding valid sets in the card game. In the game you have to consider four criteria in combination, but in a discovery process you can mostly consider each element of the system in isolation. You just need to be thorough about each one. To be systematic, let’s look at all the element types one by one.
Entities: Systems may process one type of entity or multiple types. How you define them is up to you. In the border station simulations I worked on the only moving entities were border-crossers in general. The fact that they were private passenger vehicles (cars, etc.), commercial vehicles (trucks, etc.), buses, and pedestrians was important, but those differences were treated as characteristics of entities, not different types of entities. A manufacturing system might treat an assembly that becomes the final product differently than the parts that get added to it. Returning to the example of border stations we might have chosen to model the movement and presence of the officers explicitly, and they could reasonably have been considered a separate kind of entity. The distinctions here are subtle, and such classifications can be difficult and may not be that important in the end. However you define them, make sure you find them all.
Entities can also be messages, transactions, permissions, reports, requests, orders, notifications, and almost anything else. Anything that moves in a system can be thought of as an entity.
The entity characteristics you must identify are those qualities that affect their processing. For example, in a border crossing the processes are affected by the mode of conveyance and the citizenship of the border-crossers. A very important property of entities is the time and rate of arrivals.
Stations: These are the places where processes and operations are carried out. There may be multiple stations that all carry out the same operations at the same time (e.g., a grocery store might have a dozen checkout lines, all of which work at least roughly the same way). Groups of similar stations might be called facilities, plazas, process blocks, or something else. They may also be referred to as a process, but the concept is that stations do operations in parallel (many things at the same time), while processes do things more in series (one thing after another).
Once you’ve identified a process identifying the stations is relatively straightforward. In physical system you might identify the stations first, which could lead to identifying the process. The most important characteristic of stations is how many of them there are in each processes (12 lanes in the grocery checkout process). After that you should determine whether the stations have different rules (15 items or less, self checkout, or general) or process different types of entities. Process time(s) can also be very important.
Processes: Processes are individual operations or series of operations carried out at individual stations. It’s easy to miss some of these. Ask everything you can about the operations that go on in each station for each type of entity. Find out what types of decisions are made and what the range of outcomes might be and why. Find out how many operations occur, and what steps have to be handled separately and which, if any, can be combined or abstracted. If it makes sense, find out how long things take. Determine the distribution of times and results, along with averages, minimums, and maximums. Last but not least, find out what conditions must apply before the operations can be carried out. What is needed? Staff, supplies, utilities, logical conditions?
As an example I once analyzed a system that made decisions about whether to underwrite companies for disability insurance. The entities were documents describing the company staff, and those were collated into files, one per employee. Groups of files were shuffled from area to area where different processes were performed. Each process might be composed of multiple sub-operations. Sometimes those had to be considered separately and sometimes they didn’t. Multiple people worked in each area, each carrying out the same process and sub-operations on different files in parallel. In this scheme the people, or at least their desks, could each be thought of as stations.
The way to be thorough when identifying processes in physical systems is to not be bashful about asking what things are. If you see a door or counter or machine or painted area on the ground, ask what it’s for, and what happens there. The worst that can happen is to be told it doesn’t matter. If you have a guide it’s always good to listen to all the information they offer, and some guides may not miss a detail you need. But, you shouldn’t assume the guide will always know what you need. If you ask a lot of questions about things you may jog the guide’s memory, or at least get them to think differently about what you need. It’s a cooperative venture. Be polite and respectful, describe what you’re thinking, and work together. The guide wants you to understand the system so you can solve his or her problem.
Paths: Paths define the routes by which entities move from process to process. If the system involves the movement of real objects then the paths are defined in space. They might be roads, sidewalks, hallways, conveyors, or something else. Paths may also be logical, as in the case of, say, data records getting shuffled to different queues and processes in an IT system.
Buffers: Buffers are intended to hold entities while they’re waiting to be processed. Physical paths may act like buffers, since entities could wait in line on the path to be processed. The most important characteristic of a buffer is its capacity, especially if there are limits to it. The minimum time to traverse a physical buffer might be of importance, but this might not apply to a logical buffer. They often behave like one or another kind of queue, but there are exceptions. A parking lot would be a kind of buffer but the rules for exiting the lot could be implemented in different ways. The residence times could be generated according to a random distribution or could be defined by the time it takes for one or more pedestrian occupants to be processed separately.
Resources: Resources are logical conditions that must apply in order for other elements of the system to work. With respect to stations, resources might include staff, supplies, permissions (including those based on schedules), and so on.
Scope: Understanding the scope or reach or boundary of the system might be the trickiest thing to understand. In my opinion it’s better to consider the scope too widely than too narrowly, at least on the first pass. You will review your findings before doing anything with them, hopefully with experts or customers, so you can always eliminate things you don’t need. If you miss something entirely you’ll either have to go back and look again or you’ll simply fail to capture something important.
One of the biggest disappointments of my career came because I didn’t think widely enough when I was trying to diagnose a system problem. I assumed that furnace combustion gasses just flowed to the exhaust under their own pressure, so when they weren’t flowing properly I only looked at the feed piping, control valves, and instrumentation. I didn’t realize that the particular type of furnace I was dealing with actually had a big ol’ fan mounted in the base of the exhaust stack. The fan was needed because the exhaust had to be pulled out through the bottom of the furnace rather than just jetting out the top like it did in most other furnaces, and in this case the fan wasn’t running. The Level 1 guys would have recognized the problem immediately since they had to do the controls for it, and the field service tech who was sent figured it out right away. I was alone on the site, and as a Level 2 engineer I mostly didn’t have to think about anything that wasn’t going on inside the furnace proper. I knew what some of the exterior stuff was, but I usually had my hands full and didn’t know everything.
I also didn’t think to ask, which is really the greater sin. At the very least I should have called back to the office to ask, “What am I missing?” There was some back and forth, but I know I didn’t ask the right questions and wasn’t systematic enough. There were a lot of ways I could have figured it out, and I kick myself to this day whenever I think about it. Once I thought about what happened in some detail I resolved not to make that type of mistake again. Do us both a favor and learn from my experience.
Most business systems take inputs from a variety of different sources, process them in some way through a number of steps, and produce some sort of output. While the details may change I think you will find this approach useful. If you have any experiences that could add to this general framework I’d love to hear about them.