Skip to main content
SAP Implementation

Build S/4HANA on the Standard Process, Not on Modifications

A greenfield SAP build is decided in the fit-to-standard workshops, long before anyone configures a company code. We run SAP Activate properly, start from the preconfigured best-practice process, make you justify every deviation, and keep extensions off the core so your first upgrade is not a project.

50+ ERP and software projects. Zero failed projects since 2021.

SAP Activate Phases
Illustrative
✓
Discover
Trial system, value case, deployment choice
Complete
✓
Prepare
Project team, sandbox, best-practice content loaded
Complete
✓
Explore
Fit-to-standard workshops, backlog of real gaps
Complete
4
Realize
Configuration sprints, BTP extensions, data loads
Running
5
Deploy
Cutover, opening balances, go-live
Next
6
Run
Hypercare through the first month-end close
Planned
Each phase closes on a quality gate your steering group signs.
9-18 mo
Typical greenfield build
6
Activate phases, gated
0
Failed projects since 2021
Clean
Core, extensions on BTP
Why It Matters

SAP projects are not lost in Realize, they are lost in Explore

The configuration work is predictable. What decides the cost is how many deviations from standard you agreed to, and where you put the code you genuinely need.

Fit to Standard

Start from the SAP process and argue your way out of it

SAP ships preconfigured best-practice scope items. We load them into a sandbox before the workshops start, so your process owners look at working screens instead of slides. Every step you want changed goes on a list with a named owner and a business reason, and the list is what the steering group approves. Over several weeks in Explore, most requested deviations get withdrawn once people see the standard flow run.

  • Workshops run on a live sandbox, not a document.
  • Every gap logged with an owner, a reason and a cost.
  • Deviations approved by the steering group, not by the project team.
Process owners running a fit-to-standard workshop on a S/4HANA sandbox
Clean Core

The code you write decides what your upgrades cost

Modifying SAP objects is the reason older landscapes became impossible to patch. We keep the core untouched. Small logic goes in key user extensibility inside S/4HANA. Anything larger sits on SAP BTP, built with CAP or the ABAP environment and talking to S/4HANA only through released APIs and events. Nothing we build reaches into a standard table or a modification. That discipline is not free during the build, and it is the difference between a two-week upgrade and a two-quarter one.

  • Released APIs and events only, no direct table access.
  • Key user extensions in-app, larger extensions on BTP.
  • A written extension register, so nothing is invisible at upgrade time.
Reviewing a clean core extension design on SAP BTP
What We Configure

The S/4HANA workstreams we set up

Configured against the best-practice scope items, then adjusted only where your business genuinely differs.

💰
Finance (FI/CO)
Company codes, the Universal Journal, chart of accounts and group reporting, cost centres, profit centres, product costing and margin analysis, plus tax codes and the month-end close schedule.
📦
Sourcing and Procurement (MM)
Purchasing organisations, material and vendor masters, release strategies, source lists and outline agreements, invoice verification tolerances and the three-way match.
🛒
Sales and Distribution (SD)
Sales areas, order types, pricing procedures and condition records, credit limits, availability check, delivery and billing document flow and revenue recognition.
🏭
Manufacturing (PP)
Bills of material, routings and work centres, production versions, MRP settings, discrete or process orders, capacity planning, confirmations and backflush rules.
🚚
Supply Chain and Inventory
Plants, storage locations and warehouse structure in EWM or inventory management, goods movement types, batch and serial handling, physical inventory and stock valuation.
👥
Human Capital and Projects
Organisational structure and employee master replication from SuccessFactors, plus Project Systems for work breakdown structures, project budgets, timesheets and settlement rules.
How It Works

Five stages of delivery inside the Activate phases

1
Scope and deployment
Value case, process scope, and a decision between public edition, private edition under RISE with SAP, or on-premise.
2
Fit-to-standard
Several weeks of workshops on a loaded sandbox, producing a signed backlog of real gaps.
3
Build sprints
Configuration, BTP extensions, Fiori roles and integrations delivered in sprints with a demo at the end of each.
4
Test and data load
Unit, integration and user acceptance cycles, then at least two full mock cutovers on migrated data.
5
Go-live and hypercare
Cutover on a rehearsed plan, then daily support through your first month-end close in S/4HANA.
What Is Included

Everything a greenfield build covers

📋

Fit-to-standard backlog

Every workshop decision recorded as a scope item accepted, adjusted or rejected, with the reason attached.

⚙

Configuration and org structure

Company codes, plants, sales areas, purchasing organisations and the full module configuration behind them.

🔄

Data migration

Masters and open items loaded with the SAP Migration Cockpit, reconciled against your legacy trial balance.

📱

Fiori launchpad design

Business roles, catalogues and spaces built per job, so a warehouse operator sees six tiles and not six hundred.

🔗

Integrations and extensions

Integration Suite interfaces to banks and third-party systems, and BTP extensions on released APIs.

🛡

Hypercare

Daily on-site or remote support through cutover and the first full month-end close, with a formal exit.

What Changes

What a disciplined S/4HANA build gives you

One
Universal Journal for finance
Clean
Core, upgrades stay routine
Faster
Period close and reporting
Role
Based Fiori people adopt
Fewer
Custom objects to maintain
Real
Time stock and cost visibility
Why Us

Why teams choose TCB Infotech for an S/4HANA build

1
We run Activate as written
Quality gates at the end of every phase, and we will tell you when a gate should not be passed.
2
Standard first, always
A deviation has to earn its place in front of your steering group, with a build cost attached.
3
Clean core is not optional
No modifications to SAP objects. Extensions sit on BTP or in key user tooling, and they are registered.
4
Honest on edition
If the public edition fits your processes, we say so, even though a private edition project bills more.
5
Fiori designed for jobs
Launchpad roles built around what a person does in a day, which is what decides adoption.
6
Proven delivery
50+ ERP and software projects across industries, with zero failed projects since 2021.
FAQ

