On 4 October 2016, I took to the Dreamforce stage to deliver a talk on what I did with the 10+ year old Salesforce instance I inherited at Amazon.
Spoiler alert: I fixed it.
Since leading this session, I have been invited to speak with other Salesforce customers to share my thoughts on whether they should keep, fix, or kill their own aged Salesforce implementation and have been asked over email and LinkedIn to share my ideas of how others should go about making this decision for themselves. The most recent question I received was:
Greetings Corey, I was wondering if you may be able to share with me some ideas of where to start analyzing the instance of Salesforce to determine if a re-platform is the solution. I’m trying to determine where to begin, what metrics to gather, and reasoning for this direction. I want to be able to create a report that will resonate with decision makers. — DG.
I am happy to help, DG!
Defining keep it, fix it, and kill it
- Keep it: Keeping your instance means making small improvements to KLO or keep the lights on.
- Fix it: Fixing your instance means replatforming, either in whole or in part, to rebuild your data model, workflow, and sales process.
- Kill it: Killing your instance means dropping Salesforce completely and moving on — either to something else, or nothing. You do not always *need* a CRM system and things change.
Understanding technical debt
Technical debt, and the amount of which is negative, will be the single most important input into your decision-making process. Here is how you evaluate the technical debt in your own Salesforce instance:
- Do you have instances of field hijacking? Reuse of fields is a typical Salesforce practice; however, the active repurposing of a field across different groups is problematic — I call this field hijacking. Look for examples where a field not only has a different definition amongst teams, but also contains a different set of data per use. Too many instances of field hijacking indicates a strong propensity to replatform — a few instances can likely be fixed within your KLO program. Example: “Priority Lead”. Normally I’d expect this field to be a checkbox; however, let’s assume the field is a picklist with values 1,2,3. Field hijacking occurs when group A uses this field to track prioritization status (using 1,2,3 as prioritization options), group B uses this field to track what program this lead has been put into (using this field to track lead warming campaigns), and group C uses this field to simply track whether or not a lead has been marked as priority (just choosing option 1 to indicate priority). In this example, org-level reporting for priority is problematic as groups have begun to build their own SOPs to workaround Salesforce, not within it.
- Have you reached your column or workflow limits? Salesforce is highly customizable, this is why you’ve bought and deployed the platform; however, excessive customization — likely due to localization — is indicative of negative technical debt being amassed. If you have hit, or are within 90% of your object column limit (800), or workflow limit (300) — both as of 5 March 2017 — chances are high that you’ve localized too much and you’ll need to replatform rather than try to fix your instance. Why? This level of customization means that your instance has been highly localized for many disaparate processes and functions — attempting to change only one, or a handful, will simply resolve your Salesforce issue and not the underlying org data model problem.
- Do you have data integration jobs updating sales stages, close dates, or other fields typically set by your sales process? Steps of your sales process — for leads and opportunities — are meant to be worked by your sales team. If you have automation in place to update these steps for you, using data outside of Salesforce, it could mean that the process is no longer useful and your workflow is outdated. The use of a handful of integration to update this data is not entirely indicative of a problem; however, if multiple teams are using different data sets and building automation jobs for the same fields, you could have a scenario where your workflow in Salesforce is outdated against the current state of your business indicating a need to replatform.
Making your decision
Once you have the scope of your technical debt understood, the decision to keep, fix, or kill your Salesforce instance will now come down to two other factors: your commitment to Salesforce as a platform and the expected growth of your business over the next three years. If your commitment to Salesforce is low, and you could potentially abandon CRM altogether or move to another platform, an investment to kill your instance and rebuild is unwise. Your resources are better spent understanding your need for CRM and making its place as a business driver more well known. If your commitment level is high, you then need to look at the expected growth of your users as determined by group and role. If you are in a stable business, you can keep your current instance and resolve more of your negative technical debt through a KLO program than if you are in a growth or changing business.