Service Transition, Change, and the Service Desk

As I was preparing to write this chapter, I spoke with several IT practitioners who indicated that they were using ITIL. Most of them indicated they were using ITIL V2. I was somewhat surprised that when I asked them when they were moving to ITIL V3, most answered something to the effect of, "We went through enough pain with ITIL V2. What's the point of moving to V3 if we already have built our service processes around V2? What's the big difference?"

ITIL V3 Perspective of Service Transition

So, what is the big difference between ITIL V2 and ITIL V3? I discussed the differences Chapter 1; however, it is worth taking a closer look at the differences as they reflect the changes in business focus. Table 2.1 compares and contrasts the high-level business issues for ITIL V2 and ITIL V3.

Table 2.1: High-level ITIL V2 and ITIL V3 differences.

Service Transition seeks to ensure that all the planned changes will be implemented in ways that actually meet the defined objectives. The processes within Service Transition activities include focus upon:

• Change Management
• Service Asset and Configuration Management
• Release and Deployment Management
• Knowledge Management
• Stakeholder Management
• Transition Planning
• Support and Service Evaluation

All these activities are supported by a Configuration Management Database (CMDB) and Configuration Management System (CMS).

Why Is Service Transition Necessary?

Throughout our lives, we have probably heard a million times the phrase "be prepared." So it should make sense that IT leaders must ensure the enterprise infrastructure, supporting components, personnel, and resources are prepared for changes. However, historically the preparation portion of IT changes have been shortchanged, and as a result of inadequate preparation, changes often resulted in problems and incidents that caused downtime and business stoppage. Service Transition is necessary to ensure that the changes you want to make will have the highest likelihood of meeting your objectives in addition to having little or no negative business impact.

By using the seven IT processes previously listed, IT leaders can be confident that changes will be efficiently and effectively managed across the enterprise to the benefit, not impediment, of the business. For example, suppose your organization just acquired another company. Service Transition can be used to ensure you align the services of the acquired company with your business requirements and operations prior to actually connecting the acquired network to your infrastructure. By doing careful planning for this significant change, you can help ensure that the individuals who need to use the existing and new services can do so with minimal business downtime and incidents, ultimately adding value to the associated business operations.

The value of Service Transition is fairly obvious for mergers and acquisitions. But there are many additional business values Service Transition activities provide:

• What if your marketing area wants to implement a new campaign to maintain a competitive edge and must act quickly? Following Service Transition processes will help ensure a quick change that meets the business objectives with minimal business disruption.
• What if your success rates for changes and releases have been poor to the point that business leaders complain that IT seems to be a liability to business and they start looking into outsourcing all IT activities? Implementing effective Service Transition processes can dramatically improve change and release success and demonstrate the value of the inhouse IT function.
• What if your business leaders are worried that implementing a new application or system will have unacceptable negative business impact? Effective Service Transition processes will help to document, demonstrate, and allow business leaders to understand the levels of risk prior to and immediately following the changes.

New Perspectives of Service Transition

The good old days of business computing are generally considered to be back before the mid1990s when most business processing was done on mainframes. The IT folks were basically curtained off from the business and only worried about keeping the computer systems chugging along and up as close to 100% as possible. The programmers had to have a basic understanding of business to do their coding, but relied heavily upon their business unit contacts to test and verify that their programs worked appropriately for business. The programmer managers' biggest gripes were the ongoing onslaught of spaghetti code that made debugging a nightmare.

These are still issues, but now they are joined by highly decentralized systems and applications, and not only spaghetti code in programs but also a huge spaghetti bowl of network components that must be efficiently managed to keep mission-critical applications available and business going for as close to 100% of the time as possible. In addition to this increased complexity, it is now incumbent upon not only IT management but also all IT staff to soundly understand the business that they are supporting so that they can most appropriately establish their priorities, determine risks, and identify interrelationships that changes, problems, and incidents can impact.

Being as supportive as possible to business unit customers is more important than ever before to IT. Customer-focused delivery and orientation is one of the most important strategic considerations for IT management in today's enterprises.

I have asked many IT practitioners how their job responsibilities and activities impact their business. I have heard far too many practitioners reply something to the effect of, "I really don't know much about the business. I just focus on knowing about the network and how it works." This prevalent perspective leads to the business being far less successful than it could be. Organizations must deliver IT services in the context of the business. To do so successfully, IT personnel must have an understating of the business so that they can communicate effectively with their business customers.

Good understanding of business allows for realistic service level expectations and opportunities to provide IT services and support that allow for business to not only chug along but also actually result in business improvements.

Perceptive IT leaders understand that IT activities must align with business activities and goals. They know that the business is depending upon IT to make business-critical services highly available and to ensure the quality and accuracy of those services. In publications, at professional meetings, and anywhere IT leaders gather, they commonly state that better aligning IT with business is one of their top priorities. However, is any progress being made?

To successfully align IT with business, IT leaders must have three primary goals:

• Ensure business-critical services are available whenever needed and with the highest possible quality
• Deliver IT services at optimal cost while appropriately managing risk
• Understand the business and how IT can drive value, not just utility, for the organization Achieving these goals requires a slightly different bent on the view of IT within business. More emphasis must be placed upon business availability, business quality, business cost optimization, business compliance and business risk reduction than ever before. It is absolutely imperative for IT leaders to start thinking, and planning, like business leaders. The ITIL V3 framework facilitates this, and Service Transition in particular provides the processes necessary to engage business thinking throughout all layers of IT activities.

Meet Complexity Challenges

Never before in the history of business computing have technology and networks been more complex. And guess what? It is only going to become more complex as the pace of technology development explodes on a continuous basis. The IT area now provides a dizzying array of services, including the good old mainframe and server management, and is branching out into unified communications with voice services, online media broadcasting, Internet access, social networking support, and an unlimited number of others.

Added to this complexity is another dimension, including such things as server virtualization, the use of Software as a Service (SaaS) solutions, and a growing dependency upon automated tools. These certainly can bring great benefits to business, but their additional layers of operations processes and software exponentially increase the number of IT components for the IT area to manage.

This complexity spawned specialization silos, which are basically separate business systems and applications incapable of reciprocal operation with other silos, which worked for a while. Even ITIL V2 implied the use of silos. However, ITIL V3 wisely retooled their framework to allow for all IT infrastructure elements to work together seamlessly in an effort to deliver highly available, high-quality, and highly efficient operations. This does not mean that specialization is dead; it just means that the specialists must all work together better than they ever have before.

The Speed of Change

Not only are IT services and components more complex, they must also be changed more quickly and frequently. Newly discovered flaws and vulnerabilities that could be exploited and damage business continue to be announced on an almost-daily basis. Add to this a forever changing economic market and volatile economic conditions, and even more changes are a must for successful business. Continual change results in continual redeployment of existing IT assets paired with deployment of new systems, applications, and technologies to improve IT agility and its ability to respond to yet more change.

More Entities Communicate with IT

Way back in the olden' days, the IT folks sat in their offices, hidden away from contact with not only external customers but also internal business customers. However, with increased complexity and the need for more speedy changes, the IT players are no longer relegated to the back office. They are increasingly called upon to speak directly to business customers, business partners, vendors, and even, sometimes, external customers. IT personnel can no longer be complacent about not understanding the business of their organization. IT personnel must clearly understand how their activities impact the business. When business suffers as a result of IT failures, it puts IT personnel's necks on the line.

The Business Perspective Has Benefits

By operating IT with the best interest of the business in mind, as opposed to the best interest of IT, you will find many benefits:

• Improved customer satisfaction—Your business customers will recognize, and appreciate, that IT is taking a more professional approach to service delivery. You will, in effect, be speaking the same language; more than has typically happened with IT-tobusiness communications.
• Improved productivity—Generally, by using the ITIL V3 framework, in particular the Service Transition processes, you will be putting into effect proven IT best practices that have been shown to reduce costs, create consistent IT delivery, and improve IT productivity throughout the enterprise.
• Improved use of skills and experience—No longer will large numbers of IT personnel be off trying to address IT service changes, problems, and incidents in an ad hoc, unorganized manner. Following repeatable processes builds skills that are strengthened and made more valuable through repeated use.
• Reduced costs—By creating processes that are shared throughout the enterprise and using automated tools to enhance those processes, duplication of effort is eliminated, along with the mistakes and problems that occur when IT services are managed through separate and unconnected silos.

Stretch IT Management Thinking for Service Transition

These new perspectives of IT Service Transition require IT leaders to stretch their thinking and planning, and operate by looking forward instead of always looking back or at the current moment. Table 2.2 provides a look at how IT leaders must start stretching their thinking into the future when making IT decisions.

Table 2.2: Ways in which IT leaders must stretch their thinking.

This change in perspective is supported well by ITIL V3 framework processes. Service Transition supports these changes by emphasizing many important points:

• Highlighting the criticality of implementing an end-to-end integrated life cycle process
• Providing a common frame of reference across silos to successfully integrate IT into business
• Ensuring IT is actually delivering the services businesses expect and need
• Providing change management processes that are consistent, reliable, and repeatable
• Understanding the need for Service Desks and associated Service Desk functions

ITIL V3 supports these new, and necessary to business success, perspectives. IT leaders must measure IT success in terms of business value.

Change Management

What does "change management" mean to IT management? Too often in the past, and still too often in many organizations, it meant business disruption at the mercy of the IT area. By implementing efficient and consistent Change Management processes, IT not only can provide more up time for the business but also improve business. IT management must create and implement Change Management processes that will be of most benefit for their particular organization.

Change Management Automation Lassos Network Cowboys

Back around the mid-1990s, there was a large multinational organization that had many service and product offerings and many business units who were responsible for each of them. Around that time, each business unit was implementing its own Novell file servers and hiring personnel to run those Novell servers. The organization had not yet moved away from its mainframecentric IT focus, and had not seen all the Novell servers infiltrating the organization; they had no procedures or tools in place to reveal this development.

The Novell servers were all connected to the network and were in direct access to the mainframe but physically scattered throughout the enterprise facilities with varying levels of physical security. The mainframe, in contrast, was physically located in a secured room with backup power and cooling. The IT department was focused on just the network architecture, maintenance, and the mainframe, but not Novell server administration and support.

