One configuration. Quote, drawings, BIM object.
That's what Wabric's CPQ and Produce module does: prices the order, builds the production drawings, and generates the BIM object, all from the same configuration.
See CPQ + Produce →A building's BIM model runs through nine stages, start to finish. A manufacturer's own data enters the picture at exactly one of them: fabrication, where a product's real geometry and specifications get built into the model.
Enter it from where, though? Usually, not from the same place as the quote. The software that prices an order isn't the software that builds a BIM object. One's a CPQ or ERP tool. The other is CAD or BIM authoring software. Different vendors, different jobs, no connection between them by default.
This piece is about what changes when that stops being true: when one configuration builds the quote and the BIM object at once.
What is the BIM lifecycle?
The BIM lifecycle runs through nine stages across a building's life: concept, design, analysis, scheduling, fabrication, construction, handover, operations and maintenance, and renovation, then back to concept for the next one. BIM itself, Building Information Modeling, is the digital model that carries real data, not just shapes, through all of it. Architects and engineers own most of that lifecycle, right up until fabrication, where a manufacturer's own data takes over.
This isn't a niche concern anymore. BIM use on European construction projects climbed from 10% in 2009 to 53% in 2025, and in the Nordics it's already the default rather than the exception: Sweden reports 93% company-level adoption, Denmark and the Netherlands 78% each, according to European Architectural Barometer data published by USP Marketing Consultancy. A manufacturer who isn't showing up correctly in that process is missing a growing share of it.
Why the BIM object usually gets built separately from the quote
Once an architect has a manufacturer's object, they're inserting it into a live, coordinated model, and it has to behave like the real thing it represents: the right dimensions, the right materials, the right compliance data, sitting correctly next to every other system already in the building. That object has to be modeled by someone, in some piece of software, at some point.
Traditionally, that's a different system and a different effort than the one that produced the quote, a CPQ or ERP tool for the price, CAD or BIM authoring software for the object. Nothing connects them by default, so whether the object gets made at all, and how well it matches a real order, comes down to whoever has time for it.
What's the difference between a BIM object built separately and one built from the quote?
Think of a BIM object as a digital Lego block for one specific product: a shape, plus the data riding along with it. An architect's model of the whole building is just thousands of these blocks snapped together, walls, windows, railings, pipes, all of it. Any block that's roughly the right shape will snap into place and look fine on screen. Whether it's actually the right one, the one that matches what gets built, is a different question. Built separately, by whoever has time for it, that block is usually generic: one object standing in for a whole product line, because hand-modeling a unique version of every possible configuration isn't realistic. It goes stale as the range changes, and it needs manual editing before it matches any specific real order. In BIM terms it sits at a fixed Level of Development, both geometry and information, set once and rarely revisited.
Built from the quote, it's a different thing entirely. The same configuration that priced the order also generates its BIM object, so it already reflects exactly what was ordered: the dimensions, the materials, the finish. It updates automatically as the range changes, because it isn't a file someone maintains, it's a projection of the same data the quote came from, ready to drop into the architect's model at construction-ready LOD, full geometry and full information, the moment it's generated. BIM objects are technically where the information flow starts, which is exactly why it matters whether that starting point is generic or exact.
A generic object and an exact one solve different problems. Only one of them can be built automatically instead of by hand.
What does an architect actually gain?
There's a second beneficiary here, and it isn't the manufacturer.
A real, project-specific object means the architect isn't waiting on a custom rendering from someone's design office. It means the object clashes correctly against every other system already in the model, because it was built to the actual dimensions instead of a generic placeholder adjusted by hand later. It means fewer surprises once construction starts, because the specification and the manufactured product were never two different things to begin with.
The same object keeps paying off after handover. Facility teams inherit the model to run maintenance schedules and plan renovations, often through COBie, the standard format most facility management handovers already run on, and a structured, accurate object feeds into it cleanly. A generic library file that's been hand-edited to get close is a liability by then: confirming it still matches what actually got built takes real work, if anyone does it at all.
That's worth saying to an architect directly, not just implying it: generated from the exact configuration, never edited by hand.
Proof: Krah Pipes
Krah Pipes ran fabrication drawings the old way: sales quotes the order, engineering redraws it for production, the customer asks for a change, engineering redraws it again. Sixteen revisions was normal before a standard order's drawing was locked. On Wabric, that number is zero for standard configurations, because the drawing is never redrawn in the first place. It's the same parametric model that generated the quote.
That's what it looks like when the quote is the engineering output, and it's exactly the kind of output a manufacturer needs at the fabrication stage, whether the audience is their own production team or an architect's BIM software.
See how Krah Pipes eliminated drawing revisions →
The same model does BIM too
The parametric model that prices an order and produces its production drawings is the same model that can emit an IFC object, the open, vendor-neutral format openBIM runs on, smaller and faster to move between teams than a native software file, and free to open on either side. Not a generic stand-in for the product line: the actual configuration, with the correct geometry, correct materials, and correct classification, ready to drop into the architect's Revit or Archicad file. Standard BIM practice treats this as a one-way rule: quantities and drawings are supposed to come out of the model, never the other way around.
Wabric's CPQ and Produce module applies that same rule to a manufacturer's own product data, running the client-facing quote, the CAD drawing headed to the factory, and the BIM/IFC object headed to the project off one configuration. Same underlying data, three outputs, no separate BIM effort bolted on after the sale.
It's also a head start on compliance
A parametric BIM object isn't only geometry. It carries materials, classifications, and provenance data too, the same data that lives in PIM. That also happens to be exactly the structured, machine-readable format the EU's Digital Product Passport rules are asking manufacturers selling into the EU to produce. A manufacturer still quoting from spreadsheets is looking at a genuine multi-year project to get that data into shape. A manufacturer already generating a structured object on every quote gets most of the way there as a byproduct of how they already sell, not as a separate compliance initiative.
Fabrication is the one stage in this whole cycle where a manufacturer's own data enters the model directly. Show up there with a real object instead of a generic one, and it carries the rest of the way: matching the drawings, matching the compliance record, matching what actually gets built.
Get this kind of thing before it hits your inbox from somewhere else →
About the author
Kaur Tull is CEO of Wabric and a certified civil engineer (Estonian Qualification Framework, level 7) with a background in BIM coordination and modelling.
Frequently Asked Questions
Building Information Modeling: a digital model of a building or structure that carries real data, not just geometry, through every stage of its life, from concept and design through fabrication, construction, and years of operation and maintenance. The model itself, not a drawing set, becomes the shared source of truth for everyone working on the project.
Nine, running in sequence: concept, design, analysis, scheduling, fabrication, construction, handover, operations and maintenance, and renovation, which feeds back into the next concept phase. Architects and engineers drive the first four stages, manufacturers and contractors drive fabrication and construction, and facility managers take over from handover onward.
Almost entirely at fabrication, the stage where a product's real geometry, materials, and specifications enter the model. Earlier stages belong to architects and engineers, later stages belong to contractors and facility managers.
A generic object is a placeholder representing a product category, with most properties still undefined. A manufacturer-specific object carries the real dimensions, materials, and performance data for an actual product, or in a parametric system, an actual configuration.
Yes, arguably more than a standard product does. A configurable product has no single fixed geometry to represent, so a static library object can only ever approximate it. A parametric object generated at the point of configuration is the only version that matches what's actually being built.
It gets a manufacturer most of the way there. A DPP needs structured, machine-readable product data: materials, classifications, provenance. A parametric object already carries that data, because it's the same data used to generate the quote.
Mainly time and accuracy. It matches the actual configuration instead of a generic placeholder, so it coordinates correctly with everything else in the model, needs no manual editing, and stays useful after handover for facility management and future renovations.
