HD Request Management Process

HD Request Management Process

Welcome at the documentation pages for the process "HD Request Management Process", of the service healthdata.be (Sciensano).

The following sections are (will be) provided:

manager Thu, 01/13/2022 - 11:26

Introduction

Introduction

This document describes the healthdata.be Request Management Process. The process is end-to-end oriented and based upon the lifecycle model wherever applicable.

manager Tue, 01/25/2022 - 09:33

Implementation of the Request Management Process

Implementation of the Request Management Process

The implementation of the healthdata.be Request Management Process will be done on a pragmatic base. During a start-up phase (6 months as of the use in the production environment), the results will be measured.
At the end of the start-up phase, the healthdata.be Request Management Process will be fixed. This will be done by taking into account the achievements during the start-up phase, the statistical information provided by the Information Technology Service Management System (i.c. ServiceNow).

manager Tue, 01/25/2022 - 09:32

Start and evaluation of the Request Management Process

Start and evaluation of the Request Management Process

This Request Management Process takes effect on January 1st 2022 and remains active until a new version is communicated.

The evaluation of the Request Management Process is done on a regular basis.

Once a year, the year results, the content of the Request Management Process and related SLA’s will be evaluated by the Accompanying Committee of the healthdata.be platform. The Request Management Process can be modified as described in Par “Modifications to the Request Management Process”. Related documents can have start dates different from the Request Management Process start date.

manager Tue, 01/25/2022 - 09:33

Modifications to the Request Management Process

Modifications to the Request Management Process
  • Every request by the Partner to change the contents of this Request Management Process will officially be sent to the healthdata.be Service Management.
  • The Changes, if approved by the healthdata.be Service Management, will become active as soon as the Request Management Process have been published.
manager Tue, 01/25/2022 - 09:33

Request management

Request management manager Tue, 01/25/2022 - 08:57

Definition and scope

Definition and scope

A Request is considered to be the most generic item, can be of any kind, and triggers specific actions depending on the type of request. Requests can lead to Changes, Information returns, Project Initiations. Requests that are identified as being Incidents or Problems, are transferred to the applicable flows and handled there.

Requests are the unified way of dealing with all kinds of end-user demands. It acts as the entry point towards healthdata.be. Requests can arrive from existing and new End-users, Suppliers, internal Staff. The person who is creating/initiating the request, is called the Requestor.

Requests can be associated with Business Programs; Applications; Technical Projects (including Sub-Projects).

The Request Management Process is an end-to-end process, handling:

  • receiving and capturing
  • classifying
  • processing
  • closing

of requests.

The Request Management Process links to the following other processes managed by healthdata.be:

  • Change Management Process
  • Project Management Process
  • Incident Management Process
  • Configuration Management Process
  • SLA Management Process

The Request Management Process is implemented in the following applications used by healthdata.be:

  • ServiceNow
  • ZenHub

The Request Management Process is interfacing with following applications used by healthdata.be:

  • ServiceNow ServicePortal
  • DB2 Reporting Process/Tool
  • ZenHub

The Request Management Process is owned by:

  • Team lead “Services & Support” of healthdata.be.
manager Tue, 01/25/2022 - 08:58

Overall Process

Overall Process manager Tue, 01/25/2022 - 08:58

Diagram

Diagram

This diagram describes the major process related activities, for each of the major steps. For each step, the responsibilities of all roles applicable are explained in a RACI matrix. Each step is explained as well in the next paragraphs.

manager Tue, 01/25/2022 - 08:58

Roles & Responsibilities

