Sourcing in Step with Development

Unlike traditional sourcing tools, the Direct Material Sourcing for Discrete Manufacturing solution—integrated into S/4 HANA—supports the procurement of direct materials throughout the development phases of a component, from early design through the production contract.

Direct materials follow a different logic than indirect procurement. What goes into a vehicle isn't decided at the negotiating table, but rather during the design process: A component is designed, built as a prototype, validated, and sampled—and only then procured for mass production.

Costs and feasibility are directly tied to design decisions, and any change to the bill of materials affects procurement as well. Sourcing is not a downstream activity here, but rather runs parallel to product development, spanning program milestones, with changing specifications and close coordination between purchasing, engineering, and suppliers.

Limitations of Traditional Sourcing

That is precisely what a traditional sourcing tool fails to capture. It takes into account the request for proposals, but not the development cycle behind it. For an automotive supplier whose value creation depends on technical complexity and long product life cycles, this is no minor issue:

A single part that isn't procured on time can jeopardize the start of mass production. It's worth clarifying a point here that repeatedly causes confusion in the SAP community. The term „Direct Material Sourcing“ appears in two contexts, and they do not mean the same thing.

First, there is the product sourcing functionality within the SAP Ariba Strategic Sourcing Suite. It provides broad coverage of strategic sourcing and is best suited for environments where the process primarily runs through the cloud suite. On the other hand, there is SAP Direct Material Sourcing for Discrete Manufacturing: a standalone application anchored in SAP S/4HANA, built specifically for the manufacturing reality at hand. Both have similar names, but they occupy different places in the landscape and perform different tasks.

The Material Master Requires the ERP Core

For a supplier with deep manufacturing integration, this distinction isn’t just semantics—it sets the course for the project. Anyone who wants to procure direct materials in line with the bill of materials, the plant structure, and the development cycle needs close integration with the core ERP system, where the material master, production planning, and cost calculation are already housed. It is precisely this integration that led Multimatic to choose the S/4-based solution. The core of the approach is integration. Because the application is anchored in SAP S/4 HANA, it has direct access to the very elements that make the procurement of direct materials manageable: the material master, bill of materials, production planning, and cost calculation are tightly integrated—not outsourced to a loosely connected neighboring system. At Multimatic, the solution is operated in the Private Edition, which provides the necessary flexibility for customization and deep integration into the existing system landscape—something a pure public-cloud approach does not offer in this form.

The practical difference becomes apparent in collaboration. Sourcing, supplier collaboration, and contract management are integrated into a single, end-to-end process, and engineering, quality, and sustainability operate within that same process rather than around it. The solution also allows drawings and specifications to be co-edited throughout the sourcing process via integrations with product development, rather than sending them back and forth via email and spreadsheets.

Every island is an interface

Standalone solutions can handle individual steps well when considered in isolation. However, every additional connected “island” creates a new interface and a new point where data can be lost. The value of an integrated solution lies in avoiding precisely these “seams” where cost and time pressures are already greatest.

Rollouts Are Never Smooth Sailing

No rollout of this kind goes off without a hitch, and this one was no exception. The reason lies in the nature of off-the-shelf software: It is tested based on assumptions, but end users work differently. It is precisely at this interface that gaps come to light during live operation—gaps that no one sees in advance. The project team took on a dual role here. It relayed the requirements identified in practice directly to SAP and pushed for corrections that could be resolved at the product level; for anything SAP could not resolve in time, it devised workarounds and adapted the business processes to keep the project on schedule.

Specifically, this was evident in a number of requirements arising from day-to-day operations: the visibility of quotes created on behalf of suppliers; the handling of currencies with five decimal places; the validity of pricing terms; and the notification of suppliers regarding negotiation details.

Cherry Picking for Everyone

SAP has implemented four of these points; another—negotiation in the supplier’s currency—is planned for a future release. One feature stands out—referred to as „Cherry Picking“ in the project—which allows users to assign individual line items in a sourcing transaction with multiple line items to specific suppliers, for example, based on quantity. Leading OEMs had also requested this feature; SAP subsequently included it in a standard release. What began as a specific request from one customer is now available to the entire user base.

Where the standard fell short, customized solutions were developed—such as a structured cost breakdown template to serve as the basis for comparable cost breakdowns. In this way, a supplier’s practical experience was incorporated back into the product. Several requirements were incorporated into the standard, from which future users will benefit.

Understanding the Process as an Obstacle

Perhaps the most important insight from the project is not a technical one. Shortly before go-live, it became clear that the biggest hurdle lay not in the tool itself, but in understanding the process—specifically, in how differently teams and locations handle the same workflow. Software can only execute a process as well as it has been understood, standardized, and embraced beforehand.

This is precisely where a significant portion of the work lay. Cost structures and supplier data had to be standardized so that comparisons on an equal footing would even be possible—for example, through harmonized standards for cost breakdown. Responsibilities for the end-to-end process had to be clearly assigned, long-standing practices had to be reevaluated, and the process had to be transformed into a robust, cross-site workflow. This is less a matter of configuration than of alignment. Anyone implementing a system of this scope is also introducing a new way of working, and this aspect plays a key role in determining whether the technical effort will ultimately pay off.

A tool that's not for everyone

As powerful as the solution is, it isn’t right for everyone. It is designed for direct materials, not for indirect materials or service procurement, and it only realizes its full value where scale and complexity justify it: at OEMs and other manufacturers of complex, engineering-intensive products, with deep bills of materials, close coordination between engineering and procurement, and a supplier network that supports such processes. For a smaller supplier with a manageable range of parts, it would be overkill. This assessment is part of any sound decision-making process: Not every company needs this tool, but those that do need exactly this one.

Where applicable, the benchmarks collected by SAP from early adopters show what’s possible: up to 40 percent shorter sourcing cycles, a 15 percent faster time-to-market for new products, and a reduction in direct material costs of between two and five percent. These are benchmarks, not Multimatic’s actual results. The supplier has just gone live; reliable performance metrics of its own will emerge over time following the go-live, not the day after.

Predictive Scenarios

The go-live lays the foundation—it is not the end of the process. The real impact only becomes apparent during operations, when seamlessly integrated processes generate robust data, sourcing decisions are based on reliable cost and supplier analyses, and a reactive procurement approach gradually evolves into a data-driven one.

Predictive scenarios and automated recommendations mark the horizon; the path to getting there is measured in months. Above all, this project leaves behind a solid foundation: a solution that is embedded deep enough in the system to grow with it, and a process that takes real-world practice so seriously that it reflects it back into the product.

To the partner entry: