Skip to Content
Author's profile photo Ann Hustis

Customers wouldn’t dare use a non Audi engine in their new Audi S4…

…so why do they use Z functionality in SAP?

Life’s good and you’re going to treat yourself to the car of a lifetime – a brand new 2014 Audi S4!

So you go onto Audi’s website to configure your car.  (Side note:  is Audi’s car configurator powered by SAP’s PLM module?  But I digress.)

Choose Engine – you choose the S4 3.0 TFSI quattro Technik Manual cause you just love the manual shift.

Choose Suspension – you go with the Audi Quattro with sport differential and dampening suspension cause you know you’re going to eat up the Autobahn and venture into the country too.

Choose upgraded Inlay – money’s no object; you get the Beaufort oak aluminum inlay available exclusively on the S model (sorry A3 drivers)

Choose Optional Parking System – you add on the Audi parking system with rearview camera cause you know hubby will be driving it too (had you fooled, you thought with all that preceding tech talk this is written by a man; nope!)

Choose Wheelchair assist entry system – Mom is a frequent passenger and sadly she’s in a wheelchair but you love her so you’re going to get the hardware to make her life easier getting in and out of your Whip (don’t get weird ideas; look up that word; it’s slang for ‘expensive car’)  But wait, Audi doesn’t offer a Wheelchair Assist Entry System!  You ask Audi for their help and they direct you to Acme Wheelchair systems, a company who has been adding these things to Audis since the days when Pluto was a planet.  Acme and Audi have worked together for years to get the design just right so performance is not impacted and the assist folds up out of sight.

Finally you’re done.  Your dream car has been built!

At any moment did you consider going to Joe’s garage and getting a different 3 litre engine? 

What about the Inlay; surely your carpenter friend could build the inlay out of a wood even more beautiful than Beaufort oak. Did you consider that?

No you didn’t!

You didn’t consider doing any of these things because Audi has been building superbly engineered cars since, well, since Pluto was a planet. You bought the S4 because Audi has a fantastic reputation in making well crafted, superbly engineered cars.  But you added on one non Audi component – the Wheelchair assist entry system.  You did so because Audi didn’t offer one and it came well recommended by Audi.

Now relate this to your SAP system:

The Engine is the MRP program.

The Suspension is the Available to Promise check in Sales Order Processing

The Upgraded Inlay is the Capacity Requirements Planning tool

The Parking System is the Order confirmation transaction 

and the wheelchair assist is a Z report that is required for manufacturers in your province; it is not offered in Standard SAP. 

