Implementing commercial information exchange: a construction supply chain case study

Abstract

The concept of electronic trading (e-trading) has transformed supply chain interactions in many industries, yet little research explored its implementation by Architecture, Engineering and Construction (AEC) supply chain firms. E-trading relies on commercial information exchange by supply chain partners which is generally adopted through intermediary technology partners (Hub Providers) to facilitate the accurate and timely communication of transactional data between buyers and supplier. A case study was conducted to explore the challenges and barriers to implementation of cross-firm commercial information exchange. The study primarily involved investigation of the interfaces between software development and organizational functions assisting with the electronic exchange of commercial information (eCIX) implementation. Findings from the case study show that implementation of commercial information exchange is not an easy task with several themes of factors to be considered during delivery of such projects, namely technical, coordination, integration and organizational. The study contributes to the knowledge and deployment of e-trading solutions within the context of AEC firms, and should be of interest to the practitioners contemplating similar projects.

Keywords:

• Case study
• commercial information exchange
• electronic data interchange
• e-trading
• implementation

Introduction

In an attempt to streamline their procurement processes, many contractor firms (CF) are considering tighter integrative practices with their key supply chain partners which represent as much as 75% of the cost of the construction projects (Harris, 2013). One of the solutions that enable streamlined and synchronous commercial interaction is the Business-to-Business (B2B) electronic trading (e-trading). The purpose of B2B e-trading is to enhance the existing relationships through transformation and integration of the inter-firm commercial processes (Gunasekaran and Ngai, 2004). In broad terms, the central role of B2B e-trading solutions is to facilitate the buying and selling aspect of the business interaction.

In order to effectively implement e-trading, trading partners need to embrace an integrated approach whereby systems and technologies used for e-trading purposes are interlinked with the companies’ back-end Enterprise Resource Planning or ERP systems (Dai and Kauffman, 2002). However many of the current e-trading systems used by the industry firms lack an integrated approach to exchange of commercial information generated during the procurement and supply of materials, equipment, goods and services (e.g. purchase orders, quotations, requisitions, invoice, delivery notes, catalogues and many other documents part of the procurement process) (Cole, 2008). Consequently, there are silos of information residing in different systems which not only leads to inefficiencies and waste in storage, processing and management of data, but also results in increased transaction costs for both buyers and suppliers. Through streamlining of the commercial processes and automation of the transactional information between the back-end systems (for example, automation of highly repetitive and voluminous purchasing activities) CFs would not only achieve time and cost savings in administration of the purchasing process, but also benefit from less or no paperwork, improved purchasing lead time, and reduced inventory (CITB, 2006; E-Business W@tch, 2006).

Prior literature provides little information on e-trading systems implementation which involves electronic exchange of commercial information between the backend ERP systems. A number of studies investigated implementation of ERP systems by construction organizations (Shi and Halpin, 2003; Voordijk et al., 2003; Yang et al., 2007; Acikalin et al., 2008; Chung et al., 2008) however the scope and focus of these studies has been on intra-firm ERP applications rather than cross-firm application integration. Cole (2008) discussed the Electronic Data Interchange implementation which is one of the ways to achieve end-to-end integration. He gave several examples of issues with integration however the findings are largely based on his personal experiences with electronic data exchange hubs. Other studies have focused on the e-readiness of organizations where key factors related to people, process and technology dimension of implementing new and innovative technologies have been addressed (Goulding and Lou, 2013). However, e-readiness dimension only provides a strategic overview of the issues and challenges that enable or hinder technology implementation projects, and falls short of addressing the variety of issues that crop up during the actual deployment phase.

Against this background, the premise of the article presented here is to contribute to the understanding of e-trading systems implementation, with specific reference to the end-to-end commercial information exchange by Architecture, Engineering and Construction (AEC) supply chain firms. The objective of the study is to investigate the challenges and barriers that surface during deployment phase of the implementation. The research adopts a case study approach to investigate a real-life project between a large contractor organization and ten of its key trading partners through a third-party e-trading solution provider. Commercial information is defined as data that has transactional detail relating to the sale of materials, equipment, goods and services, and electronic exchange of commercial information (eCIX) is considered as one of the central tenets of the e-trading concept.

The remainder of the paper is arranged as follows. First, an introduction to technologies that facilitate e-trading is provided. The methods by which end-to-end integration is conducted are discussed in the following section to provide a background into implementation of eCIX projects. The research methodology is introduced next, followed by a detailed insight into the case study context. The findings of each integration case are presented next. The challenges and barriers experienced across each integration project are collectively grouped under four headings and lessons learned from the case study are drawn out in the next section. The article ends with a brief summary of the study, as well as pointing to the limitations of the current research and opportunities for future research.

Electronic trading technologies in the AEC industry

The concept of electronic trading is rooted in the idea of e-business which is commonly defined as electronic conduct of business operations (Chaffey, 2009). According to Gartner Group (2016), a research and advisory firm, e-business is a process rather than an absolute state of company. The principle aim in its implementation is to streamline the business processes, improve productivity and increase efficiencies (Bocij et al., 2008). The e-trading phenomenon is based on the same principle; however it is much narrow in the sense that it is primarily concerned with B2B commercial exchange over computerized networks, in particular Internet and web-technologies. This definition should not be confused with another commonly used term in the literature; e-Procurement, which its boundaries stretch beyond the commercial exchange to embrace other associated (intra-firm and inter-firm) procurement activities, including identification of need, negotiation, contracting and settlement (Grilo and Jardim-Goncalves, 2011). Thus, being a narrow scope than e-Procurement, e-trading is described as web-based technologies that facilitate the B2B commercial exchange between a buyer and supplier.

Driven by the advancements in internet, connectivity and web-services, the technological solutions for e-trading have evolved significantly over the years from stand-alone Electronic Data Interchange (EDI) applications to much more sophisticated, multi-functional and multi-purpose technologies. In examination of the literature on digital technologies used in procurement of construction projects Ibem and Laryea (2014) distinguish the latter type as ‘intelligent systems’ which are largely web-based information systems used for communication, collaboration, integration and coordination needs at different stages of construction procurement activities. A prominent example of the e-trading technology used by the AEC supply chains includes Web-based Project Management Systems (WPMS) (Nitithamyong and Skibniewski, 2004). In addition to their core functionality of project documentation and drawing management, and collaboration, WPMS can also facilitate the systematic sourcing; which typically include organization, planning and management of tenders and contracts) of production-related materials, goods and services (Nitithamyong and Skibniewski, 2004). However, Ren et al. (2008) argue that a major limitation of the WPMS is that they are primarily designed to facilitate the business and workflow processes for strategic sourcing needs of firms (or projects) rather than support the inter-firm operational activities related to buying and selling.

Another type of e-trading technology is the e-Marketplace systems which are primarily used to facilitate the organizational exchange of information, goods, services and payments between the buyers and suppliers (Standing et al., 2006). Whilst there is a lot of confusion over their roles and functions, extant literature often distinguish e-Marketplace systems on the basis of the ownership model. Accordingly, there are three main types of e-Marketplace systems where each offers a variety of different value propositions to participating firms (Dai and Kauffman, 2002; Balocco et al., 2010).

