Request Definition
1 Introduction
The following document gives an overview of the available request types and their definitions. The glueckkanja-gab IT service and managed services make use of these request types.
1.1 Overview of request types
- Service requests
- Change requests
- Incidents
- Problems
- Monitoring & Events
2 Service Request Management
2.1 Description
glueckkanja-gab support the agreed quality of service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner. Service Request Management is dependent upon specified standard processes, procedures, and automation.
The respective Managed Services specify which service requests can be provided by the service. More detailed information can be found in the service descriptions.
2.2 Required information
Each service request requires defined information so that it can be implemented as standardized or automated as possible. The information required for the individual service requests can be found in the respective service descriptions.
2.3 Activities & Responsibilities (RACI)
No. | Activity | Customer | glueckkanja-gab | Description |
---|---|---|---|---|
1 | Service Request Creation | R,A | C,I | Creating Service Request via ITSM system integration |
2 | Service Request Authorization | R,A | C,I | Validating that Service Requests are valid and authorized customer requests |
3 | Service Request Execution | I,C | R,A | Providing the requested standard change or information/advice. |
3 Change Request Management
3.1 Description
Change is defined as a Service change in any addition and installation, modification, or removal of anything that has an effect on the basically defined service scope. Change Management has the scope to manage all the services, configuration items, processes documentation, and commercial effects to bring the change in permanent service. The process includes recording, documenting, approving, and monitoring, and ensures that changes are planned, efficient, cost-effective, and executed with minimal risk.
3.2 Differentiation of change types
We distinguish between different types of change requests: Standard Changes, Normal Changes, and Emergency Changes.
3.2.1 Standard Changes
Standard Changes are small changes within a service that has no impact on the general service structure or delivery. Standard Changes are described and handled identically within the service descriptions of our Managed Services together with Service Requests.
3.2.2 Normal Changes
Normal changes are all changes that are not defined as standard changes in the scope of the Managed Service. Normal changes can be significantly larger in scope and more complex, which results in outsourcing to our consulting service. In general, we always try to have a Normal Change implemented by the 3rd level, however, as described above, the transfer to the Consulting Service may be necessary. In this case, the Normal Change is treated as a (small) project in Consulting. Normal changes are charged via the on-demand quota or hours.
3.2.3 Emergency Changes
Emergency changes are unpredictable and usually sudden changes that can have an impact on the general service structure or delivery. Furthermore, emergency changes can directly affect or impact end-users. For emergency changes, an accelerated procedure is defined with the customer in order to be able to react to special situations. If necessary, additional employees from consulting must be called in for an emergency change. The implementation of an emergency change requires the explicit approval of the Customer Service Manager (CSM) and glueckkanja-gab Service Lead. Emergency changes are charged via the on-demand quota or hours.
3.3 Required information
The Service Delivery Team has the right to forward requests to glueckkanja-gab Consulting Services. Their processing times may differ from the description in our Service Level Agreement. An acknowledged request must contain at a minimum the following information from the customer:
- Customer company name
- Requestor name
- Technical contacts at Customer
- A clear description of the request
- Desired task completion date and timeframe
- Sufficient details for glueckkanja-gab to execute the request (e.g. cloud system login credentials, implementation details, and limitations, specific requirements, etc.)
3.4 Activities & Responsibilities (RACI)
No. | Activity | Customer | glueckkanja-gab | Description |
---|---|---|---|---|
1 | Change Request Creation | R,A | C,I | Creating Change Request for glueckkanja-gab following agreed change request process. |
2 | Change Request Authorization | R,A | C,I | Validating that the Change Request is valid and authorized |
3 | Change Request Execution | I, C | R,A | Providing and implementing the requested change. |
4 Incident Management
4.1 Description
The Incident Management provides an incident first response (break and fix or escalate) with processing times and severity levels further defined in the Service Level Agreement. glueckkanja-gab has the responsibility to raise the Incidents automatically from the preventative infrastructure and service availability alerts based on Monitoring & Event Management.
4.2 Standard services and Tasks
- Acknowledgment of Incidents
- Triage of Incidents
- Resolution of Incidents
- Workarounds of Incidents
- Escalation of Incidents
- The overall incident resolution process
4.3 Activities & Responsibilities (RACI)
No. | Activity | Customer | glueckkanja-gab | Description |
---|---|---|---|---|
1 | Incident Creation | R,A | I,C | Creating Incident requests |
2 | Incident First Response | I | R,A | First incident response for incidents received |
3 | Incident Resolution | I | R,A | Incident resolution and if necessary incident escalation |
4 | Incident escalation to glueckkanja-gab 3rd Level | I | R,A | Incident escalation to 3rd Level and priority management for escalated incidents |
5 | Incident escalation to 3rd party support provider | I,C | R,A | Incident escalation to defined 3rd party support provider and priority management for escalated incidents |
6 | Incident escalation to Problem Management | I,C | R,A | As described in the Problem Management section, Incidents can be escalated to Problems. |
5 Problem Management
5.1 Description
glueckkanja-gab’s Problem Management, based on Root Cause Analysis (RCA), focuses on problem identification and its elimination. Incidents in question are analyzed and recurrence and severance of them are investigated. Then, Problem Management aims to provide instructions and guidance for problem elimination.
The analysis and sustainable avoidance of disruptions (incidents) are the focus of problem management. Here, Incident Management is provided with temporary solutions (workarounds), and final solutions to known errors (known errors) are developed. The goal is to identify problems in the area of responsibility of glueckkanja-gab, to make them transparent, to accompany solution progress, and reduce the number of incidents. Problem management includes both reactive and proactive action to solve and Avoidance of problems. Reactive Problem Management describes the process from error identification to structural correction by Change Management. In proactive problem management, analyses of incident data, trend analyses, and results are prepared and develops solutions to prevent incidents before they occur. The Problem Management of glueckkanja-gab becomes active when:
- A serious incident occurs for which a structural solution is found
- The analysis of the incident data indicates an accumulation of incidents or a trend is recognizable
- The analysis/monitoring of the Cloud infrastructure detects weak points that could lead to new incidents
5.2 Standard services and Tasks
- Acknowledgment of Problems
- Triage of Problems
- Resolution of Problems
- Workarounds of Problems
- Escalation of Problems
5.3 Activities & Responsibilities (RACI)
No. | Activity | Customer | glueckkanja-gab | Description |
---|---|---|---|---|
1 | Identification | I | R,A | Improve the overall availability of services by proactively identifying problems. Proactive problem management aims to identify problems and/or provide workarounds before (further) incidents occur. |
2 | Categorization and prioritization | C,I | R,A | Record and prioritize an issue with appropriate diligence to enable rapid and effective resolution. |
3 | Diagnosis and solution | I,C | R,A | Identify the underlying cause of a problem and initiate the most appropriate and economical problem resolution. If possible, a temporary workaround is provided. |
4 | Monitoring | I | R,A | Continually monitor open problems and errors for their processing status so that corrective action can be taken if necessary. |
5 | Conclusion and evaluation | I | R,A | Ensure that - after a successful problem resolution - the Problem Record contains the complete description of the resolution history and that the Known Error Records associated with it have been updated. |
6 | Review | I | R,A | Review the resolution of a major problem to avoid recurrence and to gain experience for the future. Furthermore, check whether the problems that have been marked as "Closed" have actually been eliminated. |
7 | Reporting | I | R,A | Ensure that the other service management processes are informed as well as IT management (in the form of the problem management report about open problems, their processing status and existing workarounds.) |
5.4 Root Cause Analysis
glueckkanja-gab shall deliver a Root Cause Analysis (RCA) of the reported Problems within the Problem Management. The RCA is completed by the Managed Services team (3rd Level) and as a result, an RCA document is created. Upon completion, the RCA document is delivered to the customer and optionally a meeting is arranged where the RCA is gone through. RCA Document breakdown:
- Summary
- Business impact
- Activity Log of Problem Management work executed by glueckkanja-gab
- Root Cause
- Suggested Corrective Actions
6 Monitoring & Event Management
6.1 Description
glueckkanja-gab offers an automated monitoring and instrumentation platform in its managed services that provides a 360-degree view of a customer's infrastructure, including :
- Monitoring feeds from cloud infrastructure monitoring and alerts such as Azure Alerts or various Microsoft 365 Alerts.
- Service Level Monitoring
The extent to which monitoring and event management is offered by which Managed Service is included in the respective Managed Service descriptions.
Monitoring & Event Management is used by the Service Delivery Team and the respective Managed Services Teams to deliver the scope of services included in the respective Service Descriptions.
6.2 Incident creation
Incidents can be generated via Monitoring & Event Management. The Managed Service Teams are responsible for the creation of incidents and under which conditions they are created. Details about the incident generation can be found in the service descriptions.