Wednesday, March 27, 2013

Business Information Systems



Q2.                 

SLA

This Service Level Agreement (SLA) is an agreement made between Computacenter and Tradeteam, referred to as the client to cover the provisions provided by Computacenter. The purpose of this agreement is to ensure the reliability and stability of all services covered under this SLA.
Period of agreement
This agreement will be effective from DD/MM/YY and prepared to be valid for 12 months thereafter or until the agreement is renegotiated following the acceptance by both parties.
Review procedure
This SLA will be reviewed for any modification or change at any time by the request of either party in accordance with the change management process and any changes will be agreed and made appropriately.
Service description
The aim of this SLA is to provide a basis for close co-operation between Computacenter and Tradeteam, for the support services, thereby ensuring a timely and efficient support service is available to Tradeteam end users.
Tradeteam IT service current goals include:
• develop and maintaining the service catalogue;
• develop and maintain the policies and procedures document;
• exploit performance reports for problem management;
• identify and implement the best integrated service management tool;
• keep nurturing the service culture;
• keep focus on supporting the business and its projects.
The intended benefits for the Tradeteam are as follows:
·   Increased visibility of costs incurred through IT suppliers
·   Clear relationships between Tradeteam and its IT service provider
The service will be provided by a technically qualified Computacenter engineers. An incident needs to be normally resolved and closed on the first visit. Computacenter shall provide a set of core IT services which are secure, up-to-date, and easy to use and meet the actual and perceived needs of users.

Scope of the agreement
Services covered by this agreement include:
·         tradeteam’s operational services
·         Support Desk operations
·         Application and software support services
·         Maintenance of server systems
Service hours
Ensure Computacenter operates in a consolidated manner that the service desk and on call support for critical incidents are functional 99% of the time in a 24x7x365 environment.
The Maintenance Service need to be available between 09.00 and 17.30 Monday to Friday, excluding Public and Bank Holidays, unless specified.
Service availability
This SLA is another step in the effort to achieve that objective. It is Computacenter intension to continuously apply tradeteam’s quality standards to improve the client service in all areas whenever possible. Computacenter should guarantee to be available at all times. This 100% guarantee covers the availability of all services including the service desk and, call support, software services, maintenance and support of the AS/400s and data backup incidents.
Reliability
Actual levels of service are to be compared with agreed target levels on a regular basis by both Tradeteam and Computacenter.  In the event of a discrepancy between actual and targeted service levels will lead to unreliable conditions of the operations. Tradeteam and Computacenter are expected to identify and resolve the reasons for any discrepancies in close co-operation.
Service performance
Tradeteam and Computacenter have a clearly defined and mutually agreed level of service to be provided. This will provide a strong basis for a better working relationship between the two parties. The SLA program is designed to increase transparency and accountability.
Service performance, service level targets, actual results and outcomes will be evaluated periodically through a monitoring procedure including annual user satisfaction survey, internal reviews and feedbacks and annual progress reports. The results will be processed and analysed in order to improve the services supply.
The following Key Performances Indicators (KPIs) will report annual service performance.
  Service availability (up-time) of key services
  Level of user satisfaction with IT services identified by users (from annual survey)
  Internal reviews of each  departments in relation to the service performance
  Feedback from comment and feedback forms will be monitored

Security
The Computacenter manages the security of the database system and associated components. All necessary precautions should have been taken to ensure access to the technical infrastructure, both physical and through networks, are restricted to authorized personnel only and that the system is protected from unauthorized users, systems, agents and viruses.
In an event of a breach of security Computacenter should take immediate steps to protect the integrity of the systems and the security of the data.
Contact points and escalation
When service falls below the agreed level targets identified under the section of ‘service scope’ and delivery of unsatisfactory service will cause complaints by third party users and also internal departments. In such situations joint meeting between the parties will be used to discuss and resolve problems that resulted. The Company will use all reasonable endeavours to ensure a satisfactory service, in the event the services remain outstanding beyond the agreed levels. The escalation path for related incidents or services are not resolved would be to the IT Service Delivery Manager or IT Service Delivery team.
If the incident or problem proves to be within the associated services, the user is responsible for contacting the appropriate local parties to update all affected users on the investigation and resolution.
Responsibilities
The Computacenter should provide high quality and reliable IT services which are cost-effective, based on best practice and meet the requirements of the Tradeteam. Furthermore it is the responsibility of the Computacenter to ensure all necessary precautions are taken to protect Tradeteam’s information.
Appropriate meetings need to be arranged between Tradeteam and Computacenter as necessary.
Tradeteam will provide 1st level support to Computacenter; such support covers any incidents with regard to the agreement.