•	Public e-Marketplace systems are centralized portals for procurement of direct and indirect supplies for public projects, for example, CompeteFor1 originally developed for the 2012 London Olympic Project and used by public authorities to publish contract opportunities for subcontractors and suppliers.
•	Independent e-Marketplace systems are privately owned marketplaces which concentrate on bringing as many buyers and suppliers together with an aim to generate business transaction. To give a few examples; RS2 is an intermediary marketplace for sale of various electrical, mechanical and IT products and services. In addition, there are various material/product specification directories primarily used by architects, engineers and facilities managers such as ESI.info3, BuildingDesign4 and Barbour5; however the use of these marketplace systems does not generally extend beyond product information sharing.
•	Private e-Marketplace systems are governed by the hierarchal structure in the relationship where one of the parties (usually a buyer firm) invites its portfolio of supply chain firms to conduct a full procure-to-pay business transaction via an intermediary technological solution provider. The e-Marketplace system is generally outsourced to an intermediary Exchange Service Provider whose scope of the functionalities offered may extend beyond the transactional exchange to value-creating interactions (such as collaboration, collaborative forecasting and replenishment, logistics and so on) (Wang and Archer, 2007).

More recently the ubiquitous drive towards adoption of Building Information Modelling (BIM) has put Cloud-based Software-As-a-Service at the forefront for sharing, collaboration and coordination of information-rich 3D model files in a vendor neutral ‘Common Data Environment’ (Succar, 2009). Developments in this particular field are fast-changing and recently a number of authors either proposed (Ren et al., 2012) or reported on the development of the work that is underway to initiate e-trading activities directly through the Cloud-based BIM models (Grilo and Jardim-Goncalves, 2011; Costa and Grilo, 2015). However, as also acknowledged by these authors, lack of standardization of procurement processes and problems with interoperability of product data presents a complex challenge for collaborative and transactional processes across BIM models and e-Marketplace systems. Hence, presently the Cloud-based BIM models fall short of its potential to be effectively utilized for e-trading purposes.

Implementation of commercial information exchange by AEC firms

In addition to streamlining the cross-organizational commercial activities, a vital ingredient of e-trading is the alignment of trading parties’ back-end ERP systems (Dai and Kauffman, 2002). Most often the above-mentioned systems work in isolated fashion where parties to trade have to reprocess the information manually in their back-end systems, leading to loss, distortion, and duplication of data across systems. A fully integrated e-trading system supports inter-operation of data through electronic exchange of commercial information (eCIX) where different types of transactional information (including, but not limited to, product and pricing information, order, delivery and invoice data) is exchanged seamlessly amongst businesses and their back-end ERP systems.

There are multiple ways to implement eCIX with suppliers. EDI can be considered as the simplest form where two firms link their legacy systems to communicate, share or exchange business documents such as order and invoice data. Typically, EDI messages contain highly structured product, order, or invoice data which is exchanged over a communications network. However in order for EDI to work, both organizations (sender and receiver) must agree to a common standard on syntactic (data format), structural (description of how the data will be structured), and semantic (definition of content of data) dimensions of interchange. Implementation of EDI can be direct (i.e. B2B) or by Value Added Network (VAN) providers who intermediates the connection, translation and transition of the transactional messages. Despite its long history, reported usage of EDI is scanty within the AEC industry (Lu et al., 2014), with builder’s merchants and CFs being the most notable users (Samuelson and Björk, 2013). Kong et al. (2004) reasoned the initial cost of set-up and complexity of standards for the low levels of adoption whilst Lewis (1998) concluded that lack of clear business case with little apparent benefits from its application, deferred AEC firms’ decision to invest in the technology.

Other approaches to eCIX include using platform independent common data formats, most notably the eXtensible Markup Language (XML) document types which is considered to be the lingua franca to data exchange between different software solutions. Similar to EDI, implementation of XML-based eCIX heavily relies on existing frameworks to standardize the syntactic, structural and semantic representation of the data. Although there are several open-source and proprietary XML-based frameworks available, for example, aecXML,⁶ agcXML,⁷ bcXML⁸ and eBuildXML⁹ (where the scope of the business activities covered varies in each framework) their adoption and utilization by the AEC firms are not well known.

In addition to the XML-based messages, the Industry Foundation Classes (IFC) and STEP file formats (which are primarily used in design and construction stages of a project) allow embedding of the building specification data within its content (Shen et al. 2010). Ren et al. (2012) explain that the information stored in these files maybe part of the 3D model file which contain additional intelligent data about the 3D building objects and elements, or separate from the model file itself. However, since their application aimed primarily for the design, construction and ex-post processes in a project’s life cycle, the use of the IFC and STEP file types for the transactional exchange is currently limited to cost information sharing: for example, data from an IFC can be exported into CIS/2 exchange standard for cost analysis of structural steel (BuildingSmart, 2015).

Besides the data exchange standards and formats, another important consideration in eCIX implementation is the construction product catalogues (CPC) which contain the necessary information about the details of the transaction (for example item description, specification, price, unit, quantity and so on). The mechanisms adopted for exchange of CPC information can be either file-based (e.g. PDF or spreadsheet document) or through establishing inter-connection with a web-based supplier hosted catalogue (through services such as PunchOut or RoundTrip interface). The prime issue related to CPC is the management of product information data, in particular the categorization and classification of the goods/services where many firms utilize a customized and bespoke product code, description and specification (CITB, 2006).

One of the biggest challenges in inter-connecting the back-end systems relate to the compatibility of the existing ERP modules and applications. The back-end ERP systems used by supply chain firms are often configured and customized to the specific needs of firms which make integration with external systems a complex activity; especially when implementation involves multiple supply chain partners (Cheng et al., 2010). This results in significant amount of efforts to be spent on mapping, transformation, and translation of data (Samtani, 2002). In addition, the capability of the existing systems to connect and exchange data with external systems also presents a big issue during implementation. The existing legacy systems that are used to store, process, and manage commercial information may lack the functionality to automate real-time exchange of information. In such cases a messaging layer or middleware provider may be required to help with the connectivity before integrating with external systems (Samtani, 2002).

Given that an e-trading system supported by eCIX requires a complex technological infrastructure, firms can choose to outsource the development activity to third-party service providers known as Hub Providers (HP) (Dai and Kauffman, 2002). Many HPs act as mediators who are responsible for facilitating the cross-organizational commercial processes as well as translation, conversion and communication of transactional data between the back-end systems of the trading parties (Samtani, 2002). They not only support all open data exchange standards, but are also capable of handling data validation and business rules for a highly accurate data exchange (Cole, 2008). Some of the essential components of HPs include (Samtani, 2002): (i) a connection layer through which transactional messages can be communicated with the back-end systems (e.g. EDI, http, ftp, sftp and email); (ii) services layer which enable range of capabilities and functionalities such as supplier directory, purchasing and order management, product search and so on, and; (iii) presentation layer, which provides a web-based front-end interface where users can view and interact with the system.

Methodology

