Requirements for Business Process Automation

Key ideas#

What is different about this kind of project#

The starting point is a process, not a list of features. You model how work is done today (as-is), find where automation helps most, design how work will be done (to-be), and specify requirements step by step. The organization must also change how it works, and software alone cannot make that happen.

Untangling the acronyms#

The authors distinguish overlapping terms: - BPA, business process analysis: understanding processes as a basis for improvement. - BPR, business process reengineering: redesigning processes, in part or across the organization. - BPI, business process improvement: measuring and optimizing step by step, often with Six Sigma or lean. - BPM, business process management: defining and managing all of an organization’s processes; it can combine the three above. - BPMN, Business Process Model and Notation: a notation any of them can use when basic swimlane diagrams are not enough.

Eight steps from process to requirements#

The sequence is not always linear, and not every step is always needed: 1. Link business objectives to processes. 2. From the organization chart, identify the departments and user classes involved. 3. List every process these user classes take part in. 4. Model the current processes with flowcharts, swimlane or activity diagrams. Users quickly spot wrong steps, roles or logic. 5. Analyze them for the biggest automation opportunities, using performance measures, so you fix the real bottleneck rather than the first one you see. 6. For each process to automate, walk through it with stakeholders and elicit requirements for each step. 7. Trace requirements to process steps. A step with no requirements is either missed or deliberately left manual. 8. Model the future processes to prepare the organization, find gaps, and define transition requirements and training.

Process first or system first?#

A common mistake is to expect a new system to change processes and culture by itself. Software cannot deliver cultural or training changes, yet customers often expect the development team to own them. The authors suggest designing the future processes first and then assessing which systems need to change (possibly several), developing processes and application in parallel so they stay aligned.

KPIs on process steps#

In Beatty and Chen’s key performance indicator model (KPIM), you attach key performance indicators (KPIs) to specific steps of a process diagram. Record each KPI’s current value before automation so you can measure the real improvement. Improving one measure can worsen another, possibly in another part of the organization: the same kind of trade-off as between quality attributes.

When not to automate#

• The authors describe a company that wanted software to help staff find the right colleague through an intranet with stale contact data. The real problem was the lack of a process for keeping contacts current. Making someone responsible for updates solved it without new software.
• In another case, a manager’s manual task of about 30 minutes a week cost less than building automated decision logic, so it stayed manual.

Not everything that can be automated should be.