Ship Repair Yard Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the scope of a yard system get written the wrong way round?

The biggest scope failure here is buying or building a project system that assumes the work was known when the contract was signed. Every general contracting package and every generic scheduling tool is built on that assumption: a work breakdown structure, tasks, dependencies, and a change request process for the exceptions. In ship repair the exceptions are the business. You cannot know the wastage until the coating is off, the tailshaft clearance until it is drawn, or the valve seat condition until it is opened.

So a system designed around the quoted specification treats your actual product, priced and proven additional work, as an afterthought bolted onto the side. The symptom is predictable. Variations get raised late, in the office, from memory, by someone who was not on the dock, and the evidence is a photograph on a phone.

Write the specification the other way round. The variation is the primary object: owner specification reference, description in the owner's language, measured quantity, rate pulled from the contract rate card, photographs taken before the plate was cut, date and time, and the attending superintendent's signature captured on site. Everything else, planning, timesheets, invoicing, hangs off that. If a prospective developer draws project, task and change request, they have brought a construction tool and are about to learn ship repair at your expense.

What goes wrong when you migrate rate cards, specifications and job history?

The data problem in a yard is not volume, it is that the most valuable information has never been written down. Rate cards are the clearest case. Most yards run three or four rate structures, negotiated differently per owner, with position and access loadings for confined or overhead work, and the full logic frequently lives with the commercial director rather than in a document. Extracting it is the longest pole in the project and it is always mistaken for a quick meeting.

Specification history is the second. Owners send specifications in their own numbering, so your archive holds documents in a dozen structures, and the mapping to your internal job numbers exists only in the estimator's head or in a spreadsheet per vessel. That mapping is exactly what would let you price the next docking of a repeat vessel from what the last one actually cost, and it is usually unrecoverable.

Job costing history is the third, and it is often distorted rather than missing: hours posted to a general job number because the foreman did not have the right one to hand, subcontractor invoices matched to a vessel rather than to the work order that raised them.

Do the extraction as a workstream with the commercial director in the room, write the rate rules as prose, and have an estimator price a past job against them to check. Then migrate selectively: current and recent vessels with their mapping, the rate cards, and nothing else. Distorted historic cost data imported wholesale will make your first margin reports wrong and destroy trust in week one.

Why do the timesheet, stores and accounting integrations break after launch?

Three integrations carry a yard build and they fail for three unrelated reasons. Labour posting breaks on discipline rather than technology. Clocking systems record that a man was on site, not which job he was on, and the gap between those two facts is filled by a foreman allocating hours afterwards. If your build depends on accurate labour posting and nobody changes how allocation happens at the trade level, you will get precise reports built on approximate inputs.

Stores breaks on timing. Plate and consumables are frequently issued against a job before the work order exists, or against the vessel generally during a rush, and the correction never happens. Decide up front whether an issue without a valid job number is refused or parked in an exceptions queue, and make sure the storeman knows which, because a system that refuses at the hatch during a night shift will simply be bypassed.

Accounting breaks at the invoice boundary. Progressive invoicing, retention and a final account that must be presentable in the owner's numbering are three different shapes, and if the mapping to your ledger is not agreed with your finance team before build, every month end becomes a reconciliation argument.

Ask any developer for the specific system and the specific document, not a general claim about integrations. Posting hours from a clocking system, issuing stores against a job and pushing a final account to a ledger are three problems with three failure modes.

What happens when class attendance and permit to work are not covered?

Two operational gaps regularly turn into commercial losses and neither is usually in the first specification.

The first is class survey attendance. A surveyor's visit has to align with the state of the work: the tank has to be clean, gas free and staged before he arrives, and the item has to be ready to present. When attendance is planned in a separate calendar from the production plan, a surveyor arrives to find the staging not built, and you pay for the wasted attendance and lose the slot. Worse, an item that fails to be presented before undocking becomes a condition carried to the next port, which is a conversation with the owner you do not want.

The second is permit to work and gate control. Hot work permits, gas free certification, confined space entry and the contractor gate register are safety obligations first, and when they sit on paper in a hut they are also invisible to the plan. A tank that cannot be entered because the certificate expired at noon is a stopped trade, and the cost lands as idle labour nobody attributes to the cause.

Covering it means the production plan, the class attendance calendar and the permit state are the same picture. An item scheduled for survey shows whether staging, cleaning and certification are complete. A permit approaching expiry raises a flag before the trade walks to the tank. And every stoppage records its reason, so at the end of the docking you can see how many hours went to waiting rather than working.

Should you build custom or configure what you already own?

If you are an afloat repair outfit doing voyage repairs, small steel jobs and superintendent assisted machinery work with no dock of your own, do not build. Your scarce resource is people rather than slots, and a disciplined paper process with a strictly enforced signed variation form will hold. Spend the money on lifting gear.

If you run long term fixed contracts with one naval or government customer under their own reporting regime, do not build either. You will be forced into their formats and their document control, and a parallel system becomes double entry.

And be honest about SpecTec AMOS, SERTICA and ShipNet. They are mature maritime systems and they are not weak, but they were built for the shipowner and the technical manager: planned maintenance, component hierarchies, procurement, certificate tracking across a fleet. If an owner sends you a specification there is a fair chance it came out of one of them, which is precisely the point. They are the other side of the table's tools, and they were never designed to protect a yard's commercial position on growth work.

Build when you own a dock or a syncrolift and slot utilisation drives your result, when growth work is a material share of the typical final account, when you have lost a dispute in the last two years for want of evidence, or when you quote in more than one pricing model on the same job.

How do hidden costs get into the quote?

Offline capability is the first and it is not optional. Dock bottoms, double bottom tanks and engine spaces have no signal, and a variation feature that silently fails there is worse than paper because it creates the belief that a record exists. Local storage, a sync queue, conflict handling when two foremen raise overlapping items, and photographs that upload later without blocking the form are all real engineering, and a quote that treats offline as a checkbox has not priced the work.

Rate card discovery, discussed above, is the second and it is your cost as much as the developer's, because it consumes your commercial director.

Multi currency and multi language is the third, and interface language for the trades and document language for the owner are two different requirements.

Fourth is device provisioning in a hostile environment. Tablets on a dock bottom get dropped, wet and covered in blast grit, so the fleet, the cases, the charging and the replacement rate are an operating cost. Fifth is training in shifts, because a yard runs nights and weekends during a docking and a single daytime session reaches perhaps half the people who need it.

What separates a build that works from one that fails here?

The builds that work make the owner's specification number a first class identifier that never disappears. Import the specification once, map each owner item to one or more internal work orders, and carry both references through quotation, timesheets, variations and invoicing, so the final account can be printed in the owner's numbering. That single change removes the reconciliation week your estimator currently spends per vessel and takes the most common argument off the table before it starts.

They link approved variations directly into the dock plan. Twenty eight extra tonnes of steel is also extra days, and if the plan does not move automatically the next arrival finds out late. Making that link converts a scheduling surprise into a commercial conversation you can have a week early, which is usually the last point at which you can recover the day rate or renegotiate the slot.

They put the exposure in front of the owner the same day. A portal showing agreed variations as they are signed changes the tone of the final account meeting more than any other feature, because the argument becomes about work rather than about whether the work happened.

And they leave you owning everything. The repository, the cloud accounts and the right to hire anyone else to continue, agreed in writing before kickoff. At Digital Heroes the code is yours from the first commit, and we would tell you to walk away from anyone who hedges, because a yard whose variation evidence lives on a developer's infrastructure has moved its most important commercial record off its own premises.