Saturday 2 November 2019

What’s different in SAP Sales and Distribution (SD) in S/4 HANA

If your knowledge of SAP’s S/4 HANA only came from attending Sapphire, or reading the company’s marketing materials you might think that it was old news. After all, the product launched four years ago and has been pitched so hard since that surely by now every SAP customer must have not only drunk the Kool-Aid dry but also signed up and finished implementing it. But outside of the Orlando conference center spin zone, businesses need more than trade show hype to jump at the latest bright and shiny object. Business cases must be made, budgets approved, and projects scheduled, all of which take time. Lot’s of time.


On a personal level it was just this year that I completed my first SAP S/4 HANA project as an SD consultant. And despite a mountain of marketing materials, I found very little useful information about what exactly is different in S/4 HANA vs ECC and specifically from an SD perspective. I thought I would share my experiences and a few tips and tricks learned along the way. To set the stage, the project I was involved with was implementing the on-premise version of S/4 HANA 1809, with the hardware hosted remotely by the consulting company. By the way, someone will have to explain to me sometime the point at which on-premise and cloud diverge. With the servers thousands of miles away how is this still called ‘on-premise’? But I digress. As I said this was my first S/4 project, but far from my first rodeo. I’ve been implementing SAP SD for the past 22 years, ten years with SAP America and the last twelve as an independent contractor. So like the Farmer’s insurance company ad says, I like to think I know a thing or two because I’ve seen a thing or two.

How different is SD in S/4 HANA compared to ECC?


Here’s the good news (shh, don’t tell anyone), 80% of SD is exactly the same in S/4 HANA as it was in the earlier versions of SAP. And when I say exactly the same, I mean exactly the same. Pricing is the same, sales orders are the same, texts, item categories, deliveries, billing, on and on and on, all the same. It was actually surprising to me how few differences there actually are. Digital core my eye!

What is different in SD in S/4 HANA?


Ok, so if it’s 80% the same then what exactly is different? And why isn’t this information easy to find? Let’s break it down in my completely unauthorized, un-scientific analysis of what’s different, in order of impact:

Fiori, Fiori, Fiori 

If your customer is implementing S/4 HANA there’s a pretty good chance that they’ll be using the latest and greatest revolution in User Interface technology, a thing called “Fiori” or as I like to call it, ‘Web Pages’. If you’ve ever used a thing called ‘The Internet’ you’ve probably seen web pages. I’m joking (a bit). At it’s best, Fiori is more than just HTML enabled SAP screens. Some of the Fiori tiles/apps are actually new screens that combine functionality from several transactions in the ‘backend’ (that would be S/4 HANA in this case), and really do improve ease of use and look pretty good. However it’s really sort of a mixed bag – some of the Fiori tiles are just the same old SAP tcodes, web-enabled and made slower and more awkward with scroll bars embedded within in scroll bars that make using them just painful. Then there are some things that just don’t quite make sense. There is a manage sales orders app which gives you a nice sales order list and is quite a visual improvement over good old VA05. It’s also got a hyperlink in it to launch a ‘create sales orders’ tab. And of course, there’s a tile just for sales order create. But somewhere, somehow, someone decided that you don’t need a quotation create or a sales contract create tile. Those features are only available within the manage quotation or manage sales contracts apps. So creating a quote or a contract becomes a two-step, two-click process for no apparent reason. And speaking of sales order create, the mother of all SD transactions, within Fiori it is…drumroll please…here it comes …wait for it…..just an HTML version of the VA01 screen, but made more awkward. Would it be too much to ask that someday, someway, SAP introduces any easy configuration tool that lets you control the tabs and fields on sales orders? Here’s a secret – we’ve had this on service notifications and service orders for over 15 years! Would it be too much to ask to have something similar for sales orders? In my experience over half of the tabs and fields are unused for any given customer and the busy-ness of the screen just frustrates people. (Whatever happened to ‘simplify’, Bill?)

SAP S/4HANA, SAP S/4HANA Cloud Sales, SAP Sales Manager, SAP HANA Study Materials

