Configuring Salesforce.com is easy. We agree! Configuring it without comprehensive planning and documentation can lead to trouble.
It’s a game played around the world in which one person whispers a message to another, which is passed through a line of people until the last player announces the message to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first. Reasons for changes include anxiousness or impatience, erroneous corrections, and that some players may deliberately alter what is being said to guarantee a changed message by the end of the line.
Deploying Salesforce without a business process review is like playing telephone with your organization. An executive says “this is how we do it” and the administrator interprets that in Salesforce.com. A user whispers “well, this is how we actually do it“, so the administrator makes a slight change to a sales process, adds a field or changes a security setting. The manager says “that’s interesting, can you do this also?” resulting in another change. As Salesforce.com is released to your organization, there is no clear definition of the process and your organization either 1) settles for what they get and define an obscure phase 2 roll-out to come, or 2) no one is happy and its not very amusing.
Our approach to deploying an enterprise instance of Salesforce.com is to analyze the business process to be conveyed into Salesforce.com and illustrate that process in two diagrams that clearly define the process “on paper.” Our mantra is if you can define it on paper, you can deploy it online. Success in Salesforce.com is achieved by planning, planning, planning then configuring Salesforce.com to meet your specified needs.
A Business Process Review (BPR) defines your business in a group setting that is inclusive of key decision makers. During a “white-board” session, we define the lifecycle of the process you are seeking to manage in Salesforce.com. This can be a sales & marketing process, a service process or operational process.
We define the role of staff in process, how information flows, database management, and anything else discovered during the BPR process. The result of this process is a swim-lane analysis of the process by role.
The swim lane flowchart illustrates processes and decisions that are grouped visually by placing them in lanes. Parallel lines divide the chart into lanes, with one lane for each person, group or subprocess. Lanes are labelled to show how the chart is organized.
In the accompanying example, the vertical direction represents the sequence of events in the overall process, while the horizontal divisions depict what subprocess is performing that step. Arrows between the lanes represent how information or material is passed between the subprocesses.
When used to diagram a business process involving more than one department, swimlanes often serve to clarify not only the steps and who is responsible for each one, but also how delays, mistakes or cheating are most likely to occur. Often, Salesforce.com implementations fail because there is lack of consensus in a process or that process is not clearly defined. An outcome of this process is clarity which streamlines the implementation or re-engineering of Salesforce.com for your business.
Once we define the process in terms of the swim lanes, we will review the overall system architecture and produce a system architecture diagram commonly referred to as an Entity Relationship Diagram (ERD). It is a database design tool that provides graphical representation of database tables, the columns in tables and the relationships between tables inclusive of Salesforce.com and any other databases.
The accompanying sample ERD illustrates how data and systems coexist in a complex implementation of Salesforce.com. The “red” shaded boxes are standard Salesforce.com data tables, and the polygons are external databases.
These diagrams are supported by written materials that define the process and architecture in terms that Salesforce.com Administrators and engineers can configure the system to meet the agreed upon needs. Once we define it, we can deploy it. Our ERD uses Business Process Model Notation as a standard.
Business Process Model Notation (BPMN) is a graphical representation for specifying business processes in a business process model. Business Process Management Initiative (BPMI) developed BPMN, which has been maintained by the Object Management Group since the two organizations merged in 2005. As of March 2011, the current version of BPMN is 2.0 and includes notational information and execution semantics.
The Business Process Review including swimlane analysis and BPMN has broader value than establishing the groundrules for an enterprise deployment of Salesforce.com. The process may be used for training, business planning and ISO certification.
As a professional services organization, Avideon’s role is to fully understand your business process, and convey that process into Salesforce.com based on best practices. Avideon can set that foundation and be available to respond to your needs as they evolve.