As a Salesforce Admin, we are constantly implementing new processes for our organizations. To start a new salesforce.com project off right, it is crucial that we take the time to interview the right people (and allow them all to contribute!) and clearly identify and document where their pain points are within the process.
UPATE SEPTEMBER 2015: I presented on this topic at Dreamforce 2015 “The 5 Key Steps to Documenting Process Like a Rock Star” watch it here!
Personas
The first order of business is to identify the subject matter experts (SMEs) and a business owner of the current process and interview them. Schedule a kick off call and get them all of in one room if at all possible (with white boards and sticky notes!). Larger projects/ initiatives should have an executive sponsor.
To ensure you have identified all the right people, be sure to send an email in advance with a persona diagram asking everyone to confirm that the diagram covers all departments/ units/ teams that own and or work within the current process. Here is an example diagram for a contract management change initiative:
During the meeting be sure to ask them why they do what they do for each step of the process, and what does each step do for them exactly (you are trying to identify where the value is in each step of the process, often you find their actions are completed in order to initiate another process for a different team). Your goal is to document a visual workflow of their current state and identify all teams that are affected in any way.
Bombs
Process improvement is about solving major pain points for the business (often these are heavy duty manual processes and complicated tracking processes that were designed in Excel instead of a database solution like salesforce.com). Your goal here is to listen, ask good questions and make them feel comfortable. Make it clear you are there to help them, thus building trust with them and giving them a sense of ownership in the project at the same time. Gaining trust and support from this core team will be essential to the success of your project!
Example of process Bomb:
The legal team must manually create a contract and send it to the sales team in order for them to send the contract on to a prospect (even though it is the same basic template with small modifications, currently the legal team does not allow for the sales team to make manual changes, so the template is locked down and only legal is able to generate it).
Jams
Jams represent areas of the process where there are delays due to chronic email churn, where there is no visibility into the current status of a task or opportunity, and or it is not easy to follow up on something (i.e. the status of a contract when it was sent via email and it is not mandatory to track the action anywhere else!).
The way I typically differentiate between a bomb and a jam is by keeping jams under the umbrella of “something I can easily fix with out-of-the box force.com functionality” (such as approval flows, or an automatic field update with workflow rules, and or auto generating email alerts to the proper teams, etc.).
Example of a process Jam:
The sales team changes the status of the opportunity record when they email the contract out but there is no reliable way for the sales director to see a report of how long it takes a contract to be signed on average. Implementing an auto date field update based on the status changing to “contract issued” and then another date field capturing when the status is changed to “contract is signed” can be done very quickly using out of the box functionality (to see a demo of the automatic date field updates check out Episode #1 of my Admin to Admin Academy Podcast!).
