Development of Transportation Management System with the Use of Ontological and Architectural Approaches to Ensure Trucking Reliability

Abstract

With the wide variety of information systems and applications for motor transport and transport logistics control we have today, one may think we are already living in the digital era of general welfare, and digital tools would easily ensure sustainable development and prosperity of businesses. However, the experience of deployment and introduction of such solutions shows that their value for transport business is significantly lower than expected. Moreover, in some projects, business performance of transport companies had no correlation with introduction of information systems. In the best-case scenario, they provided for a slight decrease in document flow transaction costs. The change of the strategic status of a company in the transportation service market is a fairly complicated task, which, as analysis of literary sources shows, is achievable for few enterprises, primarily small and medium-sized businesses. Such situations show that information solutions were introduced without analyzing or assessing the business models of certain companies which could be used a basis for digital landscape of business as a whole. In recent years, the basic concept of forming a single information space of an enterprise has been the enterprise architecture. It provided for coordination between all the business processes in order to achieve a company’s strategic goals. The fundamentals of the concept were developed by J. Zachman in his famous Zachman Framework, and it was later developed with numerous models of enterprise architecture (e.g., TOGAF (Department of Defense Architecture Framework), GERAM (Generalised Enterprise Reference Architecture and Methodology), DoDAF (Department of Defense Architecture Framework)). However, currently some researchers note that sustainable corporate development should stem not only from a “correct assembly” of all its business elements, which was the purpose of enterprise architecture, but also from the interaction of these elements when reaching the emergence effect. In this context, one should pay attention to comprehensive activity analysis of a transport and logistics business using ontological and architecture approaches.

1. Introduction

Trucking is the most important connecting link between the economies of many countries from all over the world, which unites suppliers and consumers both within states and across their borders. Therefore, this industry has become a sensitive barometer of economic activities, reflecting both positive and negative trends in the economic environment. The decline in trucking, as a rule, serves as a clear indicator of the deterioration in the business environment in any given country or region. Obviously, the owners of the transport companies demand confidence in the conditions of instability and uncertainty, they would like to see their business resistant to various negative influences even in crisis situations in the market [1]. In the current context, many different factors can be the reasons for such impacts on a commercial organization; such factors should be perceived and evaluated in an appropriate manner and then management decisions should be taken to improve the company’s business processes [2]. Again, it is also necessary to assess the performance targets implemented by the current business processes of the company and, if there are deviations, to perform control actions, trying to achieve optimal combination of material, human and financial resources [3]. It is also known that the sustainable development of a transport company under the conditions of external uncertainty and instability is ensured not only by technological and economic, but also by social factors, where the knowledge and experience of employees, their motivation, mutual understanding and well-coordinated interaction are sometimes decisive [4]. Creativity, flexibility and unique thinking, including the ability to find solutions in a rapidly changing world, requires of company employees to possess multidisciplinary knowledge in order to confidently navigate the flow of information which keeps increasing due to the digitalization of transport and logistics activities [5].

Digital technology has long been used in the transportation industry [6]. Now, it’s hard to imagine a commercial truck without GPS/GSM (Global Positioning System/Global System for Mobile communication) navigation system and built-in on-board electronic systems [7,8]. At the same time, extensive experience in implementing the transportation management system (TMS) indicates that the value of such solutions is by no means unconditional. There are many cases where TMS did not cause any significant changes in the business processes of the transport company and did not lead to improved business results. A number of studies on analysis of the gap between business expectations and the functionality of information systems show that ignoring the human factor (i.e., how users perceive the information system) often results in failure [9,10].

