It’s been quite a while since my last blog post and we’ve been pretty busy in the primary support department.
A major change for us had been the introduction of “Enterprise Support” (ES) and the offer to customers to not only get support with technical issues but also to get free consulting to a certain degree.
I don’t want to go into the discussion of the pros and cons of ES – to me, it’s a fact that I accept.
So do many of SAPs customers.
In fact, many of them are e.g. big IT outsourcing companies that require having the level of support offered by ES.
The idea here is, of course, to provide customers with top IT-know-how and top operation procedures a support that fits this.
The reality (at least at our end of the support chain) is somewhat less “top”.
In the last months, I’ve seen more and more customer messages that had not been opened because the software did not work as it should.
Instead, these messages were opened to clarify questions like:
- “How should I setup my standby server?”
- “How often do I need to take backups?”
- “I’m going to install a new system, Should I use Oracle 9 or 10 for that?”
- “Our storage system is full – what should I do?”
Obviously, these questions are a bit awkward when found in support messages of high-level IT-companies.
More frightening then the questions itself is the timing with which these are sent to SAP support:
All of them needed to be clarified as soon as possible because the decision/information was on the critical path of a super important and already late implementation project or GoLive due data.
Let put this a bit clearer:
These customers began to worry about the “WHAT” and “HOW” of their database backup strategy two days before they wanted to start the productive use of their system.
The best thing to do here is usually to postpone the GoLive and go back into the planning phase.
But what other options are there for the system integrator to get the answers to their questions?
Answering “Read the f***g documentation!” to this request would be just cynical.
Instead, SAP offers a much better alternative: “Run SAP Best Practices” (available in the SAP service marketplace at this link http://service.sap.com/alm-methodologies )
There you’ll find lots of documents that tell you what to do and how to do it.
And even better: what NOT to do.
One of my favourites of this collection is document “012 – Backup and Restore for SAP System Landscapes“.
In its current revised version, a complete overview of the Do’s and Dont’s of system landscape backup and restore is given.
A big part of the guide is dedicated to highlighting the critical dependencies that come with point-in-time recoveries.
This is one of the documents that everyone involved in technical operations of SAP landscapes should now rather well!
Ok – that’s it for today.
Now, go and get your copy of this Run SAP Best Practice!