Software Change Management Elements of a Software Change Management Strategy. SAP AGS - IT Planning May 2013

Transcription

1 Software Change Management Elements of a Software Change Management Strategy SAP AGS - IT Planning May 2013

2 Elements of a Software Change Management Strategy Introduction

3 Introduction Software Change Management is a key operations process Software Change Management is a key operations process Enterprise change is continuous: Go to market strategies, regulatory compliance, manufacturing innovations and technology upgrades are a few of the drivers that are fueling continual change. Enterprises need to be prepared for continual change to remain competitive and compliant in a consistent cyclic and re-occurring manner. Software Change Management is a key operations process for an SAP system. A good Software Change Management strategy includes the definition of procedures and responsibilities, and the choice of supporting tools and transport landscape. When implemented correctly, Software Change Management will mitigate the risks to production whilst enabling innovation to support the needs of the business SAP AG. All rights reserved. 3

4 Introduction Holistic View on Elements of a Software Change Management Strategy Elements of Software Change Management Strategy Release Management Change Request Management Transport Management Requirements Management Test Management Requirements Design Build Test Deploy Operate Input Channels Prioritization Classification Blueprint Level of Effort Estimate Release Assignment Resource Assignment Develop Unit Test Integration Test Regression Test Performance T. Cutover Test User Acceptance Test Dress Rehearsal Go-Live Monitor Support Continuous Improvement 2012 SAP AG. All rights reserved. 4

5 Introduction IT objectives for Software Change Management IT objectives for Software Change Management Typical IT objectives for Software Change Management are: Quality of service Minimizing failure of changes, service degradation, and unplanned outages Speed of deployment Reducing the time to implement support for a new business requirement or a fix into production systems Reasonable IT cost Minimizing IT cost without compromising quality of service Keeping technology up-to-date Ensuring that infrastructure and software are up-to-date enough to enable innovation and guarantee support from the vendors The importance of the different objectives is different from customer to customer from solution to solution within a customer, based on the individual requirements (criticality of the system), and the amount of changes expected for the solution (new vs. mature solution, small vs. large customer, etc.). So there is no one size fits all for Software Change Management processes and supporting tools and transport landscape SAP AG. All rights reserved. 5

6 Elements of a Software Change Management Strategy Release Management

7 Release Management Motivation Concept of Release Management: Bundling of Changes 2012 SAP AG. All rights reserved. 7

8 Release Management Motivation Motivation: Why should changes be bundled into releases? A release is the collection of software, processes and documentation which is required to implement one or multiple approved changes. Such a release is then treated as single piece when it comes to testing and deployment. A release may contain one or many projects. In a release with multiple projects, all projects must align when the Release enters or exits a quality gate or major milestone. Benefits of managing changes in releases: Clear promise to the business of what goes live when. Increased stability of production because frequency of changes to production is reduced and solid testing for the releases done Lower cost (people and systems) and more simplified testing process using common regression and integration testing for several projects / changes in one run Reduced risk of inconsistencies for example due to "forgotten transports" or sequence violations Reduced administration efforts for transport management as all projects move from one phase to another at a single point in time 2012 SAP AG. All rights reserved. 8

9 Release Management Release Categories Release Categories differ in test effort/duration and therefore in scope/level of changes that can be included in such a release Major Release Minor Rel. Minor Rel. Standard Changes Go Live Cycle Every 3-6 months Every 1-4 weeks Every 1 7 days Change Request Categories included All types of changes including invasive changes Non-invasive changes (+ Re-Import of Emergency Changes) Standard changes only (non invasive, low risk and impact well known) Change Request Priorities included Normal Priority Normal Priority Normal Priority Test Strategy Complete test scope New features + Regressions for core processes (automated tests) Test identified in preapproval. Regressions for core processes (automated tests) Examples New (major) functions, Support / Enhancement Packages, Upgrades Non-critical configuration, medium or low priority incidents Already approved changes e.g. storage locations, currency exchange rates Emergency Changes On Request only Emergency only Emergency only Regressions for core processes (automated tests) Any changes to solve high priority incidents 2012 SAP AG. All rights reserved. 9

