Become an SAP Pricing Expert - Matthias Liebich, Author, The Ultimate SAP Pricing Guide
Podcast Transcription: "On Matthias' keys to success an independent SAP Pricing consultant, and how to use The Ultimate SAP Pricing Guide to advance your (or your teams') pricing know-how"
Jon Reed with Matthias Liebich, Author, The Ultimate SAP Pricing Guide
Podcast Interview Date: March 23, 2010

Jon Reed: Hi, this is Jon Reed of JonERP.com, on location in Atlanta, Georgia. I'm in the home office of Matthias Liebich, who is a pricing consultant I've known for many years. We're here on a very fancy occasion commemorating the release of The Ultimate SAP Pricing Guide. Matthias, you should be very proud of this book - it's an excellent read. We're here to give a little context as to why SAP pricing is so important to companies, what some of the issues are, and how your book fits into the picture.

One of the great things about your history is you go back a long way. I was talking with you about maybe going to Waldorf at some point this year, and you're actually intimately familiar with it. You said that back in the R2 days you were on campus there. Can you tell us about that?

Matthias Liebich: I'm actually from Germany. I was born 45 minutes south of Waldorf, so when I started my SAP career I was going up there several times for training.

Reed: You said you actually developed a solution in R2 that's similar to some of the stuff in R3?

Liebich: That's correct. In the early R2 days there were rudimentary pricing capabilities in the system. The client was in Germany; they had the requirement to make it more flexible. So I actually started developing a solution with custom tables that resemble the condition technique in today's system.

Reed: You reminded me of the good old days when we were talking earlier because you mentioned you actually did have R2 experience, which is more than a lot of consultants had. Then you had three days of R3 training and you were out in the field. A a little bit later on you actually became a pricing expert because you were the guy in the right place at the right time. Can you tell our listeners about that?

Liebich: As you mentioned, I had a three-day jumpstart class in R3 and was sent straight to the client as an SAP expert in pricing, so I basically scrambled to read the SAP documentation. That's actually one of the reasons why I wanted to write The Ultimate SAP Pricing Guide: to make it easier for consultants or users who never worked with SAP pricing to understand the functionality better.

I don't think the standard SAP documentation that you can access through the system provides a very detailed explanation of how the individual components work together. The process I went through to understand pricing made me think there should be a better way to actually explain how pricing works in SAP.

Reed: In terms of SAP pricing functionality, how different is it now from the days of, say, R3 3.1? When we talk about the journey from 4.6 to maybe 4.7 to 6.0, is it hard to make the jump between 4.6 pricing to 4.7 to 6.0, or is the functionality pretty solid at this point?

Liebich: Basically after the 4.6 release, there were not many changes, or hardly any changes, in the pricing component. There were some things in rebates, like new rebate procedures, that got introduced; some screens were a little bit different; some fields were renamed. But the big changes in pricing happened between 3.0 and the 4.0 and 4.6 releases. Rebate functionality became much more robust. Master data transactions to maintain multiple condition records for different condition types were introduced in 4.0. So the big changes happened actually before the 4.6 release.

Reed: So for our listeners out there, if they're interviewing for a 6.0 job and the manager asks if they only have 4.6c experience, the listeners should be able to say they can do it because there really aren't that many changes.

Liebich: That is correct.

Reed: Consulting is a funny field because consulting is created by a certain complexity that companies need to grapple with. So companies don't want consultants because they want to do it all themselves, but sometimes they really do have to invest. Pricing seems to be one of those areas. So, why do we need SAP pricing consultants?

Liebich: One of the reasons is that if you don't understand it correctly, the condition technique and pricing basically turn off a lot of consultants and/or users. Also, a pricing consultant brings to the table a thorough understanding of how best to apply the configuration to an individual customer's pricing design. So what you should look for in an SAP pricing consultant is someone who applies the configuration to the customer's pricing design.

Reed: We were just talking earlier about the degree to which SAP consultants are more functional or technical and what is a good mix. For the ideal SAP pricing consultant, does this person know ABAP?

Liebich: This person should know ABAP. Although the standard pricing functionality is pretty flexible in SAP, especially in certain industries like the consumer products industry, the requirements are not necessarily fulfilled with the SAP standard pricing functionality. SAP provides you with several areas where you would need that ABAP knowledge to make modifications to how pricing applies, to make changes in the design, etc. So yes, I think it is a big bonus to have ABAP knowledge.

Reed: When you and I were shooting a video, you were talking about something that resonated with me about how you need ABAP, of course, but also that it's not just about configuring tables, it's about solving business problems. You even mentioned an example. Can you tell us a little about why good pricing consultants do more than just configuring tables?

Liebich: A lot of clients try to replicate what they have in their legacy systems in SAP one-to-one. It could be that in their legacy system they didn't have the capabilities to group information. For example, the most common mistake is to create pricing records by customer and material number, although the prices are the same for a group of customers or a group of materials. There are several fields in SAP where things can be grouped together. Maybe in the legacy environment, they are unable to group it because it doesn't have the fields and technology, but SAP can do that.

You could take it one-to-one and replicate it in SAP, but a good pricing consultant would make suggestions on how to reduce the number of records in the system. That also improves performance and the maintenance effort for a pricing person in the business.

