Service Tracker Project Spec No Toc

8/4/2019 Service Tracker Project Spec No Toc

1/20

Service Provision Management SystemService Tracker for Advisory support services

Project Specification version 0.2

Last updated: 9/23/2011


2/20

Version History

Version Date Author Description

0.1 18 July 07 GvM Initial version

0.2 24 July 07 GvM Added estimated number of users and location

Service Provision Management System Project Specification

DRAFT


3/20

Distribution List

Name, Job Title and Company

Distribution

Requirement Signature Date

Mads Svendsen, Mgmt Advisor, MCT

Tina Friis Hansen, Coordinator, MCT

Anil Soud, Advisor, Executive Office Sign off required

Thomas Eriksson, Planning Advisor,

BoM

Akiko Yuge, Assistant Administratorand Director Bureau of Management

Sign off required

Mitchell Toomey, Chief, Portal andWeb Services Unit OIST

BRATISLAVA?

BANGKOK, COLOMBO, PACIFIC?


DRAFT


4/20

1.0 Introduction

1.1 Project Overview

The main rationale for developing a Service Provision Management System is to ensure consistency andcomparability 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 andregional advisors based in HQ and in Regional Centres.

It is anticipated that this data can support the establishment of demand-driven budget processes forinternal 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 servicesranging from a manual Excel tool to a web-based service tracker. Not only do these tools differ in thefunctionality they offer, they also differ in the way in which data is captured which makes impedes dataconsolidation and comparison.

To ensure consistent and meaningful data comparison, it is proposed to create a common template andplatform 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 allservice providers.

1.2 Project Objectives


DRAFT


5/20

Georges van Montfort

Mitchell Toomey


DRAFT


6/20

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 theannex

o 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

annexo Other selection fields are blocked and can only be modified by a Global Admin User

o Local Admin Userneeds to be able to modify local users (i.e. create, delete, change)

Automate service request processing workflow from request to delivery and follow-up:

o Local users of the service provider can create and change service requests

o After creating a request, the requestor user can view and edit the request

o Users can view requests related to their local service provider

o In the management view of requests, organize the requests by date, type, and country

o Provide printer-ready version of requests to support offline requirements


DRAFT


7/20

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 onthese 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 forthe delegation of roles.

2.3 Role Profiles

The following table defines the permissions afforded for each role in the Service Provision ManagementSystem. A single user will be assigned at least one role, but there needs to be the possibility to assignmultiple roles.

Role Request-related Permissions Notes

Global admin user

Allowed to modify global drop-down selection boxes

Design user roles 2 users


DRAFT


8/20

provider or globally


DRAFT


9/20

2.4 Role Permissions Request workflow including sourcing management

The system helps the user manage the request workflow from registering an incoming request to creatingfeedback as part of the follow-up. User roles in this respect are set up in a simplified manner inthe sense that all activities in the workflow can be done by the Advisor user. The table belowspecifies the typical steps as part of the service workflow. Note that not all steps are applicable toall 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 Description Notes

1 Register Request(mandatory)

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

2 Define Request(mandatory)

Activities

Source Advisors

Detailed scope of service

Confirm schedule & timing


DRAFT


10/20

Step Description Notes

Deliver service (mandatory)

Outputs

Finalized agenda (optional)

Working documents (optional)

6 Complete Service

(mandatory)

Activities

Final review meetings (optional)

Outputs

End service action plan to client (optional)

Service deliverables packaged to client (mandatory)

7 Review Service

(mandatory)

Activities Client survey (mandatory)

Update service request

Outputs

Feedback questionnaire

Service deliverables uploaded into Service Management system(mandatory)

2.5 Role Permissions Configuration

As indicated above the system needs to be configurable in the sense that the options in several drop-


DRAFT


11/20

2.7 Role Permissions Reporting

Report users are able to pick report criteria, generate and print reports. Reports will be tailored to providedifferent 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 willhave an additional selection criterion to select the service provider or the global level view.


DRAFT


12/20

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 thelarger UNDP intranet environment.

Provider A


DRAFT


13/20

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 usersand 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 testingSoftware integrity must be tested against a suite of programmer-written unit test cases.

Usability testingUser interface (UI) must be tested against human usability standards and expectations.

Pilot rollout testingPilot version of this tool must be tested, and user feedback must be managed with bug tracking.

Acceptance testingFinal 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 andcompleteness 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. Testactivities must be bought-in by all project team members Without adequate testing project efficiency and


DRAFT
http://spms.undp.org/send_action_items.xml?userID=XXXXhttp://spms.undp.org/send_action_items.xml?userID=XXXX


14/20

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 arerequired 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 documentationmaterials. 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)


DRAFT


15/20

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


DRAFT


16/20

Bratislava Regional Centre

Home page (regular user) Create request Edit request

Taxonomy of the service Service team and effort Service Deliverables


DRAFT


17/20

Data related to individual service requests:

request


DRAFT


18/20

Master data fields

Ad i


DRAFT


19/20

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-downboxes can be maintained by the Local Admin User assigned to that specific service provider. This in orderto ensure data consistency yet allow for flexibility for the service provider.

Field Description Location Type

1.1 Service type Service Tracker Global

1.3 Service Beneficiary Service Tracker Local

1.5 Location Service Tracker Local

1.8 Primary Service Area Service Tracker Global

1.9 Secondary Service Area Service Tracker Global

1.10 Primary Service Line Service Tracker Global

1.11 Secondary Service Line Service Tracker Global

1.12 Service Team Service Tracker Local from master data

1.13 Service Handler Service Tracker Local

2.3 Team member Service Tracker Local from master data

3 3 Oth t b S i T k L l


DRAFT


20/20

Documents

Service Tracker Project Spec No Toc