SAP Analysis 1 – Core SAP Weaknesses

A Series of articles based on my experiences with SAP

Core SAP Weaknesses

SAP is a great piece of software; however, every piece of software has weaknesses.  There are three major weaknesses with SAP software.

  1. Architecture of the core software is ancient, in addition, early SAP developers were not database-oriented and were making a database agnostic piece of software.
  2. Non-uniform posting to core transactions.
  3. Expensive consultant and developer expertise required to configure and customize the SAP core software.


There are a few major weaknesses with the Core SAP product (SD/IM/MM/WM/FI/CO/etc…) that may end result in major problems for the future of SAP.

Database Weaknesses

There is no question that database technology was different when the R/3 ERP product was created.  In fact, one of my problems with SAP ERP is caused by the database technology at the time of SAP ERP creation and the good idea of a database agnostic product.

Database Agnosticism

In case some less technical people are on board with this article – a database agnostic software is a software that can run on any database such as IBM DB2, Microsoft SQL Server, and Oracle among others.  Today, most programs are easily made to be portable or database agnostic.  It could have an impact on the objects used to interact with the database or if ODBC is used it is possible that the only difference need be the connection string identifying the database.

Proprietary SQL

Compounding the problem with the older database technology when SAP R/3 ERP was created is that often performance enhancing capabilities are associated with proprietary SQL Statements.  SQL (Structured Query Language) is an ANSI standard language used for interacting with data in the vast majority of databases.  Except that each database vendor then extends SQL calling it T-SQL (in the case of Microsoft) with commands that do not exist in the core SQL.  In many cases these extended command either provide functionality not in the core SQL specification or provide higher performing SQL statements than the standard ANSI SQL statements.  These performance enhancing SQL statements are exactly what is required in many cases when running SAP (especially without archiving) in a productive environment.

Real World Problems Caused By Different Databases

These enhancements over the standard SQL cause problems particularly when upgrading SAP – even Core SAP upgrades with regards to EHP (SAP Enhancement Packs).  In a practical experience I ran a project upgrading SAP ECC 6.0 EHP 0 to EHP5.  The upgrade was performed with very few problems.  One of those problems was that a specific set of Purchasing functionality with regard to Purchase Requisitions was performing very slow.  Lots of investigation later it was found that there was a special service pack with regards to IBM DB2 that was required.  Also, the fact that we never archived data in over 15 years might have been contributory to the performance problem.

Database Standards of a By-gone Era

To avoid problems as illustrated above you can do what I would call the lowest common denominator development.  In this case database agnosticism works because you are only going to execute ANSI standard SQL.  In this case you ignore any performance enhancing non-standard SQL that may be available.

SQL isn’t the only problem faced by a database agnostic system.  In the By-gone era of when SAP was developed – there were strong limitations in some major databases for the number of characters in a table name and the number of characters in a field name.  These object names persist in to the present.  Below is an example – of an up-to-date SAP server and current SAP database tables.

After logging in to SAP (assuming you have the appropriate permissions) go to transaction SE11.  This is the ABAP dictionary.  In other words, this is the place in SAP where you create and maintain tables (among other objects) – and if you make a custom table this represents DDL (Data Definition Language) in SQL Server terms.

SAP_Main_Menu_Transaction_Entered[Above] – transaction SE11 entered in SAP main landing or main menu screen.


[Above] In the blue box I entered a common table name from SAP Warehouse Management (WM) – the transfer order header table which is called LTAK and then in the red box I clicked on the “Display” button.  Instantly anyone familiar with current databases will notice something odd.  The original core SAP database tables all conform to a 4 character naming convention.  This is extremely limiting in a system that now has tens of thousands of tables (granted, not all of the tables conform to this standard as some are much newer than the original requirements).


This is the main screen for LT11.  It shows on the top, the table name, the table description in your user’s language (in this case E, or EN for English) and several tabs with detail information.  The primary tab is the “Fields” tab which displays by default.  You see here the field names, the data element they are based on, the base type and base length of each data type, and finally the short description in user’s language for each field.

The field names conform to a five character limit just as the table names conform to a 4 character limit.  Fields have been added to these tables over time, but the core field names, field contents (frequently) and data types have remained the same for decades.