Roles & Responsibilities
RoleDescription
Request OwnerThe Request Owner is responsible for ensuring that all activities defined within the process are undertaken and that the process achieves its goals and objectives.
Request ManagerThe Request Manager is responsible for the Request procedure, for work instruction design, and for the day to day management of the overall procedure. The manager has authority to manage all aspects of Requests fulfilment.
Request AnalystThe Request Analyst is responsible for designing and implementing the Request Procedure as defined by the Request Manager, and to be a point of contact for escalated issues, questions, or concerns.
End UserThe End User is the person using an IT resource. This role is responsible to report all Incidents and make all IT requests and contacts through the Service Desk.
ServiceDesk AgentThe Service Desk Analyst is responsible for the day to day communication with all End Users and to facilitate the resolution and fulfillment of Incidents and Requests.
Request CoordinatorThe Request Coordinator is responsible of managing all requests that are assigned to his group, within the SLA defined.

Implementation of the major roles in the healthdata.be team:

RoleHealthdata function
End Useranybody who is not part of the healthdata organization, but is a user of its services (scientists, Sciensano staff, hospital/laboratory staff, …)
Service Desk AgentIs part of the role of Support Engineer/Service Desk Officer in the Services & Support Team
L2/3 Request AnalystIs part of engineer/developer functions in all HD teams- IAT, DC, DWH, SOB; as well as the DPO, EA, other architects
Request CoordinatorIs part of the role in all HD teams
Request ManagerIs part of the role of Incident management in the Services & Support Team
manager Tue, 01/25/2022 - 08:58

RACI matrix

RACI matrix
RefFunctional Process ItemEnd UserService Desk AgentL2/3 Request analystRequest CoordinatorRequest Manager
R01Request IdentificationIRRR, A
R02Request LoggingIR  R A
R03Request Categorization & PrioritizationIR  R A
R04Known request ? R  R A
R05Request fulfillmentRR R A
R06Consult End-userCR R A
R07Set request as ‘completed’IR R A
R08L2 needed ? R R, I A, I
R09Assign request to L2/L3 RI R A
R10Reassign ticket to Service Desk IR R A, I
RACIDescription
A = AccountableThe single owner who is accountable for the final outcome of the activity.
R = ResponsibleThe executor(s) of the activity step.
C = ConsultedThe expert(s) providing information for the activity step.
I = InformedThe stakeholder(s) who must be notified of the activity step.
manager Tue, 01/25/2022 - 09:29

Process activity steps

Process activity steps

R01. Request Identification

Input(s)A ticket can be initiated by phone call, email, portal, or walk-in.
Output(s)Request ticket is created in Service Now
StatusNew
DescriptionThe End-user can initiate a request via :
Portal : preferable way of reporting a request. Email : a user sends a mail to Support.Healthdata@sciensano.be. The Service Desk has one day to pick this up and create a ticket on behalf of that user. Phone : a user contacts the Service Desk by phone to report a request. The Service Desk will immediately, while on the phone, create a ticket on behalf of that user. Walk-in : a user can visit physically the Service Desk to report a request. The Service Desk will immediately create a ticket on behalf of that user.

R02. Request Logging

Input(s)Details gathered from the End User is added to the ticket
Output(s)Ticket is enriched with information in the work notes.
StatusOpen
DescriptionThe Service Desk will perform a first analysis of the request ticket : It is not a request, but an incident : the request ticket will be closed and the Service Desk will create an incident ticket It is a request : the ticket will be enriched with the first analysis

R03. Request Categorization

ObjectiveTo categorize every new Service Desk Record for assignment, diagnosis, and reporting purposes.
Input(s)Open Request Record
Output(s)Categorized Request Record
StatusOpen
DescriptionThe Service Desk will verify or modify the category on which the request has been opened :

R03. (2) Request Prioritization

ObjectiveTo set an appropriate Priority for scheduling and handling the Request.
Input(s)Open, Categorized Request Record
Output(s)Open, Categorized and Prioritized Request Record
StatusOpen
DescriptionThe Service Desk will verify or modify the priority on which the Request has been opened : Catalog resolution times to define : e.g. RFI = 10 working days, RFAccess = 3 working days, …

R04. Known request ?

ObjectiveTo identify if a fulfillment action is already known.
Input(s)Open, Categorized and Prioritized Request Record
Output(s)Open, Categorized and Prioritized Request Record
StatusWork in Progress
DescriptionThe Service Desk will try to detect if a fulfillment actions is already known in the knowledge base. If found, the Service Desk will apply this action