The organization had very strict but justified risk-based policies regarding the connection of the corporate network to any other outside enterprise network. They had procedures the business units were supposed to follow if they felt one of their business partners needed to have access to the corporate network, and they had several feasible options for allowing authorized connections.

One of the Novell administrators, in one of the business units that had many business partners, did not like to be slowed by rules and was always agitated when following the procedures. "I could easily set the connections up myself," he said on more than one occasion.

The IT and Information Security departments referred to the particular Novell administrator as "Cowboy." Upon one occasion, Cowboy submitted a request that information security had to turn down. He wanted to connect one of his business unit's business partners, which also happened to be a competitor of another of the organization's business units, directly to his Novell server, use no firewall, and give the partner 24 × 7 access; all using one ID that would be shared by approximately 24 of the business partner staff. Certainly this was a bad idea from many risk perspectives.

The Information Security department documented reasonable alternatives to connect the business partner and sent it to Cowboy, along with copies to Cowboy's business unit VP, the corporate CIO, and the senior VP to whom Information Security reported. It also outlined the risks involved with Cowboy's requested connection.

Cowboy didn't like it. He complained to his VP. His VP talked with the CIO and the senior VP, and ultimately agreed to one of the proposed alternatives that Information Security had provided. Cowboy fumed. He didn't like it. He said it was unreasonable to make such a valued business partner jump through such hoops.

Fast forward a couple of months. The IT team was seeing unusual activity in one subnet on a recurring basis and bandwidth surges were impacting response times for everyone on the network during these timeframes. Around the same time, Facilities Management was puzzled about damage to some ceiling tiles.

It turns out Cowboy knew that network cables ran in the ceilings above the dropped ceiling panels. Apparently, sometime when no one was around, he had removed the panels above his cubicle and examined the wiring long enough to identify where to patch in a cable, from a modem that was on his desk, to his Novell server. The cable ran up the wall, and was hidden by a tall voluminous fern. Investigation revealed that he'd leave the modem on whenever the business partner needed to send files or access files from his business unit's Novell server. However, no one knew where the business partners actually went on the network when they were connected.

This organization decided that it would be prudent to install automated tools to identify when any changes, physical or logical, were being made, and immediately alert the appropriate IT team. They chose a change management tool that fit their requirements. Soon following implementation of the change management tool, they discovered other, not quite as blatant, attempts at making changes to the networks that would have introduced significant risk to the business. It took them a while to justify purchasing the change management tool, but after it was implemented and being used, they found it to be invaluable and wondered why they had waited so long to get a tool like this.

A Use Case Example

Change Management is about managing risks related to making changes; not actually implementing the changes (that is the responsibility of Release and Deployment Management). Today, it is not uncommon for giant corporations to merge with other giant organizations. Think about the changes that accompany those mergers! Unless you want a big mess of a network, and devastating IT impacts that could make the business leaders wish they never heard the word "merger" or "IT," you need to carefully plan for such a change and address the accompanying challenges.

When two large organizations merge, the IT complexity and problems of each organization will be integrated. A common goal of mergers is to achieve economies of scale, reduce IT costs, and reduce IT complexity for business, ultimately improving the overall experience the business customers then have with IT.

Merging large organizations commonly involves merging resources, facilities, and personnel as well as successfully addressing the challenges created by different IT personnel and operations centers scattered throughout a wide number of geographic areas. How should you tackle this? Start with effective planning.

Service Portfolio Management

Oftentimes, IT planning does not result in successful or efficient IT implementation. Many, and perhaps most, organizations experience deadlines that are missed and keep getting pushed back, significant cost overruns, ongoing miscommunications, one after another priority changes, and, ultimately, unsatisfied stakeholders throughout the enterprise. Establishing effective Service Portfolio Management (SPM) can eradicate many of these problems. Start deciding how to merge the enterprise networks by reviewing the SPM practices within each of the organizations.

Use SPM to assign investments to develop new services, modify existing services, and retire services that will no longer be needed.

So what does each of the organizations have planned for its SPM? To help determine this, take the following high-level steps:

1. Define the Goals for the Service Portfolio (SP)—Work with management teams to identify potential business process projects resulting from the merger. Identify issues for negotiating inventory services; ensure you have considered business cases and validate portfolio information.
2. Get the input for and analyze the SP—Review project lists submitted by business leaders and create a draft of a charter for each project that defines the purpose, deliverable, and approach. Look at the project lists and consolidate to maximize portfolio value, align and set priorities, and balance supply and demand.
3. Approve the SP—Have meetings with the project lead, coordinators, and architects to review the final analysis. Finalize the proposed portfolio, then authorize the services and resources that will be used.
4. Create the SP charter—Create a full charter to communicate decisions, allocate resources, and charter services. Save the full charter; it is a good practice to put it in the tactical planning database if you have one.

Change and Release

Next, work on defining which groups and staff will be required for each of the identified projects within the SP, and reach a consensus on staff dependencies. At a very high level, this will involve:

• Perform a Project Coordinators' Review—Review and evaluate the approach and feasibility, the staff dependencies, and the completeness of the charter.
• Architects' Technical Review—Have the technical subject matter experts (SMEs) look for correspondence with roadmap for the proposed roadmap, make resulting technical decisions, determine the appropriate sequencing, and detail the project dependencies.
• Inspect the CMDB—Search for the groups, applications, and systems upon which the identified projects depend. Identify any potential conflicts or gaps with the involved configuration items (CIs). Update the request for change (RFC), SPM, and CI accordingly.
• Review—Provide direct feedback to the involved managers if their projects are focused on the divisional priorities and how they can improve their charter submissions.
• Create output for the release and deployment—Revise the charters, include consideration for comments and recommendations from management and architects. Create the current baseline of how your networks exist, and define the target baseline of how the business, service, application, technology, and product architectures should look after the release.

Providing the full details of this very important part of the process is beyond the scope of this document. However, as you can probably infer from these steps, you will need to perform Configuration Management activities, utilizing your CMS, updating the CMDB, and creating dependency mapping.

A poorly constructed release and deployment plan will result in a significant amount of extra time that your IT folks will need to spend troubleshooting problems, fighting fires, and understanding the issues related to the complexities of joining two networks. By investing an appropriate amount of time into creating a comprehensive, well-planned release and deployment plan, you will ultimately deploy your changes and more quickly enable effective business use of the involved services.

Don't Forget Your CAB!

The Change Advisory Board (CAB) is another critical component to efficient, successful changes. This group, comprised of representative experts from throughout the enterprise, must be able to ensure that all the changes made throughout the enterprise are made with the best interests and viewpoints of both the business and technology.

Members of the CAB should include, as advised by and paraphrased from the Office of Government Commerce (OGC) ITIL V3 documents:

• Business customers
• Business managers
• User group representatives
• Applications developers and maintenance specialists
• IT specialists and technical consultants
• Representatives from the IT services and operations staff including, but not limited to, the Service Desk, test and quality assurance management, IT Service Continuity Management (ITSCM), information security, privacy, records retention, capacity management, and so on as applicable
• Facilities and office services personnel, such as when physical moves or changes are involved
• Contractors and third-party representatives, as applicable and as involved through outsourcing commitments

The Role of the CAB

The purpose of the CAB is to support changes and their corresponding authorizations in addition to helping Change, Release, and Deployment Management personnel to assess, prioritize, and assign changes. When the CAB needs to meet, it is important that they have access to the information they need to make a good and unbiased decision.

An important piece of information used by the CAB is a change impact analysis. A change impact analysis will provide a "what-if" look at the repercussions of the proposed changes. A change impact analysis will be very valuable in helping to determine, with consideration of a wide range of scenarios, the cumulative impact of multiple changes that occur during a single scoped period of time.

Role of the Service Desk

Historically, the Service Desk responsibilities, commonly called in the dinosaur computer days the "help desk," were given to entry-level IT staff who basically wrote on notepads the problems, questions, requests, and complaints that came into the IT area. They then ran around trying to find someone to address whatever the issue was that prompted the call.

The help desk has since evolved dramatically and is typically made up of experienced staff dedicated to only Service Desk functions to most expediently and centrally address all IT-related calls from throughout the enterprise. Gone are the days of needing to know Joe's and Sue's separate phone numbers if they happen to be stuck with help desk duty for the week or month; now organizations call, email, text, or otherwise contact just one Service Desk area.

Automated tools have been created to capture customer information, and standardized policies and processes were developed to improve the efficiency of the "help desk," a formerly reactive responsibility, into a "service desk," a team of knowledgeable, trained, and coordinated personnel whose job is not only to react and solve IT issues after problems happen but to keep their eyes on the network and business applications to keep problems from happening. ITIL V3 can not only make the Service Desk functions more effective for IT but also provide tremendous value to business.

The most important goal of the Service Desk is to provide maximum and sustained business productivity, which results in optimizing the organization's Service Desk return on investment (ROI).

To reach the goal of providing maximum and sustained business productivity, the Service Desk must be proactive and perform the actions necessary to prevent incidents and problems from occurring in the first place. This goal cannot be reached in most organizations without the use of automation tools.

Values of ITIL V3 Service Desk Processes to Business

There are numerous types of value that a Service Desk running under ITIL V3 processes can bring to a business. Some will be unique to an organization and others will be common throughout many organizations. The following list highlights just a few of the values an ITIL V3 Service Desk can bring to all businesses:

• While handling an incident, the Service Desk can identify additional service or training requirements not only for the IT areas involved in the incident but also within the impacted businesses areas.
• A well-trained and experienced Service Desk will know how to communicate effectively to business areas in many ways, as appropriate to the area with which they are speaking. They will know how to use terms that are easily understood by the business customers without confusing their customers with technical mumbo-jumbo.
• The Service Desk, effectively using ITIL V3 concepts, will ensure everything possible is being done to get normal IT services back to the business, in addition to keeping the services as continuously available as possible.
• Throughout its day-to-day activities, the Service Desk is in the unique position to see where many areas of improvement can be made throughout the enterprise. It truly is in a unique position to see how disparate and otherwise separate applications, network components, and business processes are linked. The Service Desk can take this type of omnipotent view and make quality and improvement linkages—for not only technology but also business processes—that no other area is in a position to make.
• The Service Desk can be a key driver within any organization's Continual Service Improvement Program. The Service Desk is often the area where problems are first noticed and inefficiencies identified. Through the Service Desk's observations, monitoring, and communications, subsequent reviews, analysis, and recommendations can result throughout the entire service life cycle.

