While mergers and acquisitions are the rage these days, there’s an equally important, but often overlooked business activity that’s driving companies to relook at their enterprise landscape. We’re discussing Divestiture, the art of splitting up a conglomerate into multiple business entities which often results in some of those entities being sold off.

Why, you may ask. The reasons are many but some of the most common are to reduce cost, improve cash flow or could be capitalization of value built so far by founders or many more. We’re here to address the impact of divestiture on the enterprise IT landscape.

Challenges

In most cases, enterprise systems are not designed for easy sell-off/split-off with the technology and data being mixed up. Add to it, the impossible timelines stipulated by forces outside of the IT department. Things get even more challenging as some of the enterprise systems hold intellectual property data or trade secrets.

Every divesture project is going to be different. It is purely dependent on what business lines are to be retained, who takes ownership and the impact to the application in question. Keep in mind that the rules of engagement change by the hour or by the minute. As companies are being evaluated for sale, legal procedures can swing the scope of the project wildly, so it’s important to partner with a team who can be nimble and flexible.

Key Considerations

1.    Timeline

The most important aspect to consider is the timeline and is defined once divesture decision is official. This paves the way forward for an action plan that drives us towards the end state. It’s important to form a PMO team that works out a plan to achieve this objective by breaking down the scope of work into various milestones. This exercise opens a lot of open-ended questions that will need inputs from cross functional leadership teams. The schedule will remain fluid and will need to be worked on constantly to accommodate scope changes.

2.    System Architecture

Most organizations own an ERP system which is heavily integrated with other systems for master and transactional data. ERP is the system of record for a variety of data elements and usually the central element. So, we need a deep dive to understand  to- be landscape based on what applications are retained. Some of the edge application may reside in IT firewall of parent company and needs a strategy to be built to retire/rewire/replace as necessary based on who is going to own it. Here’s an illustrative diagram of an enterprise IT landscape and how data flow between systems.

Fig1: Enterprise IT Architecture

1.    Technology Partner

When it comes to choosing a technology partner for this activity, companies may not be having enough time to go through ideal process of RFP and companies would consider traits in partners who are agile, flexible, composed, connected with business to make sure that ever changing requirements are addressed while meeting timelines for ‘Day1 of Divestiture’.

2.    Data Migration

a.    Intellectual Property

Data is the most important aspect of any enterprise. In case of divestiture, we need to identify intellectual property rights and which business line is going to own it. Multiple stakeholders including Legal teams play a crucial role in this exercise.

b.    Master Data

Master data like items, customers, and suppliers which were shared will need to be cleansed and segregated.

c.     Transactional Data

This includes but is not limited to Purchase Orders, Sales Orders, Payable Invoices, Receivable Invoices, Inventory, Work Orders etc. Bankruptcy is a disruptive process that requires invoices and contracts to be re-negotiated. Finding the right owner for each of these key transactions is key.

d.    Data retention

There will demands from multiple stakeholders to retain data for segregated business units even after data has been shared. This is usually agreed upon by all the parties and adds another layer of complexity to the process.

3.    People

a.    Stakeholder identification is key to the success of any program. However, with divestiture, the stakeholders are going to rapidly change. For eg: in bankruptcy, there’ll be a high rate of attrition. It’s hard to control and outside anyone’s control.

4.    Change Management

While company is going through divesture, it is imperative that there are lot of changes going with stipulated time frame. The change could be in terms of technology, policy changes that are going to come into effective from Day1, role changes, reporting structure changes etc.. so absorbing that change by all employees is going to be a challenge and sometimes can create panic so managing this change requires formation of a ‘Change Management Team’, possibly managed by or in collaboration with third party vendor, to manage this change.

5.    Signing authorities

These are stakeholders who will sign-off on various aspects of the project. Who is going to retain access to data/systems, who will provide data requirements to for master/transactional data or whether to mask the data that is not going to be used. Ideally, signing authorities are to be identified well in advance for all data entities to avoid any kind of legal issues that may arise at a later point in time.

6.    Access/License Management

All applications will undergo thorough review to evaluate usage. Roles and responsibilities will change depending on the size of business units. License changes will result in negotiations with multiple vendors. It’s ideal to prioritize high value and business critical system licenses to help ensure adequate coverage.

7.    Test Cycles

Time is a critical factor that determine how many test cycles can be conducted. There’s inherent risk in limiting the number of test cycles, but the larger scope of the exercise will determine the testing roadmap. It’s common to assume that risk and proceed to achieve the goals of the divestiture exercise.

8.    Cut Over Strategy

The strategy determines process of transitioning to the new landscape. It will provide duration of the cut over, system down time, sequence of activities along with owners. The strategy includes identifying all data entities, master as well as transactional, where action is to be performed, when to perform, when to align business for their review & approval. It is also going to have information about when edge applications are going to stop transactions, configuration changes that are required to be done to achieve intended objective, when to restart the transactions, communication with internal and external stakeholders etc. A strong PMO will drive this and ensure successful closure of all activities.

9.    Transitional Service Agreement

Once a company is divested, the parent company continues to support their IT for a period of time. The terms of this are governed by the ‘Transitional Service Agreement’. This agreement is going to include the IT architecture post divesture to be supported, what businesses to be supported, what data entities to be supported, what edge systems are to be supported, time zone in which support staff is going to be available, tool to log, track and monitor the incidents, definition of severity levels of the incidents logged, what are support level agreements for each severity of the incident. Support team to follow as per the agreement.

In one of the businesses where we have divested the organization into three different units, requirement was to divest 2 business entities from the ERP system and to retain one entity in the system so separation of master data pertaining to three different business entities was difficult by business hence, we came to an agreement at the very early stages of the program on each master data entity what needs to be done and also on transactional data. On transactional data like sales orders, on hand, work orders, purchase orders where data for divested companies also exist so criteria for what data to be retained, how divested data to be cancelled are well defined in early stages of the program. And Divested businesses also needed their data in specified format so that they can utilize the history of transactions in their new organization and utilize it for business purposes. So we decided on divesture in ERP to be done on day1 and data for divested companies would be provided at later point in time agreed with all stakeholders. We have legal team to sort out any differences arising to agree upon.

Conclusion

The most important aspect of day 1 of divestiture is to ensure business continuity. It might not be the ideal IT landscape, but one that works. It’s only the beginning, what follows is a multi-year roadmap to an ideal state that involves re-implementing and upgrading the systems to suit the needs of the new business to latest technologies like SaaS and optimize costs.

Glossary

ERP –>  Enterprise Resource Planning

PLM –> Product Life Cycle Management

MES –> Manufacturing Execution Systems

CRM –> Customer Relationship Management

BI –>  Business Intelligence

EDI –>  Electronic Data Interchange

ASN –> Advance Shipping Notice

SI –> System Integrator

IT –> Information Technology

SIT –> System Integration Testing

UAT –> User Acceptance Testing

RFP–>  Request For Proposal

Co Author:

Alexander Kurian, Director Enterprise Application, Proterra

An Enterprise Technology Executive with deep experience in leading globally distributed IT organizations, delivering large-scale enterprise applications, digital and cloud transformations, business automation and complex acquisitions and divestitures. A change agent with over 18 years of diverse industry experience in Supply Chain, Finance, Customer Relationship and Human Capital Management systems.