Back from SAP TechEd: Back on the dark side?!

After enjoying SAP TechEd in Barcelona last week, I’m back in reality now. I really enjoyed TechEd. I would call myself some kind of a geek and I really like to get insides on new stuff which appears on the horizon even if it might be years ahead of my daily business or if it might never become my daily business. I have to emphasize that I really like to see that SAP continues to go the way they started to go with HANA years ago. Since I’m working in the SAP Eco System (that’s almost 15 years by now) that’s the first time that they follow the same strategy for such a long time. The technologies and products seem to become more mature and stable. Of course, there is often place for improvement but in general I like what I see. Especially the fact that SAP gets more and more open as you can see in several areas: openSAP, contribution in standardization (e.g. OData) and contribution to open source software … That’s definitely a big move and I really like that!

But now I’m coming to the point why I’m writing this blog post. I’m back at work, back in my daily business and somehow I want to call it back on the dark side. The story is about the experience I made with a specific BAPI and the SAP support.

Before I start to tell my story, some general remarks on the BAPI concept:

I regard the concept of having BAPIs very good. At the time when it was introduced it was a really innovative idea to have encapsulated business logic which you can call from another system. But one issue I have with many of the existing BAPIs is the way they are designed. In many cases there is only one BAPI which is supposed to do all the changes on a business object. This “one fits all approach” makes it almost impossible to define all the test cases you should have in place to test the whole functionality, which leads to an open door for side effects. Furthermore, the signatures of some BAPIs consist of more than 20 tables and structures. There are fields in this signatures which should never be filled, but you can fill them. As BAPIs are also an interface to the non-SAP world, the way they are designed led to the reputation of SAP being complicated and not easy to understand among .net , Java developers and any others who had to use them. In my opinion, the fact that they are that complex is also the reason SAP does not dare to re-write them (they got wrapped within the SOAP services and now they are often wrapped as an OData service, I’m wondering what will happen with S4HANA). But still, I’m very happy that they exist and as I said, at the time when they got introduced they were state of the art.

Now I want to tell a true story about the last almost 18 months and the “fun” I had with SAP support. To make it clear: I don’t want to blame anybody personally. I assume all the people involved do their job in the way they are told to do it.

The story is about a BAPI which exists since 2005. It’s in the area of material master data. A quick search on Service Marketplace reveals that SAP released more than 50 SAP Notes within those 18 months. I’m not that proud about the fact, the at least five got created after one of our tickets which already sum up to nine by now. Already this facts shows that this BAPI kept me quite busy. We are using this BAPI for a master data interface which is quite critical to our application. So all this issues got even management attention. Each developer knows that it doesn’t make problem solving easier when management guys attempt to solve your software issues 🙂

Ok, one could say, if SAP released more than 50 SAP Notes, they realized the quality issues and installed some quality management processes. I don’t know if they did, but at least I don’t think so.  After the first tickets we created and after having endless discussions with SAP Support about declaring it as a bug or not, we ended up in debugging the SAP code and pointing them to the place where we identified the bug. Even in that cases it took weeks to get a fix. Now, we do a deep dive into the SAP coding before we open a ticket. This is a painful work but not as painful as those discussions. But even if we tell them, “look here, this must be a bug” they sometimes just ignored our hints for weeks. Finally, in the SAP Note they ship, they changed surprisingly the mentioned part of code.

One of my colleagues already suggested we should just go and re-implement that BAPI on our own. I’m still convinced that this would be the completely wrong solution (always use SAP function modules to change data in SAP tables, there are very good reasons for doing so!). But looking to the effort we invested, it would have been possible to develop a BAPI for our needs.

SAP gets good money for the support from their customers. Their customers need a good support because they run very often mission critical systems for their business. But as a customer you should really worry if the support teams of your software supplier acts as we experienced it:

• All our tickets which made it to the development support were processed by the same person. I don’t know exact numbers of SAP customers which use SAP MM but it must be thousands for sure. It’s clear that this person must be more than busy!
• You as a customer need skilled ABAP developers even if you are only using SAP with the code SAP shipped (I would be surprised if there is any customer without any custom code on a SAP system) because otherwise you will end up spending years in convincing SAP Support that you found a bug
• After agreeing on having a bug it takes up to ten weeks to get a fix even if you tell them that you will have a go-live in between
• SAP Support is asking you providing simple test cases on your system to test the fix because they are not able to produce a similar test case on their system
• Not to mention the annoying game “I just ask another stupid question to the customer. I already know it makes no sense at all. But it will improve my KPIs when I change the status as fast as possible.”
• SAP Support doesn’t answer question why they do not respect their own architecture and coding guidelines
• Even if you got a ticket with priority “very high” you do not get 24/7 support because there is only one development team taking care for your issue

For me it looks like, that the existing ERP Suite, which is running at the vast majority of the customer’s systems became just legacy. There are support teams responsible for coding which is almost not commented and if commented, in a language they do not speak. I can only guess about the documentation they have.

All this experience really worries me!

Are all my experiences just an individual case or did you make similar experience?