Hey all! I am back. I wanted to chat for a spell about another point that I brought up in Part 2 of my wonder twins powers series. If you remember, and I do not know how one could forget, but just in case the thoughts of Thanksgiving dinner have made our discussion slip your mind, I will refresh your memory. I was pontificating on the benefits of establishing a service catalog and the value of spearheading a CMDB effort simultaneously. Does this refresh your memory? Cool.

So why do this? What are the benefits? Thank goodness you asked.

The reason that this is the bee’s knees is related to the day after the service catalog is deployed. What happens?

The second has to do with addressing the management of a service catalog structure. So after you rip out your hair and the wounds heal from the effort of developing a service catalog structure, you finally have done what seemed impossible - you have a document titled service catalog (Fans Cheer). I apologize if I am a being cynical. Please believe me when I say, I know the amount of effort it takes to build such a document. I definitely have the scars to prove it. So what happens next? How does a business obtain real, hard-dollar value?

The reality is the next day, or the next month, components within a service begin to change and when that happens the nice document that took such a long time to create is sadly out of date. Ouch? I know this is painful. While the document is not a waste of time, the thinking that has to go into creating a service catalog document is good work, it just falls to the hands of progress. To avoid this situation, a service catalog needs to be integrated with the source that contains all its pieces. This will provide the catalog components to adopt changes as they occur. Does this make sense? Let me know if not. As always, I would love to chat about this some more. Well until next time; remember to use your powers for good.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags: project manager project plan plan project

—–

Yes the holidays are an exciting time, and so is having a chat about how to increase the value of IT by building a structure to become the Chuck Norris of IT. While I joke with an infamous Chuck Norris reference, because the reality is no one can be that cool. I would say investing in a comprehensive structure that addresses the establishment of a Service Catalog and CMDB. Why would I say this?

Well, establishing the Service Catalog and CMDB will provide the appropriate degree of change to generate the traction needed to start the IT transformation process and become an agent of change. While each on their own do have merit, I would say that the strength and challenge is in the integration. I can tell you from my experience that those from the Configuration Management camp are of a different mindset than those from the Service Level Management contingent. Getting these teams to collaborate provides some attention but when you think of the benefits, the end can justify the means. The benefits that first come to mind are as follows:

1. Ability to identify the composition of a service that includes Hardware, Software, Manpower Governance, Standards, etc.
2. Reduction of Service Catalog Maintenance.
3. Assembling the change in thinking about IT from Products to Service (internally and externally).
4. Gaining an awareness of what IT does.

Is there any thing I am missing or any questions?

If not, I would love to dig into these points a bit and chat away. Unfortunately, this will have to wait until next time. I have to get on to attending to some things before the holiday. Well until next time; remember to use your powers for good.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags: itil process cmdb itil itil cmdb helpdesk itil processes business process solutions

—–

I’m currently working with a client to help improve their processes using ITIL as a guide and benchmark. We started with a maturity assessment and used the results to identify major gaps (as defined by business value, not ITIL’s textbook). Serve Desk and Incident Management were two of the key foundation areas for improvement, so we started there first.

If you’ve worked with ITIL much, you know it didn’t take long for challenges to show up. Specifically, one of the key requirements of a good Service Desk is enforcing the defined SLAs and OLAs - as defined by the Service Catalog. Well- this client doesn’t have a Service Catalog. Not yet, anyway. So we had a long series of conversations about “What is a Service Catalog?” and “How can we define a Service Catalog that supports the business?”

The key, I believe, is to look at everything from the business’s perspective. The CEO of the company wants to receive a relatively few services from IT. Things like email, internet and core application availability. As a shortcut to finding out which services are really key, take a look at your disaster recovery plan. The services they you restore first are, by definition, most critical. So you could start with your highest priority services (as viewed by the customer) to define your basic Service Catalog.

Of course, there’s a lot more to it- like SLAs and OLAs and Underpinning Contracts. And now we get to the catch: How can you define realistic SLAs if you don’t understand all the underlying infrastructure that supports a service?