This causes problems with all users in learning SAP.  Not only is there a character limitation for the table names and field names, but the source country for SAP is Germany.  These field names and table names are abbreviations of German names of objects.  This is good for Germans and German speakers (to some extent) and bad for everyone else.  I say to some extent because these are abbreviations and even for a native German speaker it may not be easy to understand why LGNUM means warehouse, LGORT means storage location, BWART means movement type, WERKS means plant.  It is because Warehouse in German is Lager (which being German I might have confused with beer), storage location is Lagerort, plant is a couple of things in German including werk, and movement type is Bewegungsart (according to web translation).

The core of SAP cannot be changed (at least from SAP cost point of view) as there would be thousands upon thousands of objects that would be impacted – and code that might break.  I think it could be done, easily in this day and age, however, it is a high risk proposition with SAP’s installed customer base.  My understanding in speaking with SAP representatives is that the core of SAP will not change until 2020.

In the end people spend (waste?) a lot of time that could be productive in learning obscure table names, field names, function module names, and other objects that could all be done much more quickly (and cheaply) than customizing SAP.

Non-Uniform Core Transactions

Learning how to deal with SAP presents many hurdles to the average SAP user.  The end-user experience leaves something to be desired in most SAP transactions.  There is a reason for this, of course, and it is a good reason.

Transaction Ease of Use

SAP transactions are made to be everything to everyone using the transaction.  The upside is that the transactions are versatile and capable of doing a great many things for many different end-users.  The downside is that the transactions are typically burdensome to run for the end user.  Burdensome to learn to do with a variety of inputs that have nothing to do with the end-users primary goal (or are required by the transaction, but the end-user doesn’t need to know).  Then the transactions are burdensome to run on a constant basis, requiring inputs to be constantly entered (inefficiently) that contribute little to the current transaction.

Example of Inefficient Transaction Design

In IM(Inventory Management) end users are constantly moving stocks, goods issuing stocks, returning stocks, and cycle counting and performing physical inventory.  These transactions should be incredibly easy to do – with minimal input requirements.  Everything that can be defaulted should be – and made parameters (global user based variables – called PID Parameter IDs in SAP).



[Above] is the first screen of two main screen for transaction MB1A.  This is where you would perform some of the IM transaction mentioned above.  An end user looking at this might think they need to input everything on this screen.  You don’t.  Typically, I would just enter the movement type, plant and storage location and press enter.  Everything else on the screen to perform a standard goods issue to a cost center is not required.

Most SAP transactions are like this – riddled with fields that the typical user doesn’t need.  A shared code base is a nice thing to have; however, in implementation there should be separate transactions for many of these capabilities.  When I’ve written RF (Radio Frequency) or WiFi transactions for warehouse users to perform movements on handheld devices – I almost never asked the end user for the movement type.  Typically, Plant and Storage Location would be PID values or if that wasn’t possible – barcodes would be in the facility with a combined plant and storage location value so there would only one field of entry – and it would be a barcode with a low chance of end user error.

The real required data is the material and quantity to be goods issued and the destination cost center.  Unit of measure should be pulled from the Material Master – most likely using the issue unit of measure.  If the issue unit of measure is blank then using the base unit of measure.

So, why are there all these field on the screen?  Well, to cover for the many different possible ways the transaction could be used.  Some end users may spend the entire career using the transaction on a daily basis and never once Document Header Text.

Some people who have been using SAP for a long time (and I’ve been using SAP for a long time) might say that you just need to learn how to use the system and deal with end user UI problems.  System usability starts with end user acceptance and being able to perform their transactions without assistance.  Having a bunch of fields on the screen that may never be used is not the way to make good transactions for end users.

Different UIs

Over the past few years SAP has been developing many new UI technologies.  The standard (and used in these screen shots) is SAP GUI.  There is SAP Portal which allows the end user to run most SAP GUI transactions through a browser.  Then, some SAP systems like MDM (Master Data Management) use SAP GUI and then push out to a web browser to perform some transaction.  This is a very error prone and not lean way for a UI to behave.  I’ve seen this break a number of times in SAP Tech’Ed sessions.

