A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.

Hanson Australia

Paul Hardy, Senior ABAP Developer

Enabling Next-Gen SAP Assistance

Paul Hardy

In the years leading up to the year 2000, my company identified a serious problem. In our industry— construction materials—there was little to differentiate us from our competitors. We all sold more or less the same product at competitive pricing, and since concrete has been made the same way since the days of the Roman Empire, there was limited scope for product innovation.

The one thing that we could compete on was customer service—and the radical new idea at the time was that this could be achieved using IT which at that point was generally considered just a means of automating the accounts department.

The result was that we implemented an ERP system (specifically SAP) in order to put “white space” between us and our competitors. The changes we wanted to make went far beyond just a system replacement.

The idea was that when the customer phoned up the central call center the system would recognize the number and even before the customer said “hello” the agent would be looking at a screen showing the customer details and their recent history with us for example open orders, contracts, and so forth.

Then if they wanted a delivery to the same place as before, all well and good otherwise a map popped up in front of the agent so they could geo-code the new delivery location. That is important as we interfaced SAP to a 3rd party scheduling system—with an in-memory database no less—which knew where all our trucks were and all our plants were and all our customers were and recalculated the plan for the rest of the day every 30 seconds.

It needed to be that often as we get a massive amount of order cancellations every day, as well as new orders coming in—so the plan at 6 AM will look very different to the plan at 8 AM.

One Thing To Note Is That When It Comes To The “Build Vs Buy” Decision Often We Chosen The “Build” Option To Build Up In-House Expertise And Not Be At The Mercy Of 3rd Party Suppliers

It did not stop there—we also had automatic interfaces to the concrete batch computers (so the butchers did not have to manually copy over information from SAP for every load) and to the weighbridges at quarries.

Moreover from the very start we took the approach that the standard SAP screens were far too complicated for use in a high-pressure environment—especially as a lot of the frontline staff were not used to computers—and thus built custom “veneers” so that whilst standard SAP was being used in the background what the user saw was a vastly simplified version.

Ironically what we were doing back then—playing with in-memory databases and simplified front ends—foreshadowed what SAP is doing right now with HANA and UI5.

All this was our starting position—it was what we went live within the year 2000. Naturally nothing works perfectly at first but it did not take that long to get everything working OK, and from then we had put the “white space” between us and our competitors, but we could not just sit back and relax—we have had to keep innovating as fast as possible ever since to maintain our lead.

A list of the innovations we have made in that 18 year period would fill this magazine. One thing to note is that when it comes to the “build vs buy” decision often we chosen the “build” option to build up in-house expertise and not be at the mercy of third-party suppliers when it comes to needing innovations or fixes in a hurry.

Two examples of such in-house developments would be a supplier invoice verification workflow—which made life vastly easier for both accounts payable and the field staff—and the dynamic concrete BOM (ingredients) determination which speeded order entry, saved us a large amount of money in regard to raw material costs yet at the same time resulted in a better quality product, one more tailored to the individual customer order.

I would like to end by mentioning one other thing that our IT organization does which may help explain why we have been so successful.

This is the idea of plant visits—where a programmer, a business analyst and a member of IT management go to visit a concrete plant or a quarry and ask them what is wrong with our IT system. Virtually every time we find one or two little things clearly wrong which are relatively easy to fix but would never have been reported as problems. Often the staff at the field do not even recognize there is a problem and have been happily doing something the hard way, unaware that a minor tweak to the system would mean it would no longer be hard at all.

In summary, our success has been based on having ambitious ideas, building software ourselves and most importantly never forgetting our customers.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.