IT Service Management - Practical Insights

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

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 "concalls", 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:

• Technology Roadmaps: http://en.wikipedia.org/wiki/Technology_roadmap
• Prioritizing Requirements using a Cost-Value Approach http://en.wikipedia.org/wiki/Prioritizing_Requirements_using_a_Cost-Value_Approach
• The Albright Strategy Group http://www.albrightstrategy.com/roadmap.html
• Product Development and Management Association http://www.pdma.org/visions/oct02/roadmapping.html

Your roadmap should be captured within a layout no larger than a legal (8.5x14) or tabloid (11x17). 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.

Doug McClure
Senior Managing Consultant
Business and IT Service Management (BSM/ITSM)
BM Software Services for Tivoli (ISST) - Netcool
e: dmcclure@us.ibm.com
w: +1-678-267-3120 c: +1-404-386-0288
BSM/ITSM Blog: http://dougmcclure.net

Elements of Business Service Management Part 2: A "Recipe" for Business Service Management- Key Ingredients of Business Service Management Success

In my first posting in this series last year I started with a goal of establishing a better working definition for Business Service Management. This was my new working definition, not IBM's or an analyst’s. My encouragement for you was to take it for what it is and use it as a reference as you define what Business Service Management is for your company.

Making sense of what Business Service Management is has to come from within your own unique environment. You’ll need to define what Business Service Management is within your organization and how you'll use the concepts of Business Service Management to help your company be successful. Use this specific definition as your mission statement and catalyst to help define where you are and where you want to be in your Business Service Management journey and how Business Service Management will help more closely align IT with the Business and Business with IT. If you just take what your vendors, partners or consultants are telling you as "the only way", you're setting yourself and your company up for disappointment in the future. Spend considerable time coming up with what Business Service Management is for your company!

Let's look at some of the things I've heard over the past few years.

• I've got all the right capabilities in the new Business Service Management technology, product or solution that I've just bought or am evaluating.
• I thought our proof of concept and pilot was a success, why wasn't my Business Service Management project funded?
• Why aren't my Business Service Management solutions being used?
• Why was my Business Service Management technology, product or solution maintenance renewal cancelled?

These may be some of the things you've dealt with as one who has implemented or is planning on implementing Business Service Management solutions. You're expectations for successes were very high, but the reality that set in was something very different. What went wrong? Was it me or my team? Was it our technology, product or solution choice? Was it my dashboards or reports? The facts are that it could have been any of those things that turned your vision of Business Service Management success into "just another tool" or "eye candy" with little to no real value.

The key here is that successful Business Service Management solutions are much more than the technology, products and solutions on the market today. Success with Business Service Management requires significant commitment, dedication and being able to work within the organizational and political forces that exist in most organizations towards the agreed upon goals and objectives defined for Business Service Management.

Here’s a high level "recipe" for Business Service Management success:

10 Parts "Commitment and Buy In"

• Established based on Business Value - not necessarily ROI, but the tangible and intangible things that provide the company, lines of business and management value
• Maintained by having a measurable and results oriented strategy and road map
• At the right levels to ensure success in all of the items described below

8 Parts "Understanding What's Important and Why"

• To the business, customers, partners, IT, competitors, financial community, investors, board of directors, etc.
• Linked to Business Value- everything must be tied back to the value drivers you've identified
• Your solution may appear to be very IT centric to those who are unfamiliar with it, but that focus should exist only to DELIVER SOME MEASURABLE VALUE for the goals and objectives of the business to be met
  • If this doesn’t exist or isn't well understood by everyone - you're likely to see the solution treated as just another tool

6 Parts "Transparency"

• Willingness to 'lay it all on the table'
• Able to break down or minimize the impact of organizational silos, kingdoms, fiefdoms
• Everyone recognizes what they’re good at and what they’re not good at

5 Parts “Having a Service Mentality”

• Understanding business and IT services and the service delivery chain
• Common service oriented goals and objectives are established company wide
• Everyone understands the role they, their organization, their technology plays in delivery of services - it's not just about "my servers" - it's about "our services

4 Parts "Visibility"

• It doesn't matter if you're an enterprise, SMB, global service provider or telecommunications company, you've got to have visibility into what's happening within your environment and the environments of everything you depend on for business and IT service delivery
• Indicators, metrics and measures from both the IT and business perspectives
• A well established solid foundation in the fundamentals of network, system, application and service management and monitoring

These are just some of the "ingredients" you'll require for being successful with Business Service Management. These items will undoubtedly lead to more questions like:

• What does this "BSM Recipe" deliver? What does it look like?
• What's the value of this "BSM Recipe"? Are there other approaches?
• Do I have the right ingredients? People, Tools, Processes, Sponsorship?
• Do I need to forklift everything I have in place already?
• What do I need? How much will it cost?
• How do I get started? How long does it take to ...
• How do I assess where I am right now and where my gaps are?

Follow on postings within this series will be focused on helping you get there. Where? That's what you'll be determining - your own Business Service Management Maturity Model, Strategy and Roadmap. I'll continue to share my thoughts and ideas on what a Business Service Management maturity model looks like aligned with the Gartner IT Maturity Model. Using this, you'll be able to determine where you are today and learn about practical steps you can take towards maturity with Business Service Management in your company.

Doug McClure
Consulting IT Architect
Business and IT Service Management (BSM/ITSM)
IBM Software Services for Tivoli (ISST) - Netcool
e: dmcclure@us.ibm.com
w: +1-678-267-3120 c: +1-404-386-0288
BSM/ITSM Blog: http://dougmcclure.net