OLA-1
This is an Operational Level Agreement between Service Desk and the Network Support team (2nd Line) for the provisioning of IT services required to support and sustain. This shall remain valid for 12 months and will be reviewed annually.
The purpose of this OLA is to ensure that correct procedures are in place to enable supporting the service as agreed. This OLA:
·         Serves as a reference document
·         Defines roles and responsibilities
Support service description
The purpose of this is to ensure that the proper elements and commitments are in place to provide consistent service in network section.
Scope of the agreement
·         System operations, administration and network connections
·         IT desktop and custom services
·         Systems Operations,
Service hours
The target availability of the service is 95 %.
Service targets
Supports the day-to-day operations through maintenance in the areas necessary
OLA-2
This is an OLA between Service Desk and Server Management team for the provisioning of IT services required to support and sustain.
Support service description
These services are necessary elements of the service to function the whole operations of the company.
Scope of the agreement
·         Desktop Support, Infrastructure
·         Server support, and custom services
·         Application Support, and Consulting and Procurement Services
Service hours
The target availability of the service is 95 %.
Service targets
Effective support of in-scope services is a result of maintaining consistent service.

Q3.                 

Change Management Process

Workflow

The broader Change Management process shall be organized as shown in the Figure 1. Change Management Process Workflow.

















Figure 1: Change Management Process Workflow.

Composition of CAB and eCAB:

Clear definition of the roles and the responsibilities will be highly important for the proper implementation of the Change Management process and the pre-planned Change Models. The CAB and eCAB will be composed of number of different members having different roles and responsibilities such as listed below:
1.    Change Administrator:
·         Supports the change manger
·         Maintains the records
·         Prepares the reports
2.    Change analyst
·         Provides recommendations
·         Provides technical knowledge
·         Impact assessment
3.    Change Authority
·         Authorizes the change
4.    Change Manager
·         Oversees the overall Change Management process
·         Coordinates day-to-day execution of the process
·         Schedules change implementation
·         Accepts and classify the RFCs
·         Chairs the CAB and ECAB meetings
5.    Requestor
·         Submits the RFCs
·         Provides the required information for the change

Operations:

The requestor collects all the information about the change and prepares the Request for Change (RFC). Then it is submitted to the Change Manager. Change Manager Reviews the RFC and determine it whether to be a valid one or an invalid one. If the change required is valid, then the change manger needs to determine whether the required change is a normal change, a standard change or an urgent change. Then the change implementer has to implement the change, while the change owner can monitor the implementation. As the implementation goes on the owner of the change can realize whether the changes has met its objectives by reviewing the change. If so, the change owner can close the record and notify the requestor that the change is closed.
Evaluation process can be carried out by the external process manager where the impact, risks, cost benefit analysis of the change will be made and an assessment will be delivered as an output. This assessment results can be reviewed by the change owner which can make change manager to schedule a CAB meeting or an eCABmeeting as per necessary. Then change manager will have to do the necessary evaluations and present the necessary documentation including the project charter, schedules and other information relevant. Then the change authority will authorize the change where the change manager will have to be involved in the negotiation process in order to plan the implementation of the change.

Change Models
Three main types of requests for change can be found: Standard, Normal and Urgent.
In this Change Management procedure, three different change models have been presented: one for the normal and urgent requests and the other for the standard requests.

Change Model for Normal and Urgent Change Requests

