We understand that complex enterprise organizations, for many reasons, are currently managing multiple orgs. With this, often comes a number of questions about how to best manage a multi-org environment.

1. Living in a MultiOrg World

2. Objectives of this session
Discuss the reality of why we are here
Considerations around multi/single org
Living in a multi-org world
models
pro’s cons of each
actions in assessing
Discussion/experience share

3. Assumptions – why you’re here.
You have multiple instances with common business process
You have multiple instances each used for totally different things
You have multiple instances, and have no idea what is common or different
You hear a lot about companies slipping into this and want to prepare
Other items
LANGUAGE
GEO
COMPLIANCE
LEGACY CUSTOMIZATIONS
LEGAL

4. Why are you Multi?
Salesforce seed strategy

5. Why are you Multi?
Salesforce seed strategy
Merges and acquisition

6. Why are you Multi?
Salesforce seed strategy
Merges and acquisition
Intentional strategy
Variance in business process
Fundamental separations in functions/business

7. Why are you Multi?
Salesforce seed strategy
Merges and acquisition
Intentional strategy
Legacy technical constraints

8. Why are you Multi?
Salesforce seed strategy
Merges and acquisition
Intentional strategy
Legacy technical constraints
No idea

9. Before we get started
Consider what SFDC is to you.
Customer Relationship Management
Common understanding of customer
One version of truth
Consolidate the perspectives CUSTOMER

10. Before we get started
• Consider what SFDC is to you.
• Operational Platform – capture X functional process
Linking the organization internally. Collaboration. Place I go to find/execute work

11. Before we get started
• Consider what SFDC is to you.
• Development platform (App Cloud) – host custom
applications

12. What have 2000 projects taught us

13. No matter how unique
the business. Core
processes can be
normalized.

14. Humans are hoarders.
In life, data and
metadata.

15. Users operate in short
time windows. It’s not
that they forget. It’s just
not worth it to them.

16. Systems drive efficiency
at the company level.
This can feel like
inefficiency at the user
level.

17. If we had a fresh start…
If we were to start again with all that we know
What would we do?
Establish the ideal state.
Process into requirements
Macro needs
Don’t default to single org. What is reasonable?
Single view of customer.
Security
Common business process
Analytics
TCO

18. But we don’t have a fresh
start Jenkins!

19. What do the sponsors tell you?

20. How are the systems being used?
Conduct user / admin interviews
User stories
Day in the life interviews
Business process review
Role/ Business Function/Process/Statement/Validation

21. What does the data tell you?
Conduct detailed data audit of orgs
What objects are in use.
What fields
What date stamps/age
When were they used
What reports are being used
What data is being entered
What does the data tell you.

22. What does the meta data tell you?
Conduct detailed audit of the event logs– user interaction logs
Who
Clicked what
When
Large data volumes – warning
Analytics overlay required
What does the data tell you.

23. Simple summary
think forensic analysis

24. Two philosophies
SPEED QUALITY
COST
NATURAL SELECTION DOMINATES BUSINESS ENGINEERING

25. One framework
NATURAL
SELECTION
DOMINATES
BUSINESS
ENGINEERING
How do we get the best of both?

26. One framework
NATURAL
SELECTION
DOMINATES
BUSINESS
ENGINEERING
How do we get the best of both?
Intentional experiments
Rollback strategy
Sharing intentions
Learning repository
Documented results
Learnings/Go forward
Successful experiments
Non-negotiable elements
True governance

27. What are the options

28. SEPARATED – BI Summary
Allow for true agility at the “org” level. Provide a
set of services for integration and require BU’s to
maintain their dictionaries and provide data for
rollup/executive reporting
++ +++
BI Summary
Layer
Consider ERP integrations?
Cover up. Why not fix the
source.

29. PARTIAL INTEGRATED
AKA matrix strategy, each org subscribes to object
and data definition standards, communicating
projects and data dictionaries, allowing for point to
point integrations between orgs to drive business
process.
+
+
S2
+
+
S1
+
Samples shown for S1 and
S2 only.
Integrations become a
nightmare. Anonymous
captors.

30. MASTER DATA
Business units or even departments will maintain
their own instances, but be forced to tie all
common data to a separate consolidated
environment. Could be MDM or a Master Data
Instance of Salesforce.
MASTER
Account Master
Contact Master
Product Master
Price Master
Reference Master
Leverages Data.com use
DUNS as a common key
Does not consider business
process.

31. MASTER META DATA
Business units or even departments will maintain
their own instances, but be forced to maintain
common metadata definitions, data structures,
governance standards. Common stack for all orgs.
Tip- common sandbox for ALL previous to rollout will drive
governance.
MASTER
META
Account Base Object
Contact Base Object
Product Base Object
Workflow
Triggers
3rd party apps
Does not consider common
data. No 360.

32. CLONED
All orgs are “birthed” from a common – evolving
master implementation. While they will be
expected to diverge over time, the base is
consistent. In cases where base functionality has
to be changed, the parent is changed and change
has to be pushed down. Similar to Master Meta,
only less rigid.
+
+
+
+
Source
Org
Internal
Appexchange
What about the data?

33. Great. Nothing works. Awesome

34. So what is the right approach
What should be considered table-stakes

35. Regardless of the Multi Approach
Common data definitions
Master Meta-Data
Maintain a data dictionary
Establish a x-functional group to maintain with representation
Force standards on field labelling

36. Regardless of the Multi Approach
Common reference data
Common Master Data
Who at any one time “owns” the attribute (system/person)
Do they understand/know this
Standard integration “services/apps”
Canonical view – pure standards at the central source
Method of nominating the “golden record” attributes

37. Regardless of the Multi Approach
Common governance/stewardship
Common maintenance
What are the standards X all orgs
How are they being maintained
How are we assessing them – metadata discovery
What are the functional roles of the people to manage

38. Regardless of the Multi Approach
Common technology stack where possible
Cloned
Avoid additional complexity introduced through new apps
Standardize at the app level

39. Regardless of the Multi Approach
Common rollout/QA and metadata management
Common methodology
Sandbox and rollout strategy
QA processes
Project documentation and requirements management
Cleanup/retirement of data/app strategy

40. Regardless of the Multi Approach
Reflect performance from the top of the hierarchy
Common benchmarking
Provide installable packages or access to enterprise reports
Display differences and performance gaps
Show orgs what is seen at the exec level – drive accountability

41. If you cannot recall
anything else – next slide
counts

42. TAKEAWAYS
Size of business does not indicate Multi/Single fit
Common business process trumps common system
Common apps across all orgs – allow intentional experiments
Common reference data – dictionary
Common org management (governance/training/qa/deployment/sb)

43. Discussion starters
How will the new capabilities around Lighting affect this?
What is the worst thing we can do in running our SFDC environments?
Where do I start?
How do we find the balance between democratic/dictator?
What are the indicators of bad things ahead?

44. Thanks!