M&A Application Retirement – Part 2 – Inventory Time
When one company acquires another company, it is likely the acquired company has their own IT organization and application landscape. It is likely that some or all of these applications will no longer be used when the acquired company becomes integrated. See M&A Application Retirement – Part 1 – The Case for Retirement of this blog for more on the case for retirement.
Inventory? Sure, we have one of those
None of us working on the project had undertaken an application retirement of the scale we needed here. We were all clear that an application inventory is something needed to execute a complete retirement plan, but (we thought) it was also clear to us that there were more important activities that had to come first.
Our most important first task was to ensure a controlled lockdown of the core application set of the acquired company following the switch-over to the new IT systems. These core applications were well known and understood by the IT organization at the acquired company and, as a result, very easy to focus on.
With these applications switched to a read only mode, we started to determine how best and most quickly to reduce the overall foot print of the acquired server landscapes. We started to remove unused tiers in the landscape, reducing from a 3, 4 or 5 tier landscape to a 2 tier landscape, to capture quick wins. We worked on this for about two quarters.
Time to determine the real inventory
Up until this point we had taken an ad hoc approach to collecting whatever inventory we did not already know about. We found business owners where we could and we captured any bits of information we could find. Eventually we got to the point where we thought we were ready to shut off the last instance of our first application and we discovered the information we had was inadequate and inconsistent.
The first phase had helped us to reduce the server footprint, but it also hid the fact that that we did not fully understand the complete scope of the retirement effort. It might seem a little self evident that an application retirement project would need a list of applications that need retiring and we had such a list. This list was well known to IT. About a 1/3 of the applications were supporting core business processes and the remainder a variety of ancillary processes. On day-one we had a list with about 50 applications, but that list had grown to over 100 as we started to uncover less obvious parts of our landscape.
The crux of the problem was the inadequate and inconsistent information when it came to meeting various compliance requirements. Certain data had to be available for a medium to long term; in the case of HR data this was up to 30 years. Some data needed to be available on a fairly regular basis to comply with regular tax, SOX, and other audits. Where data could be taken offline, we had to be concerned with what level of data destruction would be necessary on the decommissioned storage systems. On the surface there seemed to be infinite possible variations and it looked as though we would be buried in compliance red tape. I seemed pretty clear that we needed a standard process to identify and catalog the inventory.
The first step was to compile generic requirements from the various stakeholders then translate those into a process that would determine we had captured all the necessary information. It was a little surprising to learn how little variation there was from application to application once we analyzed all the retirements.
With these questions we had the information needed to produce a retirement requirements template that could be used uniformly to plan the retirement for each application.
Getting the inventory ball rolling
The next problem was to find the individuals that could be accountable for the answers to these questions and would be able to sign off on the resulting retirement plan. Most of the individuals whose names we had for the applications either did not feel empowered to take this accountability, had left the company, or had moved on to a new job following the acquisition.
The key to solving the problem was to find an executive that could act as the single point of escalation and coordination within the business. In addition to being available for escalation, their job would be to notify the executives in each of the functional areas about their responsibilities for application retirement. We were able to leverage the old governance structure from the larger integration project to find the best person, but this would have been easier if we had executed it earlier in the integration.
Each functional executive was asked to produce a business lead to take accountability for the application retirement in their area. It took a few iterations, but we eventually got a person named for each area.
The business lead had three responsibilities. The first was to ensure our application list for their area was complete, the second was to get the questions answered, and finally to get a signoff for the retirement plan for each application. In some cases there were clear experts in the business where this could be delegated and others where all expertise at long since left. In each case we now had a business person with a clear role in helping us complete the inventory.
How many applications did you say?
In a fairly short timeframe we had a pretty complete inventory of applications, which now numbered over 200! It included critical information about how and when the applications would be retired. We learned some of our inventory contained the same application with simply a different name, some had already been retired, and some applications were still critical for certain business processes. This last point was generally a problem created by a need for historical information to support certain processes where that need had not been uncovered as a gap during earlier phases of the larger integration program.
By then end of the process we had a comprehensive view of each application through a wide variety of attributes which included accountable and expert persons, dependencies on other applications, type of archiving required, what data destruction was needed, earliest date for retirement, and a measure of the functional and technical complexity of retiring the application.
To simplify status reporting effort we attached an XcelsiusTM dashboard to the Excel based inventory. This gave a nice view to those outside the project and was updated automatically as the inventory changed. In the example below the names, dates, and numbers have been changed to protect the innocent and everyone else. The dashboard requires Adobe FLASH in order to operate. Make sure you set your browser security to allow FLASH to run.
The moral of the story
In the end we found nearly 5 times as many stand alone applications as we thought we had plus thousands of “applications” hidden inside reporting and web platforms. In the context of the overall integration effort, application retirement started about 4 months after the main transition planning. As a result, we missed an opportunity to take advantage of the momentum of the gap analysis exercise that preceded the cut-over date.
Having a process to capture the information needed to completely shut off applications is critical. It should be applied as early as possible and it should be expected that it will help uncover otherwise unknown gaps resulting from the larger integration. By deferring this inventory effort we diminished our ability to complete it as subject matter experts and business owners from the acquired company changed jobs and left altogether.
The process of building the inventory continued from the moment we started the project right up until the quarter the project closed. A much earlier start is likely to have reduced the overall duration of the project and reduce the number of applications that needed to be kept running for an indefinite period.