R05. Fulfill request

ObjectiveTo define whether a request can be solved by the Service Desk or not
Input(s)Open, Categorized and Prioritized Request Record
Output(s)Open, Categorized and Prioritized Request Record
StatusWork in Progress
DescriptionThe Service Desk will apply the fulfillment action(s)

R06. Consult end-user

ObjectiveTo have the confirmation of the end-user that the actions applied fulfill the request.
Input(s)Open, Categorized and Prioritized request Record
Output(s)Open, Categorized and Prioritized request Record
StatusPending (! Same as for IM ?!)
DescriptionThe Service Desk will contact the end-user, preferably by phone If not available by phone, the Service Desk will send a mail The SOP ‘Manage awaiting tickets’ will apply

R07. Set request as completed

ObjectiveTo set the request ticket to status ‘complete’ after confirmation of the end-user.
Input(s)Open, Categorized and Prioritized request Record
Output(s)Open, Categorized and Prioritized request Record
StatusClose complete
DescriptionOnce the end-user has confirmed the fulfillment, the Service Desk will change the status to ‘closed complete’. If the end-user should not be satisfied, he will not be able to re-open the ticket, he will have to create a new request ticket

R08. L2 needed ?

ObjectiveTo determine, after diagnosis (R04), whether the Service Desk can fulfill the request or a L2-group has to manage the request.
Input(s)Initial Diagnosed request Record
Output(s)Open, Categorized and Prioritized Incident Record
StatusWork in Progress
DescriptionIf Service Desk cannot fulfill the request, the ticket will be assigned to an L2/L3-group

R09. Assign request to L2/L3

ObjectiveTo assign the incident ticket to a L2/L3 group.
Input(s)Investigated and Diagnosed request Record
Output(s)Open, Categorized and Prioritized request Record
StatusWork in Progress
DescriptionOnce the ticket is assigned to a L2/L3-group, the request coordinator of that particular group has to manage this ticket, under control of the request manager

R10. Reassign ticket to Service Desk

ObjectiveTo ensure that the fulfillment action is validated by the end-user.
Input(s)Fully Updated request Record
Output(s)Updated request Record
StatusWork in Progress
DescriptionWhen the fulfillment action is applied, the request ticket will be reassigned to the Service Desk, who will continue with step R06
manager Tue, 01/25/2022 - 09:30

Service Portal for Request management

Service Portal for Request management

The department healthdata.be of Sciensano uses ServiceNow as IT Service Management tool (ITSM). ITSM tools are software solutions that help organisations manage the provision of IT services, either to internal users or — for IT service providers — external customers.

The following IT processes will be managed using this ITSM tool:

  • Incident management
  • Request management
  • Change management
  • Management of Configuration management database

With this ITSM tool an external Service and Support portal is created for users to request help in case of an incident, or when for example access is needed for an application of the healtdata.be platform.

manager Tue, 01/25/2022 - 09:30

Work instructions for Request management

Work instructions for Request management manager Tue, 01/25/2022 - 09:30

Work instructions for Request for new project with HD

Work instructions for Request for new project with HD

1. Introduction

This document describes the healthdata.be work instructions related to a Request for New Project.

1. Objective and Purpose

Objective : describe the process when requesting a new project

Purpose : helping the client fulfilling his needs when requesting a new project.

2. Procedure

2.1. Diagram

2.2. Work instructions

2.2.1. STEP 1. User requests a new project

Action: A user requests a new project. If the request is done by mail, the user has to attach the fully completed template-file ‘New Project’ to it.

2.2.2. STEP 2. SD creates a ticket RF Information

Action: Service Desk creates a ticket, of type Request for New Project on behalf of the user

It is mandatory to attach the template-file ‘New Project’ to the ticket. This file is the one attached to the mail of the user.

The request is submitted by clicking on ‘Order now’