What I’d Like for My ITSM Christmas

Many of us have been following the ITIL Refresh (or ITIL v3) effort for quite some time and are eagerly awaiting the anticipated new publications in Spring of 2007. The new books are expected to focus on a lifecycle approach to IT services. This should be a great improvement over the current books, which seem to be an evolutionary improvement over existing IT practices rather than a significant leap in how IT carries out its business.

Not much has been revealed about the upcoming books. The ITIL publisher has begun publishing a newsletter about the Refresh effort (see www.itsmf.org), but it primarily confirms some of what they have revealed so far. We still don’t know much more than a very high level description of the books.

With the holiday season upon us, I thought I would make a list of what I would like for Christmas. Not the December 25 holiday, but what, for many of us, would be the "ITSM Christmas" – the release of the new ITIL v3 documents. Here is my list of what I’d like to see in the new documentation.

What is the scope of IT Service Management?

ITIL is focused on IT Service Management (ITSM). The organization that promotes ITIL is the IT Service Management Forum (itSMF). Yet, it is hard to know what the scope of ITSM is. Is IT Service Management just the 10 Service Management processes? Or does it encompass all of IT? Or somewhere in between?

The reason this is important is because an IT organization needs to know just what processes, functions, and best practices it needs to implement in order to bring about true IT Service Management. Is having an integrated service desk enough? (In my opinion, no.) What if you add Service Level Management and charge for your services? Is that enough? (Again, no.) How do you know when you are done implementing ITSM? If the scope of ITSM is left undefined, it’s a great thing for consultants, but it’s not good for IT organizations, who will constantly be told that they will finally reach ITSM nirvana if only they will implement 5 more processes or 8 more roles or 2 more applications.

ISO 20000 attempted to clearly define the processes that make up IT Service Management. Yet, that standard is very heavily dependent on ITIL. ITIL should lead the way by making a clear statement about what is "in scope" for ITSM and what is not.

Where do you handle service requests and requests for information?

One of the first difficulties most ITIL newbies run into when they go through the ITIL foundation course is the issue of service requests. The ITIL Service Support book does a good job of describing how incidents are handled in the Incident Management process. Unfortunately, it does not do a good job of describing how service requests are handled.

ITIL says the handling of service requests is similar to the handling of incidents. This seems to be hiding some of the additional considerations and procedures that go into handling service requests. It’s like describing letter handling at the post office without describing how packages are handled. True, the same people and basic mechanisms are involved, but packages need more space, often special handling, and include long customer lines for getting correct postage.

Some organizations have seen this inadequacy and have created a "service desk" process in order to handle service requests. This is somewhat orthogonal to ITIL, since ITIL calls the service desk a "function", not a process.

ITIL needs to describe workflows for handling service requests and how that integrates with the handling of incidents. There should be a clear description of how that relates to change management and "standard" or "pre-approved" changes.

In addition, service desks must also handle requests for information. Many users simply need to know how to perform a particular task or where to locate software or procedures. This could be considered a "service request", but I consider this separate from service requests. ITIL should also describe how these types of requests are handled.

Where are changes developed?

ITIL has a very good story concerning changes that involve the installation of vendor software patches. The story is that an RFC is created to install a patch, it is assessed and approved by change management, then it is deployed by release management.

Unfortunately, changes are not always such a clean, tidy story.

What if the patch has to be built by the IT organization? Or what if the change is much more significant, such as the creation of an entirely new application? ITIL does not provide a great deal of guidance about that. Instead, ITIL says that such a change request must be sent to the "relevant technical group" and that change management will play a "coordination role". It is left up to the reader to determine what the development process should be.

In addition, changes could involve the purchase of new hardware or software. Where are the processes for procuring those items? What if services are to be outsourced? ITIL should describe those processes.

What if the change simply involves creating new training courses and rolling those out? What processes are involved?

ITIL needs to describe development processes, supplier relationship and purchasing processes, a project management process, and workforce training processes.

Where are services operated and maintained?

As mentioned earlier, ITIL is all about IT Service Management. If that is the case, then services must be set up and operationally executed for IT customers. ITIL describes Service Level Management, which allows IT customers to select services and negotiate service level targets for the selected services. However, ITIL does not describe the actual operation of those services.

For an IT organization to provide a service, that organization must also manage that service as an entity. Although the service may be an integrated collection of hardware, software, procedures, and people, it must be managed as an entity. That means the service must be set up, initiated, operated, and suspended or halted if necessary.

IT organizations are traditionally focused on IT operations. That is what they know best. Most of their operational focus is on the operation of IT systems. ITIL should clarify what processes operate and maintain IT services. Unless there is a focus on a service as a whole, an IT organization will only manage the piece-parts of a service, which will not make for very robust services.

How do you keep Configuration Management and Asset Management distinct, yet integrated?

One of the most innovative (and most difficult!) aspects of ITIL was the concept of configuration management. This process allows an IT organization to keep track of everything in its infrastructure, as well as the relationships between elements of the infrastructure.

Most IT organizations had been practicing asset management prior to the advent of ITIL. Both asset management and configuration management keep track of things in the infrastructure, but for different purposes. Configuration management did not address the additional functions provided by asset management.

This left ITSM organizations with two overlapping processes – configuration management and asset management. Both are needed, but there is little advice on how to keep both of these in sync. For instance, if you want to audit what’s in your IT infrastructure, do you start with configuration management or asset management? What if there’s a conflict between the two databases? Should they be two databases, or should they be a single integrated database used for multiple purposes?