Modern enterprise, in particular transport and logistics company, unites employees of various professions, for example, accountants, managers, engineers, who have various knowledge and competencies. Each of these specialists has their own point of view on the functionality to be implemented in the information system [11]. The works show that this point of view substantially depends on the knowledge of users. Thus, the accountant and the vehicle technician will have different points of view on the TMS, since the accountant will be primarily interested in changes in the state of financial assets and the technician will be interested in changing the performance characteristics of vehicles. Accordingly, they use different terms and concepts and set different goals in their day-to-day activities. As a result, the relationship between employees of different professions as well as of different departments within the enterprise is far from mutual understanding. This fact significantly affects the efficiency of the team as a whole. It is generally accepted that the experience and skills of employees, as well as their knowledge and competencies, are the company’s asset. However, there are often situations when the experience, knowledge and skills of employees are obsolete and can become a serious obstacle to the TMS implementation [12,13]. Unfortunately, direct conflicts of interests between different enterprise divisions or managers of different divisions can also take place frequently. For example, an accountant will insist on purchasing cheaper spare parts, like brake pads, arguing for a decrease of operation costs. However, a mechanic will insist on purchasing more expensive spare parts (brake pads in this case), arguing that they have higher value, and following operation cost calculations per mile, it will turn out more efficient. Consequently, TMS should analyze both direct and overhead costs per mile, in order to match the points of view of the accountant and the mechanic. Further analysis reaches the level of selection of types, makes and characteristics of vehicles (fleet composition), where knowledge and practical experience of people making decisions have a significant impact on the strategic status of the transport company later on.

Obviously, when conducting a preliminary study of the organization and collecting requirements for the future information system, these factors should be taken into account. This is especially important when deploying TMS, as fleet and logistics management is a specific area of activity. An inexperienced business analyst, while interviewing employees of an enterprise, can record outdated or inefficient “as-is” business processes. For the formation of a holistic vision of optimal “to-be” business processes, it will be extremely difficult for the analyst to semantically link the points of view of all employees of different specialties involved in the value chain. Therefore, there is a need to directly describe the semantics of enterprise business unit interaction before the modelling stage [14].

2. Materials and Methods

Currently, in a number of works, it is proposed to use the ontological approach to form these semantic relations. The origins of ontology come from the philosophy of the ancient world where it was used in attempts to describe the entire world order according to the views and ideas of that time [15]. In the current conditions, the initial stage of developing an ontological model of an enterprise involves the ability to form a glossary of terms and concepts which define the business subject-matters of a particular enterprise [16]. These subject-matters can represent both real-world objects (employees, vehicles, buildings and structures, etc.) and other objects (organizational structure elements, documents, business rules, etc.). If possible, this glossary should include all concepts and terms related to various aspects of the operation of motor transport, including technical, economic, social and informational components [17].

It should be noted that currently there is no single reference ontology that fully describes trucking. For example, the work presents an ontology for urban trucking, which includes trucking process activities, resources and goals of the consignor, carrier, consignee, state and municipal organizations [18]. There are also ontologies related to fuel management, road safety, strategies of transport companies [19,20,21], etc. Since making profit is the goal of any commercial organization, in our opinion, the ontology should first of all include certain subject-matters due to which the transport company earns money in a competitive and uncertain environment in the trucking market, creating value for its customers and relationships between them.

However, ontologies in general are characterized by a high level of formalization and are rather general in their nature [22,23]. As part of ontology, “elementary particles” or classes, that make up an enterprise are defined based on business terms. To build a meaningful, workable enterprise model, you need to put these “atomic particles” into the “right molecules” using the “right” business processes to achieve results that must be reproducible. The structural description of how “atomic particles” (business units) interact with each other (business processes) are translated into business outcomes is reflected in enterprise architecture. Thus, enterprise architecture represents a fundamental design of the organization as a whole, including the principles governing this design and the development of the organization [24]. Currently, there are over 50 different frameworks that reflect enterprise architecture, including DoDAF (Department of Defense Architecture Framework), TOGAF (The Open Group Architecture Framework), FEAF (Federal Enterprise Architecture Framework), and Zachman Framework (ZFEA).

To systematize and put in order the enterprise ontology, we chose Zachman Framework. The concept of enterprise architecture has been known for a long time, since 1987, when J. Zachman presented his famous framework, which is a 6 × 6 matrix. Each column of the matrix answers a specific question of the given enterprise architecture: “What?”, “How?”, “Where?”, “Who?”, “When?”, and “Why?” [25]. The lines reflect the points of view of experts of the various levels of management hierarchy: The planner, the owner, the designer, the builder, the sub-contractor, and the user [26]. Despite the fact that the Zachman’s framework has been known for quite a while, it still remains relevant. J. Zachman himself adapted his framework several times to the developing IT (Information Technology) industry, and today it is considered a kind of reference concept harmonizing information technology and business needs [27,28]. At the same time, a number of experts, including J. Zachman, tend to consider this as a framework rather than an ontology [29,30]. In Zachman’s modern view, his framework is a kind of Mendeleev’s Table [31], which helps “assemble” “elementary particles” by means of certain processes in certain combinations into the required results. In this context, the Zachman framework is a clearly organized structure or pattern that helps the researcher build the structure of the enterprise level by level by consistently answering the questions like “What?”, “How?”, “When?”, “Who?”, “Where?” and “Why?”.