The next thing to be aware of with Fiori is that it runs off of a second server/system. The browser connects to the Fiori gateway server which connects to the S/4 HANA system. The Fiori user logs on from their browser to the Fiori gateway server/system which contains all of the Fiori roles, and then that system connects to the S/4 HANA system (the ‘backend’) which has all of the ‘regular’ user roles. So now we’re dealing with two sets of user roles, one that controls what is visible (which tiles do you see when you log on to Fiori) and another that controls what is possible (the normal security profiles/roles in S/4). And now you’re going to learn way more about roles than you ever wanted to as an SD consultant because you or your users either won’t see the tile you want, or you’ll see it and it won’t work. Sometimes. And sometimes the tile you want won’t be there. And you’ll have to figure out whether the tile exists and is not assigned or whether it doesn’t exist as a tile, and you have to get a custom tile created for a standard transaction. And here’s where Fiori is different. SAP has a web site called the Hana apps library where you can search by tcode and find out if there is a Fiori app for something like serial number display, and search for what role it’s in. And sometimes the tcode mysteriously isn’t in a role at all (maintain email template, I’m talking to you!) so you have to get your tech guys to create a custom tile for what you want. And all these fun and games when you’re in the middle of a fast-moving project. And speaking of fun and games, I’m sure everyone remembers that the great promise/premise of HANA is the speed. Lightning fast, right? Well, I’m not a basis guy but when you stick a Fiori system and a browser in front of it, what we were seeing on my project was not lightning fast. Half the time we’d get the three balls of doom – the Fiori equivalent of the old clocking circle of wait.

Reporting, Reporting, Reporting

Another huge change in the S/4 HANA /Fiori world is reporting. Bye-bye BW. Adios BI. All of the sales reporting is now directly in the transactional system, accessed via Fiori apps.* Not only are there a fair amount of pre-delivered reports, but there are also tools that let you pretty easily build your own custom reports/queries/cds views. It’s actually pretty awesome except 1)Trying to figure this out in the middle of a project takes time, 2) What the heck is a cds view,** 3) On our project we had no reporting resource so the SD guy is now the reporting guy, 4) The last time I did reporting was on 3.1 before BW when we were still messing around with info structures in SIS / LIS etc., 5) I was actually interested/excited to do something new (reporting) but with the project moving at warp speed that can was always kicked down the road and there wasn’t enough time to do reporting, let alone learn it properly.

*Ok, calm down reporting nerds, yes there is still the possibility to have a BI system and link it to Fiori, blah, blah, blah, Roadmap, blah, options.

**Independent consultants get to learn by doing rather than going to training classes.

Business Partner

This is the one difference you’ll hear about the most often. In theory, it makes sense. The concept is this – an entity that a company does business with has different roles. That same entity could be both a customer of the company and a vendor to the company. And a way to describe that relationship is the role the entity plays. So in S/4, we have business partners instead of customer master, and those business partners have the role of ‘customer’. Ok, so conceptually I’m down with this, it makes sense. But in practical terms, what SAP has done in the BP transaction is add a million and one roles to scroll through, with different screens and tabs, and new things to learn. To solve what? That we occasionally had to link a customer and vendor record? As an experienced SD consultant the main things you’ll need to do are:

Get familiar with the navigation within transaction BP

A customer will have to be created in three roles: General, Customer (Fin Accounting), Customer. Have fun scrolling. Tip – if you open an existing customer in display mode instead of change only the existing roles will show up and you’ll do a lot less scrolling. You can also configure the default to open in display instead of change. You can also configure to hide unused roles but that impacts everyone.

When you create a customer BP it will probably be as an Organization (a company).

The Grouping field controls the number range so if you want to use a specific number range check out the help on this field before trying to customize your own. It might already exist and all you have to do is create the customer, sorry, business partner with a specific entry in this field.

Within the customer role, you have to select the sales and distribution button at the top to have all of the familiar sales area dependant SD fields appear.

The vast majority of the fields are the same. Sales District is new but everything else is pretty much the same that it’s been forever. The transactions XD01 and VD01 have been removed and replaced with ‘BP’ but customer business partners are still built on top of the same tables, KNA1, etc. Enjoy!

BRF+

BRF+, or Business Rules Framework, or what happens when you give developers the keys to the car. This has got to be my least favorite of the S/4 HANA innovations. I know I’m going to sound like a crusty old man, but you take what was working perfectly fine, in this case Output determination, and replace it with some half-assed kludgy pseudo-programming interface, and well, let’s just say I’m not a fan. Rather than detail out my gripes here I’ll just pass on a few tips:

◉ BRF+ is optional – at least in 1809 you can still use regular output determination instead. Choose wisely grasshopper.

◉ BRF+ doesn’t work for all SD output – Sales orders, yes. Billing docs, yes. Deliveries….oops. But for an added twist, it kinda looks like it might work for deliveries, and you’ll try, and search and search for answers and try to figure it out, until you come to this same conclusion.

◉ Configuration tools – lotsa fun here! It’s partly in the IMG and partly in a web interface. But for the web part to work someone has to do some XML mumbo jumbo.

◉ Configuration – most of the configuration is done in the aforementioned web interface. So you’ll need to spend a bunch of time figuring this out. Tip – when you can’t find something that should be there, it’s probably hiding because you don’t see the scroll bars to go to the right until you scroll down. Madness.

◉ Transports – Rant begins: the web configuration piece is transportable, but it appears to be all or nothing, in that it doesn’t transport just your changes but rather everything. And if someone else has made changes before you what they changed gets locked up under their transport and even though you reassign it to yourself it still won’t unlock even after you move it, and instead you go directly into the test system and make your changes there, but everytime you transport from development your changes get overwritten, because as I said at the beginning it transports the whole damn thing. Rant finished.

