Download Best Practice

935 views
806 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
935
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Our agenda for today is to discuss: How to manage change in an on-demand environment – it is a bit different than a traditional client server type of environment Principles of on-demand change management – these are key things to keep in mind when evaluating and preparing to release new functionality in Salesforce How to maintain a quality implementation – this is an iterative process that requires constant evaluation and scrutiny We’ll have time at the end for Q&A but please feel free to stop me along the way and ask any questions you may have. I will be presenting a lot of material to you, but I’d like for this to be as interactive as possible as well.
  • Let’s start out be ensuring that we’re aligned on the definition of change management. Change management is the process by which your organization identifies, prioritizes, assigns, executes and communicates change. A good change management strategy can be used to manage any type of change within an organization; not just software development. Our focus here though is obviously managing change within a Salesforce environment and how that is similar to but different than your traditional client/server environment. Many factors can drive the need for change in Salesforce such as: Organizational restructuring – this can affect the role hierarchy, sharing and assignment rules Changes to your business process – for example if you introduce a new approval process for discounting, you’ll want to enable that process in Salesforce We traditionally have 3-releases per year that introduce new features and functionality to our customers. Through your change management process, you’ll want to evaluate which features to enable or capitalize on for your deployment And finally, if you want to integrate a new system or download an application from the AppExchange for instance, you’ll want and need to have an effective process in place to manage that change within the organization ?? Does your organization follow a defined methodology for change management?
  • A well defined Salesforce program, or any application program, is really about continuous improvement. It starts with a well-defined Vision and Strategy. This identifies for the organization the overall goals for the program. The proverbial, “light at the end of the tunnel” per se in terms of identifying the goal you are trying to achieve. Once you’ve established your Vision, you want to continually initiate and plan various projects that support your Vision. Salesforce does some of this for you with our feature releases; however, it’s important that you too are collaborating with your users and executives and looking for new applications to build or deploy or functionality to introduce that will continually improve the user experience and help drive adoption. You obviously operationalize those key functional components and then you have in place mechanisms by which you can continually validate your results and course correct if and when necessary. ?? Does your organization have a stated Vision and Strategy for Salesforce that you are aligned towards in focusing your resources and efforts?
  • It is critical within any organization to take advantage of the web services model by enabling the business to own some of the core configuration responsibilities while at the same time keeping key control over the environment within IT. Some business however, like to maintain control within one division or another. Should you decide to use the hybrid approach depicted here with the business owning some responsibility and IT others, it will be important to clearly designate the roles/responsibilities of each organization and ensure there is cross-functional collaboration between the teams. We depict here the types of changes that the business can typically manage and those that IT would typically manage. IT typically takes on the more complex tasks such as integrations, coding, and such. ?? Which group will be managing/administering the Salesforce application?
  • This table depicts the different types of releases that can occur within Salesforce and the activities associated with each. For example, you may have what is referred to here as “immediate releases.” These are typically small, low complexity changes that can occur immediately in production and do not require change control oversight. Examples would be the creation of new reports/dashboards, addition of new custom fields that only impact one business unit, i.e. record type, adding new views, field repositioning, etc. These items can be communicated to users via email, alerts/messages on the home page, or other mass communication tools. Another type of release is a “minor release.” These are more complex than the immediate release candidates; however, have only minor impacts to the business. It is typically recommended that these types of changes; as well as, the major release change we’ll discuss next, do utilize Sandbox to configure and test. Minor releases should be scheduled, i.e. bi-weekly or monthly as well. Users should receive a more formal type of notification such as a web training session, tip sheet or something along those lines to notify them of the change. Examples of minor release items include the introduction of new page layouts, changes to territories or account assignment, new custom object changes, work flow or approval process introduction and things like that. Finally, you may have what is called a “major release.” These are significantly larger and more complex in scope, such as the introduction of a new Appexchange application, a new custom application, data migration, integration changes or additions or things like this. These are obviously higher impact so the users need more focused training such as a web session or class room session if appropriate. You should treat your major releases like a project and in order to ensure that all the appropriate tasks are assigned and addressed with more extensive testing such as regression or UAT.
  • This is an example of a very basic and simple change management process that an organization may utilize. Every organization’s change management process may be unique based on the tools used internally, how release cycles are defined and such but it is important to demonstrate the necessity of a well documented and communicated change management process. This will help your Users understand how enhancement requests are submitted and ultimately implemented; thereby, increasing visibility to and engagement with your Users throughout the process. This example assumes that the organization has a governance model in place that requires the review/approval of a Change Management Committee, aka: Executive Steering Committee or a Center of Excellence, that is responsible for reviewing and approving all changes made to the Salesforce.com production environment prior to the changes being implemented/deployed. This is an especially important step for organizations that are required to adhere to various types of compliance regulations. Also, this example assumes that IT involvement is warranted as part of the overall change management process. Depending on the nature of the request, IT may not have to be involved, i.e. if the enhancement can be configured by the SFDC Admin directly.
  • Now we are going to get into the 4-major principles of change management. We’ll review principles 1, 2 and 4 at a very high level and spend a bit more time diving into principle 3.
  • The first principle is to collect ideas and requests from your Users. You obviously have to have a mechanism in place for your users to submit their feedback and requests for consideration. Salesforce offers two best practice tools that we recommend for this purpose: Salesforce Ideas – in your org today, you have access to configure and deploy Salesforce Ideas to your internal users. You can configure a specific category of ideas around “Enhancement Requests” for example and have your users input their requests and ideas into the Ideas module. Other users can go in and review ideas, vote on them and you can use this as a means to have your users drive the priority of certain requests. Are you familiar with the Salesforce IdeaExchange? If not, this is a forum for Salesforce users to log their ideas directly to our Product Management team for consideration in a future release. PMs will comment on ideas, other users comment and vote on them and our PM team uses this as one of the many tools to determine which items will be in an upcoming release cycle. It’s a great way to get your users involved and engaged in Salesforce and feel they are part of the process with a ‘voice’ per se. Another way to collect user feedback is through the use of the Case object. It is recommended that, if you use Cases to also track external customer issues, that you create a Case record type for internal enhancement requests. You can collect all of the required information you need to appropriately evaluate the request and also use the built in reports and dashboards to monitor the number, type, frequency of, release schedule, etc. of specific requests. Qualcomm uses the Case object for this purpose and it’s very useful for them from an analytics perspective.
  • Now we are going to get into the 4-major principles of change management. We’ll review principles 1, 2 and 4 at a very high level and spend a bit more time diving into principle 3.
  • The change control or oversight committee is a cross-functional team that meets regularly to discuss and schedule more complex enhancement requests. The Executive Sponsor of the org should definitely be part of the process; as well as, members representing both the administration and cross-functional business units that utilize Salesforce. This is important because you want to ensure that for changes that impact the entire organization, i.e. the enablement of a global setting such as tags, you have cross-functional agreement (or at least awareness) of the change and that the teams discuss impacts to their business unit or processes. In addition to reviewing, prioritizing, scheduling and approving requests, the change control/oversight committee should be responsible for monitoring overall org usage, evaluating key metrics, and developing tactics to drive and maintain effective user adoption.
  • Now we are going to get into the 4-major principles of change management. We’ll review principles 1, 2 and 4 at a very high level and spend a bit more time diving into principle 3.
  • Force.com Sandbox combines the best of both worlds: you get a separate test environment plus all the benefits that the on-demand model provides. You can refresh your Sandbox environment, every 30-days, with a single click in order to keep your production environment and your development and test environment in synch. Definitely as a best practice, Salesforce recommends that you build more complex types of configuration changes in Sandbox and test them fully before migrating those changes to production. Items you should consider in Sandbox are: Work-flow and approval processes Integration changes Role hierarchy changes Sharing rule changes or additions Territory changes Apex code or Visualforce enhancements Building of new custom apps
  • The process to refresh your production environment to Sandbox is pretty simple. First, you access the Sandbox through the Set-up menu under Data Management | Sandbox. You must be in the production org to initiate the refresh. If your environment is available to be refreshed, you can select to refresh. This process may take several minutes. Requests to refresh Sandbox are queued and you’ll receive a notification when the refresh is complete. Once you have refreshed your Sandbox environment, you can make your configuration updates in Sandbox. You can then use Sandbox as your unit testing grounds to validate the changes and conduct regression testing. After unit testing is complete, you can invite your Users to log into Sandbox and conduct UAT. This is a great place for user testing because you have the most up to date configuration; as well as, data available for the users to work from. After all testing is complete, you can use the migration tools that are provided by force.com to migrate the changes – or you can migrate some of them manually if the change is not part of the Metadata API (which we’ll talk about next) or is simple enough that you don’t need a specific tool to help migrate.
  • Force.com provides a complete set of developer tools for all of your application development and customization needs. This is all made possible by our metadata APIs which provide programmatic access to the metadata that defines both your custom apps and the customizations your organization has made to packaged applications. On the next slide, I’ll show you what is available to migrate using the Metadata API. Unfortunately, currently not all changes can be migrated using the Metadata API but enhancements are forthcoming. As well, it is our eventual goal to have one click migration from Sandbox to production available to customers. We’ve talked about the benefits of Sandbox. Sandbox allows you to instantly deploy multiple environments to support all of your development, test, staging and training environment requirements. The Eclipse force.com IDE delivers a full integrated development environment that your developers can use to interact with custom applications and app-customizations at the code-level. Additionally, you use the IDE to manage the process of migrating changes, customizations, integrations and whole applications between your environments. Plus with Force.com code share you can easily integrate with source code control systems and collaborate with other teams of developers working on common projects. Code Share lets developers store the definitions of their Force.com applications in source control, and deploy those applications in their Developer Edition, Sandbox or production environments. It is important to note that both the force.com IDE and code share are currently in developer preview. You can locate more in-depth information on the developer.salesforce.com website.
  • Here is a list of all of the items that are accessible using the Metadata API. Using the Force.com IDE, the Metadata Ant task, or an AppExchange app like Dreamfactory Snapshot will help you more quickly move configuration changes between your environments.
  • Here is how all the pieces come together. The IDE is at the center controlling the movement of code between environments and the source control system. The Force.com IDE can Integrate with most Version control management systems including Subversion, CSV, Perforce and Google Code. If you want or need more detailed information on these tools, let’s discuss setting up a more in-depth technical discussion with one of our technical resources that can walk you through how to effectively utilize these tools.
  • Snapshot is an Appexchange application published by Dreamfactory that allows you to track, manage and promote changes to object, field, profile and other “metadata” customizations inside Salesforce. You can also track the changes using Snapshot so you can do a side-by-side comparison of the configuration before and after the change. This is helpful too in troubleshooting. Further, you can roll changes between the environments which obviously makes it easier for you to manage and track the changes. If you’re interested in a tool like Snapshot, let me know and I can coordinate a meeting or demo with the vendor and help facilitate the evaluation process.
  • Sometimes, things may not work out the way you planned or expected so it’s important that you have control processes in place to restore your current state as quickly as possible. Relative to data migration, it is always a best practice to export your current Salesforce data before importing, updating or deleting records in Salesforce. You can perform data exports whenever necessary. We typically recommend that customers back up their data at minimum on a monthly basis but more often depending on the complexity of your org and the types of changes you’ll be making. You can use tools such as Snapshot that we discussed before to capture current configuration state. You should always control who in your organization has access to administer the tool. Make sure that the right individuals with the correct level of oversight are in place so you can control and mitigate configuration issues. It is typical for organizations to designate “one time” or immediate access to allow configuration changes. They flip the profile for the user to Sys Admin for a period and then change it back when the changes are made. Organizations such as Kaplan Financial do this currently.
  • In today’s highly regulated environment, many organizations are required to comply with various regulatory standards. Maintaining compliance in an on-demand, multi-tenant environment such as Salesforce.com is really no different than standard IT compliance processes that your organization may have in place. First, it’s important that all changes are appropriately tested and validated. This can be accomplished through system test and/or user testing. Secondly, only approved changes should be deployed to production. Typically this means that the system manager or owner is responsible for approving the changes before deploying them to production. Lastly, records of the successful testing, validation and approval should be maintained and kept on file to record that the appropriate steps were followed prior to introducing the change in production. You can use internal ticketing applications to record and manage the process or use the Salesforce application (i.e. create a custom object and business process) to manage your change control process.
  • Now we are going to get into the 4-major principles of change management. We’ll review principles 1, 2 and 4 at a very high level and spend a bit more time diving into principle 3.
  • It is important that you have a training strategy that includes both initial/new user and on-going training to support the evolution of your usage as you grow. The training should support multiple groups and different roles as their needs are different . As well as their learning styles might be different – think of training a Sales Rep versus training a technical consultant. Lastly, you should capitalize on various mediums to deliver training or information to the end-users such as in class training, web meetings, newsletters, tips & trick notifications or using home page messages and alerts. I have some HTML that you can use to put a scrolling message across the top of your home page if you’re interested in using something like that to configure custom messages that really stand out for the user. Customers like Qualcomm and Avery Dennison use these messages to notify users of upcoming Salesforce outages, new field or feature information, provide links to other sites, etc.
  • There are many parts to managing an effective and quality implementation of your Users. Like many aspects of Salesforce, this should be an on-going and iterative process of analysis of your current and future states. You should continually evaluate the new functionality that Salesforce releases each year to identify opportunities for improvement or feature requests that may be useful to your user base. Capitalize on the ease of use of the point-n-click administration console to really help you expand the power of your Salesforce deployment. Use a tool such as the Capabilities Value Map to identify new functional areas of your business or core processes that you can enable in Salesforce. Encourage your users to think about what new features or capabilities would be most useful and high value to them. Be relentless about data quality. This single piece can profoundly impact the quality of your Salesforce instance and nothing will decrease the value of your Salesforce program more than to have users that don’t believe in the data or how it’s being used. Salesforce and our partners continue to rapidly innovate and introduce new tools for you to customize your application. Either through the use of Visualforce, Apex, or partner applications available in the AppExchange, you have a powerful tool set at your fingertips to innovate and take your Salesforce program to new heights. Security is a fundamental and real aspect of your deployment. Ensure that you are using all of the appropriate tools such as session time-outs, IP range restrictions, password policies and other available tools to protect and secure your important Salesforce data.
  • Download Best Practice

    1. 1. Salesforce Change Management Best Practices <CSM Name> <Date>
    2. 2. Salesforce Change Management <ul><li>Business Driver </li></ul><ul><li>Best Practice Overview </li></ul><ul><li>Topics of Discussion </li></ul><ul><ul><li>Managing change on-demand </li></ul></ul><ul><ul><li>Principles of on-demand change management </li></ul></ul><ul><ul><li>Maintaining a quality implementation </li></ul></ul><ul><li>Additional Information </li></ul>
    3. 3. Business Driver <ul><li>Managing change in an on-demand environment is similar but different than in a traditional IT client-server environment. It is important to understand the key concepts and best practices around managing change within salesforce.com in order to effectively and efficiently manage your organization’s application. </li></ul>
    4. 4. Best Practice Overview <ul><li>Every successful implementation of salesforce.com should have a well-defined change management strategy in place. This presentation outlines the key aspects of managing change in an on-demand environment. </li></ul>
    5. 5. Salesforce Change Management
    6. 6. Topics of Discussion <ul><li>Managing change on-demand </li></ul><ul><li>Principles of on-demand change management </li></ul><ul><li>Maintaining a quality implementation </li></ul><ul><li>Questions & feedback </li></ul>
    7. 7. Change Management Defined <ul><li>Change Management is the process by which your organization identifies, prioritizes, assigns, executes and communicates change </li></ul><ul><li>In a Salesforce deployment this could result from: </li></ul><ul><ul><li>Organizational change </li></ul></ul><ul><ul><li>Business process changes </li></ul></ul><ul><ul><li>Addition or subtraction of processes </li></ul></ul><ul><ul><li>Modeling modifications </li></ul></ul><ul><ul><li>Salesforce release of new features and capabilities </li></ul></ul><ul><ul><li>Introduction of new custom applications or integrations </li></ul></ul>
    8. 8. Change Management A process of continuous evolution <ul><li>Initiate/Plan </li></ul><ul><li>Identify key Salesforce capabilities required </li></ul><ul><li>Develop a roadmap to implement </li></ul><ul><li>Tie capabilities to program objectives </li></ul>Continuously analyze your current state, collect User feedback and implement change when appropriate <ul><li>Operationalize </li></ul><ul><li>Build, configure and deploy application </li></ul><ul><li>Manage organizational change (release mgmt, training, etc) </li></ul><ul><li>Drive adoption of new features </li></ul>Vision Strategy Objectives Initiate/Plan <ul><li>Vision & Strategy </li></ul><ul><li>Establish program vision </li></ul><ul><li>Define strategy to achieve </li></ul><ul><li>Develop objectives to ensure progress </li></ul><ul><li>Validate </li></ul><ul><li>Audit Salesforce data </li></ul><ul><li>Monitor performance metrics </li></ul><ul><li>Use results to drive behavior or process change within the organization where appropriate </li></ul>Validation Validate Operationalize
    9. 9. <ul><li>Reports </li></ul><ul><li>Dashboards </li></ul><ul><li>List View Management </li></ul><ul><li>Documentation Management </li></ul><ul><li>User Administration </li></ul><ul><li>Solution Management </li></ul><ul><li>Communication Templates </li></ul><ul><li>Email Templates </li></ul><ul><li>Minor Release : Simple configuration changes that do not impact day to day business or require training. </li></ul><ul><li>As Required (Target Monthly) </li></ul><ul><li>Major Release : New Initiatives and other changes that require training or testing. </li></ul><ul><li>Dates determined by Steering Committee </li></ul><ul><li>(Target Quarterly) </li></ul>On-Demand Development Methodology A more flexible approach Business Responsibilities Daily Changes IT Responsibilities Monthly Changes
    10. 10. Release Definitions For consistent implementation and support, investment requests should be categorized as immediate, minor or major based on level of effort Release Type Activities Examples Level Of Effort Immediate Release <ul><li>Small changes that can be implemented in a short time span and directly in the production environment as needed </li></ul><ul><li>Changes can be configured, tested and deployed with minimal impact within a single business unit </li></ul><ul><li>DOES NOT HAVE TO GO THROUGH CHANGE CONTROL PROCESS </li></ul><ul><li>New dashboards and reports </li></ul><ul><li>Field positioning </li></ul><ul><li>New related lists (existing objects) </li></ul><ul><li>New roles </li></ul><ul><li>Data Loads </li></ul><ul><li>Territory Alignments </li></ul><ul><li>LOW </li></ul><ul><li>No additional training required </li></ul><ul><li>None or minimal impact to integration </li></ul><ul><li>Potential candidate for Business Administrators </li></ul>Minor (Monthly) Release <ul><li>Medium level changes that can be implemented with minor impact to the production environment </li></ul><ul><li>Changes can be configured, tested and deployed with minor impact to one business unit </li></ul><ul><li>New Fields </li></ul><ul><li>New page layouts </li></ul><ul><li>New custom Objects </li></ul><ul><li>New org or sub-org in role or territory hierarchy </li></ul><ul><li>MEDIUM </li></ul><ul><li>< 1 day of additional training required </li></ul><ul><li>< 1 week of configuration development </li></ul><ul><li>IT involvement </li></ul>Major Release <ul><li>Large changes that have major impacts to the business or environment </li></ul><ul><li>Changes requiring a significant interface update, data migration and/or integration impact </li></ul><ul><li>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 </li></ul><ul><li>Items that do not need to follow naming convention: Fields, Custom Objects, Reports, Dashboards </li></ul><ul><li>New AppExchange app </li></ul><ul><li>Process-impacting configuration changes </li></ul><ul><li>Data migration impact </li></ul><ul><li>Integration changes </li></ul><ul><li>Impacts to multiple business units </li></ul><ul><li>HIGH </li></ul><ul><li>1 day of additional training required </li></ul><ul><li>> 1 week of configuration development </li></ul><ul><li>> 1 week of integration development </li></ul><ul><li>IT lead </li></ul>
    11. 11. Change Management Process Flow Example SFDC Admin IT Submits change request Reviews request Approved? Determines release timeframe Analyzes request and timeframe IT required? Configures feature/ functionality Sandbox required? Configures feature/ functionality Notifies CMM request completed Conducts Testing (end-user & IT) Moves changes to production environment Communicates changes to end-users User notified SFDC User Change Mgmt Committee Sandbox Environment Production Environment
    12. 12. Principles of Change Management Managing the process 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 3 4 Fully-replicated
    13. 13. User Feedback & Requests Suggestions on managing enhancement requests <ul><li>Implement Salesforce Ideas </li></ul><ul><li>Use Salesforce Cases </li></ul>Engage all your communities online Bubble the best ideas to the top Spark conversations around ideas Use record types to differentiate case types Report on the requests received Collect required information on the record
    14. 14. Principles of Change Management Managing the process 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 3 4 Fully-replicated
    15. 15. Prioritizing Requests Determining what’s important <ul><li>An oversight committee should be established to review, analyze and prioritize change requests. The committee should be comprised of members of the: </li></ul><ul><ul><li>Administration team </li></ul></ul><ul><ul><li>Executive Sponsor </li></ul></ul><ul><ul><li>Cross-functional business leads </li></ul></ul><ul><li>The committee should meet on a regular basis (e.g. monthly or quarterly) to discuss the change requests received including review current metrics: </li></ul><ul><ul><li>Adoption </li></ul></ul><ul><ul><li>Usage </li></ul></ul><ul><ul><li>Performance </li></ul></ul>
    16. 16. Principles of Change Management Managing the process 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 3 4 Fully-replicated
    17. 17. Managing Configuration Changes Best Practices Development Testing Training
    18. 18. Refreshable Sandbox Environment The process Source Control Refresh sandboxes Parallel development in config only dev orgs User testing in full UAT sandbox Updated production configuration Start One-Click Refresh CVS
    19. 19. Implementing Change Requests Force.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 Code and Schema Metadata API Force.com Migration Tool Guide @ http://wiki.apexdevnet.com/index.php/Migration_Tool
    20. 20. Using the Metadata API What is available? <ul><li>Custom fields </li></ul><ul><li>Custom objects </li></ul><ul><li>Apex classes </li></ul><ul><li>Apex triggers </li></ul><ul><li>Apex components </li></ul><ul><li>Visualforce pages </li></ul><ul><li>S-controls </li></ul><ul><li>Record Types </li></ul><ul><li>Profiles </li></ul><ul><li>Field level security </li></ul><ul><li>Custom applications (tabsets) </li></ul><ul><li>Custom tabs </li></ul><ul><li>Documents </li></ul><ul><li>Folders </li></ul><ul><li>Package </li></ul><ul><li>Weblink </li></ul><ul><li>Email template </li></ul><ul><li>Letterhead </li></ul><ul><li>Picklist/Record Type map </li></ul><ul><li>Custom buttons </li></ul><ul><li>Static resources </li></ul><ul><li>Custom links </li></ul><ul><li>Workflows </li></ul><ul><li>Page layouts </li></ul><ul><li>Page layout assignments </li></ul><ul><li>Home page components </li></ul><ul><li>Home page layouts </li></ul><ul><li>Validation rules </li></ul><ul><li>Approval processes </li></ul><ul><li>Custom report types </li></ul><ul><li>Tab and field renaming </li></ul><ul><li>Button overrides </li></ul><ul><li>Field dependencies </li></ul><ul><li>Picklists </li></ul><ul><li>Dashboards </li></ul><ul><li>Reports </li></ul><ul><li>List views </li></ul><ul><li>Queues </li></ul><ul><li>Public groups </li></ul><ul><li>Email attachments </li></ul><ul><li>Tag API New! </li></ul>Other Enhancements to our MetaData API are planned for the future
    21. 21. Migrating Changes Moving data from Sandbox to Production – Force.com tools Multiple Sandbox Environments Production Deployment Version Control IDE Test Develop Train CVS
    22. 22. Migrating Changes Moving data from Sandbox to Production – partner tool <ul><li>Save snapshots of configuration </li></ul><ul><ul><li>Metadata read from WSDL </li></ul></ul><ul><ul><li>Written to local XML files </li></ul></ul><ul><ul><li>No user data read/stored, only metadata </li></ul></ul><ul><li>Benefit: track and document org changes </li></ul><ul><li>Compare side-by-side </li></ul><ul><ul><li>Multiple snapshots – 2 or more </li></ul></ul><ul><ul><li>See similarities, differences, both </li></ul></ul><ul><ul><li>Evaluate changes over time </li></ul></ul><ul><ul><li>View configuration of entirely different orgs </li></ul></ul><ul><ul><li>Dissect changes in user privileges – object permissions, security settings, field visibility </li></ul></ul>
    23. 23. Controlling Change Mitigating risk when introducing change <ul><li>Before migrating any data changes from Sandbox to production you should always make a back-up copy of your production organization data </li></ul><ul><ul><li>Data back-ups: Setup | Data Management | Data Export </li></ul></ul><ul><ul><li>Data exports can be run immediately or scheduled </li></ul></ul><ul><ul><li>Use the Data Loader to restore the data to the previous state </li></ul></ul><ul><ul><li>Appropriate for territory changes, assignment changes (i.e. account or case transfers), etc. </li></ul></ul><ul><li>Copies of your configuration can be made using tools such as Snapshot </li></ul><ul><li>Control administrative access to your org </li></ul><ul><ul><li>Allow only a certain number of users full access to make configuration and data changes </li></ul></ul><ul><ul><li>Implement an oversight committee to review/approve changes before they are made </li></ul></ul><ul><ul><li>“ 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 </li></ul></ul>
    24. 24. <ul><li>Typical compliance requirements for change management are: </li></ul><ul><ul><li>Changes are appropriately tested and validated </li></ul></ul><ul><ul><li>Only approved changes are deployed into production </li></ul></ul><ul><ul><li>Records are maintained to indicate the successful test, validation and approval of the change prior to deployment </li></ul></ul>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) Test Develop Test and validate changes
    25. 25. Principles of Change Management Managing the process 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 3 4 Fully-replicated
    26. 26. Communication Strategy Best practice – Assessing your organization’s needs <ul><li>A comprehensive communication strategy: </li></ul><ul><ul><li>Is targeted training for specific groups or roles </li></ul></ul><ul><ul><li>Assesses needs of each audience and is based on functional, cultural or geographical needs </li></ul></ul><ul><ul><li>Allows users to prepare before hand (e.g., web based tutorials, etc.) </li></ul></ul><ul><ul><li>Provides formal and informal training programs for continuous improvement </li></ul></ul><ul><ul><li>Utilizes the right type of training/communication tool for the size and scope of the release </li></ul></ul><ul><li>Suggested training and communication tools: </li></ul><ul><ul><li>Class room training </li></ul></ul><ul><ul><li>Web-based training/recordings </li></ul></ul><ul><ul><li>Newsletter communications/Tips & Tricks </li></ul></ul><ul><ul><li>Home page Messages & Alerts </li></ul></ul>
    27. 27. Maintaining a Quality Implementation Making the pieces work together Configuration Data Quality Capabilities App Extension/Integration S E C U R I T Y
    28. 28. Questions & Feedback
    29. 29. Additional Information
    30. 30. Sandbox Definitions & Availability Type Features Enterprise Edition Unlimited Edition Full Sandbox <ul><li>Full copy of configuration and production data </li></ul><ul><li>Storage limitation based on that of production org </li></ul>0 Included up to 3 Sandboxes allowed 1 Included Configuration Only Sandbox 2) <ul><li>Full copy of configuration only (no data copied) </li></ul><ul><li>Data copy is responsibility of the customer (500 MB limit) </li></ul>0 Included up to 5 Sandboxes allowed 5 Included Developer Sandbox <ul><li>Full copy of configuration only (no data copied) </li></ul><ul><li>10 MB of data limit suitable for testing purposes </li></ul>1 Included 15 Included
    31. 31. Additional Links & References <ul><li>Salesforce.com Community Sandbox Best Practice Posting </li></ul><ul><ul><li>http://www.salesforce.com/community/crm-best-practices/it-professionals/release-management/sandbox-release-management.jsp </li></ul></ul><ul><li>Salesforce.com Community Force.com IDE Information </li></ul><ul><ul><li>http://wiki.apexdevnet.com/index.php/Force.com_IDE </li></ul></ul><ul><li>Force.com Migration Tool </li></ul><ul><ul><li>http://wiki.apexdevnet.com/index.php/Migration_Tool_Guide </li></ul></ul>

    ×