Melchior Du Boullay

Outsourcing SAP: Choosing a Partner to Manage Our SAP Environment

Blog Post created by Melchior Du Boullay Employee on Feb 10, 2016

This blog was co-written with Dominik Herzig, VP of Delivery for US & Canada at oXya. It is the second blog in the “Outsourcing SAP” series. Please ask us any questions you have on the subject of “Outsourcing SAP”, either by posting questions in the Comments below, or sending us an email to Melchior du Boullay <mduboullay@oxya.com> or to Dominik Herzig <dherzig@oxya.com>.

 

--------------------------------------------------------------------

 

Last week’s blog, Outsourcing SAP: Should We Outsource Our SAP Environment?, was the first in a series of blog posts that focus on the subject of “Outsourcing SAP”. That blog covered various questions and concerns that customers ask about and examine, when they face a decision of whether to manage their SAP environment in-house, or use a partner that will provide SAP managed services for them.

Outsourcing SAP 1 - screen shot.jpg

 

We discussed in length the security concern, that each and every customer considers when thinking of outsourcing. The conclusion: security threats are similar, whether your IT is in-house or you manage it through an external managed services partner. We also discussed the responsibility aspect, and showed that using an outsourcing partner for your SAP systems did not mean that you, the customer, didn’t have any responsibility left; you still needed to manage the relationship, review reports, and more.

 

Then, we had a discussion on various types of outsourcing partners, and brought various examples regarding what you should be careful from (multiple outsourcing partners handling the same SAP systems, something that would slow the resolution processes), and what you should prefer (a specialized SAP outsourcing partner, with responsibility over your entire SAP landscape).

 

We also mentioned additional considerations that were relevant to outsourcing your SAP systems, such as infrastructure and headcount. We will expand on these two considerations, and possibly a few more, in next week’s blog.

 

Today’s blog deals with HOW to choose a partner for your SAP environment, once you’ve decided that this is the route you prefer. In today’s blog we’ll suggest some important criteria regarding what you should look for when interviewing partners and comparing between them; this will ensure that you select the best possible partner for you, to which you will outsource your SAP environment.

 

So how do you select your SAP outsourcing partner? What are some important criteria to check?

 

Here are a few things you need to look for when searching for an outsourcing partners. These criteria are important for any situation, but are especially critical with regards to the SAP domain.

 

SAP-specific SLAs

 

When dealing with SAP outsourcing, you must have specific SLAs regarding SAP response time, server uptime, frequency of backup, and so forth. General SLAs are not enough; for example, everyone that provides outsourcing services will give you some type of a guarantee for server uptime, such as 99% or 99.9%—depending on what you ask for an are willing to pay (uptime, at the end of the day, is based on the infrastructure on which the service is offered, including redundancy and DR systems, and the same for other SLAs).

 

However, a general uptime is not enough in the case of SAP. What you should be looking for are SAP-specific SLAs for server uptime. For example, a server may be up and running, but its performance is slow to a level which SAP determines as “bad” (and which would make the users’ experience miserable). SAP has clear guidelines regarding performance, running backups properly, and so forth – all that should be in the contract with your outsourcer.

 

At oXya, we typically guarantee our customer an average response time of under 1 second, across all dialog steps in the system (dialog steps are generated when a user interacts with SAP through the GUI). This is a measure of the system’s responsiveness to a user’s actions. SAP users will be frustrated if they click on something, and it takes the system 5 seconds to respond. The rule of thumb for SAP is that any response time below 1 second is good, and anything above 1 second is bad.

 

000038368138_high (Custom).jpg

Furthermore, on top of the general system performance SLA, we also have an additional SLA on the top 10 transactions, meaning the 10 most important transactions for the customer’s business. These transactions are defined by the customer at the beginning of the contract, and can be changed if the customer’s behavior changes.

 

Once these “top 10 transactions” are defined, their performance is being monitored and reviewed every month; we commit to the average performance of these transactions, that are highly important to the customer. Remember that we already provide an SLA of sub-one-second average across the entire SAP environment, as we mentioned above. By applying the same sub-one-second average performance to these 10 most important transactions to the customer, we actually commit to providing an even better response time and performance for these specific transactions.

 

Backups is another highly important SAP SLA. There’s a specific daily backup for our customers, and if we miss a backup we get penalized for it. Furthermore, our contracts are built in a way that the penalties for us increase. For example, if we missed a daily backup then the penalty is X, but if we missed 3 daily backups in a row, then the penalty increases exponentially. This ensures the customer that we will do anything, above and beyond, to meet the SLAs, provide a great service, and avoid the penalties.

 

