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

—–

Hey there everyone! It is me. I would like to add some thoughts to my last posting about the advantage to developing a Service Catalog and CMDB as parallel initiatives. While I would agree that this may add some additional complexity to the project, I think the value that can be captured from such an approach will bring about true measurable value to the organization that may not be achieved otherwise.

The inherent nature of ITIL processes almost always leads to ITIL gridlock. In my experience on implementing an individual ITIL process, there is always a grocery list of opportunities that need to be placed on hold until a dependency can be addressed by another process area. This is especially a challenge in the initial phases of an ITIL implementation because typically most of the support structure needs to be addressed to properly establish a portion of an ITIL discipline. Establishing SLM is no exception. In fact, initiating the discipline of SLM by starting to create a Service Catalog is commonly one of the most significant challenges in adopting ITIL processes. This is largely due to two factors. The first is dealing with the organizational challenges from adopting and working in a service-oriented structure. The second has to do with addressing the management of a Service Catalog structure.

These are the two points I will like to discuss next time we have a chance to chat. So enough from me (for this time); I would like to hear from everyone with your thoughts on SLM and the dependencies that Service Catalog has on the CMDB. I welcome your thoughts and questions.

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

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

—–

Hey there everyone! It is me. Yes again. I want to qualify my belief that establishing a Service Catalog is a great undertaking. There is no doubt this is an unruly call to duty but it can be a valuable achievement that provides a tremendous amount of benefit not to just IT but the entire organization.

If properly integrated into the day to day operations, this can transform the way the organization conducts work. Work that comes in many different forms, including Business to IT, IT to Applications, Accounting to IT, and how about HR to IT (yes, HR to IT) can all be transformed into a single measurable service structure. (Do you here the fans cheering?) A structure that can establish a common playing field which includes:

1. the details of the offering,
2. the level of service accompanied with the offering and
3. the dependencies needed to provide it.

This structure provides the needed communication bridge that is often skipped within the context of internal business relationships by establishing the expectations needed to provide a service regardless of whether the service is to an external or internal customer.

Well it is time to put the soap box away for tonight. As always I would like to hear from everyone with your thoughts on SLM and the dependencies that Service Catalog has on the CMDB. I welcome your thoughts and questions.

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

—–

One of the first questions when contemplating a Service Catalog is, “Where do we start?”

The project I’m currently working on is an “ITIL maturity improvement” project, or to describe it more accurately, it’s the first phase of a long-term IT Service Management improvement program. In this phase, we’re working directly on ITIL Incident Management, Problem Management and Service Desk.

But if you know ITIL, you know it’s impossible to only work on one process area… in fact one of the key roles of the Service Desk is to be the manager and negotiator of the Service Catalog and the resulting Service Level Agreements (SLAs).

So, in this client’s case, they don’t yet have a formal Service Catalog, and yet one of the key objectives of Phase 1 is to deliver a Service Desk that enforces SLAs… and offers a Service Catalog. So how are we supposed to do that?

Here’s where it may be useful for you: Even though these folks don’t have a formal, written Service Catalog, there’s nevertheless a large set of informal, unwritten services, expectations, historical precedents and other understandings that, in the customer’s mind, have the same effect as a Service Catalog with SLAs.

I’ll give you an example - the existing Help Desk has service hours and an expectation that the phone will be answered and calls handled within a certain timeframe. This has been the usual course of business for many years; all the customers and end users have the expectation, but it’s just never been formally written up, no underpinning OLAs have been negotiated and no customer has ever placed a signature, in ink, on an agreement. Nevertheless, the Service and the SLA exist.

As we investigate, we find dozens of other examples - for instance, an application support group that deals with a particular business unit has an understanding about turnaround times for small fixes and enhancements. It’s not documented and signed, as ITIL would specify, but the Service is (somewhat) defined and the SLA is reasonably solid (though not always measured effectively).

So as you look at your shop, start looking for the “hidden” services and SLAs that are probably already there - so instead of beginning a “from scratch” exercise, you’ll be doing a “document current state” exercise.

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

Scott Braden

Technorati Tags: help desk itil software service level agreement service

—–

A recent engagement on developing a service catalog for a client gave me pause to think about the importance of service catalogs and why companies need to develop them. That lead me to think about the top 10 reasons that companies develop service catalogs. I would love to get your feedback, suggestions and edits on this list. Let me know what you think.

10. In order to develop a taxonomy and hierarchy associated with IT services, that establishes the ‘highest’ (broadest) level within the Service Catalog structure and provides a comprehensive infrastructure that supports all services with minimal anticipated revisions. Service Families should be aligned with the functional areas that they support.

9. In order to provide a single repository for all IT services, one of the steps towards building a CMDB.

8. In order to map established services to the existing customer population, providing IT with an understanding of service demand and an opportunity to validate all of the services actually being used, so that unused services may be altered or decommissioned.

7. In order to leverage the industry standard best practice processes, such as ITIL (Information technology infrastructure library) and CoBiT (Control Objectives for Information

6. In order to ensure that dependant services, processes or vendor lead times are accounted for associated with services, also providing the foundation for the development of OLAs and SLAs.

5. In order to establish Operational Level Agreements and develop clear pictures of services and their interdependencies, also a tool for the development and capture of internal metrics for a given service, the first step towards developing Service Level Agreements (SLAs).

4. In order to establish service level agreements for applicable services, based on gaining agreements between IT and its customers on the terms and availability of services.

3. In order to establish a cost for services and appropriate pricing for available services based on the level of service being delivered, and involves an analysis of the various service catalog servicess, SLA options and calculations of cost in relation to services delivered.

2. In order to provide the customer one location to view and order services provided by IT, as well as organize and bundle ?services? in a way that customers can understand and use them.

1. In order to rationalize end user demand through the establishment of service and vendor standards, optimize that demand based on business planning and spend, and organize the myriad of hardware, software, networking and services in a way that the services are then valued by the business.

Let me know what you think of my top 10 reasons for developing service catalogs, and share your own here as well.

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

Technorati Tags: infrastructure service level itil

—–