Nyheter
- 2026-05-12
- 13:45
From URS to Validated Production: Why Most Custom Automation Projects Fail
Pick any custom automation project that ran over time and budget: somewhere in the post-mortem, you will find the same handful of root causes. The instrument usually works, the team is usually competent, and, in the optimistic scenario, a User Requirements Specification (URS) was written, reviewed, and signed. This is not a story about bad engineering, but about failure points that appear at predictable stages, across a surprising number of projects, whether in precision dispensing for IVD or other manufacturing industries.
After 25 years of building custom precision microdispensing systems for diagnostics and life sciences manufacturers, we have seen enough of them to know where to look. Every custom automation project typically passes through the same sequence of phases: the diagram below traces that journey (Fig. 1). Each of the four failure points described in this article maps to a specific stage in this sequence, from the first requirements conversations to validated production.
Root Cause 1: The URS is not written, or written by the wrong people
The user requirements specification (URS) is supposed to capture what the system needs to do. In practice, it is either missing entirely, or written by a single function in isolation. Sometimes that is the R&D or application team, defining requirements that reflect laboratory conditions rather than a production floor. Sometimes it is the other way around: operations management writes the URS without input from the people who will actually run the system day to day, producing a document that is commercially coherent but practically unworkable. Either way, the result is a specification that describes someone’s reality, just not the one that matters most when the system goes live.
A URS with no throughput, environmental, operational or traceability requirements will produce a system that passes acceptance at the vendor’s site and then struggles during qualification at the customer. The same applies to integration: conveyors, barcode readers, MES/LIMS interfaces are either absent from the URS entirely, or described at a level of detail that is too vague to be actionable. This matters more than it might seem: the URS feeds directly into the Functional Requirement Specification (FRS), which is what the vendor engineering team uses to design the system and define test criteria, tracing each URS requirement to the relevant specs in the FRS via the TM (Traceability Matrix). An imprecise URS produces an imprecise FRS, and the gap only becomes visible late in the project, when it is expensive to close. This is not a vendor problem in any legal sense, but a good vendor should flag it early, because meeting a weak URS and delivering a working production system are not always the same thing.
At SCIENION, every custom project is assigned a dedicated Commercial Project Manager (CPM) from the outset. Their job is to ensure that the right stakeholders are in the room when requirements are being defined, and to ask the questions that the customer may not yet know to ask about their requirements, that is about what a successful product is, and how can this be measured. Getting Quality, Operations, and IT into the URS conversation before signature will add scope; that is exactly the point.
Read more about the importance of the URS in regulated manufacturing in our blog: Designing a Validation-Ready Precision Dispensing Workstation
Root Cause 2: The Process Changes between R&D and Production
Imagine a team spends months validating a dispensing process on their development platform. The reagent is characterised, the substrate is qualified, the parameters are locked. Then production starts, and the reagent supplier changes the formulation slightly, or a new substrate lot behaves differently, or the production instrument is a different model from a different vendor.
Re-validation follows. Not all of it, but enough to hurt. In our experience, reagent and target variability between development and production is one of the most common sources of delays in precision dispensing projects for IVD manufacturing, and one of the least discussed. It often falls to the instrument vendor to demonstrate that batch-to-batch variation in the customer’s own materials is the source of the problem, rather than the dispensing system. That is a conversation nobody wants to have nine months into a project.
Two things help. First, lock your materials earlier than feels necessary. Second, keep the same dispensing technology from development to production. If a process was working on an S3 bench-top microdispenser, that is already meaningful evidence of feasibility on a larger platform. The sciFLEXARRAYER range uses the same core dispensing technology from the S3 to the S100. Process knowledge built during development transfers directly, and re-validation scope is significantly reduced compared to switching platforms at scale-up.
Root Cause 3: The Requirement is Clear. The Testing Plan Isn't.
Short validation runs do not reveal what 24/7 operation will. Thermal drift, humidity sensitivity, reagent behaviour over long runs, conveyor timing conflicts, software errors under sustained load: these do not appear in a two-hour acceptance test, but later, under real conditions.
The underlying issue is that customers define requirements without defining how those requirements will be verified. A requirement with no testable success criterion is, in practice, unenforceable. These conversations — about what exactly constitutes a pass, under what conditions, with what reagents — tend to happen just before the Factory Acceptance Test (FAT), when there is no longer any room to adapt the design. Ideally, they happen at URS stage, or at the latest when the FRS is signed off.
Custom automation has been central to SCIENION’s business for now 25 years. The majority of customers running high-throughput SX systems and all our S100 customers require some degree of customisation, whether that is integration with an existing production line, a specific environmental configuration, or custom software logic. This is not an edge case for us, it is the norm. Design For Manufacturing (DFM) feasibility studies are part of what we can scope and deliver alongside the instrument itself, and our engineering and application teams have accumulated a significant body of experience in where integration problems hide. Long-duration run testing and stress testing need to be designed into the development plan from the start, with budget allocated accordingly.
Root Cause 4: Acceptance Criteria Are Set for the Vendor, Not for the Site.
The last of the most common failure mode, subtler and worth examining carefully, sits even later in the process, at the point where the system leaves the vendor facility and meets the customer’s real production conditions for the first time. The acceptance criteria in most projects describe what the instrument needs to demonstrate at the vendor’s facility: dispensing accuracy, positional reproducibility, cycle time etc. These are meaningful metrics, but they are not always the same as the criteria that determine whether the system performs in the customer’s actual production environment.
Functional testing with real reagents, under real site conditions, often happens late or not at all before acceptance: the system passes the factory acceptance test; it arrives on site; then the customer finds that what constitutes a pass at the vendor’s facility and what constitutes a pass at their production line are not quite the same. Customers sometimes respond by setting very conservative QC acceptance criteria, effectively pushing the risk back to the vendor. This drives up cost and timeline for everyone and does not resolve the underlying gap.
A more productive approach is to do some of this functional testing earlier: running the process on a smaller in-house system to understand where the tolerances actually sit before committing to acceptance parameters that nobody has validated against real functional outcomes. Testing with real reagents and real targets (and not just beta-quality materials!) as early as possible in the project gives both sides the information needed to adapt scope before it becomes expensive to do so. This is something that can be structured as a formal DFM feasibility study. This is also where the Commercial Project Manager’s (CPM) role becomes most visible.
The Common Thread?
Across the projects that go well, the pattern is consistent:
Requirements are defined with the right people in the room. Integration scope is agreed during design, not discovered during qualification.
The right structure, applied early enough, makes the difference between a project that delivers and one that teaches expensive lessons.
Taking the Next Step
If you are planning a custom precision microdispensing project, or reviewing one that has started to feel more complex than expected, the most useful first step is a structured feasibility conversation.
You can start that discussion on our custom solutions page, or book a call directly with one of our application engineers.
More news
Håll dig uppdaterad
Få det senaste först.
