Ear­li­er this year, ASUG sat down with Chris­t­ian van Helfteren, author of the SAP Press book ​“Con­fig­ur­ing Sales in SAP S/4HANA.” In the first part of our con­ver­sa­tion, we dis­cuss van Helfteren’s back­ground along with some things cus­tomers can do with the sales func­tion­al­i­ties in SAP S/4HANA to make their migra­tion to the ERP solu­tion eas­i­er. 

ASUG: Can you tell us about your work expe­ri­ence and how it’s pre­pared you to write this book? 

Chris­t­ian: I have 30 years of work­ing with ERP solu­tions, includ­ing close to 26 years with SAP. There are mul­ti­ple ways you can learn the SAP S/4HANA. But if you see it in action, there’s no bet­ter way for you to acquire the knowl­edge. You can see what hap­pens along with the reflec­tion of any con­fig­u­ra­tion you put in. That is a very valu­able expe­ri­ence. When writ­ing the book, my expe­ri­ences were help­ful. I also tried to include not just a tech­ni­cal descrip­tion of what a fea­ture is, but also how often it’s used and what kind of indus­tries it is most­ly used in. Some fea­tures may be coun­try-spe­cif­ic. I try to high­light some of that in the book as well. 

ASUG: What is an orga­ni­za­tion­al struc­ture as it applies to sales? Why is it impor­tant to devel­op one when using the sales func­tion­al­i­ties in SAP S/4HANA?

Chris­t­ian: That’s crit­i­cal, even if you’re doing a pub­lic cloud imple­men­ta­tion, which has lim­it­ed con­fig­u­ra­tion capa­bil­i­ties. But the orga­ni­za­tion­al struc­ture is always required and it’s impor­tant for all sales func­tion­al­i­ties. Every­thing you can do in the sys­tem is going to require you to iden­ti­fy which orga­ni­za­tion you’re a part of. That should reflect the way the com­pa­ny is orga­nized. The dif­fer­ent depart­ments, divi­sions, and busi­ness focus ini­tia­tives with­in the com­pa­ny need to be rep­re­sent­ed in the sys­tem using the orga­ni­za­tion struc­ture ele­ments pro­vid­ed by SAP.

[ad]

You will find the sales orga­ni­za­tion dis­tri­b­u­tion chan­nel and divi­sion are pret­ty much every­where you look in the sys­tem. The process of defin­ing them is crit­i­cal. This step comes at the begin­ning of an SAP S/4HANA project. You have to try to make it as lean as you can. One very com­mon issue that I’ve seen in orga­ni­za­tions is that they cre­ate too many divi­sions. Then they end up hav­ing to deal with the mas­sive data impact. Every divi­sion would require you to dupli­cate your sales views on the cus­tomer mas­ter. Unless that’s some­thing you want, you should avoid it. The prob­lem with this dupli­ca­tion is that you don’t know that you don’t want it when you’re defin­ing it. You’re only going to find out prob­a­bly when it’s too late — when it’s already close to your go-live or worst after you’re live. That’s what makes this deci­sion so crit­i­cal in the begin­ning. You need to com­mu­ni­cate all the impacts of the deci­sions that are being made and put togeth­er some­thing that is lean, long-last­ing, and can be expand­ed upon lat­er. One of the main arch­es of the sys­tem is that it’s built for growth.

ASUG: How can SAP S/4HANA users lever­age the ERP solution’s func­tion­al­i­ties to keep the com­pa­nies and the peo­ple that they inter­act with organized?

Chris­t­ian: Every com­pa­ny that your orga­ni­za­tion inter­acts with is now rep­re­sent­ed as a busi­ness part­ner in SAP S/4HANA. Before, all your cus­tomers, ven­dors, con­tract, per­sons, com­peti­tors, and many oth­er clas­si­fi­ca­tions of busi­ness part­ners each had their repos­i­to­ries back in the day. Now that’s all uni­fied into a sin­gle repos­i­to­ry called busi­ness part­ners. From there, you can have a cen­tral­ized data­base that links togeth­er mul­ti­ple roles that that same com­pa­ny may per­form with your orga­ni­za­tion. If you have a cus­tomer that is also a ven­dor, both of those enti­ties used to be rep­re­sent­ed sep­a­rate­ly in your SAP ECC sys­tem. Now in SAP S/4HANA, they’re rep­re­sent­ed as a busi­ness part­ner. This helps with report­ing. You can take a busi­ness part­ner snap­shot and you can see every­thing they bought from you and every­thing is sold to them.

