How Contractor Executives Can Plan for Construction Software Interoperability

What do construction executives and technology selection teams need to know about integrations between construction software products?

4d4dc0b9

When a construction contractor invests in technology to help them grow, increase margin or perform more with less, they have to think ahead about how that software will communicate with other technology inside their contracting business and with their project partners up and down the value chain.

The design sector—architects and engineers—are further along than the contractors that produce the value on site. Project design will now often be delivered in the form of a building information modeling (BIM) file, which aligns with a format from the Industry Foundation Classes (IFC) CAD data exchange schema. BIM applications used in design may generate a proprietary or open file that orients project design data around 3-dimensional space and construction processes. More elaborate BIM applications may also capture project cost data, environmental performance data or data used to support the maintenance or facilities management process over the lifecycle of the built asset.

The ISO 19650 standard provides a further platform for open BIM, making BIM model data at least somewhat consistently interoperable.

Once design data crosses the chasm to contractors who need to produce the value outlined, standardization and interoperability fall off. Within a single contracting business, estimating software, product management software, procurement software and other technology classes used by a contractor will have different data structures and formats from each other. On top of this, the project will usually be executed by more than one contractor in a collaborative environment, each of them using different software products with their own data structures and proprietary barriers. Digital workflows should be able to cross over this inter-company technology membrane quickly and easily. But it does not happen without due diligence, forethought and planning by construction executives and the team charged with identifying prospective technologies for the business.

With a thoughtful software selection process that encompasses the future direction of the contracting business and the vendor, a contractor can:

  • Run several or more software products inside their business that hand business processes over from one stage of the contract to another—estimating, scheduling, subcontracting, project management, logistics, equipment operation, change orders and application for payment
  • Participate in or facilitate collaborative digital workflows with project partners as processes and data pass between the general contractor, subcontractors, the owner and even materials or equipment suppliers
  • Create or contribute to a digital twin of the asset, where each physical feature in the project has a corresponding digital data set containing the full universe of data on how the building was designed, constructed, by who and when using what equipment, materials, mechanical systems and components down to serial traceability and any lifecycle maintenance or asset management guidance

How can a contractor maximize these types of interoperability? Here are four critical modalities that help deliver construction software interoperability.

1.      Standard construction software integrations unfold over time.

Commercial software products for construction should have standard integrations with other products used by the software vendor’s customer base. But a list of integration partners is only so valuable because the utility, performance and usefulness of integrations vary widely.

A case in point is Kojo, a leading provider of procurement management software for construction contractors, has built tight integrations with enterprise resource planning (ERP) software products used in construction.

  • Integrations with Trimble Viewpoint Vista and Trimble Viewpoint Spectrum drive purchase order data into these systems of record to eliminate duplicate entry.
  • The Sage 100 Contractor and Sage 300 CRE integrations synchronize vendor, job, phase code, job cost category, tax code, general ledger code and purchase order/commitment fields.
  • Kojo’s integration with QuickBooks Desktop updates QuickBooks vendor, job, item, class and purchase order fields while the integration with Quickbooks Online updates vendor, customer, item, tax code and purchase order fields.
  • Within Procore, Kojo’s integration updates project, vendor, cost type, cost code, commitment and schedule of values fields.
  • Kojo’s integration with ComputerEase synchs with the job, phase, category, tax code, vendor and purchase order fields in ComputerEase.
  • Within Coins, a Kojo integration writes to the vendor, job, cost code, tax rate and purchase order fields.

In July of 2022, Kojo announced an initial integration with Autodesk Construction Cloud. In a briefing with Kojo CEO Maria Rioumine, IRONPROS learned that this integration is a different beast from the company’s existing integrations with purchasing.

“Using this integration, mutual customers of Kojo and Autodesk can add a partner card into their Autodesk Construction Cloud dashboard,” Rioumine said. “What this means is that they will be able to access their Kojo environment directly from Autodesk. In other words, the Partner Card acts as an embedded experience straight from their Autodesk Build Insight or BIM360 Project Home Dashboard. Because the construction management process is so fragmented and disjointed, there is a huge risk of mistakes and miscommunications between teams. What integrating with Autodesk Construction Cloud is enabling customers to do is access their procurement and materials insight right from their main construction management platform.”