Despite the fact that some experts criticize the Zachman Framework for being excessively “technocratic” and formalized [32], pointing to a significant social component of any enterprise, we believe that the combination of this framework and enterprise ontology, on the contrary, allows us to get a consistent plan or a roadmap for the realization of an information system implementation project from the uncertainty and ephemeral discussions of various business ideas to delivering a value to the consumer. In our context, thinking over the possibilities of implementing commercial motor trucking, a value proposition for the transport services market needs to be formed (i.e., what the consumer will be willing to pay their money for). Further, taking this value proposition as a basis, a certain abstract ideal will be built that would describe how the enterprise will make money; that is the business model of the enterprise [33]. Then, based upon this business model, we propose to form an enterprise ontology that includes technical, social, cultural and economic aspects of the organization’s functioning [34].

For this reason, preparation of a business model of an enterprise should be the initial stage of the transport and logistics company’s ontological model formation [35]. For this purpose, as a basic framework, we propose to use the A. Osterwalder’s Business Model Canvas, which the author himself defined as an ontology [36]. Both for transport and other companies, the value proposition is the most important element of the business model; that is, the service, which will be sought-after by the consumer. Since the competition in the transport services market, as a rule, in different countries and regions is very high, therefore, the development of a value proposition should be done very carefully. However, as the situation in transport market changes constantly, business flexibility requirements assume the possibility of adaptation of the business model to the changing conditions. As the basic factor of value offer, we are suggesting transportation reliability, where, based on this fundamental factor, you can form a set of business models following trends in transport markets. The reliability of trucking is an integral indicator reflecting the likelihood of carrying out trucking without violating the terms and conditions of the agreement [37].

$$P\left(t\right)=\frac{N_0-n\left(t\right)}{N_0}=1-\frac{n\left(t\right)}{N_0}$$

(1)

where

• N₀ is the number of truckings performed during time t;
• n(t) is the number of truckings during time t, performed with full or partial refusals (deviations from the agreed requirements for the quantity and/or condition of cargo and/or violation of timing parameters).

Failure to comply with the cargo delivery time, damage to the cargo, loss of accompanying documents and other deviations from the agreed terms and conditions of trucking may be considered violations of the terms and conditions of trucking, which, by analogy with the technical theory of reliability, can be interpreted as a refusal [38]. Based on the well-known seven rules of logistics (delivery of the right product in the right quantity in the right condition to the right place at the right time for the right customer at a right (reasonable) cost based on the transfer of the right (correct) data in the right (correct) format to the right place at the right time), formula (1) can be interpreted through the following expressions [39]:

$$P_{cpr}=\frac{N_{cpr}}{N}; P_{cpl}=\frac{N_{cpl}}{N}; P_{ccu}=\frac{N_{ccu}}{N}; P_{cti}=\frac{N_{cti}}{N}; P_{cql}=\frac{N_{cql}}{N}; P_{cqt}=\frac{N_{cqt}}{N}; P_{cdo}=\frac{N_{cdo}}{N}$$

(2)

where

• N is the total number of truckings;
• P_cpr is the probability of delivery of the right product (undamaged items corresponding to the order);
• N_cpr is the number of truckings with the right product;
• P_cpl is the probability of delivery to the right place (accurate delivery at the point of destination);
• N_cpl is the number of truckings exactly to the required destination;
• P_ccu is the probability of delivery to the right consignee;
• N_ccu is the number of truckings carried out exactly to the required consignee;
• P_cci is the probability of delivery exactly at the right time;
• N_cci is the number of just-in-time truckings;
• P_cql is the probability of delivery of the product of an adequate quality;
• N_cql is the number of truckings of the product of an adequate quality;
• P_cqt is the probability of delivery of the product of an appropriate quantity;
• N_cqt is the number of truckings of the product of an appropriate quantity;
• P_cdo is the probability of transmitting correct information on the product (data, messages, documents);
• N_cdo is the number of truckings performed with correct documentation.