My Wish

So, with visions of service requests and service management dancing in my head, I’ll settle down to a long winter’s nap. And I hope to hear the jolly laughter of someone delivering these answers in my Christmas stocking before I wake.

Author:
John Long
j1long@us.ibm.com

Assuring the “Service” in Service Management – Part 2

In the first part of this series, we looked at the impact that workload, speed of change and technology complexity is having to companies in search of Service Excellence, overviewed the SLM process, introduced the IBM Service Management(ISM) Service Level Management Process Manager (SLMPM) and discussed automating SLM. The second and final part addresses best practices implemented in the Process Manager.

Best practices implemented in the Process Manager

The Service Level Management process manager will provide best practices, in the form of process workflow definitions, for the following:

• Create and maintain agreements (SLA, OLA and UC)
• Conduct Service Review
• Formulate Service Improvement Plan
• Create and Maintain Service Catalog
• SLA Adjudication

Supporting tasks (tasks that are performed outside of a process template) will be provided for the Monitor and Report on SLA Achievement process. It should be noted that not all of the above best practices may be available in the first release of the SLM Process Manager; it may take several releases to get all the processes fully implemented.

Create and Maintain Agreements Process Workflow Definition

Multiple process workflows (best practices) will be provided for the Create and Maintain Service Level Agreements process. The different workflow definitions reflect the differences in the process flow required based upon the type of agreement being processed. There will be unique process workflow provided for creating and updating SLAs, OLAs and UCs. There may also be additional workflow definitions for creating a specific type of SLA, for example an SLA associated with transaction response time may have a different process template than an SLA for incident resolution times.

The image below shows all the activities that are available for the Create and Maintain SLA process workflows. It is important to realize that every activity isn’t performed in all process workflow definition. For example, if the create process is being performed for an OLA the "Negotiate SLA" activity wouldn’t be contained in the process template for creating Operation Level Agreements. The user of the process could add that activity to the default process template if the organization wanted it performed for OLAs using the ISM process customization views provided. The tasks that are performed as part of each activity aren’t discussed in this article but the image below does provide a high-level description of the activity and tasks comprising that activity.

Create and Maintain SLA Activities

The Create and Maintain processes will leverage resources and relationships contained in the CCMDB to help determine which resources and dependencies are needed to provide the service for which the agreement is being implemented. These resources, their dependents and their dependencies (as represented in the CCMDB) will be analyzed to determine if each is being monitored and being monitored in a way to support the data needed for the agreement. The monitoring information will be obtained by leveraging the Discovery Library Adapters (DLA) provided by many of the Tivoli monitoring tools. These products will load the resources they monitor into the CCMDB via their DLA and the CCMDB will record that the Change Item (resource) is monitored by the Operational Management Product (OMP) that is the source of the DLA information.

The output of the Create and Maintain SLAs process is an agreement (SLA, OLA and UC) that has been reviewed, clearly documented, approved and enacted. The SLMPM is optimized to allow the agreements created via the process to be fed into the Tivoli products that monitor and report on SLA achievement. The Tivoli Business Service Manager (TBSM) and Tivoli Service Level Advisor (TSLA) products will be able to directly consume the output of the SLMPM process workflows associated with creating and maintaining SLA, OLA and UC agreements. This will allow the agreement definitions needed in TSLA and TBSM to be created using the information collected during the SLM process execution, thus reducing the time needed to create and maintain the definitions in the OMPs.

Conduct Service Review

A process template representing the best practice for the SLM Conduct Service Review process will be provided. This template will contain the activities shown in the diagram below. The process can be invoked manually on an on-demand basis or be scheduled to occur on a regular (weekly or monthly are typical frequencies) per agreement basis. An imbedded activity in this process is the SLA Adjudication activity, discussed in further detail below.

Conduct Service Review Activities

SLA Adjudication Process Template

SLMPM process workflows will also be provided for activities that have been identified as SLM best practices when doing the SLMPM process, activity and task design. A good example of this is SLA adjudication. While not explicitly called out as an SLM process in ITIL or ITUP, SLA adjudication is a necessary activity in any organization that has implemented Service Level Management. SLA adjudication deals with the process of adjusting the data or results associated with SLA attainment for a specific period. These adjustments are allowable and necessary when SLA attainment isn’t achieved and the reason(s) for not achieving the SLA are not the fault of the service provider. For example a network failure occurred but the network isn’t part of the SLA contract with an application provider. In SLA adjudication the outage associated with the network failure would be removed from the SLA evaluation and the SLA attainment numbers would be recalculated. The SLMPM will provide an activity template for SLA adjudication.

SLA Adjudication Activity Tasks

Monitor and Report on SLA Achievement

The SLM process of Monitor and Report Service Level Achievements is where the availability metrics for the agreement are analyzed to determine if the agreement was satisfied for the reporting period. The SLMPM will not provide this analytics engine. The determination and analytics associated with SLA achievement is the responsibility of OMPs (TSLA or TBSM) or customer specific processes or products. The output of analyzing the SLA attainment is utilized by the SLMPM as input into the Conduct Service Review and Formulate Service Improvement Plan processes. Process workflows will be provided by SLMPM for both these processes.

In summary, SLM can help customers achieve service excellence and can be used as an initiative to drive the alignment between the business and Service Management. Customers can leverage TSLA today as the foundation for SLM and then move to automate the process when the SLMPM is available.

Authors:
Chris Terry, Wayne Riley and James Moore

