Four Things to Consider Before Mapping Processes for Software Requirements (4 of 4)
May 17, 2019
by Frank Weiss, P.E.
The fourth of four articles regarding the use of process mapping in support of software projects, particularly GIS projects.
In Article 1, we discussed how using business process modeling and design (BP) software as a single source of truth helps to avoid rework, duplication and potential transcription errors. In Article 2, we discussed how to leverage viewing and report-generating tools to disseminate BP information to non-BP software users. In Article 3, we discussed ways to determine how much information to include on a process diagram and when to break it into sub-diagrams. In all these articles, I’ve made examples with Enterprise ArchitectTM (EA),’ our tool-of-choice for BP requirements mapping at POWER Engineers Geospatial and Asset Management Division.
In this article, I’ll share how using standards will help maintain consistency among the diagrams you and others in your organization create. Moving between diagrams when the content has a different appearance can be disorienting to a user, so consistency is important.
Business Process Mapping and Notation (BPMNTM) is a specification published by the Object Management Group. It has become the de facto standard for process mapping and is the standard that we use in our work at POWER. If you are just starting out with process mapping, I encourage you to seek out references on the correct way to apply BPMN before diving in. Starting without investigating its correct use can lead to misapplying the symbols. Also, it is important not only for you to understand the standard, but also for those to whom you provide your diagrams.
POWER typically provides workshops for clients to help them capture their work processes. Workshop participants often have had little to no prior exposure to process mapping. If you jump right into the mapping effort, their focus may be split between figuring out the BPMN symbols and contributing to the mapping effort. That’s why we begin workshops by explaining the most commonly used symbols and how they are applied. A sample set of symbols is shown below:
This approach familiarizes the participants not only with the major elements of process mapping (activities, gateways, events, etc.), but also the meanings for their different types and associated symbology (user task, parallel gateway, timer event, etc.).
The use of an industry standard like BPMN helps keep diagrams consistent. However, because there are other tertiary elements to consider, it helps to also have your own documented guidelines. Within them you can define things like naming conventions, headings, colors, legends and the minimum amount of information that should be captured. Holding to your guidelines will help ensure consistency plus help you analyze and report the information captured.
BP software provides the ability to capture a great deal of information — probably more than you will need. Double clicking on an activity will open the properties screen, where you will add this information (see below).
Multiple information screens may be accessed from here by drilling down the tree in the left-hand pane. The “general” screen (left arrow above), allows you to capture the activity name and its description. It also has tabs below the right-hand pane (right arrow above) that provide the ability to capture additional information. In this example, the tags pane is showing a “systems” tag of work management that was entered.
Selecting requirements in the tree (image below, left arrow) changes the panes as shown. Multiple requirements (right-hand pane) may be added to each activity. Clicking on a requirement displays the name (top right arrow) and description (bottom right arrow) for viewing and editing.
Your guidelines should establish what information you need to capture and how you plan to record it. At a minimum, you should capture the name and description of the activity. Descriptions are important. A step or activity may seem obvious during a workshop, but later when reviewing the process, you may forget its purpose without a description.
The naming of activities should follow a verb-noun convention (prioritize work, perform inspection, etc.). I would also suggest that you add a prefix in front of the name. We typically use a two or three-character abbreviation, followed by a numbering hierarchy for a prefix. A prefix will permit sorting to keep all related processes together, plus it makes it easier to find an activity in a diagram. For example, instead of searching all over the diagram for the name “document completed assignment,” you can go straight to “MW.06.” If there is a child diagram, use the prefix from the parent, appended with a period and a sequence number. For example, if the parent process is MW.01, the activities on the child diagram would be prefixed with MW.01.01, MW.01.02, etc. Note: EA has a function that will automate the creation of prefixes to help simplify this task.
One thing we discussed in Article 2 was POWER’s VB script-based reporting tools. Since EA stores the diagram information in a database (called the repository), information can be extracted via code for reporting and analysis. This underscores the value of consistently capturing information. Obviously, the report programs won’t function properly without good data. An excerpt from a report generated by VB Script is below.
The data on this report excerpt was extracted from the repository. The VB script selects the data, sorts the records by name (with their prefixes) and generates the report. The table below shows the information sources used for the report.
While this is an example of using the data to generate a report document, it also comes in handy for analysis. We have other VB scripts that export the data to spreadsheets. This allows you to perform tabular analysis such as: which activities use what systems, which users use what systems, summarize requirements, etc. That information is very useful for identifying who is impacted by a change when developing change management and training plans.
Another way we leverage EA for consistency is to automate the coloring of activity symbols (example below).
Looking at the legend in the above diagram, we see a color code for the systems. We have configured the legend to automatically color the activities based on the “systems” tag value. So, if you change the “systems” tag for activity MW.04 from “GIS navigation app” to “work management,” that activity’s symbol would change from blue (as it is above) to gold. This makes it easy to see at a glance which activities are supported by what systems. The color scheme should also be defined in your guidelines to keep all diagrams consistent, even among different projects.
I hope you have found this series helpful. My goal was to provide practical considerations to help with your process mapping efforts. Much of the content I presented was based on my experiences of what worked, what did not work, challenges I faced and the resulting solutions. Here are some final nuggets:
- Using a BP tool expedites the mapping process and provides the single source of truth to leverage throughout the project. (Article 1)
- There are many ways to send stored information to all who need it. Don’t shy away from using BP software on your project just because of licensing concerns. (Article 2)
- Keep it simple. Don’t make the diagrams too complicated, especially if your intended audience is business subject matter experts, rather than application developer types. (Article 3)
- Developing and adhering to a standard set of guidelines for information capture is useful. It makes your diagrams easier for the viewer to comprehend, plus it provides the basis for analysis and supports standardized reporting. (Article 4).
If you have questions or suggestions, I’m happy to reply. My contact information is below.
- Article 1 – Wouldn’t it be Great to Manage Processes and Related Information Together?
- Article 2 – Sharing Process Results with the Enterprise
- Article 3 – The Right Level of Diagram Detail
- Article 4 – Consistency is the Key – The Importance of Internal Standards
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 firstname.lastname@example.org.