10 Release Management Release Categories The test strategies (scope, effort and duration) are different per release category according to the level of changes. Major Release Minor Rel. Minor Rel. Standard Changes Emergency Changes Unit Test Yes, including code inspector and peer reviews Yes (code inspection and peer reviews if possible) Yes (According to standard change process) Scenario Integration Test Yes (important) Yes User Acceptance Test Yes (usually required for sign off) Yes (per correction/ change) Regression Tests Yes (complete regression test) Recommende d at least for core processes Performance / Load Tests Recommende d (e.g. based on outcome of single activity trace) No No No No No No Additional Tests (System, Cutover Tests) Potentially (depending on request) Usually no 2012 SAP AG. All rights reserved. 10

11 Month Release Management Release Calendar (agreed with the Business) Release Calendar After the release categories are defined, the releases are put into a central release calendar. Best Practice is to align the release go live dates across all SAP applications within an environment (e.g. SAP ERP and SAP APO within a region). The release calendar needs to be aligned with the business on freeze periods, downtime scheduling and frequency of shipment of changes. The release calendar should also include cut-of days, CAB meetings and testing periods. Calendar Year Jan Feb Mar Apr May June July Aug Sept Oct Nov Dec Minor Minor Minor Minor Minor Minor Minor Minor Minor Major Major Business requested system freeze Business agreed planned downtimes 2012 SAP AG. All rights reserved. 11

12 Release Management Link of Change Request Management to Release Management Requirements Release Categories Change Requests 1) Break Fixes 2) New requirements 3) Standard changes 4) Business enhancements Project features 1) 2). 3).... x).. Project features 1) 2). 3).... x).. Requirements Review Major Release Minor Rel. Minor Rel. Standard Changes Emergency Changes Non-business-driven Requirements 1) OS/DB Patches 2) DB Reorg 3).. Central categorization and prioritization of requirements Allocation of all change requests (and projects) to release categories based on change categories and prioritization and other well-defined criteria Alignment to a specific releases and Go-Live dates for a change/project 2012 SAP AG. All rights reserved. 12

13 Elements of a Software Change Management Strategy Transport Landscapes

14 Transport Landscapes Overview of Transport Landscapes Overview of Transport Landscapes Find below typical transport landscapes used by SAP customers. A lot of variations of the shown landscapes exist and could be suitable based on the company s requirements. 3-System Landscape 4-System Landscape 5-System Landscape Supports enterprises during initial implementation and also production support where change volume is low. To reduce risk and increase flexibility, an additional testing instance is added. PRE is a pristine testing environment where release changes can be imported and tested in isolation. To further mitigate risk, a second development track can be introduced to separate production support from project development. Production in PSD, projects in DEV track. DEV QAS PRD DEV QAS PRE PRD PSD PSQ PRD DEV QAS 6-System Landscape Similar to the 4-tier landscape, an additional testing instance can be added to the project landscape (and potentially for the production support track) to isolate release changes and improve testing capabilities. In large enterprises, the 3-system landscape is generally not suitable given the expected high amount of changes that needs to be processed SAP AG. All rights reserved. 14 PSD DEV QAS PRE PSQ PRD

15 Transport Landscapes Single track 3-System Transport Landscape Single track 3-System Transport Landscape Concept: All changes are created and unit tested in DEV. All major tests are done in QAS before transports are imported into PRD. Sandbox System can be added (temporarily) and used for prototyping of new functionality or initial testing of disruptive changes such as maintenance. There should be no transport path between SBX and DEV. This landscape has lowest costs, but quality risks in case of high project activity/scope Overlapping projects with different release dates may be tested in parallel in QAS. Testing environment does not represent PRD. Risk that change works in QAS, but not in PRD. The 3-tier landscape is best suited to those customers that have entered a mature production support state, and need only to update production periodically with minor enhancements and corrections. This scenario is not suited for testing multiple long running development projects as the ability to isolate and test in a pristine environment is restricted to QAS where developments with such a requirement would be in varying stages SAP AG. All rights reserved. 15

16 Transport Landscapes Single Track 4-System Transport Landscape (1/2) Single Track 4-System Transport Landscape Concept: All changes are managed in a single development system, incl. production support and project development. All changes can be transported to QAS for integration testing. This system partially contains the changes from the new release that currently is in development. PRE (=pre-production) provides a pristine environment where the next release can be isolated and tested. That means that only changes released for the next release go to PRE staged testing. Release and regression testing is done in PRE This landscape is best practice for solutions with production support and development projects of a medium scope. There are a number of very large customers who manage all changes even larger projects through this environment. Pre-requisites are a very mature organization and very mature software change management processes. Some of these customers even execute SAP maintenance events in this landscape, whereas others use a temporary dual track landscape consisting of a project DEV and QAS for maintenance events SAP AG. All rights reserved. 16