Assuring the “Service” in Service Management – Part 1

Overview

There has been quite a bit written about Service Management and achieving Service excellence over the past couple of years. Catch phrases like "agility, flexibility, visibility and integration capability that highlight the characteristics of service excellence abound yet in a recent CEO study 78% of the CEOs interviewed believe that integrating business and technology is of great importance to driving business growth yet only 45% of them believe that they have successfully integrated business and technology in their organizations.

IT departments are under ever increasing pressure to deliver more with less, provide cost effective solutions while at the same time aligning IT management with the goals and objectives of the business. End users are demanding better response times and have little patience with IT concerns about the complexity of the IT fabric that ultimately enables, or in some cases hinders, their ability to do their job.

To make matters worse, pent-up demand is putting CIO’s under incredible pressure for new projects, according to "The State of the CIO 2006," an annual survey by CIO.com, demand for IT is back with a vengeance. It's almost like the late 1990s. Except that what's missing now is the money, staff and late-night takeout to deal with today's demand. In turn, the backlog of requests for IT projects continues to grow. CIOs say that managing this application backlog is the number-one barrier to their job effectiveness today, regardless of industry or company size.

Ultimately the CIO is responsible for Service Delivery and must balance the requests inundating them for new service with ensuring that the services already provided are meeting customer’s expectations. With the complexity of an ever changing IT environment that enable composite applications spanning multiple technology towers how in the world can the CIO feel any sense of well being that they are able to assure the performance of existing IT services, let alone try and successfully roll out new ones ?

Managing customer expectations of a service is absolutely critical yet is elusive without a way of clearly understanding the service requirements, monitoring, measuring, and reporting actual attainment results and improving the service over time, enter Service Level Management(SLM). This is part one of a two part series which explores ways of assuring the "Service" in Service Level Management.

Service Level management

The objective of SLM is to define, implement, automate, measure and improve the level of service availability, after-all, one can’t improve what isn’t monitored and measured. SLM allows the IT organization to properly allocate critical resources to provide the required service availability as defined with the users (customers) of that service; eliminating the costly errors of over providing when not necessary or under providing when critical.

From an Information Technology Infrastructure Library (ITIL) perspective the goal of SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service – in line with business or cost justification.

SLM is one of the few ITIL processes that have the stigma of having a penalty associated with implementing the process; the fear that you must commit to service availability, be accountable for that availability (via attainment reports) and potentially be required pay a financial penalty if committed availability is not delivered. However, in reality a properly implemented SLM process allows the IT organization to clearly understand service availability requirements, properly allocate scarce resources, assess changes and evaluate new services with confidence and most importantly, hard data.

Several conditions can bolster a Service Level Management initiative. These conditions include sufficient management support, common understanding of, and agreement to the goals the SLM practice are meant to achieve, and standardized methods for defining, measuring, monitoring, reporting and refining the levels of service provided.

Since these conditions are not always present, they have been cited as common obstacles to realizing the full benefits of Service Level Management. However, the absence of these ideal conditions should not be deemed as obstructive prerequisites, but as conditions that an SLM process initiative can help realize. If organizations implement the appropriate balance of tools and processes to guide and leverage its collective knowledge and experience, then consensus, support and standards are easier to achieve.

The way to find the appropriate balance of tools and process can depend greatly on the predominant orientation of the organization. Depending upon an organization’s levels of IT maturity, organizational structure, and culture, it may approach SLM from different starting points. Although there are multiple ways to categorize current IT methodologies and maturity, the most predominant entry points to SLM are from a Business Service Management approach, an IT Operational and Resource orientation, and a Service Desk orientation.

The Business Service Management approach usually involves a top-down, business-oriented driving of IT, where both business and IT relationships are clearly understood and aligned. Organizations implementing BSM in tandem with SLM tend to treat IT as a service, focusing on service quality and service guarantees.

Many organizations are implementing SLM from an IT Operational and Resource orientation. This common approach to IT management, with an event management focus on real-time, reactive, fault management, has traditionally not included mature, refined IT service management processes. This approach has resulted in event consoles that often display component-specific faults that do not represent IT service status. It is common for organizations to focus solely on the granular elements of IT, often split into silos, or groups based upon the types of IT resources operated.

It is also common for the organizations running Service Desk tools to drive requirements for SLM. Since Service Desk tools are critical to enable organizations to react to and manage IT incidents and user problems, it is critical that achievable targets and customer or user expectations are set. SLM in this context tends to focus on an organization’s aptitude in closing trouble tickets associated with incidents and problems. However, it is becoming more common to leverage the metrics produced by traditional Service Desk tools, in overall SLM efforts.

For organizations in each area of orientation to SLM there is a valuable level of input, assessment, organization, and output of information that an effective SLM process can facilitate. To initiate or refine an SLM process, tangible and widely understandable mechanisms will need to be used to obtain sufficient consensus. The most common way to do so is through Service Level Agreements (SLAs), Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). SLAs document the service levels external customers should expect, while OLAs are used to document internal service delivery, such as between an IT organization and internal department. UCs document service delivery obligations between an organization and its vendors.

There are five top-level processes defined for SLM; Create and Maintain Service Catalog, Create and Maintain Service Level Agreements (this encompasses SLA, OLA and UC), Monitor and Report on SLA Achievement, Conduct Service Review and Formulate Service Improvement Plan.

ITIL SLM Processes