There is SAP Friori which can be displayed on multiple different devices.  There used to be SAP Console which allowed you to represent small simple SAP GUI transactions on text based devices (one area where I had made many transactions for warehouses).  When one of my most recent clients installed SAP CRM (Customer Relation Management) it required the users to use SAP Netweaver Business Client.  Meanwhile, half of the facility of 20,000 staff were using standard SAP GUI.  End users that had been using SAP GUI for years were now forced to use a new UI.  While members of the technology industry change quickly, members of the end user community don’t react well.

IT headaches – maintaining multiple End User UI technologies

One of the major problems is now that there are so many different ways to access SAP, that the IT group now has to maintain multiple different UIs.  For example, the IT group choose to maintain both SAP GUI and SAP Netweaver Business Client as an early layer for protection against users accessing CRM that didn’t belong in that system.  This was viewed as an easier solution than converting all the existing end users to SAP Netweaver Business Client – which is substantially different than SAP GUI.  There are benefits to using SAP Netweaver Business Client, such as instead of going to an external browser from an SAP GUI session when MDM requires it – it opens a web session inside of SAP Netweaver Business Client.

IT headaches – corporate attitude to IT

Perhaps your companies attitude is that IT is there to just get the job done and by the way we aren’t hiring any more people even though now you are doing twice the amount of work maintaining UIs for SAP than you were previously.  The basic problem with this attitude is that the more IT time spent on mundane tasks the less time they have to do all the innovative, cost-reducing, and business enhancing things you need them to do.  It is a choice, which sadly most companies mistakenly think that they can choose to just make people do what they need them to do, instead of intelligently choosing where their staff spends their time.

IT headaches – Enhancement Packs, Service Packs, and installation

One of the major headaches when I was involved in SAP IT processes was something that should have been really simple:  Upgrading SAP GUI.  Some activities, that seem on the surface to be simple tasks; unfortunately are not that simple.

Even the sequence of events that led to the upgrading of SAP GUI isn’t as straight forward as you would think.  Our IT department over the years and probably been bitten by upgrades that did not go well or did not have full internal customer sponsorship was to not do them.  If your software is working and stable – leave it alone.

Unfortunately, during our upgrade to SAP ECC 6.0 EHP5 from EHP0 was that we had to upgrade the SAP GUI.  Hours or researching later over the course of days resulted in lists of computer IDs that had different versions of SAP GUI installed on them with many different operating systems (and if you would believe it a significant number of Windows 2000 system) and different Microsoft Office versions.

Hours of meetings with different people, hours of analysis and determination (no we weren’t going to SAP Netweaver Business Client because of the retraining requirement), discussions about replacing PCs with Windows 2000 to Windows XP (gulp! only 6 months newer operating system) and who exactly is going to pay for those new computers?  The business’s philosophy like throwing work at IT staff seemed to be that if the PC didn’t fail even though it had lasted twice the depreciation time to keep it in service.  Hence, Windows 2000 PCs still in service in 2013.

Install of the new version of SAP GUI on select test user’s PCs.  Waiting for reports to get back about errors.  Then actively pursuing users for their input about problems with the new version of SAP GUI.  Discoveries that the newest version of Microsoft Office did or did not integrate with the “new” version of SAP GUI we were installing.

Then the killer was when the remote install tool failed that IT would then have to send people to manually install the SAP GUI.  Large swaths of waste inside of this 20,000 person hospital system.

This whole process took over 6 months and delayed the implementation of EHP5.  It took so long that it would have been great to just go the EHP6 which was now in general release – if it didn’t require the SAP Basis group to redo work on the SAP Server side and potentially have some unknowns in regard to testing the service packs installed to support the Enhancement Pack Upgrade.

Citrix is a great (but expensive) solution.  Upgrade your Citrix server and everyone has the new version next time they log in and in the end this might be the way to go.  Even though Citrix and Citrix servers might be expensive, they are probably cheaper than the vast process I outlined above.  Of course, if we could just use portal then SAP GUI would be web based (for the vast majority of people) and that would be the end of it as well.

Recovering from Bad UIs

Bad user interfaces are hard to recover.  Teaching the end users what to do is a difficult task.  There are training documentations, online learning software such as RWD uPerform can help, in person training sessions – all of these things help.  However; at the end of the day, the fewer things your end user needs to remember to perform a specific task, the more likely the end user will complete that task successfully.

