The engineering sector is undergoing a rapid transformation thanks to the advances in software and technology. From automation and artificial intelligence to data analysis and digital workflows, software is enabling engineers to solve complex problems, improve efficiency, and deliver better outcomes for their clients.
However, adopting and implementing software solutions is not without its challenges. Engineers face various issues such as cost, compatibility, data quality, skill gaps, and trust.
Here are the highlights of an engineering and industry technology roundtable with representatives from six UK SME engineering firms.
Automation
One of the areas where software has made a significant impact is automation. Automation refers to the use of software to perform tasks that are repetitive, tedious, or time-consuming. Tasks like these are often found in areas of design, drafting, calculation, or documentation. Automation can save engineers a lot of time and effort, as well as reduce human errors and increase consistency.
When it comes to automation in the engineering (and surrounding) sectors we must recognise the multitude of products out there. SMEs with under 300 people can utilise over 100 different software products (many of which do similar things!) raising challenges including productivity, inefficiency, security, usability, management and ultimately client relations.
There is an increasing number of software solutions for engineering companies including design tools, CAD, 3D modelling, BIM software, drafting, analysis & design software. Some engineers are more proficient with some and less with others but the power of software is undeniable. It is challenging to keep up especially when working with new clients who require them to use their technology stack. Further, it can be hard for younger engineers using these tools to know whether they are using them correctly as they may lack the experience to know if the results are always accurate or not.
With this rising number of products/solutions used also comes the usual problem of a lack of interoperability and dataflow. Typing the same data many times into different systems is time consuming, human error through mistyping occurs, and there can be steep learning curves. Additionally, it can be hard for engineering companies to argue with big tech companies when items they believed to be part of the service are costly add-ons. There is real value to having technology/software experience in-house or through trusted partners. Speaking from experience CCQ has seen some unnecessary astronomical bills from large software vendors choking SME budgets highlighting the importance of knowing what services are required from Software-as-a-service (or any) technology solution providers.
Integrating products and automating tasks has huge benefits. The reduction in human error and efficiency gains directly impacts engineering firms’ profit margins. One attendee shared with the group that they had reduced aspects of design within temporary works from 5 hours to 8 minutes! by integrating products and automating common/mundane design tasks. Clients can get answers to important queries that same day cementing the key relationship and consistently providing a differentiator from (larger) competition.
Automation by leveraging APIs to connect disparate systems can be highly beneficial but sometimes require skillsets that SME engineering firms do not always have in-house.
Another example of automation from CCQ Tech’s own projects frees-up engineers’ time to perform necessary calculations without needing to be fully fledged software engineers. Reading large data streams (like LiDAR scans, radar or point cloud data) is difficult and hard to process into other file outputs. Generally, converting data from one format to another is time consuming when done manually and workarounds stifle productivity. By developing the software architecture to read these in, process them, stream them out to other files engineers can focus on the mathematics and their calculations to do what they need. By only focusing on the smaller scientific side of the coding and not the architecture side they have a lot more time on their hands. CCQ Tech’s managing director, Hugh Buxton says that clients can now focus on what they are best at and rid themselves of complications from a software development/architecture point of view.
Not just in engineering but in many verticals is the widespread use of spreadsheets. One attendee shared how engineers can be very proud of the work produced by spreadsheet or VBA applications but it can be wasted time if they are the only ones who know how they work! Also, a waste of time if engineers get too focused on the detail and not what needs to be done. For example, when design spreadsheets to support construction projects using screws when in reality onsite workers are likely to use Paslodes and nails!
Another attendee commented that coding in python can be easier to read and a step between pen & paper and excel spreadsheet where things get hidden.
Problem definitions
When it comes to Automation it is challenging to know what solutions are available and which are going to deliver those much-sought efficiencies that impact the bottom-line. One of the challenges here is sometimes the breakdown of communication between technical teams and software teams. It is not always easy for technical teams to describe what the problem definition is for the software teams to develop a solution.
This is where a real understanding of a company’s domain is crucial. In engineering, figuring out business requirements and mapping the business logic is complicated thus spending time to understand specifications and user-stories is vital to develop a product or adopt a software solution.
If software teams (internal or external) do not understand the nuances of a company’s domain, the solution (developed or adopted) may not be fit for purpose and a waste of money. A civil engineer in the room mentioned how they adopted a solution to serve a tier 1 rail client. The software vendor made assertations and promises but failed to deliver because they did not fully understand the details of the client’s domain requirements.
However, despite a lot of time spent in meetings and costs the company has now adopted the right solution. Sometimes you must go through pain to achieve what you need! Although if it’s possible to get right first time it often saves time and money.
CCQ Tech adopts a philosophy of ‘build fast, fail fast, learn fast’ to create rapid development and iteration cycles, building a more effective shared domain understanding early on, something software development teams often struggle with.
Discovery Projects and Proof of Concept projects
Often companies don’t know what they don’t know. They don’t know if a technology solution even exists for some of their problems and can be afraid to ask for quotes. Large numbers can be thrown at them forcing a return to doing what they know works. SMEs don’t have the budget of larger companies and cannot swallow high costs without first knowing that they will achieve a return on investment. Discovery projects or Proof of Concept projects can be ideal. CCQ Tech suggest by starting small with a low-cost discovery project (technical discovery or business discovery) to identify quick wins, get something in place rapidly to introduce the concept and expanding on the idea. People can quickly see the gains and benefits. A defined starting point where a company can be open-minded and explore what is possible given the specific problems, people, and tech stack.
Artificial intelligence, Chat GPT, Large Language Models
There is much hype on this subject across the globe and, I think, the conversation found a balance between excitement, caution, and experimentation.
Many of the directors in attendance had been to conferences on the subject be it in offshore wind, energy, tunnelling, or civil engineering. All were astonished by what AI is being touted as capable of and how it will transform industries. In one example a junior engineer in an hour used BingAI to produce two pages of project calculations and designs that took days to produce by the team using traditional methods. In engineering you must get things right first time or risk danger to live so companies cannot yet fully rely on AI produced designs. But the results in a small amount of time were shockingly close to the actual designs produced which was encouraging.
A great question arose “Can we design AI tools or LLMs to be modelled on our internal data only?Our data is as old as the business and is much more reliable and accurate than most sources found on the internet.”
With LLM it is important to know while they create detailed and useful information, they make mistakes like humans, and a key element (even after months of playing around) is knowing what questions to ask. LLM must be trained on multiple data sets for reference. The data for original GPT3 was up to 2019 and the newer versions on a dataset up to 2021. An agent (a program that interfaces with a LLM) needs to sit on top of LLM. Specifying how we want it to speak to us is important. The reason many capable AIs are monopolised by large companies, like OpenAI, is because it is very costly to train AIs and create the necessary datasets. The solution isn’t necessarily building your own model it is using the right agent and feed it your information/data. These engines are complicated, and the application is hard to get right. The advantage of these LLMs is they can take in anything human readable. We suggest to structure the data that is fed like a tagging system, PDFs or raw text files.
When discussing other real world engineering application of AI, we discussed 3D scans from say tunnelling. With large volumes of data rather than engineers manually reviewing data we can replace with AI and smart algorithms to process all data (much of which humans would gloss over anyway) and highlight areas discovered in photograms or other images (like LiDAR) for example and suggest areas humans should specifically review. CCQ Tech have been developing on the cutting edge recently, building technologies to feed multiple synced data-streams to AIs.
Another example is offshore wind where there are huge volumes of data that needs processing but many of the big companies are not willing to invest until they know there is a return. So is it possible to use AI to help capture, and interpret data and generate the business case for investment? Also, when it comes to disagreements and insurance claims it is difficult to attain the relevant information so can AI help here too?
As with all emerging technology that are a lot of gaps and unknowns however, no one can argue that AI isn’t a game changer whose application needs sensible thought and understanding to implement effective strategies for SMEs or corporates to reap the reward.
Conclusion
Software and things like AI are transforming the engineering sector in many ways. Software can help engineers to automate tasks, analyse data, optimise solutions, and generate new ideas. Software can also help engineers to customise their products, improve their compatibility, and create new solutions all of which are affordable and accessible to SMEs. However, there various challenges for engineers, such as cost, compatibility, data quality, skill gaps, and trust. Engineers need to be aware of the opportunities and obstacles that software presents, as well as the best practices and strategies to adopt and implement software solutions effectively.
By investing a small amount of time and money into Discovery or POC projects the SME can better understand the variety of technology options available, their costs and capabilities. They can then build the business case for larger, more widespread software/technology/automation solutions they know with a high degree of confidence will improve efficiency, create happier clients, and increase profit margins.
CCQ Tech extend our gratitude to our attendees who gave us their time and shared valuable insights. Stephen Sidgwick, Andrew Blackie, Luca Montalti, Jordan Lance, Fabrizio Fortunato, Sebastian Kumpfmueller