Process First, Then Automation

Every week, another vendor promises to automate your BIM workflow with AI. Every week, another firm buys the promise, points the tool at its existing process, and discovers an iron law of operations:

Automation applied to a broken process just produces mistakes faster.

If your naming conventions are inconsistent, automation will propagate the inconsistency at machine speed. If your family library is a junk drawer, a script will fill your model with junk more efficiently than any human ever could. The tool is not the problem. The sequence is. Process first, then automation.

Map before you machine

Before we automate anything — for ourselves or for a client — we map the process end to end: every handoff, every approval, every file that moves from one environment to another, every decision and its actual owner. Not the process as the standards manual describes it; the process as it actually runs on a Tuesday under deadline.

The map always reveals the same three categories of work, and each demands a different treatment:

• Work to eliminate. Steps that exist because they have always existed. Status meetings that restate a dashboard. Double data entry between systems that could share a source. Approvals from people who never decline. This is the highest-ROI category, and no software is required — you simply stop.
• Work to standardize. Steps that are genuinely necessary but performed differently by every person who touches them. Family creation. Sheet setup. Model auditing. QA checklists. Standardization is the boring middle child of process design, and it is non-negotiable: you cannot automate what you have not standardized, because automation is standardization enforced by a machine.
• Work to automate. Only what survives the first two filters: repetitive, rule-based, high-volume, and running on clean standardized inputs. Batch parameter validation. Naming enforcement. Quantity extraction. Clash report triage. Here — and only here — the scripts, the Dynamo graphs, and yes, the AI, earn their keep.

A before and after, anonymized

A production team we integrated with was spending roughly two days per submittal cycle assembling drawing sets: collecting views, checking naming, verifying revision clouds, exporting, and re-exporting after the inevitable catch. Their instinct was to buy a publishing automation tool.

The map said otherwise. A third of the effort was rework caused by upstream naming drift — automation would have shipped the drift faster. A quarter was a review step that duplicated a check already performed in the CDE — eliminated outright. What remained was standardized into one sheet-setup protocol and one view-naming rule set, and only then automated. The cycle dropped from two days to under three hours. The tool they almost bought would have locked the original mess in place — an expensive way to make a broken process permanent, which is what most automation purchases actually are.

Why this is unfashionable and correct

Process mapping does not demo well. It produces documents instead of dopamine, and it forces uncomfortable questions about who owns what. Vendors skip it because it slows the sale. Firms skip it because everyone is too busy drowning to study the water.

But across 200+ projects, the pattern has never once inverted: the firms that get durable returns from automation are the ones that did the unfashionable work first. They knew exactly which thirty percent of their workflow deserved a machine, because they had already deleted the ten percent that deserved nothing and standardized the sixty percent that deserved a rulebook.

That discipline — map, eliminate, standardize, then automate — is the difference between buying technology and building capability. It is also, not coincidentally, the first thing we do inside any environment we integrate with. The audit comes before the engine. Always.