Each of the above top-level SLM processes is decomposed into a set of activities that need to be performed to support that process. The activities are further decomposed into the tasks necessary to complete each activity. A common question asked by IT organizations when considering the SLM process is where to start and what should we be doing for each SLM process? To help answer these questions an ITSM Service Level Management Process Manager (SLMPM) is being developed. The SLMPM will provide process workflow definitions (a definition of the ordering of activities and tasks) to cover the five SLM processes shown above. The process workflows represent the instantiation of an ITSM best practice for performing and implementing these SLM processes.

Automating SLM

This section describes the IBM Service Management(ISM) Service Level Management Process Manager (SLMPM). At the time of this publication the Service Level Management Process Manager is still being designed and developed. The first product version is planned to ship in the 2007 or 2008 timeframe. The contents of this section are based upon what is anticipated as being in the fully implemented Service Level Management Process Manager. However, it should be noted that the actual functions and features provided in the SLMPM may differ slightly from what is contained in this section of the article.

The Service Level Management Process Manager is being designed to address specific key pain points associated with adopting and implementing the SLM processes such as those defined by ITIL.

These main points are:

• Clarification of what are the necessary activities, tasks and artifacts that need to be considered when implementing SLM
  • The ITIL Service Level Management documentation doesn’t provide sufficient detail- to allow the reader effectively implement SLM
• Allow an IT organization to commit to agreements with confidence and in a timely manner
  • Provide data, leveraging the Change and Configuration Management DataBase (CCMDB), which allows a clear understanding of the IT components and component dependencies that exist and must be monitored to support an agreement.
• Facilitate the collaboration required across the multiple roles involved in establishing an agreement
  • Utilize the ISM process engine to ensure engagement of the proper individuals for task completion, reviews and approvals in a consistent and repeatable process.

The SLMPM provides process workflow definitions which contain activity and task definitions to support the ITIL and IBM Tivoli Unified Process (ITUP) definition of the SLM process. As the SLMPM process workflows are exercised the appropriate process artifacts are collected to provide reporting, audit information and document the supporting data utilized to make decisions (human or automated) while completing SLM activities and tasks. The SLMPM process supports creation and maintenance for the following types of agreements; SLA, OLA and UC. Process workflow definitions are provided to support each type of agreement and the tasks contained in the process definitions will adjust their data content as necessary depending on the type of agreement the task execution is addressing.

In the next part of this series, we will look at the best practices provided by the IBM Service Management(ISM) Service Level Management Process Manager.

Authors:
Chris Terry, Wayne Riley and James Moore

Elements of Business Service Management- Part 1- A Better Working Definition for Business Service Management

I've been involved with Business Service Management efforts for the better part of the last five years in the enterprise and service provider spaces and now as part of IBM Tivoli. One thing that continues to be a general issue in this space is that there has never been a really good working definition of what Business Service Management is. The definition that I most frequently reference is the one from Deb Curtis of Gartner which most people have seen in Gartner presentations on the topic of Business Service Management. I've found that it was sufficient in the early days to give the vendor community and early adopters something to rally around, but now as Business Service Management makes attempts to become more broadly adopted, we need a better working definition for what Business Service Management is.

I'm starting a series of postings that will focus on what I call "Elements of Business Service Management". Firstly, a better working definition for what Business Service Management is. This is my definition for Business Service Management, not IBM's, an analyst's, etc. Take it for what it is and use it as a reference as you define what Business Service Management is for you and your company. Yes, that's right. You need to define what Business Service Management is within your organization, how you'll use the concepts of Business Service Management to help you and your company achieve their business goals and objectives. Use it as a catalyst to help define where you are and where you want to be in your Business Service Management journey and how Business Service Management will help more closely align IT with the Business and Business with IT.

Follow on postings within this series will be focused on helping you get there. Where? That's what you'll be determining - your own Business Service Management Maturity Model, Strategy and Roadmap. I'll share my thoughts and ideas on what a Business Service Management maturity model looks like as aligned with the Gartner IT Maturity Model. Using this, you'll be able to determine where you are today and learn about practical steps you can take towards maturity with Business Service Management in your company.

Part 1- A Better Working Definition for Business Service Management

Business Service Management is an enabling technology at the intersection of business and IT alignment. The days of IT organizations operating with only an understanding of the IT perspective are quickly passing. Business Service Management brings the business perspective and context to the IT environment. Business Service Management solutions help IT understand how their infrastructure and technology investments support the business and how business benefits from that IT infrastructure and technology.

Business Service Management is a strategy, approach and methodology for aligning IT elements to the goals of the business. Business Service Management is about communicating the right message at the right time to the right level within IT and the business in business terms or IT terms as appropriate for each audience. Business Service Management is about delivering and maintaining quality services, applications, processes, activities and transactions to the business so business goals and objectives are met - not IT's.

Business Service Management is about understanding how IT impacts the business and how business impacts IT. It's about the known and unknown relationships and dependencies between IT and the business. How either one may affect the other. How IT best practices, processes and activities such as change and release management may impact a business entity, transaction, process or activity.

What was done years ago by creating a "single pane of glass" for the network and systems management industry, Business Service Management creates a similar "single pane of glass" for IT infrastructure and technology and how it supports and enables the business to meet its goals and objectives (make money, control costs, etc.)

Business Service Management is the integration and consolidation of systems management with business management. It’s the creation of service and operational level agreements (SLA/SLO), underpinning contracts (UPCs), policies, rules and thresholds for business services, applications, processes, activities and transactions much the same way it’s done for a server or network device. Business Service Management is about enabling IT operations and support staff with empowering information that helps them to understand the impact on the business in business terms. Business Service Management helps IT at all levels prioritize restoration, improve communication, and establish deeper relationships with their business peers.