Frequently, end users only use transactions once a month or even once a year (like annual inventory processes or accounting annual closing process).  To expect them to know every detail that they need to do in a complex process in a transaction (or multiple transactions) is unreasonable – certainly in view that the end user’s core tasks are most certainly not “run SAP transactions”.  “Run SAP transactions” is always secondary.  A means to getting something done for the typical end user.

GUI XT, Custom Code Modifications (user exits and enhancements), and Custom Transactions

There are many strategies for dealing with Bad UIs.  One is just to absorb the risk and tell your end users to suck it up!  This is the way it is going to be and you better learn and know how to do everything we need to do in SAP after SAP is live and running.  That is, unfortunately a common and unenlightened way of dealing with end users.

The alternatives; however, are not really great either.  At one Tech’Ed I overheard a technical colleague discussing how SAP was so bad for their end users that they were converting all the transactions they used to ASP.NET web pages.  This is surely the extreme reaction.

There is GUI XT – where you can (for the most part) graphically alter and create specific versions of SAP transactions that don’t include entry of information that is not required or will always be the same for a set of end users.  While this is a great tool, I’ve never had to use it in the work place.  I have heard of people who have used it to great success.

One of the tougher (but more polished) ways of dealing with bad UIs is to make changes to the SAP transactions themselves with user exits or enhancements.  There are some big problems with this as well.  There is a potential that with the next service pack, enhancement pack, or SAP upgrade that your enhancements will no longer function and require rework.  There is the possibility that all the wonderful and enlightened things you want the transaction to do are simply not possible given the user exits/enhancements that are available.  Even if you find you can do the changes you want through enhancements – you may find that the amount of work to make the changes would have been less to simply create a completely custom transaction.

Completely custom transactions may seem like a panacea, but they suffer from problems as well.  While initially less problematic than enhancements – there is always the possibility that the function module or BAPI you are using to post will be broken, change signature, or simply perform differently in an SAP Enhancement Pack upgrade or SAP core upgrade.  There are “consulting issues” of discovering the correct function modules or BAPIs to post the same way as the original SAP transaction (more on this later).  In fact, the way ABAP works in dialog transactions is significantly different than most programming environments – and presents problems in terms of live screen updates with changes in underlying data or simply not having the events necessary for the program to operate the way the end users require it.  Often, for making portable programs this is one of the best ways to go – and these programs can look so different and be so easy to use that end users will be surprised that the programs perform the same functionality.

Non-Uniform Internal SAP postings and ACID

Over the years I have written many ABAP programs and custom function modules in SAP to perform many different postings, validations, and gather reporting data.  It is shocking to see how non-uniform the posting methods are in SAP.  The entire WM (Warehouse Management) module you perform postings by calling function modules that start with L_TO .  In IM (Inventory Management) you call a very complex BAPI called BAPI_GOODSMVT_CREATE to accomplish many of the postings.  In some areas like working with Handling Units you have to call one BAPI, and then follow that BAPI call to BAPI_TRANSACTION_COMMIT.  Other function modules you had to use the line Commit Work and Wait.  Even other functions you just called it and it posted.

Sometimes, in the case of WM and IM integration, you had to call two function modules or one function module and a BAPI to ensure the transaction was performed in both IM and WM.

ACID – Atomicity, Consistency, Isolation, and Durability – one of the core principles in programming to ensure that everything goes right.  Guess what, I am pretty sure that SAP has never heard of this, or having heard of it 10, 15 years to late decided that everything was screwed and they wouldn’t be able to fix it or address it so let’s not mention it to the horde of customers out there, ok?

Expensive consultant and developer expertise required to configure and customize the SAP core software

The results of the many SAP hoops and hurdles is that SAP consulting is very expensive.  If you go through SAP you could get charged $400 an hour for consulting in a module like FI.  Problematically, even though you purchase consulting through SAP, it may not be an SAP employee that you are paying top dollar.  It could be a consultant of another organization and it could be sub-contracted out to several levels until you get to the company the SAP consultant is actually employed.  That is my understanding in conversations with some consultants and other SAP customers over time.  I could be wrong, but I would say that if you purchase SAP Consulting services from SAP expecting a Platinum level consultant.  Talk to your SAP sales rep, talk to whoever the consultant is that comes through the door – and find out just who they work for – and direct consult with that company instead of SAP for some savings of money.

