Living in a MultiOrg World

Objectives of this sessionDiscuss the reality of why we are hereConsiderations around multi/single org Living in a multi-org world

modelspro’s cons of eachactions in assessing

Discussion/experience share

Assumptions – why you’re here.

You have multiple instances with common business processYou have multiple instances each used for totally different thingsYou have multiple instances, and have no idea what is common or differentYou hear a lot about companies slipping into this and want to prepare

Other items

LANGUAGE

GEO

COMPLIANCE

LEGACY CUSTOMIZATIONS

LEGAL

Why are you Multi?Salesforce seed strategy

Why are you Multi?Salesforce seed strategyMerges and acquisition

Why are you Multi?Salesforce seed strategyMerges and acquisition Intentional strategy

Variance in business processFundamental separations in functions/business

Why are you Multi?Salesforce seed strategyMerges and acquisition Intentional strategyLegacy technical constraints

Why are you Multi?Salesforce seed strategyMerges and acquisition Intentional strategyLegacy technical constraintsNo idea

Before we get startedConsider what SFDC is to you.

Customer Relationship ManagementCommon understanding of customerOne version of truthConsolidate the perspectives

CUSTOMER

Marketing

Sales

Product

Services

Support

People

Operations

Finance

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 workCa

mpa

ign

Lead Oppo

rtuni

ty Orde

r

Proje

ct

Purc

hase

Or

der

Reso

urce

Effor

t

Log

Invoic

e

Case

Before we get started• Consider what SFDC is to you.

• Development platform (App Cloud) – host custom applications

What have 2000 projects taught us

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

Humans are hoarders. In life, data and metadata.

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

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

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 requirementsMacro needs

Don’t default to single org. What is reasonable? Single view of customer.

SecurityCommon business processAnalytics

TCO

But we don’t have a fresh start Jenkins!

What do the sponsors tell you?

How are the systems being used?Conduct user / admin interviews

User storiesDay in the life interviewsBusiness process reviewRole/ Business Function/Process/Statement/Validation

What does the data tell you?Conduct detailed data audit of orgs

What objects are in use.What fieldsWhat date stamps/ageWhen were they usedWhat reports are being usedWhat data is being entered

What does the data tell you.

What does the meta data tell you?Conduct detailed audit of the event logs– user interaction logs

WhoClicked whatWhen

Large data volumes – warning Analytics overlay requiredWhat does the data tell you.

Simple summarythink forensic analysis

Two philosophies

SPEED QUALITY

COST

NATURAL SELECTION DOMINATES BUSINESS ENGINEERING

One framework

NATURAL SELECTION DOMINATES

BUSINESS ENGINEERING

How do we get the best of both?

One framework

NATURAL SELECTION DOMINATES

BUSINESS ENGINEERING

How do we get the best of both?

Intentional experimentsRollback strategySharing intentionsLearning repositoryDocumented resultsLearnings/Go forward

Successful experimentsNon-negotiable elementsTrue governance

What are the options

SEPARATED – BI SummaryAllow 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.

PARTIAL INTEGRATEDAKA 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.

MASTER DATABusiness 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 MasterContact MasterProduct MasterPrice MasterReference Master

Leverages Data.com use DUNS as a common key

Does not consider business process.

MASTER META DATABusiness 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.

MASTERMETA

Account Base ObjectContact Base ObjectProduct Base ObjectWorkflowTriggers3rd party apps

Does not consider common data. No 360.

CLONEDAll 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 Appexchang

e

What about the data?

Great. Nothing works. Awesome

So what is the right approachWhat should be considered table-stakes

Regardless of the Multi Approach Common data definitionsMaster Meta-Data

Maintain a data dictionaryEstablish a x-functional group to maintain with representationForce standards on field labelling

Regardless of the Multi Approach Common reference dataCommon Master Data

Who at any one time “owns” the attribute (system/person)Do they understand/know thisStandard integration “services/apps” Canonical view – pure standards at the central sourceMethod of nominating the “golden record” attributes

Regardless of the Multi Approach Common governance/stewardshipCommon maintenance

What are the standards X all orgsHow are they being maintainedHow are we assessing them – metadata discoveryWhat are the functional roles of the people to manage

Regardless of the Multi Approach Common technology stack where possibleCloned

Avoid additional complexity introduced through new appsStandardize at the app level

Regardless of the Multi Approach Common rollout/QA and metadata managementCommon methodology

Sandbox and rollout strategyQA processesProject documentation and requirements managementCleanup/retirement of data/app strategy

Regardless of the Multi Approach Reflect performance from the top of the hierarchyCommon benchmarking

Provide installable packages or access to enterprise reportsDisplay differences and performance gapsShow orgs what is seen at the exec level – drive accountability

If you cannot recall anything else – next slide counts

TAKEAWAYSSize 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)

Discussion startersHow 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?

Thanks!