As defined by the OGC, "Continual Service Improvement is responsible for managing improvements to IT Service Management Processes and IT Services. The Performance of the IT Service Provider is continually measured and improvements are made to Processes, IT Services and IT Infrastructure in order to increase Efficiency, Effectiveness and Cost Effectiveness."

Management of all the IT assets within the enterprise is the key to ITIL. The central point for coordinating contact between IT and the business units is the Service Desk—an area that often does not get the respect it deserves. However, the Service Desk can be very valuable to the enterprise. Consider just two of the areas where the Service Desk has a major impact: within Change Management and by making constructive use of the change impact analysis.

The Service Desk performs key Change Management functions; they support crucial Service Transition processes, such as receiving and logging requests for changes; and they serve as the focal point for the CAB. In addition, the Service Desk uses the change impact analysis to determine several important considerations:

• Cross-organizational capabilities—The Service Desk can educate contacts from throughout the enterprise about the expected impacts of recent or upcoming changes. They can make sure the appropriate business areas know about service impacts and be prepared for reacting most effectively to them.
• Service dependencies—Possibly the most valuable benefit of Change Management is discovering how changes to shared components will impact the various IT services throughout the enterprise. Interdependencies between IT services are often overlooked in change requests, and the business impact of changes is difficult to determine. As a result, there is poor alignment between the business and IT areas and difficulty controlling costs, quality, and service availability. As the pivotal point within the organization, the Service Desk can use automated tools to map changes and reveal complex dependencies.
• Prioritization—The Service Desk can assess the impact and urgency of each incident and recommend a priority level, along with an appropriate and realistic resolution time and date, and an escalation time and date. Having someone at the Service Desk arbitrarily setting priority, which often happens, is not best practice, and can have negative impact on the business. Instead, the services impacted by an incident or outage, and the associated, predefined Service Level Agreement (SLA) should drive prioritization. This task is made easier, more effective, and more efficient through the use of automated tools.

The Service Desk also supports business-critical processes such as incident and problem management, and is the automation point for associated IT processes.

CMS, CMDB, and Dependency Mapping Tools

A CMDB is critical in today's complex enterprise networks. According to Gartner (Source: "CMDB or Configuration Database; Know the Difference," by Ronni Colville), an effective CMDB must have four critical capabilities: federation, reconciliation, mapping and visualization, and synchronization.

Federation

Very generally, "federation" means taking data from multiple configuration and management sources and repositories and effectively putting them into one logical, virtual CMS in such a way that the most up-to-date values are used, all the information is integrated so that there are no repeats or gaps, and the information is comprehensive. Federation directly brings in multiple data sources by linking to different sources.

However, it is important to note that this federated data does not usually reside in a single repository. Federation combines assorted and diverse CMDBs and related data repositories, providing an accurate, single view, but not necessarily single location, of data for all IT processes from which to work.

There is a long-standing and often-criticized aspect of a CMDB: many skeptics proclaim that creating a monolithic CMDB is too large of an undertaking. Indeed, the CMDB of ITIL v2 was often interpreted as a single, massive repository, while the ITIL V3 CMS relies more on federating data from multiple sources.

Ideally, federation should provide a context for the user and application. Yes, establishing federation can be a large undertaking, and the larger and more complex the enterprise, the larger and more complex the task of effectively creating a CMS. For this reason, automation tools should be used to tackle and resolve this challenge as well as facilitate the federation process.

Reconciliation

Reconciliation will ensure data is coalesced to avoid having duplicates as well as to enable matching CIs from different sources. The CMDB is the repository that provides a single source of CI data for enterprise IT services and processes to use. It is a very good idea to use automated discovery tools to keep the CMDB updated. However, when using the automated tools, you cannot simply run them to update the CMDB and assume that everything will be correct. You must ensure an appropriate level of logic is applied, and know how the tools capture the CI data and store it within the CMDB. It is also very important that you understand how conflicts between the CMDB and incoming data are accurately resolved.

A few years ago, I worked with a very large multi-national organization that had more than 20 service and product business units throughout their enterprise. They had established a separate external customer marketing opt-out database within each of the business units. Throughout the day, as each business unit would receive an opt-out request from their external services and products customer, they would update their business opt-out database. As communicated to the customers, these opt-out requests were supposed to apply to all the organization's products and services. Each night, an automated process ran to take each of the databases, in the same order every night, and update the central master customer opt-out database. Sounds like a good idea, right? Wrong.

A significant portion of the organization's external customers purchased services and products from multiple business units. When customers from Business Unit A called to request an opt-out from further marketing, the opt-out request was entered into the Business Unit A opt-out database. When the nightly process ran, it started running the opt-out requests in order, starting from Business Unit A. Thus, those customer opt-out requests were updated to the master opt-out database. But guess what? The customers for Business Unit A, who were also customers of Business Units B through Z, still had their marketing choice flagged as opt-in. So when the central opt-out database was updated with the opt-out databases from those units, the customers' opt-out requests made to Business Unit A were basically wiped out. There was no logic in place to see when customers made their opt-out requests or to determine within which of the other business units they were also customers. Oops.