The eCIX implementation project requires support from different disciplines including software engineers to execute the technical operations at the backend. The interaction between the technical team and project coordination team is, therefore, an essential part of the eCIX implementation process. Furthermore, eCIX projects become even more complex if the e-trading solution is outsourced instead of developed in-house (for example in cases where e-trading is outsourced to HPs). In relation to this point Willcocks et al. (2011) argue that as the complexity of the development (for example mapping, transformation, and translation of data) increases, issues with project coordination, information management and control, and meeting end-user expectations becomes harder to manage. In addition, given that firms will want to integrate with as many key suppliers as possible (for example in order to derive maximum benefits from the e-trading operations), the difficulty of managing the eCIX implementation project is expected to increase in parallel with the number of suppliers incorporated to the project. As a consequence of these factors, there is a need to explore the interface between software development and organizational functions assisting with the eCIX projects for deeper understanding of the implementation process.

In framing the methodological concerns surrounding the information systems (IS) research (which many e-trading systems fall under), Benbasat and Zmud (1999), and Davis (2000) make a compelling case in order for IS research to become more industry relevant. Case study method is one of the most widely used approaches in IS research. Case study research can yield many important insights as to ‘how’ and ‘why’ a phenomenon occurs given its specific context. It allows in-depth study of the phenomenon which the researcher can use to form as the basis of a more extensive study (Yin, 2014). However, the case study approach also has limits in the sense that generalization of the findings would be difficult due to the fact that the study is bound to the case study context only. Whilst recognizing this weakness, a case study approach is considered to be the most appropriate method of investigation because it allows the study to report on full life-cycle of the project with a significant amount of qualitative and quantitative data to support the research findings (Yin, 2014).

Research method and process

The aim of the current study was to explore the challenges and barriers faced during delivery of a case study eCIX implementation project between a large UK CF and ten of its suppliers. As part of its ongoing business improvement programme, the CF identified an overall operational cost saving, and increased efficiencies in procurement processes by moving away from paper-based transactions to e-trading. During 2010, the company deployed its own custom-built ERP system to manage accounting related operations for all of its projects and, business and operating units. A year later it had selected a HP in order to interconnect with its supply base and start e-trading with the selected suppliers. The initial goal set was to get at least 20% of firm’s overall transactions to trade electronically (See Table 1). Table 1 gives the profile of the supplier firms and the number of orders sent to suppliers before commencing with the project. The name of each supplier company participated in the project is removed for the reasons of commercial confidentiality. In addition, the contractor company will be referred to with the code ‘CF’ whilst ‘HP’ will be used to refer to the HP.

Table 1 List of suppliers implementing eCIX

Supplier code	Sector	Company turnover^a	Percentage of orders^f	Percentage of the total number of orders^g
S2	Safety and workplace commodities	£100 m	40.7	8.8
S10	Construction materials (timber and building materials)	£1.9 bn	13.9	3
S1	Heating and Plumbing supplies	£1.8 bn	12.1	2.6
S7	Underground Drainage Materials	Unknown^e	9.7	2.1
S5	Construction materials (timber and building materials)	£1.8 bn	7.2	1.6
S8	Office and stationary supplies	£250 m^d	5.2	1.1
S6	Printing and document management	£50 m^b^,^c	3.5	0.8
S9	IT Services	£50 m	3.3	0.7
S3	Construction tools and equipment	£100 m	2.6	0.6
S4	IT hardware, software and services	£350 m	1.7	0.4
Totals			100	21.6

Note: Bold values indicates percentage of the total number of orders raised in 2010.

^a UK turnover only. Except otherwise stated, figures are based on 2013–2014 financial year submitted to the Companies House and rounded to nearest £50 k.

^b Figure published in 2012 for the trade period between 2011 and 2012.

^c The company was acquired by a competitor for an undisclosed amount in 2014.

^d Unofficial estimate only, not based on any factual data. The global turnover of the company is £14.5 bn.

^e The company went into administration in 2012 and no financial information before pre-acquisition could be found.

^f Percentage of orders placed with each company in 2010.

^g Percentage of the total number of orders raised in 2010.

The reason for the selection of this particular case for data collection was primarily based on availability of the project and access to data (between 2012 and 2015). At the beginning of the project, the researcher, who is one of the authors, was primarily involved with monitoring, and reporting of project activities and progress on behalf of the HP. This opportunity gave intimate access to the project and allowed the researcher to collect as much rich data as possible from the earliest stages of the project until completion.

Data collection and analytical procedures

Data collection involved capturing of data from multiple sources including project development logs (the back-end software activities involving mapping, coding and implementation), meeting minutes, and project reports as well as observational data gathered through face-to-face and teleconferencing meetings. In addition, the researcher had access to the email archives of the project coordinator who was responsible for managing the project from the HP’s end. The project coordinator was the central authority who was in control of all the project communication therefore availability of this data gave the case study the opportunity to explore the full picture, that is, the communication and correspondence patterns between the project participants (the teams at the CF, suppliers, as well as the internal correspondence between the HP’s technical project delivery team). Over the course of the study, the total number of emails exchanged was 3646; which were between 98 people working across 15 different companies (including the CF, HP, ten suppliers and three third-party service providers to the supplier firms).

With regard to the data analysis, emails were initially grouped according to the project and later categorized into the appropriate implementation stage. For each implementation, information from the emails, project development logs, technical documents and case study notes were compiled into a single spreadsheet in a three-level work-breakdown structure. The reason behind lack of progress was codified along with all the relevant information including the details of the delay, source organization and impact of the delay on the project timeline. The activities that resulted in unnecessary hold-up such as non-communication, unavailability of the systems, setting up joint meetings, late change requests, and so on, were tracked to determine their impact on projects’ schedule. On the other hand, the development activities which include tasks such as implementing the mapping schemas, and conducting testing to validate the implementation were also recorded. The project monitoring spreadsheet provided a large amount of detailed and reliable information over the lifetime of all the 10 projects. A simplified version of the project monitoring spreadsheet can be found in Appendix 1 which shows high-level summary of one of the projects. Finally, the information from the project monitoring spreadsheets was extracted into a single workbook which allowed the study to identify the trends and patterns, and categorize them into several themes of challenges and barriers.

Case description

Following sections aim to provide a background into the case study context. First, the eCIX implementation method is introduced. This is followed by the description of processes which the eCIX facilitates and the phases in the project. The next two sections introduce the CF and HP who were the main partners in execution of the project. Each supplier case is then presented to give further insight into challenges and barriers faced during project deployment.

Case study context

Supplier integration method

The e-trading functionality is enabled through the HP’s Cloud-based e-trading portal which is interconnected with the CF’s (CF) back-end ERP system (Figures 1(a) and (b)). Buyers at the CF access the portal via a secure login and can be given multitude of access rights to projects (referred to as workspaces) to trade electronically with any supplier connected to CF’s private e-Marketplace. The e-trading functionality is also supported by spend analytics features of the HP’s platform, including: (i) access to all of the transactional documents exchanged with full audit history, (ii) running custom reports on spend data, and (iii) monitoring purchasing activities of each project or business unit.

