Categorized | Media

Which Comes First: Process or Tool?

…or another way of saying this is: “A fool with a tool is still a fool!*”

As a consultant, a large portion of my job consists of developing and documenting business requirements for tool implementations and upgrades. The result is that I have a lot of opportunity to see the way some of the legacy tools have forged processes at client sites. This is neither good nor bad on the surface, as every organization needs to find a mechanism for integrating their tools into existing processes, but changing tools offers an incredible opportunity to realign processes where they have strayed from best practice or not kept pace with the positive changes in the ITSM frameworks.

An Opportunity for Improvement

Thus, if you’re in the process of upgrading or implementing a new tool it’s a great time to look back at your processes for a little Continual Service Improvement (CSI). Here are some areas to consider, based on some of what I’ve seen:

  • Incident vs. Request Management: If you’re growing from a smaller or older tool, your current tool may not distinguish between Incident Management and Request Management, dumping all customer interactions into a single Incident module. The most common work around for this is either using the category to differentiate or assigning a low priority to all requests (for example, Incidents might use priority 1-3 and requests use priority 4-5).
  • Implementing work flows and quality gates for Problem Management: many older tools treat Problems much like an incident, through a manual process that enables an organization to track problems and assign tasks related to working them. Newer tools enable the ability to add work flows that support a repetitive Problem Management Process.
  • Change Management without a CMDB: given the challenges of building and maintaining a CMDB in older tools, many organizations skip this critical portion of their implementation. The result is a Change process without sufficient tools for assessing risk or maintaining a CMDB when one is built.
  • Asset Management: Many organizations don’t take the CMDB down to devices at the user level (for example desktops, tablets etc.). While this is a good place to start, good Asset Management and tracking CI’s at this level add quite a bit to the Problem Management process. There is also a lot of money to be saved with a good asset management practice.
  • No Employee Self-service: This one is an implementation in its own right, but if you’re moving off a tool with poor or no self-service into almost any of the tools available today, implementing a self-service catalog is a critical part of your implementation.

Leveraging CSI to help you get there

These are the top ones and I’d like to take a little more time to dive more deeply into things an organization might consider when transitioning tools. Before I start however, let’s looks at how you can leverage aspects of CSI to accomplish the task.

1. For each of the processes you’re putting under the microscope, consider how the process supports the organization’s mission and vision and document your goals and objectives for that process.
2. Next, pull out the original ITIL process or process documentation from another ITSM framework and compare your process against the framework you’re utilizing to see how much the current process has strayed.
3. Conduct a SWOT analysis, looking at the strengths, weaknesses, opportunities and threats in your current process.
4. Use the inputs from the first three steps to assess your current process and document improvement opportunities, prioritizing those opportunities.
5. Document the improvements that relate to the tool along with business requirements for implementing your desired process in the new tool. Include metrics you’ll need to produce with the tool to measure process effectiveness as you continue your journey.
6. Document an improvement program for the remaining items you’d like to address outside of the tool implementation.

Look hard at your processes

To get you started, I’d also like to dive a little more deeply into the processes mentioned above and offer a few pointers:

Incident and Request Management
These are two distinct processes, with distinct process flows and something is lost when they are merged into a single module. Thus, if you are coming off of a tool with only one module for both of these processes, it’s important to re-evaluate both of them. One thing to watch out for is the impact of merging two processes into one within the tool. Has it watered down Incident Management or slowed down the fulfillment of Requests by using the same linear process for both? Are you able to manage and report on both distinctly to understand where improvements can be made? Is the Service Desk overly involved in processing requests, impacting their ability to manage incidents properly? How are Service Level Agreements addressed? A few additional considerations to think about:

  • Review/streamline your category stack: Make certain you’re not using categories to represent Configuration Items (CI’s) or Services, cut it down to two levels with no more than 10 categories and no more than 5-10 items within each.
  • Re-design resolution codes to provide good trending information for Problem Management.
  • Review Service Level Management and Major Incident handling processes and use the tool to help manage the resulting escalations and notifications.

Looking at Request Management, the goal here is to get requests to the fulfillment teams as quickly as possible with as little Service Desk intervention as possible and to ensure they are appropriately approved. Removing them to their own module will provide the ability to measure fulfillment times and know what to focus on but there are several aspects to Request Management that should be reviewed, documented and made repeatable:

  • How are approvals being managed today?
  • What are the fulfillment steps or work flows used to fulfill the most common requests?
  • What are the fulfillment timescales?

Problem Management
There is a distinct work flow to Problem Management and tools that enable work flows can be leveraged to ensure it is followed. Even a tool without work flow capabilities for Problem Management can use status codes to help drive this work flow. Consider these distinct phases of a problem when configuring the module:

  • Investigation and Root Cause Analysis
  • Resolution Planning and Approval
  • Resolution Implementation
  • Verification

Breaking the process down into at least these phases enables your organization to know where each problem is in this process and later, as you mature you can add timescales to exit each, along with quality checkpoints to move to the next phase.

This may not be applicable for all organizations. If you are just implementing Problem Management, a simple out of box tracking program is sufficient, but as you mature breaking the process down into logical components will help with its continual improvement and effectiveness.

Change Management with a CMDB and tool work flows:
First consideration if you have now added a CMDB to your product is to review how risk assessments are being performed today and add the ability to check for related changes that could impact a proposed change. For example, is someone planning network maintenance on the segment of the network to which the servers getting patched belong? Your Change Management process will need some policies around this. For example, if there is more than one change to a single CI, are they grouped together or done one at a time? If there are collisions across the infrastructure, how will the scheduling issues be resolved (for example, does one infrastructure component get prioritized higher than the other, do Service-related changes trump all infrastructure?). If this is not handled through process, it will become an issue during meetings to address these issues and can lead to conflicts.

