OSF 4: How to handle Users and Roles in an OBA
[OBA Solution Framework Index]
Consider a team that is trying to deliver an OBA for a particular business process (e.g. to manage procurement). This could be an internal in-house IT development team building a standardized business process for enterprise-wide deployment, or it could be a solution provider who is building a packaged application to sell to customers. In either case, development of the OBA is a separate, decoupled activity from actual deployment of the OBA. So the solution provider will not know the end users at the time that the solution is being built. Instead the solution provider should work in terms of personas and roles, and package OBA artifacts (e.g. document templates, reports, dashboards, actions, workflows) accordingly. Doing this in the form of an OBA actually makes it easy to customize the business solution at the time of deployment, to manage change post-deployment, and for end users to personalize the solution extensively at any time.
In most business processes, people and systems interact by exchanging documents.
It should be straightforward for a business analyst to identify the roles that make up the process, and to create personas for these roles. For example:
Name: Alicia Role: Purchasing Agent
“I order materials and supplies. I follow up on PO confirmations and partial receipts. I also research suppliers to get the best quality products at the lowest price.”
Name: Eduardo Role: Order Processor
“I am responsible for the physical entry of orders as well as other sales support tasks. I take orders passed to me by the sales rep as well as repeat orders directly from customers.”
For each persona, it should be possible to inventory their needs for this business process:
- Document templates (e.g. forms, spreadsheets)
- Metrics, reports, dashboards
- Workflows
- Task lists
- List of alerts / exceptions / notifications to be monitored
These artifacts can be built into a set of role specific SharePoint personalization sites - one for each persona. These sites could then be packaged as a set of Site Template files (i.e. .stp files) that make up the business process. During deployment of the solution at the end customer site, the SharePoint administrator would deploy these site templates, and then create personalization sites from these on the shared services provider using the admin console.
What is the advantage of this? This allows end users to automatically discover links to role specific sites on their personal 'My Site's. This can be set up after deployment, by the SharePoint administrator, who would set up 'audiences' that map to each role in the deployed solution through rules on properties stored on User Profiles. Then the personalization sites could be configured through the admin console, to automatically appear on 'My Sites' for those users who fall in each of the configured 'audiences'.