As a general recommendation, it’s always good to have an SLA with an associated penalty to the outsourcer for these type of things. It will guarantee that you have some recourse if something goes wrong, plus the outsourcer will do everything possible to meet those SLAs and avoid the penalties. If there are no penalties associated with the SLAs, then the contract is not as constraining for the outsourcer, which is why you really want to have these penalties built into the contract. At oXya, we are so certain of the service level we provide our customers, that we suggest these penalties ourselves, sometimes to customers amazement.

 

And just for a full disclaimer, this penalty system unfortunately doesn’t work the other way around; meaning the outsourcer does not get a bonus for outstanding service (or at least we don’t have that in oXya contracts).

 

Reporting

 

Another SAP specific thing that is of high importance is the reporting prepared for you by the outsourcing partner. What kind of information do you get from your SAP outsourcer on a daily, monthly, and yearly basis?

 

normal_ian-symbol-positive.png

We recommend you ask the outsourcer for sample, standard reports that are being delivered to the customer, and ask about the frequency of these reports. At oXya, we have:

  • Daily reports that are sent in the morning and summarize the SAP system’s activity on the previous day; any incident, syslog, alert or error message that happened on the previous day would appear on that report. Also, any escalation, meaning any call to the administrator during off-hours, will be there. It’s really a status on the health of the system, on a daily basis.
  • Monthly report, which is more high-level. This report summarizes all the SLAs that we discussed previously, and shows if any of them were out of sync, compared to what we were supposed to provide. This report also includes capacity planning, meaning size of the database, growth of the database, how much space is left on the disks, whether we need to increase the size of the disk, and that type of info.

 

You want to make sure you get all the information you need, to feel comfortable with your SAP outsourcer. This is why at oXya, we build these daily and monthly reports together with the customer; we can add any metric the customer is asking for, to make the customer feel comfortable with our service.

 

The delivery model of your ‘standard’ SAP outsourcing partner

 

Another critical component for customers, and something you should examine in detail, is the delivery model of the SAP outsourcer you choose. You must be comfortable with the delivery model you’ll receive, and it’s not something trivial.

 

How does it usually work? Everyone working in IT have had the case where we needed to call for a specific issue, say a hardware issue. You call the number of a call center, and get someone who answers that call (that person can be located in Americas, EMEA or in the Far East). That person doesn’t really understand about the issue, it’s not her role to resolve it. She answers the call, writes down the issue, gives you a ticket number, and promises that someone will call you back. Then, you sit and wait for someone to call you back…

 

And you wait… and wait…

 

Sometimes, they even call you back. But quite often, no one calls back. And as you know from your experience, if they don’t call you back soon enough, you need to call them again, and ‘remind’ them of your issue, and that you need it resolved.

 

Standard Delivery Model.jpgHere’s what happens in the background with these standard outsourcers, and you can also see a graphical representation on the right-hand side of the slide:

  • You call the service number you have (a call center), and open a ticket with the issue you have.
  • Once you opened a ticket with the call center, the ticket goes to one team, that specializes in a specific area. That team determines whether it’s their issue or not. In the SAP world, let’s say you created a ticket because you have an issue with SAPyour Production is running slowly. That ticket gets sent to the SAP Basis team.
  • When that first team gets the ticket, they examine the issue. If it’s an SAP issue then they may fix it. However, quite often the SAP Basis team may say (internally, you don’t know about it!) “you know what, this doesn’t look like it’s our issue, we believe it’s a database issue”, and so the ticket gets forwarded to the database team.
  • Next, the database team looks at the ticket. Again, it may be a database issue, in which case they’ll fix it; but they may determine that it doesn’t look like a database issue, they think it’s a hardware issue, so they forward the ticket to the hardware team.
  • Now it’s the hardware team’s turn to take a look at the issue, and decide if they can fix it, or move it forward to the next team in line.

 

And so your ticket circles, between various teams (SAP, database, hardware, operating system, and more). Often, the ticket will move between teams located in different countries, and even different time zones.

 

The good news: at the end, the issue does get resolved.

 

The bad news (for you, the customer): every time your ticket hops between teams, you lose precious resolution time. Of course, there is no direct contact between you (the customer) and these teams, these are all internal hops. Unfortunately for customers, this is how things work among many of the SAP outsourcers (the huge outsourcers employ this model—the big and famous names that you know very well).

 

oXya unique delivery model: an extension of your IT team

 

The previous section described how service usually gets delivered in our industry. The way oXya works is completely different. We are unique, since we’re actually working as a real extension of your IT team.

 