Software like SAP should be configurable through a questionnaire.  It might be several dozen questionnaires, with many questions; however, it shouldn’t require vast amounts of consulting.  Feed the answers of the questions (must be yes/no, requesting a value, etc) and potentially 1 consultant to help with the answering of the questions – and the system should configure itself.

At least that is how I would design it – removing the requirement for lots of configuration consultants.  What I have noticed the last time I worked in the industry about a year ago is that third party consulting for core SAP charges good rates, but now a few consultants share the roles of what used to be many consultants.  Running in this manner is guaranteed to cause problems.

SAP is now coming in more pre-configured or partially configured solutions, similar to the solution that I use for generating screen shots on this blog – an IDES ERP cloud system.  This isn’t intended for productive use, but for a few dollars a month you can own access to an SAP system and be able to configure and perform movements on it to teach yourself – this kind of capability would have been invaluable in the 1990’s and 2000’s.

Final Thoughts on SAP

SAP is still riding high at present.  There is the three pronged attack that has been pounded in in the past three SAP Tech’Ed’s

  2. Cloud Solutions
  3. Mobile Platform

Even so, I still think that SAP is past the prime point.  That the core SAP solution is a major weak point as well as one of SAP’s strongest selling points.  This core SAP solution is on an aging platform with a million chips in the armor.  I think it might be a great starting point – for an entirely new base product platform – re-engineered from the ground up – to provide all the same functionality – in many different ways.  In the end SAP and the multitude of products needs something the sales people don’t want – huge investments and simplification and reduction of the products and functionality of the products in the entire platform.

Updating Core SAP (Additional Thought)

Earlier in the article I stated that the core or SAP cannot be changed from SAP’s point of view based on the potential impact to their customers.  Interestingly; however, almost all the objects used in SAP are located in tables in a SQL Server.  Writing code that traces everything through should be simple – including custom code – and even field symbols.

 SAP Complexity Requires Simplification (Last Thought)

If you don’t believe me in regards to the statement that SAP needs to be re-engineered from the ground up and simplified I would like you to pursue what it takes to make a web service in ASP.NET and IIS.  Then see what it takes to create a web service in SAP – in terms of effort, resources and servers required.  Then you won’t need to believe me, you’ll know.



The First Question in Implementing SAP

I have participated in a couple SAP implementations and there is something that strikes at the core of the value proposition of SAP.

Do you use the vanilla SAP business processes with configuration or do you customize  SAP(and how much do you customize SAP), and finally, does implementing SAP simplify your business system architecture?

You might ask why does this question strike at the value proposition of SAP?

SAP to start off is a fairly expensive piece of software.  When all is completed a business will be adding staff (basis, programmers, managers, potentially a DBA).  When all is completed you will have added a lot of fairly expensive hardware that will have a limited lifetime.  There will be a lot of training and at the end a complex architecture will be in place, consisting at a minimum of DEV (development), QAS (Quality Assurance), (sometimes a TST Test system), and PRD (Production) instances of SAP.

SAP consultants for functional configuration, SAP consulting for project management, and SAP consulting developers – if sourced from SAP would be hundreds of dollars per hour per consultant.  Suffice it to say that while you might buy SAP from SAP, you will be using a third party to provide the installation and customization expertise.  Even so, SAP is not a universal skill like programming in Microsoft T-SQL and therefore the restricted supply means that these people will be more expensive than your typical IT consultants.

The original value proposition of SAP is that it would be a one-stop software.  You could install it and expand it with different modules and the integration between the modules would reflect changes in the other modules immediately.

Perform a goods issue in WM and IM and it is reflected in the Cost Center immediately.  Need an estimate of how much all the stock you have on hand is valued – the information is available, either through custom code, SAP transaction or reporting solution.

When SAP first rose to popularity there were lots of home grown systems, large companies with multiple systems that had to be manually integrated and different staff to maintain each system – so SAP represented a value, a savings and even a ROI.

However, in today’s world there are many best of breed applications that are business area centered – for example, in the medical world there is Epic, Carefusion carousel systems, Carefusion packagers, Carefusion Pyxis units, asset management software like Four Rivers, and many more systems seemingly endless in number.

