Real-Time Quality Management: A Biomaterials Manufacturing Success Story

A biomaterials manufacturer, a shared Excel file, and what happens when a team decides to actually fix it.

There's a particular kind of operational pain that's easy to ignore until it isn't. It usually starts with a spreadsheet.

Not a bad spreadsheet, necessarily. One that was built thoughtfully, that worked well for a while, and that quietly became the load-bearing wall of an entire operation. Then the team grew. The process got more complex. More people needed access. And one day, the file that held everything together started freezing mid-shift, and someone's edits overwrote someone else's, and IT got called again, and a manager asked a simple question about process performance and had to wait two hours for an answer that could have taken two minutes. We've heard this story before. But what this particular team did about it is worth sharing.

A process that was always going to outgrow a spreadsheet

Our customer produces a bio-based leather alternative, a technically sophisticated biomaterial. That kind of complexity demands traceability, tracking quality at both lot and batch level from intake to finished product. And in a small, cross-functional team, the same person might be reviewing R&D data on Tuesday and manufacturing results on Thursday.

A shared Excel workbook was never really the right tool for this. It just took a while for the gap between the tool and the need to become impossible to ignore. Multiple users editing simultaneously caused the file to freeze. Cross-sheet references broke without warning. Decisions on whether a batch should be accepted, regraded, reworked, or scrapped, depended on individuals remembering to notify the right people at the right time. And every performance conversation required someone to manually pull and analyze data before the discussion could even start.

For a company serious about ISO 9001 compliance and building systems that could scale, something had to change.

Starting with the people, not the platform

What stands out about how this team approached the transition is that they didn't start by configuring software. They started by talking to people. Before a single workflow was built in AlisQI, their project lead ran feedback sessions with each major team: manufacturing, R&D, and internal product validation. Not demos. Listening sessions. The goal was to understand where friction actually lived before deciding how to address it.

Manufacturing wanted to stop preparing data before every management conversation. A live dashboard they could open mid-meeting, without any prior setup, was the ask. R&D needed experimental batches and full production runs to coexist in the same system without getting conflated, each governed by its own specification thresholds. The validation team wanted one thing above all else: confidence that no one would have to make a decision on incomplete data, and that rejected material would automatically reach the right people without depending on anyone's follow-up.

Each of those conversations became a configuration decision. Wherever possible, the system was configured around terminology and processes already in use, so that no documents needed rewriting and nothing about the way teams worked had to change to accommodate the platform.

Our direct involvement in the build stayed light, not because we weren't readily available to support, but because the platform didn't require us to be hands-on. AlisQI is designed to be configured by the people who actually understand the process, without needing a technical specialist to translate between business logic and system logic. Their project lead moved from feedback sessions to a working build largely independently, checking in with our team when specific questions came up. The system that emerged genuinely reflected how each team worked, because the person building it was already part of that operation.

Where things stand

When the project lead walked each team through the build during internal feedback sessions, the response was, in their own words, "overwhelmingly positive." Teams that had spent years working around the spreadsheet's limitations immediately saw what the new setup made possible. The overview dataset, automatically populated from test results across the operation, drew particular praise. Other teams could finally check testing status without interrupting those running the tests. The validation team recognized immediately the value in removing them from the middle of a communication chain they'd never wanted to be in.

The speed of that recognition matters. Before a single formal training session had taken place, teams were already seeing the value. Configuring the system around the language and workflows each team already used seems to have lowered the barrier to that initial buy-in considerably. A platform that's easy to configure tends to produce systems that are easy to adopt. That's not a coincidence.

What we take from this

Most quality management implementations are sold as transformations. Big, complex, months-long projects that require significant external support to get across the line. And sometimes that's what's needed.

But this engagement is a reminder that it doesn't have to work that way. When a team can take genuine ownership of the build, when the platform gets out of their way and lets them configure something that actually fits, the results show up faster and stick better. Here, they showed up before the project was even finished.

That's the kind of success story we like telling. Even more so when it's still being written.

Curious whether AlisQI could work for your operation? Let's talk →