The Modern Engineer's Guide to Process Automation: Breaking Free from Manual Tasks

According to a study conducted by Siemens and Tech-Clarity¹, Engineering teams are losing substantial amounts of time in their day-to-day work. Another study by Colab² concludes that engineers spend an alarming 23% of their time on non-value-added work.

23%! While some time spent on non-value-added tasks is inevitable, this number goes beyond mere inefficiency – it directly connects to product quality, development timelines, and ultimately, market competitiveness. And indeed, Tech-Clarity reports an alarming 96% of companies see low engineering productivity negatively impact their business.

For engineering teams already facing talent shortages, competitive pressures, and accelerated timelines, this reality represents not just a productivity challenge but a strategic business threat.

The Top Engineering Time Wasters

But what exactly is draining engineers' productivity? Tech-clarity went further and categorized time wasters for different company sizes.

• Manual processes & repetitive work: Two aspects of the same problem. Engineers spending time on processes that are required to translate thoughts into digital models, for example, adjusting CAD geometries or setting up analyses. Make that manual work repetitive and you’ve got a great combo to grind down productivity as well as motivation of any engineering team.
• Poor collaboration: Waiting for that FE analysis to come back from the always busy simulation engineer, forgetting to forward that important design update to the manufacturing engineers – these things not only cost time but also increase frustration. In the worst case, the result not only a slow process, but a blaming culture and finger pointing between departments, a true killer for innovation.
• Interruptions: Engineering requires focused work. Attaining that focus can take around half an hour – only to see it going down the drain again when that next phone call or Teams message comes in.
• Non-value-added tasks: Not improving the product, these are related to communication and documentation.

Top time wasters in product development. Percentages indicate the portion of participants struggling with these. From Boucher (2022): The Business Value of Reducing Engineering Time Wasters, Tech-Clarity Inc.

It’s interesting that, for manual and repetitive work, both small and larger business struggle similarly. For communicative and organizational topics (meetings, interruptions, collaboration issues), larger businesses suffer substantially more than small ones – possibly due to their more complex hierarchies and processes.

In this article, we’re going to look into how process automation tools can present solutions to these time wasters, focusing specifically on manual work & repetitive tasks.

Breaking the Shackles of Manual Work

One of our engineering customers recently worked on a detailed injection molding design requring the application of hundreds of individual fillets. This job took one CAD designer almost two days of mind-numbing click-work. What’s more, any change of the underlying geometry would also require a redo of all of the filleting operations.Tedious manual steps – for example the selection of hundreds of edges to be filleted – can substantially slow down product development processes. Image by GPT 4o.

Imagine the frustration of both the poor person to execute this job as well as their manager looking at the money paid for an engineer doing monkey tasks. And frustration aside, a manual step like this seemingly simple operation can become a bottleneck in any iterative process, crippling the performance of the end product.

Sounds familiar? Then automation might be a solution for you! But what does it take to automate engineering tasks and processes? Do you need programmers? Which tools are required? Here are some thoughts on these topics.

The algorithmic mindset

Engineers are often not well trained to automate their work. What we see at our customers is that some users become automators and some don’t. It appears that it takes what I like to call the “algorithmic mindset”: To tune in to process-based thinking, where the end goal is an efficient and automated algorithm instead of a specific part or geometry. To find automators among your engineers, look out for these traits:

• They ask “why” more often than “how”
• They are great at recognizing similarities across different parts or processes
• They think in terms of parameters that drive outcomes and see engineering as an interconnected process rather than isolated actions
• They have solid foundations in computational geometry – at least if CAD processes are involved

Engineering can also be a very traditional realm where “this is how we’ve done it the last 20 years” opinions hinder forward thinking or new solutions. I’ll never forget the FEA engineer I met at the early days of my career who’d still create his meshes manually while automatic meshing was long established. Experts like this can be hard to convince.

Time is another factor. If there are pressing project deadlines, there will be hardly any time for establishing new tools and processes.

Ongoing work can often obscure possibilities to improve processes. Source: GPT-enhanced version of an internet classic of unknown origin.

Neglect this organizational resistance and your automation journey might stall before you even hit the play button the first time. To keep engineers motivated, it is crucial to present positive incentives to change.

• Identify automation-receptive engineers and help them become champions to get the initial momentum going. Once success becomes visible in the first projects, their enthusiasm can be contagious.
• Create dedicated time for learning. Some tools have a shallow learning curve, but engineers will not risk delaying ongoing projects by trying automation. Next to allowing budget for training, think about 1–2 day hackathons where more experienced automators and new users work together on small projects.

Programming languages are not made for engineers

Education for engineers typically doesn’t include a lot of programming. So how can you expect an engineer to automate processes, maybe even across multiple softwares like CAD and FE?

Help comes in the form of no-code or low-code tools which enable individuals without coding experience to create algorithms and automations through user-friendly drag-and-drop interfaces.

An intuitive interface aside, what engineers require from an automation solution are:

• strong visualization capabilities
• robust geometry operations – especially for surfaces and solids
• connectivity to wide a spectrum of engineering tools, e.g. for mechanical analysis or manufacturing preparation
• data & version management, e.g. through PLM systems

In the graphic below I’ve gathered the corresponding information for a number of tools that would lend themselves to being used for automation in engineering contexts:
Overview of tools that can be used to automate engineering processes. Scripting languages (FeatureScript, Matlab, Python, TCL) generally show a much steeper learning curve and except for FeatureScript lack built in visualization capabilities. Low-code tools like xGenerative, Grasshopper and Synera allow much faster value moments.

With this overview, it should be possible to get an understanding of the automation tool landscape and make a choice about tools worth trying. At Synera, we aim for end-to-end workflows and an open ecosystem that integrates as many engineering tools as possible – but that might not necessarily be your focus, so explore!

A good use case

With the tool and the people in place, it’s time to get started – ideally with a use case that delivers value quickly when being automated. It should be simple and carried out many times. Think about complementing or modifying part databases, e.g. by checking out parts, measuring geometric properties like volumes and adding that information as meta-data. A small job with many repetitions presents quick wins and moments of success – lowering the probability of resistance and allowing engineers to extrapolate the possibilities to bigger tasks instead of being overwhelmed. At Synera, we see it as one of our most important jobs to find these quick-win projects together with our customers to create wow-moments quickly.

Example of a low barrier project to get started with automation: Import of CAD geometries, assessing key geometric features to establish the current orientation,  followed by a reorientation and export of the part. Automating this task lead to time savings of over 90%. The automation was robust enough to correctly orient 97% of the parts. Not only was the process done faster, but it also avoided outsourcing of this task – which typically involves a lot of communicational overhead.

Here are some more angles towards use case selection:

Build time vs number of repetitions

Building (and debugging) an automation takes time. In the filleting example from the beginning, one manual iteration took almost two days. With our visual programming language, our customer was able to automate this task within 3 days and the automation would then run for 2–3 hours to apply all fillets. After the second iteration, the automation already paid off, reducing each run to 15–20% of the time required manually – and freeing one CAD designer from this menial task.

So as a rule of thumb: if the time spent on automating roughly equals the time for one manual iteration, it can already make sense to automate. Even if the automation does the job equally slowly as a manual worker – that one individual has now been freed up to do a more meaningful task. Typically though, build time often exceeds time savings for one iteration, so more usage is required to reach break even. 

Flexibility vs. robustness

When designing automation solutions, you'll inevitably face a fundamental tradeoff between flexibility and robustness. Highly specific automations that handle one precise task are typically more reliable but break when conditions change. Meanwhile, flexible automations that adapt to varying inputs tend to be more complex and error-prone. 

Consider our suction gripper example. The automation expects these grippers to be axisymmetric bodies of revolution and the suction lip contour to be the largest circle in the geometry. Throw in any other geomtry and the automation will fail – for example if there are no circular curves to be found – or return results that are not meaningful.

Balance this tradeoff by understanding your process stability. For established, standardized workflows that rarely change (like standard part processing), prioritize robustness by keeping the automation simple. For evolving design processes or areas with frequent requirement changes, build in flexibility—but expect to invest more in testing and maintenance.

An effective approach to flexibility is to create modular automations that still allow engineers  to configure parameters without rebuilding the entire workflow. This "parameterized flexibility" offers a middle ground, allowing adaptation within well-defined boundaries while maintaining core reliability.

Here’s an example for a flexible FE analysis automation: It uses colored geometries and Excel sheets that map colors to boundary conditions as inputs.  This workflow enables CAD designers to run static mechanical analyses for any geometry using the company’s standard solvers and quality criteria – completely without the assistance of FEA experts, thus avoiding a common organizational bottleneck.

Tool transitions

Yet another parameter in the decision to automate is the number of transitions of the data between tools. These transitions typically cost precious time and are error prone, requiring rework if the wrong data is ex- or imported between tools.

Automating processes with multiple tools does away with these obstacles, leading to a more streamlined process. The requirement here is of course that the chosen automation solution allows data exchange between tools without compatibility issues. This might be either by staying inside one vendors comprehensive solution – or using an open automation system that allows data im- and export of various formats and across software solution from different vendors.

Summary

Engineering process automation isn't just about efficiency—it's about reclaiming the creative potential of your engineering teams. By identifying high-value automation opportunities, selecting the right tools, and nurturing the algorithmic mindset within your organization, you can transform repetitive tasks into streamlined workflows. The journey requires balancing technical considerations with organizational change management, but the rewards are substantial: faster iterations, fewer errors, and engineers focused on innovation rather than monotony.

As competitive pressures mount and talent grows scarce, automation isn't just a nice-to-have – it's becoming essential for engineering organizations that want to thrive. The question isn't whether to automate, but which processes to transform first.

Sources

1: https://resources.sw.siemens.com/en-US/e-book-smb-improve-engineering-productivity-with-plm-product-lifecycle-management/

2: https://www.colabsoftware.com/research/23-of-engineering-time-spent-on-non-value-added-work