Presentation on theme: "In Part 1 of the Session In Part 1 one of this 2-part session we will look at how to plan for, staff, budget, and prepare for a HANA implementation We."— Presentation transcript:
0 An A-to-Z Guide to Implementing SAP HANA: Planning, Scoping, Staffing, Budgeting, and Execution Bjarne BergComerit
1 In Part 1 of the SessionIn Part 1 one of this 2-part session we will look at how to plan for, staff, budget, and prepare for a HANA implementationWe will see two demos of SAP HANA and discuss the different implementation scenariosYou will learn about your hardware options and see real price examplesWe will explore a milestone plan and look at three different staffing models from real implementationsAt the end of this session you will know how to start the project planning for your implementation or migrationIn the second part of this presentation we will look at how to execute a HANA install and HANA migration project, and see how to do development in HANA
2 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
3 HANA Editions and Components While HANA is sold as an appliance, there are many internal components and the edition you buy may contain different licenses to these components.
4 HANA Release Strategy and Names Source: SAP AG, SAP HANA Product Management, Dec 2013.As of December 2013, SAP introduced the idea of “production verified revisions” to provide in-depth testing of all service packs for SAP HANABased on the planned releases over the next 24 months, customers should adjust their plans for service packs accordingly
6 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
7 SAP Business Suite on HANA As of January 17, 2013, SAP has supported SAP Business Suite on HANAThis means that you can install a new ERP system on HANA, or migrate your existing system to HANA to take advantage of the simpler architecture as well as the significant performance benefits of HANAIn 2013, several companies installed or moved their ERP systems to HANA, and it is becoming increasingly commonTo see what is supported from an ERP standpoint, take a look at SAP Note (SAP Business Suite Powered by SAP HANA - Restrictions); a list of pre-checks and more details are available at
8 SAP Business Suite on HANA (cont.) SAP has created many sites for helping customers navigating the ERP migrationThe “best” tactical step-by-step site is found atMore general information can be found at SAP HANAThere is not a lot of qualified ERP migration consultants available (yet), so plan on involving SAP in your project team as well.
9 SAP HANA Analytical Framework You do not need SAP BW, nor ERP to benefit from HANAMany organizations can benefit from the speed and simplicity of SAP HANA even if they do not have SAP Business Suite (ERP) or SAP BW (data warehouse)The open nature of HANA allows you to build your own data warehouse and analytical applications in anyway you want, and you can access the models with most tools through a variety of interfaces, including ODBC.
10 Four Options for Migrating BW to HANA There are basically four different approaches to migrating your BW system to SAP HANA. Each are slightly different. They may be summarized as:Standard BW to HANA migration without OptimizationBW to HANA migration with OptimizationBW to HANA migration as a Re-ImplementationMigrate a copy of BW to HANAA major decision before you start is to determine which of these options your want to pursue. We will now take a quick look at each of them
11 1. Standard BW to HANA migration without Optimization In this approach you treat your BW move to HANA as a database migration project.This means that you start with the BW system, complete the cleanup and preparations and migrate the database over to SAP HANA, but leave the application logic and data models the same.After the migration you will have your database system as HANA, but there are no model changes to your system and there will be no impact to your queries, link to NLS, interfaces, or data loads except for substantially faster performance and some internal changes on how HANA processes at the database level (i.e., data activation and compression)Functionally, you have the same system and this approach is therefore the fastest and most common.
12 2. BW to HANA Migration with Optimization In this approach, the migration also involves the optimization of data structures to take advantage of the new capabilities in HANA This may include HANA optimized InfoCubes and HANA hints on data transformations to make lookups go faster or LSA redesign.This migration approach is a technical and functional upgrade at the same time. While the impact is minimal, significant additional performance in data loads and query performance can be achieved.For very large BW systems, this approach can be very time consuming and require more testing. To reduce this, you can limit the optimization to slow performing areas that need this extra boost, or do the standard upgrade first and then optimize as part of future development efforts, or when enhancing InfoCubes and data loads.How much additional optimization effort you are willing to undertake depends on the resources available and how fast you have to complete the migration.
13 3. BW to HANA Migration as a Re-Implementation Some organizations have decided to take the BW to HANA migration as a re-implementation approach to also clean up old designs and retire no longer used InfoCubes, InfoObjects, DTPs, reports, queries, and other elements.The steps involve setting up a new BW system on HANA parallel to the current BW system running on a relational database. Then, for key areas, the InfoCubes and DSOs are transported to the HANA box and the data loads are switched over to the new system as part of smaller projects.Meanwhile, other InfoCubes and DSOs are running on the old BW relational database- based system. Basically, you are running two BW systems at the same time without duplicating the loads to InfoProviders in both systems.While more costly, this approach allows you to keep the old system around and minimize risks of the HANA migration. The outage required is also minimal and can be done over a weekend, functional area by functional area.
14 4. Migrate a Copy of BW to HANA This alternative approach can be used by organizations with very low risk tolerance and those who have lots of time to migrate BW to HANAIt involves copying the production BW system and applying notes or upgrades as required. Then reconciling the BW and the new BW on HANA system from a functional standpoint (interfaces, open hubs, reports, analytics, security, and data). When the tests are done, the process chains are run and the data is reconciled again.We will look at the Direct Migration Option (DMO) and the features of Post-Copy Automation PCA in Part 2 of the session
15 Summary of BW to HANA Migration Options For many organizations, a migration of their BW systems to HANA (technical migration), followed by a later functional optimization is the most common approach (so far)
17 Pre-Steps — Analyze BW Readiness SAP has a checklist tool for SAP NetWeaver® BW powered by HANA (thanks to Marc Bernard at SAP Labs).In this tool, SAP provided automatic check programs for both the 3.5 version and the 7.x version of BW. These are found in SAP Note:In the latest version of this tool, hundreds of checks are done automatically in the BW system. This includes platform checks on database and application and system information.There are even Basis checks for support packs, ABAP/JAVA stacks, Unicode, BW releases, and add-ons to your system
18 Pre-Steps — Analyze BW Readiness (cont.) Your should run this program well in advance of the actual migrationThe tool is essential to the planning phase to understand the tasks that are required for migrating to SAP HANAThis tool does not replace the upgrade tasks in the ASU, which we will examine in Part 2 of the session in more detail
19 Pre-Steps — Analyze BW Readiness (cont.) The idea of the checklist tool is that you run it several times throughout the projectOnce before you start, then periodically as you resolve issues and upgrade requirements, and then finally when the system has been migrated to HANAThe checklist tool also has specific checks for the HANA system that can help you identify any issues before turning over the system to end users
20 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
21 Some Hardware Options for HANA There are many certified HANA hardware vendors with over a dozen different products.Some boxes can be used as single nodes with others are intended for scale-out, scale up, solutions for large multi-node systems
22 A HANA Hardware Example In this box, we see the inside of an IBM x3950 HANA systemThe system basically consists of memory, disk, processors and network cardsThe hardware vendor will install, connect, and do a health check on your system before handing it over to you. A 3-year service plan is also normally required.
23 SAP QuickSizer for HANA There are three versions of the tool for each version of SAP HANAThe QuickSizer for the Business Suite allows you to size for specific modulesThe second QuickSizer version is for SAP HANA on SAP NetWeaver BWThe last is for those who want to use SAP HANA as a standalone platform for in-memory data (i.e., using SAP Data Services to load data to)SAP’s QuickSizer for SAP HANA is available at
24 SAP QuickSizer for New BW HANA Implementations If you’re using planning in SAP NetWeaver BW, enter the info here. The fields marked with * are mandatory.For H-PLAN-1, enter the maximum concurrent users in the USERS field. The S.T. and E.T. fields are the start and end times for the processing.By entering this type of information, you’ll get estimates of loads on the SAP HANA system by time periods at the end of the sizing exercise.Enter the estimated number of information consumers (H-BW-INFO), business users (H-BW-BUSI.), and experts (H-BW-EXPER). SAP suggests a ratio of 71%, 26%, and 3% for each user group, but you can enter your own mix if you have better estimates.
25 SAP QuickSizer for New BW HANA Implementations (cont.) In SAP Note , SAP BW on HANA: Sizing SAP In-Memory Database, there are programs you can run on SAP NetWeaver BW to get good sizing numbers.The shell script is located in the file get_size.ZIP, which should be extracted and executed along with the file load_RowStore_List.SQL for size input to TABLE 4.The exception to this approach is the IBM DB2 database on the z/OS. For this combination, there is an ABAP program instead.NOTE: The QuickSizer should only be used for new HANA implementations and not for migration of existing systemsIn TABLE 3, you estimate how many records will be loaded to SAP NetWeaver BW periodically. In this example, we’re estimating that 279,994,355 records will be loaded each day between noon and 1pm.
26 SAP QuickSizer for New BW HANA Implementations (cont.) Enter the InfoCube and DSO information. The max number of dimensions (DIM) you can enter for the InfoCube is 13. The three fixed dimensions of BW are already included, so just enter the free dimensions.The field KEYF. refers to the number of key figures in the fact table of your InfoCube, while the field COM. is the estimated compression.If you don’t have better estimates, a rate of 5 may serve for the initial sizing before you refine the estimates with your hardware vendor.In the INITIAL LOAD field, you enter the number of records in the existing InfoCube, and in the PERIOD. UPLD field, you enter the number of records you estimate will be loaded periodically.
27 SAP QuickSizer for HANA — Output This SAP HANA sizing example calls for 1.6TB of memory.Because we’re unlikely to get this in a single server node, we’ll have a multi-node system.In this case, SAP HANA for BW will deploy the master data, ABAP system tables, and row store data on the master node. The other connected server node(s) will contain the InfoCubes and DSOs.
28 SAP BW on HANA Sizing Tool for Existing BW Implementations SAP has released an updated tool that generates a report significantly better for sizing SAP BW than using the QuickSizer. This tool should be used by all existing BW implementations for sizing (QuickSizer is only for new implementations).This program takes into consideration existing database, table types, and includes the effects of non-active data on the HANA system.To increase speed, you can suppress analysis tables with less than 1 MB size.The higher precision you run the estimate at, the longer the program is going to run.With 12 parallel processors and 10TB database, it is not unusual to see minutes runtime
29 SAP BW on HANA Automated Sizing Tool Since timeouts are common when running the sizing program, you can temporarily change the parameter in rdisp/max_wprun_time to 0 in BW transaction RZ11. Finally, you estimate the growth for the system as a percentage, or as absolute growth.The output is stored in the file you specified and the file can now be ed to hardware vendors for sizing input and hardware selection.This program is referenced in SAP Notes and on the Service Marketplace
30 Rule Of Thumb Approach to Sizing HANA — Memory Memory can be estimated by taking the current system size and running the programs in “get_size.zip” in SAP Note to get row and column store sizes for your systemThe 50 GB is for HANA services and caches. The 1.5 is the compression expected for rowstore tables and the 4 is the compression expected for column store tables. The 2-factor refers to the space needed for runtime objects and temporary result sets in HANA. Finally, the term “existing DB compression” is to account for any compression already done in your system (if any).Memory = 50 GB +[ (rowstore tables footprint / 1.5) +(colstore tables footprint * 2 / 4) ] * Existing DB CompressionRemember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases
31 Rule of Thumb Approach to Sizing HANA — Disk The next item you need is disk space, which can be estimated by the following:In this example, you need 4 x 710 GB disk for the persistence layer and about 710 GB for the logs. This equals around 3.5 TB (don’t worry, disk space of this size is now almost “cheap”).The persistence layer is the disk that keeps the system secure and provides for redundancy if there are any memory failures, so it’s important not to underestimate this.Disk for persistence layer = 4 MemoryDisk for the log = 1 MemoryRemember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases
32 Rule-Of-Thumb Approach to Sizing HANA — CPU The CPUs are based on the number of cores that you include. For example, 10 core CPUs now exist (depending on when you bought your system).If you have a single node with 4 x 10 cores, you will have 40 cores and can handle 200 active users on that hardware node, and quite a larger number of named users.CPU = 0.2 CPU cores per active userRemember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases
33 A T-Shirt Model for Sizing HANA on BW A T-shirt model is a quick way to get some basic ideas on what a system may look likeWhile very inaccurate for sizing, it provides basic information for those just starting to consider SAP HANAThe number of processors are largely driven by the number of users and usage patterns. Serious consideration should be made before buying hardware.
34 Summary of HANA Sizing Approaches Approach Quality of Estimate Effort RequiredT-Shirt Sizing Sort of “OK” Very LowRule of Thumb Better LowSAP QuickSizer Much better (new implementations only) HighSizing for BW program Excellent (for existing BW systems) Moderate/LowWork with your preferred vendor before ordering your hardware or finalizing your budgetsSAP Note (ABAP report to help with BW on HANA Sizing)SAP Note (SAP NetWeaver BW Migration Cockpit for SAP HANA)SAP Note (SAP BW Checklist for Migration),SAP Note (Sizing the Master node)
35 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
36 Staffing a HANA Migration Project — Small Team System ProfileRaw data size: TBComplexity: MediumDataStores:InfoCubes:Queries:Duration: weeksEnvironments:Risk aversion: MediumOther usage: Integrated PlanningThe test team was dedicated for 9 weeks during the migration of QA and Prod environmentsThe test team from the business was comprised of experienced users of the BW system and needed minimal trainingHANA Optimization of InfoCubes was done for SD reports only in this migrationThis organization was using BWA 7.0 and retired it as part of the HANA migration, thereby saving licensing costs for this platform
37 Staffing a HANA Migration Project — Medium Team System ProfileRaw data size: TBComplexity: MediumDataStores:InfoCubes:Queries: ,300+(incl. BOBJ)Duration: weeksEnvironments:Risk aversion: HIGHOther usage: NoneThe testing of core queries in BEx and Web Intelligence was done by the businessThe data reconciliation and process chain testing were done by dedicated resources in each teamThe team must be staffed with experienced resources. HANA training for team members and hardware installs should be in place prior to project start.
38 Staffing a HANA Migration Project — Very Large Team System ProfileRaw data size: TBComplexity: HighDataStores: ,300+InfoCubes: ,720+Queries: ,600+Duration: mosEnvironments: 4Risk aversion: HIGHOther usage: APO, IP,BPCThis assumed minimal additional functional optimization
39 Budgeting a HANA Migration Project — Training Remember to budget for HANA training employees before the project startsClass schedules are found at: training.sap.comOn average, plan for $3,000 to $6,000 to train each team member plus traveling costs if you don’t use e-learning
40 On-Going Support Tasks and Staff Required Major on-going support tasks consists of:User and role maintenanceSecurity maintenanceBackup and disaster recoveryLoad balancing, monitoring, and hardware maintenanceSoftware patches and notes for HANA, BW, and componentsCleanup, NLS, archiving, and log deletionsTransports, table copies, system copies, and data copiesPeriodic system upgradesWhile most tasks are similar to the old relational database systems, the way we do this is quite different. Make sure your HANA support staff is onboarded early and trained before cut over to production of your migration project.
41 On-Going Support Tasks and Staff Required The staffing roles required are normally:One basis resource for system admin and monitoring for every 4-5 environments (Do you need 24-hour support?)One resource, part-time, for security, roles, and access maintenance (depends on number of users)One BW resource for monitoring loads, issues, and fixes (could be part-time role in small and mid-sized organizations)The support of HANA is actually easier than the traditional Basis support. Most functions are done in a single interface and many of the tasks are significantly simplified due to the inherent performance of HANA.
42 HANA Demo — The SAP BusinessObjects Front-End Tools on HANA
43 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
44 1. Lessons Learned: Buy Hardware Early The typical lead time for the basic HANA appliances is as little as 4-8 weeksHowever, for large scale environments, or multi- node environments, the lead times can sometimes be as long as weeksThis is particularly true for virtualized systems managed by a third-party who has to set them up, configure backup, and learn the new technologyGet a small team on-site early for planning, budgeting, and sizing; and hold off staffing all team members from the business until you get a confirmed hardware delivery date
45 2. Lessons Learned: Get the Right Team Members While there are many with basic certifications in HANA, the pool of qualified experienced resources is limitedGreat HANA resources are most likely working on another project alreadySo, if you want the best, be prepared to give your implementation partner several weeks lead timeDo you want “who is available” or “who should be available” on your project? Be prepared to give your implementation partner longer lead times than usual.
46 3. Lessons Learned: Include Training for your Staff There are a lot of “myths” and beliefs about HANA that your have to address earlyBefore you start the project, make sure your implementation partner has a formal written training plan on how they will provide knowledge transferInclude your support staff and Basis people in all project discussions from the first planning sessionMany are “fearful” of a new technology and are unsure how this will change their work. You should provide real demos and workshops early so that everyone knows what is happening and how HANA will change their day-to-day jobs.
47 4. Lessons Learned: Hardware Sizing Should Include Growth Some customers forget that sizing would be for 3 years out and not based on current system size aloneYou should have a sizing estimate that includes new projects, data growth, and data retention policies, as well as periodic scheduled clean up activitiesFunding for hardware is sometimes easier in a project mode, and many companies plan for 30-50% more capacity as part of the initial rollout if they can afford it
48 5. Lessons Learned: “Master-Node” Size Some hardware vendors want to maximize the number of processes available to the users. They can do this by using multiple smaller nodes with many processors in each.The drawback is that all of your row and master data stores may not fit on the small node as you grow.Pay very careful attention to the row-stores sizes and the master data growth when buying hardware. You don’t want to have to upgrade shortly after go-live.
49 6. Lessons Learned: Create an Ecosystem of Experts Having access to the best and brightest within SAP, consulting firms, and industry experts is key when issues or questions ariseThese people are very busy and are often engaged on many projects as “supporters”Formally assign a team of 2-3 experts to come in and meet with your team a few times during the project planning and execution. Make sure these project advisors are hands-on and that they can act as technical go-to resources for your team if questions arise.
50 7. Lessons Learned: Think BIG A HANA implementation should not be treated as a replacement project. It is an enabler …Plan ahead on what you are going to do with the new technology, e.g., mobile, forecasting, planning, BI dashboards, customer and vendor facing analytics, market basket analysis, stratification, data visualization, etc.Early in the project create a 2-3 year strategic plan that demonstrates to the leadership what you are going to do with this new technology. Present it as new capabilities not just how fast it is …
51 8. Lessons Learned: Plan for Reporting and System Consolidation After go-live you should have planned for howyou are going to migrate all reporting and management analytics on to HANA and away from datamarts and standalone expensive systems that are not integrated into the long-term visionYou will most likely have to do some “selling” to your fellow employees and be prepared to give them “free access” to your HANA systemHANA is not just for BW or Business Suite. It is an enterprise platform for integrated analytical and data processing. You can give developers access to your system and they can build their own Agile marts inside HANA, even if they don’t want to use BW.
52 9. Lessons Learned: Near-Line Storage Can Save Millions Removing data that is not needed on a daily basis from your system and placing it on near-line storage instead of in-memory can save you millions.In one project a customer took his system from 112 TB to 38 TB by simply moving data to near-line storage (NLS)An Asian firm took a 3.8 TB BW system to “only” 900 GB after cleanup and an NLS implementationThere are many NLS solutions available that can save you big bucks by reducing the need for multi-node, multi-terabyte HANA systems. Take a serious look at SAP IQ solution for NLS. It is tightly linked with HANA already.
53 10. Lessons Learned: Save Money with MCOD and MCOS You may not need separate hardware for sandbox and development environmentsUsing Multiple Components One Database (MCOD) and/ or Multiple components One System (MCOS) you can simplify the number of hardware environments you needSAP NetWeaver BW on SAP HANASAP Finance and Controlling Accelerator for the material ledgerERP operational reporting with SAP HANASAP Finance and Controlling Accelerator: Production Cost PlanningSAP Rapid MartsSAP COPA AcceleratorSAP Operational Process IntelligenceSAP Cash ForecastingSAP Application Accelerator / Suite AcceleratorSmart Meter AnalyticsIn addition to custom developed datamarts, all items above can run in an MCOD setup (see SAP Note for more details)
54 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
55 Budgeting a HANA Migration Project - Systems There is a set of items you need to budget for. From a system perspective, you will need to consider:Hardware quotesGive at least two vendors your sizing estimate and ask for quotesVendor SupportMake sure your hardware vendor includes 3 years of support in your purchaseUpgradesPlan and budget for any BW upgrades required before going to HANA (7.4)Do the pre-steps BW cleanup we outlined earlier as soon as possible and then the formal sizing effort before requesting a hardware quote
56 Mid-Size Budgeting Example HW Quotes — HP This example quote is for a mid-sized 512 GB memory box with 4 x 10 core CPUs and 7 TB disks based on Hewlett-Packard’s high-end DL-980 BoxIncluding all services and support agreements, this quote is only $150, (1 box)Certified HANA vendors such as HP, IBM, Dell, Cisco, NEC, Hitachi, and Fujitsu have dedicated staff to help you get a detailed quote in a matter of days
57 Small Example HW Quotes — Dell This example is a quote for a smaller 128 GB Memory Box with 2 x 10 cores and is based on Dell’s R910 platform for a HANA sidecar usage for less then $40,000 (including tax!)Most of the smaller HANA systems from the other vendors are similarly priced and depend on the number of boxes you buy, existing discount agreements, and the size of the deals you are requestingExpect competitive bids for larger systems and similar vendor pricing for similar capabilities
58 Budgeting a HANA Migration Project — People Experienced HANA consultants are in very high demand, so budget $1,600 to $2,300 per day for these resources (US)Testers with BW experience and some HANA training can be found for more normal consulting ratesSolid hands-on migration experience with SP4, SP5, and higher is key for SAP BW to HANA migrations. Don’t confuse this with a HANA “sidecar” experience. It is very different.When staffing your HANA project, don’t schedule the start date before you get your staff. You want the best resources, not whoever is available.
59 A Milestone ExampleFirst we clean the BW system, size the box, and do a health check of the overall system to finalize all stepsThen we order hardware and get the vendor to install the hardwareBe prepared for 4-6 weeks lead time for hardware deliveryWhile waiting for hardware, upgrade BW, apply SPS, and execute training
60 A Milestone Example (cont.) Start with refreshing the sandbox from the development environmentMigrate the Sandbox carefully, and spend time on testingDo not rush this part of the project, and document all activities (create a migration script of all activities)Plan “contingency” time for any delays and do a cutover on the weekend
61 What We’ll Cover Background and HANA demo HANA implementation options Hardware sizing and planningHANA project staffing, roles, and responsibilitiesTop 10 lessons learned from SAP HANA implementationsCreating realistic budgets and project plansWrap-up
62 Where to Find More Information Bjarne Berg and Penny Silvia, SAP HANA: An introduction, SAP Press; 2nd edition (May 1, 2013)SAP’s main page for all SAP HANA related informationPowered by HANA demosSAP NetWeaver BW Powered by SAP HANA Community
63 7 Key Points to Take HomeThere are programs to do pre-readiness checks for an ERP and BW system for migration to HANAA BW Migration Cockpit is now available to assist in the tasksWhile one is more common, there are actually four possible approaches to the HANA migration projectThere are currently seven different certified HANA vendors and many options for small, medium, and large systems — Make sure you get a competitive bidBudgeting should include HANA training and system cleanup, as well as support staff required or reorganizedMost HANA projects can be done in a matter of weeks.Only extremely large systems may require 4-7 monthsIn the next session we will look at the project tasks for executing a HANA migration, an install, and demo the most common HANA development work steps
65 DisclaimerSAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet™®, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.