First, we’re working on-shore or near-shore, as opposed to many other SAP outsourcers who provide off-shore services. When you call from the US to get support, you will speak with people located in either our Jersey City or our Denver support centers. For Canada, you will speak with people in our Montreal support center.

 

Not only is oXya working on-shore, but you have direct access to the people actually working on your systems. When you call, you will speak with the team leader, who leads the team working on your systems; that leader is an SAP expert, with many years of experience. You will not speak with a call center, simply because we don’t have such a thing. You always call directly to the team that is doing the work, and that team will identify the issue and solve it.

 

The way oXya is structured to provide service is the following. We have teams of 8-12 people in each team, and team members are located in the same support center, sitting together and collaborating continuously. Each such team is dedicated to a specific pool of customers. Each team only handles these specific customers, and are entirely dedicated to these customers. Furthermore, each team already has all the necessary skills and knowledge within the team—SAP Basis, databases, operating systems, hardware, networking, and more.

 

When a customer calls, the customer always calls and speaks with the same people on that team. Very quickly, the customer knows not only the name of the team leader, but also the names of all members of the oXya team that handle that customer; furthermore, all members of the oXya team know the people on the customer’s side.

 

Even more important, the oXya team will very quickly know everything about the various systems that the customer has, the criticality of the various systems, and all the complexities behind the various systems. This knowledge, and the intimate understanding of the customer’s systems, help to significantly reduce the time to resolution for each issue, and also help the team to proactively perform various activities that prevent potential issues.

 

This is why at oXya, we proudly say that we are always as close as possible to the customer, and that we really do work as an extension of the customer’s internal team. This is what we’ve been doing for many years, and for hundreds of customers.

 

oXya Delivery Model.jpg

Now let’s take the same example we brought in the previous section (with all the bullets), and assume that the exact same issue happens to an oXya customer. Let’s say that you, the customer, have an SAP issue, and you call oXya (see a graphical representation on the left side of the slide):

  • When you call oXya, you call directly to the team that you know, speak with someone whom you already know (let’s say John), and you tell John that you have an issue with the Production environment, and that it is running slow. Without further information, John already knows exactly which environment you refer to, and what is the criticality of that system. John also knows things like the exact built of this environment, in order to start working on a resolution. John is able to immediately connect to the system—while you (the customer) are still on the phone—in order to experience/replicate the issue by himself (slowness, in this example).
  • Then, the entire team handles the issue together, simultaneously checking it from all possible angles (SAP, database, OS, hardware, etc.), significantly reducing the time to resolution, compared to the 'standard' delivery model described in the previous section.

 

It’s really important, when you decide which outsourcer you want, to keep in mind that for some of the BIG and famous outsourcers out there, you don’t really know who will answer your phone calls, and what type of service you’ll get.

 

The experience that we’ve heard from numerous customers, who transferred to oXya from other BIG and famous outsourcers, is something like the following:

  • You call the call center, get someone offshore who sometimes understands what you want (and sometimes they don’t understand…); also, sometimes you will actually manage to understand what they are telling you; you may or may not get along with that person on the phone (language issues is a recurring complaint about some competitors).
  • Then, the person who answers the call may or may not know about your specific systems (usually not), and so begins the 'standard' support cycle we described in the previous section.

 

We are very proud of our delivery model, and see it as a key differentiator in providing service to our customers. Furthermore, we believe that this is something you should pay careful attention to when selecting an outsourcer, as this is one of the most critical things aspects of the service, and will affect the entire service levels you get, on a daily basis.

 

-----------------------------------------

 

Our next blog in the “Outsourcing SAP” series will discuss the questions of infrastructure & headcount – two subjects that all customers ponder when considering outsourcing their SAP systems.

 

And please remember to send us your questions about any aspect of “Outsourcing SAP”, and we will answer them in one of the upcoming blogs in this series. Please post your questions to the Comments below, or send them directly to us, Melchior du Boullay <mduboullay@oxya.com> or Dominik Herzig <dherzig@oxya.com>.

 

 

-----------------------------------------

oXya_HDS_logo_300dpi (Custom) (2).pngMelchior du Boullay is General Manager, Americas at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.

 

Dominik Herzig is VP of Delivery for US & Canada at oXya. Dominik has 10 years of SAP experience, starting as a Basis Admin, and then moving to SAP project management and to account management. Dominik was one of the first few people to open oXya’s US offices back in 2007.

 

oXya, a Hitachi Data Systems company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~600 SAP experts, who service more than 260 enterprise customers with more than 250,000 SAP users around the world.

Outcomes