17 Transport Landscapes Single Track 4-System Transport Landscape (2/2) Single Track 4-System Transport Landscape Illustration of Staged Testing Example of Staged Testing: 4 parallel projects in DEV, with only RED project going live with the next business release Steps: 1. In DEV there are 4 separate independent projects. 2. At various stages 3 of the 4 projects are transported to QAS to start various testing scenarios. 3. Prior to the net release window PRD should be copied into PRE. Soft Freeze for Regression testing 4. You then transport the RED project into PRE, conduct the necessary final regression and user acceptance testing. Any potential dependencies / handshaking defects the RED project may have with any of the other developments can only assuredly be detected during qualified and isolated testing in PRE. 5. After successful testing in PRE, you can transport the RED project to production SAP AG. All rights reserved. 17

18 Retrofit Transport Landscapes Dual Track Transport Landscape (1/3) Dual Track Transport Landscape Overview Production Support Concept: Project Development One set for production support and smaller projects: PSD, PSQ, PSP (optional) One set for major project development: DEV, QAS, PRE (required if multiple projects with different release dates) Changes in PSD are retrofitted to DEV periodically (ideally using Solution Manager ChaRM) Ideally the transport landscape is the same for all systems in an SAP solution. In case of a temporary project development track for individual systems only, concept for early integration test needs to be worked out. More than one project development track is generally not recommended. This landscape is a good option in case of large projects as it allows for segregation of production support and development tasks and its personnel, thus for safe and fast production support at all times. However, this landscape is not a must-have in case of large developments for a landscape. In the end it becomes a costs/benefits discussion, as the additional costs are quite high with multiple applications. For some customers it may only be suited as a temporary landscape for maintenance, if at all. Benefits: A dual track transport landscape can help mitigate risks for production from project development, e.g. if the solution is still in full roll-out mode, there are different organizations with different skills involved, a lot of invasive transports are expected or there is high risk sensitivity in the company or for the particular solution SAP AG. All rights reserved. 18

19 Retrofit Transport Landscapes Dual Track Transport Landscape (2/3) Dual Track Transport Landscape with 6 systems Illustration of Staged Testing Production Support Refresh from PRD Project Development Regression testing w/o impact on production support Example of Staged Testing: 4 parallel projects in DEV, with only RED project going live with the next business release Steps: 1. In DEV there are 4 separate independent projects, plus potentially a project in early phases in SBX. 2. At various stages 3 of the 4 projects are transported to QAS to start various testing scenarios. 3. Prior to the net release window PRD should be copied into PRE. 4. You then transport the RED project into PRE, conduct the necessary final regression and user acceptance testing. Any potential dependencies / handshaking defects the RED project may have with any of the other developments can only assuredly be detected during qualified and isolated testing in PRE. 5. After successful testing in PRE, you can cut-over the RED project to production SAP AG. All rights reserved. 19

20 Transport Landscapes Dual Track Transport Landscape (3/3) Options for Project Cut-Over in case of a permanent Dual Track Landscape Cut-Over Options PRO CON 1. Option: PRE PSD (or QAS PSD if PRE does not exist) Single source of developments for production, i.e. all changes (project and correction) arrive in PRD systems from PSD system. Opportunity to build new transport packages in PSD system in order to improve import runtime, e.g. repackaging original transports and by that achieve that an object is only transported once. This option is the standard configuration in SAP Solution Manager ChaRM. PSD system not available for production support during time of re-packaging and testing of the project developments in Pre-Prod systems. In case of Virtual Single Instance (multiple PRD with single PSD/DEV): very limited possibility to deploy new projects to different PRDs at different points in time, as production support for remaining PRD systems may not be possible in PSD anymore. 2. Option: PRE PRD (or QAS PRD if PRE does not exist) End-to-end support for development and production support during project test and cut-over Potentially more hardware required to run regression tests in project and production support environment (both PSQ and QAS have to meet test data requirements) 3. Option: Track Switch (using DEV QAS PRE after project go live for production support and build new DEV2 QAS2 PRE2 for project development, e.g. reusing PSD/PSQ/PSP) Generally not recommended Easier go live from a single project perspective All open developments and change history in PSD are lost after go live. Challenges in Solution Manager if system role changes. Challenges in test systems if only certain applications switch tracks (integration, data with LOGSYS in key) SAP AG. All rights reserved. 20

