Every workaround is a customization
In short. Before an S/4HANA migration, inventory your workarounds and sort them by shape. Custom screens and added fields sit inside the ERP and get priced in the audit. Spreadsheets and detours around controls never do, yet they carry operating knowledge that the new system will not have. Clean core is the right doctrine: keep the standard standard, and move the business-specific knowledge (product equivalences, customer ordering habits, pricing exceptions) into a layer above the ERP, where it can change weekly and survive the migration.
Nobody approves a workaround. That is the entire point of one.
A workaround appears the moment the distance between what the system requires and what the work requires grows wider than a person's patience. Someone opens a spreadsheet beside the screen. Someone asks a consultant for one more field. Someone quietly stops using the control that was supposed to prevent the problem in the first place.
None of it goes through architecture review. All of it shows up in your migration scope.
If you own the SAP roadmap at a distributor or manufacturer, this is the part of the S/4HANA conversation that rarely makes the business case. You will sign a scope and a budget based on what IT can see. The frontline has been building its own system beside yours for years, and none of it is in that scope. If it isn't accounted for, it doesn't disappear at go-live: it gets rebuilt, outside your governance, the week after.
Three shapes, and only one of them is visible
The spreadsheet beside the screen. Price checks, load calculations, the list of what goes with what. Free to build, absent from every system inventory, and, for some part of your operating knowledge, the only place it exists at all.
The screen someone built for you. At one distributor, the delivery dispatch board is a hand-built matrix inside the ERP, commissioned from an outside consultant years ago. It works. It is also close to impossible to modify or export, and every version upgrade has to account for it. That is a workaround that hardened into an asset nobody wanted to own.
The control everyone routes around. Stock reservations that exist in the system and are not respected by operations: the goods ship anyway. Load weights recorded in the data with no alert when an order passes the limit, so an advisor builds to 98,000 lbs against a 52,000 lb ceiling and starts the whole order over.
The system holds the rule. The floor goes around it. Both facts are true at once, and only one of them is in the documentation.
Why this stops being free
Workarounds have always been cheap, because nobody counted them. That changes on a specific date.
- 31 December 2027: SAP ends mainstream maintenance for ECC, with optional extended maintenance to 2030 (SAP, February 2020).
- About 61% of the roughly 35,000 ECC customers worldwide had not yet licensed S/4HANA at the end of 2024, according to Gartner (The Register, March 2025).
- About 18 months: the average S/4HANA migration reported by ASUG members, with some taking up to six years (ASUG, July 2024).
Run that against a calendar. For most organisations still on ECC, the comfortable window has already closed, and the scoping exercise that starts every migration is the first time anyone counts what the frontline built.
Clean core turns your workarounds into a line item
The doctrine of S/4HANA is clean core: keep the standard standard, push the specific out of the middle. As engineering, it is correct. As a budget event, it means every customization you carry has to be justified, re-platformed, or abandoned.
The audit before a migration is the first time most organisations see their workarounds priced.
And the compiled ones are what get priced: the custom screens, the extra fields, the bolted-on logic. The spreadsheets stay invisible, which is a different problem. They are not in the scope, and they are not in the new system either.
Here is the uncomfortable part. The workarounds exist because the work needed them. Removing them without replacing what they did does not clean the core. It moves the problem back onto the person at the counter (where the order really starts), the same person who invented the workaround in the first place, and who will now invent a new one.
The distinction worth making before the audit
There are two kinds of specific, and they have very different costs.
Specific inside the system of record. Custom fields, modified screens, added logic. Every one becomes a scoped item in your migration, and a regression test in every upgrade after it.
Specific in a layer above it. Changes weekly without touching the core. Survives the migration because it was never inside it. The ERP stays standard: genuinely standard, not aspirationally.
Your product equivalences, your customers' ordering habits, your pricing exceptions, the four questions a junior advisor has to ask before an order is safe to place: none of that belongs in the ERP, and it never did. A system of record is exceptionally good at recording that an order exists. It was never designed to know that this particular customer orders in linear feet, or that this item was superseded last year.
Inventory your workarounds before the migration scopes them
You can do this before any vendor or integrator sizes the project. Pick one workflow, such as order entry. For every workaround you find, note its shape, where it lives, whether the audit will see it, the knowledge it carries and who owns it. Then give it one of three decisions:
- keep it standard and retire the workaround;
- move the knowledge into a layer above the ERP;
- or keep it in the core because it truly belongs there.
That list is the conversation to have with your integrator and your business owners before the scope is frozen. It turns an invisible cost into a line you can defend in the budget, and it gives the business a place for its specifics that isn't the core.
Where Frontleap fits
Frontleap is built to be that layer above the ERP. Frontleap runs alongside SAP without modifying it: the core stays standard for your integrator to migrate and upgrade, and the business-specific rules live where the business can change them. For order entry, that layer is the Order Desk. (Why we build this way.)
Before the migration scopes them for you, it is worth knowing what your frontline has actually built. Every spreadsheet open beside an ERP screen is a specification somebody wrote for free.
Frequently asked questions
Does clean core mean removing every customization?
No. It means keeping the ERP standard and moving business-specific logic out of the core. Some specific belongs in the system of record. Much of it, like product equivalences, customer habits and pricing exceptions, can live in a layer above it, where it changes without touching SAP.
What happens to spreadsheets and workarounds during an S/4HANA migration?
Custom screens and fields are scoped and priced. Spreadsheets and detours around controls are usually not counted at all, so the knowledge they carry is neither migrated nor replaced. Inventory them before the scope is frozen.
How can you keep business-specific logic without customizing SAP?
Put it in a layer that runs alongside the ERP. The ERP stays the system of record. The layer carries the rules, context and exceptions of the work, and survives upgrades because it was never inside the core.
Inventory one workflow before your scope is frozen
Bring one workflow your team runs around the ERP, and your integrator if you like. Together we will: list its workarounds; mark which ones the audit will see; sort what stays in the core, what moves above it, and what can be retired.
Book an inventory sessionAuthors
Read more
Frequently asked questions
What is Frontleap, exactly?
Frontleap is an AI-powered order management platform built for manufacturers and distributors on SAP. It adds an execution layer on top of the ERP to simplify and automate order work. Your ERP stays the system of record; Frontleap is where the work actually happens — order entry, product search, inventory lookup, document access — in an interface built for the people doing it. Nothing is duplicated and nothing is replaced: we hold the last 20% of the ERP, the part your teams currently handle with spreadsheets, email and workarounds.
Do we need to replace or modify our ERP to use Frontleap?
No. Frontleap runs alongside your existing ERP, without modification to your core systems. Your ERP keeps operating exactly as before, and your IT team keeps full control of its configuration and security. We don't rip and replace anything — we sit on top and send clean, validated transactions back into the system of record.
How long does implementation take and what's involved?
Most deployments run one to three months, in three steps: connecting to your existing systems, configuring the workflows your business actually uses, then a pilot with one team before wider rollout. We deploy progressively — one location or department first, expanding once it's proven. No disruption to daily operations.
Is Frontleap secure and compliant?
Yes. Single sign-on with your existing identity provider, role-based access controls, encrypted transmission. We don't store your sensitive business data — we read it in real time from your secured systems. Everything stays inside your existing security perimeter and compliance frameworks.
What can Frontleap handle?
Order entry and modifications, product search and inventory lookup, quote generation, returns and credits, customer account management, access to specs and pricing documents, multi-location stock visibility. In practice: anything where someone has to jump between screens or systems to get one job done.
Why not just improve our current ERP?
Because the problem isn't your ERP — it's the distance between it and the people using it. ERP projects deliver the system of record; they rarely deliver adoption at the counter. Frontleap runs independently of your ERP version, so it doesn't break with upgrades, and your teams are productive in a fraction of the usual ramp-up.
Does Frontleap work on mobile and in-store devices?
Yes, any device with a browser. Desktop, tablet, phone. The interface adapts to the screen, and works with the hardware already on your floor, like scanners and receipt printers. Your teams can look up stock, build orders and process transactions from anywhere in the building.
What is AI-assisted order entry for SAP?
AI-assisted order entry uses AI to interpret an incoming customer request, map it to the products and information stored in SAP, identify missing or uncertain information, and prepare the sales order before a representative approves it. With Frontleap, the AI works alongside the existing ERP rather than replacing it. SAP remains the system of record, while Frontleap handles the operational work required to turn an unstructured customer request into a clean, validated transaction.
How does Frontleap turn an email or PDF into an SAP order?
Frontleap reads the customer request from an email, PDF or information captured during a call and identifies the products, quantities and other order details it can determine. It then resolves those details against your catalogue and relevant ERP context, including stock, pricing, customer information and previous orders. Instead of guessing when information is unclear or missing, Frontleap surfaces the exception to the representative. The rep reviews the prepared order and approves the clean transaction before it reaches SAP.
Can Frontleap understand customer product names that do not match SAP material numbers?
Yes. Frontleap is designed for the gap between how customers describe products and how those products are represented in the ERP. A customer may use an abbreviation, an old part number, a local nickname or a description such as “the usual 12 inch.” Frontleap uses catalogue information and operational context to resolve that language to the appropriate product. When there is not enough information to make a reliable match, it asks the representative rather than silently selecting a material.
What does Frontleap validate before an order reaches SAP?
Frontleap can use the information surrounding the transaction — including catalogue data, inventory, pricing, customer account information, previous orders and business context — to prepare the order before it reaches SAP. The objective is not simply to extract fields from a document. It is to determine whether the order is ready to process and identify what still requires a human decision. Missing information, uncertain matches, pricing questions and other exceptions remain visible to the representative for review.
Does Frontleap create SAP orders automatically, or does a representative approve them?
Frontleap is designed around human approval where a business decision is required. The AI prepares the order, resolves what it can from your systems and operational knowledge, and isolates the exceptions that genuinely need attention. The representative can then review, correct and approve the result before the validated transaction is sent to SAP. This allows teams to automate repetitive order preparation without asking an AI system to make business decisions that should remain with the people operating the desk.
Does Frontleap replace SAP or require changes to our ERP?
No. Frontleap runs alongside SAP rather than replacing it. SAP remains the system of record for the transaction, while Frontleap provides an execution layer where frontline teams can prepare orders and make operational decisions. This separation means the order desk can get a simpler, task-oriented workspace without turning the initiative into another ERP replacement project. Frontleap connects to the existing enterprise environment and sends validated transactions back to the system of record.
How long does it take to implement Frontleap Order Desk?
A typical Frontleap deployment runs approximately one to three months. The process starts by connecting the relevant enterprise systems and modelling the workflows, terminology and rules used by the order desk. Frontleap can then be introduced with one team, location or workflow before expanding more broadly. The objective is to prove the workflow against the customer’s own operating baseline rather than require a large transformation program before the order desk can start using the product.
Does clean core mean removing every customization?
No. It means keeping the ERP standard and moving business-specific logic out of the core. Some specific belongs in the system of record. Much of it, like product equivalences, customer habits and pricing exceptions, can live in a layer above it, where it changes without touching SAP.
What happens to spreadsheets and workarounds during an S/4HANA migration?
Custom screens and fields are scoped and priced. Spreadsheets and detours around controls are usually not counted at all, so the knowledge they carry is neither migrated nor replaced. Inventory them before the scope is frozen.
How can you keep business-specific logic without customizing SAP?
Put it in a layer that runs alongside the ERP. The ERP stays the system of record. The layer carries the rules, context and exceptions of the work, and survives upgrades because it was never inside the core.
Why do counter staff ignore the memos and pop-ups in the ERP?
Usually not because the information is wrong, but because it is delivered in a way that blocks the sale in progress. Staff learn to dismiss it to keep serving the customer. The fix is to deliver the same information without interrupting the action, so both administration and sales get what they need.
What is the difference between training staff on the ERP and making them autonomous?
Training teaches the screens. Autonomy comes from having the answer at the moment of the sale: which product the customer means, which branch has it, what to do when the standard path doesn't fit. A workspace that follows the real sequence of the counter, and shows those answers in the flow, lets new hires serve the customer without calling a senior colleague.
Can you improve counter work without customizing SAP?
Yes. The specific way your counter works can live in a layer above the ERP instead of inside it. SAP stays the system of record, and the workspace carries the sequence, the context and the shortcuts your people need (why that matters before a migration).
How do you reduce the order desk’s dependence on a few senior people?
Capture what they know while the work happens, not in a manual. Follow them through one real workflow and note every time they leave the system. Record each rule they apply with its source, scope and owner. The knowledge then stays with the business when people move on, and new hires can draw on it from day one.
How do you keep order knowledge current when catalogues, prices and teams change?
Give every rule an owner. When someone corrects an order, the owner decides whether the correction becomes shared knowledge, where it applies, and which old instruction it retires. A correction on one order should never silently change every future order.
What should an AI agent handle alone, and what should stay with a person?
An agent can act where an approved rule fully determines the next step. Judgment, negotiation and commitments beyond its authority go to the right person, with the context attached. Write down what proceeds, what pauses and what allows the work to resume before anything is delegated.
Does clean core mean removing every customization?
No. It means keeping the ERP standard and moving business-specific logic out of the core. Some specific belongs in the system of record. Much of it, like product equivalences, customer habits and pricing exceptions, can live in a layer above it, where it changes without touching SAP.
What happens to spreadsheets and workarounds during an S/4HANA migration?
Custom screens and fields are scoped and priced. Spreadsheets and detours around controls are usually not counted at all, so the knowledge they carry is neither migrated nor replaced. Inventory them before the scope is frozen.
How can you keep business-specific logic without customizing SAP?
Put it in a layer that runs alongside the ERP. The ERP stays the system of record. The layer carries the rules, context and exceptions of the work, and survives upgrades because it was never inside the core.
Why do counter staff ignore the memos and pop-ups in the ERP?
Usually not because the information is wrong, but because it is delivered in a way that blocks the sale in progress. Staff learn to dismiss it to keep serving the customer. The fix is to deliver the same information without interrupting the action, so both administration and sales get what they need.
What is the difference between training staff on the ERP and making them autonomous?
Training teaches the screens. Autonomy comes from having the answer at the moment of the sale: which product the customer means, which branch has it, what to do when the standard path doesn't fit. A workspace that follows the real sequence of the counter, and shows those answers in the flow, lets new hires serve the customer without calling a senior colleague.
Can you improve counter work without customizing SAP?
Yes. The specific way your counter works can live in a layer above the ERP instead of inside it. SAP stays the system of record, and the workspace carries the sequence, the context and the shortcuts your people need (why that matters before a migration).
How do you reduce the order desk’s dependence on a few senior people?
Capture what they know while the work happens, not in a manual. Follow them through one real workflow and note every time they leave the system. Record each rule they apply with its source, scope and owner. The knowledge then stays with the business when people move on, and new hires can draw on it from day one.
How do you keep order knowledge current when catalogues, prices and teams change?
Give every rule an owner. When someone corrects an order, the owner decides whether the correction becomes shared knowledge, where it applies, and which old instruction it retires. A correction on one order should never silently change every future order.
What should an AI agent handle alone, and what should stay with a person?
An agent can act where an approved rule fully determines the next step. Judgment, negotiation and commitments beyond its authority go to the right person, with the context attached. Write down what proceeds, what pauses and what allows the work to resume before anything is delegated.
What is AI order entry for SAP?
AI order entry for SAP uses artificial intelligence to interpret customer requests, match them to catalogue items and prepare sales orders using relevant business information, such as pricing, inventory, customer records and order history. SAP remains the system of record.
Does AI order entry replace the customer service representative?
No. AI-assisted preparation can identify a likely product, bring pricing and customer information into view, surface a shortage and prepare the order for review. The representative resolves ambiguity, agrees on delivery or substitutions, and confirms that the order reflects the customer’s agreement. Commercial exceptions go to someone with that authority.
How is Frontleap different from SAP’s Order Management Assistant?
SAP describes its Order Management Assistant as orchestrating Joule Agents or custom agents for order fulfilment risks, sourcing optimization and revenue reconciliation. Frontleap Order Desk focuses on complex order preparation: a CSR workspace that brings the customer request, product match, stock, price and approval together. The functions overlap in part, so the practical test is how each handles your team’s terminology, customer rules and exceptions.
How should you evaluate an AI order entry solution?
Test it with orders that made your experienced people pause: an old product number, an unclear unit of measure, an expired quote or a request that conflicts with available stock. Check that the representative can see the evidence behind a match, identify missing information, correct the proposal, involve the right authority and verify the final order. Measure preparation time, corrections, unresolved questions and errors found after entry.