While it is easy to auto-discover assets on a network and capture their related attributes, it is important to realize where the value is in the data. The IT Service Asset and Configuration Management (ITSACM) process as outlined in IT service management best practices asks what level of component data needs to be managed in order to more effectively facilitate and inform Incident, Release, Change and Problem Management in the business environment. The ITIL framework provides the guidelines for organizations that want to define their service management processes, but it does not provide the processes themselves. ITIL also does not take into account tool-specific capabilities that can be used to increase process efficiency.

Creating the process to define the importance of the information stored in the configuration management database (CMDB) as part of a configuration management system (CMS) adds value to the overall service knowledge management system. The CMDB should support effective and efficient service management processes by providing accurate configuration information to enable people to make accurate decisions. For example, is it appropriate to authorize a change during business hours on a particular system? The combination of the CMDB and Service Catalog would allow a Change Advisory Board (CAB) to determine if this is an appropriate action to take, assuming it is a non-emergency change.

Remember—a configuration item (CI) is any component that needs to be managed in order to deliver a service. CIs are tracked and controlled in the CMS. CIs are also more than just PCs, laptops, switches, and routers. CIs can also include (but are not limited to):

Most of us have stories where there has been a catastrophic breakdown in communication because the service maintenance processes were not clearly defined. It is important to involve internal stakeholders and external partners to help organizations achieve defined goals, improve processes, and align with the ITIL framework. At the end of the day, it is important that the entire organization focuses together to ensure that the effort involved in building a CMDB will drive efficiency and effectiveness in achieving established goals and will deliver value to the bottom line of the business.

I recently was working with one of our longtime customers. They wanted to use Service Desk Express for their facilities group. They needed a solution that would allow them to track repairs, work requests, and assets. As I was talking to the manager of the group he said, “We want to treat this project as if we were constructing a new building.” I must admit, at first I was a little puzzled, but I quickly grew fond of the analogy. Many times organizations want to buy a Service Management application and tell the vendor all the things they want over the course of a few conference calls. Then they expect the product to be implemented in a week or two according to how they imagine it should work. If a construction company were to take this approach, I think we would all agree this would be pretty scary; what would the structure look like and how functional would it truly be? How would a “Service Management” project turn out if it were handled like the construction of a new building? The next few paragraphs give an idea of what this might look like.

The Design Process

We would not expect any builder to start construction without a good set of plans, right? A functional and efficient structure starts with a good plan. Likewise, shouldn’t we expect to have a good Service Management implementation only if we have well-defined and documented processes? The only way to get those plans is to meet with an architect so that they understand the purpose, style, and size of the structure. Usually this is obtained through a series of meetings with the customer. This approach should also be applied when implementing Service Management. It is not enough to have an internal meeting to determine these needs. Internal meetings are necessary for everyone to agree on what is needed. The requirements still have to be clearly communicated to the consulting firm that is going to help the organization implement the Service Management application. During these meetings, the customer organization can leverage the experience of the consulting firm. After all, firms like RightStar have implemented Remedy and SDE for hundreds of customers. We can share insights into the things that have worked and, probably more importantly, the things that did not work so well. In short, learn from the success and failure of other customers. This is one of the themes of the final ITIL IT Service Management framework phase, Continual Service Improvement.

Have a Good Set of Plans

The next logical step in the building process is to develop the plans and refine the design. The same would apply to the service management implementation. After gathering the requirements, the consulting firm should be able to develop a Scope of Work to define the breakdown of work that will happen during the implementation. This should also outline the customer organization’s responsibilities as well. Remember that involvement in this process is critical. The customer should be sure to review the Scope of Work, ask questions, and request more detail. These documents, like a blueprint, are in place to make sure everyone is on the same page.

Groundbreaking Ceremony

Now that everyone knows what the building is going to be used for (also referred to as its utility) and how it is going to look, construction can start. At this point the organization needs to make sure all the key players are in place and that the right data is available. This is where project management is critical, typically for both parties involved. Most customers think that because their project is small, project management is not needed. I would argue that some coordination is needed for any size project. This is also a time when someone within the organization should work side-by-side with the consulting firm. This is really where organizations begin to take ownership of not only the product, but the processes that are employed. The organization should now have a vested interest in the project, and committing a resource to receive maximum transfer of knowledge from the working consultant is key.

Grand Opening

