Anton Karnaukhov

SAP S/4HANA Embedded TM - Frequently Asked Questions (FAQ)

Author's Note: This post was originally published in January 2018 and has been updated for accuracy and comprehensiveness to cover S/4 HANA 1809 release.

With the release of S/4HANA 1709 SAP customers have been able to run SAP Transportation Management functionality on the same instance as their ERP solution.  S/4HANA 1809 release has made the embedded TM option even more appealing, by closing most of the functional gaps that S4/HANA 1709 release had with the AnyDB stack TM release 9.5+. The embedded TM option certainly looks very appealing, as it reduces the complexity of several interfaces and data duplication.  However, the embedded SAP TM alternative has its limitations that are important to understand and take into consideration.

We have compiled a number of frequently asked questions and answers in regard to embedded TM offering in SAP S/4HANA and published them for your reference below.  Please note that the information provided below is accurate as of the writing of this post (August 2019) and relates to S/4HANA version 1809.

SAP Transportation Management - Frequently Asked Questions (FAQ)

We decided to compile and share a list of question about SAP Transportation Management (TM) that we hear most frequently from companies that are interested in learning more about SAP TM.  A lot of these questions are fairly basic and high-level, so this FAQ will be most helpful to people who have limited knowledge of SAP Transportation Management capabilities and requirements.

BRFplus - a hidden gem within your SAP system

No matter how much one tries to minimize customization in an SAP system some volume of custom business logic is usually unavoidable.  Historically this meant introducing custom ABAP syntax in various user-exists, enhancements, BAdI's and custom programs.  Given the complex and interdependent nature of an SAP system, it becomes imperative to carefully manage such ABAP-based customization in order to ensure that business logic is in sync across various functional areas and is not duplicated.  That's where SAP Business Rules Framework Plus (BRFplus) comes into play - a fairly new piece of functionality from SAP that makes it possible to manage all of your custom business logic in a single place and in a re-usable way.

A dinner chat with Mike Vizdos

I've been following Mike Vizdos @mvizdos on Twitter for quite some time now.  His popular web site mixes a healthy dose of cartoon humor with some very practical and handy advice on utilizing Scrum.  So when Mike tweeted about being in Sacramento for the week we reached out and asked if he would be interested in exchanging ideas over some food and a couple of brews.  Thankfully, Mike was gracious enough to accept our offer.

We ended up discussing some engaging topics and ideas, many of which left me thinking and reflecting on for many days to come.  But there were a few discussion points that left an especially long-lasting impression.

Feature planning in an agile SAP implementation

In one of our previous posts we talked about the core roles and basic team structure in an agile SAP implementation.  We are now ready to take a look at one of the first steps in planning the implementation and assessing the work that will need to be done by each team - defining the project features. 

A feature (aka epic or epic story) is the next level down from the overall project in that a single project contains one or more features. There is no black and white rule on what makes up a feature but here are some guiding principles that we try to utilize:

Agile Terminology for SAP Project Teams

We don't need to tell anyone who is used to working with SAP that getting the terminology right is often a daunting task.  Agile project management brings with it a number of new terms that are critical to understand in order to be able to comprehend any of the detailed discussions on how agile can help you implement SAP solutions in a better way. These terms are by no means universal, but at BestXperts we do try to use the terminology that is most common in the agile circles, regardless if we are talking about SAP implementation projects or building a web application.

Team Structure in Agile SAP Implementation Projects

One of the first things that each software implementation project has to worry about is the general structure of the project team.  We at BestXperts have tried a few different variations of project team composition over the years and can definitely attest to the fact that there is no canned project team setup that will work on every project.

Constriction to Force Ourselves to Create

As I was reading Mike Cohn's "Agile Estimating and Planning" for the last couple of days, I've taken some notes that I thought were worth sharing and discussing.  The later sections of the book really focus on the technical aspects of agile planning, such as using points for estimation, planning poker, release planning, etc, all of which I was already fairly familiar with.  For me, most of the interesting observations were in the first half of Mike's book where estimating and planning is discussed in broader terms and contrasted with counter-part approaches in waterfall project management.

Things you SHOULDN'T do in an agile SAP implementation

It's one thing to have the desire to implement SAP software in an agile way, envisioning the benefits of significantly lower cost and much happier end-users.  It is a whole other thing to actually make it happen, resisting the constant desire to fall back to the old waterfall ways of doing things.  And have no doubt, that desire will be there for quite some time, like a juicy carrot on a stick - if only we could map the entire project in a Gantt chart, if only we could put a deadline on every task no matter how far out that task is, if only we could achieve precise estimates on anything and everything and compare them to actual time spent, then and only then we can take control of the project, determine exact go-live date and keep our executive management properly informed.  Falling into this type of thinking in an agile project is very simple.  Having the understanding, discipline and commitment to the core principles of agile throughout the entire project is often very difficult.

US needs to produce more native SAP professionals

To most people the term "SAP" is nothing more than a cryptic abbreviation.  It is far from a household name.  Few are aware of the fact that SAP is the largest business software company in the world.  Even fewer know that roughly 65% of the world's business transactions run through an SAP system at one point or another.  In many ways, SAP software runs the business world.  And every year it runs more of it. On top of this, SAP software implementations are no longer reserved for billion dollar companies with deep pockets.  We at BestXperts have a number of customers with roughly $100 million in annual revenue that have successfully implemented SAP and are able to run their business in a sustainable and flexible way.  And once a company implements SAP it typically goes on a long-term cycle of optimization, streamlining and automation of business processes through the enhancement and use of additional functionality from SAP.

Running SAP projects - the path from waterfall to agile

We at BestXperts did not adopt agile project management overnight. In fact, it took us years to come up with an approach that was both repeatable and scalable. At first we dispensed with the idea of massive upfront blueprinting and instead began to have many mini-cycles of blueprinting, realization and testing throughout the project. In the process, we started structuring our project schedules around “sprints” and conducting daily standups to facilitate active communication within project teams.

ERP for the modern age

Don't get me wrong, we at BestXperts are diehard SAP fans. After all, we earn our living by implementing SAP software. But there are times when we just can't stop ranting about SAP idiosyncrasies that drive us crazy. Most of these rants boil down to one common trend - SAP is unnecessarily difficult. Some of this stems from the fact that SAP has turned into a behemoth with a number of large acquisitions in the last 5 years which seems to have impacted SAP's ability to execute quickly and with acceptable level of quality. Other times we get really frustrated with SAP's "enterprisy" approach to such things as mobility and web services which feel very bloated when compared with the modern technologies and approaches used in those areas in the consumer space.

So we decided to do what we do best - dream a little. What would an ERP system look like if it was built today, in 2012, making use of the current trends and technological advancements in the software development space?

Investing in relationships with your clients pays triple

Here is a real situation. Two SAP consultants are equally knowledgeable, equally diligent and equally passionate about their work. Both do a great job at gathering business requirements, configuring the system and getting things done in a reasonable amount of time. One finishes a successful go-live and gets praise from the client. The other is accused of taking too long, not keeping the client properly informed and is cut from the project. The only difference between the two consultants was the amount of time and effort they put into building personal relationships with their clients.