Request Fulfillment Table of Contents
A Service Request is a request for a move add or change (MAC) to an existing service offered by a service provider. It usually involves a low risk modification to an IT infrastructure which is accomplished through the invocation of a set of well established procedures. Process Requires Re-writing for conformance with ITIL Version 3. This process was previously called Service Request and in ITIL version 2 was covered within incident Management.

Introduction to Request Fulfillment

Request Fulfillment is a process within the Service Operation module of the ITIL Service Lifecycle.

Request Fulfillment

• Employ best practices as a guide in developing re-vitalized service management principles and practices
• Provide an appropriate level of review and approval based on request type
• Establish automated and/or self-help methods for fulfilling service requests wherever feasible (e.g. automated password reset, self-help knowledge bases)

Scope

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.

The crucial elements of a standard Change are that:

• the risks associated with the change should be low, well known and documented
• the tasks are well known and proven
• authority is effectively given in advance
• the train of events can usually be initiated by the Service Desk
• budgetary approval will typically be pre-established or within the control of the Change requester.

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:

• a request for service
• a request for information
• the reporting of an incident

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.

Possible Coverage by Service Request Procedures

• the connection for electronic and/or electro-mechanical devices used for data and voice transmission. This includes:
  • Application: All requests for new applications or release upgrades.
  • Database: Requests related to database files, such as adds, deletions, re-organizations, or maintenance.
  • Hardware: Requests to install, modify, de-install, or move IT production equipment or maintenance of distributed or host equipment.
  • Network: Requests related to connectivity, cabling, connectors, adapters, or configuration settings or maintenance.
  • Network Hardware: Requests to install, modify, de-install, and re-locate production network equipment.
  • Network Software: Requests to upgrade, change, or modify network software.

• Processes: Requests to change or improve the definition or documentation of defined business processes. Modifications to enablers, guides, inputs or outputs should be reflected in the process documentation.
• Software: Requests to modify operating systems; install or de-install program products and utilities; upgrade or maintain distributed or host equipment; or any requests to change data format for planned uploading.
• Telephony: Requests to install, modify existing set ups, de-install, or relocate PBX equipment and services or maintenance.
• Password Setups and resets: requests to reset passwords
• RFC: if procedures do not follow the established workflow they should be referred to the appropriate Change agent creation on an RFC.
• New Service Initiation: request for new services should be referred to Service Level Management for consideration
• Service Catalogue Maintenance: the service descriptions are frequently cited in a Service Catalogue along with information on how to request the service. The Service Request process is responsible for forwarding suggestion for modifications to the service catalogue to Service Level Management.

Not Covered by Service Request Procedures

• An Incident is covered by the Incident Management process
• The Service Request process is designed to accommodate "one-offs" or the modification of a small number of similar Configuration Items. Where large numbers of CI's are involved, the risks associated with the change are considered to be more than negligible and entail coordination activities beyond the scope of the approved process descriptions. These changes should be brought before Change Management and may even be accompanied by a Release strategy involving Release Management principles and procedures.
• A Service Request which does not have a set of procedures and/or tasks which have previously been approved by an authorized Change Authority.
• Service Requests which expect to deviate from approved procedures. These should be submitted on an RFC through Change Management

Relationship to Other Processes

Configuration Management

