Monday, 26 August 2013

The Configuration Management System (CMS) – The Service Management Linchpin

Over the years as a practitioner it seems as though I keep repeating myself like a broken record referring to the CMS (Configuration Management System) on the ability to take process “x” to the next level. No matter where in the lifecycle it has been I always seem to find myself saying “how does the CMS apply to this”?

Despite the fact that for some I will be preaching to the choir, I feel a sense of obligation to share a few examples on where this integration point can take the delivery of customer service to the next level. Overall the CMS should really tie into all Service management processes, but let’s not get ahead of ourselves. We can start with a few of the obvious ones:

Incident Management

Both Incident and Problem management should have the ability to pull information from and input info into the CMS. Just think about how detailed information would allow the service desk to improve on its delivery of service. They would have the visibility needed to see what makes the service tick. It would allow the analysts to see the known issues and any workarounds that would be associated to a configuration item. From a service perspective this may allow us to drive down first line resolution.

Change Management

This is probably more obvious but there needs to be solid ways to ensure that whatever configuration items (CI) we already have are updated as part of any change we put into our systems. With a solid link we can ensure that the available information in the CMS is as accurate as we need it to be. In some cases the ability to graphically see the relationships between configuration items which would easily identify any potential risks as the result of any upcoming changes

Knowledge Management

The CMS, which in reality is the base for your knowledge management system, should provide the details that will enable people to make better informed decisions based on quantifiable data.  This requires that your knowledge management policy supports these activities.

So why don’t we do this more often than not

Because it’s hard! As we know all things worth doing may not be easy. Remember that in these relationships while one thing may be the glue that binds it will open new possibilities and challenges along with it. One comment I had heard recently was that with the “Cloud” we won’t need to manage CI’s this way. Not quite, we just need to make sure we manage them in a way that makes sense. We need to make sure that where we can this is not a hard process to manage – simple is best. Automate where possible. Ensure that you choose the proper scope. For example, what business outcomes will we need to support through this process.

Keep in mind that as you make any improvements you may need to review the other processes to ensure we are still on track from an overall improvement perspective.

Follow us on Twitter @ryanrogilvie


Monday, 19 August 2013

Do You Have The Right People In Your CSI Raft?

Much like a raft you need to make sure that you have all the right people on board to ensure you can make the journey. What this really boils down to from a Service Management perspective is:

          ·         People
          ·         Process
          ·         Product and
          ·         Partners
All these four components are in place in some capacity in your organization. The key is to identify how much of a role they play. In essence, the question you have to ask yourself is “are these the right people or the wrong people in your CSI raft”?

You need to understand what you want to improve. This should be looked at from the customer’s needs. In other words “What is going to improve the customer experience”? When you can identify what you want to improve you can look through your 4P’s to see how you can make those improvements through those components. Identifying the inputs and outputs will allow us to define who we need to engage, or in this case who we need in the raft to fix this issue

Just because some parties may not be vested in this improvement initiative today doesn't mean that we don't need them tomorrow. We are not suggesting that we kick them overboard, at least not yet. Ensure that we have open lines of communication and that all the improvement activities are transparent to all stakeholders. There should be no secret that we are looking to make things better. This goes for IT as well as you customer.

Let’s look at an example.
We have application “abc” which needs to have major releases regularly every 6 months. The business has had some constraints around as they put it “changing anything” until they are complete with some client side project work. They need “abc” up and running all the time operating the same way until the project has been completed this fiscal year. As projects tend to do the launch dates were pushed out and as such so has the ability to update “abc” we are now at a point where we are several releases behind from the application perspective and some of “abc” tie ins to other applications are not working as they should as the releases missed impact those connections though web interface constraints. We are starting to see incidents regularly because of that releases we have not done
What we need to do now is to ensure that we have some agreements with the business on when we are allowed to have agreed on maintenance windows. Whether this is part of a service agreement or part of your release policy this should have be flushed out. Now we know, we need to let the business know that having no managed outages now may create unmanaged incidents down the road. This would speak to all 4P’s in some way.

Overall taking a look at your process, people, products and partners from another perspective is just one component of continual service improvements. Doing this will allow to see if you have the right parties in your raft and that they are all paddling in the right direction.

Follow us on Twitter @ryanrogilvie

Monday, 12 August 2013

Workarounds and Implementations – Like Ripping off a Bandage

