3Scenario for Developing a Task UI
Scenario for Developing a Task UI
This chapter describes a scenario for developing a task UI. It includes the following topics:
Overview of Scenario for Developing a Task UI
The example in this topic describes how to develop a task UI. The scenario describes work that the following individuals perform:
Business Analyst. Possesses detailed knowledge of the way the organization does financial planning and reporting. The analyst possesses detailed knowledge of various technologies, from personal computers to mobile personal devices, but possesses no experience using a formal programming language.
Application Developer. Possesses a computer science degree and a strong technical background, including five years experience creating applications.
Usability Analyst. Possesses a degree in art history and a technical background, including five years experience designing interfaces. In the last two years the interface developer created user interfaces for various customizations of a predefined Siebel application.
Information Technology Director. Drives the business process management initiative at the organization that optimizes and automates business processes.
This chapter describes job roles in the context of a fictional organization. Job roles, job titles, and division of labor might vary significantly for your organization.
For more information about:
General technical procedures, see Roadmap for Developing a Task UI.
Specific technical procedures, see Examples of Developing a Task UI
About Iterative Development
To minimize the risk of project failure, your development process can be iterative and incremental. Using an iterative technique means feedback from a phase can cause reiteration of a previous phases. For example, a significant performance issue might require a UI redesign that causes a reiteration of subsequent phases.
Using an incremental technique means that the best way to mitigate the risks of using new technology, such as Siebel Task UI, is to begin with a smaller scope, deliver it to customers, and then use customer feedback to incrementally create functionality. For brevity, this chapter does not fully describe iterations and incremental releases. However, most implementations include iterations and incremental releases, and it is recommended that you plan for them.
Example of Developing a Task UI
To develop a task UI, do the following tasks:
Determining Improvement Requirements
This task is a step in Example of Developing a Task UI.
The meet for a brainstorming session where they list on a whiteboard the business processes for the organization that are in their purview. They then assess the best candidates for process improvement and determine that the main criteria include the following items:
Return On Investment (ROI)
Risk
The IT director and business analyst do a careful examination, and then pick the expense reporting and reimbursement business process as a candidate for a task UI. They choose this business process because it includes a common, irregularly run job task that most employees perform.
This business process is relatively simple and well defined, making risk and investment low. The IT director and business analyst are aware that the current way of handling this process, through email and spreadsheets, is labor intensive and error prone, making the process expensive and slow. This situation makes potential ROI very large.
The IT director and business analyst estimate they can realize the following improvements:
Cut costs by 30%.
Speed up the process by 400% from the current median time of 12 days to 4 days from submission to reimbursement.
Save the company $200,000 each year through better enforcement of company reimbursement policies.
To achieve these improvements, you can use various Siebel technology to automate a part of the process, and you can use a task UI to guide the manual part of the process and enforce rules.
Designing the Task UI
This task is a step in Example of Developing a Task UI.
To design the task UI, the business analyst begins by modeling the business process.
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 UI
Review expense report, accomplished through a task UI
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 UI 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 UI.
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 UI 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 uses the Workflow Editor in Siebel Tools to model the business process as a long-running workflow process. The following image includes the workflow process that is not yet executable. 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 in Siebel Tools, so the application developer can refine the model. The following figure includes the revised prototype that the developer can refine into an executable workflow process. 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.
Creating an Executable Workflow Process
The business analyst used Siebel Tools to model the business process, which saved the application developer time because the developer can use the model that the analyst created as a starting point for iterative refinement. The application developer notices that, although logically it belongs in the business process model, the team must remove the submission task UI from the executable long-running workflow process because it must start the workflow process. The submission task must pass the ID for the expense report as an input argument. The developer decides to reuse the Object ID process property that the developer defines as an input argument to the workflow process. The developer communicates this refinement to the business analyst.
Next, the developer considers the Decision step that determines if further review of the expense report is required. The developer determines if it is best to call a business service that is dedicated to enforcing the review decision. The developer examines the Review task UI and realizes that Siebel CRM must assign it to a reviewer before Siebel CRM can instantiate it. The reviewer can use a business service step to call the Assignment Manager. This step resides immediately upstream of the review task. The following image includes the executable workflow process.
These revisions to the draft business model help to illustrate the differences that exist in the level of abstraction between a business process model and an executable workflow process. The application developer continues to refine the workflow process. For example, creating conditional branches, process properties, input arguments and output arguments, and then testing and deployment, until the team is ready to implement the workflow process in a production environment. For more information, see Siebel Business Process Framework: Workflow Guide.
Next, the business analyst identifies the context for the task UI.
Identifying the Context for the Task UI
The business analyst must refine the task UI. The analyst begins by identifying the context for the task. The application developer notifies the business analyst that the submission task UI starts the long-running workflow process, so the analyst realizes that the user must manually start the submission task in a standard view. The analyst also realizes that most employees will frequently do this job task.
For these reasons, the analyst decides the development team must add the submission task UI to the Common Tasks task group, and concludes that the submission task does not require context passing. The context is the current record. For example, the record being submitted. The task UI that submits the record does not need to pass information about the submitted record to the next step in the business process.
The user must be able to frequently pause this task UI. For example, to provide the user a moment to find required documents. So the analyst decides that the task must use the description for the expense report as the value of the Context field in the Universal Inbox. This configuration allows the user to distinguish between different instances of the same task.
The analyst notes that Siebel CRM opens this task UI from the long-running workflow process, so the user opens it from the Universal Inbox. For this reason, the analyst does not add the review task UI to a task group. The review task does require that Siebel CRM pass an expense report number as an input argument. A Boolean value named Approved seems to be an appropriate output argument. The appropriate context for the Universal Inbox is a concatenation of the total amount for the expense report and the name of the submitter. For example, $450.00 from Aaron Jones.
Next, the usability analyst designs the task UI.
Designing the Task UI
The usability analyst now identifies activities in each task UI, and creates a prototype for the task. The Submit Expense Report task UI includes the following activities:
Create expense report header.
Create expense items.
Review and submit the expense report.
The usability analyst uses the Task Editor in Siebel Tools to model the task UI. The analyst defines the three activities as three separate task view steps. The analyst is not familiar with the View and Applet editors, so the analyst enters only the view step names without linking the view steps to the task views. These views do not yet exist.
The other task UI that reviews the expense report is a simple task UI. It requires only the Review Expense Report task view step.
For an example that includes view mockups that assist with designing a task UI, see Example of Developing a Task UI That Assists with Creating Multiple Opportunities.
Next, the usability analyst refines the task UI.
Refining the Task UI Design
At this point, the usability analyst is ready to work with the application developer, who is familiar with the Expense Report business object and the underlying data model for the objects. Together, they sketch the view layouts on a whiteboard. The application developer identifies the business components and applets that the Submit expense report and the Review expense report task UIs require.
The team must determine whether the user must create all expense items in the same view, or create each item in a separate view. The business analysis indicates that most users do this job task frequently. The business analyst and the usability analyst agree that productivity is more important than UI simplicity, and they conclude that the user must create all items in the same view. As an advantage of this hierarchical technique, the usability analyst realizes the possibility of reuse for two applets in two similar views. The third view that resides in the submission task UI displays the same data that the view that resides in the review task UI displays.
Developing the Task UI
This task is a step in Example of Developing a Task UI.
To begin developing the task UI, the application developer creates the task.
Creating the Task UI
The application developer does the following work to create the task after the team reaches consensus on the task view layouts for the task UIs:
Makes required additions and modifications in the configuration for the business logic.
This configuration might include the business object, business component, links, picklists, and so on.
Creates or reuses the required applets.
Creates or reuses the required task views.
Next, the application developer refines the task UI.
Refining the Task UI
The application developer does the following work to refine the task UI:
Add links to the new task views.
Adds an insert Operation step before the first view in the submission task UI.
Adds an update Operation step after the task view step in the review task UI.
Reviews and updates properties and multivalue properties for task steps.
Makes sure that the task UI contains no validation errors or warnings, including setting the Instance ID task property that the business analyst identified.
Next, the application developer creates the task group and deploys the task UI.
Creating the Task Group and Deploying the Task UI
The application developer does the following work:
Creates a relationship between the submission task UI and the Common Tasks task group.
Recompiles the SRF (Siebel Repository File) with the new UI configuration, including the task group update.
Clicks the Publish and Activate button to deploy the submission task UI to the development environment.
Next, the application developer sets up access control.
Setting Up Access Control
The application developer does the following work:
Makes sure the responsibility for the test user possesses the visibility to run the submission task UI. For more information, see Adding a Responsibility to a Task UI.
Makes sure the Siebel client displays the customizations in the Siebel Mobile Web Client that Siebel Tools opens after the developer publishes and activates the customizations.
Testing the Task UI
This task is a step in Example of Developing a Task UI. The application developer begins with unit testing.
Unit Testing
Siebel CRM displays the Submit Expense Report link in the context pane. If the user clicks this link, then Siebel CRM displays the first view of this task UI. The application developer is excited, but this joy is spoiled by the fact that the developer failed to include an Expense Description field in the Expense Header Applet. Several iterations later, the developer demonstrates the submission task UI to the business analyst, who is pleased, but who also notes that there are a few details that require refinement. Finally, version 16 of the submission task and version 22 of the SRF is ready for integration testing.
The review task UI is more difficult to unit test because it requires tight integration with a long-running workflow process. The task UI is relatively simple, so the application developer defers unit testing for the review task until the team integrates it with the long-running workflow process.
Next, the application developer does integration testing.
Integration Testing
Testing for the entire business process includes the following work:
Publishing and activating the latest versions of the task UIs
Publishing and activating the latest version of the long-running workflow process
Compiling the latest UI configuration to the SRF, including business layer configuration modifications
To test the configuration in the development environment, the application developer uses the Siebel Server and the Siebel Web Client because a long-running workflow process cannot run on the Siebel Mobile Web Client. The developer uses the Task Debugger to analyze any defects that exist in the task UI logic.
Next, the application developer performs system testing.
System Testing
If the configuration appears to satisfy the business requirements, then the application developer uses Application Deployment Manager (ADM) to migrate the entire configuration to a test environment. ADM typically includes migration of new or updated LOVs that a task UI uses. The developer verifies functionality, and then tests performance and scalability.
Implementing the Task UI
This task is a step in Example of Developing a Task UI.
The team implements the new task UI and the long-running workflow process in the production environment. This work is best performed as part of a system wide configuration upgrade, because new functionality typically requires SRF modifications and some server downtime.