From the analysis of literary sources [40,41,42,43], it follows that currently, high reliability of trucking can be a stronger trump card for a transport company in the market, compared to the low cost of services provided, since customers are currently very demanding, for example, in terms of meeting delivery times. Thus, adherence to the terms of delivery or reliability in terms of delivery time will be crucial for transportation of food products, milk in particular. However a high reliability of trucking can result in a higher cost for the customer. At the same time, it should be noted that such an attractive value proposition as reliability can be a factor driving the customer loyalty [44]. Thus, developing the business model of a transport company and, at the same time, taking the reliability of trucking as the basis of the value proposition, we accordingly determine the key partners of a company, customer segments, key resources, etc. (Figure 1). At the same time, another factor determining the delivery reliability is cargo safety and integrity, and adherence to the terms of delivery will have a lower priority. Properties and characteristics of vehicles, their equipment, selection of drivers, route, etc. will be determined based on this. Thus, the paper [45] presents a reference business model of a transport company which one can modify in order to ensure the specified indicators of transportation reliability for these particular conditions.

3. Results

Using the A. Osterwalder’s Business Model Canvas as a basic ontology defining the outlines of an enterprise’s business activities, it can be extended by adding subject-matters and semantic relationships from other areas of knowledge related to the commercial operation of trucks [45,46,47]. For example, developing the concept of trucking reliability as a key factor in the value proposition of the business model Canvas, we have developed an ontology of trucking reliability, a fragment of which is shown in Figure 2. This ontology represents subject-matters that can be associated with the refusals. These subject-matters are as follows: vehicle, cargo, people (driver, dispatcher, mechanical engineer), external environment and infrastructure. Such manifestations of the external environment as natural and climatic factors (rain, snow, floods, etc.) can cause delays in run or cause traffic accidents. For example, choosing a shorter route associated with a high traffic can also lead to delays. This factor is associated with the infrastructure domain. It is obvious that vehicle failure, driver’s or dispatcher’s mistakes can lead to deviations from the trucking terms and conditions specified in the agreement.

The practical implementation of TMS for each specific company should ensure the embodiment of a business model of this company in the form of tangible business results. This means that implementation of TMS should, for example, lead to significant improvement of the strategic status of a company in the transport market, ensuring stability in conditions of uncertainty and risk, not only lowering some operational costs. The ontology of the enterprise is the “inner world” of the given enterprise and the logic of interaction of the subject-matters of this world. It is also the behavior of these subject-matters and their influence on each other under the influence of various environmental factors. Since the nature of the interaction of these subject-matters can be quite complex, depending significantly on the structure of the organization, its business processes, employee competencies and other aspects, then, as a rule, an architectural approach linking all these factors together when implementing TMS should be used [48,49].

Nowadays, a number of studies provide examples of using the Zachman Framework for modeling the architecture of a logistics enterprise [50]. For example, in some studies [51,52], it is proposed to use the SCOR reference model (supply chain operations reference) for supply chain management, from which reference business processes are selected, for modeling the Zachman Architecture. In general, the business logic of the logistics organization in these studies is projected onto the Zachman Architecture model as follows:

• “What?”—Describes the business entities of the logistics company;
• “How?”—Describes the business process of the logistics company;
• “Who?”—Describes the business roles of the logistics company personnel;
• “Where?”—Describes the locations of the processes of the logistics company;
• “When?”—Describes the start and end times of logistic processes;
• “Why?”—Describes business motivation.

However, despite the fact that the examples presented seek to cover all operations related to supply chain management, in our opinion, their compliance with real business processes when deploying an information system will not be complete enough due to the complexity and complication of each specific enterprise. Some works suggest using special IT alignment procedures. However, our approach assumes that the relationship between the business architecture (“Why?”) and the information infrastructure is logically projected from the enterprise ontology, which in turn is projected from the company’s business model. This makes it possible to carry out both a flexible and a clearer and more transparent deployment of the information system. Consider this example, which is presented in Figure 3, choosing a freight carrier as a model.

4. Discussion

