≡ Menu

Elements of Business Service Management Part 3: Getting Business Service Management on the Radar Screen

in Best Practices, Business Service Management, Implementation, Service Management, Strategy, Value

Originally posted on the IBM Tivoli ITSM blog here.

OK, you’ve got the word that you’re going to get to start your Business Service Management journey. Let’s say you’ve got some level of buy in, but your boss and other management are still a bit skeptical. They’ve given you the green light to put together a more formal strategy, roadmap and plans for the upcoming capital budgeting cycle and project portfolio planning session in a few weeks. You’ve been asked to make recommendations about near, mid and long term costs, level of effort and return on investment and value to the company.

Where do you start? You’ve typically been just the tools guy responsible for network and systems management. You may be stuck underneath the NOC or other network or systems organization silo and never had to work on tasks like this before. Don’t worry, most of your peers haven’t had to do this either. The tools group is often left far from the Enterprise Architecture table where IT strategy and roadmap initiatives are often driven.

If Business Service Management is a top down initiative in your company, your job may be a lot easier and you may get formal support from other enterprise IT organizations such as the Enterprise Architecture organization, PMO, etc. If so, this will still be applicable and will help you bring a solid approach to the realities of what’s involved in the business service management journey. You know, your boss may need to hear and see this reality to properly set expectations upwards!

Let’s keep it real and on what you know. You know what your job is, what tools and resources you have to do your job. You may have people in similar roles as you in other lines of business or organizational silos within your same company. If you’ve been around the network and systems management space for some time, you know your job is about collecting data, information, metrics, events, etc. from various components throughout the company. You make this stuff available to many different groups such as the NOC, SOC, help/service desk, operations support groups, network engineers, application support, etc.

If you stepped back, way back and looked at your company from a 50,000 foot view and looked at all of the individual components that make up what your company does, you’d see a lot of stuff that’s familiar to you in your job but also a lot more stuff you’ve never heard about or know that your tools and applications are not interacting with. The fact is, in a perfect world, everything you see here would be monitored and managed in some way where someone could understand each components individual status, availability, performance, reliability, performance, capacity to do/support something, etc. You could even say that you’d have insight into what people, processes, services, activities, clients, etc. depend on those individual components. You’d know what incidents and problems currently exist for that item, any upcoming change requests, downtimes, vulnerabilities, bugs, etc. You’d also know how much each of those items costs you to support, manage and operate and the value each one delivers to the company or your clients.

You could say that each one of those individual components has an ecosphere associated with it. An ecosphere of monitoring, management, metrics, data and information which help people make decisions. The reality is you probably don’t have everything managed and monitored in your company. Don’t worry the majority of others in the same role as you are likely only monitoring availability by simple “pings” to see that it responds or some simple, out of the box, slightly customized agents, situations, thresholds and rules. I’ve yet to run into anyone who comes close to “perfection”, but it does help give you a target for continuous improvement.

What am I saying here is that you’ve probably got some pretty significant gaps in overall visibility into the key infrastructure, applications, databases, etc. that make up the business services, processes, transactions, etc within your company. One of the key components of our Business Service Management methodology is to ensure that our clients have a solid foundation in the basics of network, system and application management. Visibility into that ecosphere is critical for successful, reliable, trustworthy and value oriented Business Service Management.

I’d like to jump ahead one step here and talk about the creation of the roadmap first. Nearly all the clients I meet with are interested in getting to the “quick wins” rather than spending the time working out a formal long term Business Service Management strategy. I advise against this, and I will write in a future posting on the importance of developing a formal strategy. The strategy document becomes the overarching vision for Business Service Management for the company. It ties together all of the key components of what Business Service Management is, the expected value, returns, methodology, integration and alignment with all of the other key business and technology strategies and architectures. It helps determine what goes into the roadmap.

The roadmap is the short and long term plan. It’s what gets worked. Plan the work and work the plan as they say. It lays out the key activities and areas of focus. It’s measurable. The roadmap serves as the guiding document that resources can rally behind. It helps eliminate chaos, confusion and conflicting priorities. It’s not a project plan per se, but it summarizes at a high level the major work areas, dependencies and pre-requisites and the time dimensions that they may get worked on. These major work areas would be backed up by more traditional project plans, schedules and resource assignments.

Five Steps to Creating a Business Service Management Roadmap

Step 1 – Know what’s Important

  • Seek what’s important to the business first, IT second
  • “Look and Listen” for the pain points within the company, hallway and water cooler conversations, operations firefighting “concall”, service/help desk or NOC staff, daily/weekly/monthly reports and scorecards, etc.
  • Balance the “Quick Win” with “Doing things the Right Way”

Step 2 – Know what you need

  • Model your ideal “ecosphere” of visibility into the business or IT service, process, activity, transaction, etc.
  • Identify metrics and measures that help you assess more than just state such as performance, quality, user experience, value, revenue, costs
  • Ensure you think about alignment with the business here – what do you need to really understand how the business is impacted, how much revenue is lost, what value is provided by something within IT

Step 3 – Know what you’ve got

  • Based on your expertise and understanding within your areas of responsibility, identify what visibility, data, metrics, events, etc. is provided by your group, tools, applications, etc.
  • Identify what other groups may be doing with their own tools and applications
  • Identify what the business may be doing to provide visibility into the identified area

Step 4 – Know what your gaps are

  • Identify the gaps between what you need and what you (and) others have
  • Identify ideas on how to close the gaps through tactical and strategic approaches
  • Identify how you can leverage what others have through collaboration, “win-win” scenarios, adult beverages, etc.

Step 5 – Know what you can do now

  • Identify what small, high value, iterative projects you can do now with your resources, tools, data, events, known gaps, etc. (no longer than 30/60/90 days)
  • Identify three ideas for near, mid and long term tactical and strategic approaches; recommend a path forward to the ideal solution
  • Identify no, low and high cost approaches, alternatives
  • Identify expected return on effort, return on investment, expected value, soft/hard benefits if possible
  • Categorize benefits into cost savings, efficiencies, performance/availability improvement, etc. or other buckets relevant to how your company looks at making their technology or capital investments.

Roadmap documents may take on many looks and formats. Your company may have a preferred format for you to use. A Google search on the topic may help lead you to results such as these:

Your roadmap should be captured within a layout no larger than a legal (8.5×14) or tabloid (11×17). Your goal here is to design a roadmap with a layout that’s clear, clean and concise. Look at many of the examples listed above or elsewhere on the Internet. They’re generally very easy to read and understand. They communicate a well thought out message. This is what we’re striving for, a well thought out plan for implementing business service management solutions in the near term leading towards the long term.

The roadmap content contains the summarized, high level output of what work you’ve done in the five steps above. What you’re focusing on, what your key work efforts will be, how you’ll address the gaps and ultimately how you’ll deliver the solution for a given business service. What you put into the roadmap should be believable, achievable, measurable and realistic. You’re better off here to under estimate and over deliver. It’s ok to set some stretch goals here, but clearly identify them in some manner so they stand out. Technology executives, especially the ones who approve funding, have a keen ability to sense something that’s unrealistic and far-fetched. Spend as much time as it takes iterating here to create the right roadmap that will get the approval and backing by your management, Enterprise Architecture team, capital review boards, etc.

I look forward to hearing about your own Business Service Management initiatives, strategies and roadmaps. I hope you’re able to share and join in the conversation so others may benefit and increase their success with Business Service Management. Follow on postings in this series will touch on creating a Business Service Management strategy, introducing a Business Service Management maturity model and other discussions around enabling success with Business Service Management.

Comments on this entry are closed.

Next post:

Previous post: