Acquisitions and Mergers from an IT perspective
In today’s fluid business environment, the one thing most businesses are guaranteed to experience is some form of organizational change. For many, that change will come in the shape of an acquisition, merger, or divestiture. For some it can be as simple as a realignment of departments and resources. Hy Wu, a Principal Consultant at MondayCall is the technical leader behind many of MondayCall’s org change projects. With a strong background in both IT and Salesforce, Hy has lent his expertise to almost every org merge, split, and migration project that MondayCall has successfully completed. We asked Hy what the trends are of late in organizational change and recommendations to minimize risk.
What are some of the scenarios that would result in a need for an org merge/split/migration?
I’ve found that most org changes are prompted by companies that have either been acquired, consolidated, or sold-off divisions. Those are the most common cases in my experience, though I’ve also handled a few others that involved changes due to compliance, and even one where the customer simply wanted to move themselves to a smaller org in order to streamline and optimize their existing functionality.
What are some things to consider when planning for a merge/split/migration?
The biggest things [during a merge/split/migration] are to be sure to include 1) change management and 2) collaboration in the technical shift. For teams on both sides, whether you’re going through a split, merge, or migration, they’ll be put in different environments and potentially experience unexpected functionality or processes. It is especially important to consider the changes as functionality is tested to make sure you still have everything you need and operating as intended. Another area to consider is the technical shift, where we may make the decision to take a team and put them in a new org, or combine them with an existing org. Clearly defining the direction and process will avoid misunderstandings and prevent scope creep or problems with associated business processes later on down the line. We have the technical skills to make org changes as seamless as possible, but it’s important the customer participates in any decisions to ensure changes work as intended.
For a project as broad in scope as this, is there the potential for confusion in the expected process, roles, or outcomes?
Misunderstandings can be commonplace – a lot of the people we work with aren’t in the IT space, so they tend to interpret the process as just cutting out the old org and pasting it into a new one. Nearly everyone seems to think that when we offer to copy a database and its functionality over to another database, it would preserve all the same functionality exactly as it was before – but all the technical IDs and all the processes are now in a brand new org. That said, everything should function about the same if all steps are followed, including all the testing. It’s also important to note that in many cases, splits, merges, or migrations, all activities may tend to be ‘forced’ upon an org. The potential disruptions involved in changing an org’s workflow should be carefully considered in relation to the operation of the business as a whole.
What are some of the toughest parts of org change projects?
The toughest aspects [of any org change project] are change management, setting expectations, and getting participation. When it comes to getting participation, that should come from both the existing org and the new org, especially at the senior levels. Making any sort of change can be challenging if you’re trying to do the work without executive buy-in and support. For instance, a customer we worked with was doing a simple “move one org into another” – on paper, this should be pretty straightforward, but as it turned out, the customer’s source org is still owned by the parent company, and they wouldn’t let us work directly with their system or data. We had to manage the entire move through an approved third-party in order to get the customer’s data and metadata.
Lastly, it’s incredibly important that whenever we perform any sort of org change, that we make the customer’s transition to their new system as seamless as possible. We want to hear the comments, and make sure that it really was a non-event.