PLANNING A PERFECT S/4HANA PROJECT

Starting an SAP project takes a lot of convincing. Executives see them — with good reason — as costly, lengthy, and risky undertakings. Many stakeholders may have vivid memories of crowded meeting rooms and operational troubles after ERP rollouts. But if the board puts off such a vital project for years, essential IT staff may leave the company to look for S/4HANA opportunities elsewhere.

Eisenhower said, “Plans are worthless, but planning is everything.” No implementation project starts without an approved budget — and to get that, you need a plan. The board will demand costs and timelines. But what they are especially interested in is the mitigation of risk.

Therefore, let’s learn how to take the risk out of an S/4HANA project.

THE FIVE FUNDAMENTAL RISKS TO AN ERP PROJECT

In practice, project failure is due to a combination of the following five factors:

1. Underestimating process complexity​: only a few business stakeholders know the nitty-gritty details of processes. They are few and notoriously short of time. However, without a clear picture of the most complex processes, projects go invariably off the rails.

2. Poor advice​: Blame the consultant! Truly, SAP S/4HANA is a booming market. If you choose the wrong partner, you may end up with a crowd of juniors doing internships — at an inflated cost.

3. Technical risks​: R/3 was “involved”, but S/4 is a beast of multiple technology stacks: Java, gateway technology, complex table structures, and object-oriented programming.

4. Overly optimistic project planning​: Consistent with the Dunning–Kruger effect, many consultants suffer from delusions of superiority and completely underestimate the project’s true magnitude. I like to call them the “belly-button estimators.” They are a great threat to the project by putting the project on the wrong track from the start.

5. Decision paralysis: According to Patricia Gaffney, “misery alternates with euphoria.” Once the initial budgets are overrun, without any visible results, decision-makers are in trouble. Feeling trapped, they procrastinate on difficult decisions, and projects accumulate mountains of costs.

When these five risks are not managed, the final product ends up having severe gaps in functionality. Support staff picks up issues. If you’re lucky, there is still a budget for external help to provide focused support.

COMING UP WITH A PLAN

When a consultant tells you from “experience” that a project like yours should take this or that amount of time and money, your program is in deep and utter trouble. Whatever any “expert” says, implementation projects require extensive preparation. No project is the same, and the devil is in the details. SAP projects are far from standardized products — they are highly unique, customized installations.

Unfortunately, planning requires money. It is the age-old chicken-and-egg story: there can be no plan without money, but no money without a plan! Fortunately, if you do it right, you may not need large budgets in the beginning.

1. Key capability definition (weeks to a few months)

2. Architectural roadmap (several months)​

3. Creation of prototype (six to twelve months)​

4. Budgeting (one to four months) ​

5. Project execution (years)​

6. Hypercare and full support (forever, hopefully)

Instead of an all-or-nothing approach, the project starts slowly and gradually ramps up. This approach saves resources and allows staff and business key users to participate. An agile approach is best suited for steps one to three. After this, develop a rock solid waterfall plan that allows for clear traceability.

While your key business stakeholders can participate, they won’t disappear in overcrowded meeting rooms for the next two years. Follow a fact-based approach and keep discussions open but avoid lengthy yadda-yadda-yadda meetings. It will build bridges between business and IT, get stakeholders on board, and train key junior users who will prove indispensable for the hard project work.

KEY CAPABLITY: BUSINESS MEETS TECHNOLOGY

Whatever expensive functionality in SAP is essential for the company’s survival is a key capability. Now, creating an invoice, coordinating a simple returns process, and printing a delivery note — these functionalities are all standard and do not need a lot of reflection. Sure, it costs money, but any Tom, Dick or Harry can implement it. Typically, about 10 to 30 fundamental issues within a company are hard nuts to crack. For example:

· You receive sales data from a multitude of distributors, providing your basis for distribution statistics. How do you consolidate the customer data automatically into your database?

· A steel manufacturer needs to customize his products to customer demand carefully — is it still possible to standardize some components and provide systematic material numbers?

· How can a company-wide materials requirement plan be achieved?

· How do you automate the production material supply safely without risking a grinding deadlock?

· Can you achieve a 24-hour delivery and fully track transport through a net of various distribution channels?

You can be sure that your customer master data, your accounting processes, and many other aspects will require careful consideration. Your IT staff will not understand at first how to do it all in S/4, but it is vital for business and IT to get a common understanding of the challenges.

Organize a couple of workshops for logistics, finance, production, and any other functions you have in the company. If there are several divisions, make sure each division receives separate and careful treatment. It requires a delicately calibrated meeting and substantial skill. External support of a trusted consultant may also be a good option (make sure you get a true expert!).