A few weeks back I was speaking with a colleague who expressed challenges with some applications she had. Her frustration was that this legacy application was not scalable, and it was this way because of change management. I admit at first when I heard legacy app and issues my mind was drifting a bit. But when they said it was the fault of the Change Manager my ears perked up a bit.
“I’ll bite, what did the Change Manager do? I asked, even if I was a bit skeptical.
The background was this…
It turns out that the original component of the application was built in house to allow the warehouse manager to report on performance metrics and then take that data to schedule the next weeks forecasted staffing requirements. Sounds simple enough, right? As things tend to do there was a requirements change as the organization grew. The Warehouse Manager (WM) no longer was going to shoulder the responsibilities of metrics and scheduling. It was put onto 2 leads, one for each. We’ll call them Metrics Lead (ML) and Schedule Lead (SL). After the two were shown what to do they were off until….
The Warehouse bought a nice new off the shelf inventory tool. The salesman, who worked the room like a Kennedy, sold them on the idea that without cost they could have a tie in for the Scheduling and later maybe something for Metrics. Things were working fairly smoothly at first. There were a few hiccups but for the most part the scheduling was well driven from the output inventory app provided. After several months ML approached SL to see about tying in all 3. They contacted the vendor and an integration point was established. There was only one challenge; they required a manual intervention for information to be dumped from the Scheduling files to the Metrics files each day. An automated solution could be created but the professional services associated with this was determined “not worth it” from the business perspective. Without this file dump the piece count for each warehouse employee would not be accurate. It also included a file for cases which were returned to the warehouse in error
There was a downturn in the economy and WM had to let go of middle management (SL and ML) while he didn’t want to lose them, he was assured that the suite of applications would help him to cover the function (he once did by himself) quite well. There was nothing physically documented about how the applications worked together, and in his “brain dump” was explained that these files should be moved each day.
The application was still pretty solid for a few more months. It was at this point that the VP of the company decided to have a “pay by performance” initiative. This was not formally discussed with any IT stakeholders.
“We have a tool that tells us how many cases each staff selects a day, and we can incent them on their performance” There was quite the buzz on this.
The company was quite large now and the application was starting to have some challenges with the file capacity during the transfer during the day. A change was created to automate the file transfers to the inventory application at night. There was only one challenge. The returns file could not be automated due to other process constraints
…see, it’s the Change Managers fault…she said.  I was a bit puzzled.  “It was because of them that the process had to change and then the pay for performance wasn’t accurate, the warehouse workers were not getting paid properly. “
I could see where she of any of the stakeholders in her company would get that. To me It looked like there was a gap in the review of this change. What was missed for sure was:
·         The lack of knowledge captured about the application and how it works (and integrates with other components) – Knowledge Management is important
·         That the business drove this decision, risks should have been discussed and had sign off before proceeding. Did they know what they were approving?
·         A risk mitigation plan should have been included outlining what to do should issues arise.
·         An understanding that this process at its core was a workaround.
The company had to terminate the pay for performance program. Despite its potential, the organization was not in a position to leverage its data to accurately pay staff on the information captured

What was learned?
·         There was not a project to implement this Pay for Performance. Simply the change. many important requirements were missed
·         Had the architecture, process and limitations of the tool be documented they may have been in a better position to discuss what the tool was actually capable of
·         That while this change did not go as planned, it does not fall solely on the change manager, and there were several stakeholders who were not aware of the challenges associated with this tool and allowed this to proceed.
·         That this shortcoming should be documented, did I mention Knowledge Management
·         That a workaround, like a bandage can sting if it gets ripped off before its time

Follow us on Twitter @ryanrogilvie

Tuesday, 6 August 2013

How do YOU Define Services? Service Delivery – Chicken or Egg

Recently I have been thinking about what defines services. So I thought that I would look up an actual definition on-line. I was surprised how many there were and that all really were subject to interpretation. This is where the light bulb went off a little bit. It is not up to anyone to define the services with the exception of your customers and must be done on their level and what they see as the service.

Depending on the maturity of your organization you may already have a formalized set of services and the constraints around how they are supported, maybe through a 3 letter acronym of some sort like a SLx. In other cases you may have a single service which needs no definition.

But what happens when you are a larger organization and don’t have anything formalized or established? May feel a bit like the chicken and the egg. Where do you start? There are more questions than answers, I will give you that. At the end of the day this will be an exercise in improvement which in itself is a journey down the right path.

To determine what your scope for this initiative is you really need to identify what is the end goal? This isn’t a trick question, but the title is Service Delivery, so delivering services to the customer successfully if goal number one. The next part and trickier component is how you do that. This is where the scope will come into play (that chicken and egg bit, how do you start unless you know where you end).

Depending on your environment you may have many services which you provide but getting alignment with the customer on their business outcomes are paramount. After all, whatever goals the customers have we should tailor our efforts to provide those results. To simplify if the service is critical to achieving our business goals, then it is a critical service.

Sit back and take a good look at where you are right now.

·         What are your Core, Secondary, and Tertiary services?
·         Are the services defined in that way – are there just services?
·         How are these supported today?

You may have this figured out already, you might not. If you don’t, assemble a list of services you provide and then go back to the business to determine the level of criticality these have to achieve your business outcomes. You may be surprised with your results after discussions with the business.

I can already hear the challenge…. What if the customers says “all my services are critical” this may be the case. They way that you may want to simply your list to prioritize them is through the “Jenga” example. There is a game called Jenga, in which you remove blocks and place them on top of the same stack of blocks. The object, like your business, is to keep everything balance during this game. Your key critical services will be those “blocks” at the base which cannot be removed. For example application X is key but if the network is down, the application becomes secondary.

Discussion with your customers may also allow you to streamline the way the IT Operations works as well. IT may have a perception that services need to be supported in one manner and this touch point will verify or dispel any of those assumptions. This dialog will allow IT to take a look at how it manages the services and leverage what the customer defines to further quantify IT’s activities. For example, we may have less support coverage than we need, or it may turn out that a particular skill is shorter in supply than we thought.

At the end of the day the road is long, and we need to start the discussions and have a scope which will reflect what the customers need. Having these discussions will allow you to ease any support changes with customer buy in as they will be driving the requirements rather than us “telling” the business what we “think” they need

Follow us on Twitter @ryanrogilvie