1. Introduction

Whilst HANA is an incredibly stable database and ECC runs very well on it, HANA will be a new database to the organization and it is best to start with a system which is not transactional in its nature. It is always recommend doing BW on HANA first - it allows the training of staff, implementation of infrastructure, backup, high availability and disaster recovery, monitoring processes etc. Once BW is in, the organization will have the maturity to support HANA, and ergo the maturity to migrate Suite.

If getting live on Suite is a priority then organizations can run parallel projects, going live with BW first, and with Suite 4-8 weeks later (which is idle). Implementing BW on HANA first is just a better way to build organizational process intelligence around HANA. If the company doesn’t have BW then just need to be a little more structured around how to build that capability. Things to consider includes (but not limited to) architecture, sizing, networks, updates, backup/restore and monitoring. There are processes like support and incident management, change management, release management and transport management and people-centric items like support personnel and DBAs. Just the same as any other system.

2. 10 Strategies Recommanded

Below are the recommended strategies (categorized into 10) in order to be succeeded in any major ERP implementations.

1. Build an Integrated Schedule

2. Build mid-level and detailed plans

3. Have a communications plan and stakeholder map

4. Have a production-sized sandbox/pilot

5. Consider having some skin in the game from SAP

6. Join the Customer Advisory Council

7. Change Many, Test Once

8. Adopt Solution Manager

9. Test, test and test!

10. Build an integrated cutover plan

1. Build an Integrated Schedule with Optimized System Architecture

This is important for any project, but with Suite on HANA it is essential. In any streamlined organization, there will be connected systems like Supply Chain Management, forecasting systems like BPC, reporting systems like BW, third party interfaces and integration. There will be a raft of front end tools like SAP GUI (Graphical User Interface), Portals, Web Stores. Cloud integration to SuccessFactors or Ariba or Salesforce.

This involves a huge integration part with teams from Basis, Systems Architecture, Infrastructure, Networking, Custom Development, Test Management, Finance, HCM and others. Suite touches the whole business. Better to build always an integrated schedule with an optimized systems landscape (fig-1) that describes the project that can be displayed on a single monitor screen, so everyone can understand what is happening and how it is happening.

Figure 1. Real-time systems (Integrated SAP and non-SAP systems) along with DB

Make sure that the integrated schedule contains a reference to other releases or projects which will run concurrently, so one can track them, any change freezes, or dependencies. It's important in an integrated schedule to ask teams not to pad their times, but to provide realistic estimates for how long tasks will take. Then, as a project manager, one can add in contingency which will allow some slippage for issue resolution.

2. Build Mid-level and Detailed Plans

It is always good to have 3 levels of plans for a migration project. The integrated schedule which typically describes the project on a weekly basis is the first.

The second is the detailed plan, which is at a task-time-resource level. Detailed plans are very hard to read, and only experienced project managers really know how to work with them and interpret them, building Gantt charts with complex dependencies, resource costing, WBS and allowing burn down charts and earned value calculations. Typically only the PMO needs to use the detailed plan.

The third is a mid-level plan, which is at the task-day-team level. This allows to explain the project team what they need to do and when? How? And Why? Because this allows to squeeze the plan and shorter projects have better time to value and lower cost.

3. Have a Communications Plan and Stakeholder Map

This can be very straightforward, but a Suite on HANA project will have eyes from many places in an organization. Decide who, how and when to communicate with, and do it regularly. CIOs and other senior leaders often like a short weekly update - rule of thumb is it should be readable with one swipe of the finger on a smart phone.

A periodic meet of all-hands call can be useful too - for anyone interested in getting an interactive update. If it communicates regularly to all stakeholders which dramatically reduces the chances of misinformation spreading and causing disruption to project.

4. Have a Production-sized Sandbox/Pilot

As an evangelist of In-Memory Computing and the latest trends in BI, Visual BI has adopted a market-leading approach in helping enterprises assess, plan and integrate HANA into their BI architecture. By having prior hands-on and in-depth expertise in this space, and can guide HANA initiatives end-to-end covering strategy, consulting, licensing, implementation, reporting, performance optimization and support.

The details of how this works will depend on the size of organization, landscape and complexity. But once entering the main development system, it is going to have a change freeze. The best way to keep this change freeze short is to be prepared, and can't be prepared unless one have previously completed a production-sized migration. So, take a system copy of the production integration environment (BW, ECC, PI etc.) and then migrate the ECC system to HANA. Let Basis team do this 2-3 times before releasing it to the technical and functional teams if possible, so they can hone their process.

It's also possible to do this early on, prior to purchasing all the hardware (buy one sandbox which is roughly sized using the SAP Sizing Guide). If one can do this, can be validated sizing to have confidence in Bill of Material, and do things like archiving and data aging to reduce the hardware requirements.

5. Consider having some Skin in the Game from SAP

