Vous êtes sur la page 1sur 20

Service Provision Management System

Service Tracker for Advisory support services

Project Specification version 0.2

Last updated: 9/23/2011

Service Provision Management System Project Specification


Version History
Version 0.1 0.2 Date 18 July 07 24 July 07 Author GvM GvM Description Initial version Added estimated number of users and location

Page 2 of 20

Service Provision Management System Project Specification


Distribution List
Name, Job Title and Company Mads Svendsen, Mgmt Advisor, MCT Tina Friis Hansen, Coordinator, MCT Anil Soud, Advisor, Executive Office Thomas Eriksson, Planning Advisor, BoM Akiko Yuge, Assistant Administrator and Director Bureau of Management Mitchell Toomey, Chief, Portal and Web Services Unit OIST BRATISLAVA? BANGKOK, COLOMBO, PACIFIC? Sign off required Sign off required Distribution Requirement Signature Date

Page 3 of 20

Service Provision Management System Project Specification


1.0 Introduction
1.1 Project Overview
The main rationale for developing a Service Provision Management System is to ensure consistency and comparability of data related to the provision of Advisory support services in the organization. These advisory support services are delivered to Country Offices and other clients by global and regional advisors based in HQ and in Regional Centres. It is anticipated that this data can support the establishment of demand-driven budget processes for internal support services. This includes internal markets for the work of the global and regional advisors, to ensure their work is aligned with country office needs1. Currently different service locations have different tools in place to track the Advisory support services ranging from a manual Excel tool to a web-based service tracker. Not only do these tools differ in the functionality they offer, they also differ in the way in which data is captured which makes impedes data consolidation and comparison. To ensure consistent and meaningful data comparison, it is proposed to create a common template and platform for collecting the data related to advisory service provision. This platform can build on the tools that are currently available in the organization but should be developed as a corporate tool available to all service providers.

1.2 Project Objectives

Automate and streamline the process for tracking advisory service provision Ensure consistent and meaningful data collection related to advisory service provision Improve data quality related to advisory service provision Provide robust tools to report on different dimensions of advisory service provision Reduce human effort required to consolidate data on advisory service provision

1.3 Success Criteria

A single system developed and used in all service locations to track advisory service provision A reporting capability at the different organizational levels (including the corporate level) on advisory service provision Consistent data gathering across the different service providers

1.4 Project Team

Anil Soud

Mads Svendsen Thomas Eriksson

Internal market mechanism has been introduced in a message from Kemal Dervis, 4 December 2006 (message to all staff) Page 4 of 20

Service Provision Management System Project Specification


Georges van Montfort Mitchell Toomey

Page 5 of 20

Service Provision Management System Project Specification


2.0 Functional Specification

2.1 Functional Requirements
Data elements in the system interface needs to be tailored to the specific service provider: o Several of the drop-down selections need to be specific to the service provider (e.g. advisors that can be selected, clients etc) detailed list of these fields are provided in the annex Local Admin User in the service provider needs to be able to modify (i.e. add, delete, change) drop-down selections detailed list of these modifiable fields are provided in the annex Other selection fields are blocked and can only be modified by a Global Admin User Local Admin User needs to be able to modify local users (i.e. create, delete, change)

o o

Automate service request processing workflow from request to delivery and follow-up: o o o o o Local users of the service provider can create and change service requests After creating a request, the requestor user can view and edit the request Users can view requests related to their local service provider In the management view of requests, organize the requests by date, type, and country Provide printer-ready version of requests to support offline requirements

Provide sourcing management (assigning advisors to specific requests): o o o Certain users can assign advisors to specific requests The system will allow for last minute substitutions of advisor sourcing, given the dynamic nature of this process. Advisor users will receive an email indicating the request that they have been assigned to at the moment of assignment and after the assignment to be prompted to complete the request tracking Advisor users can view the requests that they are assigned to as well as other requests related to their local service provider

Provide master data entry to capture the expenses related to overall service provision i.e. operational management, and administration cost of the service provider o A master data user should be allowed to enter and modify costing data related to the management of the service provider (salaries, general operating expenses such as utilities and rent) Users can generate reports using menu-based search criteria selection Provide printer-ready version of reports to support offline requirements Page 6 of 20

Provide reporting ability based on multiple search values: o o

Service Provision Management System Project Specification


To view automated workflow for assigning advisors to requests, see section 2.4.

2.2 Design Assumptions

Two service providers (Bratislava Regional Centre and Bangkok/Colombo/Pacific Centre) have already developed elaborate Service Request Trackers and this new system should build on these experiences. Workflow as well as look-and-feel can be leveraged from these existing systems The system will provide tools for the local admin user to handle User Management. Note: Once the system has left the development stage the technical team is not responsible for the delegation of roles.

2.3 Role Profiles

The following table defines the permissions afforded for each role in the Service Provision Management System. A single user will be assigned at least one role, but there needs to be the possibility to assign multiple roles. Role Request-related Permissions Allowed to modify global drop-down selection boxes Design user roles Create/edit permissions for all users Allowed to modify local drop-down selection boxes Create/edit permissions for all users Notes

