A business process analyst, business analyst or systems analyst is used to review the business process if a new system is about to be built; or, massive changes are about to be made to an existing system. This post focuses on documenting the business process associated with implementing a new or updated system. The topics that will be discussed are gathering business requirements, documenting business requirements, tracing business requirements and generating the data dictionary.
Gathering Business Requirements
When defining a new system or system updates; the business process analyst will typically review the business process steps as they are performed by the worker. Some organizations use MOST work measurement to not only capture business process steps, but determine the amount of time it takes to perform each step. This information is then used to define the exact number of people needed to complete a job within a specific time-frame. However, for Information Technology projects MOST work measurement is typically not used because companies are looking at the process steps and related information; usually, they aren't looking to assign time values to the process.
To review the business process the business process analyst may be tempted to want to "talk" to individuals to capture this information. But there are one of two approaches that will guarantee the information documented is accurate:
1. Review & Validate a business process already documented: If the business process has already been documented; the business process analyst may ask for a copy of the document. Next, ask a worker if you can shadow him/her as the worker performs the process one time. This provides an opportunity to validate the accuracy of the business process document. In other words, determine whether or not some of the process steps have changed since the document was written. If so, update the document to reflect the changes and circulate the updated document for review.
2. Document a business process that has never been documented: If the business process has not been document the business process analyst should shadow a worker and watch as the worker does his/her job. The business process analyst will watch closely and ask questions as the worker performs the process steps necessary to complete the task. The business process analyst will ask about the business rules applied, software used to capture data (inputs) or generate documents (outputs). The business process analyst will also capture the process flow. The benefit here is, if a new business software is to be built it can be built to support the existing process so the business process changes very little. This means instead of the process changing, the tools used to perform the business process changes. Or, if the business process will change, the process changes can be documented so workers can do their job once the new/updated system is implemented.
The following sections provide one way to document the business process, business rules, inputs, and outputs.
Documenting Business Requirements
Business requirements are typically documented in the form of business rules. But, capturing the business process provides more than just business rules. You will also document business process steps, inputs and outputs. The inputs and outputs typically provide requirements used to define reports or user interface fields. These elements are ultimately used to define database table fields and the table field relationships needed to generate the outputs.The document reflecting the current business process is the As-Is business process. After stakeholders/users discuss how they would like to do business with the new/updated system in place; you will need to write the To-Be business process document.
In the following As-Is example, Company "A" users upload enhancement requests to a shared drive to request changes to the company's software product. This section provides a high-level overview of the current business process, the actors, and process owners. The To-Be Business Process Operations Report outlines how the business process is performed with the new/updated system in place.
Input Documents
Document Name
|
Description
|
Step ID
|
Notes
|
Enhancement Request
| The Enhancement Request is currently created using an Exchange Form. The re-engineered process will need to store each request in a database. Users will be able to submit these requests online using the updated system. |
Step 1
|
(For the TO-BE environment, the customer wants a document library using content types so that all related documents for an Enhancement Request are centralized and easily accessible. )
|
| Impact Analysis Report | The analyst emails a copy of the Impact Analysis report to the CCB reviewers. | Step 2 | A COTS will be used for the TO-BE environment. |
| Test Documents | Step 4 | ||
| Release Notes | The Technical Writing Department is responsible for updating the Release Notes and uploading the document to the shared drive. The path is sent to Product Support and the Deployment team. | Step 4 |
Output Documents
Document Name
|
Description
|
Step
|
Notes
|
| N/A | Currently there are no outputs. The TO-BE Business process should include information on the reports to be generated for the new process. | Step 5 |
Sub-Process Operations
In this example, the BSA uses a separate process to create the Impact Analysis report. Therefore, a Sub-Process Operations report would be created to capture the steps. The ID of the Sub-Process Operations Report would include the Parent ID and the step number (i.e., Business Process ID: 2237.2). The business rules, inputs and outputs would also be captured.
Generating the Data Dictionary
Once you have documented the inputs and outputs, it's a good practice to create a data dictionary. At a minimum the data dictionary should include the element name (such as Enhancement ID or user ID), description, whether or not the element is required, the data length based on any forms and/or business rules, data format (for example dates must be mm/dd/yyyy), data type (i.e., date, string, etc.). Following is one example of a data dictionary. Microsoft Press published a book titled "Software Requirements. It also includes an example of a data dictionary.
Business Process To-Be Report
To capture the To-Be business process requirements stakeholders should review how business is currently done. In addition, a list of current business problems is also captured. The Analyst should look for opportunities in which automation can help the business process become more efficient. And, users and stakeholders should be prepared to discuss problematic areas. All of this information can help the organization look for opportunities to improve the way business gets done.
Business Process Flow Diagram
Another way to capture the business process is to create a business process flow chart, which uses symbols to define the business process. The following picture shows the As-Is business process used to Bill Customers.
In the previous process flow diagram the process begins with the IT Department. The rows shown on the process flow diagram includes horizontal swimlanes. A swimlane is the rectangle that depicts an actor. A swimlane can be horizontal or vertical depending on the number of actors and number of process steps. The shapes inside the horizontal swimlane depict the process start, process documents (i.e., complete timesheet), sub-processes (i.e., Process Customer Bill), process decisions (i.e., approved?) and process end.