Table 2 Challenges and barriers to eCIX implementation

	Challenges	Barriers
Technical	Capability and adaptation of existing systems Availability of human and IT resources Impact of eCIX on existing commercial processes and EDIs Lack of clear specification Late design changes Inadequate documentation	Flexibility of suppliers to accommodate changes Cost of development for suppliers
Coordination	Lack of adequate project coordination Inadequate change management Large number of people involved Clear identification of roles/responsibilities	Dispersed virtual teams Differences in time-zones Social/cultural diversity of teams
Integration	Single-hub connections: impact of any new changes on existing connections/processes Inter-hub connections: duplicating data conversion efforts	Competition amongst hub-providers
Organizational	Lack of commitment from suppliers Lack of eCIX implementation strategy Lack of strategic support High staff turnover in project management/coordination team Inaccurate business strategy for suppliers Lack of people with appropriate skills and experience in EDI projects	Supplier relationship discontinuity Supplier business uncertainty

Depending on whether suppliers’ back-end system is capable of connecting with external systems, integration with the suppliers can be implemented with direct connection with the supplier’s ERP or legacy system (Figure 1(c)) or through an intermediary, third-party HP who provides the connection infrastructure for the supplier (Figure 1(e)). Alternatively, suppliers can use the off-the-shelf package offered by the HP which is an online portal for management of the procurement process (Figure 1(d)). This is regarded as the most appropriate method for low-spend, project-specific suppliers where the transactions are not frequent and low in volume.

General characteristics of the eCIX implemented

Figure 2 shows the process adopted for the eCIX. The information that CF wanted to exchange with its suppliers are shown in white boxes whilst black boxes show the supplier sourced commercial information. As can be seen from Figure 2, four-way validation is implemented on all documents sent/received to ensure maximum data accuracy. The first stage in purchasing process is to publish an electronic catalogue (e-catalogue) through which buyers can purchase goods/services from. There are two ways by which e-catalogues can be implemented; either through HP’s portal or supplier’s own web store. With regard to the former, suppliers are provided with a spreadsheet template which is populated with the item/product details and then uploaded onto HP’s portal. In the latter method, supplier maintains its own catalogue facility and interface with the e-trading application through the PunchOut or RoundTrip solution.

Figure 1 eCIX implementation map (supplier implementation options shown by white arrows)

Figure 2 The eCIX procurement process

The blanket order (BO) is a form which contains information about the value of spend allocated to project buyers in each project. Generally a BO contains much more detailed information including the period of BO agreement, items or categories of items covered by the BO, pricing and quantity restrictions etc. however, within the context of the CF the details of the commercial contract was maintained within the ERP system therefore the purpose of the BO was mainly to manage the spend at each project for different suppliers (as well as informing suppliers, for example, their depots or branches, about the potential value of spend by a particular project).

Call-off orders, in the context of the case studied, are essentially purchase orders sent to each supplier in the supplier’s requested file format (along with the necessary data transformation). In order to raise a call-off order buyers use the HP’s Cloud-based online platform. There are a number of business rules applied to call-off orders before they can be issued to a supplier. These include:

•	Check whether call-off order exceeds the total BO limit;
•	Check whether call-off order value exceeds individual buyers’ monthly and transactional limits;
•	Check whether buyer has permission to order products/items.

Upon receiving of the order message suppliers send an order acknowledgement message to the buyer to confirm safe receipt of the order message. This is a standard transmission message which does not have any information concerning the content and status of the order. Once the goods/services have been dispatched supplier issues the invoice(s). The invoice document goes through similar checks to validate the information being passed on and make sure it contains accurate information. For example, invoices must conform to validation and business rules such as invoice number should be unique and refer to a call-off order, mandatory references (such as BO number, call-off reference number etc.) must be correct/present, pricing and product details on the invoice file should match with those in the corresponding call-off order and total value of partial invoices should not exceed the total order value. The creation of a GRN document is not covered within the implementation process due to way CF handles deliveries but for reporting reasons the HP automatically creates a GRN message when an invoice is successfully processed. Lastly, supplier sends credit note after the CF clears the payment (which is outside the system) and similar to the way invoices are processed, validation and business rules are applied to credit notes to ensure highly accurate data exchange.

Approach to eCIX implementation

The implementation process can be considered as a bolt-on exercise where the HP worked with CF’s supply base to interconnect the CF with the suppliers. The eCIX implementation process followed the sequential software development methodology, called waterfall model (See Figure 3) which is one of the most widely used frameworks for software project management (Cadle and Yeates, 2008). Description of each activity/stage is given below:

Figure 3 Stages involved in implementing eCIX shown in V-diagram (a slight variant of waterfall model) (After Cadle and Yeates, 2008)

Requirements gathering/commercial agreement: This is the first stage in engaging with the suppliers. It involves high level talks between the project coordination team at the CF and HP, and business managers and IT specialists at the supplier company. The aim of this stage is to capture supplier’s specific requirements to come up with the most appropriate strategy for the integration. A technical questionnaire is issued to supplier to filter down the most appropriate solutions for the project so a commercial agreement between supplier firm and HP can be settled.

Project specification: Once the technical questionnaire is returned to the HP, together with the CF’s IT team, a detailed project specification phase takes place to clarify the requirements. This stage is highly dependent on the issues which have been identified at the prior stage following the technical talks with the supplier’s IT team. A number of technical documents (connection documents, business rules and mapping documents) are shared with the supplier’s IT team to provide more detailed technical information on the project.

Connection and mapping exercise: This stage aims to establish a test connection between the supplier and HP to initiate the actual implementation process. Implementing eCIX between two heterogeneous systems entail intense mapping exercise to restructure a source data into an instance of a different schema (target format). Although this is a relatively easy development task, issues arise when one system is not capable or flexible enough to accommodate the mapping requirements. This is one of the most intense stages in the project where file formats, message content and, validation and business rules are analysed in detail and configured as necessary.

Implementation: Any development task risen as a result of mismatch between two systems, e.g. where the supplier’s system cannot accommodate the standard integration requirements, or where supplier asks for a change request, it is usually carried out in the implementation stage which may or may not be in parallel with the earlier stage(s).

Phase 1 testing: At this stage all the mapping and implementation is done and testing between the supplier and HP is carried out to test both, connection and successful transmission/validation of messages (e.g. call-off orders, order acknowledgement, invoices and credit notes) between the HP and the supplier.

Phase 2 testing: This is the stage where an end-to-end testing is carried out by CF, HP and the supplier. It is the stage where the procurement process is tested from beginning to the end (i.e. procure-to-deliver). If the testing fails any business logic, validation, and/or any of the mandatory business rules, or if there are any bugs identified in the data exchange process, solutions are proposed/developed and implemented followed by another round of testing.

Deployment: Once Phase 2 testing is signed-off by the supplier and CF, a Go-Live date is agreed and any work related to setting up of integration on live system is carried out.

Contractor firm