Let’s take email for example. From the business perspective, it’s simple - they want to be able to instantly, always send and receive email. Behind the scenes, that requires a wealth of infrastructure and resources - servers, applications, spam filters, firewalls, network gear, ISPs, administrators and on and on. How hard would it be for you to complete this list for your environment - and keep it complete and accurate at all times?

Pretty hard, I suspect, if you’re like most medium and large IT shops. The rate of change is simply too high, there are too many people involved and there is no single place where the information is stored. Now you see why the CMDB is a critical underlying requirement for true, solid SLAs and OLAs and, ultimately, a real Service Catalog.

Sure, you could do what many shops do and simply ‘declare’ some SLAs that you know you can meet. But what does that accomplish? For one thing, it’s only a matter of time until the CIO or CFO or CEO starts asking, “How much would we save if we reduced our availability SLA for email from less than 15 minutes per outage to less than 60 minutes per outage?”

Here’s why that’s important: the business will always seek to optimize its investments in IT, and as service providers, it’s our responsibility to have good data and solutions to help them do that. If you don’t have this information, you’re guessing. Executives don’t like guessing.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Till next time, keep up the good work.

Scott Braden

Technorati Tags: itil service level agreement help desk

—–

Hey there everyone?. It is ‘I’. I wanted to take some time and to elaborate on the points that were mentioned in Part 2. If you recall, I discussed my belief that the value of implementing a service catalog can be extended by establishing a CMDB in parallel. I am sure some of you had thoughts of this being the beginning of my pitch to sell you a time share in some tropical island location, but I assure you this is not the case. No, my reasoning has only been founded through the pain and suffering of being limited on what can be delivered within the context of a service catalog project.

The first benefit of such an approach is to increase the rate of adoption of a service catalog. Adoption of a service catalog is quite a challenge. It is like convincing a two year old that they need to eat their vegetables. It is a really tough sell. To understand the reason you first need to understand the customer you are trying to sell the change to. Your average IT good-doer has been exposed to an ever-changing environment from the day they started in IT. So to get jazzed up about a change in strategy, it will take a bit more than a fancy stress ball or mouse pad. IT good-doers are really good at determining whether a change is real or fake. As a result, implementing a catalog needs to be presented as something of substance and value or it will fail. For this reason, it is essential that it does not get perceived as just a static documentation that comes with the penalty of requiring updating. A service catalog needs to be integrated into process and part of how IT does work. This can be establishing by properly aligning it with the operational structure of the CMDB. This design, while requiring additional resources, will add to the value equation to increase adoption and provide the results the management needs to maintain momentum.

As always, please let me know your thoughts and comments. I am interested in comparing notes to see what challenges you have come across. Well until next, take care.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags: help desk software help desk strategic planning itil software business

—–

Greetings and Salutations, fellow bloggers; it is I once again. Recently I have been spending a considerable amount of time helping organizations think about establishing Service Level Management within the context of ITSM process improvement projects. It is increasingly apparent that to derive real value from a Service Catalog, one cannot focus on this tower of knowledge independently. There needs to be equal focus in establishing the CMDB (which is the other needed knowledge tower). This is largely due to the significant dependencies that a catalog has on a CMDB.

Why do I say this? The reason for this is due to the dependencies that a Service Catalog has upon a related CMDB. Without a CMDB (in place or at least in some significant state), true Service Level Management (including a value-providing Service Catalog) cannot be reached. A catalog needs the support of a CMDB to provide its true value to the organization. While an initial catalog is developed as an independent knowledge tower, the maintenance and development of such a structure becomes a resource burden, and when those resources are challenged, the structure often ends up abandoned. The true value of a catalog can be found only when it is integrated with the CMDB and is employed as part of the operational fabric of the organization.

This is not to say that the approach should change to anything but iterative. It is just acknowledging that the value of a catalog is contingent on the maturity of the CMDB structure. Consequently, if the desired goal is to implement a catalog to return real value to the organization, it is imperative to coordinate the development of both towers of knowledge: catalog and CMDB.

Thoughts?

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags: help desk software help desk helpdesk+software helpdesk itil desk software support software

—–