HD Request Management Process
HD Request Management ProcessWelcome at the documentation pages for the process "HD Request Management Process", of the service healthdata.be (Sciensano).
The following sections are (will be) provided:
- Introduction
- Implementation of the Request Management Process
- Start and evaluation of the Request Management Process
- Modifications to the Request Management Process
- Request Management
- Definition and scope
- Overall Process
- Diagram
- Roles & Responsibilities
- RACI matrix
- Process activity steps
- Service Portal for Request management
- Work instructions for Request management
- Definitions
- General definitions
- Abbreviations
Introduction
IntroductionThis document describes the healthdata.be Request Management Process. The process is end-to-end oriented and based upon the lifecycle model wherever applicable.
Implementation of the Request Management Process
Implementation of the Request Management ProcessThe 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).
Start and evaluation of the Request Management Process
Start and evaluation of the Request Management ProcessThis 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.
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.
Request management
Request management managerDefinition and scope
Definition and scopeA 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.
Overall Process
Overall Process managerDiagram
DiagramThis 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.
Roles & Responsibilities
Roles & ResponsibilitiesRole | Description |
---|---|
Request Owner | The 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 Manager | The 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 Analyst | The 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 User | The 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 Agent | The 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 Coordinator | The 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:
Role | Healthdata function |
---|---|
End User | anybody who is not part of the healthdata organization, but is a user of its services (scientists, Sciensano staff, hospital/laboratory staff, …) |
Service Desk Agent | Is part of the role of Support Engineer/Service Desk Officer in the Services & Support Team |
L2/3 Request Analyst | Is part of engineer/developer functions in all HD teams- IAT, DC, DWH, SOB; as well as the DPO, EA, other architects |
Request Coordinator | Is part of the role in all HD teams |
Request Manager | Is part of the role of Incident management in the Services & Support Team |
RACI matrix
RACI matrixRef | Functional Process Item | End User | Service Desk Agent | L2/3 Request analyst | Request Coordinator | Request Manager |
---|---|---|---|---|---|---|
R01 | Request Identification | I | R | R | R, A | |
R02 | Request Logging | I | R | R | A | |
R03 | Request Categorization & Prioritization | I | R | R | A | |
R04 | Known request ? | R | R | A | ||
R05 | Request fulfillment | R | R | R | A | |
R06 | Consult End-user | C | R | R | A | |
R07 | Set request as ‘completed’ | I | R | R | A | |
R08 | L2 needed ? | R | R, I | A, I | ||
R09 | Assign request to L2/L3 | R | I | R | A | |
R10 | Reassign ticket to Service Desk | I | R | R | A, I |
RACI | Description |
---|---|
A = Accountable | The single owner who is accountable for the final outcome of the activity. |
R = Responsible | The executor(s) of the activity step. |
C = Consulted | The expert(s) providing information for the activity step. |
I = Informed | The stakeholder(s) who must be notified of the activity step. |
Process activity steps
Process activity stepsR01. 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 |
Status | New |
Description | The 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. |
Status | Open |
Description | The 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
Objective | To categorize every new Service Desk Record for assignment, diagnosis, and reporting purposes. |
Input(s) | Open Request Record |
Output(s) | Categorized Request Record |
Status | Open |
Description | The Service Desk will verify or modify the category on which the request has been opened : |
R03. (2) Request Prioritization
Objective | To set an appropriate Priority for scheduling and handling the Request. |
Input(s) | Open, Categorized Request Record |
Output(s) | Open, Categorized and Prioritized Request Record |
Status | Open |
Description | The 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 ?
Objective | To identify if a fulfillment action is already known. |
Input(s) | Open, Categorized and Prioritized Request Record |
Output(s) | Open, Categorized and Prioritized Request Record |
Status | Work in Progress |
Description | The 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
Objective | To 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 |
Status | Work in Progress |
Description | The Service Desk will apply the fulfillment action(s) |
R06. Consult end-user
Objective | To 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 |
Status | Pending (! Same as for IM ?!) |
Description | The 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
Objective | To 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 |
Status | Close complete |
Description | Once 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 ?
Objective | To 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 |
Status | Work in Progress |
Description | If Service Desk cannot fulfill the request, the ticket will be assigned to an L2/L3-group |
R09. Assign request to L2/L3
Objective | To assign the incident ticket to a L2/L3 group. |
Input(s) | Investigated and Diagnosed request Record |
Output(s) | Open, Categorized and Prioritized request Record |
Status | Work in Progress |
Description | Once 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
Objective | To ensure that the fulfillment action is validated by the end-user. |
Input(s) | Fully Updated request Record |
Output(s) | Updated request Record |
Status | Work in Progress |
Description | When the fulfillment action is applied, the request ticket will be reassigned to the Service Desk, who will continue with step R06 |
Service Portal for Request management
Service Portal for Request managementThe 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.
How to submit a request
How to submit a requestWork instructions for Request management
Work instructions for Request management managerWork instructions for Request for new project with HD
Work instructions for Request for new project with HD1. 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.
Work instructions for Request access to a HD application
Work instructions for Request access to a HD application1. 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’
Work instructions for Request for infrastructure by HD
Work instructions for Request for infrastructure by HD1. 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’
Work instructions for Request for information about HD
Work instructions for Request for information about HD1. 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.
Definitions
Definitions managerGeneral 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.