2.2.3. STEP 3. PMO analyses the template ‘New Project’

Action: PMO-team will analyze the template-file on its completeness. :

  • If not, the PMO-team will enter the missing info in the Customer communication and reassign the item to Service Desk. (see step 7)
  • If complete, the PMO-team will approve the requested item (see step 4)

2.2.4. STEP 4. PMO-team approves the requested item

Action: Once the template-file is complete, and the outcome of the analysis is positive, one of the PMO-teammembers will approve the requested item, by clicking on ‘Requested’ and in the next screen, on ‘approve’.

Additionally, the user will be informed and a ZenHub-ticket will be created.

2.2.5. STEP 5. PMO-team sets the requested item to ‘Closed Complete’

Action: PMO-team sets the requested item to the state ‘Closed Complete’

2.2.6. STEP 6. PMO-team sets the requested item to ‘Closed skipped’

Action: if the outcome of the analysis is negative, one of the PMO-teammembers will reject the requested item by clicking on ‘reject’.

A userfriendly information will be entered in the Customer communication-field.

2.2.7. STEP 7. Service Desk to consult the user and ask to complete the request

Action: in case, after analysis by PMO-team, the template-file is not complete, Service Desk will consult the user and ask to complete it with the missing info described in the customer communication.

manager Tue, 01/25/2022 - 09:30

Work instructions for Request access to a HD application

Work instructions for Request access to a HD application

1. Introduction

This document describes the healthdata.be work instructions related to a Request for Access.

1. Objective and Purpose

Objective : describe the process when requesting an access

Purpose : helping the client fulfilling his needs to gain access to a certain application..

2. Procedure

2.1. Diagram

2.2. Work instructions

2.2.1. STEP 1. User requests an information

Action: A user requests an access via a mail.

2.2.2. STEP 2. SD creates a ticket RF Access

Action: Service Desk creates a ticket, of type Request Access on behalf of the user

Service Desk enters the info coming from the users mail in the ticket

The request is submitted by clicking on ‘Order now’

2.2.3. STEP 3. SD consults the user to complete the request

Action: if needed information is missing, the Service Desk will contact the user and ask for more information in order to complete the form.

2.2.4. STEP 4. DPO handles the request

Action: once ordered, DPO will be notified that an approval request is waiting. After analysis of the request, DPO will choose the appropriate action.

2.2.5. STEP 5. Fulfill the request

Action: if the request is approved, Service Desk will give access as requested in the requested item

2.2.6. STEP 6. Set the status to ‘Closed complete’

Action: once fulfilled, Service Desk will set the status of the requested item to ‘Closed complete’

2.2.7. STEP 7. DPO motivates the rejection

Action: if DPO rejects the requested item, he will enter a motivation in the Comments.

2.2.8. STEP 8. SD to inform the user and set the status to ‘Closed skipped’

Action : Service Desk will inform the user by copying the motivation into the Customer communication field and set the status of the requested item to ‘Closed skipped’

manager Tue, 02/14/2023 - 15:57

Work instructions for Request for infrastructure by HD

Work instructions for Request for infrastructure by HD

1. Introduction

This document describes the healthdata.be work instructions related to a Request for Infrastructure.

1. Objective and Purpose

Objective : describe the process when requesting a new/modified infrastructure component

Purpose : keeping track of the approvals, and maintain the CMDB.

2. Procedure

2.1. Diagram

2.2. Work instructions

2.2.1. STEP 1. User requests an infrastructure

Action: A user requests an infrastructure component. This can be :

  • A new server
  • A change on an existing server (additional RAM, CPU, Diskspace, …)

2.2.2. STEP 2. SD creates a ticket RF Infra

Action: Service Desk creates a ticket, of type Request for Infrastructure on behalf of the user

Mandatory fields are the first name and the name of the requestor. The fields ‘Infrastructure request’ and ‘Comments’ are optional.

The request is submitted by clicking on ‘Order now’

2.2.3. STEP 3. SD sends template to the user and requests to fill in