One way to think about the difference between Kojo’s Autodesk integration and their existing integrations is to see the Autodesk integration as a window to let you see from one system to the other, whereas their other integrations are a door data can pass though. And it is not uncommon in the sector to see two entities starting small with integrations—StructionSite launched a similar integration for bidirectional visibility with Latium’s Job Site Insights Smart Construction platform.

According to Ryvit Vice President of Business Development Greg Mattes, this is par for the course.

“An integration can start very simple,” Mattes said. “Sometimes it is just a connection between one system and another system. In the construction space, you have for instance an integration between Procore and an ERP and accounting product like Viewpoint Vista. Sometimes it can be moving a single field between those two systems. But these really simple integration profiles can provide some amount of automation for a shared business process.”

And getting to that rudimentary point still requires a good deal of planning because the two software products require a shared framework and permissions to access data in the other.

“Even before moving that one field, there is the matter of establishing some sort of connection,” Mattes said. “That enables one system to communicate with another system and understand what credentials need to be used. It would depend on the use case. Maybe there is a use case where I would want to be able to see what is happening in this system so I can do double entry in this other system. It makes these tasks simpler. Real value is true interoperability.”

One example of an integration enabling deep interoperability may be when a human resources software product is integrated with a construction ERP or accounting product to enable a contractor to move employee data the HR package to ERP where it is used for payroll and tracking employees, their credentials, and how they are assigned to specific projects or job tickets.

A next step would be a bidirectional integration that pulls payroll data back into the HR package so employees can see their pay stubs without logging into the ERP software.

Determining exactly how deep an integration between two software products in fact can be tricky.

“There are some challenges around the terminology around integration," Mattes said. “Some people use terms like connections or integration or automation. I think when they start using terms like automated data flow, that perks my ears up. Data is moving between one system and another, and vice versa. That is true system integration and true interoperability

Mattes suggests contractors ask vendors touting integrations first of all whether the integration amounts to a simple interface, or whether data is flowing in a unidirectional fashion or bidirectionally. Also, it can be important to determine what data is being moved including:

  • Employee
  • Budget
  • Submittals
  • RFIs
  • Cost
  • Safety
  • Equipment
  • Change Orders
  • Potential Change Orders

Also important is ensuring that the integration does not require manual processes to upload data and whether it happens in real time or near-real time or is a periodic batch update.

TAKEAWAY: The lesson here is that integrations between software products are not one-and-done events. They are like relationships that unfold and grow over time based on customer demand and mutual investments. Knowing where two vendors are in their relationship towards deeper integration will be critical in contractors selecting software for interoperability.

2.      More modern software integrates more easily.

Modern software integrations are facilitated by application programming interfaces or APIs, including RESTful (short for Representational State Transfer) APIs that contain deeper information on each field and the nature of the data to make integrations easier and more straightforward. Contractors will need to find a balance between their commitment to mature software products they have used for many years and ease of integration. These legacy products may need to have APIs opened up with help from external vendors. Modern software meanwhile will have standard APIs that expose a number of parts of the product at likely integration points, and the most advanced solutions are API-first and may use the same APIs exposed for integrations as they use to facilitate processes within the solution. One such product is Billy, a construction insurance platform that tracks and manages insurance certifications for subcontractors.

“Currently, we are targeting our first integration with Procore in Q2 of this year,” Billy CEO Nyasha-Harmony Gutsa said. “A lot of builders that are out there wanting to keep Procore as the system of record for their project data. However, the insurance side of things needs to transition from reactive to proactive approach. Billy automates and digitizes that process.”

As an API-first company, Billy developed the API and built the rest of the platform around it.

“The reason we built the software that way is to make it easier to build a mobile app because everything is an API or connected to other systems that way,” Gutsa said.

