What if someone like me — an independent consultant — came along and said “SAP, I’ve got some really great ideas on how you can dramatically change the application for far greater success in the marketplace”?
What if this change make the application more useful, and would not cost that much in developer time or resources?
What if this change could be done almost completely with pre-existing functions, functionality, and code that SAP already has but has not done a good job themselves of integrating?
These ERP application changes would be low cost, high benefit, and completing game changing. Game changing because the changes below and many more I know of cover the vaunted three areas of value proposition all at once: product innovation, operational excellence, and customer experience.
What if these changes demonstrated enough benefit to create a compelling case for version upgrades without expiring support as the reason?
What if these changes allowed SAP to more easily sell in the Small and Midsized Business (SMB) space?
Would SAP take up the cause?
My proposition would completely change the ERP competitive landscape and move the application to the next level without much cost, complexity, or difficulty involved.
Remember when you paid millions upon millions of dollars to do the “EnjoySAP” design work, employ the consultants (internal and external), develop coding, and build user experience? I’m giving you the next generation application process free, which will make a huge difference in the application experience.
What if this solution delivers the same results without the significant costs?
EnjoySAP
Years ago I remember when SAP embarked on a transformation project called “EnjoySAP,” which was initiated to make the application more user friendly. The project created a new GUI interface and lots of “N” transactions for the new interaction paradigm.
Today, SAP has the ability to add tremendous value to its transaction processing through a few relatively minor changes. These would appear to be dramatic changes on the surface, but in reality, they are relatively simple and low cost. Best of all, they can all be completely backward compatible, mostly without having to use a switched framework.
This update would require few or no core application code changes to existing transactions, and even those few changes could be done fairly easily. Even when those changes are necessary, SAP can simply incorporate its switched framework for coding enhancements and add the switches to the IMG to give customers the option of using the existing ways, or the new significantly enhanced methods.
Here We Go…
For many years I have done full-cycle, full-module, functional configuration in SD, MM, and PP. Along the way, I have encountered some issues that have made me wonder why SAP hasn’t focused more on the end user experience. End user or customer experience is one of the vaunted three value proposition pillars in SAP.
DIMP Solution Add-On Transaction, ADSUBCON
The SAP subcontracting functionality has always caused problems. Separate t-codes for nearly every process, separate inventory management processes, separate stock report t-codes (forget about MMBE here), you name it. Overall, it is a disjointed and painful process. However, one day on a DIMP project at an automotive company, I came upon this incredible subcontracting processing cockpit transaction called ADSUBCON. It is probably one of the most useful, well-thought-out, and well-designed transaction options in the system.
Why isn’t this included in the core application for every customer, whether they use DIMP or not?
SAP should extend this cockpit paradigm to other process areas of all of the modules. Simply create the transaction code process flows, with all of the options, and enable configuration to include or exclude certain transaction “buttons” or “options” in the cockpit.
Here are the advantages of the cockpit paradigm:
1) Users are exposed automatically to the full breadth of the process, so they gain a more holistic business process perspective (even if they can’t execute certain transactions). 2) The common look and feel of the cockpit facilitates knowledge transfer and usability.
ME21N – Do We Need a VA01N?
In ME21N, the document overview and ability to drag requisitions to the shopping cart to create new POs are useful. Why doesn’t this exist for Sales Orders?
SAP could easily incorporate the VA05 transaction processing behind the scenes to make this feature more usable. The VA05 could be the document overview like what is used in ME21N. SAP could easily use the copy control to copy document to document, or item to item. On top of that, depending on how the transaction is structured, it could also include a list of the last X orders / deliveries / invoices (based on configuration settings) for that Ship-To party as soon as that customer number is entered and you press ENTER.
On top of that, several function modules for the R3 Internet Sales application already have this development. This change would dramatically change usability for a key transaction string. Along with that, it would not require a huge amount of development work.
Overall, these changes would provide substantial benefits to the end customer.
Document Flow in MM and PP
The PO History was a good start in the ME”xx”N transactions, but SAP should extend this feature to material documents, accounting invoice displays, etc. This was done in SD and has been a tremendous asset and help for troubleshooting, understanding document history, etc. Why hasn’t this same paradigm been applied to MM and PP yet?
Pricing and SD-MM Coordination
This idea would require some redesign, but in the end it would be worth the pain.
The differentiation between SD “Pricing Procedure” maintenance and MM “Schema” maintenance has always baffled me. A significant amount of the backend plumbing, tables, etc. are the same between the two modules. Even a lot of the programs are the same, and only application area settings separate them. Why again are they named differently?
In reality, lots of these things should be made exactly the same, but in reverse. Many of the clients I have worked with wanted to do similar types of posting functionality that are available on the SD side but currently on the MM side. Instead of revenue accounts, maybe expense and liability account determination.
Consistency in naming conventions in the IMG for SD and MM pricing would be helpful. The similarity in functionality would open doors to more consistent thought and condition setup, leading to better business benefit. The ability to drive more granular General Ledger level spend tracking on PO’s by having similar functionality to SD’s Revenue Account Determination functionality would allow businesses to track discrete components of the competitive pressures that vendor power creates.
Designing similar and equally robust pricing processes on both the SD and MM side, along with the expanded FI integration, opens a whole world of possibilities for business.
Output Processing WMTA-Style
On nearly every project I’m on, someone will request to automate a transaction. The process chain automation seems to be a consistent and routine theme, no matter what module it is.
Over the years, I have used Lean WM and the Auto TO creation through the standard WMTA condition.
This paradigm is a great solution for automation at any point in the system. Because of the number of BAPIs and Function Modules that are already produced for most of the document creating (or changing) transactions, this would be relatively easy to do. Simply include a BAPI or function module in a condition to create the follow-on document, and pass the data to the function module or BAPI through the print program.
This solution is tremendously flexible because the business can control the individual behavior of each output through the use of the condition technique and access sequences.
On top of that, you could develop a standard print program with all of the standard supported output options, and a configuration-switched framework that uses the application area and standard or custom condition type to be processed. Then, only a single print program would need to be maintained, and the output condition could have its own separate BAPI or function module assigned.
This method can easily enable business process flows with standard functionality and standard programs for processing or re-processing outputs. This is the type of innovation that small and midsized businesses badly need.
Conclusion
The concepts I described are only a few of my ideas. I have many more areas where SAP can substantially improve the ERP application, without significant expense, time, or resources. These and many other improvements begin to provide a compelling case for upgrades, even without support ending.
Some of these enhancements would improve use, business process focus, and innate knowledge transfer so strongly that even small and midsized businesses would become interested in SAP.
If SAP is listening and interested, I am happy to speak with one of your key developers from Palo Alto or Waldorf. After over twenty implementation projects, I have a good idea what customers are looking for and what is meaningful to the small and midsized business space. Let’s work together to “supercharge” the ERP application, and in the process, shoot for 90% of the entire ERP application space! It’s time for order of magnitude changes on the customer experience and business process side of the house.