As a result, a significantly large number of customers, frustrated that they kept getting postal and email marketing materials even though they had made multiple opt-out requests following the procedures the organization provided, complained. And they complained loudly. Right up to the CEO. The situation made the news, and the organization lost many customers and was very embarrassed to appear to be so incompetent when they were promoted as being a leading-edge technology company. If they had established a reconciliation process to make sure that data updates were not overwritten by old data, they could have avoided this significant business problem of customer loss and bad publicity.

Reconciliation helps to ensure that the CMDB values are updated appropriately; also helping to ensure the data within the CMDB is good and accurate data. Reconciliation is not a separate function from managing a CMDB; it is simply a key requirement for making the CMDB implementation and enterprise use successful, ultimately bringing value to the business. Figure 2.1 shows how these reconciliation decisions are made following typical business logic.

Figure 2.1: Using business logic to make reconciliation decisions.

Mapping and Visualization

Significant numbers of IT leaders do not believe they really need a CMDB, based upon their enterprise characteristics, which are typically based on the size of their enterprise. Common situations that involve such beliefs include:

• The IT leaders have a comprehensive list of the applications used within the infrastructure
• There are comparatively few, such as less than six or seven, configuration data sources within the enterprise
• They have documented all the business impacts of changes to each of the components of their enterprise infrastructure and applications
• They have comprehensively tracked how many of the infrastructure and applications changes were unplanned
• They have documented all their business services well enough so that, in the event of an outage, they can identify the likely causes
• There is a low rate of change within the enterprise, and the related information can be realistically and easily managed manually

If all these characteristics apply to your organization, perhaps you are managing your infrastructure resources successfully on your own and you do not need a CMDB! Or perhaps you already are maintaining a CMDB, of sorts, using a Word, Excel, or other type of document. However, most IT enterprise networks of all sizes can benefit from a mapping and visualization tool to see how all the types of data found within a CMDB relate. Even in the otherwiseseemingly simple enterprise networks, there is inherent complexity that, if not visually represented, makes it very difficult for IT leaders to keep track of all the business-critical network components and applications.

For example, with mapping and visualization, you can determine whether the best network path is being used and where there are network bottlenecks. When network maps and visualization is not used, network administrators typically determine the data flow path by doing a number of repetitive activities:

• Pinging each node within the anticipated path
• Re-verifying the traceroute each time the path is traversed
• Doing telnets to intermediate nodes
• Going back to pinging and starting the process over again

This process can be very time consuming, and the number of times these steps are repeated could go on for what seems to be infinity to the IT personnel, as Figure 2.2 illustrates!

Figure 2.2: Classic way of determining data paths

An effective mapping and visualization tool will show you, all on one screen, the data path along with significant diagnostics along the way, such as the latency between each hop. Figure 2.3 shows how such a map may look.

Figure 2.3: Data path created with an automated tool (Source: HP).

So what used to take the administrators a day or more to do their pinging and tracing can now take perhaps less than an hour to get the same information. This time savings relates to business value by making business processing quicker and more dependable with less downtime.

In a 2002 survey of 450 Fortune 1000 companies, Find/SVP found that the average hourly downtime cost is $82,500. Here is the breakdown by industry of the amount of money lost for each hour of business processing downtime:

• Manufacturing—Approaching $400,000 of loss per hour
• Telecommunications and Internet—A little more than $300,000 of loss per hour
• Banking—Close to $250,000 per hour
• Transportation—Just over $150,000 per hour
• Retail—Approaching $150,000 per hour
• Insurance—Losing right at $125,000 per hour

It is very likely that these costs are notably higher now, 6 years later. And besides, which of your business customers want to sit and twiddle their thumbs while waiting for their business application to finish processing?

Synchronization

Synchronization, through the use of reconciliation, will ensure accuracy across integrated systems. Within ITIL V3, the CMDB documents the way the CIs are supposed to be configured, not necessarily the way they are actually configured, which automated enterprise discovery tools can reveal to you. The automated detection of actual state compared with desired state is one of the value propositions for good discovery. Being able to associate unplanned infrastructure changes with the services the infrastructure support is critical for driving stable and resilient services. Change controls must be in place to synchronize or to ensure any changes to the monitored CIs are approved and updated within the CMDB.

Synchronization typically is associated with the replication of data from one source to another, as within a monolithic CMDB. This is not an ideal practice for many reasons including duplication of data, storage, and network bandwidth implications. Rather than using replication for synchronization, companies are moving to federated solutions that do not require physically copying the data. Using these new synchronization methods, that are actually reconciling information, supports effective change impact analysis, which will prevent unexpected downtime. Root cause analysis can be used to enable rapid incident and problem resolution.

Using the ITIL V3 synchronization through reconciliation provides a consistent way in which the actual environment can be compared with the target environment, allows IT personnel to more easily determine unplanned changes, and very importantly, creates audit trails that can be used for compliance activities. Synchronization also helps to support IT initiatives that meet the organization's strategic business goals.

CMDBs Help Reveal the Big Picture for Enterprise Components

