Gathering Information for Defining Processes and Sub-Processes

Automation is one of the primary goals of Business Process Management (BPM). Another goal is documenting the target process workflow at a sufficiently low level of detail to identify observation criteria for measurement of task activity; this enables control of process repeatability through limitations on undesirable process variation, and allows monitoring of process performance and status through collection, analysis, and reporting of metrics. As metrics are collected, data trends can be identified and evaluated to determine if there are any opportunities for continuous process improvement.

This article focuses on the techniques for applying the appropriate level web-based automation mechanics using a form for data entry and tracking/routing. Techniques are described for gathering and using the correct scope and level of data from the appropriate sources to automate a process. These same techniques can be applied for gathering information to re-design a process.

The Role of Process Diagrams in Automating Paper-Based Forms

Process modeling diagrams are used to illustrate how to manually execute a process as it currently exists ("As-Is" workflows), and to illustrate how to automate a future process with required improvements applied to it ("To-Be" workflows). Paper-based data entry forms are converted to automated data entry forms only after customer and stakeholder requirements have been identified and verified. Neither the "As-Is" nor the "To-Be" automation workflows include "how-to" details for executing forms-based process activities. Task level information is gathered from those in the organization who have the most knowledge about how to execute the "As-Is" process.

Interviewing Process SMEs to Establish "As-Is" Workflow Information

To be considered a Subject Matter Expert (SME), a person must work with the target process on a routine basis, be considered by both peers and managers as a leader in his or her field, and be recognized as the authority on all aspects of the target process. A SME should know what documented information provides the mandate for the process, and what documentation exists to structure and describe desired process performance.

Always select more than one SME and identify alternates whenever possible. Although you should ask managers for recommendations for SME's, screen potential interviewees before convening process interviews to identify strengths and weaknesses in what they can communicate about the target process.

Involve the whole Business Project Management Team (BPMT) in selecting SME's; team members who will be conducting follow-up interviews should have an opportunity to provide input into the selection process. While selecting interviewees, obtain and review any documentation on the target process to help in formulating questions for the interviews.

Schedule two-hour interviews at least two weeks in advance. Meetings lasting longer than two hours per session tend to impede the effectiveness and efficiency of the information gathering process.

In advance of the interview meeting, provide each interviewee with a list of the questions you intend to ask to help focus their input and to set the expectation of the type of information you will be asking them about.

Convene several SME's together in one session to gain from their individual experiences and knowledge to avoid one-sided responses; they may also have different experiences with the same process that may be external to your immediate organization. Also, do not allow one or another person to dominate the session.

The definition process starts with identifying all enabling functions followed by task identification for each function. Metadata for each process function and each task do not have to be characterized until the priorities for further process decomposition have been set.

During interviews with SME's, gather as much information about business rules and requirements driving the activities included in a given process. Identify the source of the rules and requirements as well as the level of compliance with them. To ensure that any requirements gathered during SME interviews are documented, use the Requirements Traceability Verification Matrix (RTVM) format. The RTVM will be handed off to process re-design analysts to be completed with details on full capability process functions.

Inquire about the current health of the entire process. Identify process bottlenecks, especially those that occur in conjunction with milestones associated with data entry forms-based sub-processes, and changes in life cycle states in those sub-processes. A primary objective is to determine if the bottlenecks are associated with acquiring data for entry into the forms, availability of information needed for forms completion, or whether the form needs to be re-designed because it still requires input using out-dated data or data requirements that are newer than the form. Identify bottlenecks involving information not associated with a particular form.

Identify and Review Requirements

Requirements may originate from different sources and may be a mixture of official and unofficial requirements. They may also be temporary or permanent in implementation. They may include technical requirements, and they may be business requirements. In most cases, the SME's will only know about business requirements if process information resides primarily on a hardware/ software system; in that case, they should also know about system processing and response capabilities, capacities, and availability.

Consider the reasons why each requirement is included in the process. Whenever a mandated requirement has been implemented only partially or not at all, be sure to obtain and cite official documentation that waives the organization from implementing it.

Become familiar with existing documentation on a process prior to scheduled interviews so you can formulate follow-up questions about the extent to which requirements are actually implemented and why there are problems implementing some requirements. Do not turn the SME Interview into a requirements review session, but use the requirements to identify specific sources of information that must be gathered by an automated data entry form; obtain the location of documents and determine how you can get access to them.

It's quite possible you may not identify all requirements during the first session. Explain that additional time will be needed to finish identifying the requirements. Obtain an idea of what requirements still need to be identified and determine which SME knows the most about the identified requirements. Obtain a commitment from the best qualified persons to provide specific information about the additional requirements for the next interview session. Remember to gather requirements that characterize the need for activities for the entire process under review as well as for functions that support mostly or only form completion activities.

During the requirements identification process, keep in mind that the automation project involves identifying manual processes that can be transferred to a hardware/software system environment. When manual functions are identified that can be replaced by an automated form or systems-based routing/tracking, functional requirements (activities and attributes allocated to system capability) will need to be derived that characterize what functionality must be performed by the system.

Clarify Requirements and Prepare Work Flow Diagrams

Present the business requirements and any derived functional requirements to the SME's in a follow-up meeting designated to review the requirements. Organize the requirements by target process function, indicating which functional requirements are derived from which business function. Obtain consensus on the requirements statements. A good technique for organizing and documenting requirements is to present them in a Requirements Traceability Verification Matrix (RTVM). The RTVM allows you to document the source of each requirement as affects development and implementation of the automation process in each project work document or customer deliverable.

In addition to establishing the baseline for the "As-Is" process diagram, the benefit of defining the process to the functional level is for identifying paper-based forms that need automating. Since the use of a form may include one or more process functions, it is necessary to collect metadata that enable validation and verification of data sources within each affected process function.

Not all process functions require exchange of information within forms-based sub-processes. It is important to characterize the boundaries of all functions to identify which sub-process activities involve manual operations that can be automated through the use of an electronic data entry form.

Figure 1 illustrates the contact points between a larger process (Peer Review Process) and the sub-process (Software Product Evaluation) SPE form. The SPE has a life cycle process that is separate from that of the larger process.

The SPE form, an electronic data entry form, shown in yellow process flow icons in Figure 1 illustrates how only some steps of the wider process actually involve exchange inputs and outputs with the SPE. Only 6 of the 16 tasks in the Peer Review Process involve the use of the SPE shown in Figure 1. In some cases only one or two steps in a task involve use of the form; in other cases, all steps in a task are involved.

The purpose of presenting this figure is to emphasize that data entry form automation is a part of a larger process. If the form is automated without acknowledgement of the boundaries of the larger process, the automation project may or may not be successful. The greatest risk to implementing a successful automation is the inability to verify the source(s) of supporting information. Also, another objective of implementing a BPM methodology is to provide a source of information for collecting and analyzing data for continuous process improvements. To validate and verify data needed to support the development of automated forms, it is necessary to decompose relevant process function information to a low level, to the "how-to" level.