In general, software provisioned in the cloud will be easier to integrate with than software that is on premise. A legacy solution that had been designed to run on premise may also require work by an organization like Ryvit or HH2 to create APIs that can be accessed by one or more different applications. And software application suites that have been assembled by acquisition of multiple products must be integrated with each other to deliver cohesive process flow. The quality and flexibility of these integrations and the extent to which the different acquired products work together and how easily they can integrate with external software products from other vendors.

In a recent IRONPROS product deep dive, Trimble Vice President of Product Development at Viewpoint Dan Farner described the work his company is doing to unite the various products that make up the Trimble Construction One suite, which is comprised of a broad assortment of applications including the multiple products that Viewpoint acquired prior to its own acquisition by Trimble.

Integrating the former Vista and Spectrum products with external applications, both within and without the Trimble portfolio, can be done now. But Farner said the company is making significant investments not only in API libraries that will enable integration, but in re-architecting the underlying data structures of the various products so they have more in common. This in turn will make integrations more agile and robust. It will also help make it easier, more transparent and more desirable to integrate Trimble Construction One applications with each other rather than with products from third parties.

“There are places where it will be important to have some common data models—but this is really actually hard,” Farner said. “This will help with the integration activities and application interoperability because each application knows where the data is coming from and where it needs to go.”

TAKEAWAY: Construction software that has been on the market for a decade or more may be functionally rich, but newer products built around or with substantial thought given to an API strategy will present more graceful, cost-effective and flexible integration profiles. Contractors considering subscribing to or implementing more venerable, proven software may want to do extra due diligence on the vendor’s integration strategy and the depth of current and planned standard integrations. An older software product may receive less research and development resources than a more current one, but most of the dollars they do receive may go to standing up new integrations. A contractor may want to consider the trade-off between paying for net new standard integrations and paying for a growing set of functionalities.

3.      Low-code-no-code tools democratize integrations.

Process automation and even simple interfaces between software products often involve systems integration work to create a standard integration or are one-off projects that require a professional services project. There are, however, technology tools and construction enterprise software products that enable end user companies to create their own integrations using low-code, no-code tools. Without writing code or a technical background, a business analyst or other user knowledgeable of business processes can develop their own integrations without writing code.

One obvious use case for this approach is business analytics, and construction business analytics vendor Briq includes no-code integration creation tools enabling data from disparate datasets like project management systems, ERP software, time clocks, CRM and pipeline management software and accounts payable/accounts receivable applications to be easily aggregated. But this still requires an analyst layer in the company who can conceive of ways to mash up data together to solve specific problems. The low-code approach is an obvious win for middle-market or smaller contractors with fewer technical resources but is still appealing to larger concerns as well.

“In some of our larger general contractor customers, there is a data analyst or data science team,” Briq CEO Bassem Hamdy is quoted in an IRONPROS Product Deep Dive. “If this is the case, they still gain value because we empower their IT team to not have to build these integrations. Or we empower our customers with help from our own internal data analysts to help them get the most out of the platform.”

But most customers opt for a self-service approach, setting up their own processes to pull the data from various sources. Customers have gained enough data agility using the no-code integration features in Briq that they according to Hamdy have been able to move off an integration platform as a service (IPaaS) applications from Dell Boomi. Other customers abandoned internal projects built in Apache or standard products from Alterix.

Stream the IRONPROS Product Snapshot video on Quickbase for deeper insights into how this no-code platform can assist with construction software interoperability.

Quickbase, meanwhile, is a stand-alone application that enables not only integrations but development of full-blown business applications in a no-code environment, using a straightforward visual interface. In an IRONPROS Product Snapshot video, we see firsthand how Quickbase can be used to orchestrate processes across various software products.

Meanwhile, major ERP products like Oracle Cloud ERP have adjacent technologies that facilitate integration, but customers will still often want to rely on the guidance and professional services of an Oracle systems integrator, who with a low-code tool can complete an integration more expediently than without.

