Our Insights

Four Things to Consider Before Mapping Processes for Software Requirements – No. 3

March 12, 2019

No. 3 – The Right Level of Diagram Detail

The third of four articles regarding the use of process mapping in support of software projects, particularly GIS projects.

Synopsis

The level of detail one should include on a process diagram will vary based on business need and intended audience. This article provides some guidance on when you should, or should not divide a diagram up into subprocesses.

In Article 1, we discussed the advantages of using business process modeling and design (BP) software as a single source of truth, helping avoid rework, duplication and the potential for transcription errors. In Article 2, we discussed ways to disseminate the information to non-BP software users by leveraging viewing and report generating tools.

In this article, we want to talk a little about the diagramming itself. Specifically, how do we know how much information to place on a diagram and when we should break a diagram into multiple smaller diagrams. However, before we get into that, let’s talk about parent-child diagram relationships.

Business processes can get very involved. If you think about it, there may be a hundred or more steps end-to-end for a given process. Obviously, trying to get all that information on one drawing can be problematic, so you may want to think of the overall process as a collection of smaller processes. To decompose a diagram, you take segments of the overall process and push some details into smaller subprocesses. All these subprocesses are related, so how do you keep the different diagrams organized?

This is an area where BP software can help. Because POWER Engineers has standardized on using Enterprise Architect [1](EA) for BP requirements mapping, I will base this discussion on that software. However, other BP software products have similar capabilities.

In the image shown above, a diagram contains four Parent processes. In the BP software, clicking on one of those Parent processes will open the Child process diagram, as shown by the arrows. The Child diagrams may themselves contain subprocesses (as shown in the two to the left above) which will open additional Child diagrams, or they may just contain activities (as shown in the two to the right above). In this way, BP software makes it easy to navigate up and down the parent-child tree of diagrams.

To leverage this functionality, you will need to decide where to break up your diagram, but be careful. If you decompose to too many levels, you end up with numerous diagrams, which can be confusing. On the other hand, if you don’t break it down sufficiently, you run into aesthetic problems. In the latter case, the diagram becomes cluttered, difficult to read and hard to modify (due to space limitations, crisscrossing lines, etc.). Something else to consider is to what level of detail should you capture information to keep the effort in line with the need? So how do you decide where to break it up? Well, it depends.

The first question you will need to answer is what is your objective? If you are focused on business process reengineering, you only need to capture enough detail to evaluate things like cycle times, number of handoffs, number of resources involved and the number of activities. This will allow you to compare current- state (as-is) and future-state (to-be) processes and develop a gap analysis.

However, if your goal is to develop and deploy a software application, you may need to drill down to greater detail to capture discrete steps, application requirements and artifacts used.

The second question to answer is who is the target audience? If you are communicating with the business Subject Matter Experts (SMEs), they may have had little to no experience with process mapping. While going through process mapping workshops, they will be trying to conceptually relate what you are showing on the diagram back to their own business experience. If that is the case, you are better off breaking the diagram into logical components to keep the discussion focused.

Start with higher level business functions, for example receive, design, construct and close-out. It helps if the facilitator understands the business and has some of the business functions already mapped as a starter set. Working with the SMEs, capture the steps for each of the functions. If the diagram gets too busy, consider breaking it up. You can postpone breaking the diagram up until after the work session to avoid interrupting the discussion flow.

I typically consider breaking the diagram up when the number of activities gets past 15 or 20. This is a good rule of thumb to keep the diagrams easily understood. Also, if you find there are several steps that are used in multiple processes, consider combining those steps into a single subprocess that can be reused on multiple diagrams.

That covers the SMEs, but what if the answer to who is the target audience is a technical team? In that case, you may take a different approach.

Developers most likely will use these diagrams as a reference for requirements in developing or configuring software. Picking off requirements can be easier to do from a more global view, rather than from a decomposed set of diagrams. For this reason, developers may prefer a larger diagram that they can walk through checking off functions, identifying state changes, capturing domain values and understanding the overall flow.

The diagram below is an example of this from one of our projects. This is not being presented as a best practice but may provide some insight to real-world experience.

We originally started with a large diagram, much like the one you see above. However, for our process workshops, we broke it into smaller, logical parent-child diagrams. That worked well to support interaction with SMEs and refining the processes. However, the end goal of the effort was to configure a work management system, so the diagram was reassembled into the above form, which was preferred by our developers.

Thus far, I have attempted to provide some practical guidance for the creation of process diagrams. Lastly (and at the risk of getting into trouble), I would like to talk briefly about process levels.

Invariably someone will ask you to what process level are you mapping? They are referring to established standard classifications that define appropriate information to be contained in the diagrams. I use the word standard loosely because I have seen multiple definitions and numbers of process levels, so it depends on the definition to which you subscribe. Some use four levels, some use five and others use six. I like the four level definitions presented below. Keep in mind that there may be additional child diagrams within a given level.

Level 1 – These are very high, corporate level diagrams. They don’t depict workflows as much as they provide a container within which to organize your processes. In many cases, level 1 diagrams are not created.

Level 2 – These are end-to-end processes that cut across organizational boundaries. For example, these processes may involve the Customer Service groups, Engineering groups, Drafting groups and Construction groups. By BPMNTM definitions, process flows do not cross organizational boundaries, but messages flows are used to pass information between them (more on BPMN in the next article).

Level 3 – Level 3 diagrams are getting down to the details. They will depict process steps within an organizational area and show activities, roles, inputs and outputs. Process mapping efforts often stop at this level, unless you need to develop very specific requirements.

Level 4 – At the lowest level, the diagrams are very detailed. Level 4 diagrams will show step-by-step what work is performed, what applications are used, requirements information and artifacts used or produced. The creation of level 4 diagrams for the enterprise can be very time consuming. They are typically done only when the need dictates.

In Summary

The amount of detail that you should include on a given diagram is driven by the needs and the intended audience. For general Business Process mapping efforts, you should not produce diagrams that are overly complicated. However, in specific situations, a large diagram may be required. There some standard guidelines available from various sources, but in the end, the diagrams you produce are affected by personal style and preference.

In my next article, I will discuss the use of standard diagramming conventions. We will discuss not only the BPMNTM specification, but also the value of establishing guidelines on what information should be captured. While personal preference affects the final product, adherence to a standard helps the diagrams have the same appearance and level of content, no matter who creates them.

View other article(s) from this series:

About the Author

Frank Weiss, P.E., is a strategic consultant in POWER Engineers’ Geospatial and Asset Management division. He has over 40 years’ experience in the utility business, including 19 years as a consultant. Frank has utilized his expertise to deliver solutions in engineering, operations, process reengineering and software implementation projects. His process mapping experience includes mobile workforce dispatch, T&D work management, outage restoration, energy market resource dispatch and GIS-based job design and posting. If you have any questions or comments for Frank you can contact him at frank.weiss@powereng.com.

[1] Enterprise Architect is a software product developed and sold by Sparx Systems Inc. Note: there are many other tools provided by EA including Data Modeling, Use Case and Sequence Diagramming.