Dallas Salesforce User Group - January 2012 Meeting: Release Management

January 19, 2011

Org Change ManagementDallas User Group

Sathya SridharProfessional Services Manager@sridharsa

Certified Developer5 years exp. with salesforce.com

Kyle BrownDirectory of Sales@dfsoftwareinc

6 yrs exp. with salesforce.com

Agenda

• What is Change Management?

• Why do we need Change Management?

• Change Management Practices

• Using SnapShot for Change Management - Demo

• Q & A

• Process of managing Org enhancements to ensure an orderly release process

Change by design, not by chaos!

Change Management

• Ensure optimal execution of releases through a codified process minimize customer frustration resulting from change and eliminate downtime.

• Lifecycle Management continually manage requirements, enhancement projects and deployed

changes

• Org health optimize usability, untangle complex orgs for maintainability, and eliminate

bloat

• Governance Control & track: who, what, when and audit results Document change for compliance

Avoid expensive rollbacks!

Why do we need Change Management?

• Backup, backup, backup• Document current state, expected changes• Gain buy-in/ approval before applying change• Explain and Train before change occurs• Have the ability to track and verify changes• Have an exit strategy (roll back or alternate

implementation)

Change Management Practices

Process Guidance for Change and Release Management

Topics of Discussion

• Managing change on-demand• Principles of on-demand change management• Maintaining a quality implementation• Questions & feedback

Change ManagementDefined

• Change Management is the process by which your organization identifies, prioritizes, assigns, executes and communicates change

• In a Salesforce deployment this could result from:– Organizational change– Business process changes– Addition or subtraction of processes– Modeling modifications– Salesforce release of new features and capabilities– Introduction of new custom applications or integrations

Change Management A process of continuous evolution

Initiate/Plan•Identify key Salesforce capabilities required

•Develop a roadmap to implement

•Tie capabilities to program objectives

Continuously analyze your current state, collect User feedback and implement change when appropriate

Operationalize• Build, configure and

deploy application• Manage organizational

change (release mgmt, training, etc)

• Drive adoption of new features

VisionStrategy

Objectives

Initiate/Plan

Vision & Strategy • Establish program vision• Define strategy to

achieve• Develop objectives to

ensure progress

Validate• Audit Salesforce data• Monitor performance

metrics• Use results to drive

behavior or process change within the organization where appropriate

Valid

atio

n

Valid

ate

Opera

tionalize

Reports Dashboards List View Management Documentation Management User Administration Solution Management Communication Templates Email Templates

Business Responsibilities

Daily Changes

IT Responsibilities

Monthly Changes

Minor Release: Simple configuration changes that do not impact day to day business or require training.

As Required (Target Monthly)

Major Release: New Initiatives and other changes that require training or testing.

Dates determined by Steering Committee(Target Quarterly)

On-Demand Development Methodology A more flexible approach

Release Definitions

Release Type Activities Examples Level Of Effort

Immediate Release • Small changes that can be implemented in a short time span and directly in the production environment as needed

• Changes can be configured, tested and deployed with minimal impact within a single business unit

• DOES NOT HAVE TO GO THROUGH CHANGE CONTROL PROCESS

• New dashboards and reports

• Field positioning

• New related lists (existing objects)

• New roles

• Data Loads

• Territory Alignments

LOW

• No additional training required

• None or minimal impact to integration

• Potential candidate for Business Administrators

Minor (Monthly) Release

• Medium level changes that can be implemented with minor impact to the production environment

• Changes can be configured, tested and deployed with minor impact to one business unit

• New Fields

• New page layouts

• New custom Objects

• New org or sub-org in role or territory hierarchy

MEDIUM

• < 1 day of additional training required

• < 1 week of configuration development

• IT involvement

Major Release • Large changes that have major impacts to the business or environment

• Changes requiring a significant interface update, data migration and/or integration impact

• Major releases should be tracked by a standard naming convention for items such as: Role Hierarchy, Profiles, Page Layouts, Record Types, Sales and Support Processes, sControls

• Items that do not need to follow naming convention: Fields, Custom Objects, Reports, Dashboards

• New AppExchange app

• Process-impacting configuration changes

• Data migration impact

• Integration changes

• Impacts to multiple business units

HIGH

• 1 day of additional training required

• > 1 week of configuration development

• > 1 week of integration development

• IT lead

For consistent implementation and support, investment requests should be categorized as immediate, minor or major based on level of effort

Change Management Process FlowExample

SF

DC

Use

rS

FD

C A

dm

inC

han

ge

Mg

mt

Co

mm

itte

eIT

Submits change request

Reviews request

Approved?Determines

release timeframe

Analyzesrequest andtimeframe

IT required?

Configuresfeature/

functionality

Sandbox Environment

Sandbox required?

Configuresfeature/

functionality

Production Environment

Notifies CMMrequest

completedConducts

Testing(end-user & IT)

Moves changesto productionenvironment

Communicateschanges toend-users

User notified

Principles of Change ManagementManaging the process

Fully-replicated

Configure/develop and deploy using Sandbox