Action:

Documentation: Template is available on https://www.dropbox.com/home/HD_Proc/HD_Proc_Doc?preview=HD_Request_Infrastructure_Form.docx

2.2.4. STEP 4. User fills in the template ALL lines except nr 16 and returns it to the SD

Action: If not complete, the Service Desk informs the user and requests to complete the template

2.2.5. STEP 5. SD to attach the template to the ticket and assign it to Operations

Action: Service Desk will :

  • Attach the template to the ticket
  • Create a folder containing the ticket number on https://www.dropbox.com/home/HD_Org/HD_Org_SOB/5.%20Request%20Management/Request%20for%20infrastructure
  • Save the template in that folder

2.2.6. STEP 6. Request via mail send to the supplier requesting a quote

Action: Operations will send the mail to the supplier requesting a quote.

2.2.7. STEP 7. Supplier sends a quote

Action: Operations will update the ticket with the quote, received from the supplier

2.2.8. STEP 8. Request via mail the approval to COORD.

Action: Operations will send a mail to COORD, requesting the approval

2.2.9. STEP 9. Not approved

Action: Operations will :

  • inform user
  • complete/saves the template (no approval) in the appropriate folder on https://www.dropbox.com/home/HD_Org/HD_Org_SOB/5.%20Request%20Management/Request%20for%20infrastructure
  • Set the ticket to ‘closed skipped’

2.2.10. STEP 10. Approved

Action:

  • Operations will send the approved template to supplier
  • Operations will approve the requested item
  • The Financial Coordinator of Coord will complete the template by filling in the approval data and line nr 16.

2.2.11. STEP 11. Supplier fulfils the request and informs Operations

Action: the supplier will send a mail informing Operations that the request has been fulfilled

2.2.12. STEP 12. Request fulfilled

Action: Operations will :

  • inform user
  • complete/saves the template
  • Set the ticket to ‘closed complete’
manager Tue, 01/25/2022 - 09:31

Work instructions for Request for information about HD

Work instructions for Request for information about HD

1. Introduction

This document describes the healthdata.be work instructions related to a Request for Information.

1. Objective and Purpose

Objective : describe the process when requesting an information

Purpose : helping the client fulfilling his needs with information he requests..

2. Procedure

2.1. Diagram

2.2. Work instructions

2.2.1. STEP 1. User requests an information

Action: A user requests an information. This can be :

  • An explanation on a project, …
  • A list

2.2.2. STEP 2. SD creates a ticket RF Information

Action: If the user did not create a ticket from the portal, the Service Desk creates a ticket, of type Request for Information on behalf of the user

Mandatory fields are the subject and description.

The request is submitted by clicking on ‘Order now’

2.2.3. STEP 3. SD investigates the request and enriches the request

Action: Service Desk opens the requested item, linked to the request, and investigates the needs of the requestor. If necessary, the Service Desk will add clarification info in the customer communication, which is visible for the user.

2.2.4. STEP 4. Fulfill the request

Action: If the Service Desk knows how to fulfill the requested item, they will execute the action. If they do not know how, they will first investigate if they are able to fulfill the requested item or if they have to assign the requested item to another assignment group. (step 6)

2.2.5. STEP 5. Set the requested item to ‘Closed Complete’

Action: Service Desk or 2L-assignment group will inform the user by entering a user friendly comment in the ‘customer communication’ field and set the requested item to the state ‘Closed Complete’

2.2.6. STEP 6. Assign the requested item to 2L-group

Action: if no fulfillment possible, the Service Desk will assign the requested item to a 2L-assignment group.

2.2.7. STEP 7. Fulfill the request

Action: the 2L-assignment group will fulfill the requested item and execute step 5.

manager Tue, 01/25/2022 - 09:31

Definitions

Definitions manager Tue, 01/25/2022 - 09:31

General definitions

