Why Shipyards Still Run on Excel

Excel in a shipyard is not a stopgap. Weight, equipment, tanks, estimates, production progress and class submission packages — countless judgments are made inside those files. That is why the slogan "let's get rid of Excel" never convinces the people doing the work. There is a prior question to ask. Why does ship data, once decided, get re-entered into multiple files, and why must a person chase its traces every time the design changes?

The morning of a weight review meeting

Picture a morning during basic design. An equipment supplier has sent the final weight of a cooling water pump. It is 1.8 tonnes heavier than the value used in the initial estimate, and its center of gravity has moved 420 millimeters higher. The 3D model engineer updates the equipment properties. But the weight engineer's Excel file still holds the previous value, and the purchase specification and the production department's equipment list carry different revision numbers.

The first task in the meeting is not a stability calculation. It is establishing which value is official, which file is current, and who was informed of the change. This scene is not an exceptional incident but the ordinary friction of a large ship project, because a single vessel contains thousands of equipment items, compartments, pipes and structural members, and several organizations move at the same time.

Why shipyards trust Excel

Explaining Excel's survival simply as "shipbuilding is conservative" misses the point. Excel absorbs the variability and exceptions that ship design demands, and it does so extremely fast. A different ship type changes the calculation items, owner requirements are added, and shipyards and design houses each hold different standards. Reviewers can open formulas and intermediate values directly, and columns and sheets can be reshaped on the spot to fit a project.

A weight tracking file holds far more knowledge than a simple total. SWBS or a shipyard's proprietary classification system, margins by estimating stage, whether a supplier has confirmed the value, the confidence grade of a weight, position coordinates and the organization responsible for each system are all managed together. A tank calculation sheet reflects shape corrections, filling ratios, free surface effects and operating conditions. An estimating file hides not only material unit prices but productivity, outsourcing arrangements, shop constraints and experience factors.

These files grow more refined the longer they are used. When someone finds an error, a warning formula is added; when class or owner requirements change, a new sheet is attached. Excel is, in effect, a shipyard's executable memory. Replacing it with a new system requires more than replicating functions — it requires understanding why that memory formed.

The problem is not Excel, it is duplication and disconnection

Excel's strength turns into a weakness the moment work moves file by file. When an equipment weight is entered separately into the equipment list, the weight roll-up, the estimate, the purchase file and the production status file, the same information acquires several owners. Column names and units differ between files; some files use an equipment tag while others use only an equipment name or drawing number. Even confirming that two entries describe the same equipment becomes manual work.

If a design were fixed once, this approach could hold. But real ship design is revised repeatedly. Owner comments, class review, vendor confirmations, spatial interferences and producibility studies each move values and states. The more changes accumulate, the more time engineers spend on transmitting and re-entering data rather than on design.

The design knowledge hidden behind a cell address

Turning existing calculation sheets into digital assets takes more than reading formulas. You have to know what `Summary!H42` actually is — whether it is the current weight of a specific equipment item, a vendor-confirmed value, or a design weight that already includes margin. You also have to know whether the unit is kilograms or tonnes, whether coordinates are referenced to AP or FP, and whether an empty cell means zero or "not yet determined".

Parsing Excel is therefore a technical exercise and an exercise in modeling engineering knowledge at the same time. Named ranges, formula dependencies, external links, VBA, hidden sheets and protected cells all have to be analyzed, but attaching meaning on top of that analysis matters more. Storing a cell as `B17` is not enough; expressing it as `Equipment.P-2101.Weight.Design` is what makes connection to other systems possible.

The invisible cost is waiting time, not errors

Disconnected data in a shipyard produces more than simple entry errors. The larger cost is time spent waiting for confirmation. The stability engineer cannot update calculations until the weight engineer confirms the vendor value; the production department cannot fix the lifting plan until procurement verifies the specification. When the source and status of a value are unclear, work stops — or the responsible engineer assumes conservatively and stacks margin on top of margin.

Organizations leave that headroom in the name of safety, but if no one can trace where and why it was added, the vessel's total weight and cost can grow. Connecting data is not merely a technique for saving time; it is a technique for making visible where uncertainty was absorbed, and how much of it.

Where to begin

A first project should not attempt to integrate every piece of data across an entire vessel. It is better to choose one flow with high business value and relatively clear relationships. Equipment lists and weight control, compartment areas and volumes with estimating, or tank data with capacity calculations all make good starting points.

Suppose you pick the equipment weight flow. First, gather 20 to 50 real Excel files and classify their common inputs and outputs. Next, define equipment tag, weight type, coordinates, status and source as a minimum schema. Then connect to one project's 3D model or equipment list, attempt automatic population, and compare the results against the existing calculation sheets. Finally, introduce a single change and verify how accurately the system finds the related documents and calculations.

You can only move beyond Excel by respecting it

Shipyards have rational reasons for using Excel. Solving the problem means not denying those reasons and leaving Excel to do the calculation and presentation it does well. What must come out of the files instead is the data's source and object, its version, and its change relationships.

The next article turns this principle into an actual structure. It looks at how to define vessel, deck, compartment, tank, equipment and weight item as objects, and how to connect them to the cells of existing Excel files so that data entered once can flow safely into many calculation sheets.