So a large business like a hospital cannot run the entire business on SAP.  Already out of the gate you are obligated to interface many different softwares together in order to perform daily operations such as order supplies, perform fundamental business processes, supply chain for drugs, and etc.

The second nail in to an SAP System is the premium costs often exceed the costs of a best-of-breed application.

At one customer we are faced with a decision – implement asset management in SAP or use a software that had been purchased by an individual department to perform asset tracking.

When all was said and done there were two solutions with two sets of costs.

Option 1: Configure and use Asset Management in SAP – consulting costs over $300K, and would have to be supported by internal personnel that already have a full place.  So, potentially a new FTE.

Option 2: Use existing asset management software which was already purchased for $100K, with support fees of around $10K a year and reasonable hourly rates for customization of software (certainly less than 1/4 SAP direct consulting rate).  Included in this software was also mobile applications that worked with the asset management software.

Anyone picking Option 1 over Option 2 would have to either have an agenda or a dedication to the SAP solution that overrides cost concerns.  You could select Option 2 and spend $100K on integration and Option 2 would still look good.

In addition, there are many dangers in over-customizing SAP.  Periodic upgrades to core functionality (although greatly delayed at present) and the application of service packs and enhancement packs expose over-customized SAP instances to risk any time there are changes.

That being said, there are many good attributes to SAP software, but if you are using it for an all-in-one solution that will show a ROI after installation, you might need to look elsewhere.

SAP BPC 7.5 Lessons Learned

At a previous customer they replaced an end-of-life solution (SRC) with BPC (Business Planning and Consolidation) 7.5 for their budgeting processes.  The SRC solution had been end-of-lifed triggering the need for a new solution.

SAP had purchased BPC from another software provider as they had a best-in-breed budgeting solution in Microsoft Excel.  In BPC 7.5 you experience all the growing pains of a solution in the middle of integration from external functionality to functionality fully incorporated in to SAP.

This meant that we had to purchase Windows servers, there was a general lack of integration, workflows worked outside of SAP workflows, the system architecture (never really lean in SAP) was so far from lean that it introduced many difficulties in determining where performance problems were located.

SAP has really reached a point in the market where just about everybody that wants to use SAP for their core business processes, owns SAP.  Like other large software companies when people make solutions that work better than theirs they tend to buy the competitors out and incorporate their software as an ‘add-on’ to the core SAP.  This is an additional licensing fee for SAP instead of adding an existing core module like WM, IM, or SD.

There are other pain points with BPC 7.5:

  1. There were three interfaces to administer BPC.
    1. A web based interface for primary system control.
    2. SAP GUI to look at the data in BW
    3. A windows executable program

That is for administration and administration can be tough and you might need to do it in multiple places; however, even on the end user area there was more than 1 UI.

  • Excel
  • Web pages (workflow and approvals)

Having more than one interface, plus the added many Excel sheets that the end users needed to be trained was a headache in itself.

At the time my customer installed BPC 7.5 SAP was producing patches seemingly every day in order to make it a stable product.

Patching systems is a problem; however, it is something that is manageable.  There was an additional problem that patching the Windows Client, BPC servers, and SAP BW all seemed to be interrelated.  The net result is that often when an update was required it impacted all end users.

After all of these hurdles you find that we still had to deal with performance issues in BPC largely caused by the clients decisions to have a large number of dimensions.

Unfortunately, it seemed like the BPC 7.5 UI was particularly resistant to being packaged and resulted in many manual installs wasting man hours that would have been better spent managing projects or working on the budget.

One piece of functionality that sticks in my mind is when an end-user is looking at the budget and sees what they consider to be a discrepancy in last years postings, what do they do?  What they need to do?  They need to look at the details to understand what happened.  There is drill down functionality available in BPC.  Unfortunately, this required additional hardware and wasn’t identified early enough in the project to be done.  This left unhappy end-users at the client.

Another major issue was that the different interfaces had different logins.  In addition to that, the login frequently had to be entered several times before letting the end user perform the task they set out to do.

Many of these items are claimed to be addressed with BPC 10 and BPC 7.5 is now deprecated technology.  But as a vendor and a customer these problems will always be recalled to my mind whenever I think of BPC or discussions come up about installing BPC at a client site.