These days, divestments and spin-offs are common transactions during business and IT transformation programmes, hence it has become imperative that IT as a function pays closer attention to this reality. Conscious design decision-making during these initiatives can restructure the IT landscape, minimising inherent complexities of divestments and spin-offs hence facilitating faster routes to success.
Typically, IT separation projects are extremely complex and time-sensitive. Their timeframes are dictated by numerous factors such as the size and complexity of the IT landscape, as well as how interwoven the landscape and business processes are. Often, organisations do not factor in the possibility of potential divestments or spin-offs for particular lines of business. That results in the IT optimisation and design principles that drive standardisation, reuse, and more integrated IT landscapes which then become extremely difficult to separate.
IT separation is a major but not the only complex component during business separation initiatives. For instance, people, contracts, suppliers, assets, accounts payables, receivables, and numerous other factors also play key roles in the overall success of the separation. However, the scope of this article series is limited to IT functions as the primary focus area.
Note: There are numerous terminologies and jargon used to describe the IT separation activities of divestments and spin-offs e.g., carve-out. In this article series, for simplicity, we will refer to them all as IT separation.
It is important to note that, depending on the sale agreement, IT separation processes adopted by an organisation can vary. For instance, if an existing business entity is sold outright with its people, process, data, and technology then the scope of separation could be minimal – the focus will shift towards how the buyer will integrate the new components into their existing landscape. However, if the same company wants to divest a portion of the business which is not a legal entity on its own, a significant amount of work is required at all layers – from defining the legal entity to completing relevant separation activities.
IT separation projects are inherently complex, and anyone who has been part of the journey will provide a long list of challenges such projects need to overcome. The below section covers some of the key challenges that IT separation projects face. Whilst most of these may look familiar and can be argued as common issues, this is by no means an exhaustive list of IT separation project complexities.
Time sensitivity: IT separation projects are extremely time sensitive; the top management, buyers, and other external stakeholders have a keen interest in timely outcomes. Thus, delays or deadline extensions are usually not up for negotiations, given that the organisation’s reputation and credibility – judged by its ability to deliver – are at stake.
Scope for separation: Establishing the correct scope of people, processes, technology, and data for IT separation projects is usually a huge challenge even for well-established and mature IT teams. The tight integration as well as shared nature of people, processes, technology, and data makes this a complex and high-risk task. Any gaps or misses during the scope definition stage will pose a huge risk to delivery and can derail the separation programme quickly.
Subject Matter Experts (SME): The lack of knowledgeable resources is problematic for any IT project, but filling this gap for IT separation projects assumes special significance. Tacit knowledge is unlike any other as it is built over years by experiencing the intricacies of processes and systems. Without the right SME, most IT separation projects are a recipe for disaster as establishing what needs to go (business to divest), what needs to stay (business to retain), and what needs splitting (shared functions) is no easy task.
Interim and end-state architectures: IT separation projects undergo several interim state architectures before reaching the end-state architecture, where the divested business and the retained business have a fit-for-purpose IT estate that can support the ongoing business activities. Often, optimal sequencing and finalising several interim states are complex tasks – any oversight can result in a significant increase in scope and cost. In addition, a huge portion of spending for interim states can be regret spend as they are temporary and may not be part of the end-state architecture. So, it is of utmost importance to ensure there are minimal interim states and to minimise temporary changes (i.e. regret spending).
System and 3rd Party Integration: With the new businesses establishing their own identities, organisation structures, systems, and processes, there is a constant need to establish separate or separable integration flows with the internal and 3rd party systems. Separable, in this context, means using a shared integration flow whilst the systems are shared during interim states. Then, the data flows can be cloned when the new businesses get their own sets of systems. This is a critical task, and the end-state architectures of the retained and new businesses can be significantly different, having potentially undergone numerous interim states due to the gradual addition or removal of new systems and processes. With the constant addition and removal of systems throughout the IT separation phases, system and 3rd party integrations pose an unprecedented level of challenge and risk.
Data separation: The challenge that is unique and often the highest priority for an IT separation project is determining who owns what data and how to ensure the right data items are migrated to the relevant parties. This topic needs a separate focus given its importance and will be covered in detail as part of future articles where we delve into various phases of IT separation. Depending on the divestment or spin-off approach, the scope and complexity of the data separation can vary significantly. The end-to-end process typically involves:
- Setting up a new legal entity for the business
- Understanding the data separation requirements (who owns what), then migrating accordingly
- Migrating or copying the relevant master and transaction data items to the right business entities (in-flight, historical, unstructured data, and so on)
- Incorporating security and access restrictions to ensure unauthorised access is limited between the users of the various business entities whilst ensuring the support or shared team can support both businesses
- Implementing system and process controls (automated and manual) to ensure the processes are compliant and do not breach any regulatory or legal requirements
- Archiving/purging data sets that are no longer required, based on retention policies, to minimise the scope of data sets that need splitting.
- Making system-level provisions (processes and tools) for long-term data access that are to be supported based on sale agreements
- Deleting data sets that are no longer required for the intended purpose of the business, based on retention policies.
The above is not an extensive list of challenges, but it covers the most common and critical ones to be noted. A few additional issues haven’t been explored in this section as they are more specific to the separation phase (e.g., logical and physical). They will be covered in detail later as part of the series.
Any consultant who has been part of an IT separation project would have heard the mantra “Transition first and then transform” – the importance of this statement cannot be emphasised enough. IT separation projects already face the daunting challenge to create an operational legal entity against aggressive timelines. So, it is of utmost importance to defer any process improvement ideas, transformation, and optimisation agendas until the transition phase is complete.
From an IT point of view, there are three main phases for most IT separation projects, namely:
Logical separation (aka carve-out): This phase focuses on logically carving out a portion (or portions) of a business, creating a separate legal entity (or entities) to represent the business being divested. Initially, the newly created legal entity (or entities) could be part of the existing group – destined to be transferred to the buyer organisation on the sale date. Systems and processes will be mostly mixed (i.e. comprising of dedicated and shared areas/items).
However, controls and boundaries are established between the new and the retained businesses. Functions like IT delivery and support will be in shared operations mode (i.e. same team supporting both businesses) and will usually be covered under Transitional Service Agreement (TSA). System and process level security and controls are implemented so that authorised business teams can access only the functions that are relevant to their respective businesses.
Physical separation: This phase focuses on physically separating the people, process, technology, and data aspects across the board. For instance, a shared ERP system needs to be split and the typical approach would be either cloning the application for the new business or migrating the relevant functions to a new application. In both scenarios, the result is that the applications become physically separated and are no longer shared by the businesses. This physical separation does not stop with IT systems but is implemented across all relevant areas such as Data Centres, Networks, Active Directories, Software Licenses, Office Premises, Physical Devices (e.g. laptops, phones, etc.), People, and so on. This phase is usually executed in stages, resulting in various interim states – a big bang approach is usually too risky.
Data deletion: During the period between logical separation and physical separation, both businesses may be sharing many IT systems to support their core processes, thus leaving a significant data footprint. Data sets that fall under the Commercially Sensitive Information (CSI) and Personally Identifiable Information (PII) are of extreme importance and any breach or illegal access incident can result in serious issues. Thus, it is extremely important to delete the data that is not relevant for the intended purposes of relevant businesses i.e. delete new business data in retained business systems and vice versa.
These phases are usually regarded as separate projects, and they come with their own sets of challenges, risks, issues, and opportunities. The subsequent articles will cover each of these phases in detail, highlighting key challenges and how to overcome them.
ODS Architecture team has strong capabilities in supporting IT separation initiatives i.e. helping avoid most pitfalls, minimising risks, and thus maximising chances of meeting divestment/spin-off deadlines. We operate across Europe and serve all business sectors, bringing cross-sector knowledge to our clients. Our consultants will provide adept assistance and unbiased advice on how best to simplify your IT estate, increase efficiency and reduce long-term costs. To find out more about how we can help your business, please get in touch with us now.
