Renovating your SAP House part 3: (the programme schedule)

Continuing on the home improvement theme from part 1 and part 2...

Having decided on the changes that you want to make as part of your renovation project, you then need to work out a plan for delivering those changes. There are very different ways of addressing this as is evidenced by the differing approaches that I took on my own home renovation project in contrast to some near neighbours doing some major work at the same time. I took a decision to stay living in situ while building progressed, with a stipulation to always retain a working kitchen throughout. This did slow down progress (not to mention meaning that everything was coated in a light film of brick dust for months), but did save the additional expense of finding somewhere else to live, and allowed me to keep a close eye on progress. By contrast, my neighbours moved out of their house, allowing for rather more rapid progress, but at the cost of living in a winnebago on their driveway for some months.

Roadmap: breaking down your renovation project into manageable steps

Two key drivers of the plan are the degree of change, and how much of this change you are able to make in situ on a live system (a bit like the 'stay in the house vs move out' example above). Back in the SAP world, taking an approach nearer the brownfield end of the spectrum might be less invasive in the short term, but it will probably take you longer to get to your ultimate destination, with a series of separate subsequent initiatives required to reach the desired end state, which may also end up costing you more overall.

It is sometimes nice to have a break from the constant sound of power tools, or indeed, it may be necessary to phase work to allow time to build up sufficient funds to pay for the next phase of work. This applies equally to building projects and S/4HANA implementations, where change impact, change fatigue, risk profile and budget constraint can all be major drivers behind the project roadmap.

1. Defining the end state

The first point to plot out in the roadmap is where the end state lies. Organisations don't always need to aim for perfection in ERP - sometimes 'good enough' is OK. To guide this decision, it is necessary to define which are your business critical processes (or those which support your USP as a business) up front and aim for perfection there. It is important to realise that in modern composable system architectures, these processes may not even lie within in ERP scope, but might instead be supported by integrated best of breed applications.

The end state may also be budget constrained. In my own home renovation project, whilst I would have liked to refurbish the whole house top to bottom, my bank balance dictated that I just couldn't do it all, so I decided to focus spending on downstairs, and continue to live with some rather dubious '70s Artex upstairs (after all, perhaps it will be come a design classic one day?!)

2. Preparation

In any home move or major renovation project, it makes sense to have a bit of a clear out and do some preparation before you start. The same is true of your journey to S/4HANA. At a minimum, tidying up your data is a good place to start... just like taking all that unwanted junk to the tip before building work begins. At a minimum, doing basic housekeeping like closing out open items in your ledgers; marking redundant master data (such as customers or suppliers) for deletion; running any archiving routines you might already have in place; or even thinking a bit further ahead and considering rework to your chart of accounts or cost centre structures to support the future information requirements of your organisation, are all valuable pre-work initiatives. This step is particularly important for those considering a Brownfield migration, as remember from part 2 of this series - all that data comes with you.

There are some other preparatory initiatives that may be required. As an example: New G/L is a mandatory feature of S/4HANA. Those wanting to carry out a Brownfield migration must therefore already be using New G/L. If you aren't already using it, this may necessitate a New G/L migration project first, which is a significant undertaking in its own right. Back when New G/L was 'new' (a long time ago new), I saw relatively few organisations actually doing a New G/L migration, with more preferring to re-implement and take advantage of the opportunity to make other changes to their system at the same time. The same is true now... and clients needing to carry out a New G/L migration before moving to S/4 may well find it faster / cheaper / easier to move to S/4 via a selective transformation where this step may be incorporated into the migration, rather than carrying out the New G/L move, followed by a Brownfield Migration. The sum of the parts is often greater than the whole in this case. I would also suggest that if a company isn't currently using New G/L on their ECC system, then they probably aren't too much in need of the functionality that it offers, and might struggle to stand up a business case for the New G/L project alone.

3. Plotting out the journey

Once you have worked out where you need to get to, and put the required foundations in place, the next step is to plot out how to get there.

Do you jump to the 'north star' vision in a single, Greenfield step? This might superficially have a high price tag, and is obviously not without business risk, and a high degree of change impact.

Do you carry out a large project - perhaps at the greener end of the selective spectrum? This can end up having many of the same downsides as going full Greenfield - but does make sense if your legacy ERP is largely fit for purpose, but is just in need of future proofing.

Do you minimise risk, and move to S/4 closer to a Brownfield, and then plan a roadmap of smaller improvement / innovation initiatives to get you to your desired end state? This certainly reduces risk, but whilst the price tag may appear more attractive, by the time you add in all those additional projects, it may actually end up taking longer and costing more than that big, riskier Greenfield.

As you can see from this series of articles, there are a lot of different moving parts at play - and there most certainly isn't a simple answer to the 'how do I get to S/4' question... the decision process and journey will be very different in each case. One key take away to bear in mind is that in order to compare the options properly, you rally do need to look across the whole roadmap, rather than just comparing Brownfield vs Greenfield to get to S/4.

It can be a case of the sum of the parts sometimes being greater than the whole.

That thought about the sum of the parts brings me back once more to the home renovation project analogy. A few years ago, my parents downsized by building themselves a new home within the garden of the house that I grew up in - quite literally a Greenfield build. When comparing this to my own extension and reconfiguring downstairs rooms project (a selective transformation) - their project actually ended by taking a similar duration, but actually being significantly cheaper. OK - so there are some unfair comparisons, such as costs of building work at different ends of the country, and the influence of my father's decidedly Scottish frugality on managing a budget... but I think it does illustrate a comparison that companies looking to move from ECC to S/4 also need to make. Often, trying to carry out a transformation around the framework of an existing structure (ERP system) can be much more complicated that starting from scratch - particularly when you are constrained by the baggage of legacy data and processes.