Gartner research has also revealed that the most frequent driver for organizations to use CMDBs is to have a better, more comprehensive understanding of how the enterprise infrastructure components relate to each other, and use this information to make better decisions during change impact assessment problem isolation to ultimately improve the business (Source: "Conference Poll on CMDBs Shows Some Progress"). A valuable CMDB will be one that is business services-centric. It will maintain a comprehensive and current record of all CIs and relationships from multiple sources, in addition to providing services to make the CMDB information as valuable as possible to the business. This value is increased through using automated CMBD tools.

To put it another way, a CMDB is a view of all the IT services and the associated enterprise infrastructure interdependencies. This includes configuration information within the network devices as well as the systems and applications. It also includes information for the logical associations for IT services and infrastructure components, including such things as customers, operational owners, suppliers, outsourced services, and so on. In a nutshell, a CMDB is like a view of a system of sources along with the policing and associated technologies by which they are governed that result in a comprehensive view of the enterprise IT services. Remember, ITIL V3 is all about IT adding value to the business, so the CMDB must be business services-centric to be most effective.

A business services-centric CMBD will have the following capabilities; use this list as a checklist when you are comparing vendors:

• Host Discovery—The CMDB should provide accurate and current information that can be enhanced with automated discoveries
• Base Federation and Reconciliation—The CMDB should provide support across Service Transition activities and improve data quality throughout the enterprise as well as allow for enterprise federation with third parties
• Mapping and Visualization—The CMDB should contain information that can be used to provide accurate service views and maps to help break down silos and better integrate IT with business
• Configuration Change Tracking—The CMDB should provide the data to improve the mean time to repair (MTTR) and enforce standards
• Access Control—The CMDB should provide the right information to the right people, and keep unauthorized individuals from accessing data for which they have no business need
• Application Mapping—The CMDB should have the data necessary to allow for automated, comprehensive application and service discovery
• Impact Analysis—The CMDB data will allow for automated tools to proactively analyze impact of changes on business services
• Reporting—The CMDB data can provide the data that will allow for analysis resulting in actionable, valuable business information
• Management Capabilities—The CMDB data will help to improve operational flexibility and reduce costs

The CMDB Federation (CMDBf) working group drafted an industry-wide specification for sharing information between CMDBs and other management data repositories (MDRs), such as asset management systems and Service Desks. Learn more about it at http://www.cmdbf.org/.

The Need for a CMS

As organizations become more complex, the CMDB will become exponentially complex, often to the point of becoming unwieldy. To help address this possibility, make IT personnel happier, and achieve good results for the business, organizations should consider using a CMS.

The OGC's official ITIL V3 books define a CMS as, "A set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also include information about incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, Locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes."

To gain effective results and avoid a lot of pain and frustration, it will be very important for you to create a thoughtful, thorough plan through coordination with all your key players.

The Need for Dependency Mapping Tools

Implementing configuration management processes is a big step forward in helping your established enterprise systems and applications communicate with each other, subsequently improving the value of IT in the eyes of business customers by increasing uptime and productivity. To be truly effective, the CMS and CMDB need to be integrated with Change Management and Release Management processes. Effectively using the CMS, CMDB, and dependency mapping tools will improve the understanding of service and application dependencies when doing change impact analysis.

Values of ITIL V3 Release and Deployment Tools to Business

There are numerous types of value that Release and Deployment tools running under ITIL V3 processes can bring to a business. Some will be unique to your organization and others will be common throughout many organizations.

The following list highlights just a few of the values ITIL V3 release and deployment tools can bring to all businesses:

• Efficiency—IT Services changes can be made more quickly and more efficiently with the least cost and reduced risks by using release and deployment tools. The automation of key activities based upon automated triggers makes change management much more efficient and timely than depending upon individuals to notice when events need to be performed, and possibly overlooking significant issues. Plus, significant cost savings to the business is always good!
• Consistency—Using automated tools can provide consistent IT Service implementations throughout the enterprise, which improves business. When release and deployment is poorly executed, or performed ad hoc, IT folks will spend a lot more time troubleshooting problems and trying to manage the accompanying complexity involved with performing an implementation without a proven, automated plan.
• Predictability—The release and deployment of IT Services changes can be made more predictable through the use of release and deployment tools. What if you ran a restaurant and used no recipes for the changing items on your menu? The results would be unpredictable, and your customers would likely want to avoid coming to your restaurant because they would never know what they would be getting from one visit to the next. ITIL V3 provides, in effect, the recipe for successfully and consistently making changes in a way that is repeatable from one change to the next. Business areas will then view the IT area as having predictable outcomes to changes each time they occur, instead of worrying how any announced change will impact their ability to actually perform their business processes.
• Reliability—The release and deployment of IT Services changes will be more reliable using ITIL V3 processes along with release and deployment tools: more reliable reactions to release and deployment events and more reliable outcomes from change releases and deployments. Release and deployment will be more reliable as a result of having these activities performed without interruption, and will deliver the outputs required by the business.
• Accountability—The individuals involved with the release and deployment of IT Services changes will be held accountable through the use of automated tools that log who has done specific activities related to the changes. There will be no easy way to point the finger at others for actions that did, or did not, occur as revealed by the logs generated through the release and deployment tools.
• Successful workflow hand-offs—The hand-offs that occur throughout what are increasingly complex series of activities will be more likely to successfully take place through automated release and deployment tools. Such tools will automatically trigger hand-offs and human error will be lessened.
• Better coordination and scheduling—Considering the increasing complexity of networks and applications, it is no wonder that necessary release and deployment activities slip through the cracks when you depend upon individuals to maintain a hand-writing to-do list to accomplish the change tasks. Automated tools can ensure that all activities are appropriately coordinated and scheduled, and can automatically identify any scheduling or coordination conflicts.
• Compliance and governance—Your business leaders and compliance areas will be happy to know that there are significant compliance and governance values for automated release and deployment tools. Automation tools provide the ability to do such things as automatically verify and report on the changes that have taken place, along with who made the changes, when the changes occurred, and why the changes were made. This automation provides a consistent, reliable process to generate audit trails and logs that are crucial for a wide range of compliance requirements, in addition to limiting business risk.