Communicate to end-Users about new or changed functionality

Collect ideas and requests from Users

Analyze and prioritize requests

1 2

34

User Feedback & RequestsSuggestions on managing enhancement requests

• Implement Salesforce Ideas or Use ChatterEngage all your

communities online

Bubble the best ideas to the top

Spark conversations around ideas

Use Salesforce CasesUse record types to

differentiate case types

Report on the requests received

Collect required information on the

record


Fully-replicated





1 2

34

Prioritizing RequestsDetermining what’s important

• An oversight or steering committee should be established to review, analyze and prioritize change requests. The committee should be comprised of members of the:

– Administration team

– Executive Sponsor

– Cross-functional business leads

• The committee should meet on a regular basis (e.g. monthly or quarterly) to discuss the change requests received including review current metrics:

– Adoption

– Usage

– Performance


Fully-replicated





1 2

34

Managing Configuration ChangesBest Practices

Development

TestingTraining

Refreshable Sandbox EnvironmentThe process

Source Control

One-Click RefreshRefresh sandboxes

Parallel development in config only dev orgs

User testing in full UAT sandbox Updated production configuration

CVS

Start

Implementing Change RequestsForce.com configuration/code migration tools

Instantly Set Up Dev Environments

Everything You Need to Build Apps

Easy to Collaborate on Projects

Eclipse Force.com IDE

Force.com Code Share

Force.com Sandbox

Easy Access to Codeand Schema

Metadata API

Force.com Migration Tool Guide @ http://wiki.apexdevnet.com/index.php/Migration_Tool

Migrating ChangesMoving data from Sandbox to Production – Force.com tools

Multiple Sandbox Environments

Production Deployment

Test

Develop

Train

Version Control

IDE

CVS

Migrating ChangesMoving data from Sandbox to Production – partner tool

Save snapshots of configuration– Metadata read from WSDL

– Written to local XML files

– No user data read/stored, only metadata

Benefit: track and document org changes

Compare side-by-side – Multiple snapshots – 2 or more

– See similarities, differences, both

– Evaluate changes over time

– View configuration of entirely different orgs

– Dissect changes in user privileges – object permissions, security settings, field visibility

Controlling ChangeMitigating risk when introducing change

Before migrating any data changes from Sandbox to production you should always make a back-up copy of your production organization data

– Data back-ups: Setup | Data Management | Data Export

– Data exports can be run immediately or scheduled

– Use the Data Loader to restore the data to the previous state

– Appropriate for territory changes, assignment changes (i.e. account or case transfers), etc.

Copies of your configuration can be made using tools such as Snapshot

Control administrative access to your org

– Allow only a certain number of users full access to make configuration and data changes

– Implement an oversight committee to review/approve changes before they are made

– “Flip” the profile for Users if necessary to toggle between admin and standard user privileges – use custom profiles to define specific parameters for what a User can do without full fledged Admin access

Typical compliance requirements for change management are:

• Changes are appropriately tested and validated

• Only approved changes are deployed into production

• Records are maintained to indicate the successful test, validation and approval of the change prior to deployment

Test

Develop

Test and validate changes Review and approve the change Deploy into production

Records of testing and validation results

Records of approval from appropriate

approval authority

Records of changes deployed into

production

Typical compliance documentation requirements

Typical change management process

Maintaining Compliance(CobIT, ITIL, International Organization of Standardization ISO standards)


Fully-replicated





1 2

34

Communication Strategy Best practice – Assessing your organization’s needs

• A comprehensive communication strategy:– Is targeted training for specific groups or roles– Assesses needs of each audience and is based on functional, cultural or

geographical needs– Allows users to prepare before hand (e.g., web based tutorials, etc.)– Provides formal and informal training programs for continuous improvement– Utilizes the right type of training/communication tool for the size and scope of

the release

• Suggested training and communication tools:– Class room training– Web-based training/recordings– Chatter posts and groups, e.g., Tips & Tricks– Home page Messages & Alerts

SnapShot for Change and Release Management

•Code free approach•Schema studio for bulk editing•Automated push•Timestamp backups•Data dictionary (with relationships)•Comparison Reports •Governance•Change logs

Design, Promote, Monitor

SnapShot Change and Release Management

DEMO

SnapShot for Change and Release Management

Question and Answer

Q&A

Question Answer

How do you find complete list of accounts without activities (could be case, could be attachment, could be activity, could be case)

Create multiple reports, export to excel and compare. If just wanting activities (object) use “Last Activity” (Date) field and run straight activity report where “Last Activity” is blank. Cross object workflow might help track this during the future to create “Last Date Touched”

On Professional Edition – How should we manage change without sandbox?

Very carefully

Restrict visibility of other reps opportunities (see everything on their records, fewer on records owned by others (contract end dates, size of customer, etc)

Create duplicate fields (not best practice), use page layouts (doesn’t address reporting issue or searches)

Dallas Salesforce User Group - January 2012 Meeting: Release Management

Technology

Transcript of Dallas Salesforce User Group - January 2012 Meeting: Release Management