Modeling the Business Process

With low risk and high ROI, the executives at the organization approve the proposed project. The business analyst is now ready to model the business process, and names the business process Expense Reimbursement. This name reflects the fact that the objective of the business process is not simply for employees to report expenses, but for the company to reimburse employees for the valid expenses they incur while conducting business for the organization.

The next step is to separate the business process into separate activities. The business analyst answers the question Who does what? The answer to this question identifies the following roles:

• Submitter

• Reviewer

• Payer

The business analyst also identifies the following activities that can occur in the business process:

• Submit expense report, accomplished through a task

• Review expense report, accomplished through a task

• Pay expense report, accomplished through a business service

A favorable candidate for a business service must work as an independent entity to make sure reusability is possible. It is recommended that you use comments to document this business service to support other developers who must use the code. It must also follow a standard naming convention to make it easier for others to view the structure and understand what is happening in the code.

A favorable candidate for a task supports the entire business process and guides the user in performing the user role in this business process. The task must be clearly structured to make it easy for others to follow and understand.

The business analyst makes the following observations:

• Submitting an expense report is difficult to automate, so the analyst identifies it as a candidate for task.

• Reviewing an expense report is a candidate for automation. To minimize the risk of fraud, the business analyst notes that different users can repeat the task through an approval chain.

• The Oracle Accounts Payable (AP) application that the organization currently uses can automate the pay expense report, so the analyst notes it as a possible solution.

Creating the Draft Model

To finish the first iteration redesigning the business process, the analyst defines it as a Workflow Process, and then meets with the usability analyst and the application developer to gather feedback. The business analyst models the business process as a long-running Workflow Process. The following figure shows the steps in the Workflow Process (which is not yet executable), and the steps are as follows: Start, Submit, Review, Pay, and End. The illustration serves as a way to communicate the design intention with other team members when accompanied with notes from the analyst.

Other team members notice that the model is not finished because the business logic for the approval is not clarified. For example, when is a single approval sufficient, and when are more approvals required for a single expense? Also, the team notices that the model does not cover the situation where a review step finds that the expense report is ineligible and Siebel CRM must reject it.

The business analyst modeled the Workflow Process, so the application developer can refine the model. The following figure shows the revised prototype that the developer can refine into an executable Workflow Process and it includes the following steps:

1. A Start step.

2. A Submit step.

3. A Needs Further Review? decision step.

   1. If Yes, then continue to step 4.

   2. If No, then go to step 6.

4. A Review step.

5. An Approve decision step.

   1. If Yes, then return to step 3.

   2. If No, then the Workflow Process stops.

6. A Pay step.

7. An End step.

At this point, the developer and the usability analyst possess a thorough understanding of the business process for expense reimbursement.

Next, the application developer creates an executable Workflow Process.