Service Level Agreement (SLA)

Service Level Agreement (SLA) is a legally enforceable document that defines the minimum performance criteria a service provider promises to meet while delivering a service to customer. Typically SLA is used to set out remedial actions to be taken and penalties to be imposed if performance metrics and service quality agreed to by both parties fall below the promised criteria. SLA may be used as a measurement tool as part of the legal contract.

The following are the benefits of a Service Level Agreement (SLA):

• Establishes two-way accountability for a delivered service.
• Creates levels of service that are negotiated and standardized.
• Enables customer to be able to control the cost if justification of service provider in spending is clear.
• Makes the terms and conditions clear in case of discrepancies between both customer and service provider.
• Clearly clarifies the business goals to be achieved by customer, and management and planning of business will become easier and more feasible if the goals and objectives are clearly defined.
• Enables the performance of delivered services to be more realistic to customer in expectation.

Five key steps involved in change management process development

There are five key steps involved in change management process development, namely:

• Filtering Requests for Change (RFCs) – To specify the details of needed change program and submit it to the Change Advisory Board (CAB) for consideration. CAB is an entity, which includes representatives from many divisions, such as the server and network operations, security authority, application development and database management. Other members may represent legal, operations and administrative departments. Change program must be evaluated and studied for its practical effect and feasibility to avoid any duplication of efforts or vain implementation.
• Assessing the Impact of Changes – After we have the list of requested changes, we need to prioritize the change requests by assessing the cost involved, benefits, perceived risks and possible impacts of the change request.
• Authorizing Changes – Business partners are normally engaged in the process, we may use their expertise in evaluating the impact of the whole changes program. The CAB must advise deeper insights to the change manager before the changes programs are approved and scheduled.
• Reviewing Changes – We can review the entire process to point out those things were done very well and not so well after the changes have been implemented. This practice helps us to revamp the change management process and gain better improvement. Back-out procedures is always needed if applied changes do not perform as expected and create negative results.
• Closing Requests for Change (RFCs) – Finally the change is reviewed and accepted by the user who has submitted the Request for Change, the RFC should be closed. All configuration changes should be properly and systematically documented, and all approvals, comments, testing plans, back-out plans and other workflow-related documentation should be kept according to company policy.

Problem, change & service request management

Problem Management is concerned with identifying the root causes of incidents and thus to avert or at least minimize the adverse impact of incidents by resolving underlying problems that are caused by errors within the Information Technology infrastructure, and to prescribe proactive measures to prevent recurrence of incidents related to these errors.

Problems that come to the attention of the Service Desk must be classified according to their meaning in a resolution framework. Service request management needs to determine the category, possible impact, urgency and priority of the request raised by user. Request basically falls into two types, namely information request and service request. Information request is mostly concerned with certain circumstances that no fault with the current system or any configuration is required thus can be dealt immediately by the Service Desk. Service request is usually attended while minor changes or alterations that is already mandated within the scope of the existing system configuration. In this case, request will be forwarded to the Desktop Support Group to be dealt with.

If problem is identified critical or high level in severity, problem management will get involved in resolving the underlying errors. In case the system or infrastructure needs to be upgraded, for example, new deployment of hardware, patching of operating system, reconfiguration of system and etc, it will be then handed over to change management for planning and recording change requests, assessing the potential impact, cost required, benefit and risk of a change, obtaining proper approval. While everything is in order, change management will start managing the implementation of a change, monitoring and reporting on the implementation, and reviewing and closing change requests.