Case Study: Enterprise Service Management

Case Study: Enterprise Service Management

Summary

In this case study we look at the roll-out of an Enterprise Service Management solution (ESM).  It charts how the various Business Analysis techniques outlined in previous articles were employed to develop and implement the solution.  Overall, we achieved simplification for users and automated process steps which saved effort and allows the customer to speed up delivery.

Background

We worked with a customer that wanted to deploy an Enterprise Service Management solution (ESM).   The IT function had already had success in deploying a self-service solution and other parts of the enterprise realised they could simplify the user experience if it were to create a combined enterprise-wide portal covering Finance, HR, IT, Procurement, Site Facilities and Travel. 

Starter / Leaver

The solution was led by development of a starter/leaver process that would be offered through the IT portal.  The combined starter process covered teams across several enterprise functions.  The process started when a new hire accepted an offer in the recruitment system, which triggered a cascade of activities.

A business process engineering approach was taken to examine the whole of the starter process.  We went back to basics to look at what the new starter needed as part of onboarding.  We complimented this with the development of a user journey map that was used to explore the experience for the new starter when engaging with the starter process.  Every interaction was treated as a moment of truth where there is the opportunity to impress (or disappoint) the new hire. 

Offering

For the various functional teams delivering the products/services, interviews were held to understand what they offered to the new starter and how they provided it. Activity diagrams and rich pictures were used to describe the support activities. Workshops were held to brainstorm and sequence the integrated process. We then used business process modelling using Unified Modelling Language (UML) to codify these into flow diagrams.

Einstein is reported to have once said that if he only had one hour to solve a problem, he would spend 55 minutes defining the problem and the remaining 5 minutes creating the solution.  By using the above Business Analysis techniques, not only did we define the problem that needed solving, but we were able to share it back to all stakeholders to get alignment and buy-in for the new integrated process. 

For forms that would collect information from managers and from the new starter, wireframes used to outline the functionality of the user interface.  We then created mock-ups of the front-end to allow iterative feedback and refinement, before coding the back-end workflow. 

Automation

The development of the integrated solution opened-up a number of follow-on automation opportunities.  Each function had its own systems where they set-up the new user.  As the new portal was collecting all the required information in one go, this could be shared across multiple platforms as part of an aligned data model. 

Use Cases


A further series of workshops were held with each function, this time including their technical support teams to map their processes at a system and data level.  For some systems such as HR, the exchange on information was done at a by passing data directly into and out of their system’s from the User Portal.  Use Case modelling detailed the specific interactions that would be triggered between the systems.  The requirements from both systems were listed in a requirements traceability matrix to track the overall technical requirements.  The data to be passed was described using class modelling to detail the tables and fields that needed to speak to each other.  

Going back to Einstein’s quote, understanding and modelling exactly what data had to be passed when and in what form took the majority of the time.  Once the ‘problem’ was clearly articulated the integration was relatively easy to build. 

Even More Automation 

Similar opportunities were identified for system's used by other functions.  The Site Facilities team had implemented a centralised system for managing site and room access.  As part of the starter process the creation and allocation of a site pass was automated and was waiting for the user at reception on their first day. 

The ordering of a laptop was automated, and this was set-up ready for their arrival.  The provision of a SIM card and telephone number was set-up by passing the requirement directly to the telecoms provider. 

A credit card for expenses was requested, approved, and provisioned.  Overall, the new starter experience went from one of the managers calling around for several days to set up their new starter, to one of an accurate effortless process.  The work for the hiring manager was greatly reduced, much of the work for the fulfilment teams was automated, information was collected once and shared across platforms.  Best of all the new starter arrived enthused and ready to go.

Self Service

The success of the cross functional starter process initiated the development of self-service solutions across each of the individual functions, that were presented as part of an overall catalogue.  Workshops were held with each function to study their Business Capability Model and to develop their Service Catalogue, that listed what each function provided as a service or offering. 


In working together to document their current processes, we were able to apply Lean principles and challenge some of their business rules.  There were many processes that required approval at several steps in the process.  Analysis showed that if this was a service the user was entitled to request, and the correct information and justification had been provided, then the request was never rejected. 

It also became clear that various activities, like updating user data could be fully automated from a request.  For Finance processes such as Order to Cash and Purchase to Pay are based on setting up information on suppliers and cost centres.  By creating these as request offerings the activities were fully automated.

Through our understanding of best practise and use of various business analysis frameworks we were able to guide our customer on their journey to a simplified automated solution.

This brings us to the end of our Business Analysis newsletter, we hope you found it interesting. For more info please contact hello@ktsl.com

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics