Building Salesforce for an Enterprise

Building and implementing Salesforce for an enterprise is a massive transformational accomplishment, but I have seen too many times that organizations have difficultly implementing with speed, agility and overall purpose at an enterprise level.  Organizations fail to approach such an undertaking without first considering best practices and an overall governance model. What I mean by this is to start small, think big, scale rapidly and measure success frequently while driving to your enterprise vision. Unfortunately, usually the opposite occurs: It’s too many teams, too many people, too many ideas and the outcome is another very complex instance of Salesforce that does not produce the value set out to achieve. 

Enterprise implementations typically bring technical debt, over customization and poor adoptability. Often times, companies can’t move to Lightning or execute Einstein because they made it too complicated for the organization to manage and users were not considered adequately in roll out so they simply refuse to adopt.  

So how do you implement Salesforce at an enterprise level for all your business units while still allowing them to have their unique functions and processes?

It’s really not that complicated. It’s a simple way of working that allows flexibility with centralized structure. The art of implementation provides core functionality and utilizes an enterprise approach while ensuring that you are aligning to the enterprise vision and not one person or group’s idea of how things should work. 

The approach is the Core vs Localization model. In a nutshell, you are building an enterprise instance of Salesforce at the Core level. This is where 90% (or more) of your customization, configuration and unique features of Salesforce resides. Each business unit is treated as a Localization of this instance. They can ‘adopt’ features and configure them for their unique business needs. This also utilizes data driven frameworks and a new way of designing Salesforce. We are not simply taking a user story at face value as an input to the system, but designing it so at an enterprise level it can provide the functionality needed. This is not a templated approach as it is too strict and fails. This is an agility model that flows features from a centralized core while incorporating everyone’s ideas. 

Structuring this creates a very lean operating model. Your Core team is your largest team, but not really. You have a dedicated team for each Localization. This allows multiple lines of business to execute on the core product and does not create a waterfall approach with one business coming after another or designing Salesforce uniquely for each business unit. The main set of user stories is developed at the core level and then used by the localization teams as they implement the core instance. New features will be requested through the Localizations and these new features flow back to the Core team for evaluation, prioritization and inclusion at the Core level. Your outliers are simply localizations. 

There is a very simple decision point that governs this. If the localization is more than 10% customization or requires any level of code, it flows back to the Core team for authority to implement and ensures the design is in line with core development. To compliment this you use your governance model and best practices to identify stories that have enterprise business value so they can be discussed at an enterprise level with a board approach. 

You may be wondering why you even need a Localization team, but that team is taking your enterprise vision of Salesforce and applying it to the unique business. In many instances, this takes a lot of dialog. Your core team becomes a governing group on what is allowed and not allowed into the instance. Business units do not need to adopt all features however the underlying process for how an organization services customers or sells to customers aligns naturally. Your final outcome should satisfy your enterprise vision of something like Customers First. 

The other benefit of this model is the reduction of technical debt. If your organization is drowning, this model reduces technical debt significantly and in some instances by 75%. Core is built to take advantages of new features and is completely lightning ready. Imagine taking an instance that cannot develop one more character of code because you have over customized and reached governor limits. What is the path forward? Spin off a cleanup project? It changing how you implement. If you keep doing what you are doing today you will end up with the same results.

One of my favorite conversations was about sunsetting Siebel into Salesforce. I listened to their approach to analyze everything in Siebel and recreate it in Salesforce and chuckled to myself. The classic “lift and shift” is more common than not because it seems easier. The path of least resistance if you will. I counter this with “Why not take the opportunity to change and improve?” The future is in front of an organization, not in the past. 

I challenge you to change your thinking to Enterprise, create your enterprise vision or mantra, restructure your teams to Core and Localization, architect with purpose, design for an enterprise, and be flexible with centralized structure.  Remember to start small, think big and scale rapidly. And most of all, keep it simple!

Originally published: October 10th, 2018: https://www.linkedin.com/pulse/building-salesforce-enterprise-lauresa-escribano-csm-sa/?trackingId=T834%2BjjQSH%2BwlXf3h7emSw%3D%3D