Siebel Business Process Framework: Task UI Guide > Implementing Task UI > Scenario for Iterative Development of a Task UI Implementation >

Modeling the Business Process

Given the low risk and the high ROI, Acme executives easily and quickly approve the proposed project. User A is now ready to model the business process the company is about to modernize. After some analysis, she decides to name the business process Expense Reimbursement. The 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 have incurred while conducting business for Acme.

The next step is to break down the business process into separate activities. An experienced business analyst, User A tries to answer the question: Who does what? Her answer to that question identifies three abstract roles involved in this business process:

• Submitter
• Reviewer
• Payer

She also identifies three kinds of activities within the business process:

• Submit expense report (a task).
• Review expense report (a task).
• Pay expense report (a business service).

Submission is difficult to fully automate, thus it is easily identified as a task. Review is a candidate for automation, but to minimize the risk of fraud, User A decides (at least for this iteration) to also make it task. She also makes a note that this activity may be repeated several times through an approval chain. The third activity can be automated easily through integration with Acme's Oracle accounts payable (AP) application, so it is tagged as a business service.

Reviewing the Draft Model

User A has finished the first iteration of the business process model, so she meets with User B to get his feedback as early as possible.

User A has used the Process Designer in Siebel Tools to model the business process at hand as a long-running workflow process. This process (shown in Figure 9) is not yet executable, but (accompanied by her notes) it serves as a clear communication vehicle for sharing her analysis with User B.

Figure 9. Draft Business Process Model in Siebel Tools

Being detail-oriented, User B quickly notices that User A's model is incomplete, because she has not clarified the business rules that drive the approval. For example, when is a single approval enough, and when is it not?

User B also notices that the model does not cover a secondary scenario for which a review step finds that the expense report is ineligible and rejects it.

Because User A has modeled the process in Siebel Tools, User B is able to quickly help her refine the business process model during the review session. After doing this, he is ready to take over the process definition (the new version of which is shown in Figure 10) for further refinement into an executable process definition. By this point, he has developed a good understanding of the business process being automated.

Figure 10. Refined Business Process Model