Describe the services the business needs
An integration plan needs to explain how work will be performed after the transaction. An organization chart identifies reporting relationships, but leaves many operating questions unanswered. Start with the services required by customers and internal teams. Identify where each service is provided today, the systems supporting it and the obligations that must continue during the transition. Separate the requirements for the first day of ownership from the intended longer-term arrangement.
A carve-out can make these questions particularly pressing. The business may depend on a seller for finance, payroll, procurement or technology services. Record the scope and end date of any transitional arrangements, the information needed to replace them and the owner of each replacement. A plan to recruit a function head will not by itself resolve the process, systems and data required to run that function.
Allocate responsibility across the combined business
Decide which activities will sit in business units, which will be shared and which require central authority. Consider customer requirements, local regulation, scale, system compatibility and the cost of coordination. Applying the same arrangement to every function can create unnecessary transfers of work. A shared procurement process may be practical while technical service delivery still needs local expertise and direct customer contact.
For activities crossing organizational boundaries, specify who performs the work, who can authorize exceptions and who resolves a disagreement. Describe the handoff and the information that accompanies it. Customer-contract approval, hiring and capital requests are useful processes to examine because they expose authority that a chart can leave ambiguous. Check the proposed arrangement against realistic cases with the managers who will use it.
Sequence changes around dependencies
Systems, data and people changes rarely become ready at the same time. Map the dependencies before setting implementation dates. A combined reporting process may need common account definitions before it needs a shared software platform. A service center may require tested procedures and data access before work moves into it. Record the conditions that have to be met before an activity can safely transfer.
Include temporary arrangements explicitly. Identify the additional workload, support capacity and costs required while the businesses operate across different systems. Assign responsibility for maintaining controls and service levels during that period. A transition risk should have an owner and a response, with a clear route for escalating an issue that threatens customer delivery or a legal obligation.
Check the model against actual operations
Before expanding a new arrangement, test its procedures with the people sending and receiving the work. Confirm that they can access the necessary records, understand their authority and identify the person responsible for an exception. Use operational measures such as unresolved requests, processing errors and service interruptions. Completion of a training session or publication of a policy does not establish that the process is working.
After each transfer, review the cost and service effects against the approved plan. Record activities that remain with the former owner and any additional demand created elsewhere. Update role descriptions and service agreements when the working arrangement changes. The integration plan should show the remaining dependencies and the steps required to end temporary support, including the final handling of records and access permissions.