Business Service Management isn’t just about presenting a pretty dashboard with fancy dials, gauges, stoplights or colors. Business Service Management is the management of IT with a purpose on purpose. Business Service Management solutions, dashboards and information communicate purpose built messages tailored for each specific audience. The IT infrastructure and technology information, status, metrics, etc. are organized and grouped together with the proper context and technique so that these audiences can make important decisions or take action that enables continued business success.

Business Service Management is about understanding the business perspective also known as the "top down perspective". What value, revenue, cost, churn, ROI, etc. can be associated with the IT services, applications, processes, transactions, etc. being delivered and supported by your IT organization? How does IT enable the business to meet their goals and objectives? What are the "hidden linkages" between business and IT performance and compensation plans and business and IT service availability, performance, etc? Business Service Management leaves no stone unturned. Business services, activities, processes, transactions, etc. are understood from the business user’s perspective, internally and externally, in their terms, their language, their performance expectations, understanding the impact on their jobs, productivity, goals and objectives, etc.

Business Service Management is an evolutionary process that takes time and energy to implement. Don’t expect to get Business Service Management out of the box or overnight. Every industry, vertical, segment, new venture, product line, service offering, etc. is unique. A vendor's solution may get you in the ballpark, but significant work will still be required along the way towards reaching your desired maturity state. There are significant dependencies on getting your own house in order and building a strong relationship with others both in IT and the business to be successful with Business Service Management. The people and process components of Business Service Management solutions are equally, if not more, important than the technology components you’ll get from a vendor. The Business Service Management Maturity Model topics in future postings will give you an idea of how to understand where you are and where you may want to be over time.

Take the time to consider these ideas as you craft your own definition of Business Service Management. You'll be more successful if you can remove as much grey area as possible about what Business Service Management is and why it's important for your company. Align it with the company/CEO/CIO's goals and objectives, what's important to the business units you support, etc. Spend as much time as possible focusing on tangible and measurable benefits. The soft benefits will be plenty, but through hard work and relationship building you should be able to quantify measurable value and benefit from Business Service Management with your new found business peers and partners.

Doug McClure
Consulting IT Architect
Business and IT Service Management (BSM/ITSM)
IBM Software Services for Tivoli (ISST) - Netcool
e: dmcclure@us.ibm.com
w: +1-678-267-3120 c: +1-404-386-0288
BSM/ITSM Blog: http://dougmcclure.net

Being Capable in IT Service Management is a Moving Target

The challenges to be successful in IT Service Management (ITSM) continue to deepen and broaden. You might well have recently achieved certification in the ISO/IEC 20000 Service Management standard. Rightly, you pause to congratulate yourself, but you know you cannot stop in your improvement efforts. There is a strong argument that a capable management of services today will fail to be assessed as such tomorrow. It is worth exploring several of the reasons why this could happen – in this discussion, I’ll focus just on the set related to technology.

Virtualization provides an excellent initial example. It is entirely possible that a large number of physical servers will be consolidated onto a smaller number of virtualized servers without any change in the service as seen by its users.

If your service management has previously been based around having each physical server being configured in a fixed way and associated with a single service then virtualization will likely mean that well-established, efficient and effective capabilities require major re-design and new implementations.

• Does the data model for your CMDB allow for one:many relationships between physical and logical? Does it even have a definition for a logical server?
• How do you express the maximum capacity of a logical server when this is no longer fixed, and the hypervisor is able dynamically to adjust the proportion of the physical hardware between partitions?

More likely, technology changes will also bring with them new service designs – and each of these can bring similarly disruptive implications to service management. What can seem to be a small progression in terms of application or end user capability can turn out to be dramatic in manageability terms.

I remember working with one company in the early 90s where they were moving from the classic mainframe with ‘dumb’ screens to a new architecture where local departmental systems would replace the screen control unit and PCs the screens themselves. For the initial rollout, they would be using screen-scraping techniques and so the actual mainframe application would not be modified.

To the architects of this solution, this meant that there were few new challenges in managing its live usage, at least until they later would start to write new applications in client-server style. They were crestfallen when we suggested that – from a management viewpoint – this would be a full-scale 3-tier architecture from day one. For example, they would need a software distribution system able to reach both Unix servers and – through them – a large number of Windows-based PCs.

Virtualization could well be associated with designing a service that uses a pool of logical servers – for example, as web or application servers. How do you define and measure availability in this case? Does the loss of an individual server have an availability impact? The answer is, of course, ‘it depends’. Perhaps an individual transaction might be lost, and the particular user would then need to re-enter some data. This scenario seems unlikely to cause an availability impact, but you would like to think that you have a measure of such interrupts.

From the service provider viewpoint, this particular logical server could have been lost because of a fault which also took out all the other logical servers on this physical machine. It seems likely that the service provider would want to consider this as an availability impact, even if – because of redundancy and other techniques in the design – no individual customer service perceived an availability issue.

My point here is that developments in technology – and in the designs which can exploit them – are always just ahead of you, or could even have already made unforeseen impacts on your service management capability.

Pioneers in the use of technology developments like these will inevitably find that they need to invent and innovate for each circumstance. For most of us, we would like to think that we can learn from their successes and mistakes. To my way of thinking, there is a need for a body of knowledge that is based upon sound science and academic approach to be created.