Normal change request is followed by all the usual activities found in Change Management. However, they include a separate procedure for handling authorization. When a normal Change request is submitted, the RFC is subjected to a thorough assessment and a Change Advisory Board (CAB) meeting is convened to discuss about the change before being submitted for authorization.

Even though the Urgent change request is similar to the normal change request, the activities involved in the process must be executed much faster than that of a normal procedure due to the urgency concerns. When an urgent RFC is submitted, a smaller Emergency Change Advisory Board (ECAB) with immediate availability is to be convened. Typically the procedures like change assessment may be allowed to include fewer tasks than that of the normal procedure. Nevertheless, using a single Change Model will be adequate.




Figure 2. Change Model for Normal and Urgent Change Request.





Change Model for Standard Change Request

As per ITIL definition a standard change is a change which is pre-authorized by the Change Managementschedule. Basically the Standard changes are with low risk, less time consuming and less expensive. Some standard changes may do not need RFCs.













Figure 3. Change Model for Standard Change Request.



Key Performance Indicators for the Change Management process

Balanced Scorecard

This is a management tool developed by Robert Kaplan and David Norton. This tool enables a Strategy to be broken down into Key Performance Indicators. KPIs are important to benchmark the performance of the company after the change is implemented, in order to evaluate and demonstrate how well the Strategy is being achieved. A Balanced Scorecard has four key areas under which different KPIs have been defined. These can be used in evaluating the value being added or the extent of the success being met through the change.

Financial perspective

Table 3.1: KPIs in the financial perspective
Information Technology (IT) expense as % of total administrative expense

Average IT cost per customer

Cost of IT as % of company revenue       

Average cost of IT per PC 

Cost of IT as % of company revenue       


Customer perspective

·         Repeat orders
·         Number of customer complaints
·         Returned orders
·         On time deliveries
·         Customer satisfaction index

Internal business perspective

·         Increase in capacity utilization (litres transported per one shift)
·         percentage defective products returned
·         reduced waste
·         efficiency improvements
·         reduction in unit cost (cost per one mileage)

Learning and Growth perspective

·         Extent of employee empowerment
·         Number of new distribution channels adopted
·         Number of new information systems introduced
·         Percentage of new sales achieved through new distribution channels
·         Number of new customers





Q4.    Concise

At the end of the tutorial and specifically upon the completion of the individual and group tasks   the following unit learning outcomes could be achieved:
Group Task:
·         Team work experience
·         Analytical skill development achieved through the analysis of the case study
·         Application of ITSM theories into real world scenarios
Individual Task:
·         Knowledge and the skills in devising Service Level agreements and the Operational level agreements.
·         Skills in developing a change management procedure
·         Identifying the roles and responsibilities of the Change Advisory Board and the Emergency Advisory Board.
·         Identifying the key performance Indicators relevant to the change manage process
General Learning Outcomes:
Role of the technology played within the organisation is growing very fast. Therefore the technology adopted by an organisation has to be competitive enough to meet the expected performance and service levels by the customers. In catering this requirement the It departments will to demonstrate their capability in catering the organisation with a high end value.
However in most of the cases it is more likely than not that it will not be cost effective for an organisation to allow funding resources and skills to meet these requirements to build a competent IT department in house. Therefore, the It solution is most likely will be in the form of out-sourcing. Referring to the case we used in this tutorial exercise, the trusted IT service partner chosen by tradeteam was Computacenter.
The appendices attached herewith this assignment reflects the provision of guidance by the course which made this work towards a success.

References

