Request management
Request management manager Tue, 01/25/2022 - 08:57Definition 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 manager Tue, 01/25/2022 - 08:58Diagram
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 |