The SR process (as determined by the categorization which is invoked will be documented and maintained in the CMDB.

Change Management

Incident Management

Service Level Management

• the scope of each service
• the responsibilities with regard to the delivery of the service
• how the service is accessed
• variations in the level of service offered and associated costs
• what performance can be expected at various service levels

Suggested Policies

• The Service Desk is responsible for meeting service expectations with regard to Service Requests. This implies end-to-end ownership of the request even though it is processed by a multiple service areas,
• There should be provision for Emergency Service Request - When a process or system is unusable and must be corrected as soon as possible, the emergency or exception process for handling a Service Request is carried out because there is no time for the "normal" process. After the emergency, a Service Request is completed which documents proper approvals,
• Requested services should be described in a Catalogue of Services, the level of service to which the IT Provider is committed to maintain and the obligations of all participants,
• All participants in the end-to-end fulfillment of a service request should have their obligations and service commitments detailed and agreed to in Operational Level Agreements (OLA's).
• To ensure proper coverage, Service Fulfillment groups should contain more than one person. Notification of an assigned Ticket can be through automatic notification.
• Each Service Fulfillment Group will define and maintain a workflow consisting of a series of ordered tasks for fulfillment of the service request. These "tasks" will form the service definition which will be authorized by Change Management and documented as a "pre-authorized change" and thereafter maintained under Change Control procedures. The documented procedures may be recorded in the CMDB. Each workflow (approved through Change Management) should describe criteria for the completion of the request. One of the criteria should be customer sign-off.
• There should be a method by which Users can easily review the ongoing status of their Service Request,
• There should be a method to escalate the Service Request which will be triggered as service commitment dates are approached.
• Prior to the CLOSURE of the SR, users should be provided the opportunity to re-open and/or escalate a COMPLETED Service Request within a specified number of days.

Scaling

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.

Concepts

SR Categories

SR Status

Workflow Automation

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:

• Better timing and utilization of service delivery resources,
• Redundant efforts can be eliminated,
• Improvements in the reliability of service delivery and decreasing the need for corrective action,
• Certifying processes and the automating the workflow will detect and eliminate issues before they become problems by following corporate guidance. If an issue does arise, a predetermined escalation path with priorities can be initiated insulating the user from a negative experience before it happens.

Communication

• Affirmation that IT services are delivered in compliance and validated with documented procedures
• Identification of contact points for the user to see who owns the current status of the request
• Ability to depend on the performance of IT services in a timely manner
• The value of IT services are supported through metrics and justify charges for services
• Reduce the need for retraining the client on how to request IT services and obtain status information
• A high level of confidence in the delivery and performance of the IT department since IT's goals and objectives are aligned with the client's business needs.

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:

• STATUS=Assigned,
• STATUS=WIP,
• STATUS=Resolved,
• STATUS=Closed,
• a User changes a commitment date.

Service Level Management

Escalation Guidelines

Roles

Service Request Process Manager

• primary source of management information on the Service Request (SR) process.
• manages the relationship among the Service Desk, service areas and vendors involved in service fulfillment and, is responsible for the adequate skill levels and performance of this process and supporting SR Tools
• provision and operation of toolsets (e.g., Remedy Help desk, Service Catalogs) to support the SR processes
• retrieves and reviews data on SR performance.
• minimizes adverse effects of incidents on service levels by...
  • provide a point of escalation for customer concerns with service fulfillment activities
  • ensure that the SR process and working practices provide value to the Customer
  • ensure that stakeholders are represented in SR processes
  • ensures customer satisfaction with the functioning and behavior of service area personnel

Service Desk

• Actively encourages direct entry of SR's through any automated, web based tools
• Ensures integrity of any categorization of SR selection and self-help and owns CI associated with a CTI table. Acts as Change Initiator in advancing any changes to CTI table.
• Monitors applicability and usefulness of Service catalogue and reports inconsistencies to Service Level Management

Service Fulfillment Group

• Acts as CI owner of pre-approved Service Request
• coordinates activities and sub-assignments associated with fulfilling the SR
• minimizes disruption to line of business in fulfilling the SR
• ensures adherence to authorized procedures and work practices associated with the SR
• recommends changes to pre-approved task sets and acts as Change Initiator in obtaining approval for change
• maintains individual knowledge, skill level and performance necessary to complete the SR
• accurate and timely identification of Vendor Service fulfillment involvement
• monitors SR fulfillment against service commitment expectations and undertakes escalation when required to ensure completion to request
• ensures customer satisfaction by keeping Customers informed throughout the service fulfillment process
• ensures completeness and accuracy of SR Ticket

Measuring

Goal Indicators (targets)

Measures
• A measured reduction of the impact of follow-up incidents and changes attributable to Service Requests
• A measured reduction in the average time to fulfill service requests
• Decreased variation in the average time to fulfill service requests (i.e. setting expectations)
• A measured reduction in the cost of fulfilling service requests
• Performance Indicators (outcomes)
• Reduced time from initial service request initiation to COMPLETED status
• Reduced Idle time (i.e., STATUS=Pending) during service fulfillment
• Percent of HOWTO questions answered at First Point of Contact
• Percent of SR mis-directed

Breakdowns

• By CTI - (i.e. type of SR)
• By Line of Business (LOB) requesting SR

Metrics

• Time to fulfill request measured from STATUS=NEW to STATUS=COMPLETED expressed as number of business days
• Time service request in various STATUS categories expressed as number of business days
• Percent of time service commitment achieved

Breakdowns of Above By

• CTI
• Line of Business represented by service requester
• FPOC agent handling the Incident (and hence responsible for its' completion)

Measurement Issues

• Overlaps between Service Request and Incident processes as well as Service Desk and application incident resources need to be coordinated to ensure complete reporting
• Without established benchmarks of SR Management process performance prior to the introduction of ITIL incident management methods, determining the degree of improvement will be mostly subjective

Processes

Service Request Summary Process

	Controls Categorization Structure Budget authorities SLM Guidelines Service Fulfillment Contracts
Inputs Purchasing Plans Service Catalogue	Activities Customer Initiation Creation Verification and Authorization Fulfillment Assignment Escalation Closure	Outputs Service MAC Updated CMDB Communications Incidents Escalations
	Mechanisms SR System Fulfillment Agents

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.

Controls

• 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.

Mechanisms

• 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.

Outputs

• 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 assignment

SR'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 requests The 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.

Appendix

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.