The Service Level Agreement (SLA) is a standard part of every SAP Managed Services Provider (MSP) engagement. So standard, in fact, that it’s become almost ignorable because all SLAs, in a general sense, read the same. But when something goes truly wrong with your SAP environment, what does your SLA really promise? Do you really know exactly what to expect? We’ve been in this business long enough to have heard horror stories about lack of support, despite having a signed SLA. That’s why we’ve rethought the SLA.
The myth of the “Five-9s”
One of the most common promises in an SLA is Five-9s (99.999%) availability over the course of the contract. Mathematically, that means your SAP platform will only be down 5.26 minutes a year. But in practical terms, the process of getting SAP up and running once a failure has occurred will take much longer. Think of a common scenario: Your system loses power—anything not saved was lost along with it. When the power comes back on it takes time for systems to reboot and launch again. While the power may have only been lost for three minutes, you will likely spend a few hours recovering your work and reestablishing normal operation. So while the Five-9 promise may sound appealing, the reality is any SAP failure will take significant recovery time.
Understanding the infrastructure
Production system SLA language generally assumes there is either High Availability (HA) or Disaster Recovery (DR) architecture in place to protect the system. The problem however is that many times the deployed DR or HA architecture can never meet the stated SLA. Don’t be satisfied just to hear there is an HA or DR configuration without knowing the specifics. Some MSP’s simply roll the dice and hope that a catastrophic event won’t happen, and if it does, their penalty payment isn’t large enough to hurt.
The MSP payment penalty clause
Knowing the real implications of SAP downtime, many MSPs will add a payment penalty clause to the SLA. These payment penalties are typically about 20% of the monthly MSP fee when the Five-9s promise is broken. But let’s face it, this would be a fraction of your business/operating costs for an SAP outage.
Keeping your MSP honest and your SLA realistic
Ask some hard questions, and don’t settle for easy answers.
- If there is an SAP outage, how long is the restart process? Here are some common steps that need completing (this process can easily take an hour):
- System crashes
- Alert goes to SAP administrator (how long until they notice the alert?)
- Administrator makes sure resources have failed over to new physical equipment
- Administrator manually starts the database (could take 10–15 minutes of roll- forward and roll-back processes)
- Administrator logs to database
- Database is verified
- SAP is started and opened up for users to log-in
2. What are the terms of a Disaster Recovery process
- Who declares the disaster in order for the disaster recovery plan to begin?
- What constitutes a disaster? Be careful here—you want to remain in control of your SAP environment, and not be at the mercy of your MSP
- What technologies are used to achieve the SLA? VM Technology, SAN technology, etc?
- If it’s a High Availability configuration, does it switch over automatically? Who verifies it?
3. What is the penalty clause? Is it in relationship to the financial impact on your company?
Four ways Managecore delivers a better MSP experience
- Managecore designs HA and DR architectures to achieve the real goal—SAP application availability.
- We’re willing to negotiate the penalty clause so you truly can see we have skin in the game if something goes wrong.
- We have a tried and true, simple agreement we can use to get started, so your SAP management isn’t held up by contract negotiations.
- We make real promises we can keep. We want to discuss all scenarios before the contract is signed so everyone has a clear understanding of what Five-9s really means.
Let’s start thinking about Service Level Agreements realistically. And the best way to do that is with a personal discussion, contact Managecore today.