The company studied is one of the major contractors in the UK which is part of a multinational construction firm. The focus of the study is on the UK arm of the business which has presence in various sectors including engineering, construction, utilities, infrastructure, healthcare, facilities services as well as undertakings through Joint Venture, Public-Private-Partnership and Private-Finance-Initiative. The organizational structure of the firm consists of several business and operational units responsible for different sectors. In terms of the procurement process the firm utilizes de-centralized procurement process where sourcing for each construction project is carried out by procurement departments within each business/operating units. However, corporate level agreements are made with some of the key suppliers in order to increase the bargaining power.

As can be seen from Table 1 two groups of supply chain firms are selected for eCIX where top five firms are characterized by construction-specific supplies and the bottom five (except S3) are considered as firms operating in multiple industries. The CF’s rationale for selecting these companies were based on (i) the number of transactions taken place in the previous year; (ii) number of transactions estimated in the future; and, (iii) purchasing requirements of projects which will be piloted when eCIX project is completed.

Hub provider

The HP involved in the project is one of the few IT companies specializing in collaboration Software-as-a-Service (cSaaS) for the AEC/FM industry. Along with other collaborative, document management and project management solutions, it also offers solutions for sourcing and procurement requirements of AEC firms. The sourcing application offers comprehensive eTendering functionality for firms to manage their tendering process from Pre-Qualification to Invitation to Tender to selection and awarding of the tender. The eProcurement application on the other hand provides a platform for buyers and suppliers to transact with each other through its Cloud infrastructure.

The project implementation team at the HP company consisted of a project coordinator and technical project implementation manager who was based overseas (along with the developer team). The technical project manager was responsible for technical development whilst the UK-based project coordinator was the principle point of contact between the CF and suppliers. Responsibilities of the project coordinator included engaging with suppliers to agree on commercial proposal and coordinating the technical development work between all the parties. Communication between the internal project team members was usually through emails and telephone conversations.

Figure 4 shows the interaction patterns (emails exchanged) between the project participants (including the third-party service providers for the supplier companies) throughout the duration of the case study. The graph was produced with the help of an online data visualization tool called Circos¹⁰ which is the work of Krzywinski et al. (2009). Each segment in the graph represents a company, and the incoming and outgoing emails by the companies. The inward flow (emails received) is represented by the ribbons touching the white space under a segment (that is, the colour of the ribbon touching the white space shows the source company). The outward flow (emails sent) is indicated by ribbons where the target segment colour (company receiving the email) is touching the source segment bar. The stacked bar plots outside the segment shows the percentage of emails received (inner bar), outgoing emails (middle bar) and all messages for the segment (the outer bar).

Figure 4 The Circos graph of email communication (after Krzywinski et al., 2009)

As can be seen from Figure 4 there is a complex and intertwined communications pattern in the eCIX project which entails significant number of email exchange. The number of emails analysed (3646) include all of the emails sent directly to a project participant, i.e.: everyone in ‘To’ field, and does not include the count of copies in ‘CC’ field. The Circos graph shows that HP is the biggest processor and consumer of information. The number of internal and external communications by the HP reinforces its central role in technical coordination of the eCIX implementation. The graph also shows that CF is interacting heavily with HP, albeit it is interesting to see that it sends more information than it receives from HP.

eCIX Implementation Cases

Supplier 1 (S1)

One of the biggest firms in its sector supplying heating and plumbing materials to construction industry, the CF was keen to connect with S1 due to volume of trade and number of transactions. The initial meetings were held between project coordinator from HP, supply chain manager from CF and business relationship manager at S1 to commence with the project. The supplier firm was using an intermediary HP (X1, who is a co-member with the HP on the Hub Alliance¹¹ network) so four parties were engaged in the implementation process. The chosen method of catalogue connection was internally hosted e-catalogue (i.e. through HP).

The first activity in the process (requirements gathering) was inactive for several months which delayed the technical discussion and project specification talks. This was due to S1’s approval process for the project and signing of the commercial agreement with the HP. In the next stages of the project, progress was impeded by delays in correspondence, poor communication during phase 2 testing, developments in supplier’s ERP system, and late change request to implement mapping for invoice and credit note documents. In the end, the project took 1166 days to complete. In terms of the technical development at HP’s end, the total tracked time was only 3% of the project duration. The waste activities which held the project, such as feedback on mapping schemas; creating, sending and feedback for test documents (orders, invoices and credit notes); and, organizing project meetings between all the parties accounted for 93% of the project’s duration.

Supplier 2 (S2)

As one of CF’s key supplier with high number of repeat transactions in almost every type of project, implementation of eCIX was vital to improving the procurement process with the supplier. Despite the close relationship between the CF and S2, the process for getting the commercial agreement (that is, between the supplier and HP) sealed took long time to settle. However due to importance of the supplier for the CF’s project activities, technical implementation was pushed to start in parallel whilst the contractual agreement was formalized.

The route adopted for connecting with the supplier’s catalogue was through PunchOut connection where the e-catalogue of the supplier was hosted externally on supplier’s web store. Connection and mapping exercise was the longest stage in the project with few issues experienced during PunchOut connection, mainly due to wrong set-up. A few development tasks were deployed by the HP (as per S2’s request) to facilitate validation of invoices and credit notes. The duration of the project was 347 days. The project progress sheet tracked that waste activities in the project contributed to 96% of project’s duration, whilst technical development was responsible for only 11% of the project’s duration. The overlap in percentages is due to technical development work being completed whilst waiting for additional information from CF and S2.

Supplier 3 (S3)

The supplier had an established trading link with at least five of the CF’s business/operating units as well as a number of JV projects. Although the number of documents transacted pre-eCIX implementation were relatively low, the value of transactions was one of the highest compared to the other suppliers. Furthermore, due to the lengthy paper-based procurement process, implementation of the eCIX was considered to be important for eliminating some of the waste activities in the current procurement process.

Similar to the previous set-up, the route adopted for connecting with the supplier was through PunchOut connection. Issues which impacted the project schedule include delays in creating the necessary set-ups for testing (such as account numbers and catalogue items to be used during testing), confusion over connection method and issues with connectivity, unavailability of supplier’s test system, as well as development work to map some of the elements in order and invoice schemas. As a consequence 64% of the project’s duration of was idle (433 days). The technical development work on the other hand equated to 24% of the project’s duration.

Supplier 4 (S4)

This was another supplier who wanted to implement PunchOut connection to automate the procure-to-deliver process. Face-to-face meetings took place between the project participants to initiate the project and get the commercial agreement signed off. Although the technical talks started whilst the contract was being approved, major system changes at the S4’s IT systems and issues with connection set-up held the project for over 3 months. Once the system became available project connection and mapping exercise was resumed, albeit shortly later CF decided to drop off the supplier from the project; ending the project after 280 days.

Supplier 5 (S5)

Operating with a turnover of over £1.8 bn, the supplier is one of the largest suppliers of timber and building materials in the UK. Majority of the projects and business/operating units of the CF have trading links with the supplier’s regional and local branches which describes the importance of the eCIX implementation for the CF. The project got underway straightaway from the initial engagement meeting where teams began to work on project specification (where internally hosted catalogue connection was agreed, i.e. through HP) and connection and mapping schemas. A third-party HP for the supplier firm (X2) was also involved in the project to facilitate the integration with the supplier’s ERP system.

