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?"
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.
Emphasizes IT alignment with business
Emphasizes the integration of IT with business
Emphasizes the use of linear service catalogs
Emphasizes the use of dynamic service portfolios
Emphasizes value chain management
Emphasizes the value of network integration
Emphasizes a collection of processes that need to be integrated
Emphasizes a holistic service management life cycle that correlates closely with business life cycles
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:
All these activities are supported by a Configuration Management Database (CMDB) and Configuration Management System (CMS).
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:
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:
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.
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.
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.
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:
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.
Today IT Leaders Are...
IT Leaders Need to Be…
Focused on technology
Focusing on customer goals and outcomes
In firefighting mode
Becoming demand driven to prevent fires
Arranged within organizational silos
Integrating enterprise services and processes
Costing businesses unknown amounts of resources and money
Providing financial transparency for the IT services provided
Driven by technical metrics
Being driven by metrics that clearly reveal business value
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:
ITIL V3 supports these new, and necessary to business success, perspectives. IT leaders must measure IT success in terms of business value.
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.
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.
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.
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:
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:
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.
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:
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.
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.
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:
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:
The Service Desk also supports business-critical processes such as incident and problem management, and is the automation point for associated IT processes.
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.
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 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.
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:
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:
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:
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, 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.
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:
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/.
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.
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.
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:
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.
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?
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.
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.
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.
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.