Reed: At a time when budgets are at a premium, if you can position yourself as someone who knows how to save companies money and not just configure tables, I think that really resonates.

Looking at your book from the vantage point of the individual SAP professional, I know that one of the main reasons you wrote the book was to help other people along their journey of skills progression. How do you see your book helping individuals? Is it mostly for advanced pricing folks or is it for novices? How do you see the skill range working?

Liebich: I think the book is suitable for a broad range of users and consultants. It starts pretty basic with the individual components of the pricing configuration: condition tables, access sequences, condition types, and pricing procedures. There are tons of screen prints in there. So you could actually use that book and do a step-by-step design of your pricing system in SAP.

Basically, this is the cornerstone: it's the condition technique in SAP, which not only helps you with pricing but is also the main component for output determination, partner determination, text determination, etc. I think if you understand this technique, you're able to apply it to several different areas outside even of pricing in the SAP system.

After that basic configuration, the book also explains how to create a master database on what you configured before, using examples that were covered in the first chapter. It comes full circle in the third chapter, explaining how all your master data comes up with a final price to the customer.

Is it also for more seasoned consultants? Yes, because in the later chapters it goes into special pricing scenarios like free goods configuration, which was one of the big missing links in 3.0. In some of the user forums, the recurring question was how to do "buy one get one free." This was the big pricing question in these releases, and that got improved through the releases as well. Free goods are covered, rebates, sales deals, promotions, etc.

The final chapter of the book goes into the custom modifications. This goes back to what you mentioned earlier, that you need ABAP skills to tweak the system if the standard functionality is not enough to fulfill the customer's business requirements.

Reed: I want to shift now to the project team itself, and you can answer this question one of two ways. I'd like to either know about mistakes the project should avoid in pricing or some of the keys to success around pricing initiatives.

Liebich: What you should do from the project management side in a project group is to understand first how products are priced at a customer. What are the components? What are the different prices you have, what allowances, which charges, which rebates, etc.? What are these prices built on? You should spend most of your time understanding these requirements. Based on these requirements, build your price and design.

What you should not do is start configuring one requirement after another. You will not have much success. It gets convoluted, and you would have to redo a lot of work. It's really important to get all the business requirements first and then apply this in one design.

Reed: For a project team that's trying to best understand pricing, is this book something you think can make a difference there as well?

Liebich: Yes, I think so. The Ultimate SAP Pricing Guide is structured in chapters that build on each other, so you can flip through and try to see how condition records are created, but it won't do any good if you don't understand how the configuration works and what the components of the pricing system are. The book will provide you with a good understanding of why things happen a certain way in the system and how you can change it to meet your business requirements.

Reed: A lot of my readers and listeners are very interested in what it takes to succeed as an independent consultant. I'd like talk a couple of minutes about your own career because you've done that for a long time now. One thing that struck me is that you have a broad range of skills. You're not just a pricing person, but pricing has really been the core of how you've gotten hired on projects. What are some of the keys to your success in this field for so long?

Liebich: One is to always add to your knowledge. For example, you start with pricing, but you can't see pricing as a sole component because pricing is part of the Order to Cash process. So you have to have an understanding of how an order is created, what drives pricing based on the order, what can change between the order and the invoice side, if you're going to reprice and waste time, if you keep the prices the same as sales orders. What are you going to do on credits? Are you crediting for all the pricing components you had on the original invoice, are you only doing partial ones, etc.?

As I mentioned before, if you understand the condition technique you can apply this not only to pricing but to other components in the SAP system as well. So for example, on one project I reconfigured the whole packing functionality, which also is based on the condition technique principle. This got me a spot on a team that implemented the first truck optimization functionality at sales order time, basically seeing a real time truck displayed based on the items that were entered on that order.

Build on the skills you have, and if you have a thorough understanding of the condition technique you can apply it to other components as well.

Reed: That makes a lot of sense. And then of course don't be afraid of ABAP.

Liebich: Right.

Reed: Good advice for the pricing master. I imagine, too, on the ABAP side there are probably opportunities to move into more functional directions through scenarios like pricing.

Liebich: That's correct.

Reed: I want to let our listeners know that Matthias and I have been collaborating on this book now for two years; it's been a shared passion for both of us to put this in print. I think when you read the book, you're really going to get a sense of why it is really an achievement on his part, and the sacrifices he put into it.

Do you have any closing words of advice for anyone who might be thinking about writing a book? A lot of us talk about writing books, but not very many people finish.

Liebich: It was a long process, but I'm glad I went through it. You have to stick to it. You have to have a concept. Don't get discouraged if you get stuck somewhere. What I can only advise is to go through it in a logical manner: explain it as if you were trying to understand it yourself. Again, I wrote this book because I wished I had that book earlier in my career to understand the step-by-step instructions to get to a good result.

Reed: I think it's a good result indeed. For those listeners who are interested in learning more, we're going to post some of the book samples on JonERP.com. And of course on Amazon we've already seen a number of viewers chime in with their thoughts, so you can check out the list in there and read some of the reviews for yourself and get a feeling for what people in the field are saying about the book.

With that, Matthias, I'd like to thank you for your time and for sharing your insights on pricing with our listeners. This is Jon Reed of JonERP.com signing off in Atlanta.