Customer Success with Microsoft Dynamics Sure Step
Chapter 7. Upgrading with Sure Step
In the last chapter, we discussed how quality is embedded in Sure Step during solution delivery as well as when the solution is in operation. We covered quality management in project activities as optimization offerings.
In this chapter, we will cover Sure Step's approach to upgrading Microsoft Dynamics solutions. The following topics will be covered:
· Diagnostic Decision Accelerator Offerings for existing Dynamics customers that begin with the Upgrade Assessment Service to determine the scope of the upgrade
· Determining whether the upgrade approach is that of a Technical Upgrade, or whether additional functionalities are to be delivered as part of a Functional Upgrade
· Delivering the upgrade using the Sure Step Upgrade Project Type
· Implementing additional functionalities to an existing solution
Decision Accelerator Offerings and the Diagnostic phase
In Chapter 3, Solution Envisioning with Sure Step, we introduced the Sure Step Diagnostic phase process and models for a current Microsoft Dynamics customer, both from the customer's due-diligence perspective and from the seller's solution-selling perspective. In this section, we will discuss the process, particularly the Upgrade Assessment Service, in more detail.
We begin by reintroducing the diagram showing the Sure Step Diagnostic phase's flow of activities and Decision Accelerator (DA) Offerings for an existing customer. In Sure Step, an activity is a specific action or step in the flow. An Activity may result in a deliverable output of the step, or it could be a prescribed step in the process that leads to an outcome further down the line. In contrast, a Decision Accelerator Offering is a mini project in itself, and each DA Offering may comprise multiple services, each requiring multiple actions to achieve the stated objective of the offering. You may recall that the flow is very similar to the one for a prospect, with the only difference being Upgrade Assessment Service replaces the Requirements and Process Review Service:
As noted before, the flow for an existing customer also begins with Diagnostic Preparation, similar to that for a prospect. As depicted in the preceding diagram, the typical approach will encompass the following three phases:
Phase 1: Need Determination
· Solution Overview Activity
· Upgrade Assessment Decision Accelerator Service
Phase 2: Alternatives Evaluation
· Fit Gap and Solution Blueprint Decision Accelerator Service
· Architecture Assessment Decision Accelerator Service
· Scoping Assessment Decision Accelerator Service
Phase 3: Risk Evaluation
· Proof of Concept Decision Accelerator Service
· Business Case Decision Accelerator Service
· Proposal Generation Activity
Phase 1 – Need Determination
The Solution Overview Activity is the primary activity in the initial phase and revolves around determining customer interest levels to be upgraded and provides the opportunity to be clear on some basic requirements. Examples of this include:
· Has the customer deployed their Microsoft Dynamics solution in their production environment?
· Has the customer expressed interest in upgrading to a more recent version of Microsoft Dynamics?
· Does a qualified opportunity for an Upgrade Assessment exist?
· Does the customer want to upgrade to a supported version of Microsoft Dynamics?
When interest is established in moving the existing solution to the current version of Microsoft Dynamics, the next step is the Upgrade Assessment Service, which is the key step in this process. Before initiating Upgrade Assessment, the services delivery team should meet with the customer to ascertain and confirm that they are interested in performing the upgrade. Especially where delivery resources are in high demand, this is an important step that sales teams need to carry out before involving delivery resources such as solution architects and senior application consultants. Sales personnel can use resources from the Sure Step Diagnostic Preparation activity to understand and position the current capabilities of the corresponding Microsoft Dynamics solution.
The Upgrade Assessment Decision Service
The Upgrade Assessment Service is the most important step in the process for an existing Microsoft Dynamics customer. The Upgrade Assessment Service is executed by the services delivery team to get an understanding of the existing solution being used by the customer, determine the components that need to be upgraded to the current release of the product, and determine whether any other features need to be enabled as part of the upgrade engagement.
Once a customer's interest in upgrading has been determined, the services delivery team can conduct the Upgrade Assessment Service. The aim of the Upgrade Assessment Service is to identify the complexity of upgrading the existing solution and to highlight areas of feature enhancements, complexities, and risks. The steps performed in the execution of the Upgrade Assessment Service are shown in the following diagram:
The delivery team begins the Upgrade Assessment Service by understanding the overall objectives for the upgrade. Teams can leverage product-specific questionnaires provided in Sure Step for Microsoft Dynamics AX, CRM, GP, NAV, and SL. These questionnaires also include specific sections and questions for interfaces, infrastructure, and so on; therefore, they can also be leveraged through the following steps:
1. One of the important tasks at the outset is to review the upgrade path for Microsoft Dynamics and any associated ISV software to determine whether the upgrade from the customer's existing product version to the targeted version of Microsoft Dynamics is supported. This will have a bearing on how the upgrade can be executed—can you follow a supported upgrade path, or is it pretty much a complete reimplementation of the solution?
2. The next step in executing the Upgrade Assessment Service is to assess the existing solution's configurations and customizations. In this step, the delivery team reviews which features of Microsoft Dynamics have been enabled for the customer, including which ones have been configured to meet the customer's needs and which ones have been customized. This will allow the delivery team to consider the overall objectives for the upgrade and determine which of these configurations and customizations will need to be ported over to the new solution and which ones should be retired. For example, the older version may have necessitated customizations in areas where the solution did not have a corresponding functionality. Or perhaps the solution needed a specific ISV solution to meet a need. If the current product version provides these features as standard functionalities, these customizations or ISV solutions would no longer need to be part of the new solution. Data migration (if required) from previous versions to the new one must be considered as part of this step.
3. The next Upgrade Assessment Service step is to examine custom interfaces for the existing solution. This includes assessing any custom code written to interface the solution with third-party solutions, such as an external database for reporting purposes. This step is followed by reviewing the existing infrastructure and architecture configuration so that the delivery team can understand the hardware components that can be leveraged for the new solution. The delivery team can provide confirmation on whether the existing infrastructure can support the upgrade application, or whether additional infrastructure components may be necessary.
4. The final step of the Upgrade Assessment Service is for the delivery team to complete a detailed analysis of the customer's existing solution and generate a report of their findings. The report, to be presented to the customer for approval, will include the following topics:
· The scope of the upgrade, including a list of functional and technical areas that will be enhanced in the new solution.
· A list of the functional areas of the application categorized to show the expected complexity involved in upgrading them. If there are areas of the existing implementation that will require further examination or additional effort to upgrade them successfully due to the inherent complexity, they must be highlighted.
· Areas of the current solution that could be remapped to new functionalities in the current version of the base Microsoft Dynamics product.
· An overall recommended approach to the upgrade, including alternatives to address any new functionality desired. Dynamics Licensing cost implications must also be considered.
The Upgrade Assessment Service provides the customer with an early identification of issues and risks that could occur during an upgrade so that appropriate mitigating actions can be initiated accordingly. The customer would also get a level of confidence by knowing that an appropriate level of project governance for the upgrade is available as well as that the correct upgrade approach will be undertaken by the delivery team.
In the following sections, we will discuss how the Upgrade Assessment Service becomes the basis for completing the customer's due diligence and sets the stage for a quality upgrade of the customer's solution.
Phase 2 – additional services and when to avail them
After the Upgrade Assessment Service has been executed, the remaining services of DA Offerings may also be needed in the due-diligence process for an existing Microsoft Dynamics customer. In this section, we will discuss the scenarios that may call for the usage of other DA services and which ones would apply to that particular scenario.
From the Upgrade Assessment Service, the delivery team determines the existing business functions and requirements that need to be upgraded to the new release. Using Fit Gap and Solution Blueprint Service, they can then determine and document how these requirements will be ported over. If meeting the requirement is more than just implementing standard features, the approach maybe a re-configuration, custom code rewrite, or workflow setup. Additionally, if new features are required as part of the upgrade, these requirements should also be classified in the Fit Gap worksheet either as a Fit or as a Gap. They should also be further classified as Standard, Configuration, or Workflow as the case may be for Fits and Customization for Gaps.
The Scoping Assessment Service can be used to determine the effort, timeline, and resources needed to execute the upgrade. If it was determined with the Upgrade Assessment Service that a new functionality will be introduced, the delivery team and the customer must also determine the Release plan. We will discuss upgrade approaches and Release planning in more detail in the following section.
The Architecture Assessment Service can be used to determine the new hardware configuration for the upgraded solution. It can also be used to address any performance issues up front through the execution of the Proof of Concept Benchmark suboffering.
With many of the Dynamics products offering cloud-based solutions, either through hosted or self-hosted models, it is important to understand the potential impacts of moving to the cloud for all or part of the implementation. The Fit Gap and Solution Blueprint and the Architecture Assessment should be reflected accordingly. An example of this is the new Dynamics GP 2013 web client. This can be hosted by a partner with Azure or it can be self-hosted. Recent examples show that many businesses are opting to self-host with local financial users choosing the classic client whereas supply chain or remote users are utilizing the web interface.
It is important to note that all the three of the previously discussed Decision Accelerator Services—the Fit Gap and Solution Blueprint, the Architecture Assessment, and the Scoping Assessment—can be executed together with the Upgrade Assessment Service as one engagement for the customer if required. The point of this section is not that each of these offerings needs to be positioned individually for the customer. On the contrary, depending on the scope, the delivery team could easily perform the exercise in tandem. The point of emphasis in this section for the reader is that if you are assessing an upgrade for the customer, you should be able to leverage the templates in each service and combine them as you deem fit for your engagement.
Phase 3 – Risk Evaluation
Lastly, the Proof of Concept Service offering and the Business Case service offering may also apply to an upgrade engagement but typically only for a small subset of customers. Examples include customers who may be using a very old version of the Microsoft Dynamics solution, which means that they pretty much need a reimplementation of the solution with the new version of the product, or customers who need a complex functionality to be enabled as part of the upgrade. In both these cases, the customer may request the delivery team to conduct Proof of Concept Services of the solution prior to embarking on a full upgrade, in which case the Proof of Concept service may be executed. They may also request assistance from the delivery team to assess the return on investment for the upgraded solution, in which case the Business Case may be employed.
Determining the Upgrade approach and release schedule
As noted in the previous section, the customer and the delivery team should work together to select the right approach for the upgrade during the course of upgrade diagnostics. Sure Step recommends the following two approaches to upgrades:
· Technical Upgrade: Use this approach if the upgrade mostly applies to application components, such as executable files, code components, and DLLs. This approach can be used to bring a customized solution to the latest release, provided the application functionality and business workflow stay relatively the same.
· Functional Upgrade: Use this approach if a new application functionality or major changes in the existing business workflows are desired during the course of the upgrade. Additional planning, testing, and rework of the existing solution are inherent in this complex upgrade process and as such more aligned to a Functional Upgrade. Functional Upgrades are typically performed in multiple releases.
The following diagram depicts the two Upgrade approaches and Release schedules:
Depending on the scope of the upgrade, the customer engagement may have one or more delivery Releases. If for example, the customer's solution is on a supported upgrade path, the Technical Upgrade may be delivered in a single Release using the Sure Step Upgrade Project Type. If the new solution requires several new processes to be enabled, the Functional Upgrade may be delivered in two or more Releases. For example, if the customer needs an advanced supply chain functionality such as production scheduling and/or advanced warehousing to be enabled as part of the upgrade, a two-step upgrade is the recommended approach. First complete the Technical Upgrade using the Sure Step Upgrade Project Type to port the existing functionality over to the new product version in Release 1. On completion, add the advanced supply chain functionality using the Rapid, Standard, Agile, or Enterprise project types in Release 2.
As noted earlier, DA Services can be executed individually or in combination, depending on customer engagement. Regardless of how they are executed, it is imperative that the customer and delivery team select the right approach and develop the necessary plans such as Project Plan, Resource Plan, Project Charter, and/or Communication Plan. These documents should form the basis for the upgrade delivery proposal. When the Proposal and Statement of Work (SOW) are approved, it is time to begin the execution of the solution upgrade.
Delivering Upgrade
In the previous section, we discussed how we setup the solution delivery process for the upgrade. We now focus on the delivery of the upgrade itself, using the Sure Step Upgrade Project Type.
We discussed two approaches to upgrading with Sure Step in the previous section: the Technical Upgrade and the Functional Upgrade. The common denominator for both these approaches is the Sure Step Upgrade Project Type – for the Technical Upgrade, this provides the underlying workflow for the only Release; for the Functional Upgrade, this constitutes the workflow for the first Release. A screenshot of the Sure Step Upgrade Project Type is as follows:
As shown in the screenshot, the Sure Step Upgrade Project Type follows the waterfall method with the following five phases: Analysis, Design, Development, Deployment, and Operation. Just as in Standard, Rapid, and Enterprise project types, the activities in these phases are grouped under the nine cross-phase processes (refer to Chapter 5, Implementing with Sure Step, for a review of cross-phase processes). We will discuss some of the important activities in each of the phases of the Upgrade Project Type in the ensuing sections.
The Analysis and Design phases
The Analysis phase builds on the discovery efforts undertaken in the Diagnostic phase with the goal to finalize the requirements (the what) and the Fit Gap analysis (the how) and initiate the data upgrade, while the Design phase is used to finalize and gain approval on the solution design before beginning the development.
As you would expect on typical projects, the upgrade engagement starts with a Project Kickoff. The objective of this activity is to ensure that the team members understand the overall objectives for the upgrade engagement and each other's roles and responsibilities in the journey. Items such as what is the communication plan, who is responsible for keeping the team and the stakeholders in the know, and what will be the vehicle to achieve that, are just some of the important points to get clarified at this juncture.
This is followed by the Solution Overview Activity to provide an introduction of the Microsoft Dynamics solution to those on the team who were not involved in the assessment phase. This sets the stage for the key steps of finalizing the requirements and scope to move to Design activities.
The next two activities, Requirements Finalization and Fit Gap Finalization, are very important, but they also come into question at times. The question is usually regarding why these activities are called out both in the Diagnostic phase and in the Analysis phase. Quite simply, the answer is that depending on how deep the discovery effort was, the work in this phase may mostly entail an affirmation of the scope. But there are some very important conditions attached to it.
· If all the key users were involved in the Diagnostic activities
· If all the requirements were considered in the Diagnostic phase
· If all the questions were answered and issues were resolved during the execution of the Decision Accelerator Offerings
If the answer to any of the points is negative, it is important that these activities are executed and the deliverables finalized in the Analysis phase.
For the Requirements Finalization activity, typically a Requirements workshop is conducted to finalize the Functional Requirements Document (FRD). The FRD should clearly note the existing business functions and requirements that will be upgraded to the new release and also any additional requirements (in other words, a new functionality) to be delivered as part of the upgrade. The Fit Gap Finalization builds on the requirements using the Fit Gap worksheet to determine how these requirements will be delivered—by implementing standard features, configuration or reconfiguration, the workflow setup, or new/rewritten custom code.
Again, depending on the effort that was carried out with the Upgrade Assessment DA, the FRD and Final Fit Gap may be easily accomplished. But both are key documents that must be approved by the customer's business sponsor by the end of the Analysis phase.
Data Upgrade Preparation is another key activity in the Analysis phase. This activity constitutes the start of Data Migration activities, beginning with the identification of existing data sources, including the existing Microsoft Dynamics solution, any ISV solutions, and any interface programs. Also in scope is the identification of additional data sources and how they will be accessed. Additional items for consideration include the state of the source data (amount of data cleansing required, who, how, where, when the data will be cleansed, and so on), any legal requirements for data retention, and strategies for warehousing of data external to the Microsoft Dynamics solution. Depending on the state of the source date, the team may also need to identify whether Extract Transform and Load (ETL) tools may be needed for data cleansing and migration efforts. It should also be determined which parts of data migration will be automated and which, if any, require manual execution.
While the goal of the Analysis phase is to understand the requirements to establish the overall scope for the upgrade engagement, the Design phase is used to define how the technical upgrade will be implemented. Objectives include planning the steps for executing the upgrade and identifying conflicts for upgrading the custom code. It also includes proactively planning for potential post-upgrade issues and reviewing the existing integration and interfaces between Microsoft Dynamics and third-party solutions to determine whether they need to be upgraded to work with the newer version of the Microsoft Dynamics solution. Accordingly, the key Design phase activities include Data Upgrade Checklist for planning and executing the upgrade, Existing Code Review to analyze and identify any conflicts created by customizations to the existing solution, and Existing Integrations and Interfaces Review to determine which existing integrations and interfaces need to be upgraded. If product tools are available to support these activities, links to the corresponding tools are referenced in Sure Step. For example, Microsoft Dynamics AX provides an upgrade checklist utility with the required and optional steps denoted in a sequential manner to provide guidance and assistance during the upgrade process as well as a Compare tool for Microsoft Dynamics AX to help determine and resolve code conflicts for solution customizations. Microsoft Dynamics AX has a unique architecture where the code can be saved in different layers, (such as a USR layer for customer users and a VAR layer for partners). The Compare tool also provides the ability to compare and detect code conflicts while upgrading one layer at a time or simultaneously in all layers.
The completion of the Design phase indicates that all the customer requirements for the solution have been analyzed and the functional and/or technical designs completed to initiate development efforts for the upgrade. A phase review at the end of each phase is recommended for any size of the project but certainly for larger engagements. Besides getting an agreement from the customer on the completion of the phase, it also allows the delivery team to document the lessons learned, outstanding issues and risks, and mitigating actions for them.
The Development, Deployment, and Operation phases
The goal of the Development phase is to set up the application for the upgrade, which may include ISV solutions to complement the standard Microsoft Dynamics product. This phase also encompasses upgrading any customizations, integrations and interfaces, and corresponding data elements. The Deployment phase is the culmination of the efforts of the upgrade delivery, resulting in the transition of the customer to the new solution. The Operation phase encompasses the post Go-Live stabilization of the solution and transition to support.
The key Development phase activities in the Upgrade Project Type include Application & ISV Upgrade, Customization Upgrade, Production Environment Setup, Integration and Interfaces Upgrade, and Data Verification and Benchmarking. Just as with prior phases, the activities may include links to product tools or white papers where applicable, such as Custom Code Best Practices for Microsoft Dynamics CRM. Activities also provide templates such as Test Scripts and Environment Specification documents that can be leveraged by delivery teams as the starting point to document their efforts.
When upgrading ISV solutions, it is important to have completed the Microsoft Dynamics core application upgrade before attempting the ISV upgrade, ensuring all the prerequisites of the ISV solution have been met. Note that as part of the analysis and design, it is feasible that an ISV solution can be broken down into multiple phases of a Technical and Functional Upgrade if there are new enhancements that are required from an existing ISV solution.
While the Development phase represents a large percentage of the efforts of the upgrade engagement, the Deployment phase is where the efforts come to fruition. User Training is a key activity in this phase wherein end users get hands-on training on the new system before they go live. Depending on the size of the organization, training could be executed in groups—typically, the delivery team will train key users or a core set of users who will then act as trainers for the remaining end users. Technical training pertaining to updated technology must also be incorporated at this time; examples include updates to SQL Management or Reporting Services which are often overlooked as "nice to have". This is important to ensure the customer takes full advantage of the new technical improvements available.
Following the completion of user training, the organization can begin User Acceptance Testing (UAT). UAT is a key validation point by the customer organization of the new solution—user acceptance of the solution indicates the customer is ready to go live with the new solution. Sure Step provides several product- and industry-focused UAT script templates that the delivery teams should leverage. These detailed scripts walk the user through the steps for executing a given process or functionality. In many instances, delivery teams have also leveraged the details in these scripts to develop Training guides for the previous activity.
In Enterprise projects, performance testing should also be considered as part of the deployment.
Once this acceptance is obtained, the last activity prior to Go Live is Data Migration to Production, wherein the cleansed data from the existing system are migrated to the new system.
To prepare for this, the production environment setup must take place in parallel with the upgrade activities, thus enabling information from testing to validate the initial assumptions made during the Gather Requirements and Fit-Gap Analysis phases in the architectural design. Key activities include confirmation of hardware, load/stress testing, geographical dispersal of users, integration requirements, redundancy, and security.
After the solution goes live, the project moves to the Operation phase. The key activities in this phase include Transition Solution to Support to transfer the solution from the delivery team to the Support team and Project Closure to finalize and wrap up the project.
Use case – Microsoft Dynamics Upgrade by a nondurable products manufacturer
In this use case, we discuss how a nondurable consumer products manufacturer and distributor approaches a multisite upgrade of their Microsoft Dynamics solution.
The manufacturer was headquartered in the US and had multiple manufacturing and distribution agencies around the world. The organization's HQ was running an older version of Microsoft Dynamics AX, Axapta 3.0, while other manufacturing entities from the acquisition were running different legacy ERP systems. The company decided to not only consolidate its systems to benefit from economies of scale from its IT operations but also enable consistent processes throughout the subsidiaries of the organization.
The company worked with a Gold-Certified Microsoft Partner and went through a thorough Upgrade Assessment and Solution Envisioning processes. From the discovery of these processes, the company realized that it was running a heavily customized version of Axapta at its HQ, which would not only make for a complex upgrade process but was also not a sustainable solution to standardize across multiple entities. At that point, the company decided to alter its overall solution and IT strategy. They began by reviewing the standard functionality in the newest Microsoft Dynamics AX release, Microsoft Dynamics AX 2009, and then considered replacing modifications with the standard functionality wherever feasible, even if it meant changing some of their business processes. The diagnostic exercise, executed jointly by the partner consultants, and the customer's process and technical experts, led to the determination that they could replace about 40 percent of the customized functionality with the standard functionality in Microsoft Dynamics AX 2009.
The organization moved forward on to the solution upgrade delivery with the core objective of minimizing customizations for business processes that were unique to each operation. Because some of the company's business processes were inherently unique, such as dealing with government regulations for a specific product, the organization realized that while they could share best practices for a common solution; they also needed to account for the unique site requirements. Accordingly, the joint customer and partner team decided to leverage both the Upgrade and Implementation project types of the Sure Step methodology for the development and the rollout of the solution across sites.
The following diagram shows the Sure Step approach taken by the joint team.
The team combines guidance and artifacts from the Sure Step Upgrade project type with the Enterprise project type to develop an approach for the rollout of a consistent solution between the headquarters and its subsidiaries. The team began with a planning session that included a group of cross-functional and cross-organization analysts from business and IT functions. They designed a core solution that accounted for the common requirements across the organization, which formed the basis for the Core Build. The Core Build leveraged standard functionalities to the maximum extent and included minor custom code modifications where necessary. The team also developed Site Builds for the HQ and Subs, which accounted for specific requirements at that site. The corresponding builds were then merged for the HQ and Sub Site Rollouts.
The joint team was able to complete the engagement within one year. The company's Vice President of Operations credited the Sure Step methodology for helping to keep the project on track. He quoted, "By using the Sure Step methodology, we were confident in moving from one task to the next. Once everyone left the kickoff meeting, they needed to know exactly what to take care of. The methodology helped us to articulate exactly how we would accomplish each task." The company's IT Director also agreed by saying, "This was not the first time that we've gone through an ERP implementation. But, it was certainly the best implementation that we've ever done, in terms of how smoothly the Go-Live went."
The combined solution provided a streamlined and consistent interface for business users, affording them important timesaving capabilities. The customer saw greater employee productivity as well as gains in shortened quote-to-sales order cycle. They were also able to establish proper reorder points, which gave them better visibility, and in turn improved inventory turns. The company's process experts were also enthusiastic about the reduced complexity and less burdensome processes in areas such as managing the company's pricing structure.
The solution also led to significant cost savings from an IT standpoint in the licensing, infrastructure, and ongoing maintenance aspects. By migrating all of its business groups onto Microsoft Dynamics AX 2009, the organization eliminated its software-licensing costs for other legacy ERP systems, resulting in significant annual savings. In addition, the company substantially reduced its server infrastructure from 110 physical servers to 60 virtual servers running on just five physical servers. The combined solution also allowed the organization to reduce the number of developers needed to a third of their original number.
Finally, Sure Step methodology also enabled the IT department to minimize upgrade costs, which was evident when the organization decided to upgrade to Microsoft Dynamics AX 2009 Service Pack 1. The company's IT Director had this to say about the upgrade process. "Previously, it would take a large team months to roll out an upgrade. But when upgrading to Microsoft Dynamics AX 2009 Service Pack 1, we only needed to spare a few of our staff and they completed it in three weeks."
Summary
In this chapter, we learned the approaches to upgrade existing Microsoft Dynamics to the latest product release, including assessing the existing solution and executing the upgrade.
In the next chapter, we will learn about the Project and Change Management libraries in Sure Step. We will also learn about setting up projects, such as Upgrade projects, online using the SharePoint feature in Sure Step for collaborating effectively with others in the solution delivery team.