Customizing Salesforce – what to do first

Real world case example of a project I deployed

The client already used Salesforce classic as their sales platform.  However, as with ERP systems, the Salesforce model did not [and does not] align with business and sales processes.  Therefore the client wanted to customize the systems.  However, the sales and business processes were undocumented, unprofessional and without coherency.  In general any customization to a CRM platform cannot go ahead until a thorough audit is conducted of existing processes, usage, variances with Salesforce.com and how to fill gaps in the platform [Accenture case study, 2016].  Many ERP and CRM projects fail because the upfront documentation, knowledge and understanding is lacking [Iqbal & Dad, 2015].  This leads to a poor comprehension of project scope, requirements and purpose [Ghosh & Thadomal, 2012].  It also leads to budget over-runs, process disruption and in some firms, even bankruptcy [Oreda, 2014,].

 

Recommendation

Customizing Salesforce to the business will cost approximately £60.000 if all goes well, including additional internal resources post-project.  Before spending this budget, which is about 25% of yearly profit, it would be sensible to first write down and analyse the sales-project management & delivery management processes, variances with Salesforce.com to support that process; and then try to use existing apps or cheap technologies from Force.com to fill those gaps [Olsen & Staley, 2012].

 

The proper steps in understanding the Salesforce CRM and to implement changes, should include [Trad, 2015]:

Step 1. Write down the exact sales and delivery processes into one document [Ren et al 2015].  Project Owner[s] and stakeholders are identified and tasked with this document creation [Wood, 2010].  Problems and gaps with the current SaaS including the Scotsman sales methodology are understood [Billington, 2015].  Resources can be both internally and externally sourced as necessary [Cao et al 2016].

 

Step 2. Using the output from Step 1, create a Process Requirements Document [PRD]. This document will contain diagrams, models, and an elucidation of the business and sales process, along with a detailed explication of how Salesforce.com is, or is not, supporting that process [Datskovsky, 2016].  This should include security, backing up data to a UK data centre; and resolving data integrity issues within Salesforce.com [cleaning it up!].  Validate this document both internally and with external resources who understand the domain of SaaS and Salesforce [Cao et al 2016].

 

Step 3:  After the PRD is validated, the firm will add to that document a proper scope of the issues which need to be resolved and why.  Issues from the most important to the least important are identified.  This expanded PRD and scope will list changes, improvements, and stakeholder ideas [Chen et al 2009].  It will also list options and technologies to resolve the issues; including options from both within and from outside Salesforce.com [Kappelman, 2016 in ‘Skills’].

 

Options to be included in this step:

  • Customize Salesforce.com,
  • Do Nothing,
  • Use another platform or technology,
  • Use existing applications to plug the gaps but don’t customize.

 

Step 4:  The Project Owner will match the PRD and scope to the company’s objectives, goals and budgets, and elicit stakeholders for feedback and ideas [Chang & Hung, 2010].  Options on how to resolve the variances between IS and the business are listed, with costs attached.  Budget must include pre-and post-training [Dewett & Jones, 2001].  Importantly a return on investment or ROI, will be calculated for each option, comparing future benefits to the costs [Billington, 2015].

 

Step 5. The PRD with an ROI for each option, is reviewed in a general stakeholder’s meeting and a decision is made what to do – whether to customize, extend, buy new, or do nothing [Panda et al 2016].  The Project Owner may also decide to use external resources to help clarify options before and after this general meeting [McIvor, 2008].  Options are listed with pro’s and con’s.

 

Step 6. If a decision is made to build or customize Salesforce.com, then the PRD is finalized and updated including all details pertaining to the build; the goals, the time-frame, the budget, the process owners, responsibilities, external party obligations, project management and milestones [Chang & Hung, 2010].  A similar process will be enacted if it is decided to use ‘off the shelf’ apps to plug the gaps and variances within the existing processes and not pursue a customized project development [Maresova, 2017].

 

Step 7: Once a project commences, either to customize or use available applications, the PRD becomes the basis for the project [Ramburgh et al 2015].  Project Management is identified, start and end dates, budget, externa and internal resources and any other factors necessary for a successful project are outlined [Brown & Wilson, 2005].  Milestones, review dates, and measurements against the plan are also created [Chang & Hung, 2010].

 

Step 8: The project manager and business owner will also ensure a post project training plan.  Real costs and ROI are tracked and reported during the implementation and beyond [Ghosh et al 2012].  There will be a project debriefing when the improvements are deployed [Panda et al 2016].

 

The costs to perform the above in both internal and external resources would be £12.000 [Section 3 budget].  However, if the firm does not follow this program, the risk of failure of customizing the Salesforce.com SaaS would dramatically increase and according to the literature, quite likely lead to serious business disruption [Billington, 2015; Olsen & Staley, 2012].

 

By following the above methodology, and professionally documenting the system and processes, the firm will be able to decide what needs to be done, how, when and why.  It is critical that IS support the business [Laudon & Laudon, 2013] By following best practices, the firm will save money and build a proper platform, which should develop new revenue streams and recurring client contracts [Kappelman et al 2016].

 

Summary: Benefits and Demerits of the Proposed Solution

The key benefits of documenting and fully understanding the current IS/Salesforce.com architecture, and to use existing apps from either Force.com or some other platform to solution existing issues are:

  • Stop unnecessary spend and prevent a major disruption to the business through a failed customized – CRM project
  • Align the SaaS to the business through incremental and logical steps
  • Provide a complete set of documentation of what the firm is doing
  • Ensure stakeholder buy-in
  • Calculate an expected ROI and realistic budget
  • Produce a better understanding of data and its value
  • Satisfy legal issues around data storage and security
  • Ensure that backup and security policies are put into place
  • Identify and remove single points of human and IS failure, and remediate HR skills which are lacking

 

The main demerits of the proposed solution are the following:

  • Owners and staff may view extensive documentation as unnecessary and too time-consuming
  • Employing new sales people puts pressure to ‘do something’
  • Knowledge and resources are lacking in completing the necessary analysis and documentation to find the requisite apps to resolve the issues
  • There are a few personnel who are very keen to quickly deploy a customized Salesforce.com and if their views are thwarted there could be implications within the business

 

Main goals restated
  1. Assess the current process and problems
  2. Propose remedies to match the IS and SaaS to the actual sales process
  3. Assess how to ensure accuracy of data through the sales process into the delivery process
  4. Propose a viable solution and process to address risks and concerns.

 

By following the solution presented above the client was able to realize these primary goals and identify how to properly align IS and the SaaS platform to its business.