This decision is now in front of most supply chain teams running SAP SNC, because SAP has retired it. SAP designated Ariba Supply Chain Collaboration on SAP Business Network as the go-forward solution for supplier collaboration and stopped investing in SNC. For most companies the decision now sits alongside an S/4HANA program and the 2027 maintenance deadline for SAP Business Suite 7.
[VERIFY: confirm the exact current maintenance end date for SNC with SAP and cite it here. Dates have shifted before, and “retire” should be replaced with SAP’s own wording so the claim is precise.]
There is no comfortable version of this project. SNC sits in the middle of daily execution. Purchase orders, confirmations, ship notices, supplier-managed inventory and subcontracting all run through it, and every one of those touches suppliers who have their own systems, their own priorities and no obligation to move on your schedule. Replacing it means changing how hundreds of external companies work with you, retraining internal teams who have used the same screens for a decade, rebuilding integration into SAP, and cutting over without losing visibility of open orders.
It is a large program. It is disruptive. And it has to be done, because staying on a product that is no longer being invested in is a slower version of the same disruption, with the timing chosen for you.
What makes it harder is that almost nobody gets to do it on its own. It lands in the same window as the S/4HANA conversion, and usually alongside whatever else is already committed for the year: a plant or region going live, a planning system replacement, a data cleanup ahead of migration, an integration platform move, a security or compliance program. The same handful of people are in all of it. The supply chain lead who knows how confirmations actually work, the SAP MM functional lead, the integration architect, the master data owner. There are only so many of them, and every track wants their calendar.
The result is predictable. Supplier collaboration becomes a workstream on someone else’s plan, scoped to whatever fits in the remaining capacity, decided in a meeting convened for a different purpose, and reviewed by people who have four other decisions that week. Nobody intends to under-think it. There simply isn’t room.
Two things follow from that, and they point in opposite directions, which is why this is worth deliberate attention rather than default handling.
The first is that implementation effort matters more than it normally would. A replacement that needs a new integration platform, an ERP add-on installed and transported into a system already being converted, and a supplier enablement program running in parallel is competing for exactly the scarce people the S/4HANA program needs. The question is not only what the platform does. It is what it will cost the team during the months you can least afford it, and whether it can be sequenced after the conversion rather than into it.
The second is that you are going to absorb the cost of change once regardless. Suppliers will be retrained, integration will be rebuilt, teams will learn new screens. That happens whichever path you take. It makes the choice of destination worth real time, rather than defaulting to the option that looks smallest on a slide. The most common failure here is not picking the wrong platform. It is scoping the project as a like-for-like swap because that is what fits in the available capacity, and rebuilding a decade-old design under a new logo — then discovering two years later that everything the transaction set could not carry still needs a second project.
Direct materials supplier collaboration is one of the few areas where the requirements have genuinely changed since SNC was implemented. A forced replacement is a rare opportunity to act on that. Before choosing, it is worth being precise about what changed.
What changed since SNC was implemented
Traditional supplier collaboration was built around the exchange of structured messages: purchase orders, confirmations, ship notices, forecasts. EDI, RosettaNet, IDocs. That model works when the business follows the expected sequence and both sides agree on what was requested, proposed and promised.
Increasingly, that is not where the work is. A growing share of direct materials collaboration is about managing deviation from what was agreed. A supplier cannot meet a requested date. A component becomes constrained. Demand moves. A product change notice affects an open customer order. Inventory at a subcontractor does not match the system. A quality issue threatens a build.
These events break the transaction sequence. The transaction stays in SAP and the messages keep flowing, but the actual work moves to email, spreadsheets, calls and meetings. Any replacement that only reproduces the message exchange will reproduce that outcome.
The second change is scope. The supplier relationship does not begin when a purchase order is issued and end when material is received. For direct materials it starts with specification, qualification and production readiness, runs through planning, purchase orders, VMI, subcontracting and fulfillment, and continues into quality, performance, cost and continuous improvement. Most of that surface has no transaction to attach to.
With that in mind, there are three realistic replacement paths.
Path 1: Rebuild the transaction layer
Replace SNC with EDI, middleware and a supplier portal for the suppliers who cannot integrate. IT owns the whole thing.
Where this works. If your SNC footprint is narrow — purchase orders, confirmations and ship notices with a supply base that is already largely EDI-enabled — this is a legitimate answer, and often the cheapest one. Existing trading partner relationships and maps carry forward. There is no new supplier onboarding motion, no new commercial model, and no third party in the middle of your supplier relationships. Your integration team already knows how to run it.
Where it runs out. You have rebuilt the message layer and inherited its limits. Changes, exceptions and negotiations still leave the system. Nothing extends past the transaction set, so engineering, qualification, quality and cost collaboration stay in email. And you now build and maintain integration you previously bought, including the portal for the long tail of suppliers who will never do EDI.
The honest test. If you can list every SNC scenario you actually use on one hand, and none of them involve people outside procurement and planning, this path deserves serious consideration.
Path 2: Move to a supplier network
Ariba Supply Chain Collaboration on SAP Business Network, or a comparable network platform.
Where this works. This is SAP’s designated successor, which makes it the lowest-political-risk choice inside an SAP shop, and often the one your systems integrator already staffs. The network is enormous, and a meaningful share of your supply base may already hold accounts. SAP publishes a figure of 50-80% of suppliers already transacting on the network, and will run a supplier match against your supply base on request. Integration content is standardized and SAP-maintained. Multi-tier collaboration and logistics reach are real capabilities, and the platform is under active investment.
Where it runs out. Three things are worth scoping carefully.
Commercial model. Cost scales with transactions and spend on both sides. Buyer subscriptions vary with transaction volume, modules and scale of usage. On the supplier side, standard accounts are free with unlimited documents, but a supplier crossing five documents and $50,000 in qualifying spend with a single buyer in a rolling twelve months becomes chargeable — and once chargeable, chargeable across all their buyer relationships. Transaction fees run a percentage of transaction value, capped per buyer relationship per year. For direct materials, effectively every strategic supplier crosses that threshold in the first month. Suppliers price those fees back into unit cost.
Scope boundary. A network works by standardizing document types across every buyer and supplier on the platform. That is the source of its value and also its limit. Adjacent needs sit in separate SAP products — sourcing events in Ariba Sourcing, supplier onboarding and risk in Ariba SLP and Supplier Risk — each with its own subscription, configuration and supplier-facing experience.
Deployment weight. Integration runs through SAP Integration Suite, managed gateway for spend management and SAP Business Network, formerly Cloud Integration Gateway, delivered on BTP. SAP’s own guidance is to use the ERP add-on rather than the API-based scope item for SAP Business Network for Supply Chain. That means a BTP tenant, an add-on installed and transported into your ECC or S/4HANA system, a mapping layer to maintain, and per-relationship supplier enablement. Some customers add PI/PO or other middleware on top, which lengthens the chain further.
This is the recommended path if your direct materials collaboration genuinely is purchase orders, confirmations, ship notices, invoices and supplier-managed inventory, and your suppliers are already on the network.
Path 3: A collaboration and orchestration layer over SAP
Keep SAP as the transactional system of record. Put a collaboration environment over it that you own, covering the full direct materials relationship rather than a fixed document set.
The argument for it comes from scope. Consider what actually gets exchanged with a strategic component supplier or contract manufacturer over the life of a part: specifications and drawings, design for manufacturability feedback, first article inspection, test and validation results, PPAP submissions, deviation and waiver requests, engineering change impact, component qualification and alternate part evaluation, cost breakdowns and purchase price variance, excess and obsolete inventory, supplier scorecards and improvement actions, compliance declarations.
Almost none of that is a standard document type on any network, and much of it never will be, because the content is specific to your products, your quality system and your industry. What one company means by a component qualification package is not what the next one means.
The participants do not standardize either. A network connects buyers to supplier sales and customer service around transactions. The people who resolve a constrained component or a failed first article are component engineers, test and quality engineers, planners, program managers and sourcing, on both sides. A two-party transaction channel is not built to bring them in.
And direct materials collaboration carries IP. Drawings, tolerances, test data, PPAP packages, DFM feedback, BOM structure and cost breakdowns are governed by agreements between your two companies. On a shared network, your supplier’s account is administered by your supplier and used across their other customers, some of whom are your competitors. That may be fine for a purchase order. It is a different conversation for a qualification package.
Direct materials relationships are also not discovered on a network. You qualify an ASIC supplier or a contract manufacturer over months, under contract, with tooling and audits. The relationship is company to company. There is little network effect to capture.
Where it runs out. Be clear about the trade-offs. There is no cross-buyer network effect — your suppliers use your environment for you specifically, not a shared account across their customer base. You are adopting a platform from a vendor other than SAP, which is a different procurement and risk conversation. And you configure processes to your business rather than receiving them pre-built, which is an advantage over time and a workload at the start.
Comparing the three
| Rebuild transaction layer | Supplier network | Orchestration layer | |
|---|---|---|---|
| Scope covered | Message set you build | Defined document types | Full direct materials relationship |
| Cross-functional teams | No | Limited | Yes |
| Integration architecture | Your middleware to SAP | Network → gateway on BTP → ERP add-on → SAP | Direct to SAP |
| Pricing basis | Build and run cost | Transactions and spend, both sides | [Insert your model] |
| Supplier cost | None | Fees above threshold | [Insert] |
| Tenancy and data | Yours | Multi-tenant | [Insert: single tenant, deployment options] |
| Time to first supplier live | Build-dependent | Program-dependent | [Insert with scope] |
| Extending to new processes | Development | Vendor roadmap or another product | Configuration |
Choosing
Choose the transaction layer rebuild if your SNC scope is narrow, your supply base is EDI-capable, collaboration outside procurement and planning is not a problem you are trying to solve, and you have integration capacity to run it long term.
Choose a network if your requirements sit inside standard document types, a large share of your suppliers already transact on the network, multi-tier or logistics collaboration matters to you, and predictable alignment with SAP’s roadmap outweighs the commercial model.
Choose an orchestration layer if the work that consumes your team is engineering, qualification, quality, cost and exception handling rather than clean transactions; if you need cross-functional teams and suppliers in the same place; if IP-bearing content is part of the collaboration; or if you expect new supplier collaboration requirements that you want to configure rather than request.
These are not mutually exclusive. It is common to keep EDI with high-volume suppliers, keep network invoicing where it already works, and put an orchestration layer over the top for everything the transaction set cannot carry.
Questions worth asking before you commit, whichever path you take:
- Of the suppliers on a network match list, how many transact order confirmations and ship notices against direct materials POs today, versus holding an account for invoicing?
- When a supplier proposes a delivery split, who decides, and what do they look at before deciding?
- What share of PO exception handling runs through email today, and where would it run afterward?
- Where do engineering change, deviation, PPAP and quality collaboration live, and does the replacement move them or leave them?
- What is the total three-year cost including platform, BTP or middleware, ERP add-on effort, implementation, supplier enablement, and supplier fees priced back into unit cost?
Where ZFlow fits
ZFlow is the third path. It provides a collaboration and orchestration layer over SAP ECC or S/4HANA, with the supplier portal owned by you: your suppliers, your users, your data, your access rules, single tenant, unlimited suppliers, and no per-document or per-transaction-value metering.
Coverage spans purchase order collaboration, VMI, subcontracting, ASN and receipt, invoice, alongside supplier development, PPAP, supplier quality, performance assessment and cost variance — the surface a document set cannot represent. Integration writes directly to SAP, so an accepted supplier proposal lands in the purchase order schedule lines and confirmations rather than traveling through a network and a gateway to get there.
Implementations are phased. Start with the scenarios that matter most, typically PO collaboration, and add VMI, subcontracting, quality and engineering as your teams and suppliers are ready.
[INSERT: one-line proof point with a customer, scope and outcome. Link to the high-tech case study.]
[CTA: Free Pilot / Test Drive links.]