The mapping and phase 1 testing stage was the longest as the development of schemas also involved input and data conversion for the interface between HP and X2. Late responses by parties, confusion around the ordering process, incorrect mapping and issues with connection set-up were the main cause of delays in the project which accumulated to 88% waste and inefficiencies in the project’s duration (which was 532 days). The technical development tasks (which included custom development work for the S5 to enable validation of invoice and credit note documents) were only 7% of the total project duration.

Supplier 6 (S6)

Although the number of transactions with this supplier was comparatively low, the value of the transactions and interaction with the supplier put considerable emphasis on eCIX. Due to the purchasing process adopted by the CF only exchange of invoice documents were covered within the project (with special business rules put in place to validate and process the Invoices received). Despite the low level of integration, the project took 258 days to implement. The technical development work related to facilitate this functionality was 22% whereas 91% of the project’s duration were held-up by incorrect connection configuration, incorrect mapping, feedback on invoice mapping and delayed responses to email correspondence.

Supplier 7 (S7)

Both the supplier and CF was keen to get this implementation deployed as quickly as possible due to long existence of their relationship. The project specification started straightaway after the initial engagement between all the parties. The supplier agreed to host the e-catalogue through HP however to connect to the supplier’s ERP system another HP (X2) was also involved in the project. The project took 506 days to implement. Issues which commonly appeared in other projects also plagued this project and resulted in significant amount of idle time in project progress (95%). Difficulty of holding meeting with all the parties, confusion over the test cycle, incorrect mapping, waiting for information, extremely slow testing cycles, late change requests for mapping schema and issues with supplier’s ERP system all had impact on the project schedule. In addition, during the course of the implementation the supplier’s business went into administration which delayed the progress for at least 2 months as the fate of the project was waiting to be decided. Several technical development activities were required which were implemented by X2 and HP, which constituted to 12% of the project’s duration.

Supplier 8 (S8)

The supplier is a key partner of the CF who holds a worldwide business agreement. The eCIX implementation however, was only between the UK companies. The method of connection to supplier’s catalogue was the PunchOut solution. Although the project was the quickest out of all the cases (200 days) it too experienced considerable delays in the project due to; a period of hold-up until the commercial agreement between CF and supplier is renewed, delayed correspondence, issues with the test systems, incorrect mapping and delayed test plans, which all contributed to 71% of idle time in the project. Technical development works (which include CF’s implementation of a technical update in its ERP system) amount to 20% of the project’s duration.

Supplier 9 (S9)

This is another incomplete project which was dropped off by CF towards the half-way in the implementation process (after 378 days) due to CF ending its relationship with the supplier. The proposed method of catalogue set-up was hosting on the HP’s environment. During the connection and mapping exercise a number of issues surfaced which required development work at the HP’s end. Common issues as with the other projects (such as waiting for information from supplier and supplier to share sample documents for mapping exercise and so on) also appeared in this project resulting in 94% of the project’s duration being held-up. Technical development activities on the other hand constituted to 10% of the project’s duration

Supplier 10 (S10)

eCIX was seen highly important by both CF and supplier firm for the relationship to evolve into a tightly integrated form. The preferred method of catalogue set-up was through HP’s environment. The project’s schedule suffered heavily from prolonged periods of inactivity due to unavailability of team members, confusion over mapping, late change requests by the supplier, incorrect set-up of the test/live environments, and unavailability of supplier’s test system, delayed correspondence, and sluggish test cycle. As a result of these factors, project’s duration was held 82% of the time. The technical development activities on the other hand account up to 9% of the project’s duration. It must be noted that although the project was completed and planned to go live, it was stopped after it became apparent that there was a crucial information missing on call-off orders which would interrupt the procurement process. As a result, the project was on hold until a resolution was found and implemented, which consequently extended the project’s duration to 1271 days.

Findings and discussion

As can be seen from Figure 5 the journey to implement eCIX between CF and its suppliers was a lengthy process where majority of projects took several years to finish whilst some did not even get chance to reach to the end (suppliers S9 and S4). The phases which took the longest to implement are: Commercial Agreement, Connection and Mapping, and Phase 2 Testing (See Figure 6). It must be noted that except in the case of S7, S1 and S10, the implementation process started whilst the commercial documents were being approved/signed so the duration of the commercial agreement phase was not critical for these three projects. The email exchange data in Figure 6 shows that Connection and Mapping, Phase 1 and 2 testing stages are the most intense stages where communication and coordination efforts were at the peak. It must be emphasized that the projects went through an iterative development cycle where most projects did not follow a strictly sequential implementation process however in terms of the project activities these stages were the most information and communication intensive.

Figure 5 eCIX implementation project summary

Figure 6 Average duration of each project stage, development activities and email communication

It is difficult to determine whether the delivery of the eCIX projects has been a success or failure as there are no benchmark data to make any comparisons. During the early phases in supplier engagement it was anticipated that each project would take several months to complete, which indicates a failure of expectations but perhaps most importantly, poor execution of the project. The thematic analysis of the case study data point to four types of challenges and barriers: technical, coordination, integration and organizational; which are discussed in detail below:

Challenges and barriers to implementing eCIX

Technical

The company HP was responsible for conversion and transmission of commercial messages between the CF and its suppliers, therefore majority of development tasks were undertaken by the HP with little or no development work for suppliers’ IT department (apart from implementing the mapping schemas). Development tasks that were deployed by HP only account for an average of 14% of the projects’ duration (not including suppliers S9 and S4) which indicates that technical complexity of the eCIX implementation projects are very low. A striking proportion of technical challenges faced during the connection and mapping, and phase 2 testing stages stemmed from highly customized procurement process which CF has adopted for the eCIX. Although the rigid business and validation rules ensure almost 100% accurate data, it creates many problems when suppliers’ ERP system cannot handle the necessary mapping requirements. Secondly, some suppliers were concerned about the impact of the implementation on their existing commercial processes and EDIs. At this stage, HP had to step in to facilitate the data exchange in accordance with the business rules and mapping requirements, which further complicated the integration and increased the cost of development for suppliers.

Another source of technical challenge was the lack of clear specification and inadequate documentation. Projects were developed with no clear definition of what each procurement process in the integration entails and identification of interfaces to be integrated which caused a lot of ambiguity in some projects. Further to this, no guidance or documentation was issued to suppliers’ implementation team such as the purpose of the project, the scope, deliverables, project assumptions, development and risk management plan and so on; which are all essential for through understanding of the project. Also, the project activities were largely managed through email communication with no documentation of information on supplier-specific development activities, which all created a lot of confusion about the particulars of each project and resulted in late changes in mapping schemas.

The lack of human and IT resources also added a considerable delay to projects’ duration. A number of suppliers’ test system and ERP application was unavailable for a period of time which added few weeks and in some cases months to the testing and development cycle. On the other hand, unavailability of IT technicians from suppliers/contractor’s implementation team has also caused problems with the testing and implementation. Generally, one or two people were involved from the suppliers’ IT team or the third-party HPs’ team. As a result, delays in testing, implementation or when organizing meetings, was prominent throughout the projects’ life cycle.