In our context, the planner is the owner of the company or the leader who makes decisions on the strategy of the enterprise, its goals, mission and vision. This information is identified in the first cell of the “Why?” column. Value proposition in the A. Osterwalder’s Business Model Canvas, which is subsequently transformed in the company’s strategy, is the prerequisite for the formation of this cell. Thus, in the business model, we determined that this company will ensure reliable trucking. In the strategy, we specify that, for example, dairy products for small stores will be transported by light trucks. Accordingly, the company’s mission will sound like “Milk delivered to you will always be fresh.” Next, in the first cell of the adjacent “When?” column, the operating cycle of the company is defined. For example, the company will deliver dairy products to stores early in the morning. In the next “Who?” column of the first cell, the necessary number of employees and the scope of their duties are defined. In the next “Where?” column of the first cell, the location of the company’s units, for example, a dispatch center, warehouse, garage, repair area or parking lot for vehicles is defined. In the “How?” column of the first cell, a set of key business processes of the company is defined. For example, the company will not only carry out trucking, but also minor repairs of its own trucks. In the “What?” column, business subject-matters are defined, for example, the type and number of vehicles, their characteristics. In general, following our approach, the formation of the level of the planner of the Transport and Logistics Enterprise Architecture Zachman Framework should be carried out by translation from the enterprise ontology where the corresponding ontology domains determine the filling of the cells of the corresponding EA framework columns (Figure 4).

At the next level of the owner (Figure 5), the concept of the future TMS is formed, videlicet, based on the general understanding of commercial activities of this transport and logistics company, and the logic of the future information system operation is defined. Here, at this level, the company’s strategy is translated into a business plan, where the targets, resources required to achieve them, steps to implement the strategy, etc. are defined (second cell of the “Why?” column). In the second cell of the “When?” column, the time schedule of the enterprise is defined. Then, at the level of the Owner of the “Who?” column, the organizational structure of the enterprise is reflected. For this organizational structure, the workplaces of the employees are defined, which are reflected in the second cell of the “Where?” column. In the corresponding cell of the “How?” column, a high-level model of business processes is formed, for example, in IDEF0 (Integration Definition for Function Modeling), UML (Unified Modeling Language) or BPMN (Business Process Model and Notation) notations. Then, in the second cell of “What?” column, the semantic model of the future TMS database is reflected in the form of an ER-diagram (Entity Relationship diagram).

The level of the designer (Figure 6) already implies an IT specialist rather than a transport manager. Filling in the cells of the “What?”, “How?” and “Where?” columns at this level clearly presupposes a familiarity with the IT terminology and deep understanding of database design, business process modeling and design of corporate computer networks. Thus, in the cell of the “What?” column of this level, a logical model of the TMS database is formed, including tables and relationships between them. In the corresponding cell of the “How?” column, business processes are explicit, for example, with the use of DFD (Data Flow Diagram) notation. In the cell of the “Where?” column of this level, the topology of the corporate network of the enterprise is defined. Cells of the “Who?”, “When?”, and “Why?” columns of this level should be formed based on the requirements of transport managers. Thus, in the corresponding cell of the “Who?” column, the job responsibilities of each employee, including drivers, and their areas of responsibility are defined. In the “When?” cell of this level, the vehicular traffic route and time intervals for passing checkpoints on these routes are defined. In the “Why?” cell of this level, the business rules of the enterprise are defined. For example, in case of a more than 20-min deviation from the time of arrival at a checkpoint on the route, the driver shall inform the dispatch center on the reason for delay and the expected time of arrival at the checkpoint.

The next level of the builder corresponds to the level of the systems analyst, who determines the direct technical implementation of the future TMS (Figure 7). Thus, in the cell of “What?” column of this level, the primary and foreign keys of the tables are defined (i.e., links between the tables are formed). The tables themselves should be normalized if necessary. Business process models are translated into algorithms, which are reflected in the corresponding cell of the “How?” column. In the cell of the “Where?” column of this level, the required network hardware and software is defined. Then, in the corresponding cell of the “Who?” column, the policy of user access rights to various modules and tasks of TMS is reflected. In the cell of the “When?” column of this level, the scenarios of the employees work in the information system are reflected, and in the corresponding “Why?” cell, the sequence of actions aimed at achieving the goals is reflected.

