In the work I do I often come across the request and preconception that Multiple Companies or Business Units should be moved all into one Salesforce Org.
Let me add here a recent example I stumbled recently upon in the Trailblazer community, which kicked me into action for this article:
The company has now purchased another company and would like them on the same salesforce org. I have inherited this and now need to find a solution. So I have multiple duplicate Companies, I want to combine them and allow the individual sales teams access to sell into them. So my question is what would be the best way to achieve this? Teams?, Sharing Rules?, Permission Sets? and can I use record types for each sales team, of which there are 2( so 2 record types for opportunities only)
https://trailhead.salesforce.com/trailblazer-community/feed/
Why do we jump into solutionising so quickly?
Before jumping the guns on merging and adding all stuff & users in one org, (ie prior to merging your orgs) it is certainly beneficial to go through a proper investigation (call it governance and discovery process if you must).
The aim of this effort is to identify what the outcomes of merging your org will look like. It doesn’t have to be a lengthy, strenuous and boring exercise either!
The cost of not doing so (or the outcome of a bit of investigation) is that just a direct merger may lead to increase of technical debt, performance issues, security concerns, user friction, half-baked processes, etc.
Often the ask comes with the intention to reduce cost, but the truth is that some of the above and other reasons (like replicate, recreate, migrate, training, etc) can easily lead to additional cost.
Here is our guided checklist for you and the team to analyse:
- what are the companies doing,
- what are the privacy policies on data sharing among each entity (ie expectation from customers, parties and related data),
- what are the key processes each one has
- how different are those processes
- what are the volume of users
- what is the cross over of data and processes on the users
- what is the volume of records for each
- what is the processing needs of those records, how often and how many
- what would look like in 2 years? ie further acquisition, volumes, tech landscape
We have this tendency to think about acquiring to support acceleration and growth (gosh I have trouble with that word, growth).
Here is a nice entry from Gregg Cook on the developer site on Enterprise Architecture: Single-org versus Multi-org Strategy: https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy.
So you can extend the checklist: process over standardisation?; who is paying for support & maintenance?’; complexity vs KISS; compliance & regulatory needs, etc.
Sometimes the question is about what is the cost of not doing so?
To close with a little snippet of my last book as food for thought beyond the orgs discussion:
“We find the practice of business acquisition and mergers to support growth, on the side of what can be a negative disruption. Whether acquiring and merging companies or not may be one of the most important decisions an organisation ever faces. Time and time again, we have seen organisations defeating their purpose by ending up destroying value—rather than acting as acceleration. This instead brings disturbance, confusion and problems all around. The effort becomes all in all costly for time, input and value outcome—with all around stressed and unhappy people.” SustainableHappyProfit.com