The other major consideration is the interface between Change and CMDB maintenance. Now that there is a CMDB, it’s important to flag changes that impact both the CMDB data and knowledge articles concerning the affected CI. Both may need to be updated. Similarly, if discovery is used and finds a new CI that was not added through a change, how would you like to handle it: Incident or Unauthorized Change?

In addition to these items, this is a great time to double-check the overall Change process and how well it’s working, looking for gaps you can plug with the new tool. With tools that include work flows, you can have different work flows for Emergency, Urgent, Standard and Normal Changes, gaining the ability to leverage the power of change models. Don’t overlook the impact of adding non-production environments like development and testing to your CMDB, which might cause changes to the scope for your Change Management process. Change Management is an area that benefits tremendously from new tools and you’ll want to take advantage of the automation capabilities they present.

Asset Management:
If you’re not already leveraging Asset Management and joining it with CMDB processes, you’ve got two large areas you can leverage:

  • Improved expense control: understanding where hardware is and being able to properly retire leases and dispose of physical assets is an important cost-reduction capability gained through Asset Management, but often it’s the software licensing arena¬† that benefits the most in terms of controlling expenses. Coupled with a good off-boarding process, managing the “inventory” of licenses can save the organization a significant amount of money over time. To benefit from these costs savings, you’ll need to develop processes to manage assets, from purchase through retirement and document all of the other process touch-points (Request Management in particular) that need to be considered.
  • Many organizations represent end-user devices generically in the CMDB, but when your organization is mature enough to manage assets, you gain the ability to begin tracking software levels (OS and patching) and end-user device models when they are impacted by an Incident or Change. This can actually increase the benefit of Problem Management, when the organization is mature enough to manage problems to this level. In one of the organizations I supported, we identified a conflict between the Citrix environment and a particular version of MS Office and a run of bad hard drives by collecting the information after we began to think we had a problem. If we had this level of data in our CMDB we would have caught the issues more quickly and been able to diagnose root cause in days not weeks.

Employee Self-Service:
Adding employee self service will require a serious look at how requests are fulfilled as well as incident and change management processes. There are huge opportunities here, so next month I’ll tackle these via a full blog on this topic.

Never stop looking – there is always room for improvement

If there’s one take-away from this month’s blog, I hope it’s that you realize that a tool upgrade or replacement is a great opportunity to re-assess your processes and see if they’re still working well or whether improvements are possible. This isn’t the only time you should re-assess your current way of doing business. Periodic assessments are important to continuing to grow and mature your processes, to keep them alive and responsive to business needs. If it’s been more than a year since you’ve taken a step back and reviewed your current processes, now is a great time to get started!

*Thanks Paul Wilkinson and  Jan Schlit for the wonderful ABC of ICT card on this one!

About Phyllis Drucker

Phyllis Drucker is a business process consultant at Linium. ITIL expert certified with over 20 years' experience in the disciplines and frameworks of IT Service Management as both a practitioner and consultant, she has also served the itSMF since 2004 in a variety of capacities including volunteer, board member and operations director of the US Chapter. She is a frequent contributor of knowledge to the ITSM profession, through numerous presentations, whitepapers and articles. Since 1997, her goal has been to advance the profession of ITSM leaders and practitioners worldwide by providing insight from her experiences on a wide variety of Service Management topics.

3 Responses to “Which Comes First: Process or Tool?”

  1. Why on earth would one be changing or upgrading tools if not to improve practices? And wby would you improve practices if not to meet a business outcome?
    Maybe I misread this but it seems backwards to me. Putting a tool in or working on processes without a specific business goal in mind speaks of an out-of-control inside-out organisation with deeper issues than how good their asset data is.

  2. Jan Vromant says:

    Phyllis, rock-solid article! You hit the nail on the head with the areas where the present generation of tools indeed provides the most business value. What I have seen is that -in addition to the focus on the processes you describe- there is also a major need with clients to have “one source of truth” or an ERP for their IT, where they can tie all the data together. Also, clients like the idea that the IT tools nowadays can be used to support non-traditional areas such as Facilities Management and even Legal or HR.
    As far as IT Skeptic’s comment is concerned, reducing the cost of existing tools is also a desirable outcome and should be considered as an added bonus to providing better service to the business community.

  3. This is perfect! I should mention I agree wholeheartedly with the IT Skeptic’s comments. These are factors that should always be considered or which should drive tool implementations. I’m talking to the next step – once the tool has been purchased and configuration discussions begin.

    It’s extremely common that during requirements definition I’ll see a client wanting to duplicate a tool-driven process that may not be providing the outcomes they need it to provide, but the tool’s limitations forced it on them.

    This article is aimed at that audience: when you’re bringing in a new tool, it’s a fantastic opportunity to step back and perform some Continual Service Improvement. Look at the organization’s objectives against your processes and identify the gaps that could be addressed along with the implementation of the new tool. This way you have an opportunity to configure the tool for your future state, rather than just duplicating what you have today that may or may not be working. If a process is working well for the business, by all means keep it, but where legacy tools or practices are causing added layers of bureaucracy or not serving the business, it’s a great time to realign.

    If this wasn’t clear the first time around, my thanks to the IT Skeptic for bringing it to light. Jan, thanks for your comments too. I do get involved with projects that involve bringing in a more robust tool that has the ERP for IT capability you mention and that’s the reason the implementation is being done. Even more reason to reassess the current state of the processes against the goals for the future.

Trackbacks/Pingbacks


Leave a Reply