Think about this.  Let’s all get back to using Standard SAP!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Arturo Senosain
      Arturo Senosain

      Hi Ann.

      I'm afraid but I'm not Agree. SAP don't cover lots of functionality, lots of reports, lots of KPIs, and lots of process that company want and need, so why don't write ABAP code if you can fullfill a customer requirement and make their live easier ?

      Why functional consultants fear about create Z tcodes ? Because it spend lot of time? Because you need to test a lot? Because functional consultants don't know how to make a development specification ?

      I don't know, but non of this reasons justify. I always try to make customer live easier.

      This is just a point of view.


      Author's profile photo Former Member
      Former Member


      There's a difference between giving customers what they want and making their lives easier.  Most customers are not SAP experts and 95% of what they ask will not help them or the company in the long run.  When you develop something custom, they no longer rely on SAP to maintain the functionality - they now rely on you.  Your (and your team's) time is valuable and limited, so it's best to spend your time researching a standard solution instead of developing something inside your comfort zone.  It will save the most time (and money) in the long run.

      As for your claim that SAP doesn't cover lots of functionality or reports, that just sounds like FUD.

      By the way, Ann, I loved this post.  Great analogy.

      Author's profile photo Arturo Senosain
      Arturo Senosain

      Hi Erick. Thanks for share.

      As I told you, this is just my point of view and the way i work.

      and Yes!.. I always look for the standard solution and also I don't create  Ztcodes for whatever... this is nonsense.  The question is what happen when the standard  SAP solution not cover the required functionality (best practice in a specific process) or the legacy system functionality actually work in a better way than SAP?

      Say "this is not SAP standard" sound as a cliche in this cases and i feel embarrassed if I say an statement like that.

      Have Fun!


      Author's profile photo Former Member
      Former Member

      Good points, Arturo.  I can only speak for my organization, and I know we have written a few reports that could have been accomplished by a variant of a standard report.  We also have unnecessary custom workflows, and a ZMRP with a painful number of MRP exceptions.

      Thanks for the insight!

      Author's profile photo Caetano Almeida
      Caetano Almeida

      Hi Ann

      Very nice topic. I see many companies trying to reinvent the wheel with Z programs, or buying external planning systems because they simply "don't like" the standard functionality. In many cases they don't even try to learn or research about the standard functionalities before starting their own development.

      One classic example is transaction COOIs. I have seen many custom reports for production orders with information that can easily be found on COOIS.



      Author's profile photo Former Member
      Former Member

      Dear Ann,

                       A nice illustration. But I strongly Disagree. The wheel making differs from the skill level nit by the company brand. It is an assumption that Great companies have Great Workforce. It is not . The reality is in reverse. Due to Great Workforce, organizations become Great Companies. So,What  If the Non-Audi manufactures/fits the wheel in a very passionate/beauty than Audi ?? 

                    I have seen some experts, where SAP was not able to address the business processes addressed with Z functionality. Now, after few years, SAP brought them in to small modules and even as RDS products !! The best example for this is Create-TO-Order.

                   We can not run/change the business as per SAP. Best example is Material staging in Production. If my store and Production-line are juxtaposed, I need not to go by the Production Line-Process ,where Material Staging is not Required.

      @Arturo: It is not that consultants are enough competent in testing or do not want to take extra burden thru development. It is adhere to the Product specifications and features and for EFFECTIVE usage. Z-development is not a passion, It is/should be an ALTERNATIVE only.



      Subrahmanyam B

      Author's profile photo Ann Hustis
      Ann Hustis
      Blog Post Author

      Subrahmanyam, I agree with you that sometimes Z programs are necessary.  I was at CN Rail in the early 2000's when they and SAP co-developed the Mobile Assets solution which is now a standard SAP offering. 

      But for every fifty Z programs I've seen I'd say that only one is actually necessary.  The other 49 require the client to adopt the SAP standard business process.

      Here's a crazy one that I saw a month ago - the customer runs ZMRP instead of standard MRP because they want to separate the planned orders that come from:

      1. Planned Independent Requirements
      2. "Real" Sales Order demand
      3. Safety stock

      They do this so that they can prioritize the planned orders and give first dibs of components and capacity to the "Real" Sales Order demand.

      So now they have planned orders for PIRs and safety stock that they will not action (turn into production orders). Can you imagine trying to make sense of the MRP exception messages in MD07; there will be tons of them!

      This process is now completely broken, all thanks to the ZMRP program!

      Author's profile photo Former Member
      Former Member

      Hi Ann,

                Thanks for let us knowing about the 'ZMRP'. In that case, they have the SAP to gain/boast that they are" technologically advanced by their competitors( but Far Far away by the Process )" 🙁

               I forgot to mention in my previous post,You are inspiration to the most of the PP consultants !


      Subrahmanyam B

      Author's profile photo Former Member
      Former Member

      Good example for Industries and Consultants why we should be using the Standard SAP 😎 instead of going with Z or Custom functionality to make our life more easier and lot more messy 🙁


      Amarnath G.

      Author's profile photo Jeevan Sagar
      Jeevan Sagar

      I didn't imagine that someone can pull up an Audi S4 analogy and compare it with a huge ERP system like the one made by SAP. Anyway, your entire analogy was based on the assumption that whatever Audi offers is the latest and greatest in the world and a car customer like average Joe is same as the customer of SAP ERP which normally is a big company with totally different needs from one another.

      What if the customer wants a vehicle to go to work and wants to haul his four wheeler or rock crawler? In that case he would need some three-quarter tonner or half tonner like Ford F-150 or Toyota Tundra, what if the customer wants some thing which is good on gas like a Prius or IS250H what if the customer wants an EV with great range and high HP motor, he would have go for a Tesla. How would you compare these kind of needs with ERP customers because this how diverse the requirements and needs of companies running ERPs?

      Author's profile photo Former Member
      Former Member

      The analogy is not based on the assumption that Audi is the best.  It's about stock cars being more reliable and economical than custom jobs.  Unless you're sure a business case is impossible via standard config, don't use custom objects/development.

      For complex tasks, it's best to leave the complex coding to SAP whenever possible.  The service marketplace has never released a note or enhancement to fix a bug in one of my Z-programs.

      Author's profile photo Jeevan Sagar
      Jeevan Sagar

      I never said the assumption is based on the Audi being the best. I said the assumption is based on what Audi offers is what the customer needs and in some cases what they want. I don't even know what S4 3.0 TFSI quattro Technik Manual engine is and I don't think I'm the one who falls for the fancy marketing jargon, and if that engine can do everything in world then every car in the world even a dump truck would be equipped with that engine, unfortunately that's not the case. But you know, if that itty bitty 3 liter engine of the Audi can haul a trailer then it's good for you.

      I do agree SAP covers 90% of all possible combinations of every business scenarios and I do agree a ZMRP is pretty idiotic, but there are some important things SAP covers or even if it does those business transactions are overwhelming to the user. For example SAP still insists on using SAP script forms for production order printouts and they know that the barcode technology used in SAP Script forms is as old as the universe is. Another example would be there is no way to hide variants from some users, if I want to make the super overwhelming COOIS transaction to hide some of it's billion and half screen fields with a variant for some users I cannot do that.

      Also, I do think service marketplace is for SAP's own code, so why would it support some custom code written by some programmer out there. SAP never discourages customers doing their own custom developments.

      Author's profile photo Former Member
      Former Member

      The analogy is based on the fact that stock cars are more reliable and less expensive than custom cars.

      The example about SAP not supporting my code was the point I was trying to make.  Of course they wouldn't support customers' code.  For this reason it's better to use SAP standard to keep the maintenance costs on SAP's end and not the customers.

      Nobody is saying that custom development should never be attempted, just that it's far less reliable and should be avoided when possible.  A Z-program in your system should be as rare as a dump truck on the highway, yes?

      Author's profile photo Former Member
      Former Member

      Hi Ann,

      Thanks for sharing your thoughts and observations. However, I do not agree with it. I believe SAP should suit customer's requirement and not the other way round.

      A customer who has invested huge amount of money in SAP has all the right to seek what best suits his requirement and this differs from customer to customer.

      Also we should not forget that the customer is using the reports in their own formats for years together and are reluctant to change.

      If customer is in need of Z-reports, then we should first point out the existence (if any) of similar report in SAP standard format and if the customer is still unconvinced then we (as consultants) should develop the same for him as Z-reports (however ridiculous it may seem !). The customer is the one who should decide the requirements.

      Coming back to your analogy: Though Audi is offering the best of its class, it still does not meet your requirement of taking your mom for the ride since she is in wheelchair. If Audi point out all the standard features of the vehicle, would you still leave your mom behind to avoid tampering with Audi's best looks or would you go for installing the wheel chair assist entry system?

      This can only be best answered by you alone based on your discretion and not Audi's.

      This is just my point of view. Thanks.



      Author's profile photo Ritesh Dube
      Ritesh Dube

      Different analogy Ann,

      I do agree we should always go for standard SAP.

      But creating a Z report or a ZMIGO justified when business process not covered by standard SAP.

      For me changing a engine canbe related to creating a new ZPP or ZSD module, i dont think any one do it.

      Creating a ZCOOIS is some what fitting a Music system of my choice then to go for factory fitted one.



      Author's profile photo Romeo Georgievski
      Romeo Georgievski


      just think about ECC upgrades and I do agree with Ann : the more Z you have the more SAP governance you loose.

      Z must come when there is no standard solution.

      Best regards,


      Author's profile photo Former Member
      Former Member

      SAP is very far from people's needs, see QM results reporting( my thread ). It's very obvious, common sense, that data entered by users should be retrievable in standard report format.

      Instead SAP offers complex, non-list reporting of QM results that even consultants cnanot retrieve without Z reports. Z reports make it very easy, otherwise it is utterly impossible to retrieve this data (not cleverly hidden in some best-practice as you suggest)

      Thi sis only one example but it is very clear that SAP is not built for general use cases, even obvious use cases like this, they simply never observed how people use hte software. Anyone who entered QM data does so with the intention of retrieving it someday-- isn't it obvious? Completely obvious? Completely forgotten by SAP programmers.

      Author's profile photo Former Member
      Former Member


      Since the SAP itself provides Z programs to update the requirement, it sure that The team who created SAP System,certainly sure about the customer requirement and hence they allowed the program to do so,

      SAP LOGO Comment Best business runs sap ,which means to run the businessn succefully ,it requires different reports which may contain customized,