Coordination

High level of interdependency in project activities and large number of people involved in the project meant that coordination was vital part of the project governance. As teams were dispersed across geographies and time zones the demand for a more effective communication and coordination strategy was extremely important for the implementation teams. The results from the case study show that on average 87% of the projects’ duration was plagued with waste activities including waiting for information, delayed correspondence and poor coordination of project activities. This can be partly attributed to lack of adequate coordination whereby implementation teams were left to work in silos, often unaware of the on-going project activities. The HP controlled the project coordination efforts whilst the project manager from CF was mainly responsible for management of decisions concerning the CF, HP and supplier interface. Despite these governance mechanisms, coordination and communication issues were persistent throughout the projects’ lifetime. Here, it must be noted that social and cultural diversity of the teams can also be said to play a role in communication effectiveness and team cohesion as teams were mix of people from Asia, UK and Europe.

The second issue with coordination was primarily borne out of change requests being raised by CF, suppliers, and suppliers’ HPs. Some of the development requests coming through CF or supplier firms were hurriedly implemented without proper understanding of their impact on existing development activities and processes. In addition to this, multi-disciplinary professionals (with varying levels of rank in the organizational/functional hierarchies) were involved at different stages of the project. The technical teams, in particular, were assembled without formal and proper identification of their roles and responsibilities, creating a less effective intercommunication of information and messages at the initial stages of the project.

Integration

As seen from the case study there are two forms of integration: inter-hub connections and direct connection with the supplier. In cases where inter-hub connections had to be established, project coordination and management became an arduous task. This was primarily due to increased number of project participants which demand higher levels of coordination and management. The interaction between the two competing HPs was also susceptible to un-cooperative behaviour which sometimes resulted in longer waiting times for completion of a technical development task.

Further to above, suppliers’ HPs often reworked the mapping between themselves and suppliers which duplicated the connection and data conversion efforts, subsequently resulting in an increase in duration of the mapping process. In addition to this, where suppliers were connected directly through HP, the consequence of a change request (i.e. its impact on other connections/processes) had to be carefully considered. For example, CF had to ensure that any configuration to the parts or whole of a supplier-specific eCIX process would not interfere with the standard eCIX implementation process adopted with rest of the suppliers.

Organizational

Several highly critical organizational issues cropped up during the project’s lifetime hindering timely completion of implementation. During the course of the implementation the project saw three project managers from CF and one coordinator and one technical implementation manager from HP’s team leaving the project. This is thought to have a significant impact on the projects’ progress as the persons filling in the role took time to be acquainted to the project. Most of the newcomers were not familiar with the project (some with poor understanding of eCIX implementation) so a new learning cycle had to be acquired every time someone joined the project.

In terms of the strategic aspects of eCIX implementation, poor execution strategy as well as lack of strategic support from the top management has led to the project being planned, developed and executed immaturely. The strategy to get suppliers on-board was a one-sided decision by the CF and there was little engagement with suppliers prior to the implementation; for example, co-involving suppliers in the design and development of the new electronic process. Moreover, other than weekly and monthly reports and internal meetings, the top management had seldom interaction with the project execution team during the lifetime of the project and did not provide sufficient strategic support for the implementation teams. For example, the variations in purchasing process across projects and business/operating units of the CF was largely left to the implementation team to resolve, with little input from the cross-firm operational and strategic decision-makers. The issue was further complicated in cases where suppliers’ processes and systems required different adaptations to be made.

Whilst some projects were able to commence with an agreement in principle, suppliers S2, S5 and S8 were reluctant to commit themselves without a formal approval from the higher level management. Overall, the initial phase was a lengthy process where the average duration was 146 days which gives an indication of the difficulty in getting suppliers to commit to the project. On the other hand, the discontinuity in the CF-supplier relationship, as well as uncertainties in the suppliers’ business (S7) were some of the main causes of project delay, and in several cases (S4 and S9), project abandonment.

Critical success factors for implementing eCIX

The thematic analysis of case study data show there are a large set of challenges and barriers (summarized in Table 2) which must be overcome for a much more efficient delivery of eCIX projects. The discussion in this section is based on the findings reported earlier through which the study suggests several factors for an effective execution of eCIX implementation projects.

First of all, as identified in the case study, one of the underlying factors for poor implementation was the lack of a proper implementation strategy by the CF. It is argued therefore, without a proper implementation roadmap eCIX projects are bound to go astray. Although there needs to be a much detailed work in this area, based on the case study findings it would be appropriate to suggest the following critical factors for the implementation strategy: (i) identifying the key suppliers to be integrated, (ii) the objectives of eCIX, (iii) identification of the interfaces for integration and (iv) a strategic plan for the implementation process which includes performance metrics to measure project progress. With regard to the first point, Cole (2000) has identified several important factors when deciding whether to implement CIX with a business partner. However, as seen from the case study, the future business prospects with the supplier as well supplier’s financials is also another important point that must be considered when implementing eCIX. This is because once the business relationship ends it is highly likely that eCIX will become inactive (or used very little), resulting in waste of efforts.

eCIX implementation is more than just the exchange of commercial documents between two firms. It involves bringing the two tightly controlled and isolated processes together to complete the procurement process without any manual intervention. Although the exchange of invoice messages are considered as a straightforward task for EDI (Cole, 2000), the scope within the case study was a much more challenging task whereby application of business rules and logic significantly increased the complexity of the implementation process. Therefore, a balanced approach to business/validation rules is needed to avoid unnecessary complexity with the eCIX.

eCIX implementation projects require a two-way strategic commitment (from buyer and supplier company) to be successful. Commitment requires both, time and resources from everyone involved in the project and must spread from higher managerial levels to operational team involved with majority of the technical implementation tasks. Without this commitment it is highly likely that projects will fail or at best deliver an inconsistent eCIX solution which will subsequently have negative impact on the adaptation, acceptance and diffusion of the technology. Commitment can exist in many different forms, but as a starting point firms can adopt a strategic corporate agenda for e-trading with their suppliers. In cases where there is resistance from suppliers, firms can enforce their buying power and assert the use of e-trading as a contractual condition to transact with each other.

Before beginning an implementation journey all parties to the project (i.e. buyer, supplier and intermediary HPs) must carefully consider both technical and non-technical aspects of the project so that it does not only result in savings from automation but also creates efficiencies in the inter-firm commercial processes. For example, each business/operating or construction project unit may have different ways of interacting with a supplier, or vice versa a supplier may adopt different methods to process orders and invoices for different business/operating units. A clear understanding of how the internal business processes are managed currently and, how the eCIX will be interfaced is a critical element in the project. It is quite possible that firms will want to make alterations to their eCIX strategy hence, it is important that the systems in place are adaptable and flexible to support future change requests.

