Blog Enterprise Service Management - Making it work: The Adoption Journey

Enterprise Service Management (Beyond ITSM) - whitepaper

We have been at the forefront of Enterprise Service Management since its evolution out of the traditional IT Service Management sphere.

 

 

With organizations operating multiple legacy systems in the majority of functional areas, the big bang approach for ESM is in the minority. From our experience of delivering ESM in large organizations and the international best practice research which we conduct, there are two mainstream approaches for the ESM adoption journey:

 

  • Sequential – Working across the company to implement ESM, department by department.
  • Prioritized – Selecting a small bundle of key services from across a number of different departments to tackle ESM in order of business priority. This gives the end user community the highest possible value “version 1.0” that can be built upon over time.

 

A staged approach is recommended as more realistic and likely to succeed, but it is still a long journey. Like many other strategic technology-driven change projects, you only really get one shot at making it work. If it fails, a second shot will meet with much increased resistance.

 

As every organization has a different structure of departments, there is no off-the-shelf roadmap for which departments and services should be tackled first, but experienced guidance is a must.

 

If you plan to implement ESM sequentially, the first department you select will become a template for further roll-outs; useful evidence of the value of service management “beyond IT” that will help you to sell the value to the next department in the roadmap. Bear in mind that the relationship with each business function does not end with the inclusion of their services in the ESM portal. There will be an ongoing need to help them optimize their service portfolio over time, so the IT department cannot simply “cut and run” after the initial implementation.

 

A prioritized approach that picks out key services from across the full spectrum of internal services will deliver more value to the end user community more quickly, but you will have to deal with a larger number of departments and stakeholder simultaneously.

 

The success of ESM is largely reliant on the expertise and attention of your IT staff, so your adoption strategy should take the bandwidth of your IT people into account. The most obvious starting points are the departments that are almost entirely ‘back office’ functions (and therefore have the largest portfolio of internal business services) – HR, Facilities Management, Administration, Procurement, Finance and Legal. As such, this is where the greatest value is to be gained from an ESM program.

 

Departments such as sales, marketing and customer service are more customer-facing, have fewer business-facing services, so these should be brought into the ESM program later in the process. It is essential to draw up a high-level roadmap that shows the order in which you will build up your ESM program.

 

General implementation process

 

Identify the service domains in your business – the distinct departments in your organization which provide internal services to other departments. This list is the starting point for building a roadmap. From here, you should engage with business function stakeholders to identify the “standard” services they offer internally to the business. IT needs to develop an understanding of what the business function does, for which internal customers, and how they do it. IT also needs to use domain-specific terminology, i.e. speak the language of the business department you are engaging with. Terms like ESM, service catalog, ITIL and ITSM will be unknown to them, and technical terminology and abbreviations are a turn-off for all but a few outside of IT. Sometimes there are direct conflicts between IT terminology and terminology in other domains that IT people must be aware of. For example, IT uses the word incident to describe a break in a service, whereas HR people will think of an incident as a physical accident.

 

Although the process will vary from organization to organization, the general flow should look something like this:

  1. Sell the benefits of having an overall enterprise-wide system, but also sell the specific benefits to each business function. Create evidence with a proof of concept.
  2. Compare and contrast what the service domain does with what IT does. What is the same? What is different? Find the common ground but also what is unique about the particular department.
  3. Identify the demands that other departments make of them. These are often difficult to define as many business functions are not service-oriented and have an ad-hoc approach to external demands.
  4. Draw up a list of business-facing services and agree which should be added to the enterprise service portal. If necessary, lay these out in phases for staged inclusion in the enterprise service catalog.
  5. Model the processes by which these services are executed, adding in SLAs and escalation structures to ensure smooth operation in a way that meets the expectations of internal customers.
  6. Add these services to a test area in your Enterprise Service Management portal.
  7. Test with a selected group of stakeholders taken from the end user community. Make refinements until it is accepted by the test group.
  8. Move the test version into the live environment, making it accessible to the wider end user community by publication in the enterprise service portal.
  9. Help the service domain to tweak the interface and supporting processes, establish reporting, and institute continual improvement by listening to internal service customers.

 

You can read more about Enterprise Service Management in this whitepaper:

 

 

Download the whitepaper

 

 

 

Add new comment