A service request is a "standard change". It involves a change to the infrastructure that follows an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements. Examples might include an upgrade of a PC in order to make use of specific software, new hires within an organization, and PC, software and network connections for temporary or seasonal changes to requirements.
Once the approach has been established and documented, a standard Change process should be developed and promulgated to ensure that such Changes are efficiently processed to support the organization's business needs
A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request for Change (RFC). However, practice shows that handling of both failures in the infrastructure and of service requests are similar, and both are sometimes included in the definition and scope of Incident Management by extending the logic to encompass a "Service Event" where an event might be:
Service Requests must be based upon established and approved workflows which, when followed precisely, reduce the risks associated with the change to a level wherein they are considered pre-approved and, commensurate with this low degree of risk, can be initiated by the Service Desk or through an automated web portal.
The SR process (as determined by the categorization which is invoked will be documented and maintained in the CMDB.
With the implementation of enhanced Incident Management processes and procedures comes the opportunity to leverage new efficiencies in completing Service Requests. At some point, the organization will grapple with whether a Service Request should be treated like an incident or like a low risk change, but, because the organization is most likely to have invested in its' Incident Management system in order to garner some early wins in better IT Service Management, the Incident system will be adapted to accommodated the workflow aspects of the Service Request.
As the volumes of requests and incidents increase it becomes efficient and more effective to distinguish how they are treated. At this point the organization may endevour to utilize application support better geared to tracking workflow completion (possibly with rudimentary project management functionalities).
At some point the organization may become interested in achieving higher operational maturity levels. AS the organization attempts to achieve a more defined level of operations it will seek to codify its' services in a service catalogue. In addition, in seeking greater consistency in the degree of service fulfillment it will establish and monitor the processes described by the workflows. These will become Processes which, ideally, will be assumed under Change Management protocols and procedures. The organization begins increasingly to operate and change according to processes rather than through individual actions. As the organization strives for higher maturity it will seek to adapt its' behaviour in accordance with performance information. Analyzing Service Request and Incident data for management reporting, continuous improvement and to support other IT service management practices (eg. Problem, Capacity management) will prove valuable. Application systems based upon Change Management principles provide for better management of Service request workflow and subsequent analysis of the fulfillment lifecycle for various service offerings.
Identifying repeatable processes can improve the efficiency of service delivery as well as supporting IT governance and standards. Through utilizing clearly defined repeatable processes, the total customer experience can be measured and the costs to the organization will be decreased through:
The person named by the User when the ticket is opened should receive automatic email notifications when the Service Request status changes. The status changes generating email messages include:
Processes
Service Request Summary ProcessControls
| ||
Inputs
| Activities
| Outputs
|
Mechanisms
|
Inputs
Purchasing Plans
The organization will have specific plans developed as part of an annual budgeting exercise or completed as part of an in-year initiative which will imply the creation, removal or movement of technology. These plans can be used as basic planning documents for the estimated workload of the SR Management system.Service Catalogue
The Service Catalogue will outline the services which are available to the organization, their costs, how they can be accessed and the obligations of the customer and provider for their provision.
Categorization
The designation of service categories will reflect the organization's fulfillment organization. Ideally, this definition will be a reflection of a service catalogue outlining the organization's service offerings.Budgetary Authorizations
The organization's delegation of authority, and budgetary and costing procedures will need to be taken into account in ensuring the proper authorizations are obtained for service requests.SLM Guidelines
SLM Guidelines will determine how services are devised and made available to Customers. These guidelines will also direct how Service Catalogues are updated. SLM is also responsible for establishing the timeframes in which service requests need to be fulfilled and for directing the establishment of escalation procedures when a breech of a service objective is at risk.Service Fulfillment Contracts
The fulfillment of a service request may well involve multiple parties in its' realization. Some of those services may be provided by vendors external to the organization. The obligations and timeframes of these bodies are set out in contracts with the organization. The terms and conditions of these contracts will determine how quickly and in what priority requests will be attended to.
Service Request System
All organizations will have some system to request and record SRs. The immediate primary purpose of the systems is to provide ongoing control from initiation to completion of the service request. At greater volumes the system must provide a means to prioritize and retrieve orders. It should support this with an ongoing alert of the Status of requests to ensure that they don't get misplaced. Since some fulfillments can result in the creation of incidents and change requests a linkage to these systems will be desirable at some point. As the organization matures to undertake analysis of its' overall operations it will seek to analyze the information for trends and patterns.Fulfillment Groups
The definition and setup of the primary service Fulfillment Groups, as well as their staffing levels and expertise, will determine how and at what speed services can be fulfilled.
Service Move, Add or Change
The completion of a service request should result in the addition, movement or deletion of a component of the infrastructure. This might be as simple as the change of a password (changed, added or deleted) or the introduction of new desktops. Note, that beyond this level of technology, the risks associated with the change would normally require that more formalized Change Management processes be followed.Updated CMDB
The organization may wish to ensure that its' Asset or Configuration Management database are updated during the service fulfillment process. Alternatively, the organization may defer this activity for some later day or rely upon the identification of new or modified equipment as part of a periodic discovery process.Communications
Communications will be issued regularly during the fulfillment of the request to allow the user to adjust work behaviour and priorities accordingly.Incident
No matter how closely a service fulfillment adheres to developed and tested procedures incidents can arise. These will be more likely to occur when:- the parameters under which established procedures are being invoked are different,
- the service request was the result of an incident,
- the environment is in a state of instability,
- there are relatively new components involved in the request.
In instances where some of these factors are evident the Service Fulfillment Group may wish to take extra precautions such as ensuring reliable backout and service restore procedures are available.
Escalation
An escalation involves the addition of new or more specialized resources towards the service fulfillment. It will usually be invoked in periods of high workload or when service level commitments are at risk of being breached.
Activities
SR1 - Customer Initiation
Identify service need, route request to appropriate resources for service fulfillment
A service request is a request for new or altered service and may include
- requests for change (RFC's) - such as a Move, Add or Change to one or more Configuration Items (CI's),
- requests for information (RFI's) - a HOWTO,
- and service extensions - additional features of a service.
Ideally, a Customer will reference a Service Catalogue, or in its' absence, some list of available services.
Alternatively, the need for a service may ensue as a result of a project step when, to complete a stage, a service must be secured or changed in some fashion. This could be part of an application or hardware release or the result of an approved (or emergency) change process.
SR 2 - Create Service Request
Create SR - Provide means to document, track and fulfill request for ISD services
Once the need for a service request has been identified the Customer either directly accesses an online Service Request entry form (which should validate the customer's legitimacy) or notifies the Service Desk of the need by phone or email. The Service Desk then creates the Service Request.
Where the SR should modify a current CI or create a new CI the new or updated information must accompany the request in order to update the CMDB. Once the Service Request has been SAVED an email is sent to the requester informing them that the Request is being acted upon, affirming the service commitment and to whom the request will be assigned to.
SR3 Verify and Authorize SR
Ensure requests are legitimate and cost effective.
Depending on the categorization of the request selected the Service Request will require proper authorization to proceed. That authorization may be pre-established and the SR Ticket can be acted upon immediately by the group responsible for fulfillment.
Not all cases, however, may be pre-assigned and the Service Fulfillment Group and/or an Escalation Resolution Group will need to determine the legitimacy of the request. This will usually be accomplished by verification with the line of business manager or administrator associated with the person the request, but, normally approval will be provided and the SR is updated to reflect originating the request (who should have arranged proper approvals beforehand). The SR will be closed (with the appropriate notations) if the manager refuses this.
Normally, Service Requests will be pre-authorized, in which case they will normally be initiated by a person with the authority to spend any funds associated with the request. This might be a financial administrator in the line of business or a project manager with budgetary authority. The Authority is usually defined by a Delegation of Authorities policy issued by Finance and is accompanied by a listing of those with such empowerment. That list would be available to the Service Desk or Fulfillment Group and would be codified into associated lookup tables.
Once authorized the STATUS of the request become ASSIGNED. An email is issued to the requester indicating this status.
SR4 - Service Request Fulfillment
Provide requested Customer Service within committed timeframes
To obtain assurance that the risks to the infrastructure of a service request have been adequately considered, procedures for each service need to be devised and approved through Change Management. Then, as long as the procedures are adhered to, the request can be considered be pre-approved. These procedures will be codified as tasks associated with the CTI in the Online Services system and a request will trigger the population of the task list.
The request is then assigned to the Fulfillment Group associated with the category selected. This group will then assign the request from a console. Once assigned the STATUS of the request becomes WIP (Work in Progress) and an email is sent to the requester indicating the request is being worked on.
HOWTO questions may be treated quickly if the answers are evident. Difficult question may take some time to research and may undergo escalation if a referral to vendor support is required.
The Service Fulfillment Group assess the scope of the work associated with the task list and the timeframes to complete it by referencing the Service in the Service Catalogue. Possible outcomes of this review include:
- mis-assignment - the Service Desk is informed of the mis-assignment and the Ticket is referred back to the Service Desk
- service is not offered - the service request is beyond the scope of the Service Provider. In this case the requester is notified, The SR ticket updated to indicate this and the SR status is COMPLETED.
- the Service Catalogue may need to be updated to reflect service nuances (or, indeed, the creation of a new service) - In this case the request is deemed appropriate but the Service Catalogue needs to be modified. Since the Service Catalogue is under Change Management the matter needs to be referred to the Change Manager. The Status of this request is marked as PENDING while the catalogue revision is being considered.
- If the request is IN SCOPE then the tasks associated with the fulfillment of the request are assigned and worked on under the auspices of a lead Service Fulfillment Agent
- If service cannot be completed due to Customer unavailability (i.e. Customer is on vacation or is not ready for the Service to be fulfilled) the Service Request is pended. The deliverable (SLA) clock is paused until the condition that caused the delay is resolved and the Service fulfillment can be completed.
SR5 - Assign To Appropriate Service Provider
Speedy and correct assignmentSR's are sometimes routed to the incorrect Service Fulfillment Group. This may be due to Customer confusion or incorrect data entry. When mis-assignment occurs the requests are redirected to the proper areas assigned to fulfill the task.
SR6 - Escalate SR
Ensure sufficient resources exist to fulfill Customer requestsThe Service Desk or the Service Fulfillment Group (or an automated routine) continues to monitor the status of the SR against established completion timeframes. When a pre-established percent of that timeframe is being approached the system will issue an alert to the Service Fulfillment Agent that the SR's service commitment is at risk of being breached.
Alternatively, the Fulfillment Agent might evaluate the possibility of this risk earlier in the process (perhaps with foreknowledge of equipment delivery problems).
Escalation involves the introduction of additional and/or different resources to the fulfillment of the request. As such, it introduces a complication to the established set of tasks associated with fulfilling the request. The lead Service Fulfillment Agent needs to determine whether the escalation introduces a significant deviation from established tasks. If so, the service request can no longer be considered pre-approved and should be referred to Change Management, for further consideration.
If the change is considered to be within the bounds of the existing tasks then the Lead continues to fulfill the request. The requester should be notified of any expectations of changed completion dates and partial provision of service. If desirable, the Fulfillment Agent may negotiate with the requester to limit or phase the service request.
Escalation may be iterative as additional resources are considered in subsequent considerations. At each invocation the lead Fulfillment Agent should undertake the above consideration of scope and risk.
Once the service has been fulfilled the STATUS is set to COMPLETED and an email is sent to the requester. As part of this notification the requester is told that they have 10 business days to evaluate the SR as being fulfilled to their satisfaction. At any time during this period they can CLOSE the request but, in any event the SR will be automatically CLOSED after the designated period.
Close SR
Allow sufficient time for assessment of services provided. Ultimately de-activates the Service Request.
Once the Service Request is marked COMPLETED the Customer has a defined period in which to evaluate whether the service is to their satisfaction. They may manually CLOSE the Ticket at any time during this period.
If the Customer indicates that there are issues with the service then the Ticket is closed and an Incident Ticket is created. This Ticket will reference the SR Ticket number and specify the CI associated with the SR task list as the CI at fault.
Terminology
Terms
| Term | Definition |
| Availability | Ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratio, i.e. the proportion of time that the service is actually available for use by the Customers within the agreed service hours. |
| Category, Type and Item (CTI) | Method for Classification of a group of Change documents according to three-fold hierarchical coding structure used by many organizations. |
| Client | People and/or groups who are the targets of service. To be distinguished from User - the consumer of the target (the degree to which User and Client are the same represents a measure of correct targeting) and the Customer - who pays for the service. |
| Classification | Process of formally identifying Incidents, Problems and Known errors by origin, symptoms and cause. |
| Change Management | Process of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption. |
| Configuration Item (CI) | Component of an infrastructure - or an item, such as a Request for Change, associated with an infrastructure - that is (or is to be) under the control of Configuration Management.CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. |
| Configuration Management Database (CMDB) | A database that contains all relevant details of each CI and details of the important relationships between CIs. |
| Core Business Process | A process that relies on the unique knowledge and skills of the owner and that contributes to the owner’s competitive advantage. |
| Critical Success Factor (CSF) | Critical Success Factors - the most important issues or actions for management to achieve control over and within its' IT processes. |
| Customer | Payer of a service; usually theCustomer management has responsibility for the cost of the service, either directly through charging or indirectly in terms of demonstrable business need. |
| Environment | A collection of hardware, software, network and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform e.g. test, production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse, manners. |
| Impact | Measure of the business criticality of an Problem Often equal to the extent to which Incidents lead to distortion of agreed or expected service levels. |
| Incident | Any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service. |
| Known Error | An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a Change. |
| Mean Time to Repair (MTTR) | The elapsed time to restore service measured from either the time of the failure or the time the failure was reported to the time the service was restored to the Users satisfaction. |
| Priority | Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency. |
| Process | A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal. |
| Pre-approved service request | A request which has been previously considered and approved through ISD Change Management authorities as introducing negligible risk to the production environment. The original approval will include a set of Tasks by which the service will be fulfilled and the pre-approval requires adherence to those procedures to qualify as pre-approved. |
| Pre-authorized service request | A request which is pre-authorized for fulfillment by the line of business authority wherein the service request is to be fulfilled. This usually denotes pre-established budgetary limits to secure resources associated with the request but might also include access to facilities, use of equipment, etc. |
| Process Control | The process of planning and regulating, with the objective of performing a process in an effective and efficient way. |
| Release | A collection of new and/or changed CIs which are tested and introduced into the live environment together. |
| Request for Change (RFC) | Form, or screen, used to record details of a request for a Change to any CI within an infrastructure or to procedures and items associated with the infrastructure. |
| Resolution | Action that will resolve an Incident. This may be a Work-around. |
| Role | A set of responsibilities, activities and authorisations. |
| Service Level Agreement | A written agreement between a service provider and Customer(s) that documents agreed services and the levels at which they are provided at various costs. |
| Service Level Management | Disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to supported IT users in accordance with business priorities and at acceptable costs. |
| Service Request | A request for a change, usually both common and straightforward, to be made to a service. |
| System | An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. |
| Urgency | Measure of the business criticality of an Incident or Problem based on the impact and on the business needs of the Customer. |
