Why Direct Materials Teams Struggle to Accept Software Change Costs

In direct materials, cost change is a familiar conversation.

A drawing changes.
A new feature is added.
A tool needs modification.
A supplier needs to validate the part again.
A production process needs to be adjusted.

Everyone understands what follows. The buyer gets involved. The quality team reviews the part and process. The supplier explains the cost impact. The tooling investment is calculated. The additional cost is negotiated, approved, and amortized into the part cost.

There is a clear anchor for the cost increase: the drawing changed.

That one fact makes the entire conversation easier.

But when the same logic moves into software, direct materials teams suddenly become uncomfortable.

The difference is not just cost. The difference is who initiates the change.

In the case of a part, the change is usually initiated by an agency outside procurement.

It may come from engineering.
It may come from product development.
It may come from customer requirements.
It may come from quality, regulatory, or manufacturing needs.

Procurement is not expected to originate the business justification. Procurement is expected to enable the change, validate the cost impact, negotiate with the supplier, and ensure commercial control.

This is a role procurement understands very well.

But in the case of software, the change often originates from within the procurement or supply chain function itself.

The team realizes that a workflow is missing.
A report is needed.
An approval logic has to change.
A supplier collaboration process has to be reworked.
A new data field is required.
An exception has to be handled better.
A manual Excel process has to be formalized inside the platform.

Now the burden is different.

Procurement is no longer just enabling someone else’s requirement. Procurement has to stand up and justify its own requirement.

And this is where the discomfort begins.

Procurement was trained to be an enabler, not an owner

For decades, direct materials procurement has been seen largely as an enabling function.

Engineering defines the product.
Manufacturing defines the production need.
Quality defines the validation requirement.
Finance controls the approval.
Management owns the business case.

Procurement supports all of them.

This history shapes the mindset of the function. Direct materials teams are excellent at executing complex commercial processes. They can negotiate, follow up, coordinate, firefight, and somehow keep the line running despite enormous complexity.

But they have not always been trained to say:

“This is our process.”
“This is our system requirement.”
“This is the capability gap.”
“This is the business value.”
“This is why we need this investment.”
“This is why the software cost increase is justified.”

So when a software change request appears, they often lack the internal language, confidence, and organizational backing to defend it.

Not because the requirement is weak.

But because they are not used to owning the requirement.

In direct materials, the drawing justifies the cost. In software, the operating model has to justify the cost.

When a direct material part changes, the organization can see the reason for the cost increase.

There is a drawing.
There is a part.
There is a tool.
There is a production requirement.
There is a validation process.

The buyer can point to something and say, “This changed, therefore the cost changed.”

Software is different.

A company signs up for a platform. During implementation, users begin to discover that certain process changes are required. They may want a new workflow, a new approval logic, a different report, a specific integration, a new data field, or a change in the way the system handles a business scenario.

The software vendor then raises a change request.

And suddenly the response is very different.

“Why is this extra?”
“Was this not part of the original scope?”
“Can’t this be included?”
“How do we justify this against the already approved PO?”
“Shouldn’t the vendor absorb this?”
“Will the vendor reuse this for other customers?”

The irony is that the same organization that comfortably understands engineering change costs often struggles to accept software change costs.

The change request exposes a deeper organizational gap

Many software change requests are not merely vendor-driven commercial events. They reveal something more fundamental: the organization is discovering its own process maturity gaps.

Before digitalization, many direct materials processes run through Excel, email, calls, manual follow-ups, and tribal knowledge. These processes work because experienced people hold the system together.

But once a platform is implemented, hidden process gaps become visible.

Who should approve this?
Which data field is mandatory?
What happens when the supplier misses a step?
How is the cost impact calculated?
Which team owns this exception?
Should this be a workflow, a report, or a control?

These questions were always present. The organization simply handled them manually.

Software forces the organization to define them clearly.

That definition creates effort. And effort creates cost.

This is why digitalization creates friction and frustration

The customer’s concern is real.

They worry about scope creep.
They worry about cost escalation.
They worry that every new requirement will become a paid change.
They worry that management will ask why the original approval was not enough.
They worry that dependence on the platform may eventually make them commercially vulnerable.

But the vendor’s position is also real.

A change needs discovery, design, development, testing, deployment, training, and support. It must fit into the platform without breaking other flows. It may require changes to data models, integrations, workflows, permissions, reports, and user experience.

This is not very different from a supplier modifying a tool or process to meet a new drawing requirement.

The only difference is that the output is digital.

And because the output is digital, direct materials teams struggle to defend the cost with the same confidence.

The changes cannot be directly amortized over other customers that the vendor may or may not have and certainly does not help the vendor in the short-medium time. If anything, the changes to the software need to be amortized over every transaction. Does the agreed commercial model allow that?

That is where friction begins.
That is where frustration builds.
That is where digitalization slows down.

The real problem is lack of ownership language

The answer is not that vendors should absorb every change.

The answer is also not that customers should blindly approve every change request.

The answer is that direct materials teams need a stronger ownership language for digitalization.

They need to be able to explain:

What process gap is being solved?
What manual effort is being eliminated?
What control is being introduced?
What risk is being reduced?
What cost leakage is being prevented?
What cycle time is being improved?
What decision quality is being strengthened?
What future capability is being enabled?

Without this language, every software change request looks like extra cost.

With this language, the same change request becomes a capability investment.

Direct materials teams need to move from enabling change to owning capability

Software is no longer a support tool for direct materials. It is becoming the operating layer for sourcing, costing, supplier collaboration, quality, schedules, tooling, contracts, and cost governance.

As the scope increases, the platform becomes more deeply connected to the business.

That means software cost cannot be evaluated like a one-time license purchase. It has to be evaluated like a long-term capability investment.

A good platform will evolve with the customer’s maturity.
A strong implementation will reveal process gaps.
A serious transformation will require change.
And some of those changes will need investment.

The key question is not, “Why is there a change request?”

The better question is, “Does this change improve control, speed, governance, visibility, accuracy, or business outcome enough to justify the investment?”

That is the conversation direct materials teams already know how to have for parts and tooling.

They now need to have the same conversation for software.

Bottomline

Direct materials teams are very mature in handling cost changes when the change is tied to a physical product.

But they often struggle when the change is tied to a digital process.

In the physical world, the change is often initiated outside procurement, and the drawing justifies the cost.

In the software world, the change is often initiated from within procurement, and the operating model has to justify the cost.

That shift is uncomfortable because direct materials teams have historically been seen as enablers, not owners.

But digitalization changes that.

If direct materials wants better systems, better controls, better data, better supplier collaboration, and better AI readiness, the function has to step forward and own its digital requirements.

Because the future of direct materials will not be managed only through drawings, parts, and tools.

It will also be managed through data, workflows, integrations, controls, and systems of record.

And those need investment too.