Business Process Automation Requirements Techniques
Organizations often choose to replace manual business processes fully or partially with software to lower operational costs. In fact, most corporate IT projects involve some amount of business process automation, also known as enterprise automation. Processes can be automated by building a new software system, extending an existing system, or buying a commercial off-the-shelf (COTS) package. If you’re working on a business process automation project, there are several requirements techniques to consider using to mesh the new systems and updated business processes.
Modeling the Business Processes
Eliciting requirements to automate business processes begins by modeling those processes. By identifying tasks that users need to accomplish with the system, the business analyst can derive the necessary functional requirements that let users perform those tasks. The processes that describe how the business currently works are called the as-is or current-state processes. Those that describe the envisioned future state of how the business will operate are called the to-be processes.
What About the Process Analysis Space?
The definitions in the automation space are all but clear – there are many overlapping words about the technologies and the business processes we want to automate. We actually dove into the many acronyms and definitions related to business process automation in a related article. The analysis work is important in all automation implementations to ensure the most critical processes are identified for automation, to understand the processes so they can be automated correctly, and to measure the improvements after the automation is implemented. However, several types of process analysis techniques are commonly employed, and the names are just as confusing as those in the software automation space.
Business Process Acronyms Galore
There are extensive resources available on business process analysis, reengineering, improvement, management, and modeling. This is not a comprehensive resource on those topics. The following list provides some basic definitions of these concepts and their purposes, though you will find significant overlap in all of these definitions:
- Business Process Analysis (BPA) involves understanding the processes as a basis for improving them. It is similar to process modeling, as described in the IIBA’s Business Analysis Body of Knowledge. [1]
- Business Process Reengineering (BPR) consists of analyzing and redesigning business processes for greater efficiency and effectiveness. BPR can target specific process areas, or it can involve a complete overhaul of an organization’s processes from the ground up (Hammer and Champy 2006). [2]
- Business Process Improvement (BPI) involves seeking opportunities for incremental process improvement and measuring the impacts of changes. Tools from Six Sigma, Kaizen, and Kanban are often used for BPI efforts (CIO Magazine 2019). [3]
- Business Process Management (BPM) encompasses understanding all of the enterprise’s business processes, analyzing them to make them more efficient and effective, and working with organizations to make changes to the processes (Gartner). [4] A BPM initiative, therefore, might include applying some combination of BPA, BPR, and BPI.
- Business Process Model and Notation (BPMN) is a graphical notation for modeling business processes (Object Management Group’s BPMN). [5] BPMN can be applied in any of these approaches to business process modeling. It is a robust language of symbols that can be useful when the basic syntax of a swimlane diagram doesn’t suffice. ArgonDigital prefers to use their requirements modeling language (RML®) because it simplifies the notations to a more usable set for business stakeholders to digest.
There are a variety of methods and tools to implement BPA, BPR, BPI, and BPM that are appropriate to employ if your project is undergoing a major business process redesign. All four techniques are established approaches for understanding business challenges and opportunities.
Using Current Processes to Derive Requirements
The following steps will help you model a set of business processes and elicit requirements for an application that automates a portion of them. The sequence of these steps is not always the same, and you might not need all of them on every project. In some cases, the to-be process flows can come earlier in the sequence as a way of driving a gap analysis or to help ensure that the new system is more than just the old system dressed up in a new outfit. In general, though, consider following these steps:
- Start by understanding the business objectives, so you can link each objective to one or more processes.
- Use organization charts to find all the affected organizations and potential user classes for a future software solution.
- Identify all the relevant business processes involving participation of those user classes.
- Document the as-is business processes by using process flows, activity diagrams, or swimlane diagrams. Any of the three models is a practical choice for representing users’ tasks because users can quickly read them and point out any missing or incorrect steps, roles, or decision logic (Beatty and Chen 2012). [6] You’ll need to judge how far down into the as-is modeling you need to drill to get the necessary information to perform the remaining steps in this list.
- Analyze the as-is processes to identify the biggest opportunities for improvement from automation. If this is not obvious, you will need to gather some data about how long it takes to execute individual steps or full processes. You can model these measures by using the key performance indicator model (KPIM). This step helps identify opportunities and, if a software solution is deemed appropriate, set the scope of the software development part of the project. Make sure you are addressing true bottlenecks in the process so that accelerating them will speed up the overall process.
- Walk through each as-is process flow for the processes that are in scope for automation with the appropriate stakeholders to elicit requirements to support each step in the flow. If applicable, you might also perform some document analysis to find out what the industry standards are for the process you are modeling, to help you set realistic improvement goals.
- Trace the requirements to the process flow steps so that it is obvious if you are missing requirements for any specific steps. If you have process steps without requirements traced to them, confirm that those steps are not being automated as part of the project.
- Document to-be process flows to help the business prepare for the new system and identify any gaps that the new system might leave in their process. You might also document use cases to provide more detail about how users will interact with the new system. This information helps developers ensure that they build a solution to meet the business’s expectations, and it helps users understand what they are getting. The to-be process flows and use cases can be used to develop training materials for the new system and to identify any other transition requirements. This step helps stakeholders to understand not only what is coming, but what manual activities and automated systems need to be unplugged, swapped out, or modified.
Designing Future Processes First
There is a chicken-and-egg problem with information systems and business processes. In some cases, people expect that building a new system will drive improvements or changes in the processes. However, the way the application is used in practice might not facilitate the desired business process changes. Process changes involve culture changes and user education that a software system cannot deliver. Some customers believe that the development team is responsible for a successful application rollout and for guiding the implementation of associated business processes. Users won’t embrace a new system just because a developer says to, though.
In many cases, it’s better to devise the new business processes first and then assess the needed changes in your information systems architecture. Properly implementing a new business process automation solution might involve changing multiple systems. Thinking about who will use the system and how they will use it to do their jobs will help you define the correct user requirements, which in turn will maximize user adoption of the new system. Concurrent development of new processes and new applications help ensure that the two merge nicely.
Author Bios: Joy Beatty is COO at ArgonDigital, www.argondigital.com. Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.
Sources
[1] IIBA’s Business Analysis Body of Knowledge (IIBA 2009)
[2] Reengineering the Corporation: A Manifesto for Business Revolution (HarperCollins, 2006) and
[3] Sarah K. White. “What is process improvement? A business methodology for efficiency and productivity.” CIO, August 27, 2019.
[4] https://www.gartner.com/en/information-technology/glossary/business-process-management-bpm retrieved 10/19/2022
[5] https://www.bpmn.org/ retrieved 10/19/2022
[6] Visual Models for Software Requirements (Microsoft Press, 2012) Joy Beatty and Anthony Chen