Effective, proven ITIL V3 release and deployment tools can provide comprehensive automation to enable automated management of not only change release and deployment processes but also all technology processes across the entire business service life cycle. These tools enable you to connect different systems, tools, and groups that support a business service around key use cases in the Service Desk, for not only Change Management but also Incident Management, Problem Management, and all the other Service Desk responsibilities.

Complemented By, and Complementary, Professional Services

External IT service providers as well as internal IT departments no longer provide strictly technological services. Instead, most of them act increasingly as professional service providers for IT users and business customers. These IT users and customers demand functionality along with a minimum level of quality that supports their activities within business processes and improves their productivity.

Service Transition processes can be complemented by professional services in ways that help business customers to realize their expectations for IT Services. In addition, Service Transition can be used to complement and improve these professional services.

Consider SaaS, which is a variation of outsourcing. SaaS is often viewed within large organizations as a disruptive delivery model that challenges traditional enterprise IT management and associated services. There are certainly some challenges. Some SaaS solutions remove some of the control of mission-critical IT processes from the internal IT group. There are also concerns about the reliability and availability of SaaS solutions that are mission critical to the business. Information security is another concern. How can SaaS vendors be trusted to appropriately safeguard the information with which your organization has entrusted them? And how is the SaaS vendor protecting the privacy of any personally identifiable information (PII) to which they now have access? And then there is the integration issue. How can you ensure the SaaS systems will seamlessly integrate with your systems?

ITIL V3 Can Complement SaaS Professional Services

Large, geographically distributed organizations have different requirements for Service Desk management solutions than smaller enterprises. Different types of Service Desk management SaaS services will be needed by each. Likewise, a large, highly technology-diverse organization with many mission-critical business services will have different needs for Service Desk tools and corresponding SaaS services than will smaller organizations with one or a few business services.

IT leaders can use the change impact analysis processes within ITIL V3 to map and visualize potential SaaS solutions for the Service Desk and their business impacts. The change impact analysis, properly done, should reveal the ways in which SaaS services can handle problem, change, and configuration management within large organizations and determine whether smaller organizations will be able to obtain the one-stop asset, service, and systems management SaaS solution that they often need.

SaaS Professional Services Can Complement ITIL V3 Processes

Organizations that do not have well-integrated Service Desk and Change Management processes can benefit from SaaS services that provide mature, full-featured capabilities for Incident, Problem, Change, and Configuration Management. By using SaaS solutions, organizations can reap the benefits of being able to perform complex application mapping and service-level management without stressing their own systems and networks. SaaS services can also provide relief related to the complexity of the required workflows with Service Desk and Change Management processes specifically, and within all other ITIL v3 processes in general.

Managing enterprise changes to the information processing infrastructure is compounded by size, complexity, business impact, and new regulatory requirements. SaaS services can be used to model workflows and offer the tools to provide the appropriate approval and change controls. SaaS solutions can allow organizations with limited resources access to industrial-strength processes and workflow management tools that allow secure, auditable, and controlled processes.

Lower Costs

Using ITIL V3 Service Desk and Change Management processes and utilizing professional services such as SaaS solutions, an organization can both prevent errors and problems and fix them much earlier in the business systems life cycle.

Figure 2.4: How it costs more to fix errors and problems.

As illustrated within Figure 2.4, the longer an organization waits to correct errors and problems, the more it will cost as the errors and problems move from stage to stage within the IT Services life cycle. Most organizations will realize that the resources invested in ITIL V3 processes and solutions will be much less expensive than discovering and fixing problems and errors after systems and applications have gone into production operation.

Looking Ahead

Service Transition offers a new approach to Change Management and Service Desk operation; Service Transition recognizes Change Management and Service Desk functions are much more complex than they ever have been. What may have always worked in the past will likely not acceptably work for business in the present. Services need to be tested and deployed in a controlled manner to mitigate risk, assure quality, and make the IT department more agile and responsive, resulting in more business benefits and happier business customers.

With effective Service Transition, Change Management, and the Service Desk processes in place, you will be able to integrate IT into the enterprise business fabric, resulting in better and more productive, efficient, and successful business. Too good to be true? In the next chapter, I will point out some of the specific ways in which business is improved and made more valuable through implementing ITIL V3 Service Operations and Business Service Management processes.

---