AXEL KOLTHOF, Mike Pieper, Ruby Tjassing. 2008. ITIL V3 Foundation Exam: The Study Guide. Van Haren Publishing.
Computacenter delivers for Tradeteam. 2013. [online]. [Accessed 17 Mar 2013]. Available from World Wide Web: <http://www.computerweekly.com/feature/Computacenter-delivers-for-Tradeteam>
FAST ITIL TEMPLATES. 2012. [online]. [Accessed 17 Mar 2013]. Available from World Wide Web: <http://www.fastitiltemplates.com/service-transition/change-model.html>
ITIL – Example emergency change management. [online]. [Accessed 17 Mar 2013]. Available from World Wide Web: <http://www.ucisa.ac.uk/~/media/Files/members/activities/ITIL/servicetransition/chanage_management/ITIL_an%20example%20emergency%20CM%20procedure%20pdf>
Office of Government Commerce, 2007. Service Operation Book (Itil). 1st ed. The Stationery Office.
McBride, N. (2009). Exploring Service Issues within the IT organisation: Four mini case studies. International Journal of Information Management, 29, 237-243.


Appendix 01- ITOSM Tutorial 1

Case study analysis
Analyse the scenarios provided to complete the following table, clarifying points with the lecturer as necessary.
Company name


Identify the type of IT service provision (internal, outsourced, hybrid).


Give the number of users, sites, devices, applications, incidents, projects, IT staff.




List all IT product and service suppliers and other relevant contractual relationships.




Identify any standards or best practice guidance in use for project management, ITSM, EA, interoperability or quality management. Describe the level of maturity of adoption.


List known business priorities for short, medium and long term.




List key stakeholders for IT services.



Describe the IT management and governance structures. (Draw a diagram on the reverse.)



State the capital and revenue budgets for IT services and projects.




List the IT services provided.



Describe any legal, regulatory or other external constraints on IT service provision.



Assess the strengths of the IT service provision as described.



Assess the weaknesses of the IT service provision as described.



 

















Appendix 02- ITOSM Tutorial 2

Case study analysis
Analyse the scenario provided to complete the following table, clarifying points with the lecturer as necessary.
Identify the type of IT service provision (internal, outsourced, hybrid).


Give the number of users, sites, devices, applications, incidents, projects, IT staff and any known budget parameters.




List known business priorities for short, medium and long term.



List key stakeholders for IT services.


Describe any legal, regulatory or other external constraints on IT service provision.




State the business aims that led to ITIL adoption



State the anti-ITSM views that limited ITIL adoption


Assess the strengths and weaknesses of the IT service provision as described.






Appendix 03- ITOSM RADM Tutorial





Appendix 04- ITOSM SLA-OLA Tutorial
SLA/OLA Development
Work with your coursework group to analyse the scenario provided, clarifying points with the lecturer as necessary.
Scenario
A pharmaceutical company plans to implement a new IT service to allow its R&D facilities in Europe, North America and Japan to share data on drug development progress. The company has selected its product vendor and is now selecting an IT service provider to host and deliver the vendor’s off-the-shelf system. You are developing the SLA for your company’s bid to host the service. The main components of the new service will comprise:
1.    A web site for data entry and routine analysis that is accessible from standard browsers or Android devices;
2.    A data import utility that allows output files from local R&D databases to be transformed and loaded;
3.    An analysis suite that allows production of complex queries and statistical analysis;
4.    A service desk to resolve basic incidents and requests (password resets, diagnosing simple connectivity faults, creating and disabling user accounts) and refer more complex incidents to second line support;
5.    A second line support team to advise on complex analysis queries and deal with incidents the service desk cannot resolve;
6.    A third line support service from the product vendor for incidents the second line support team cannot resolve;
7.    A service continuity plan comprising dual servers with resilient failover, daily full backups, hourly backups of transaction logs, weekly recovery testing and 4-hour recovery target in the event of total service failure;
8.    The hardware and software for the website and database platform, hosted by the IT service provider;
9.    User training for existing and new company staff and technical training for internal support teams.
What can you answer for the following headings? Where do you need further information and who would supply it?
SLA
o   Scope, detailed service description
o   Service hours and availability targets
o   Responsibilities of each party
o   Performance targets
o   Service continuity plans
o   Security aspects
o   User support and escalation routes
o   Change management methods and targets
o   Service report and review methods and targets
OLAs
What internal OLAs do you need? Which team(s)? What further detail do you need to draft the OLAs?
Appendix 05- Case Study
















No comments:

Post a Comment

Note: Only a member of this blog may post a comment.