What if some little guy like me–, a lowly contract consultant came along and said “SAP, I’ve got some really, really great ideas on how you can dramatically change the application for far greater success in the marketplace!”
What if it would make a significant change in the usefulness of the application, AND would not cost that much in developer time or resources.
What if it could be done with almost completely pre-existing functions, functionality, and code that SAP already has but has not done a good job themselves of integrating?
Low cost, high benefit, game changing scenarios in the ERP application space. 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 made it an easier sell into the Small and Midsized Business (SMB) space?
Would SAP take up the cause?
I’ve got just such a set of propositions for you. Just the thing to 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), developer coding, and lots of expenses to build that user experience. I’m giving you the next generation application process FREE and it will make a huge difference in the application experience.
SAP, knock, knock, anybody there? You know basic value proposition issues like “customer experience” leading to better user acceptance. These and other solutions also cover the operational excellence value proposition of reducing the post-go-live change management “valley of despair”?
SAP, what if I can deliver without all the bucketloads of cash you paid for “EnjoySAP”? Are you interested?
Years ago I remember when SAP embarked on a transformation project called “EnjoySAP.” The idea was to design the application to be more user friendly, and to be just plain more usable. Along the way we ended up with a new GUI interface and lots of “N” transactions for the new interaction paradigm. That was about 10 years ago. It’s time for a change…
SAP has the ability today to add tremendous value to its transaction processing and to be able to take the application to the next level by doing a few “relatively minor” changes. These would appear to be dramatic changes on the surface, but underneath they are relatively simple and low cost. Best of all, all of them can be made 100% backward compatible, and most of that even without having to use a “switched framework.” How’s that for benefit?
Most can be done with few or no core application code changes to existing transactions, and even when there must be a few changes, they can still be done without tremendous difficulty. 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 old, existing ways, or the new, significantly enhanced methods.
Here we Go…
For many years I’ve done full-cycle, full-module, functional configuration in SD, MM, and PP. Along the way I’ve encountered some interesting things that have made me wonder why in the world SAP hadn’t done more work on application “usefulness” to the end user. We’re talking one of the vaunted three value proposition pillars here SAP –, “customer experience.”
DIMP solution add-on transaction, ADSUBCON
The SAP subcontracting functionality has always been a royal pain in the backside. 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 accidently ran into this absolutely amazing 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, are you listening? This is a BIG win for end customers.
This “cockpit” paradigm should be extended 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 be done to include or exclude certain transaction “buttons” or “options” in the cockpit. Here are the advantages of the cockpit paradigm. 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). Knowledge transfer and usability are facilitated by the common look and feel of the cockpit.
ME21N – Do we need a VA01N?
One of the really useful functions in ME21N is the document overview and the ability to drag requisitions to the shopping cart to create new POs. Why doesn’t this exist for Sales Orders?
Come on SAP, you could easily incorporate the VA05 transaction processing behind the scenes to make this more usable. The VA05 could be the document overview like what is used in ME21N. The copy control could easily be used to copy document to document, or item to item. And 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. Wow, now that would be useful.
On top of that, the development for a lot of this has already been done in several function modules that are used for the R3 Internet Sales application. What are you waiting for? This would create a dramatic change in usability for a key transaction string. Along with that it would not require a huge amount of development work.
SAP, can you see the benefit to the end customer who uses these transactions?
Document Flow in MM and PP
The PO History was a good start in the ME”xx”N transactions, but this should be extended 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? Come on SAP, the info is already there, it’s not that hard to attach the data.
Pricing, Schmicing, SD-MM coordination
This one would require some re-design but in the end it would be worth the pain. I’ve always been baffled by the “differences” between SD “Pricing Procedure” maintenance and MM “Schema” maintenance. 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 but are separated by application area settings. Why again are they named differently?
In reality lots of these things should be made exactly the same, but in reverse. I’ve even been on many clients where they wanted to do similar types of posting functionality that is available on the SD side but on the MM side. Instead of revenue accounts, maybe expense and liability account determination.
The 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 be able to drive more granular General Ledger level spend tracking on PO’s by having similar functionality to SD’s Revenue Account Determination functionality would provide greater ability for business to track discrete components of the competitive pressures that vendor power creates.
Making the pricing processes both similar and just as robust on both the SD and MM side, along with the expanded FI integration opens a whole new world of possibilities for business.
Output Processing WMTA-Style
On nearly every project I’m on there is always some request to automate this transaction into that one, etc. The process chain automation seems to be a consistent and routine theme no matter what module it is.
Over the years I’ve used Lean WM and the Auto TO creation through the standard WMTA condition.
This paradigm is a great solution to performing any kind of auto processing throughout 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 of the ability to control the individual behavior of each output through the use of the condition technique and access sequences. What a great way to get the job done!
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 unnecessary processing would not be required, only a single print program would need to be maintained, and the output condition could have its own separate BAPI or function module assigned.
Do I hear highly flexible workflow without all of the difficulties, pain, and setup work of normal workflow? This is a great way to 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.
SAP, if you’re listening at all, I have many more areas where you 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. Between these and several other ideas I have you could make the case so compelling for an upgrade that it might create a rush to “keep up with the SAP Jones’s” so that their competitors don’t gain too much of an advantage.
With some of these enhancements, the case for ease of use, business process focus, and innate knowledge transfer are so strong that it provides reasons for small and midsized business sales as well.
If you’re listening and interested have one of your key developers from Palo Alto or Waldorf call me. After over 20 implementation projects I have a pretty 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.
Think about it, these changes cover the vaunted three areas of value proposition all at once–, product innovation, operational excellence, and customer experience. How could you possibly go wrong!
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.