Home

Advent of Technology in a Construction Industry

Paul Hardy, Senior ABAP Developer, Hanson Australia

I work in Australia for a company that supplies building materials (e.g., concrete/aggregates etc.) to companies that construct roads, buildings, and so on (hereafter “customers”).

At the start of 2022, my job title was changed from “Programmer” to “Programmer / Integration Specialist”. At first, I wondered about that, but it turned out I spent the whole year working on integration projects—linking our ERP system with customers' IT systems.

Thus, I would like to revisit the problem such projects are supposed to address, how technology is supposed to solve that problem, and the past, present, and future of such initiatives in the Australian construction industry.

A Growing Concern: Manual Typing

Manually typing the same information into several different computer systems (the customer and supplier systems) wastes time, and there is a very high risk the information will be different in each system.

If that information does not match, there will be problems at invoice time, costing both parties (accounts receivable for the supplier and accounts payable for the customer) a vast amount of time and money.

Synchronised Information making the Task Easier

To avoid that problem the following information needs to be synchronised between the two parties:

● Purchase orders in the customer system with sales orders in the supplier system

● What happens on site (goods receipt in the customer system / deliveries in the supplier system)

If this happens, both parties win.

The nature of the problem never changes, but how to solve it changes over time based on a mixture of the advance of technology, how easy it is to use that technology, and the strength of the desire of both parties to use that technology. There is a huge difference between having the technology and wanting to use it.

The technical solution tends to evolve as follows:

1. Everything is manual—mailing paper documents, phone calls, etc.

2. A periodic exchange of spreadsheet data

3. Real time data exchange, in a web of different point to point solutions between each supplier and customer

4. Real time data exchange, via some form of “hub” so each customer and supplier only must connect to a single place using a standardized API

Past, Present and Future

I am told that in the 1980s in the U.K., an agreement was reached between all the major concrete and cement companies to stop sending paper invoices to each other and instead send spreadsheets. In those days, neither Excel nor email existed, so any such exchange would have involved physically mailing floppy disks containing Lotus 1-2-3 spreadsheets. But the idea was there.

As time went on and real EDI became technically possible, you would have expected some sort of set of EDI standards to evolve. Indeed, they did—lots of different ones. One of my boss’ favorite sayings is “the good thing about standards is that there are so many to choose from."

In 2000, when I arrived to work in Australia, one of the first things that I read about in the news was an online hub for the construction industry whereby everyone could send purchase orders, invoices etc. to each other electronically. One of the founding members was a major player in the concrete industry.

I thought -that makes so much sense, in no time the entire construction industry in Australia will be signed up. That never happened. That hub vanished into the mists of history.

Jump forward to March 2016, and one of our big customers was building a bunch of new train stations in Sydney. They wanted to import data – we would automatically email them spreadsheets each night so they could check if what was in our system matched what was in theirs. I wrote that program and tried to make it as generic as possible.

In December 2016, another customer was building a bunch of new motorways in Sydney. That project is still going as I write. They wanted the same thing as the previous customer, plus they wanted us to export data—extract a spreadsheet of their purchase orders from their system every day and upload that spreadsheet into our system to create sales orders. Again, I tried to make the new program as generic as possible.

We had reached the point where we were exchanging spreadsheet data on a regular basis.

In 2022, demand for B2B suddenly shot up. One possible cause is the Australian Government mandating that all government departments have e-invoicing in place by June 1, 2022, and the private sector must start doing this as well by June 1, 2023.

We had B2B requests from about ten customers, and most of them wanted data exchanged in real time. All of them have totally different systems with totally different data structures. We have managed to abstract what data is sent/received (which is always the same) from the customer data structures, plus how they like to receive data technically (which is always different).

There are already several IT system vendors all trying to capture the construction B2B market – each such vendor has signed up several of our customers, so we have built point-to-point connections to each of those vendors' disparate systems.

Now we are at a web of point-to-point connections

Going forward I am recently seeing an interest from our customers in a generic solution for every new project, rather than a new point-to-point solution each time.

Everybody—suppliers and customers – is looking for an industry standard in this area. In the worst case, that would make point-to-point solutions easier, in the best case, it would enable the ever-elusive hub solution.

Now I am not holding my breath waiting for such a standard, but at least things seem to be moving in the right direction.

After many false starts, it seems that at the start of 2023 the Australian construction industry is at an “inflection point” when it comes to B2B, so I have high hopes for the future.