SAP implementation questions

How long does a greenfield S/4HANA implementation take?
A focused single-country, single-entity build usually runs 9 to 12 months. Multiple legal entities, several plants or heavy integration work push it towards 18 months. The Explore phase alone accounts for several weeks of fit-to-standard workshops, and we will not compress that part, because every week skipped there turns into a change request later.
What does SAP Activate actually mean for us as the customer?
It means you start from a working system rather than a blank one. SAP ships preconfigured best-practice processes, we load them into a sandbox in the Prepare phase, and in Explore your process owners sit in front of the real screens and confirm or reject each step. Your job is to attend those workshops and make decisions. Activate fails when the business sends delegates who cannot sign anything off.
Should we go with S/4HANA Cloud public edition or private edition?
Public edition gives you a two-release-per-year upgrade cadence, a lower running cost and a hard limit on how far you can customise. Private edition, usually bought through RISE with SAP, keeps classic ABAP access and a slower upgrade schedule. If your processes are close to standard, the public edition constraint is doing you a favour, because it stops the modifications that make upgrades expensive. If you have genuinely differentiating manufacturing or industry logic, private edition is the honest answer.
Do we have to abandon the custom processes we run today?
Most of them, yes, and that is usually a win. In fit-to-standard we walk your process against the SAP standard and you justify every deviation in front of the group. Typically 80 to 90 percent of what looks custom is habit inherited from an older system. The remainder is real, and that is where the build effort and the extension budget should go.
What does clean core mean for our existing ABAP developers?
It means they stop modifying SAP objects and start building against released APIs instead. Extensions live on SAP BTP, in CAP or ABAP environment services, or as in-app key user extensions inside S/4HANA. The skills carry over, RAP and CDS are still ABAP, but the habit of changing standard code has to go. That single discipline is what decides whether your next upgrade costs two weeks or two quarters.
What happens after go-live?
We run hypercare through your first full month-end close in S/4HANA, because that is when the gaps in the chart of accounts, the tax setup and the reconciliation reports actually show up. Our team sits with finance and operations daily during that period. After the close is signed off, you move onto a support contract or take it in-house with the documentation we hand over.

Scope Your S/4HANA Build

Book a free consultation. We will look at your process scope, your integration landscape and your appetite for customisation, and give you a straight answer on deployment option, timeline and what the fit-to-standard phase will demand from your team.

Book a Free Consultation →

No commitment. A practical first look at your S/4HANA programme.

SAP Implementation Features

What Is Inside an S/4HANA Greenfield Build

An SAP programme is a sequence of decisions, not a software install. Here is how the fit-to-standard workshops run, where your extensions live, how the Fiori launchpad gets designed, and what your team holds on the day we leave.

Core Features

From the first workshop to a signed month-end close

Explore and Configure

Workshops on a live sandbox, then configuration that follows them

Before Explore begins we load the SAP best-practice scope items into a sandbox, so your finance, procurement, sales and production leads work through their own processes on real screens. Several weeks later you have a backlog where each item is accepted as standard, adjusted with a stated reason, or dropped. Realize then configures against that backlog in sprints, with a working demo at the end of each one.

  • Best-practice content loaded before the first workshop.
  • Every deviation costed and approved by the steering group.
  • Sprint demos on your configuration, not on slide decks.
Business leads working through S/4HANA best-practice processes in a fit-to-standard workshop
Clean Core and Fiori

Extensions on BTP, and a launchpad built around real jobs

Nothing we build modifies an SAP object. Small rules go into key user extensibility inside S/4HANA. Anything larger runs on SAP BTP using CAP or the ABAP environment, calling only released APIs and events, and every extension is written into a register you keep. On the front end, Fiori business roles, catalogues and spaces are built per job, because a warehouse operator who opens a launchpad with six relevant tiles uses the system, and one who opens six hundred goes back to spreadsheets.

  • Released APIs and events only, no direct table access.
  • An extension register handed over for upgrade planning.
  • Launchpad spaces and pages designed per business role.
Designing SAP Fiori launchpad roles and BTP extensions for an S/4HANA build
Cutover and Hypercare

At least two rehearsals before the real cutover

Masters and open items move through the SAP Migration Cockpit, and each load is reconciled against your legacy trial balance and stock position before sign-off. We run at least two full mock cutovers against the timed plan, so the go-live weekend is a repeat rather than an experiment. Hypercare then covers the first full month-end close in S/4HANA, which is where chart of accounts, tax and reconciliation gaps surface.

  • Migration Cockpit loads reconciled line by line.
  • Two or more timed mock cutovers before go-live.
  • Hypercare with a formal exit after the first close.
Reconciling migrated balances during an S/4HANA mock cutover
What You Get

Everything the build delivers

📋

Process scope document

The accepted scope items, the approved deviations and the reason recorded behind each decision.

⚙

Configured S/4HANA system

Org structure, Finance, Procurement, Sales, Manufacturing and Supply Chain configuration, tested end to end.

🔄

Migrated and reconciled data

Masters, open items and opening balances loaded and agreed against your legacy numbers.

📱

Fiori roles and launchpad

Business roles, catalogues, spaces and pages per job, with authorisations built alongside them.

🔗

Extension register

Every BTP service and key user extension listed with its API dependencies, ready for upgrade planning.

📚

Handover documentation

Configuration notes, the cutover runbook and role-based user guides, so your team is not dependent on us.