The Chartership Forum

Computational Engineering / Programming and automation for engineers

Should this be automated?

The calculation nobody does, and the reason automating a bad process makes it worse.

Lesson review: expert verification remains open

This lesson has received a full-context editorial review and a check of its technical explanations. Selected arithmetic has been checked separately. This is not independent engineering sign-off.

Checks needed for project use

  • A computational engineering reviewer must check algorithms, convergence claims, statistical assumptions and numerical examples beyond the cases explicitly recorded.

These are educational models and exercises. Check their assumptions before using the results. The full technical content and every diagram have not yet been independently verified.

Concrete and steel calculations retain their stated first-generation Eurocode teaching basis. Use the standards and amendments specified for your project; do not mix generations without an appropriate design basis.

Read the lesson register and outstanding review notes

Why this matters

Automation is nearly always justified by 'it will save time' and nearly never by a calculation. Sometimes it does save time. Sometimes it costs three days to save twenty minutes, and the twenty minutes was going to be spent by somebody who now has to learn a tool instead.

This lesson makes the argument arithmetic, and then makes the more important point that the arithmetic is not the whole decision.

Estimate the work and benefit

Include development, verification, documentation and the work needed to make the tool usable by others. Estimate uncertainty in these costs rather than applying an unexplained multiplier.

Count how often the task will run over the chosen period and how many people will use it. Calculate the saving per run after allowing for input preparation and review of the output. A one-off task can justify automation if its scale or error risk warrants the development effort.

Allow for maintenance when source data, formats, requirements or the implementation change. Recheck the affected behaviour after changes. Training and handover may also be material costs.

Set verification and checking effort according to the consequences of error. A schedule can affect procurement or construction, so its risk is not necessarily low simply because it contains no member-sizing calculation.

The calculation

If every user makes the same number of runs, estimated benefit is runs per user × users × time saved per run. Compare this with development, verification and maintenance, adding other material costs. State the time period and test how the conclusion changes when the estimates vary.

Review the process first

Automation repeats the specified procedure, including any mistaken assumptions or omitted load cases. Establish whether the process answers the engineering question before implementing it, then test the implementation against known results. Time saving alone does not establish that a tool is suitable.

Try it

Should this be automated?

Enter the real numbers, including the ones people leave out. The verdict is withheld until the risk question is answered.

days
days
days

Catalogues change, formats change, people leave. Zero is rarely honest.

h

Include the checking that no longer has to happen by hand.

If it is wrong and nobody notices, what happens?

Build cost
53 h

development plus verification

Maintenance
15 h/year
Gross benefit
40 h/year
Net benefit
25 h/year

gross benefit less maintenance

Payback
2.1 years
Break-even runs per year
13.5

runs needed in year one to cover build plus maintenance

No verdict yet. The arithmetic above is only half the decision — answer the risk question, because it sets how much verification is proportionate, and verification is a cost you have already entered.

The question this calculator cannot answer

  • Is the process you are about to automate correct? Automating a check that omits a load case gives you a fast, consistent, thoroughly documented omission — applied to every project, with the authority of having come from a tool.
  • Who will own it when its author leaves? An unowned tool becomes an unmaintained tool, and an unmaintained tool becomes a liability the year after it was written.

What this shows: Automation pays back development, verification AND maintenance — and the arithmetic is the second question, not the first.

Worked example

A connection-schedule tool

Given

  • Producing a connection schedule by hand takes 6 hours per project
  • The tool would take an estimated 5 days to build and 2 days to verify
  • The office does 8 such projects a year
  • The tool would reduce the task to 1 hour, including checking its output
  • Maintenance is estimated at 2 days a year

Find

Whether the tool pays back, and over what period

    Practice

    A script takes 12 hours to write and verify, saves 15 minutes per run, and is used by 4 engineers. How many runs per engineer are needed to break even? Give the number of runs per engineer.

    Practice

    A task takes 6 minutes and is done 40 times. Automating it takes 5 hours to write and 2 hours to verify. How many minutes are saved, net?

    Check yourself

    Which cost is most often left out of a decision to automate?

    Check yourself

    A repetitive task is a candidate for automation. What question should come before 'how do I automate this?'

    Summary

    • Count development, verification and maintenance, not just development
    • Frequency and number of users are what make automation pay
    • Risk sets how much verification is proportionate
    • Ask whether the process is right before asking whether it can be automated
    • A fast, consistent, well-documented omission is still an omission