ARCHITECUTRAL ROADMAP

For decades, IT departments have been bastions of SAP. Over time, SAP specialists complained about shadow IT while other software slowly encroached into their perimeter. Today, IT is more than SAP or ERP. Many specialized applications can be purchased from a host of vendors. Increasingly, companies also supply software development for free-style applications that cannot be bought anywhere in the market.

Consider that Google, Amazon, and Facebook all use the flexibility of software development as a critical enabler for their businesses. It’s no surprise that all three CEOs are technology experts rather than marketing gurus.

For these reasons, it’s time to take stock of your company’s ecosystem and make sure you have the right solution in place. It’s also wise to treat non-ERP offerings of SAP (SuccessFactors, BW, Fieldglass, SAP CRM, C4C, etc.) just as any other application.

You should analyze them using these four criteria:

· Efficiency of resources: What are the roles of a system, what is it less suited for?​

· Diversity of applications: Does one more system make sense, or do the costs outweigh the benefits?​

· Scalability: Does the system scale well with a larger turnover and more employees? Can it also scale down in times of lower revenue?​

· Adaptability: How resilient is the system to a crisis? Is it easily replicated to new acquisitions? What new business demands might there be, and how will the system react to them? How does it integrate into security and GDPR?

It is neither necessary nor likely that the project team will end up with a full-blown and complete vision of a company’s system landscape. A good view of the essential systems and an awareness of the others is sufficient as a first step. The roles and limitations of systems should be clear; precise interface definitions may come later as part of a larger project.

PROTOTYPE

Now the team is ready to build a prototype. The purpose of the prototype is to discover delivery options, estimated costs, and a basis for the blueprint. A methodology like SAP Activate is very helpful, even if you don’t follow it to the letter. Pay good attention to the SAP readiness check.

Using external experts with S/4 experience is hugely helpful, but they are unlikely to be required full time. If you run your budget as a tight ship, a few handpicked freelancers topping off other assignments can be a good option. Set up a test environment via SAP’s cloud service.

Select a team of your best SAP people, and make sure you have the business on board. Often, the top key users will not mind participating a few hours a week. A prototype does not require everyone to be “fully on deck.” It’s all about thinking and getting options together — allow ample time for this creative and agile process.

Set up a virtual project room with Microsoft Teams, Zoom, or other means. Plan it as an agile project with a defined scrum master and product owner. The advantages of using a prototype approach are that it is low risk and it can provide good visibility of costs and potential timelines.

PLANNING THE PROJECT

Up to this point, no big decisions have been required of the board. Funding would have come from a separate budget small enough to not raise eyebrows among the board. But that time is over!

Now it is essential to plan and budget the whole program carefully. You need external consultancies, backup for support staff going into the SAP project, and particular specialists. The project team should now have a defendable vision on why to go Brownfield or Greenfield — or if a hybrid Bluefield approach is possible.

This ERP project must be planned as a waterfall project. Many consultancies try to sell you an agile project approach — meaning that the deliverables are not clearly defined at the start of the project. You are not setting up a new website or an internal efficiency project with a team of six people. SAP rollouts are huge undertakings with many stakeholders, all holding you to a tight timeline and a well-executed rollout plan.

Consultancies should never dominate the steering committee — allow only the project manager plus one senior partner. Otherwise, they can easily overpower the steering committee with smooth talk. Define an experienced internal project manager, and source from outside only if there is no appropriate internal candidate.

Select one or many consulting partners and define a strategy for hiring freelancers, who often provide maximum skill at minimum costs. Ensure the participation of internal IT and key business stakeholders and come up with a hosting plan. Will you use the SAP private cloud or (for small-scale projects) the public cloud?

GETTING BOARD APPROVAL

Of course, in some companies, the above approach may not be feasible. All too often, internal politics and influential stakeholders can overrule sound decision-making, and this kind of poor planning will eventually make the project problematic.

Especially when opting for the Greenfield approach, you may consider starting with a small site first. Don’t make the first step too complicated. Keeping it simple will help to ramp up skill and experience as well as minimize risk as perceived by the decision-makers.

A smart board will appreciate your initiative. By now, you are in a position to present a sound plan that helps to reduce risks and costs and that optimizes timelines. You have a clear definition of functionality and a clear view of the complexity of the project. New business process experts can be trained and their support added to the project.

It is highly advisable to communicate carefully and provide thorough information before the board’s decision. They may very well be concerned that an ERP rollout will block every other program. SAP has a reputation for causing trouble and creating havoc within a company, and many SAP programs go off track, often even fail.

Show your board you can do much better than that!