The cred­it check can also take advan­tage of the uni­fied mas­ter data, cus­tomer cred­it stand­ing could affect their ven­dor activ­i­ty and vice-ver­sa. Oth­er oppor­tu­ni­ties like that are avail­able out of the box and more can be expect­ed dur­ing implementation. 

ASUG: What are the main steps SAP S/4HANA users must take to enable the solution’s order-to-cash functionality?

Chris­t­ian: When you tran­si­tioned over to SAP, more fore­thought and plan­ning are required than a lot of com­pa­nies used to have before. When a lot of com­pa­nies look at order-to-cash solu­tions, it’s pure­ly order-tak­ing fea­tures that were put togeth­er just to allow you to record what the cus­tomer wants along with some cred­it and deb­it mem­os. That’s very com­mon­place on any sys­tem. But on SAP S/4HANA, the idea is that you would pre­pare the sys­tem to receive that order and then elim­i­nate most of that deci­sion-mak­ing process that you need to have as you’re typ­ing that order because you’re already set it all up in the mas­ter data. With the order entry, you have to enter even less infor­ma­tion and you achieve even more results than before. That’s the mag­ic of SAP S/4HANA.

But the prob­lem is that it requires all that fore­thought and plan­ning. The users can pre­pare to imple­ment SAP S/4HANA by start­ing to think about what they’re doing at the time of order entry and how can they antic­i­pate that at a mas­ter data lev­el. This will be required once you go into the blue­print phase of an imple­men­ta­tion, or if you’re doing that pro­to­typ­ing approach where you just show them what the solu­tion is going to look like right off the bat. You can pre­pare your­self by learn­ing how the sys­tem works, read­ing some books about it, talk­ing to oth­er com­pa­nies that use SAP, or even bring­ing in the con­sul­tants to help you prep. 

ASUG: What is the con­di­tion tech­nique and how can SAP S/4HANA users use it?

Chris­t­ian: The con­di­tion tech­nique is a very ele­gant way that SAP allows you to do many fea­tures in the sys­tem, it has been around since the ear­ly ver­sion of SAP R/3. First and fore­most is pric­ing, which can get very com­pli­cat­ed espe­cial­ly if you go to trade com­pa­nies that are on the IAS Trade Indus­try Solu­tion. But all com­pa­nies have pric­ing poli­cies and you can auto­mate a lot of the mag­ic that takes place out­side the sys­tem on anoth­er sys­tem. Now, instead of always rely­ing on out­side fac­tors, you could build in some of the pric­ing com­po­nents. The con­di­tion tech­nique would allow you to be flex­i­ble. It will allow you to rely on infor­ma­tion that you cap­ture in many places through­out the sales order process and then affect how you cal­cu­late your prices in a dynam­ic fashion.

You could con­fig­ure new prices on the fly. If you’re on the con­fig­u­ra­tion side things, chang­ing the sys­tem is not just for pric­ing. You have oth­er fea­tures like list­ing exclu­sion and out­put deter­mi­na­tion. The main idea of the con­di­tion tech­nique is to allow you to make some­thing hap­pen on your order, such as list­ing exclu­sion pric­ing or out­put ter­mi­na­tion, based on cri­te­ria that SAP did­n’t think of but you and your con­sul­tant think about. You can just imple­ment it with­out devel­op­ment and with just con­fig­u­ra­tion. It’s some­thing that can be done in a few hours that in oth­er ERP sys­tems, you may have to hire devel­op­ers and wait a cou­ple of weeks to get done.

In S/4HANA you can use SAP BRF­plus to replace some of the con­di­tion tech­nique con­fig­u­ra­tions such as pric­ing and out­put deter­mi­na­tion, this is like­ly to become the norm on future ver­sions although adop­tion is slow.

You pur­chase ​“Con­fig­ur­ing Sales in SAP S/4HANA” from SAP Press here.