Lessons from the Field: What 3D Printing Taught Us About Implementing Software

Before flipside existed, one of our founders spent years at Materialise, the Belgian company that's been building 3D printers, printing software, and additive manufacturing solutions since 1990. Headquartered in Leuven, now publicly traded, with operations spanning medical, industrial, and consumer applications.

Not a startup. A company that grew from a rapid prototyping bureau into a global operation with hundreds of employees across multiple segments: medical devices, manufacturing software, and production services.

Leading innovation projects there didn't just teach technology. It taught how businesses actually change. And how most of them don't.

The Gap Between What Software Promises and What the Floor Needs

In additive manufacturing, there's a recurring tension. The software team builds a feature. It works perfectly in the demo. Then it hits the production floor, and nobody uses it the way it was designed.

Not because the feature is wrong. Because the workflow it was built for doesn't match the workflow that actually exists.

A build preparation tool assumes operators follow a five-step process. Operators follow seven steps, three of which are undocumented workarounds they've developed over years. The software doesn't account for those steps. So the operators do what operators always do: they work around the software.

This pattern repeats in every industry. The gap between what a system is designed for and how work actually gets done, that gap is where implementations fail.

At Materialise, bridging that gap was part of the job. You couldn't ship a manufacturing automation tool without spending time on the floor with the people who'd use it. Watching. Asking questions. Understanding why they do things the way they do before suggesting they do it differently.

That principle didn't stay at Materialise. It came with us.

Innovation Is a Process Problem

Here's what people get wrong about innovation in manufacturing.

They think it's about the technology. Better printers. Smarter software. More capable materials. And those things matter, but they're not where innovation stalls.

Innovation stalls in the processes around the technology. In how orders get scheduled. In how data flows from design to production. In how quality gets tracked, how exceptions get handled, how information moves between departments.

At Materialise, the company produces everything from medical implants to aerospace components. Each product type has different regulatory requirements, different quality standards, different lead times. The complexity isn't in the printing. It's in the orchestration.

Managing that complexity taught a specific lesson: you can't automate a process you don't understand. And you can't understand a process by reading a flowchart. You have to walk through it with the people who do it every day.

As Materialise's VP of Software once put it: "Industrializing additive manufacturing isn't a software problem or a hardware problem. It's a manufacturing problem."

Replace "additive manufacturing" with "your business" and the statement holds.

What Manufacturing Discipline Teaches About ERP

Manufacturing companies are forced to be disciplined about process. If a step is missing in production, you get a defective part. The feedback is immediate and concrete.

In an office environment, the feedback is slower. A bad process in sales or purchasing doesn't produce a visible defect. It produces a spreadsheet nobody trusts, or an order that takes three days instead of thirty minutes, or a month-end close that requires a week of reconciliation.

But the root cause is the same: the process wasn't designed for the load it's carrying.

Working in manufacturing builds a specific instinct: look at how work actually moves through the system before deciding what to change. Not the org chart. Not the job descriptions. The actual movement of information and decisions from start to finish.

That instinct translates directly to ERP implementation.

When we sit down with a client's operations team, we're not asking "what software do you need?" We're asking "walk us through a day in the life of an order." From the moment a customer inquiry comes in to the moment the invoice gets paid, what happens? Where does it slow down? Where do people have to make up for what the system doesn't do?

That's a method learned on a production floor. It works just as well in an office.

The Difference Between Fitting the Tool and Fitting the Work

At Materialise, there was constant pressure to adopt the latest tools. New software versions, new automation platforms, new data management systems. The temptation was always to deploy the capability first and figure out the workflow later.

The projects that failed, and some did, almost always failed because of that sequence. Capability first, workflow second.

The projects that succeeded inverted it. They started with the constraint. What's actually slowing us down? What step takes the longest? Where does quality suffer? Then they selected or built the tool to address that specific bottleneck.

This is exactly how we approach Odoo implementations. We don't start with the module list. We start with the pain. The 20% of processes that deliver 80% of the operational friction, those get fixed first, with the right tool configured the right way for how the work actually happens.

Everything else is a phase two conversation.

What a Belgian 3D Printing Company Taught Us About SMEs

Materialise started as a two-person company in 1990. It grew organically, added complexity incrementally, and faced every scaling challenge that our clients face today, just with 3D printers instead of inventory management.

The lessons translate directly:

Processes designed for ten people don't survive fifty. What works when everyone can walk over to ask a question breaks when there are three shifts and two locations.

Tribal knowledge is a liability. When the person who knows how the system works goes on holiday, the system stops working. That's true for a 3D printer operator. It's true for your head of purchasing.

Software is only as good as the process underneath it. A bad process in a good system produces bad results faster.

The people who do the work know more than the people who manage it. Every time. The best insights come from spending a day with the person who actually enters orders, runs production, or reconciles invoices.

These aren't abstract principles. They're scars from real projects. And they're the foundation of how we work today.

The first conversation we have with every client starts the same way it started on the production floor: "Walk us through what actually happens."

Business first. Software second.