How IT Asset Inventory and Enterprise Architecture made separation planning easier
Company restructuring – whether mergers, acquisitions, or divestiture – often drive the need for good IT asset inventory and utilization information. There are other assets that are important as well, such as employees, equipment, and intellectual property, but none require as much planning and execution time with the possible exception of facilities.
In late 2008 a multi-billion dollar global electronics corporation began considerations about splitting the company into two publicly traded companies – a Consumer Electronics division, an Enterprise Products division, and selling a third infrastructure division. To start the IT analysis for the split, the first step was dusting off a dated IT asset inventory and revising it with current information. Previously, the inventory had been used for an IT infrastructure asset sale in 2003, and then again when corporate functions were centralized in 2005.
So the first lesson of IT asset inventory is the same as any other inventory – if it isn’t up to date, it has limited (or perhaps no) value. After a little time needed to refresh the data from the 2005 activities, corporate IT began looking at every application and determining which division used it as well as which would need it going forward. This required updating the inventory with more specific and timely information on the alignment of all IT assets; networks, data centers, servers, applications, data warehouses, and IT service providers to business units, facilities, employees, customers, and suppliers.
At the same time, a massive effort began to understand the cost of every application and each site’s IT infrastructure so we could determine how the IT costs were going to be split between the various divisions. This cost data could be overlaid on the asset information to see how each division’s IT budget was going to look coming out of the split. One of the biggest issues to emerge was how to keep the IT costs from doubling and saddling each business with exorbitant ongoing IT run rates right out of the gate. The phrase that emerged from this was “1+1<2”, in other words, the IT leadership could not afford to just clone (double) all the IT assets and make them all available for each of the new business units.
This led to many tough, but eventually beneficial decisions, about the utility of each application to a business unit:
- If the application was used very little by one business unit (<5% of total usage), couldn’t that business make do without the app or use another app instead? These took on the code “KILL” for that division
- Were there cheaper replacements for some apps that could be brought to bear before the split? These were coded “MIGRATE”, and led to more cloud/SaaS adoption evaluation
- For applications broadly shared across business lines, the two designations were “KEEP” for the majority user and “REPLICATE and RUN” for the minority business unit user.
Once future needs for the application were identified, the process turned to infrastructure and integrations to make sure that the KEEP/REPLICATE&RUN/MIGRATE applications would function after the split. This provided another opportunity for a very beneficial inventory – a list of all integrations to each application. This information was not only valuable to the company split, but also to future systems changes for each division.
To effect the changes, there was a CIO for each division and each had a program manager to make sure that their interests were being covered. To facilitate the process, there were weekly program administration meetings where representatives of each IT org covered actions, schedules, program budgets, and ongoing IT run rate estimates. Supporting these program meetings were a series of weekly facility, application, and infrastructure project meetings to plan and monitor progress at a more granular level.
Data warehouses were a major concern for to two main reasons:
- How to allocate the intellectual property contained in each data warehouse, since the company had many thousands of patents covering their inventions
- How to give both businesses access throughout the split process, yet be able to establish new controls once the process was finished.
Manufacturing and distribution sites were also an area of particular concern, both for the business and for IT. On the business side, there were two large sites that manufactured and distributed goods for all three lines of business. All other facilities were small and business specific, so they were left alone. On the application front, similar decisions about REPLICATE, RUN, MIGRATE, or KILL apps were a part of the early evaluations. There was a physical WAN/LAN connection side that had to wait until the business teams figured out how to carve up the floor space between divisions so the buildings’ computer rooms and wiring closets could be realigned. In a few cases, decisions were made to exit or sell smaller facilities to further reduce costs.
Finally, in cases where there were situations that could not be split in the 9 month window, Temporary Service Agreements (TSAs) were used to contractually bind both divisions to agree to host systems and data for the duration of the split process, but they were limited in duration to 12 months after the split due to financial reporting and tax implications. This also had the side benefit of encouraging each division to separate the systems expeditiously.