Tempted to “start fresh” in a nice new clean org? While this is sometimes the best option, the true impact on users, and challenges of data migration and replicating existing functionality that should be retained are all underestimated. At a Dreamforce 2016 session, Heather Schreiber of AON, the world’s largest insurance broker, described their experience in cleaning up their old org.
AON has used Salesforce for more than nine years and currently has 13 Salesforce orgs with AON Risk Services (ARS) and Aon Hewitt being the largest. The orgs supported 7000 + users over 85 countries. Over the course of those nine years, they had accumulated what is called “technical debt.”
Technical debt is essentially any configuration or code that might be outdated or no longer in use, but it clogs up the application and can negatively impact the ability to take advantage of new features. For example, before the org-wide country pick-lists became generally available, they had built something similar that was no longer needed. As another example, before permission sets existed, if one person needed to access to particular fields that others didn’t, a new profile would have to be created. So, over time, your org can become cluttered with technical debt and require a cleaning and relaunch.
So, how did Aon do this? In 2013 a governing council was formed with regional leads from the U.S., Canada, LATAAM, APAC and EMEA. Weekly meetings were scheduled to gather requirements and make decisions via majority rules. This governing council decided to perform a clean-up and relaunch rather than starting over in a new org. Guiding principles were established for how to oversee and manage the process. Key principles included:
- Just because you can doesn’t mean you should
- Avoid code customization of system
- Optimize the user experience and value – keep it simple
- Leverage collaboration to share knowledge
How did they manage the process? The process was designed to challenge business users on their requests and to ensure that each request is analyzed and not just implemented upon request. All new requests required business justification and review/approval by the governance council; this included new fields, new pick-list values, new validation rules, new workflows, new coding requirements. Their approval guideline was to examine whether the request was in the spirit of the relaunch efforts. For example, did it simplify the system, did it enhance the end user experience, was it out of the box functionality, and did it support consistent reporting?
For their first phase they went strictly back to basics and focused on Accounts, Contact, and Opportunities. For Security, they moved from a private model to a “View All” for Accounts, Contacts and Opportunities in each country. They eliminated unused fields by leveraging the help of Field Trip, an AppExchange product. They agreed on global fields, labels, help text and overall taxonomy. They used out-of-the-box functionality wherever possible and performed an analysis of their code coverage to make improvements. For workflow and validation rules, they built one set per business process and performed rationalization wherever possible.
They presented their recommendations and approach to the governance council via demos and POCs. This included:
- single global page layouts
- three new opportunity record types
- one global price book
- one global product list
- out-of-the-box revenue scheduler
- restructuring of how data is entered to remove inefficiencies
- standardized global reports
The results are that now the business can do global reporting, they have more opportunities to do up-selling and cross-selling, and they can see all requests in one place, which means better global usage and prioritization of requests.
Critical to the success of this 18-month project was to get requirements signed off well in advance and have a strong change-management process. They also created a centralized account creation team and enhanced how they handle user management to include on-boarding team and Q&A sessions. For their deployment, they learned to turn off all outbound emails and sharing rules before migrating. Also important is to establish best practices for managing changes in sandboxes and perform test deployments well in advance. They had to perform extensive regression testing, even on areas that weren’t being touched because they could be impacted by the security changes. It is essential to review system permissions again, as once they opened up security, they needed to consider removing some permissions like the ability to export data.
In summary, it was a lengthy, time-consuming project, but they are now in a better position to manage changes and take advantage of new features and releases whereas before they were not.
If you need help assessing your org(s), Perficient has a great team that has helped customers unwind complex webs of technical debt and will work with you to ensure you are developing your org(s) to prevent the creation of new debt!
