Service Management

Willcocks et al. (1999) have collated a Top Ten list of the main reasons for failure or negative outcomes in IT outsourcing deals and refer to these as risk factors:
1. Treating IT as an undifferentiated commodity to be outsourced;
2. Incomplete contracting;
3. Lack of active management of the supplier on contract and relationship dimensions;
4. Failure to build and retain requisite in-house capabilities and skills;
5. Power asymmetries developing in favour of the vendor;
6. Difficulties in constructing and adapting deals in the face of rapid business / technical change;
7. Lack of maturity and experience of contracting for and managing ‘total’ outsourcing arrangements;
8. Outsourcing for short-term financial restructuring or cash injection rather than to leverage IT assets for business advantage;
9. Unrealistic expectations with multiple objectives for outsourcing;
10. Poor sourcing and contracting for development and new technologies.
(Willcocks et al., 1999, p. 290).

It is typically at the system level that service failures are detected. The helpdesk staff gets a call that the customer quotation system is down. The included services are not apparent to the helpdesk person and so system level procedures will be used. Every failure must be treated as an incident. Formal incident recording, tracking, management and monitoring will be needed if an organization is to be able to understand its current performance level and also develop the potential for long-term improvement of its incident management. Only in the case of life-threatening, hazardous situations should incident recording not be commenced immediately.

Historically IT staff have been disproportionately involved in service continuity as they were the suppliers of IT services that were particularly unreliable. Now that IT hardware is much more reliable, the emphasis has changed to focus on the complexity of the IT installations and the dependence for these services within the organization.

There are several challenges every business user should facing about managing the SLA (Service Level Agreement) compliances

• Establish performance-based SLAs with your service providers that reflect how you actually use business services, instead of just measuring the availability of generic IT components.
• Independently verify real-time SLA compliance so that you will have first-hand knowledge of how well your service providers are performing.
• Understand the quality of your end-users’ experience with each particular application or service.

However this challenges facing a lot of difficulties about how to measure the network compliance

"...IT Service Management (ITSM) related costs account for between 65%-80% of all IT expenditure. Almost more than three quarters of every IT budget is spent keeping the application lights burning and the wheels of the IT machine turning. Most of this money goes on labor costs..."
Rob Addy, Effective IT Service Management

Addy also stated pro and cons between using ITSM or not, here’s the reason:

Why we should use ITSM

1. Structured approach
2. Good foundation upon which to build
3. Analyst support/Easy ride for the CIO
4. Can be used to help prevent knowledge loss from the organization
5. Prescriptive nature means that you don’t have to think too Much
6. Allows for job specialization
7. Requires IT management to formally review all processes delivered by their teams
8. Encourages the use of flow charting techniques to map out business processes
9. Consistent usage of defined terminology across the industry promotes understanding and simplifies communication
10. Traceability and accountability

Does your company ready to implement effective Incident Management process? Here is common problem that your company will face:

Common Incident Management issues include:

1. Extended resolution times
2. Inconsistent service delivery/approach to resolution
3. Incomplete fixes/Incidents needing to be re-opened
4. Too many touch points required to resolve an issue
5. Inefficient trouble shooting procedures
6. Poor visibility of impact of incidents upon the business
7. Routing errors/Multiple re-assignments
8. Inappropriate prioritization of incidents
9. Inefficient workload management
10. Poor communication of outages and their impact
11. Lack of a closed loop process i.e. no formal closure
12. Continuously re-inventing the wheel
13. Ineffective use of knowledge repositories
14. Poor categorisation/classification of incidents
15. Buck passing between functional/implementation groups
16. Lack of visibility of incident status
17. Temporary workarounds being left in place as permanent fixes
18. Unnecessarily high levels of follow up/chase calls
19. Availability of Help Desk staff
20. Skill levels of Help Desk staff
21. Single incident management process irrespective of nature and scope of incident e.g. Critical service impacting incidents treated in the same way as a user that has forgotten their password.

Any other experience? This list is taken from Rob Addy book’s Effective IT Service Management. But I’m sure that the fact is usually worst than this.