Author:
Chris Finden-Browne is an Executive Consultant specialising in IT Management issues, with a particular focus on processes. He has been at the heart of the development of both ITPM and PRM-IT. He has employed them in engagements with IBM customers in both Europe and North America, and has taught the models (and their associated consulting techniques) to many hundreds of IBM consultants throughout the world.

Service Management and Air Traffic Control

"Many participants in commercial aviation have become frustrated by what they view as inefficiencies in the national airspace. These inefficiencies transfer into flight delays, occasionally missed connections, passenger complaints, excess fuel consumption, excess crew time, and ultimately, loss of revenue for companies that already have a very thin profit margin." Source – The Future of Air Traffic Control, National Research Council (US Staff)

Sound familiar????? No matter what business you’re in, inefficiencies transfer to lost revenue. Conquering those inefficiencies is one of the most difficult challenges an organization faces. We’re all dependant on the integration of technology, people, processes and information to help us manage our organizations more efficiently and effectively. We all need to improve and mature the way we do business as the industry we’re in grows and changes. That’s what Service Management is all about.

In this blog I’ll review how the principles of service management (even though it wasn’t called service management in those days) have been applied to Air Traffic Control (ATC) to mature and improve it over the years. Given the high visibility of the aviation industry’s performance and the fatal impact to people if something doesn’t work right, this industry has been pursuing a path of improvement since the 1920s. It’s a highly complex and regulated industry that has experienced tremendous growth as increasing demand has driven more and more people to fly the friendly skies. Perhaps there are some similarities and lessons learned from the maturation of ATC that can be analyzed and applied to your business.

The following chart depicts the ATC maturation process beginning in the 1920s and continuing today.

In this blog I’ll concentrate on the maturation of the technology and in the future discuss governance, process and people.

First and foremost – air travel had to be SAFE.

How is technology used to meet this challenge? It’s an oversimplification, but largely through the use of radar and computer capabilities and the exploitation of automation and visualization. Who could have predicted that today the National Airspace System would include more than 19,000 airports, 750 ATC facilities, and about 45,000 pieces of equipment. It would be impossible to manage this complex system without the introduction of technology.

Reactive = Manual Tracking

In the earliest days of aviation, so few aircraft were in the skies that there was little need for ground-based control of aircraft. I worked at an Air Traffic Control en route center many years ago with some of the original air traffic controllers. In the "good old days" as one of them described it, they tracked the position of planes using maps and blackboard and by visualizing airplane locations in their heads. They could do this because there were few airports and much fewer types of planes. They could predict what was happening with a high degree of confidence. But……nothing stays the same.

Repeatable = Information Foundation and Initial Visualization

The introduction of radar was an important postwar milestone and a revolutionary development in Air Traffic Control (ATC). This made it possible that not only the pilot knew his position, but the controllers also knew the aircraft’s position. As you can imagine, the ability to visualize the positions of the planes with a high degree of accuracy helped prevent air-crashes. The implementation of radar laid the foundation for later improvements in air traffic management by providing the aircraft positioning information necessary to manage location.

Managed = Integration of Flight Information, Initial Automation, Improved Visualization

Experimental use of computers in ATC began in 1956 spurred by an air-crash over the Grand Canyon. A determined drive to apply this technology started in the 1960s. By connecting computer systems to each other controllers were able to see for the first time how many aircraft there would be departing or arriving at a definite moment. Controllers viewed information sent by aircraft transponders to form alphanumeric symbols on a simulated three-dimensional radar screen. By automating some routine tasks, the system allowed controllers to focus on providing aircraft separation.

Predictable = Increased Automation, Improved Visualization

In 1988 the FAA recognized the need for further modernization of air traffic control and contracted the development of the Advanced Automation System (AAS). AAS included controller workstations, called "sector suites," that would incorporate new display, communications and processing capabilities. The system would also include new computer hardware and software to bring the air traffic control system to higher levels of automation.

Optimized = Use of Global Positioning for Improved Tracking

In 1994, the concept of Free Flight was introduced. It might eventually allow pilots to use onboard instruments and electronics to maintain a safe distance between planes and to reduce their reliance on ground controllers. Full implementation of this concept would involve technology that made use of the Global Positioning System to help track the position of aircraft. In 1998, the FAA and industry began applying some of the early capabilities developed by the Free Flight program.

By laying a strong technology foundation with radar and computers, the aviation industry was able to exploit that foundation by adding visualization and automation to provide necessary capabilities as the industry grew and changed. So, while many participants in commercial aviation have become frustrated by what they view as inefficiencies in the national airspace there has been tremendous progress. Sure there are delays and room for improvement. But, when you get on that plane you’re confident you’ll get where you’re going safe and sound. Or you most certainly wouldn’t use that service!

What does this have to do with your organization and how can it be applied? Are you getting the most out of your technology? Do you have the information foundation in place that will allow you to exploit automation and visualization techniques to manage your technology and therefore your business? Are you confident that the users of your business services will get what they need when they need it? Or, aren’t they using your service?

Author:
Debbie Langenfeld
Certified ITIL Service Master
djlangen@us.ibm.com

Hey, This ITSM Thing is Great!! So How Do I Get Started?

After looking at all the facts, you’ve decided implementing IT Service Management is an important initiative for your organization. You and your colleagues have been to ITIL training and are now armed with a shiny diamond shaped pins and a bunch of new "buzzacronyms" like CI and CMDB. So it is time for a quick one-question quiz: what do you do next?