21 Transport Landscapes System Role of the Pre-Production System The Pre-Production System The pre-production system (PRE respective PSP on the previous slides) is the environment the regression test, technical system tests of infrastructure changes and final integration tests. The pre-production systems should represent the status in the production systems with respect to technical architecture (e.g. HA setup), data and transport. In particular, it means that the pre-production systems must not be corrupted with new functionality or new maintenance packages until the appropriate time (ideally as close to go-live as possible). It also means that the pre-production system should be regularly refreshed from production, if possible. However, the pre-production system does not have to have the same size as the production system. Primarily the set-up should be similar, i.e. multiple dialog instances. The quality assurance system (QAS respective PSQ on the previous slides) is used as a testing environment for integration tests and unit tests. This system partially contains the changes from the new release that currently is in development. Therefore regression tests in the quality assurance system, e.g. for emergency changes, may not detect issues or detect false positives SAP AG. All rights reserved. 21

22 Transport Landscapes Suggested Sizes of the Systems in the Transport Landscape Suggested Sizes of the Systems 3-system landscape 4-system landscape 5-system landscape 6-system landscape DEV QAS PRD DEV QAS PRE PRD PSD PSQ PRD DEV PSD DEV QAS QAS PRE PSQ PRD S M L DEV QAS PRD DEV, QAS PRE PRD PSD, PSQ, DEV PSD, PSQ, DEV, QAS QAS PRE PRD PRD (PRE) Explanation of T-Shirt Sizes in table above: High Availability solution in place CPU and RAM Size compared to PRD DataVolume compared to PRD S no small Small M yes medium 100% of PRD L yes 100% of PRD 100% of PRD 2012 SAP AG. All rights reserved. 22

23 Elements of a Software Change Management Strategy Transport Landscapes for Template Management

24 Transport Landscapes for Template Management Landscape Strategies to achieve Process Harmonization Level of process harmonization depends on the Non-production Systems 0. Single Instance Single DEV PRD Harmonization across all tenants All localization in central system 1. Virtual Single Instance Single DEV PRD 1 PRD 2 2. Template + Multiple Dev. Systems Common DEV L-DEV 1 PRD1 L-DEV2 PRD 2 Harmonization across systems same as with single instance All localization in central system Harmonization across systems for common processes Localization in the multiple systems Very complex model in practice 3. Multiple Dev. Systems DEV 1 DEV 2 PRD 1 PRD 2 Autonomy of the systems Harmonization across systems by information sharing ( paper-based ) 2012 SAP AG. All rights reserved. 24

25 Transport Landscapes for Template Management Overview of Landscapes Best Practice Options for Template Dev. with multiple Production Systems (1) Virtual Single Instance all PRD systems share the same code and configuration QAS (2) Template DEV + localization DEV systems PRD systems differ in terms of localization code/configuration QAS (3) Central DEV system with separate clients per PRD system PRD systems share the same code, but differ in terms of localization configuration Client 001: Common Client 010: PRD1 Client 020: PRD2 QAS Client 010 Client SAP AG. All rights reserved. 25

26 Transport Landscapes for Template Management General Pre-Requisites for having a common DEV (1/2) Minimum technical Pre-Requisites for the Production Systems If a DEV system is shared for multiple production systems (with or without additional DEV systems for localizations), certain pre-requisites for the production systems have to be met: Same release, enhancement package, support package, country versions and legal packages Unicode compliance of all systems Same enterprise extensions and business functions activated has business impact Temporarily, e.g. in case of an upgrade, the systems can deviate. If the system requirements cannot be met (e.g. flexibility on release levels needed by production system), separate DEV systems on regional level are needed. The production systems can have different OS/DB than DEV, but with operational complexities. For safe software change management, it is important that similar hardware and same OS/DB as in the production system are used in the corresponding pre-production systems. And in case of different DB platforms, performance tests per DB platform are recommended. To support such activities the pre-production system should be set up like the respective productive system. In operations with different platforms, there are differences, e.g. you cannot just reuse tools, procedures and configuration settings between platforms. And there are differences when it comes to maintenance tasks, e.g. SAP kernel patching, OS patching, VMware patching etc. This drives complexity in operations. If the DB platform is different on central DEV and test systems than in production, you cannot just use backup restores from production for test system refreshes, but have to use export/imports instead SAP AG. All rights reserved. 26

