1 / 30

Quick Upgrade Analysis Service Report for County of San Luis Obispo

Quick Upgrade Analysis Service Report for County of San Luis Obispo. Rich Dodson Ernest Culver Phil Oertli SAP Public Services. Agenda. System Information 1.1. Technical 1.2. Modifications 1.3. Functional scope 1.4. Classification Technical Upgrade 2.1. Effort estimation

talen
Download Presentation

Quick Upgrade Analysis Service Report for County of San Luis Obispo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Quick Upgrade AnalysisService Report for County of San Luis Obispo Rich Dodson Ernest Culver Phil Oertli SAP Public Services

  2. Agenda • System Information 1.1. Technical 1.2. Modifications 1.3. Functional scope 1.4. Classification • Technical Upgrade 2.1. Effort estimation 2.2. Savings by elimination of unused objects • Extended Maintenance savings • retro-fit Upgrade 4.1. Effort estimation 4.2. Savings due to retro-fit upgrade • Payback Charts • Project Plan Examples 6.1. Technical upgrade 6.2. retro-fit upgrade

  3. General assumptions • The Quick Upgrade Analysis (QUA) provides a high-level estimate of the effort, benefit, project schedule and resources required to upgrade from your current SAP ERP system to SAP ERP 6.0. Its purpose is to provide preliminary visibility into the various aspects of the upgrade project. • The QUA does not replace a detailed upgrade assessment which refines the project estimate and provides a detailed, customer-specific project plan. • The estimates in the QUA are derived based on: • Analysis of your system using our system analyzer and its interpretation which is based on SAP benchmarks and extensive SAP upgrade experience. • Data you provided in the QUA questionnaire, such as • Test management status and maturity • Business process complexity • Organizational complexity • Upgrade experience. • It is recommended that the transaction monitor runs for at least three months to ensure that a sufficient amount of data, by SAP module, is captured & analyzed. The timeframe selected has a direct bearing on the quality of the analysis. • The retro-fit effort and benefit analysis within the QUA refers only to ERP core functionality. Analyses of systems with Industry Solutions will not deliver industry specific retro-fit potentials.

  4. System information – Technical An upgrade of PRD to SAP ERP 6.0 is considered comparatively simple due to it’s significant size and low degree of modification. Customer and system parameters System classification General data Customer: County of San Luis Obispo System: 20153413 Release: R/3 4.70 Modules: 10 large License data License: R/3 license License conversion: 0 USD Number of users: 3281 SAP maint. fee p.a.: 100,000 USD Decreasing upgrade complexity Increasing upgrade complexity Degree of modification Simple objects: 184 Medium objects: 199 Complex objects: 264 Interfaces: 71 Hardware #CPU: 8 Memory: 32764 MB Storage: 100 GB Language(s): Single code page Evaluation data Internal rate: 7,360 USD External rate: 2,400 USD Analysis time-frame: 5 years small low high Note: The following results are high-level estimates of upgrade effort and benefits based on system data collected by the transaction monitor running from 39356 and 39443 on your system. A detailed technical system review and evaluation was not undertaken.

  5. System information – Degree of modification Modified objects represent a significant cost driver during an upgrade. The following objects could be identified incl. their respective complexity to upgrade Modified objects / complexity High (>200 mLoC1) Medium2 (100-200 mLoC1) Low (<100 mLoC1) • Modifications • Modified executable programs • Modified includes • Modified classes • Modified module pools • Other modified programs • Modified function blocks Custom objects • Customer programs • Other program types • Customer includes • Customer function blocks Customer exits Modified SAP scripts Modified DDIC objects • Transparent tables • Pool tables • Cluster table Interfaces 29 4 25 0 0 0 0 235 171 11 53 21 0 9 0 0 0 12 122 76 4 10 32 32 20 4 4 0 0 71 18 1 15 0 0 2 0 166 63 16 87 No complexity evaluation and module assignment possible 1 Complexity is derived from the modified lines of code (mLoC) 2 For customer exits, modified SAP scripts, modified DDIC objects and interfaces a complexity evaluation based on modified LoC is not possible, therefore these objects are assumed to be medium complex

  6. System information – Functional scope The system analysis shows how the R/3 modules are modified. In total, 34% of all modified objects cannot be assigned to a SAP module. System classification1 • In total, 502 modified objects (SAP modifications and customer objects) could be identified • The most strongly modified modules are: • HR (227 modified objects) • FI (39 modified objects) • CO (35 modified objects) • 34% of objects cannot be assigned to a SAP module. • [Note: The data extraction program reads the module from the development class, i.e. if the development class in the modified object is not maintained, a module cannot be assigned]. 1 Only the following objects can be assigned to a module: Modifications and custom objects, except customer function blocks (refer to slide 4) 2 n/a: Modified objects which cannot be assigned to a module. Almost 100% of modifications can be assigned to a module, yet on average only 40% of customer developments.

  7. Upgrade complexity classification large 5 months 6-12 months 5 - 9 System scope 1 - 4 3 months 4 months small low high System complexity 1 - 4 5 - 9 In a simple model, the duration and effort of an upgrade is driven by the system scope and system complexity1 The cost drivers #users, #modules are used to score the dimension system scope from low (1) to high (9) The cost drivers #interfaces, #modified objects are used to score system complexity from low (1) to high (9) System classification matrix2 1 Other factors influencing the upgrade effort (i.e. organizational complexity, knowledge) are considered in a later stage 2 The values for upgrade duration are rough estimates based on SAP Ramp-up experience for technical upgrades

  8. Scope – Upgrade Scenario Evaluation The Quick Upgrade Analysis evaluates two different scenarios - Technical Upgrade and Retrofit Upgrade. 3 • Strategic Business Improvement • Focus on functionality extension and improvement • Enablement of new and optimized business processes and scenarios based on new ERP core functionality • retro-fit Upgrade • Focus on reduction of system complexity • Maximization of SAP standard functionality by replacing modified objects by standard functionality • Technical Upgrade • Focus on pure technology upgrade • No changes to used standard functionality • Elimination of unused modified objects 3 New functionalities 2 Standard functionalities 2 SAP Standardization Limited number of modifications 1 Highly modified environment 1 Start release SAP ERP 6.0 SAP Releases As-is Target

  9. Main Assumptions The Quick Upgrade Analysis is based on several assumptions regarding effort and benefit estimation.

  10. Technical Upgrade: Effort estimation A technical upgrade to SAP ERP 6.0 is estimated to require approx. 1615 PD of effort.1 Assumptions and baselines a • Planning: Is expected to consume 10% of the project duration. In this time-frame, each R/3 module requires 1 internal resource (75% utilization) for functional delta analysis, test planning, sizing ...etc. and 1 external resource (10% utilization) for delta training and consulting. • Development: Per custom development / modification an effort between 0,1-6h is estimated for a technical upgrade depending on object type and complexity. • Testing: Three test cycles - unit tests, integration test, business acceptance test - are recommended. Efforts strongly depend on number of business processes and test maturity • Go-Live is expected to take 10% of Planning effort • Training: Efforts for end-user training are negligible for a technical upgrade due to only minor handling changes, i.e. training is set to 0 PD • Hardware: HW costs are determined via delta-sizing based on SAP Notes b c d + 13% additional CPU + 23% additional memory + 9% additional storage (disk) 3 0 USD Delta training team, analysis retro-fit potentials Technical upgrade effort + planning and implementing retro-fit Unit tests, integration test, business acceptance test Upgrade of production system 1615 PD Effort in person days 1 Efforts for integration testing / acceptance tests have only been included, if customer data was provided in questionnaire 2 License fee only included if customer has provided information in the questionnaire 3 Based on OSS notes: 113795 (40B45B), 323263 (45B46C), 517085 (46C47x110), 752532 (47x11047x200), 778774 (47x200ECC50), 901070 (ECC50ECC60)

  11. Technical Upgrade: Savings through elimination of modified objects1 An upgrade enables annual savings of approx. 1,583,872 USD through elimination of unused objects and saved extended SAP maintenance. Savings potential estimation • The number of unused objects exceeds 50%(5). Our experience shows that this value is exceptionally high and can result from a too short run-time of the transaction monitor³. Further investigations are strongly recommended. • It is assumed that the unused objects can be eliminated. • Savings result from elimination of unused objects. Ongoing maintenance effort for custom objects is typically 20% p.a. of initial development effort. • Assumption for initial development effort • Highly complex objects: 10 PD • Medium complex objects: 6 PD • Low complex objects: 2 PD • An annual saving of 215 PD is estimated as follows: • Highly complex objects: 61 x 10 PD x 20% = 122 PD • Medium complex objects: 61 x 6 PD x 20% = 73 PD • Low complex objects: 50 x 2 PD x 20% = 20 PD Annual potential4 1,583,872 USD 1 Maintenance savings are based on benchmarks from an SAP study from Experton Group (2005) 2 Usage cannot be determined for these objects. They include: modified includes, classes, module pools, function blocks, DDIC objects, customer exits 3 Analysis is based on transaction monitor runtime between 39356 and 39443 on your system. 4 Calculation is based on an internal cost rate of 7,360 USD 5 Based on the total of used and unused objects (not counting the objects for which usage is unknown)

  12. SAP extended maintenance savings An immediate upgrade enables annualized extended maintenance fees of 25,490 USD compared to not upgrading in the next 5 years Savings potential calculation Year Extended maintenance1 (in %) (value) 2008 0% 0 USD 2009 2% 11,765 USD 2010 4% 23,529 USD 2011 4% 23,529 USD 2012 8% 47,059 USD 2013 8% 47,059 USD 152,941 USD Upgrading in 2008 enables savings of 152,941 USD compared with not upgrading in the next 5 years. The basis of this calculation is the standard SAP 5-1-2 maintenance model shown on the left. The extended maintenance percentages are applied to the current maintenance base. Annual savings 25,490 USD 1 Extended Maintenance 1st year: +2%, 2nd & 3rd year: +4%, as of 4th year: customer specific maintenance assumed at +8% (note: All % numbers in addition to the standard maintenance of +17%)

  13. Retro-fit Upgrade: Effort estimation A retrofit upgrade to SAP ERP 6.0 is estimated to require approx. 2208 PD of effort.1 Assumptions and baselines a • Planning: Is expected to consume 15% of the project duration. In this time-frame, each R/3 module requires 1 internal resource (75% utilization) for functional delta analysis, test planning, sizing ...etc. and 1 external resource (10% utilization) for delta training and consulting. • Development: If retro-fit is possible, a retro-fit effort of 1-2,5 PD is estimated per custom development / modification. For all other objects, adjustment efforts of a technical upgrade apply. • Testing: Three test cycles -unit tests, integration test, business acceptance test- are recommended. Additional 10% testing effort (compared to technical upgrade) are estimated for re-building test cases. • Go-Live is expected to take 10% of planning effort • Training: Key-users are trained for 2 days acting as a multiplier for end-users (Assumed key-user to end-user ratio: 1:20) • Hardware: HW costs are determined via delta-sizing based on SAP Notes b c d + 13% additional CPU + 23% additional memory + 9% additional storage (disk) 3 0 USD Delta training team, analysis retro-fit potentials Technical upgrade effort + planning and implementing retro-fit Unit tests, integration test, business acceptance test Upgrade of production system Effort in person days 2208 PD 1 Efforts for integration testing / acceptance tests have only been included, if customer data was provided in questionnaire 2 License fee only included if customer has provided information in the questionnaire 3 Based on OSS notes: 113795 (40B45B), 323263 (45B46C), 517085 (46C47x110), 752532 (47x11047x200), 778774 (47x200ECC50), 901070 (ECC50ECC60)

  14. Retro-fit Upgrade: Additional saving opportunities Maintaining SAP modifications is costly. Keeping the system as close to standard as possible should be the paradigm resulting in operational IT savings Savings potential estimation 10% 20% • Additional savings: 3 modules show high standardization potential (i.e. high number of modified objects and/or large number of new functionality) • Particularly the R/3 module(s) MM, FI/CO, HR should be evaluated in detail. • Estimated retro-fit opportunity benefits: • very high potential: 20% x 1218 PD x 20% = 48.7 PD • high potential: 15% x 360 PD x 20% = 10.8 PD • medium potential: 10% x 0 PD x 20% = 0 PD • low potential: 5% x 80 PD x 20% = 0.8 PD Savings retro-fit2 443,955 USD 5% 15% Total savings calculation (p.a.) Savings retro-fit2 443,955 USD Savings technical upgrade 1,583,872 USD Please note: Modules used but without any modifications or any retrofit potential will not be shown in this chart. The modules FI, CO, and EC are aggregated. Savings maintenance 25,490 USD Savings total (p.a.) 2,053,317 USD 1 For modules with very high retro-fit potential, it is assumed that 20% of its modified objects can be converted into the new ERP 6.0 standard. Likewise, 15% are applied for high potential, 10% for medium potential and 5% for low potential modules. 2 Calculation is based on an internal cost rate of 7,360 USD

  15. Upgrade payback analysis and main findings The estimated payback time of a technical / retrofit upgrade scenario is expected to be beyond 5 years Technical upgrade Retro-fit upgrade Key findings Key findings Using the given parameters, the following results are estimated: Pay-back period: not within 5 years. One-time upgrade effort: 1615 person days. Using the given parameters, the following results are estimated: Pay-back period: not within 5 years. One-time upgrade effort: 2208 person days. 1 Assumptions: Best Case - 100% of benefits and costs will occur. For Worst Case scenario 30% higher upgrade effort, but only 70% of best case savings are calculated.

  16. Example for ERP 6.0 Technical Upgrade Plan The technical upgrade could be achieved in a timeframe of 4 months. 2007 System complexity: Cluster III January February March April May June CW 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Project Preparation Upgrade Blueprint Upgrade Realization Production Cutover Go Live Support Activity Plan for Upgrade:

  17. Example for ERP 6.0 Retrofit Upgrade Plan The retrofit upgrade could be achieved in a timeframe of 10 months. 2007 System complexity: effort > 2.000 PD JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC Project Preparation Upgrade Blueprint Upgrade Realization Production Cutover Go Live Support

  18. SAP ERP 6.0 - Features and Value of Upgrade Business value and functional benefits of an upgrade to SAP ERP 6.0 are numerous. For more details about the new business benefits of SAP ERP 6.0 as well as a deeper insight into the functional value of an upgrade to SAP ERP 6.0 please use the attached document: To easily map and evaluate new functionality of SAP ERP 6.0 according to your current release and specific modules, please see the attached document or follow the link to the solution browser: Customer Specific Solution Browser Document: SAP Service Marketplace: http://service.sap.com/erp

  19. Suggestion for Next Steps Based on this initial analysis it is recommended to decide on the most appropriate upgrade scenario and commence planning. Step 1 DECIDE • Check if a technical or functional upgrade alone results in a substantial business case • If yes, decide on the most relevant upgrade scenario Step 2 PLAN • If no, consider if new functional requirements exist which can be addressed with standard functionality (strategic upgrade) more information: http://solutionbrowser.erp.sap.fmpmedia.com/ • Start planning the upgrade in detail (Recommendation: usage of the SAP Upgrade Roadmap) Step 3 BUILD • Consider SAP accelerators available during and after the upgrade (eg. Netweaver Admin tools, SAP test tools) • Staff and carry out the upgrade

  20. Appendix • Additional Assumptions • Upgrade complexity classification • Effort estimation – method of calculation • Effort parameterization • Benefit estimation – method of calculation • Language issue (single page, MDMP, Unicode)

  21. Assumptions The analysis is based on several general assumptions detailed below General assumptions and definitions • Scenarios: • Best Case scenario - 100% of benefits and costs will occur. • For the worst case scenario, 30% higher upgrade effort, but only 70% of best case savings are estimated. • Terminology: • Modified objects: all objects outside of SAP standard, incl. modifications, custom objects, modified DDIC objects (rf. slide 4) • Modifications: Modified executable SAP programs, modified includes, modified classes, modified module pools, modified function blocks • Interfaces: All interfaces from analyzed R/3 system (e.g. R/3, R/2 connections, TCP/IP external programs, application server connections …etc.) • Benefit analysis: • Benefits include IT maintenance savings resulting from elimination of unused modified objects and retro-fit of objects. • Determination whether a modified object is used or not is only possible for modified executable programs and customer programs (transactions). • To ensure a conservative benefit estimate, savings are based only on objects for which transaction monitor does not identify usage during transaction monitor run-time. Other objects which could potentially also be eliminated as a consequence of removing unused objects are not considered. • For the retro-fit analysis, only those modified SAP objects which are assigned to a SAP module can be considered. For all other objects, a retro-fit potential of 5% is assumed. • Cost analysis: • Modified objects cause an analysis and adjustment effort during an upgrade project • Adjustment efforts are estimated for all modified object types named above (rf. Slide 4) • Efforts are based on SAP benchmarks and project experience values (including Ramp-up for ECC 6.0) • A key-user / end-user ratio of 1:20 is assumed • The SAP maintenance costs and savings are determined based on the standard 5-1-2 SAP maintenance model. • Customer specific SAP maintenance payments (outside of Mainstream and Extended Maintenance) are expected to be standard maintenance (17%)+8% p.a. (estimate which may vary depending on the customer) • Hardware costs are not considered in the calculation – only typical delta HW requirements are provided based on OSS notes.

  22. large 5 months 6-12 months 5 - 9 System scope 1 - 4 3 months 4 months small low high System complexity 1 - 4 5 - 9 Upgrade complexity classification In a simple model, the duration and effort of an upgrade is driven by the system scope and system complexity1 The cost drivers #users, #modules are used to score the dimension system scope from low (1) to high (9) The cost drivers #interfaces, #modified objects are used to score system complexity from low (1) to high (9) System classification matrix2 1 Other factors influencing the upgrade effort (i.e. organizational complexity, knowledge) are considered in a later stage 2 The values for upgrade duration are rough estimates based on SAP Ramp-up experience for technical upgrades

  23. Retro-fit upgrade Technical upgrade Applicable for both Effort estimation1 – method of calculation The upgrade effort estimation is aligned with the SAP Upgrade Roadmap and considers the major cost drivers using experience values/benchmarks

  24. Effort parameterization The effort estimation represents a baseline, which is strongly influenced by client-specific complexity dimensions like SAP experience & organizational complexity Complexity dimensions Complexity dimensions Maturity of test management and test tools Complexity of processes running on the R/3 system to be analyzed Organizational complexity relevant for R/3 system to be analyzed Upgrade Experience Assess complexity dimensions on a 5-point scale:1 = excellent / low complexity2 = good / minor complexity3 = medium / medium complexity4 = fair / considerable complexity5 = poor / high complexity1 Identify total complexity score and adjustment percentage The upgrade effort can vary between 50% - 150% of the baseline depending on the client‘s complexity rating (see effort adjustment chart) Adjust baseline effort by this percentage Effort adjustment 1 A description for each scenario (from poor to excellent) is provided in the questionnaire

  25. Retro-fit upgrade Technical upgrade Applicable for both Benefit estimation – method of calculation Benefits result from eliminating unused modified objects (technical upgrade) and additionally retro-fitting modified objects (retro-fit upgrade)

  26. Not supported Supported Supported with limitations ERP and R/3 native language support * MDMP or Blended Code Page are NOT recommended anymore - General restrictions („Golden Rules“) for MDMP apply ** These releases are the preferred Unicode conversion releases Note: SAP support is release based, NOT time based

  27. SAP ERP 6.0 Upgrade And UNICODE Conversion Options Which Release do you use? R/3 Enterprise or ERP 2004 R/3 Enterprise or ERP 2004 MDMP R/3 Enterprise or ERP 2004 UNICODE ERP 6.0 UNICODE UNICODE Conversion before Upgrade Convert Upgrade Yes R/3 4.6C R/3 4.6C MDMP ERP 6.0 UNICODE Do you currently use MDMP? Combined Upgrade & UNICODE Conversion (CUUC) Upgrade, directly followed by UNICODE Conversion R/3 4.6B or lower R/3 4.6B or lower MDMP ERP 6.0 UNICODE Twin Upgrade & UNICODE Conversion (TUUC) Upgrade, directly followed by UNICODE Conversion No Ca. 90% of all customers R/3* Single code page ERP 6.0 Single code page ERP 6.0 UNICODE Upgrade before UNICODE conversion Convert Upgrade R/3*: For R/3 Enterprise and ERP 2004 on single code page the UNICODE conversion is also possible before the upgrade as these releases are already UNICODE enabled.

  28. First upgrade, then conversion to Unicode1 Upgrade Paths to Unicode R/3 3.1i R/3 4.0b SAP ERP 6.0 non-Unicode SAP ERP 6.0 Unicode Directupgrade Con-version R/3 4.5b R/3 4.6b R/3 4.6c 1 If No. of Code Pages in old system > 1 then the Unicode Conversion MUST be done IMMEDIATELY after upgrade.

  29. Disclaimer • This document contains confidential and/or privileged information. • Any unauthorized copying, disclosure or distribution is strictly forbidden. • All information provided in this document is based on assumptions of the customer and SAP. • Cost and benefit data are only rough estimates without any liability from SAP. • This document is not an offer and subject to SAP's board approval.

  30. Thank you! • Name Surname Business Unit Street name Code City • T +49/xxxx/xxx-Ext. • F +49/xxxx/xxx-Ext • xxxx.xxxx@sap.comwww.sap.com

More Related