The answer isn’t so easy, is it? (If you answered "study the ITIL ‘Planning to Implement IT Service Management’ book", you get negative 10 points for the quiz.) Unfortunately, many organizations have stumbled over this very question. According to a recent survey, not knowing where to start and focus is the second biggest inhibitor to ITSM implementation. (By the way, the biggest inhibitor is overcoming "organizational resistance". I’ll write on this topic just as soon as I finish my treatise on achieving world peace.)

So why is getting started so tough? Here are a few key reasons:

• Organization has different capabilities and objectives – so one size won’t fit all
• ITSM involves multiple processes and capabilities, which are in turn dependent on each other to be fully effective. These dependencies must be factored in developing a plan to adopt ITSM.
• Processes and capabilities have multiple dimensions that must be considered, for instance, effectiveness, level of automation, and governance.
• These processes and capabilities typically span organizational and technological silos.

Fortunately, the fundamental process for implementing ITSM is fairly straightforward, and looks a lot like any process for making change (business planning, for instance). The following graphic gives a high level perspective:

I will focus on the blue part of the diagram in this blog and take up the green and yellow areas in the near future. The purpose of the blue steps is to assess your organization’s capabilities and objectives to arrive at agreed to priority areas for improvement. When doing this, you should take a holistic view and avoid jumping into the technical weeds. For instance, pursuing a discussion on the merits of a particular CMDB schema is not appropriate at this juncture. Likewise, talking about solutions before you have agreed on priorities is not productive. Also be wary of vendors that have tools that purport to help you determine ITSM priorities, but primarily exist to point you magically to their solutions.

Luckily, useful tools are available to help you. Two notable ones are available from the IT Service Management Forum and IBM. The itSMF’s ITIL Self-Assessment tool covers the 10 ITIL Service Management processes plus the service desk. It asks questions specific to those areas and produces a report that shows how well your organization is performing compared to ITIL best practice. In addition, it provides benchmark data that shows how your organization rates versus other respondents.

The ITSMF assessment is useful, but it has a couple of notable limitations. First, its reports rate you versus best practices for each area. While this approach identifies deficiencies versus best practices, it doesn’t provide a direct report on how important these areas are versus the others, which is essential for prioritizing efforts. Second, the assessment does not address the area of automation, which is critical for improving efficiency in many areas.

When using benchmark data, you need to keep a couple of things in perspective. Benchmarks show how you stack up against others, but they shouldn’t ultimately determine your priorities. Your priorities should be determined by evaluating how capable your organization is in an area compared to the importance of that area to meeting your objectives. Other respondents in the benchmark may have different priorities. Also keep in mind benchmarks are only as good as the data they are based on. Not all respondents answer questions as diligently and accurately as they should.

IBM’s recently launched ITSM Self-Assessment serves as a good complement to the itSMF tool. The IBM assessment is significantly broader in scope. It includes the same processes as the itSMF assessment, but you can also choose to add up to 20 additional process areas if you want to evaluate, for instance, solution development, asset management, or security. This tool helps you rate the importance, capability, level of automation, and effectiveness of governance for each area. It then uses this information to generate reports that identifying relative priorities for:

• Process improvement -- capability versus importance
• Labor savings – level of automation versus labor spend
• Governance – process importance versus control
• Overall Priorities – factors in each of the areas listed above

In practice, since the IBM tool helps directly determine priorities, it may be best to take it first before proceeding to more diagnostic tools like the itSMF assessment.

I’ll write about the next step of the journey, determining your ITSM adoption roadmap (the green area of the diagram) in the near future.

Author:
Rob Goodling
rgoodlin@us.ibm.com

Customizing ITIL Processes for Your Organization

Several years ago, there was a cartoon series called "Pinky and the Brain", about two lab mice. During every episode, Pinky would say, "What are we going to do tonight, Brain?".

"The same thing we do every night, Pinky – try and take over the world!", was the inevitable reply from the Brain.

During each episode, the pair would hatch a "fool-proof" scheme for taking over the world, but each scheme depended on some prerequisite that they inevitably failed at. For instance, in order to create an enormous clothes dryer that would produce enough static electricity to force the world to submit to them, the mice had to find land large enough to build such a dryer. They had big plans, but got tripped up in their early first steps.

Organizations who want to implement ITIL often have good strategic plans about providing standard services, improving IT support, and reducing the total cost of ownership. Unfortunately, it is easy to get tripped up in the early steps.

An important first step in implementing ITIL is to come up with workable workflows for the processes you are going to deploy. As valuable as the ITIL documentation is, it doesn’t provide detailed workflows. A new product by IBM, the IBM Tivoli Unified Process Composer (ITUP Composer), provides detailed workflows and the ability to customize them for your organization.

The ITUP Composer is an outgrowth of the simpler ITUP tool that was released last year. ITUP (not to be confused with ITUP Composer), is a free tool that provides high-level workflows for 17 IT Service Management processes, but it was read-only. By moving to ITUP Composer, you can take detailed, ideal IT process workflows, and customize them to match how you do things in your organization.

To indicate the difference in complexity, it should be noted that ITUP contains 17 processes and 80+ activities. ITUP Composer adds 500+ tasks to those activities.

ITUP Composer was created with Rational Method Composer, the same tool that is used to create the Rational Unified Process. RMC is provided as part of ITUP Composer and is used to customize the content. The customization effort involves creating your own plug-in within RMC that uses content variability to overlay your customizations on the original IBM content. This allows you to make your own changes without removing the original source content.

Creating your process workflows is an important first step toward eventual world domination. Uh, that is, I mean toward complete and effective implementation of ITIL.

Author
John O Long
j1long@us.ibm.com