Status Tables

This is one of the few things I could find information on. The sales order status tables for both header and item have been moved to VBAK and VBAP. You won’t really care about this unless you’re building an interface or custom report.

AATP and Bop doo Wop

If you thought ATP was cool, now there’s ‘AATP’ or Advanced Available to Promise. My experience with this went as follows: Oh, I see there’s some new functionality called AATP. I wonder if that would be useful for our project. Let’s see, it says here that it requires an additional license, bummer. Oh wait over here there’s no mention of an additional license, hmm. Ok, let’s see where it’s setup. Here’s a config setting for item category to use advanced atp. Set it. Nothing happens that’s different than regular ATP. Hmm. Back to Google. Back to SAP help. Conclusion – unclear and out of time. Suspicion – the ATP part of AATP is just a rebranding that combines old ATP with what really is new which is….

BOP

Backorder processing has a new name in HANA land. Now it goes by ‘BOP’. You might have known it by the name of its twin sister ‘Rescheduling’, but apparently there’s something new under the sun in S/4 Hana. At least that’s what SAP says. Lot’s of marketing videos on this one. The videos will tell you a story about how BOP is the love child of ATP and APO, and all the groovy new features. There are “winners and losers”, “gainers and fills”, and “redistribution strategies”. Sounds pretty cool, right? I thought so, until I tried to use it. Here was my experience:

1. Log on to Fiori and Search for relevant BOP tiles – Fail
2. Search SAP website for tile info – Success
3. Ask the technical team to add tiles to your role – Success
4. Launch tiles – Fail
5. Research which of the three tiles you are supposed to use and how it’s supposed to work – partial success, not a lot of clear detailed information on this.
6. Create a variant for BOP job – Fail – technical error

I’ll stop here to tell you that behind the scenes of BOP is a whole boatload of basis stuff including a HANA DB connection, a HANA XS connection, a HANA rules framework, a bunch of OSS notes, and a lot of other techno-junk that a functional consultant has no business being involved with. I just want to see the winners and losers, but instead, I spent close to a month going back and forth with support teams. Continue.

1. Schedule BOP job – Success

2. Review BOP results – Fail because the job had failed. Who knew that I would become familiar with the term ‘Artifact Generation’ and the myriad of ways it can fail?

3. Search notes, more technical fixes, finally the first job completes!

4. Ready to explore how to work with it and party like it’s 1999! Oops, out of time.

Seriously out of time! The window for exploring options had closed, and it was time to cut bait or fish. Is it too much to ask for SAP to deliver standard functionality that works out of the box without multiple people messing with it? This was the opposite of simplicity.

Activate and Project Methodology

While it’s not necessarily tied to S/4, one of the items that falls into the new and different category is the latest SAP project methodology, “Activate”, which to me is akin to ASAP having a one-night fling with Agile, and then kicking him out the next morning. Yes, you’ll find a bit of Agile terminology sprinkled about (can you say ‘Sprint’?) but for the most part, Activate just seems like a rebranding of ASAP. So instead of a ‘Blueprint’ phase, we have a ‘Discovery’ phase, yadda yadda yadda. I suppose the idea is to ease the customer’s mind around project implementations. We are not implementing in fact, we are just ‘activating’ the software. One big positive that I found around the new methodology is that it comes delivered with a whole host of pre-defined, pre-configured, and pre-documented scenarios. The documentation includes pre-written test scripts for each scenario which really speeds that task. And if you find a customer who doesn’t want any changes, the system is pre-configured and delivered ready to go. Just let me know when you find that customer.

Final Thoughts


To wrap up then, here’s my take on how the changes stack up:

Fiori – A mixed bag. Overall a more user friendly interface, with some apps having an improvement in functionality and some a step backwards. New customers might prefer it but consultants and power users will find it cumbersome.

Reporting – A big improvement. One system to rule them all. Bye-bye BW.

Business Partner – All sound and fury, signifying nothing. Meh.

BRF+ – Someday I will find the demon developer who foisted this upon the world. Until then, suffer in silence.

Status Tables – Comme ci, comme ca.

AATP and BOP – Ya coulda had class. Ya coulda been a contender. Ya coulda been somebody, instead of a bum, which is what you are.

Activate – About time customers don’t have to pay for consultants to keep re-writing documentation. Thank you.

Staffing a project – a final thought on resources based on my experience. If 80% of the functionality is the same, I’d take a seasoned SAP veteran without S/4 experience any day over a newly minted, S/4 “certified” consultant any day. Of course with all the rampant resume / phone interview / body shop / H1-b fraud that goes on these days, it’s caveat emptor.

No comments:

Post a Comment