SAP implementation is the process of designing, building and tuning an SAP landscape. SAP can be implemented as a brand-new landscape, created from scratch (greenfield) or built by upgrading, reconfiguring and migrating an older, existing SAP landscape (brownfield). In either case, SAP implementation is an iterative process, where the team repeatedly plans, tests and refines the system, so that it’s ready to support the tenant at go live. Successful SAP implementation requires a partner who understands both the business and technical requirements of the tenant.
Expert Insight: Dave Hall, Director of Professional Services
SAP implementation covers a lot of ground. Each SAP landscape is unique, with its own organization-specific configuration, and combination of SAP and third-party modules. Organizations can run ERP on SAP’s own HANA database as Suite on HANA or S/4HANA, or on top of another database as SAP ECC. They can include a huge range of third party applications, hosted anywhere the tenant needs them to be.
Companies are unique too. Your industry, segment, business logic, and other needs can require extensive customization. SAP implementation methodology has been developed over time to cope with this wide range of scenarios. With the right partner, you can build and design a landscape that perfectly fits your needs.
What Are the Steps for SAP Implementation?
SAP has a standard set of procedures and practices for implementation called Accelerated SAP, or ASAP methodology. ASAP methodology applies not just to implementing a full SAP landscape, but to smaller SAP projects, such as upgrading. It has five basic steps — project preparation, business blueprint, realization, final preparation, and Go Live support:
Project Preparation: This is the initial planning phase. During project preparation, you get ready to execute the project — identifying objectives, priorities, and scope, gaining stakeholder support, retrieving resources and performing other preliminary tasks.
Business Blueprinting: In this stage, you define more exactly the business processes that your landscape needs to address. Your team needs to understand the business logic your organization depends on, so that they can provide an SAP solution that meets that logic.
Realization: In this phase, your team uses its business blueprint to build, test and refine the landscape. Up until this point, the process has been headed up by the functional team, who are concerned primarily with what the system does. In realization, the technical team starts to take a bigger role. Technical partners like Symmetry are responsible for all the meticulous work to make sure the landscape functions as designed — not just in a testing environment, but in real-world conditions after the project is completed.
Final Preparation: This is where your team gets ready for the migration and go-live. They perform a range of tasks like migrating your data and stress testing your system, to make sure everything is ready. The goal is a smooth, uneventful migration and go-live.
Go Live Support: This is the main event! By go live, your team should have timed every stage of the migration, gamed out everything that could possibly go wrong, and created contingency plans for any possible problems. Now, all that’s left to do is to follow the plan, and switch your business to the new landscape.
What is SAP Technical Project Implementation
SAP technical implementation is the iterative process of building the landscape. The technical team comes in once the functional team has defined the scope of the project, and works with them and the client to turn it from a design into a fully-functional production landscape. The steps can vary a bit from project to project and provider to provider, but generally it takes about 7 phases:
- Onsite Initiation: The technical team starts by reviewing the project with key stakeholders from both the client and the functional team. They’ll ask a lot of questions about the project to make sure no major details have been left out.For example, the technical provider will ask what banking partners and other third parties the landscape needs to be connected to, and how they are connected to it. This allows the technical partner to make sure the functional team hasn’t left out any needed connectivity. They may need to work with other stakeholders to revise the project, in order to address any gaps in the SAP implementation plan.
- Data Center and Network Setup: If the technical partner is providing hosting for the tenant, this is where they’ll provision and configure it for the client. If they’re providing disaster recovery, they’ll set it up as well, and link it to production.
- SAP General Activities: In this phase the technical provider will handle a few more preliminaries to get ready for the implementation. This includes obtaining various SAP credentials for the customer, and downloading software from SAP.
- Sandbox Migration: From here on out, the project is a series of migrations. Each one develops the SAP landscape a little more, in preparation for the final production migration. In sandbox, the team migrates the core landscape and makes sure there are no major problems.
- Development Migration: The team irons out any problems that were found in the previous phase, and connects non-SAP systems.
- Quality Assurance Migration: Quality assurance is a practice run for production. The team nails down the timing for each step, and makes sure everything is ready for the actual migration.
- Production Migration: In this phase, the team migrates the SAP landscape, and goes live. This requires some downtime to switch the business over from the previous landscape, so it is usually scheduled over a weekend or at some other time of low demand.
What is the Difference Between SAP ECC and HANA?
ECC and HANA are different types of things: ECC is a software suite, while HANA is a database. SAP Enterprise Central Component (ECC) is SAP’s previous generation of ERP software.
SAP didn’t have its own database back then, so tenants could choose their own third-party database to run the software. This situation persisted for decades, until SAP released their own database — SAP HANA — in 2010. As an in-memory, columnar database, HANA has serious performance advantages and other benefits over previous generations of databases. SAP has spent the intervening years, reengineering their software to take full advantage of the new database.
Customers now have two basic choices for SAP implementation: they can run the old R/3 software as Suite on HANA, or they can run SAP’s current generation of ERP — S/4HANA. SAP will stop supporting ECC in 2025, so you’ll need to get to S/4 fairly soon. However, in some cases it may make sense to move to Suite first, before upgrading to S/4HANA.
How is Greenfield Implementation Different Than Brownfield Migration?
As we mentioned in the intro, you have two basic choices for your landscape: build it from scratch, or upgrade and migrate your existing landscape. For new businesses, greenfield is the only choice — there’s nothing to upgrade, so you have to build your landscape from scratch. In most other cases, you have two possible paths to the same destination. There are a lot of considerations and factors, but it all comes down to one basic issue: what’s the easiest way to get there?
Brownfield migration is a complex, multi-stage upgrade and migration — it’s what you do if you’re in an SAP landscape that’s functional, but outdated. Greenfield implementation is for situations that take more work. Factors that might influence the decision to use a greenfield SAP implementation include:
- Records that are corrupted, inconsistent and/or no longer necessary
- An extremely old or outdated landscape
- Heavily customized legacy software
- Major changes in tech strategy (e.g. from a different ERP Suite to SAP)
Your partner can help you sort through all the factors, game out multiple upgrade scenarios and choose the most economical option.
How Do I Choose SAP Hosting?
Your SAP implementation can be hosted in any landscape you choose — on premise, in a private or virtual private cloud, on the public cloud or in a hybrid landscape. Historically, that wasn’t really the case. While the public cloud has always been an option for testing and development the consensus among SAP professionals used to be that you needed the configurability and stability of the private cloud or on-premise hosting for SAP production.
Now, you can host SAP production pretty much anywhere you want — the public cloud is stable and configurable enough to meet your needs. Similarly, the private cloud is scalable and affordable enough to host non-production and non-SAP workloads in the private cloud, and in some cases actually has lower TCO than the public cloud.
So, how do you choose where to host your SAP implementation? There’s no simple answer — you’ll have to take a close look at your needs, goals, assets and resources and choose what works for you. Some factors to consider include:
- What are you doing? Your use cases have a big effect on hosting for your SAP implementation. For example, if you need extremely low latency, your public cloud options might be limited. You’ll need to consider hybrid cloud hosting or a dedicated high-speed connection to a private cloud. On the other hand, for use cases that require massive amounts of data storage and burstability, the public cloud can be a better option.
- What have your invested in? You need to look at concrete investments in software, hardware and services. If you’ve just put a lot of money into servers, for example, you’ll probably want to stay onsite, or move to a hybrid cloud in stages, rather than migrating straight to the cloud. Therefore, you’ll have to look closely at the hybrid support offered by various cloud hosting options.
- What do you know? Your human resources and skills also need to figure into your calculation. For example, if your company has really excellent Microsoft resources with SAP cloud experience, there’s a good chance Azure is a better option for you than AWS.
- What specialized needs do you have? Are you in an industry with extremely strict compliance needs? Are you using an OS or hardware that’s not widely supported? If so, it’s likely you’ll do best in a managed private cloud from a provider with a specialized skillset. For example, if your company is on the IBM iSeries, moving to the public cloud can require an extensive (and costly) transformation. You’ll be better off in Symmetry’s IBM iSeries cloud or a similar hosting environment.
- What is your appetite for risk? A properly designed and run SAP implementation is very reliable, but there are still risks. Cloud services can suffer slowdowns and outages. Natural disasters and hardware failure can threaten your data. Human error or malice can damage your landscape.You can use your hosting to mitigate many of these risks. For example, by creating a disaster recovery plan, with a backup SAP hosting in a different geographic area than your production landscape, you can reduce the risks posed by a natural disaster. High availability can minimize the risks of any downtime, by running a duplicate of your landscape, updated in real time. If your primary production server fails, your backup server will immediately take over.
How Do I Choose a Provider Play in SAP Implementation?
Your managed services provider is the most important factor in the success or failure of your SAP implementation. Their role isn’t just to provide technical assistance — they should be a partner from the planning stages through steady-state operation. The right provider will be able to bring all your stakeholders together, and devise an approach that meets your business, strategic, technical and budgetary constraints while minimizing downtime and disruption.
Range of skills is one of the most important considerations. Your provider should understand every aspect of building and operating your landscape, even if you plan to keep certain tasks in-house. That includes Basis managed services, SAP security and compliance. They should also have extensive experience building SAP implementations. Having a complete range of skills ensures your team can account for everything, and means that, if someone from your team leaves, it won’t derail the project.
Similarly, even if you plan to host in the public cloud, you’re better off with a provider that has built and run their own private cloud landscape. Providers with their own cloud infrastructure understand the hardware behind SAP better, which helps them build and run landscapes more effectively. Additionally, an MSP that runs their own cloud and Basis managed services makes most of their profits on hosting and managing tenants, not on the SAP implementation itself. That means it’s in their interest to take the extra time to correctly design, test, and configure your landscape instead of rushing the project.
Finally, you need an MSP who can act as a partner. They should be an extension of your team, offering quick response and high touch customer service. Take the time to interview multiple partners and ask some tough questions, before committing to an MSP. Your business depends on your SAP landscape — it’s worth the time to find someone you can trust.