Global admin user

2 users

Local admin user

11 users Bratislava 90 users Bangkok 80 users Colombo 60 users Joburg 100 users Pacific 20 users Panama 80 users Trinidad 10 users Pretoria 5 users Dakar 25 users Lebanon 25 users NY 150 users 11 users 22 users 25 users

Advisor user

Create/edit/view/delete requests for the service provider the user is assigned to Assign requests to advisors Generate and view reports

Master data user Local report user Global report user

Create/edit/view/delete data related to the costing of the service provider Generate and view reports for the service provider the user is assigned to Generate and view reports for a specific service Page 7 of 20

Service Provision Management System Project Specification


provider or globally

Page 8 of 20

Service Provision Management System Project Specification


2.4 Role Permissions Request workflow including sourcing management

The system helps the user manage the request workflow from registering an incoming request to creating feedback as part of the follow-up. User roles in this respect are set up in a simplified manner in the sense that all activities in the workflow can be done by the Advisor user. The table below specifies the typical steps as part of the service workflow. Note that not all steps are applicable to all service requests e.g. a desk review- or referral- service will not need logistics to be arranged. Therefore some of these steps are optional (as indicated in the table below).

Step 1

Description Register Request (mandatory)

Notes Activities Confirm client need Identify key client personnel & decision-makers Log request Outputs Service request created in system Terms of Reference needs to be uploadable Activities Source Advisors Detailed scope of service Confirm schedule & timing Update service request Outputs Advisor(s) identified Activities Arrange travel (COA, flights, DSA, visas, hotel, security) Arrange mission logistics Update service request Outputs Requirements note Activities Review background materials and prepare service materials Meet/calls with client, and other relevant contacts Internal team meetings/calls as required Outputs Draft agenda Activities Client management meetings (optional) Confirm approach (optional) Page 9 of 20

Define Request (mandatory)

Arrange Logistics (optional)

Prepare Service (optional)

Conduct Service (mandatory)

Service Provision Management System Project Specification




Notes Deliver service (mandatory) Outputs Finalized agenda (optional) Working documents (optional) Activities Final review meetings (optional) Outputs End service action plan to client (optional) Service deliverables packaged to client (mandatory) Activities Client survey (mandatory) Update service request Outputs Feedback questionnaire Service deliverables uploaded into Service Management system (mandatory)

Complete Service (mandatory)

Review Service (mandatory)

2.5 Role Permissions Configuration

As indicated above, the system needs to be configurable in the sense that the options in several dropdown boxes can be modified. Two user roles are involved in configuring the drop-down selection criteria. The list of drop-down boxes, their values and type (i.e. global or local) is identified in the annex. 1. Global drop-down boxes certain fields will have to be consistent at the global level and will therefore only be modifiable by the Global Admin User(s). Examples thereof are service type and service area. 2. Local drop-down boxes certain fields indicate local selection criteria (such as advisor names, clients etc) and as such need to be modifiable by the Local Admin User(s). Their permissions should be limited to modifying fields related to their own service provider. No approval is needed to confirm the modified drop-down fields. The Database that stores the requests needs to keep the original value that was selected for that request. Therefore a log needs to be created in which the system tracks changes to the drop-down selection criteria.

2.6 Role Permissions Master data

In addition to capturing data related to individual service requests, the system needs to be able to capture information on the administrative set-up of the service provider (i.e. salaries for advisors, administrative personnel, General Operating Expenditures etc). Access to this data is limited to the Master Data user and the navigation etc should be invisible to other users. The Master Data User is allowed to create/edit/view/delete information related to the administrative set-up. Page 10 of 20

Service Provision Management System Project Specification


2.7 Role Permissions Reporting

Report users are able to pick report criteria, generate and print reports. Reports will be tailored to provide different levels of detail and will include raw data presented in tables as well as graphs. The Local report user can only generate reports on the basis of data related to the service provider s/he is associated to. The Global report user can view reports of a selected service provider or at the global level. Therefore, the selection criteria for report generation need to take this into account i.e. the Global report user will have an additional selection criterion to select the service provider or the global level view.

Page 11 of 20

Service Provision Management System Project Specification


3.0 Technical Specification

Note: All code design and development for the Service Provision Management System will comply with UNDP Corporate desktop standards.

3.1 Network Diagram

The following diagram shows the position of the Service Provision Management System relative to the larger UNDP intranet environment.

Service Provider A
3.2 Data Interface Requirements
The system will use the following three kinds of objects, each of which may be called programmatically by other applications (for example, PeopleSoft): request object report objects master data object

The system will be designed so that if a user or proxy system has sufficient rights and has provided certified identity credentials the data within the Service Provision Management System can be accessed via XML requests, such as: Send all data within a request object: http://spms.undp.org/send_request.xml?requestID=XXXX

Local Admin user

Send all data regarding a master data object: http://spms.undp.org/send_masterdata.xml?ServiceProviderID=XXXX Page 12 of 20


Service Provision Management System Project Specification

