We’ve all heard this one: “Don’t automate a process until you optimize it.” That’s sound advice to avoid automating unnecessary steps or, worse, institutionalizing a completely broken process.
In the real world, though, business sponsors often are unwilling to embark on a lengthy business process optimization or re-engineering effort before they begin requirements gathering. At times the best that can be hoped for is to model the business process being considered for automation, and rationalize the process within the time limits given.
Having the business processes diagrammed for reference within a requirements document package reaps numerous benefits:
- It provides context to the software developers and designers, helping them understand how the steps being automated will fit into the overall business process
- It is the basis for validation that each step adds value, even when there is no time to complete a long reengineering or optimization effort
- People understand things in different formats, so while some of the audience will best understand verbal lists of requirements, others will respond to the visual depiction of a process model
- It serves as the basis for further process improvement or re-engineering efforts
- It is the first layer of traceability for the software development lifecycle
Modeling the Process
Business Requirements come in many forms, from hastily scribbled wish lists thrown over the transom to the developers, to monolithic Word documents that wade far into the technical weeds. Someone facilitating the elicitation of requirements can use process modeling to begin the discussion, and keep the business focused on the functions it needs to perform. This allows the business to concentrate on what is needed, and lets the software designers determine how those needs will be fulfilled.
As a requirements team works to understand and document the process in question, make sure a full picture of the process is illustrated, not just those steps expected to be automated. An overall process flow provides necessary context around the goals and objectives of the business. It may even uncover assumptions about steps that can be automated that haven’t been considered.
A simple workflow, with or without swim lanes, can be taken to the level of detail needed to fully describe the functions in view. Functional decompositions can be used in addition to, or instead of, a workflow. Either method allows the focus to remain on the functions to be translated into business requirements.
Validating and Rationalizing
Once a process model has been completed, have it validated by all groups represented in the swim lanes. It will be tempting to eliminate what appears to be low hanging fruit and do “just a little” optimization. Proceed with caution until there has been sufficient analysis of the upstream and downstream impacts of these changes. However, it’s fine to probe the business on why each step is performed. (Asking why five times can come close to the root cause.) If the answers are “because we’ve always done it this way”, or (especially) “this is a work-around because our old system couldn’t do this function”, there may be opportunities for careful elimination of non-value added steps before proceeding.
Adding the Technology Layer
There are several ways to add system information to a process model. For example, color code the steps that are in scope for automation, and indicate on the connectors whether the inputs and outputs will be human data entry, system-to-system interfaces, reports, extracts, etc.
Alternately, swim lanes showing each major system can be included, showing inputs and outputs.
When choosing a functional decomposition diagram, take it down to a level that is discrete enough to detail which steps will be automated and where the interactions will be.
Be cautious about stepping too far over the technical design line. This discussion is about business processes, not technical or system processes. Collaborate closely with the technical team to ensure that design assumptions aren’t part of the process documentation. However, indicating those parts of the process that are in scope for automation can be a valuable part of stating assumptions up front for further discussion and negotiation.
Tracing Requirements to Process Steps
Once the process model has been validated, and there is as much certainty as time permits that only value-added steps remain, creating requirements is easier. The lists can flow from, and be organized within, the higher-level models. Detailed requirements arise from drilling down into each of the steps, thinking through what is needed to complete the steps. Trace each requirement to the process step that it supports. If there are requirements without steps, it may indicate either that the process model is incomplete, or that the requirement is extraneous. If there are steps without requirements, verify that the list of requirements is complete.
The traceability matrix, by the way, easily extends beyond showing the relationship between requirements and process steps. Continue to use it throughout the development life cycle of any technology project to note relationships between requirements and Use Cases, Test Scripts, and design and code components.
Leverage Process Models for Use Cases
Use cases can flow logically from the business process model. While some believe that Use Cases are technical documents, the International Institute of Business Analysts (IIBA) recommends that these be completed by the business rather than IT. Like a business process model, the focus is on how the user (actor) interacts with the system and how the system responds to the user, not on the calculations, system to system interactions, and database activities that happen on the back end.
Requirements gathering is a collaboration between the business and software team. A business process model can serve as an important tool to foster the communication needed for a development project to succeed.
