Skip to Content

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.
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.  SAP 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.  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.

So, let’s dive right in to a few examples…

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.  Admittedly this would create some development challenges around AP invoicing to be able to handle the account posting like on the SD Invoice side, but that shouldn’t be too difficult to resolve.  And certainly this is one of the areas where the switched framework would be needed.  Either do it the old way and for upgrades keep all of the old, existing methods, codes, and transactions; or do it the new way.
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! 


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Bill, this is a real hectic week for me leading up to SAP TechEd so I have to make this quick, but I like what you’re doing with these blog posts so far and just Tweeted the link to your pieces out on my @jonerp Twitter feed.

    As far as SAP listening goes, what I can tell you is that if you keep blogging and keep interacting with other bloggers on SCN and other places, you will develop connections inside and outside of SAP even beyond what you have already gained through your years in the field, and yes, SAP will listen. Whether things change substantially based on your input, well, that’s a whole ‘nuther discussion.

    Keep it up!

    – Jon

    1. Bill Wood
      Why thank you sir, I’ve followed your work for many years.  From back in the “bad old days” leading up to the Y2K crunch to today.  Great work as well.

      Thanks again for the kudos.  I’ve been doing Business focused implementations for so long that it now comes natural and I have a passion to see SAP “done right!”  From what I can see this is one of those separation criteria that will help companies implementing SAP, separate and segregate the real consultants from the technicians, and in the final analysis help SAP as well.

      Thanks again,

  2. Gregory Misiorek
    this topic/discussion reminds me of this crazy idea that i have. why not allow the drill down from an xbrl-reported financial statement item, through general ledger (document browser, included) down to billing document (payment for the A/P side), sales order, master data and back flowing up the chain. i have skipped several steps, but you get the idea, if you have read so far. and all this drilling (flowing) via URLs. I’m sure someone has already designed it, but when would we see it implemented? reminds me of good old audit trail and trace and it better tie or else?
    1. Bill Wood
      Great idea.  The document browser is similar to what I was referring to for the MM and PP side.  Sure, it would be great on the FI side as well.
    2. Bill Wood
      Almost forgot to mention that if SAP did a doc flow type table, like they do with SD, then reports could easily be developed from this that would tie-in all of the integrated module data from other areas.  The reporting and analysis requirements would be easier and more meaningful.
  3. Former Member

    I bumped into this article today. Apparently an old article (posted in 2009 Oct), but still relevant. Some features which is mentioned – document browser is possibly available from Ehp5 as per SAP documentation. I have to see it, to really believe it

    But I think SAP is more interested in investing into new product areas than investing in the core ECC now. From revenue strategy for SAP this may be right. New functionalities which are now delivered through Enhancement Package seems to be getting launched with very limited testing internally. I shiver to offer any new functionalities to customer unless I personally make sure it is any where close to what it is stated in documentation. May be I am from the old era where a promise is a promise once given to a customer!

    1. Gregory Misiorek

      i’m curious, when was the last time you had documentation that didn’t match the functionality? my experience has been documentation that was difficult to follow, but not really promising something that the properly configured install couldn’t deliver. you can also have corrections after the release but they become part of the documentation in my books. is it different for you? also, i don’t see ECC going away any time soon, despite all the innovation happening ‘around’ it.

      1. Former Member

        Hi Gregory,

          Have seen this with recently with one Ehp5 function related to procurement which I was checking out for a customer.

        Apparently the entire functionality has again gone to development team after I found that it was not even having anything close to what was mentioned in document. The project is still going on, I hope the promised function shall be available close to the project go-live. Keeping my fingers crosssed

          I did not mean to say ECC is going away. What I meant was focus is more towards other products in terms of support or new features. Quality of people (not just in a company like SAP support) is generally on decline compared to what we could see say 10 years ago. Reasons are debatable and may be better discussed in discussions like this

        1. Gregory Misiorek


          sorry to hear about your experience, but i think putting it out there (through forums, discussions, etc) should help. maybe, not immediately, but if you find more people seeking similar functionality you can create some leverage with SAP. i didn’t get the impression that support has declined, but it depends on who is handling your message. being as specific as possible usually also helps. did your messages result in any corrections? i wouldn’t expect SAP to custom code too much in ECC as it has been stable and has grown over the years. i’m aware of at least two products offered in procurement: traditional ECC and SRM. do you have any flexibility between the two? SRM, being ‘newer’, may have more development focus. feel free to point out what’s missing in Eh5 as my client is also considering an upgrade and i would like to know what’s not working as much as what is.

          good luck with your feature!

          1. Former Member


              Nothing to feel sorry about this. I think this is the way SAP (any software product company for that matter) can grow, by introducing new functionalities and improving on that functionality

            With more than one product now, the cases may be more. Integration issues becomes a pain. Take the case of a client (X) who acquires three companies – A, B & C

            For procurement function:

            A has been using e-sourcing (erstwhile frictionless) from SAP
            B has been using SRM

            C has been on ECC say version 6
            X itself is on ECC say version 5

            How do I have manage vendors (masters, evaluation, quality blocking, etc) for all the companies (A, B, C & X1)? MDM is the answer for some one who is on SAP sales team.

            How shall a strategic/operational (whatever you call) purchaser be facilitated to see all requirements from different systems at one common screen (cockpit, area any name you choose) so that she can make alerted/updated/informed to make decisions to reject, collate, order, bid for these requirements?

            How do I all this by providing access to her from an i-pad, blackberry, android, mac, windows devices? SAP Mobile is a sales answer

            Lot of work to be done..let me run.. 🙂


Leave a Reply