“As an Oracle systems integrator and independent software vendor, we always ask what is that larger ecosystem of applications a customer needs to run as well,” Inoapps Sales Director Thomas McAdams said. “They might use CMiC for key projects—and using Oracle Open Integration, also on the analytics side. They often have proprietary approaches to information that comprise a lot of their special sauce of how they estimate out these projects and try to win the work. Some have specifically built estimating tools that consume historical information. But the way they are building those estimates is how they win the business. But with Oracle Integration Cloud, we have not yet found a situation where we can’t solve an integration. If the customer has an older solution, like Procore for project control—you can take an adapter, do some clipper mapping, and make it work. You may have to work with them to get that information out.”

Because many contractors lack the analyst role in their business, or much in the way of middle management in general, even Quickbase users can benefit from third party consultants to help them get the most out of the platform.

Takeaway: Contractors do have access to technologies that can simplify integrations, but at best, these tools only take the coding out of the process. In order to structure a good integration, a contractor must have some type of analyst or other informed business technology or process role in the company who can understand how the integration should function in the business and what data is appropriate to integration at what point in a process. In some cases, a contractor may want to bring on an external consultant who, using the no-code tool, can create an integration more rapidly than could be possible without one.

4.      Construction software is integrated with materials and service vendors for in-app purchases.

Just as Kojo exposes supplier information to support the purchasing function, modern estimating software will often be pre-integrated with materials and product databases that populate and roll it up into the total project cost. The integration itself drives value, but much of the value is the result of the work put in by software vendor personnel and vendors that populate and share pricing data that in turn helps contractors specify their products and then include their products in projects. Estimating software serves as a distribution channel for materials and components, and this business model is coming to other back-office functions. Many of these use cases focus on finance and lending, including gap finance to make up for slow application for payment, project finance, small business lending and even legal services to help with collection efforts.

Finance support can come in the form of interoperability with external fintech companies’ transactional systems. In the case of software products from a number of companies, a credit card can be linked directly to the accounts payable functionality in software to help capture and automatically classify expenses, eliminating non-value-added administrative work. In the case of companies that serve very small contractors like Jobber or WorkWave, these credit cards can become essential tools to help an entrepreneur separate their business credit from their personal line of credit. In fleet management software, these credit cards can simplify ongoing expenditures made by drivers. Fleetio, for instance, has a new integration with WEX | EFS fuel cards. The integration:

  • Automatically imports fuel transactions to Fleetio within five minutes of the transaction
  • Quickly identifies potential fuel theft in real time when a fuel transaction exceeds tank capacity, or the vehicle is outside a specified vendor radius
  • Simplifies reporting on fuel efficiency/ cost-per-mile; analyze fuel by vehicle, location, vehicle type, time frame
  • Streamlines IFTA reporting using Fleetio's Fuel Summary Location Report
  • Improves overall reporting by accurately determining total cost of ownership

Despite the five-minute lag between the transaction and its appearance in Fleetio, the integration is still pretty quick, and this speed will drive value in other areas of the business according to Fleetio Head of Product Management Michael Harrison.

“The amount of time decided on to reduce how often we made the API calls is within five minutes,” Harrison said. “The transactions will often come in before five minutes, which is faster than the industry average for connecting and downloading transactions for fuel data. This integration also leverages other functionalities that already exist, such as Fleetio’s fuel exception alerting. While this functionality is not EFS specific, EFS still benefits from it. The biggest functionality improvement is the speed at which the transactions come into Fleetio, allowing fleet managers to take action on their fuel data faster. With the rising costs of fuel impacting a fleet's budget, having the necessary data for reporting and analyzing is extremely important when evaluating expenses.”

Fleetio also supports integrations with other fuel card companies including Comdata and Fleetcor.

Takeaway: Finance companies are vendors and suppliers just as surely as companies that provide parts, components and materials used in projects. Integrations with fintech can not only eliminate non-value-added administrative work, but can make a contractor more resilient and capable of succeeding in the market.

Contractors must get smart about integrations

Across industries, the idea of using a single enterprise software product to run the entire business, was never entirely realistic. And in construction, integration of multiple systems not just within the contracting business but among trading partners is even more important than it is in other industries. These simple ideas will hopefully allow you to ask more probing questions of construction software and technology vendors so you can harness those vendors’ products to deliver true interoperability across your organization and projects.

Page 1 of 6
Next Page