I ran a workshop recently to help the IT organization in a bank redefine their services. They had contacted their HP account team to say that they needed help defining “business services”, because all their IT services were currently quite technical and they knew that it would be better to have a more business-focused service catalog. This blog describes how I helped this particular organization, but you may find that some of the ideas will work well for your situation too.
The IT department had already done a lot of work on a “business service definition” project but was not sure how best to proceed. We agreed that I would spend a few days with them, reviewing the project and making suggestions for the next steps.
The service catalog they had created defined one IT service for each application. Some applications were only used by a single business unit, but others contributed to many business processes across the whole bank. The IT department had defined a standard SLA format and created SLAs for many of these applications. This was taking a long time, as there were more than a thousand applications. The SLAs for these services had quite technical targets, and this led to a potentially enormous amount of reporting, which would be of limited value to the customers.
Although the IT department knew that they wanted to define “business services”, they weren’t sure what this would involve, since the only services that they were aware of were based on supporting the applications, for which they were already defining SLAs.
We looked at a simple model that I sometimes use to help IT organizations think about the difference between an application and an IT service, but this still didn’t help them to see how they could improve their service definitions, since they felt that most of the additional components were generic across all their services.
The IT organization had a number of business relationship managers who seemed to really understand their customers. These BRMs clearly understood what the customers did and what was important to them. This was the vital information that we needed to resolve the situation. The bank had a number of business units, and each of these business units ran many business processes. Each business process relied on one or more of the applications. The BRMs had identified the major business processes and started mapping these to the applications that supported them.
We selected one business unit where the BRM had done a good job of this analysis; this was the mortgage unit, which just had 8 significant business processes. We started to draw up a table showing which applications supported each of these business processes.
It was at this point that we realized the simple solution to their service catalog problem. We simply needed to define a service for each significant business process. For example, there would be an “online mortgage support service” and a “second-party mortgage support service”. This simple idea has the great advantage that it means something to the business, and if we measure and report these services then we will create reports that have a real business focus. We can then review the targets in the existing SLAs to ensure that they underpin these new business services. Over time the application SLAs could be modified to become OLAs (operation level agreements – used to document an internal agreement between the IT service provider and another part of the same organization) with internal metrics that can be used to help ensure the business service SLAs are met.
We wanted to avoid creating a huge overhead with the new SLAs, so agreed to restrict each one to a small number of KEY performance indicators. The BRMs will talk to the customers and ask them to identify the three most important things that they want measured and reported for each business service. These will then be documented in short SLAs, and the IT department will work out how they can be measured. (See my blog titled Should an SLA define what the customer wants or what you can measure? for more thoughts about this). The IT organization will then review targets in the application SLAs to ensure that these targets are suitable to deliver the required customer outcomes.
On the final day of the workshop I was listening to a discussion between some of the BRMs, and one of them said,
“I think the customer may well ask us to report the length of time from when a new mortgage advisor joins the organization to when they have been provisioned with a PC, a phone, user accounts and everything else they need to do their job. I hadn’t thought of this kind of target before, but if that is what they want then we could invest in helping to improve this”.
It was at this point that I knew they had internalized the difference between an application service and a customer-facing business service.
Learn more about HP technology experts and how we can help you solve your most pressing challenges today – and be ready for what’s next.
If you want more ideas to help you think strategically about IT services, then read some of my other blogs (most recent blog is at the end):
- IT strategy: 4 things you can learn from the U.S. government (yes, the U.S. government)
- IT Strategy: 3 more things you can learn from the U.S. Government
- 3 Steps an IT manager should take to earn their seat on the board
- Prioritizing time to get started on strategic planning
- Don’t mistake continual service improvement for a mature IT strategy
- 6 steps to plan and prioritize IT investments
- When is it good to talk about technology with the CEO?
- Service strategy survey shows that many organizations have a long way to go
- The Five Cs of Change Management
- 6 steps to get started with knowledge management
- 3 Things That Will Help You Become a Learning Organization
- Is SaaS going to replace on-site software?
- Don’t Disrespect Santa Claus and Don’t Ditch ITIL
- Should an SLA define what the customer wants or what you can measure?