"How can I add a picklist field?"
"Can I modify this report?"
"Would you please update the Lead trigger to de-dupe by email address?"
Salesforce Administrators are faced with these, and many more questions on a routine basis. Salesforce.com CRM provides sufficiently granular access permissions to control precisely what an end user can and cannot do. As end users click around Salesforce, the general rule is "If you can do it, you probably have permission". However, the same thing cannot be said for System and Delegated Administrators.
Once a user is given administrative access to application settings, then more training and monitoring must be imposed. In short, a "change management process" must be implemented.
There are a number of business drivers for a change management process:
- Compliance - Your industry may require that certain changes be reviewed, approved, documented, and deployed in a methodical way
- Productivity - The smallest change in a user interface can result in hours of lost productivity if users aren't given advance warning or training
- Reliability - Prevent the deployment of changes that may break existing workflows or processes
Change management processes attempt to answer all or some of the following questions:
- Who approved and/or made the change?
- Why was the change needed?
- When was the change made?
- How was the change deployed?
A change management matrix can help identify how each type of change should be managed.
Steps for creating a change management matrix:
- Create a list of common Salesforce changes in a spreadsheet
- Define a spectrum of change management categories (For example, red/yellow/green lights)
- Periodically sit down with all Sys Admins, Developers and Approvers and review how the organization should respond to each type of change category
- There will always be exceptions. Add an "Exceptions" column to the matrix and document them
- Train admins on the use of built-in auditing tools to ensure compliance with the CM process