You’ve probably read Axel Angeli’s guest editorial SAP under fire: Axel Angeli on why 2007 will be tough for SAP. Not surprisingly, there was an avalanche of reader responses. Some agreed and applauded the honesty, while some jeered and argued Dynamics was nowhere near ready for prime time. Axel answered two questions in depth yesterday; today he concludes his stint on the soap box by going to the heart of the matter:
What exactly did SAP do to fumble the ERP ball, and what can/should they do about it?
Axel: The SAP ERP is still the flagship of SAP, despite all efforts to gain market shares in areas where competitors seem to be strong. While FI/CO seems to be stable and has set the European way of accounting as IT standard all over the world, the SD/MM and PP areas are still areas where the customers ask for significant enhancements. Let us pick SD for instance… Currently, we still find a hybrid of functionality, powerful but extremely difficult to make any enhancements. And it is the latter that is more and more required by companies, especially if SAP wants to conquer the markets of the SMB. The classical areas of concern are variant donfiguration, pricing, special shipping & handling scenarios, intercompany invoices … all topics the experienced SAP consultant can be caught with a cheshire grimace on her/his face.
Don’t let me be misunderstood: the functionality is powerful and covers many, many areas. But if you need to do something special, the SAP approach with user-exits (aka customer enhancements, BADIs) has its severe limitations.
To cope with the challenges of agility, a more object-oriented approach, one that has been rightly drawn and begun with the BAPI concept, is required. And again, one has to regret that SAP lost the completion of the BAPI concept out of sight. The SD-BAPIs are far from complete: e.g. the “order read” and “order create” modules have different interfaces, isolated pricing modules are still missing, variant configuration is still dug far down in the inside belly of the SD core modules. Modern ERP systems would break down an SD component into small, self-contained objects that inter-operate through message pipes. That would even allow to run a SAP SD fully decentralized, maybe the order creation on one instance, the delivery on a second and invoicing on a third one. Revamping the BAPI concept might already bring a high degree of progress and eventually a convincing argument to upgrade a newer SAP release, one based on ROI instead of simply falling out of maintenance.
SAP did well in the MM sector when succeeding in rewriting procurement in the form of the SRM component. SRM has all that the purchaser needs and it integrates with ease many external offers, like life vendor catalogue access, auctions or goods tracking via slim or sometimes not so slim Web interfaces. Although SRM might well be broken down in smaller atomic units, it is a step into the right direction of an object oriented componentization. However, the drink may be poisoned here as well: while SAP admits the necessity of integration, they are still reluctant in releasing interface specifications to the public and offering demo hubs against which developers can test their development.
The peril is ante portas, not mainly and only in the shape of Microsoft Dynamics, whose principle power lies in the marketing strength or through Oracle where we observe – I admit: to my surprise – an increasing number of new “Peoplesoft” installation, mainly in countries where SAP traditionally had a bad standing, like France for instance. There is also the open source community that seems to increasingly enjoy the ERP worlds after they worked the CMS fields to exhaustion.
Momentarily the importance of open source ERP is low due to the fact that although open source (SAP is also “open source”) they are mostly not “free software” sporting a pretty amusing variety of “licensing models”. I have seen licensing constraints where software is free but consulting must be purchased by the owner of the code and others that keep the software free for developers but require substantial licensing fees for productive use. Both models cannot work, as it is too obvious that the makers want cheap labor from the community but are pretty selfish when it comes to give anything back.
But there are also good examples of open source and free ERP approaches, like Adempiere that – after divorcing from Compiere on arguments about licensing philosophy – became number three in the charts of the most attended projects at SourceForge. Until now the ERP has not yet reached the PHP or Python community that would allow to run distributed ERP on cheap Web hosted platforms, giving the notion of EDI (Electronic Data Exchange) a completely new flavor.
This is the last (?) part of Axel’s take on the “SAP under fire” issue. As always, we’d love to hear your thoughts on the matter. Reply to this post or send your thoughts to firstname.lastname@example.org.