Send my action items: http://spms.undp.org/send_action_items.xml?userID=XXXX Etc. All other data requirements for the tool are managed using the external LDAP directory service (for users and permissions) and MS-SQL Server (for internal system logic).

4.0 Testing Requirements and Quality Control

Development of this tool is subject to the following kinds of testing prior to a UNDP-wide rollout: Software unit testing Software integrity must be tested against a suite of programmer-written unit test cases. Usability testing User interface (UI) must be tested against human usability standards and expectations. Pilot rollout testing Pilot version of this tool must be tested, and user feedback must be managed with bug tracking. Acceptance testing Final version of this tool must be tested against the original functional/business requirements. Testing of supporting materials (if applicable) If contracted, all training and documentation materials must be tested for accuracy and completeness against the UI of the final version of the tool, and a logical set of user-based tasks.

All testing must be managed using a project schedule and other traditional software project controls. Test activities must be bought-in by all project team members. Without adequate testing, project efficiency and long-term deployment success are compromised.

5.0 Maintenance and Future Development

The service level agreement (SLA) for post-launch support of this tool is as follows: The Local Admin Users and local ICT team will be the first line of support for user questions and issue resolution Escalation to OIST technical support will be supported when the first line of support can not resolve the issue

User training and documentation, if contracted, will reduce the support burden to both the local ICT teams and OIST technical support (see next section). However, care must be taken to maintain training documentation and all other materials current with any future technology changes related to the tool. Note: All changes to the user interface will follow a change request/change management process. For example, if changes are required to the global values used on the drop-down menus, the Local admin user must coordinate these changes and pass along the new requirements to the Global admin user.

Page 13 of 20

Service Provision Management System Project Specification


6.0 User Training and Documentation Requirements

Successful deployment of the new tool will require initial and ongoing user education (especially for those service providers that currently do not have such a tool in place). Training and documentation are required to meet the following needs: initial training of UNDP user base (global and local users) future training of newly hired UNDP personnel (global and local users) reference for users who have questions or difficulties using the tool instructions and rules for how the tool should be administered instructions for supporting the tool, including future code development projects

This project phase does not include the development or delivery of user training or documentation materials. To provide for these requirements, the project must contract separately for their development, or meet these needs using their own resources. Examples of documents that might be required include: user guide administrator guide online Help frequently asked questions (FAQ) classroom training (slides) computer-based training (animation)

7.0 Out of Scope

The following items are not in the scope of this phase of tool development: Feature development for functionality not specified in this document User training and documentation OIST user issue support, other than system outages and other technical errors OIST resources to support user management

Page 14 of 20

Service Provision Management System Project Specification


Appendix A: Menus and Navigation Wire Frames

Example navigation pages below are excerpts from the existing tools in Bratislava Regional Centre and the Regional Centres in Asia and the Pacific. Regional Centres in Asia and the Pacific

Home page (admin user)

Create a new request

Edit request

Service Deliverables

Create feedback

View all service records

Report selection criteria

Dynamic report capability

Dynamic report capability

This tool is located under http://www.undprcc.lk/undprccst/ . It has 4 levels of access: guest, admin, super admin, and chief. A user guide explaining the system in detail is attached (UNDP Asia-Pacific Regional Centres Services Tracker User's Guide (1 February 2007).pdf).

Page 15 of 20

Service Provision Management System Project Specification


Bratislava Regional Centre

Home page (regular user)

Create request

Edit request

Taxonomy of the service

Service team and effort

Service Deliverables

Create feedback The Bratislava Regional Centre Service Tracker currently does not have a reporting facility. The tool is located under http://km.undp.sk/?event=st.home Data fields Below is an overview of the different data entry fields. This is provided for information purpose on the data structure only and should not be used to determine the look-and-feel of the tool.

Page 16 of 20

Service Provision Management System Project Specification

Data related to individual service requests:


Basic S
1.1 Service type
Page 17 of 20

1.3 Service Benef

1.4 Client contact

Service Provision Management System Project Specification

Master data fields

5.1 Number
Page 18 of 20

5.2 Service Team

Service Provision Management System Project Specification


Drop-down selection boxes As per the specification above, drop-down selection boxes are either globally or locally defined. This to ensure that a global drop-down box can only be changed by a Global Admin User whilst local drop-down boxes can be maintained by the Local Admin User assigned to that specific service provider. This in order to ensure data consistency yet allow for flexibility for the service provider. Field 1.1 1.3 1.5 1.8 1.9 1.10 1.11 1.12 1.13 2.3 3.3 5.2 5.6 5.7 6.2 6.6 6.7 7.7 Description Service type Service Beneficiary Location Primary Service Area Secondary Service Area Primary Service Line Secondary Service Line Service Team Service Handler Team member Other cost bearer Service Team Title Level/Contract Service Team Title Level/Contract Other cost categories Location Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Service Tracker Master data Master data Master data Master data Master data Master data Master data Type Global Local Local Global Global Global Global Local from master data Local Local from master data Local Local Global Global Local Global Global Global

Page 19 of 20

Page 20 of 20