The structure is now built and we are ready to hand over the keys. At this point the organization is ready to use the new Service Management system and now needs to manage and maintain it. Unless processes or needs change dramatically, maintenance is usually minimal. We all know that change does happen and improvements should be continual, so you need to be prepared. There is a saying that many vendors have: “A trained customer is a happy customer.” It may be a cliché, but it’s still true. So the organization should ensure that their system administrators and support staff are trained to properly maintain and use the system. It is recommended to employ the “train-the-trainer” concept for some of this training. This will verify depth of understanding on behalf of the internal trainers and will also utilize consultants’ time most effectively.

One of the most important things organizations can do during this transition is to prepare staff for the cultural change. This really should start early. Staff members need to understand the change was made to drive better service to customers and to drive efficiency within the support organization. Upper management needs to be active in this exercise and committed to the plan.

In closing, some might question the aims of a consulting firm advocating for more time to be spent on planning and assessment activities. However, I believe that, “If it is worth doing, do it right!” When organizations spend a little time up front to create and document a plan, the result is a better solution with a solid foundation.

Recently there has been a hot debate, an ITIL forum thread of approximately 150 posts, over whether a Major Incident should automatically be classified as a Problem. It seemed that the voices advocating the creation of a Problem record for every Major Incident were more assertive and enthusiastic, to put it nicely. I’m sure my RightStar colleagues would often find me guilty of getting lost in the weeds of ITIL theory, but for this issue, I believe I’m more apt to consider what happens in real life for our organization and for our customers. I’ll share with you here some of my own thoughts and conclusions.

First we’ll look at textbook ITIL definitions. Many organizations and IT managers are still sorting out the difference between Incidents and Problems. The example I typically give is that of a user calling about a network printer issue. The user is unable to print to the network printer. What should the Service Desk analyst do? Well, since the Service Desk analyst is supposed to be responsible for Incident Management, by definition the analyst should be focused on restoring the service (in this case, printing) as quickly as possible. The analyst should follow standard troubleshooting procedures within predefined timelines. But if he or she is unable to resolve the Incident, the user’s system may need to be routed to an alternate printer. When the Service Desk analyst confirms that the user can print to the alternate printer successfully, the Incident record can be closed. An Incident is then simply defined as a disruption to normal service.

But of course the printer is still broken. This is where Problem Management steps in. The Service Desk analyst should create and link a Problem record for the printer issue to the Incident record and assign the Problem to the appropriate manager or group. The Problem Management process will be engaged to determine the root cause, develop or document workarounds (such as routing to an alternate printer) and ultimately provide a fix, whether it be to clear a printer jam or send the printer in for warranty repair. A Problem is defined as the cause of one or more Incidents, and the Problem Management process assumes that the cause of the Problem is not known when the Problem record is created.

Getting back to the debate and how that relates to real life for most of the organizations we’ve worked with—after reading some of the posts in the forum, I thought of an example of a Major Incident that doesn’t fit the criteria or definition of a Problem. What about a power outage? For smaller organizations especially, it’s not practical to have a fully redundant collocated data center for all of their services. And even if the data center is not impacted, there may be remote sites that need assistance with computer-related issues because the communication to headquarters or their own computing capabilities are compromised.

In this scenario, the power outage is the cause of one or more Incidents or disruptions to service. But we cannot assume that the cause of the Problem is not known. There was a storm, the lights are out and we should know why the computer won’t turn on. No root cause analysis is necessary. And the organization doesn’t have the influence to negotiate with the power company or with the weather if that was the cause of the outage. I would therefore argue that this situation would warrant the creation of a Major Incident, which is defined as an Incident that results in significant disruption to the organization. But it does not require the creation of a Problem record or the engagement of the Problem Management process. As long as alternate manual procedures are standardized and followed, the relevant information for handling the outage should reside within the Incident Management process.

It makes sense for the Major Incident record to be linked to the other Incident records so that IT can measure the impact of the outage. We would also like a mechanism that will allow us to share the information with the support staff and other customers as necessary. For users of BMC Service Desk Express, what should come to mind is the White Board notices module. This module, under the heading of “Crisis Management,” has many advantages. First of all, the sharing of information is facilitated by the scrolling White Board Ticker marquee. Individual records can be segmented to limit the display to a specific group or to include the display for the Self Service interface. Secondly, subsequent Incidents that are linked to a White Board notice can be automatically populated and updated with information from the White Board notice. Finally, when a White Board notice is closed, all related Incidents can automatically be closed with it, and a business rule will fire to send email notifications to affected users. I would even recommend renaming the “White Board” module the “Major Incident” module.

As always, ITIL is not a framework to be swallowed whole. It was developed to provide guidance for IT service management best practices and to be adapted to each organization’s needs. I expect that we’ll continue to debate the intentions of the ITIL authors. Ultimately, our goal is to provide better service and to deliver solutions that make sense.