SAP Active Global Support (AGS) and Professional Services Organization (PSO) have merged into one group, called ONE Support. Regardless of whether there is Max Attention, Active Embedded or Enterprise Support customer, one can contract them to be involved in the planning and support of the project. In particular they have a service catalog available which has a service for planning and for custom code management. There are free services for pre- and post-go-live.

Having SAP bless to the architecture, sizing and plan is a big bonus and they have good quality resources for this sort of work. In addition, there is a HANA Ambassador program available in North America which provides a resource which reports into the Global Customer Office at SAP. It's a good way to ensure project gets the attention it requires.

6. Join the Customer Advisory Council

There is a HANA Customer Council run by Scott Feldman which meets periodically. It's available free of charge for senior IT folks and project sponsors to go and talk to other customers and hear what's going on in the ground, and gain some additional confidence.

7. Change Many, Test Once

This goes against some of the views of IT folks but, good strategy is to change-many, test-once approach. SAP has excellent tool for HANA migrations called DMO, which will upgrade, patch, perform a Unicode conversion and migrate to HANA in one step, all without touching the source system.

This does increase the amount of effort in root cause analysis of problems (which caused the problem) but it provides a single test landscape. One of the biggest risks in any project is inadequate testing, and it allows to have the conversation with the test team. Reduce the number of UAT runs.

8. Adopt Solution Manager (SolMan)

Solution Manger (fig-2) in a HANA migration, which has lots of useful pages including the tooling available for HANA Migrations. This includes the Custom Code Management Cockpit (CDMC) which tells exactly what code has been customized and will break, Usage & Procedure Logging (UPL), which tells which code is used and how much and Clone finder, which tells what transactions have been cloned to custom, and how customized they are.

Custom code is not recommended in HANA migrations, especially clones, because cloned transactions won't get updated with all the nice HANA optimizations that come as part of SAP ERP 6.0 EhP7.

Remember to patch to the very latest version of Solution Manager.

Figure 2. Solution Manager (SolMan) user interface (UX)

9. Test, test and test!

Prepare a good test strategy. Make sure separate phases for unit, integration, performance, stress and user testing? Check if the organization is using any classic testing tools (automated)? Test plan (Fig3) should be very well executed.

How wide is the test coverage? Does it include front end solutions like portals and external web access?

And remember that there will be some effort in custom code restitution, so leave time to do this. Whilst HANA is an amazing database, it is a columnar database and some custom code will not run optimally if it was poorly written. Row-based databases can be much more forgiving than columnar databases for shoddy code. A comparison of traditional RDBMS systems and HANA is given below (fig-4).

Figure 3. Test plan for a successful integration/migration project

Figure 4. HANA Vs regular RDBMS

10. Build an integrated cutover plan

There needs to be "the plan"! The way we do this is to build a cutover spreadsheet with a numbering system and forecast times for every activity, and an integrated playbook which matches the numbering system in the spreadsheet to the table of contents. Traditional cutover plans (Fig 5) are good enough to maintain the project timelines.

Figure 5. Project scope and plan

3. Conclusions

Our experience so far exhibits that HANA is a phenomenal alternative than the exemplary database and has enormous potential not pretty much as a database. Late experience grabbed between the movement task being executed now for one of our customer’s shows that running the ERP framework on the HANA stage passes on significant execution points of interest after relocation, and further streamlining can duplicate them.

Based on the 10-point strategies discussed, every project should come up with and follow these in order to achieve better results.

1. Build an Integrated Schedule

2. Build mid-level and detailed plans

3. Have a communications plan and stakeholder map

4. Have a production-sized sandbox/pilot

5. Consider having some skin in the game from SAP

6. Join the Customer Advisory Council

7. Change Many, Test Once

8. Adopt Solution Manager

9. Test, test and test!

10. Build an integrated cutover plan

ACKNOWLEDGMENTS

This case study was supported by Maria LeBeau (Director, Supply Chain Management, Spectra Energy Corporation) and Christopher Collins (Manager, ERP Legacy Systems, PSCM – Procurement and Supply Chain Management, Spectra Energy Corporation, headquarters, Houston, TX). We thank our colleagues from Spectra Energy Corporation who provided insight and expertise that greatly assisted the research, with their willingness to support all of the interpretations/conclusions of this paper.

Author would also like to show gratitude to the Phillip Dunn (Manager, Compliance and SOX), Jim Ischy (Manager, MDM technologies, Spectra Energy Corporation) and Irfan Ahmed (Manager, Business Process Improvements and Implementation, Spectra Energy Corporation) for sharing their pearls of wisdom with us during the course of this case study, and we thank the reviewers Veloz Rene (Reporting Data Expert, Spectra Energy Corporation) for their so-called insights. We are also immensely grateful to Antti-Jussi Pohjonen (Manager, Supply Chain Management, Spectra Energy Corporation) for his comments on an earlier version of the manuscript.