The fifth level represents the sub-contractor’s point of view (i.e., that of the IT specialist who implements this TMS (Figure 8)). Here, the very programming of the modules of the information system or its adaptation and configuration when purchasing the “packaged” version are already carried out. At this level, database tables are formed for a specific server, for example, Oracle or MS SQL, which will be used in the information system. These tables are reflected in the corresponding cell of the “What?” column. Algorithms developed earlier at the previous level are coded in one or another programming language; for example, SQL, Java, PHP, etc. These scripts are reflected in the corresponding cell of “How?” column. Corporate network settings, including IP-addresses of workplaces, are reflected in the “Where?” column of this level. In the “Who?” cell, the means and methods of monitoring user actions are reflected. The procedure of the TMS users work are reflected in the corresponding “When?” cell. In the “Why?” cell of this level, the control over the implementation of business rules is reflected.

Finally, the sixth level reflects the user’s point of view regarding the work with TMS (Figure 9). Here, at this level, the “What?” cell contains data, which the user enters into the information system. The “How?” cell reflects the forms of the information system interface, which was obtained as a result of the search for the best interaction experience. In the corresponding cell of the “Where?” column, the TMS modules adapted for specific workplaces and their network configuration are reflected. In the “Who?” column of this level, the settings of the security policy for a specific user are reflected, taking into account the structure of the organization, job hierarchy, etc. When starting the operation of the information system, it often turns out that the initial procedure for the users work should be adjusted. This happens, for example, because, as a result of the implementation of the information system, the user is able to perform more operations, and some staff can be downsized. In this context, all changes to the procedure are reflected in the “When?” cell of this level. In the last cell of the “Why?” column, the TMS elements that help the user to make management decisions (summary tables, dashboards, reports, charts) are reflected.

Thus, the stakeholders group, consistently and creatively interacting at each level of the given framework, moves from the concept to the physical implementation of TMS (Figure 10), outlining the boundaries of the future information system at the first level. At the second level, they form the requirements for this system. At the third level, the logical formalization of the future system is defined. At the fourth level, a technological description of the system is formed. At the fifth level, the expected configuration of the information system is defined. At the sixth level, a ready-made release of the implemented TMS is obtained [53].

Therefore, the consistent development of the enterprise architecture based on the Zachman Framework can rely on the following models:

• business architecture model describing the structure of business;
• component model that will include the required software modules;
• deployment model that will reflect the physical architecture of the system according to the location of various subdivisions, departments and units of an enterprise;
• model of business processes of an enterprise;
• model of requirements for the information system;
• a high-level conceptual data model, reflecting the basic concepts and terms;
• detailed data model of an enterprise;
• security model reflecting security policy.

5. Conclusions

Currently, the search for new growth drivers is more relevant than ever in connection with the recession in the global economy due to the COVID-19 pandemic. Despite the suspension of operations of entire industries in many countries due to quarantine, trucking activities did not stop, especially those related to the supply of food and essential commodities. Moreover, the pandemic has sparked a surge in online commerce, which has prompted trucking companies to explore new ideas to meet the increased consumer demand. It is obvious that the introduction of advanced science-based knowledge directly into the provision of high-quality and reliable trucking should become a catalyst for the digital transformation of transport enterprises, which are currently among industries which use the innovative IT solutions least of all. Since digital transformation involves changing not only business processes, but also business models, finding optimal and effective IT solutions for these purposes becomes not a trivial task. The cost of mistakes in management decisions can be very high. For example, one of the biggest challenges during the pandemic was the transfer of workers from freight companies to remote work.

The projects for the formation of a single information space based on the Zachman Architecture that we developed allowed us to deploy TMS for remote work using virtualization tools. Thus, an obvious example of success in this case was ensuring the reliable operation of a company with a geographically distributed organizational structure. At the same time, an important factor in ensuring reliability was the rapid deployment of remote work using virtual desktops, which allowed users to work on low-speed communication channels. In a number of companies, this decision as a whole forced a serious study of the transition to cloud solutions. At the same time, hidden opportunities for optimizing the work of dispatching personnel were revealed, including those associated with more efficient distribution of work time.

Further steps related to the synthesis of the ontological and architectural approach are to improve the impact of decisions made by dispatchers on the life cycle of vehicles, which will allow business processes to be reproducible to create value for consumers, regardless of the skills of managers. At this stage, we are working on developing a model of a reference ontology for trucking, which will also be based on a reference business model in order to ensure the reliability of cargo transportation. It should be noted that the use of ontological and architectural approaches is not limited to applications in the road transport industry. It seems promising to use it for digital transformation in the design and implementation of information systems in industry in general, and the construction industry in particular.