27 Transport Landscapes for Template Management General Pre-Requisites for having a common DEV (2/2) Other Pre-Requisites If a DEV system is shared for multiple production systems (with or without additional DEV systems for localizations), certain other pre-requisites for the production systems have to be met: Common landscape track usages retrofit / track switching Single release strategy and release calendar Global solution manager for change request management by ChaRM Strategy for transport landscape and processes for related applications/systems (e.g. SAP APO) 2012 SAP AG. All rights reserved. 27

28 Transport Landscapes for Template Management Option (1): Virtual Single Instance Option (1): Virtual Single Instance QAS Explanation: Single development system, independent of the number of production systems. All localizations done in central development system, always hitting all production systems at more or less the same time. Result: all production systems share the same code and configuration Project landscape can be added. Considerations: Single development system is easiest way to achieve harmonized processes. One development system easier to control Risk minimized for getting out-of-sync Psychological effects of a single system In case a strong template is desired: strong governance is needed nevertheless to protect the global processes. Otherwise proliferation of process variants can happen in this option SAP AG. All rights reserved. 28

29 Transport Landscapes for Template Management Option (1): Virtual Single Instance Software Change Flexibility Software Change Management Flexibility in Virtual Single Instance Main principle: Production systems should be kept in sync as there is only a single development system for support. For speed for changes and downtime planning this model allows for more flexibility in comparison to a single production system, but the flexibility is limited in the following sense: Single changes (in particular emergency transports) can be transported to a single PRD system first, but should be regression tested and imported to all production systems with the next minor release (e.g. weekly). Medium/major business releases should be imported to all production systems within a few days, ideally within a weekend.. Upgrades (or other major changes for which a project landscape is needed) can be done if required at different consecutive weekends using the project landscape or the QAS-PRE landscape temporarily for production support (of course with the respective limited support and extra retrofit effort) SAP AG. All rights reserved. 29

30 Transport Landscapes for Template Management Option (2): Common + Localization DEV Systems (1/2) Option (2): Template DEV + localization DEV systems QAS Explanation: All common processes are developed as a template in the central development system and protected against changes in the localization L-DEV systems (e.g. using BC-sets and authorization on development classes) All localizations done in L-DEV systems, only hitting the respective productive system. Result: PRD systems share the same code and common configuration, but differ in terms of localization configuration. Project landscape can be added Considerations: Tools support the protection of the template (e.g. BC-Sets, authorization concepts), nevertheless quite sophisticated governance process needed to avoid too much localization. Ideally only one development team for common and local objects to avoid too much autonomy in the L-DEV systems. Quite complex transport patch and in case of dual track very complex retrofit process. Advantage that independent project schedules and downtimes per production system possible. Advantage that only selective configuration hits the production system SAP AG. All rights reserved. 30

31 Transport Landscapes for Template Management Option (2): Common + Localization DEV Systems (2/2) Keeping the Balance: Flexibility vs. Effort/Risk QAS The landscape can be used in very different ways and for different template cases, e.g. 95% template or partial 20% template. This landscape has built-in flexibility for change on the regional level, e.g. in case a correction is urgently needed in one of the PRDs, this could be done in the respective L-DEV. However this can partially also be achieved with a single DEV (e.g. cherry-picking of transports). And all flexibility on the L-DEVs comes with additional effort/costs and risks of inconsistencies: Short-cuts by implementing things first in one of the L-DEVs can lead to long-term inconsistencies. A solid process of how to retrofit those changes back in DEV is required. The more flexibility on the regional level is allowed, the more complex is the overall process (governance of the template, potential conflicts with the template / adoption of the template). If flexibility for upgrades is needed per track, the template DEV has to be maintained in multiple version. So generally, companies who want a strong template do all major developments and all corrections relevant for all PRDs only in DEV SAP AG. All rights reserved. 31