General definitions
  • Application Software: Software developed in order to meet specific healthdata.be Basic Services requirements.
  • Availability of an environment or an application: Availability is usually calculated as a percentage of time the IT Service, the environment or the application, is able to perform according to its agreed function. This calculation is based on the Agreed Service Window and Downtime.
  • Closing days of the Service Desk Center: 1 January, Easter Monday, 1 May, Ascension day, White Monday, 21 July, 15 August, 1 November, 2 November,11 November, 25 December, 26 December.
  • Customer: A person, an institution, an external IT Service or an IT application who has integrated healthdata.be IT services in their specific IT Services or applications. Customers are distinct from End-user, as some customers do not use the IT Service directly.
  • Detection time: Time from the moment the incident occurs and the moment the incident is identified by the user or a monitoring service. (Still not communicated to the Service desk or Supervision). This period of time precedes the response time.
  • Downtime: Time during which an IT Service is not available.
  • End-user: A person, an institution, an external IT Service or an IT application who uses the IT Service.
  • Incident: An unplanned interruption to an healthdata.be basic service or a reduction in the Quality or the Service.
  • Key Performance Indicator: A metric that is used to help manage a Process, Service or activity.
  • Maintenance Windows for Planned Interventions: An agreed time period during which Changes or Releases may be implemented with minimal impact on Services. Change Windows is defined in the Service Level Agreement.
  • Mission: The set of services to be provided by the healthdata.be platform, following a demand from the Partner.
  • Partner: Healthcare organization, research organization software package provider, healthcare stakeholders, research stakeholders are identified as healthdata.be Partners.
  • Process: A structured set of activities designed to accomplish a specific Objective.
  • Reaction time: The time between the moment that the Service Desk is informed of an event (or the moment which an incident is detected via the monitoring) and the moment that a ticket is created, including its assignment to a group for resolution. This period of time precedes the resolution time.
  • Release: A group of Changes that are tested, packaged and deployed into the IT Infrastructure at the same time.
  • Resolution time: The time from the initial assignment of ticket till the ticket is considered completed. In other word that an answer has been communicated for a request for information or a solution has been implemented.
  • Response time: Time between a user or a monitoring service tries to communicate an identified incident or an event to the service desk and the moment the service desk respond to the event. (e.g. number of ring bell, time before a mail is being treated, time before an alert is being treated). This period of time precedes the Reaction time.
  • Service Desk: Point of contact for all the Service Requests. The Service Desk consists of the Contact center and Supervision.
  • Service Desk: Single point of contact for end-users and customers.
  • Service hours: All hours within the Service Window.
  • Service Level Agreement: An Agreement between an IT Service Provider and a Partner. The SLA describes the IT Service, documents Service Level Objectives, and specifies the responsibilities of the IT Service Provider and the Partner.
  • Service Level Objective: A commitment that is documented in a Service Level Agreement. Service Level Objectives are based on Service Level Requirements, and are needed to ensure that the IT Service quality is fit for purpose. Service Level Objectives are the target of the KPIs.
  • Service Request: Request for an healthdata.be basic service (e.g. request for information, request for new project, request for access to an application, …).
  • Service Window: Agreed time period during which a particular IT Service must be available. For example, "Monday- Friday 08:00 to 17:00 except closing days of the Service Desk Center". Service Window is defined in the Service Level Agreement.
  • Service: A Service is defined, within the context of Service management, as a logical grouping of functionalities that is made available through the combination and specific configuration of hard- and software CI’s.
  • Support Window: An agreed time period during which support is available to the Users. Typically this is the period when the Service Desk is available.
  • System Software: Basic software as MS Windows, Linux, Oracle, etc.
  • Third Party Services : Services used but not developed, provided, maintained and not supported by healthdata.be (ehealth TTP, ehealth ETK, eHealth eHBox, NIC, …)
  • Working days: All weekdays except closing days of the healthdata.be platform.
  • Working hours: All healthdata.be’s working days between 8:00 and 16:30.
manager Tue, 01/25/2022 - 09:31

Abbreviations

Abbreviations manager Tue, 01/25/2022 - 09:31