by   |    |  Estimated reading time: 7 minutes  |  in assyst Blog   |  tagged

With some organizations making almost 30 acquisitions last year, the complexity can become overwhelming. Once the dust has settled, the IT department can end up with a handful of IT Help Desks and just as many Service Desk, IT Discovery, End-Point Management, Asset Management, Systems Monitoring and ITSM applications.

In this post-merger environment, where end-users struggle with unfamiliar technologies, there is a spike in demand for support—yet business people don’t always know which route to choose.


Consolidating multiple systems isn’t just about removing redundant technology. Each has its own ecosystem of IT people and processes (and sometimes end user communities)—many of which overlap. Before you can rationalize your ITSM tools, you must first investigate the other elements in the ecosystem. Organizations which fail to consider the impact on IT people, processes, data and communities find themselves firefighting issues as the go. As a result, the timeline slips, unforeseen risks emerge and critical IT and business services are impacted. In order to save time, it is worth considering all aspects of ITSM tools consolidation.

  • Interfaces
  • People
  • Processes
  • Integrations
  • Data
  • Non-IT service departments
  • Outsourcers/Managed Service Providers
  • Cloud Services


To prepare for any redundant technology consolidation, it is vital to understand the landscape; to study the ecosystem of each toolset. People in the organization will think they know what is going on, but assumptions can be dangerous. In a large organization, the ITSM ecosystem is too broad and complex for any individual to track in detail. To get a handle on the current situation and make good, informed decisions, you need to ask some tough questions.

6 questions you need to ask when planning IT tools consolidation

  1. What ITSM systems do you have in place right now (officially and “shadow IT”)? Note that these can include ticketing tools, change tools, workflow tools, call logging forms, home-grown tools, web portals, IT discovery tools, SAM tools, systems monitoring, as well as traditional ITSM suites.
  2. Which teams use them?
  3. Which regions do these tools cover?
  4. Why were they acquired? What were the drivers? Are they still relevant?
  5. What unique requirements are being served?
  6. Have they been adapted/customized?

Only when you ask deep and challenging questions can you get a truly accurate picture of the landscape in front of you and uncover the real scope of an ITSM consolidation project. It is essential to validate what you think you know against “ground truth”, or what lean manufacturers call the gemba (the “actual place”). In other words: go and see. Speak to the people who handle the data and operate the processes. Talk to service customers about their experiences. Find out if what you know lines up with reality. One of the key challenges can be to pin-point the origins of a system: sometimes nobody from the original team who acquired it remains in the organization.


You can’t simply switch one system on and switch off the others. Rapid consolidations rarely end well; people will abandon the change and drift back to the way they used to do things. Old habits die hard—and so do old systems. Risk rises exponentially with complexity, so it is essential to break down an ITSM consolidation project into manageable chunks.

Each of the elements of an ITSM consolidation are interconnected, but one will be your primary strategic focus. This decision should be driven by the unique challenges of your ITSM environment and the needs of the business.

TECHNOLOGY Traditionally, this is the default approach: systematically attack each redundant toolset—migrating people, processes and data from each one over to the selected “master” system.
CUSTOMER GROUPS/ INTERFACES Begin by migrating a single grouping —an end-user group with shared characteristics (for example everybody in one business unit). Set up a Service Desk and web portal to establish a single point of contact and migrate the services this group uses and the delivery/support processes that underpin them. Repeat until all end-user communities have been migrated and all redundant systems can be retired. This is a good option if you are looking to embed a more customer-oriented culture.
IT PEOPLE/ GROUPS Taking a team-by-team approach is probably the easiest and most clear-cut option for IT people. However, as an IT-centric approach, it’s easy to lose sight of the business impact and the IT customer experience can sometimes suffer. To balance this out, it is vital to maintain communication with end user groups to check that they are happy throughout.
IT PROCESSES There are two strategies for a process-oriented migration: one is to enforce standard processes across incumbent tools and then do a rapid switchover onto the new system which mirrors these standard processes. The other is to model each process variation in the new tool, migrate the corresponding groups, and then consolidate processes over time.
DATA People need information to do their jobs, so wherever the data go, people naturally follow. In reality, whatever approach you choose, there will always be some piecemeal migration of data, as data are central to each one of the above elements.


The aim of any redundant technology consolidation project is to end up with just one application. The big question is: which one?

Many organizations make the mistake of starting the whole process with a technology decision. Later, they find that jumping ahead without first gaining a full appreciation of the situation was, in retrospect, a bad decision.

What to look for in a consolidated IT management solution

Whether your consolidation strategy is to migrate IT to one of your existing solutions, or you’re going back out to the market to seek a new one, you should think about how your decision may help or hinder your ability to keep tools simple in the future. We find that customers are generally tired of the maintenance overheads that come with legacy framework products which require heavy customization. Instead, they’re looking for simplicity. Under extreme pressure to deliver innovation, they want to focus their attention on managing IT services, not managing IT tools.


This is the stage at which you start the ball rolling on your initiative, but you’re not quite ready to execute the change. With a clear understanding of scope, environment, objectives and benefits, it’s time to sell the idea inside the business and gather the support you need to see it through to fruition. It’s a tough sell. IT tools consolidation is not a fun innovation project. People won’t readily volunteer for what can be a complex and high-risk project.


The key to developing support is to answer the question “why” at three different levels:

  • Why is it good for the organization? (The business case)
  • Why it is good for IT? (Selling it to the IT department as a whole)
  • What’s in it for me? (Selling it to individuals/groups)


Communicate clearly and often. Reiterate what the end state looks like and how it will benefit them to maintain energy throughout. Communicate the wins that happen along the way. This is one of the fundamental reasons why an agile, phased approach beats a big-bang waterfall approach: visible value is achieved earlier in the timeline, so there is more of a sense of momentum.


Now is the time to begin on-the-ground execution. The objectives are clear. A plan is in place. People are on board. The Plan-Do-Check-Adjust (PDCA) cycle is a good framework for managing the iterations which follow—with lessons learned from each phase being passed on to the next to accelerate progress and minimize risks.


  • What do you want to achieve in this cycle?
  • What are the risks and how can you mitigate them?
  • What steps need to be taken?


  • Taking specific actions, such as:
  • Moving blocks of data from your legacy systems
  • Modelling processes in the new system
  • Configuring integrations


  • Did you follow the plan?
  • Did the plan work?
  • Were the objectives achieved?


After each phase is complete, you can reflect on how well it went and think about any lessons learned that can be applied to the next phase. Do you need to do anything differently in the next iteration to get better results?



Leave a Reply

Your email address will not be published. Required fields are marked *