In this step we will model the requirements as workflows, user stories and process indicators.
Model the Service Process Workflow
Given the requirements document from your business analyst, create a process model that looks as follows. It captures who (role) does what (activity) in what sequence to accomplish the outcome.
Workflow diagram for birth certificate registration
Start by identifying the users. The users could be citizen, vendor or employee. Its important to identify the roles the users are playing e.g. in the above the citizen is the "Applicant", Vendor is the "Verifier" and Head of Department is the "Approver".
For each role draw a swim lane (gray horizontal bar in the above diagram) which contains all the activities (boxes and rhombus). The activities should ideally be expressed as "Verb Noun" pattern e.g. Pay Charges, Verify Application and so on.
Activities can be elaborated in two ways - as a user story or a use case. User Stories are informal way of expressing what the user wants e.g. “As a [persona], I [want to], [so that].”
As an Applicant, I want to be able to provide enter the form as quickly as possible. I want to know the process and when the certificate will be available to me.
Use Case is more formal way of capturing exact steps and alternate flows the user can follow e.g.
The Applicant logs into the system by entering user name and password. The applicant then enters the following fields - child's name, mother's name, father's name, date of birth, place of birth. All these fields are mandatory.
If you are following an agile process then the user story based approach works fine. Agile also works well when you are not clear of the end outcome and want to iterate. However, if you are clear what you want and also want to avoid too much back & forth communication between the product and engineering team during development with predictable outcome then go with the use case based approach.
Elaborate Process Performance Indicators
Identify the process performance indicators that an administrator may want to see to monitor and identify areas of improvement. Example, the administrator may want to see the following metrics and compare them over various time periods and administrative hierarchies.
- 1.Number of Applications
- 2.Number of Application by Status
- 3.Average Time to Delivery the Applications
- 4.Average Time by Status
- 5.Average Feedback
- 6.Number of Complaints
- 7.Number of Complaints by Status
- 8.Average Time to Resolve Complaints
- 9.Number of Reopened Complaints