32 Transport Landscapes for Template Management Option (3): Global DEV system with separate clients Option (3): Central DEV system with separate clients per PRD system Explanation: Client 001: Common Client 010: PRD1 Client 020: PRD2 QAS There is only one DEV system, but different clients are used for configuration for each PRD system. Code and client-independent configuration is developed in client 001 and transported to all PRD systems. Common client-dependent configuration is developed as a template in client 001 and copied to clients 010 and 020 in DEV where the localization happens. Configuration is then transported to the respective PRD system (e.g. DEV client 010 to PRD 1 client 10). Of course, each PRD system only has a single client. Result: PRD systems share the same code and common configuration, but differ in terms of localization configuration. Implications and risks for operations: Transport execution is significantly more complex. Client 010 Client 020 Risk of inconsistencies for developments (configuration and code have to arrive at the same time.) Not having identical PRDs can lead to issues, in particular for cherry-picked transports, e.g. unexpected failure situations because of dependencies to/from cross-client customizing and coding possible. Problem solving is more difficult (they first need to understand the differences in a given system) SAP AG. All rights reserved. 32

33 Elements of a Software Change Management Strategy SAP MaxAttention IT Planning Offering

34 SAP MaxAttention IT Planning Strategic services for Software Change Management SAP MaxAttention IT Planning: Topics SAP Production System Strategy, i.e. number, size and location of production systems SAP Software Change Management SAP Technical Architecture, i.e. type of hardware, number of application server per system, HA/DR concept, virtualization concept, etc. Example: SAP Software Change Management Onsite Review of software change management processes at the customer Comparison to Best Practices Identification of improvement points Result: Report with concrete recommendations for software change management improvement points 2012 SAP AG. All rights reserved. 34

35 SAP MaxAttention IT Planning Motivation (1/2) Motivation Customer has the requirement to rollout new functionality for the foreseeable future, in release waves, during which time the customer will also need to able to: Stabilize and isolate production from on-going development and maintenance risks Provide an environment which has the ability to handle multiple major projects in parallel, inclusive of maintenance, and provides software change management governance Is capable of supporting business as usual requirements, such as, providing production with emergency corrections, standard changes and minor enhancements Typical situations at SAP customers: Release Management processes, to manage complex requirements, are not in place. Project Management not optimized o Projects are often treated as a release, and as such individual projects drive the landscape. This leads to a landscape optimization/consolidation effort o Project conflicts often lead to the deployment of a second development instance, separating the projects, causing significant integration effort later Change Management / Transport Management and its governance not defined, causing errors in production o Transports in environments where they do not belong, at this point in time 2012 SAP AG. All rights reserved. 35

36 SAP MaxAttention IT Planning Motivation (2/2) Motivation Most of these situations drive the customer questions: Are my software change management processes optimized? What are the software change management Best Practices? How to follow a fixed release calendar and still provide flexibility to the business units? How to manage multiple projects in parallel? o How to manage object conflicts? How to govern change, their transports, and adequately test the change? Is the landscape optimized? o What are the landscape best practices? o How are other customers managing their software change management requirements and their landscapes? 2012 SAP AG. All rights reserved. 36

37 SAP MaxAttention IT Planning Overview of IT Planning Software Change Management Strategy Service At a Glance: IT Planning Software Change Management Strategy Service The IT Planning Software Change Management Strategy service is a service exclusively delivered for SAP MaxAttention customers. helps customers to o understand the benefits of proper software change management in general, o understand how release management can ensure the quality of production software, o understand how multiple projects can be developed, tested and deployed in parallel, o ensure the fundamental change categories and prioritization are in place, o evaluate transport landscape options and its usage to ensure it can manage the software change management requirements. minimizes future risks and reduces costs of the future SAP landscape for a relatively low investment The IT Planning team has experience with software change management and its transport landscape requirements from jointly working with SAP MaxAttention customers around the world SAP AG. All rights reserved. 37

38 SAP MaxAttention IT Planning Details for the IT Planning Software Change Management Strategy Service Approach of the IT Planning Software Change Management Strategy Service Onsite Workshop (typically 2-3 days): Understand the customer s Software Change Management situation o What is the customer situation (change volume, types of changes, time for realization of enhancements, downtime requirements,.)? o What is the situation today? What are important boundary conditions? o What will change in the future? What are new requirements Review of the overall Software Change Management concept. o Does it effectively support the requirements of the customer? o Is it in line with best practices? Review of the transport landscape o What is the concept behind the current transport landscape? How did it evolve, what were driving factors? o Does it support the processes effectively? o Is it in line with best practices? o How does it compare to the landscapes used by other companies? Remote creation of Final Report: Documentation of the findings and recommendations for improvement from the workshop Result: Final Report (ppt-format) delivered typically one week after the workshop 2012 SAP AG. All rights reserved. 38

39 Thank You! IT Planning SAP Active Global Support