For anyone who has spent years in the field, Excel is far more than a spreadsheet program. It holds design criteria, it carries the trial and error a company has lived through, and it quietly encodes who reviews what, and in which order. The problem is not that Excel is old. It is that the knowledge inside it moves file by file, disconnected from drawings, models, reports and specialist software.
The question you hear most often in the meeting room
A weight review meeting at a shipyard, a design coordination meeting on a construction project, and a P&ID review on a plant project share a strangely similar scene. The latest model is on the screen, and every participant has a different Excel file open in front of them. One person argues from a PDF received yesterday, another from a file on the shared drive, and a third from an email attachment.
The argument rarely begins with a technical question. It begins with verification: “Is this value current?”, “Which drawing did that number come from?”, “Has the change been reflected in the estimate as well?” Engineers have to establish the reliability of the data before they can even start calculating. This is less a problem of design complexity than a cost created by broken links between pieces of information.
Why Excel does not simply go away
The claim that digital transformation is complete only once Excel is gone takes far too simple a view of the field. Excel is fast and flexible, and it lets engineers see the calculation as it happens. It adapts easily to the client-specific formats and exceptional conditions that differ from project to project. Above all, it already contains formulas and report layouts validated over decades.
A single calculation sheet holds more than formulas. It encodes which values must be entered first, which ranges should raise a warning, and which table layout reassures the reviewer. That is why one aging Excel file often behaves like a small piece of specialist software. Rebuild all of it as a new web screen while ignoring that, and you end up with a product that looks modern but that practitioners do not trust.
What has to change, then, is not the tool but its role. Authoritative data is managed in a controlled data layer, while Excel is freed to focus on calculation, analysis and reporting. Users keep the calculation sheets they know, but the inputs arrive from drawings, models and reports carrying their source and version with them.
When the file is the truth
When data flows and files present it
One giant database is not the answer
Shipbuilding, construction and heavy industry use different systems, and different people own the data. Hull geometry sits in 3D CAD, structural analysis results in specialist software, ground parameters in geotechnical investigation reports, and equipment procurement status in ERP. Forcing all of it into a single system looks tidy in theory, but on real projects it can make ownership of the original and its update cycle even less clear.
A more realistic structure is a federated engineering data backbone. Each system keeps doing what it does well. What gets connected in a shared layer is the object ID, the meaning of each property, the unit, the source document, the revision number, the calculation dependency and the approval status. What matters is less “where it was stored” than “what this number is, where it came from, and what it was used for”.
Should AI do the calculating, or the connecting?
Since generative AI arrived, many products have promised to “design in natural language and calculate automatically”. But what matters in engineering is not a plausible answer; it is a reproducible one. A calculation whose result shifts for the same input, or that hides its units and applicable standards, creates new risk rather than speed.
The safer arrangement is to leave the actual numerical work to validated Excel formulas, Python modules, analysis software and Rule-as-Code. LLMs and VLMs deliver far greater value elsewhere: finding candidate inputs in drawings and PDFs, grouping different names into a single object, explaining what a formula means and which standard applies, and showing how far a changed value propagates.
Deterministic calculation and rule engine
Produces the same result for the same input, with standards and units under explicit control.
LLM and VLM layer
Reads the context of documents and drawings, and connects evidence and change impact in terms people can follow.
What happens across an industry when a single number changes
The value of this philosophy becomes clear not in a search screen but in a change situation. When the weight of a ship's pump changes, the equipment list, lightship weight, center of gravity, purchase specification and production plan are all affected. When the groundwater level on a construction site shifts, earth pressure, uplift, bearing capacity, liquefaction, the dewatering plan and the construction cost all have to be revisited. When an equipment tag on a plant P&ID is changed, the equipment list, datasheets, purchase documents, fabrication drawings and inspection records all need checking.
Today, experienced engineers hold these connections in their heads. The next generation of systems has to record a change as an event and follow object relationships and calculation dependencies to find the scope of impact. Automatically correcting every item is not the objective. Missing nothing that needs a second look comes first.
Seven principles to settle before the product
When this concept is turned into a real product, certain principles matter more than a spectacular AI demo. First, do not make an enemy of existing Excel files and specialist software. Second, give every value a meaning and a unit. Third, distinguish the original from the copy. Fourth, calculations must be reproducible under identical conditions. Fifth, trace the impact of changes. Sixth, never hide the AI's evidence or its uncertainty. And finally, at the end of every automated path there must be a point of approval by an accountable person.
Follow these principles and the product itself looks different. The center is not a chatbot but the connections between objects and calculations. The source and version of an input matter more than a beautiful dashboard. Difference comparison and rollback are designed before automatic generation. And a scheme for distinguishing which items can be auto-approved from which must always be seen by a person matters more than a single number like “99% accuracy”.
Design the flow of knowledge, not the future of the tool
The engineering industry already owns plenty of software. What is missing is not another screen. What is missing is a common language that lets the geometry of a drawing, the calculation in Excel, the assumptions in a report, the sentences of a standard and the changes on site understand one another.
This series examines that common language across shipbuilding, construction and heavy industry. The first installment, on shipbuilding, starts with why shipyards still run on Excel. It means treating Excel not as an aging legacy but as an executable asset that carries ship design knowledge.
doAZ Point of View
Beyond an AI that reads drawings, what is needed is a system that explains which calculation sheets and standards a value passed through, and which decision it led to. What doAZ is building is not a general-purpose chatbot but an operating system for verifiable engineering data and calculation.