Contents
Digital transformation for engineering firms is the work of moving a firm's information out of retyped spreadsheets, email threads and individual memory, and into systems that pass it along without anyone copying it, so a project number, a design load, a drawing revision or an hour worked is entered once and read everywhere after. Software is part of it. Most of it is working out which processes the firm actually runs, and which data each one depends on.
Firms that start tend to meet the same set of limits. The software doesn't allow that. Our engineers won't use it. Our projects are too different to standardise. Some of these are real. Most have never been tested.
At university, the founder took an optional project in a hard course, worth at most 2 extra points, from a starting grade of 18.5. The work was good enough that the full 2 points would have meant a perfect score, so the professor gave 1. Limits usually exist because nobody has tested them, not because they're real. That cap had nothing to do with the work. Most of the caps a firm puts on its own digitisation don't either.
Start with where the same data is typed twice
Before any software decision, list every place where one piece of information is entered by hand more than once. In an engineering firm the list is usually familiar: the project number in the timesheet, the invoice and the drawing register; loads copied from the analysis model into a spreadsheet and then into the calculation report; site observations written on paper, typed into an email, then retyped into the weekly report.
Every line on that list is a place where data goes stale or gets mistyped, and every line is a candidate. The list also shows which systems need connecting first. Software and data integration consulting covers that side in detail.
The cost has been measured. A study by Autodesk and FMI, surveying over 3,900 construction professionals, estimated that bad data, meaning data that is inaccurate, incomplete, inaccessible, inconsistent or untimely, may have cost the global construction industry $1.85 trillion in 2020. Before that, NIST put the cost of inadequate interoperability in the U.S. capital facilities industry at $15.8 billion for 2002.
Process first, software second
Buying a platform before the process is written down encodes today's process, faults included, into a system that is harder to change than the spreadsheet it replaced.
Write the process down as it runs today, not as the quality manual says it runs: who starts it, what they need, who approves, where it waits, what comes out. The waiting points are usually where the time goes. Where AEC workflow automation should start walks through choosing the first process.
Engineers are the users, and the experts
Research on engineering companies at the bidt, the Bavarian Research Institute for Digital Transformation, found that digital transformation and organisational identity are mutually interdependent, and that growing software expertise inside a firm can become a threat to engineers' professional identity.
In practice, the engineers who do the work have to shape the tools rather than receive them. A design check written into software is still an engineering decision, and it needs an engineer who owns it.
The same research describes a balancing act between participation and leadership. The people who do the work help define the problem. One person decides what gets built. A tool designed by committee consensus usually turns out to be a form.
Off-the-shelf, configured or custom
Most of what a firm needs already exists as software. The question is which parts don't:
- Off-the-shelf for what every firm does the same way: accounting, email, file storage, timesheets.
- Configured for what every firm does slightly differently: a project management platform or a document control system, set up around the firm's own statuses and approvals.
- Custom for what only this firm does, or does in a way that is its advantage: its design checks, its calculation reports, the link between its analysis models and its drawings.
Custom AEC software development pays off in that third group. Starting with a small prototype tested on real projects, before the full investment, is covered in MVP development for internal tools.
Measure use, not installation
A system that is installed and unused is the most common outcome, and the hardest to see, because the licence report says everything is fine. Measure what changed in the work instead:
- How many people use the system in the second month, not the first week.
- The time from request to output in the process it replaced, before and after.
- How many fields are still typed by hand, and where.
- Which spreadsheet the team went back to, if any.
None of this needs a dashboard to start. A short review a month after each change is enough. Once there are several systems, a management dashboard for construction companies puts the numbers in one place.
Keep the knowledge inside the firm
Every system a firm adopts holds some of its knowledge: its statuses, its checks, its templates. The firm should be able to export its data, own the code of anything built for it, and have one person inside who knows how each system is set up. A transformation that depends entirely on one outside vendor has moved the firm's knowledge, not captured it.
Change in stages. One process, changed and measured, then the next. A firm that changes everything at once has no baseline to compare against.
If the firm's problem is that nobody uses the tools it already bought, more software won't fix it. That's a rollout and training problem, and you don't need us, or anyone like us, to start on it. When there is a process only your firm runs, our AEC workflow automation service is where that work happens.
Conclusion
Digital transformation for engineering firms starts with a list of where data is typed twice, a process written down before software is chosen, engineers shaping their own tools, and a measure of real use after every change. Most of the limits that come up along the way have never been tested. Testing one is a good place to start. What's the first thing you'd want to change? Tell us about the workflow.
FAQ
What does digital transformation mean for an engineering firm?
Moving the firm's information out of retyped files and individual memory into systems that take data in once and use it everywhere. Software is part of it. Most of it is defining the processes and the data behind them.
Where should an engineering firm start?
With a list of every place where the same data is entered by hand more than once. Each line is a candidate, and the list shows which systems need connecting first.
Should we buy software or build our own?
Off-the-shelf for what every firm does the same way, configured for what firms do slightly differently, and custom only for what is specific to your firm or is its advantage.
How long does digital transformation take?
It isn't one project. Each stage, one process changed and measured, is a project of its own, and the next starts once the last one is actually in use.
Why do digital transformation projects fail?
Usually because software was chosen before the process was written down, the engineers had no hand in shaping the tool, the system has no owner, or nobody measured whether it was used.
How do you measure whether it worked?
By users in the second month, time from request to output before and after, fields still typed by hand, and whether the team went back to the old spreadsheet.
When doesn't a firm need outside help?
When the real problem is that nobody uses the tools already bought. That is solved with training and rollout, not more software.