The task of coordination plays a pivotal role in management of any type of project. Inter-firm integration projects (be it eCIX, EDI or any other systems integration project) involve highly interdependent activities which require heavy coordination between all the actors involved with the project. The stages where most interactions occur in an eCIX implementation project are the Connection and Mapping, and Testing stages. For example, as identified from the case study, coordination and project management issues account for the 87% of the projects’ duration. Together with a practice of consistent and pre-emptive communication, better planning of activities is a ‘must’ in an eCIX implementation project. Beginning from the earliest stages in the project (i.e. requirements gathering) to the Deployment, all of the decisions taken, and any development activities implemented, must be recorded and shared with all the team members. eCIX implementation is an abstract activity which produces an intangible output at the end of the project, therefore such documentation would be essential for development of the project as well as become a valuable source of information for future reference (for example during system maintenance and upgrades).

Companies implementing eCIX must work towards a well-defined project programme which is realistic and built around project participants’ needs, requirements and concerns to ensure confidence in timely project delivery. More importantly, teams should work more closely, rather than in isolation from each other as seen in the case study, to benefit from advantages associated with collaborative working. It is highly likely that project teams will be assembled on a virtual environment where they interact through emails, teleconferencing and telephone communication. This places an important emphasis on project managers/coordinators to manage the technical and non-technical issues associated with virtual teaming.

It is highly likely that, as experienced from the case study, eCIX implementation can take a long time to complete. Indeed, one of the common characteristics of software projects is being overdue. However, with effective project management majority of the challenges reported can be eliminated and/or controlled, allowing a quicker turn-around for delivery of eCIX projects. An important element of project management is to plan a management strategy for risks involved with the implementation. The risks can be technical (for example, unavailability of systems, wrong implementation of mapping schemas, and incorrect connection set-up) and process such as design changes to the functionality/scope of the integration and other events such as changes in suppliers’ circumstances (i.e. suppliers’ business going bust and evolving relationship with the supplier). The risk management plan must identify all the potential risks with each integration project and develop appropriate action plans to prevent risks becoming issues.

Lastly, lack of skills and knowledge of project team members as well as lack of continuity of critical team members (i.e. project managers and coordinators) can have significant impact on the project’s performance. In relation to the first point, the eCIX implementation process involves intense interaction between software developers who are assigned all the technical tasks and, project managers/coordinators who are responsible for delivery of the e-trading solution. The teams that undertake such activity must possess sufficient understanding of processes, tasks and activities involved with the software projects and inter-firm commercial processes. With regard to the latter point, where possible, the successor of key project personnel should be promoted inside of the organization and have knowledge and awareness on technologies being implemented for a quicker orientation with the project. Further to this, project participants must have their roles and responsibilities clearly defined and communicated with all the team members from the beginning of the project. This will avoid inefficiencies in communication (such as sending emails to wrong people) and allowing a much responsive interaction between the team members. As teams usually rely on written and verbal communication, an effective communication and collaboration strategy is needed to utilize the most effective ways to share, discuss and exchange project-related information. Making use of collaboration technologies could provide vital support for the management of eCIX implementation projects which are likely to be executed simultaneously.

Conclusion

Electronic exchange of commercial information (eCIX), which enables end-to-end integration of commercial information between the trading parties’ back-end systems, is one of the key mechanisms in reaping the full benefits of e-trading. Despite the importance and benefits of its adoption, eCIX is not commonly adopted by the industry which perhaps explains why there is dearth of empirical research in the literature. As part of a longitudinal case study research, the aim of the study reported here was to evaluate the findings on an eCIX implementation project between a large CF and ten of its supply chain firms and thereby contributing to the understanding of fully integrated e-trading deployment by the AEC firms.

The case study CF had implemented a ‘connect once, transact anytime’ approach whereby through an intermediary service provider it would connect to its suppliers to manage its procurement activities, including linking of ERP systems to allow an automated, efficient and secure delivery of commercial transaction data. The findings of the study demonstrate that this is not an easy task to implement. The challenges and barriers that were experienced during deployment phase were categorized into technical, coordination, integration and organizational issues; however, it is evident from the research that management factors (or more specifically the project management, coordination and organizational issues) rather than technical development issues are the prime cause of the lengthy implementation period. Based on these findings, the study suggests a number of critical success factors which should be taken into consideration by both AEC supply chains and technology vendors (i.e. HPs).

The study suffers from several limitations which are worth mentioning. First, the choice and method of implementing eCIX is highly specific to the case study company which inevitably restricts the generalizability of the findings to wider context. Second, as the case study is based on researcher’s observation of the project activities, arguably it may contain some bias in data collection. Third, there is lack of existing benchmark data which prevents the case to be compared with other implementation projects. Lastly, although the case study employed a multi-source data collection, the study lacks methodological triangulation. Conducting interviews with project participants and organizational decision-makers would have reinforced the validity of the findings. Many opportunities exist for further research on e-trading systems implementation. First of all, there is more work needed to convince the AEC industry to adopt B2B practices. Without seeing the quantifiable benefits of the technology it is highly likely that industry will hold back for some more time until convincing evidence of such benefits are produced. Future studies therefore, could explore the benefits and savings derived from a real life end-to-end eCIX integration case. With regards to the case study findings, the challenges and barriers cited in this study can be tested through survey of professionals, companies or similar implementation projects to confirm (or reject) their validity and significance.

Funding

This work was supported by the Engineering and Physical Science Research Council (EPSRC) as part of an Engineering Doctorate study [EP/G037272/1].

Disclosure statement

No potential conflict of interest was reported by the authors.

Acknowledgements

The authors would like to thank the three anonymous reviewers and editor for their feedback and advice.

Notes

1. https://www.competefor.com/ (accessed 21 June 2016).

2. http://uk.rs-online.com/ (accessed 21 June 2016).

3. http://www.esi.info/ (accessed 21 June 2016).

4. http://www.buildingdesign.co.uk/ (accessed 21 June 2016).

5. http://www.barbourproductsearch.info (accessed 21 June 2016).

6. Architecture-engineering-construction-XML initiated by Bentley Systems in the US.

7. Initiated and developed by Associated General Contractors of America in the US.

8. Building-construction-XML developed by eConstruct.

9. Developed by Business Application Software Developers Association in the UK.

10. http://www/.circos.ca (accessed 21 June 2016).

11. http://www.huballiance.org (accessed 01 December 2015).

Appendix 1

Table

Project stages	Phase completion dates			Development (days)				Project hold (days)	Email count (no)	Average email response (days)
	Start date	End date	Phase duration^a	HP	CF	Supplier	Total
1. Commercial agreement	14/09/2012	13/02/2013	101				0	0	11	22
2. Project specification	18/06/2012	14/09/2012	63				0	54	15	5
3. Connection and mapping exercise	29/08/2012	26/11/2012	63	19	6	3	33	32	22	4
4. Implementation	09/10/2012	22/10/2012	9		3		3	0	4	3
5. Phase 1 testing	20/09/2012	21/11/2012	44				0	0	25	4
6. Phase 2 UAT testing	22/11/2012	12/03/2013	71	4		3	7	48	142	2
7. Deployment	12/03/2013	02/04/2013	13	1			1	5	40	1
			Totals	24	9	6	39	139^b	259

^aWorkdays (excludes holidays).

^bThe project lasted 200 days of which only 61 days were considered as ‘active’.