text:
Implementation of Genetic Algorithm to Solve Travelling Salesman Problem with Time Window (TSP-TW) for Scheduling Tourist Destinations in Malang City

In doing travel to some destinantions, tourist certainly want to be able to visit many destinations with the optimal scheduling so that necessary in finding the best route and not wasting lots of time travel. Several studies have addressed the problem but does not consider other factor which is very important that is the operating hours of each destination or hereinafter referred as the time window. Genetic algorithm proved able to resolve this travelling salesman problem with time window constraints. Based on test results obtained solutions with the fitness value of 0,9856 at the time of generation of 800 and the other test result obtained solution with the fitness value of 0,9621 at the time of the combination CR=0,7 MR=0,3.

Introduction
Tourism is one of a growing field today. Along with the development of that, the majority of governments around the world have devoted time and energy to promoting tourism through nonprofit services [1]. One of the rapidly growing tourism is in Indonesia. Can be taken as an example one of the cities that Malang has become one of the best tourist destination in East Java that is favored by many people. Neither of the tourists who come from East Java, outside of East Java, to outside Java. Many travel treats in Malang, among others: family travel, educational travel, outbound travel, nature tours, historical tours to culinary tourism. It is used by the majority party provider of travel services to offer travel packages in the city of Malang. But unfortunately many tour packages offered ineffective because in a short time can not visit some tourist destinations with optimal so many tourists who choose to venture on their own tourist destinations. Ineffective means tourist doing travel based on travel route from travel services which is visit some destination not in the its operating hours.
In the other hand, some tourists think that by traveling independently can maximize travel destinations with optimal, but in fact as ineffective because tourists do not take into account the important things such as the distance between destinations as well as 2 JITeCS Volume 2, Number 1, 2017, pp 1-10 p-ISSN: 2540-9433; e-ISSN: 2540-9824 the operating hours of destinations. The operating hours can be a limitation in determining the optimal route of travel and hereinafter referred to as the time window. In doing trips to various tourist destinations, each destination must be visited exactly once and then back to the starting point [2] [3]. Problems like these can be modeled into a Travelling Salesman Problem (TSP). TSP is one combinatorial problem in the search for a solution can only be gained by trying some of the possibilities at random so that the computing time required is quite high [2].
This problem is very important and deserves to be resolved as the subject is not the only form of conventional TSP is always aiming to find the shortest distance, but also pay attention to the time window [3] [4]. There are several methods that can be applied in solving the TSP such as Method Campbell Dudeck Smith (CDS) [5], Ant Colony Optimization [6] [7] [8], and Genetic Algorithm (Genetic Algorithm) [

Related Research
Previous research has ever done and is closely related to the problems discussed namely concerning the scheduling of these travel destinations carried out by [5] and [9]. In the study [5] conducted by Saptaningtyas is the optimization in the management of attractions in the hope that does not happen traveler piling on the attraction by applying the method of Campbell Dudeck Smith (CDS). While the study [9] conducted a visit Attraction optimization by applying genetic algorithms. But optimizations like these two studies are less effective because there is no limit problems related to the operating hours of the tourist attraction. Several previous studies conducted to the discussion of the same but apply a different algorithm as in [8] and [6]. In their study, Dong et al. [8] solve problems by using the TSP Cooperative Genetic Ant System. They use two methods namely hybridization Ant Colony optimization algorithm and genetic algorithms. While Escario [6] conducted experiments Ant Colony Extended application of algorithms to solve the problems TSP. They claimed that there novelty comparison algorithm Ant Colony algorithm optimization in general. But the application of Ant Colony algorithm in both of these studies is still less than optimal. Due to the fact that these ants is "likely to" choose a short path in search of food but the path is not necessarily the best path.
Widodo and Mahmudy [2] conducted the research with similar problems, but there are some considerations as a limitation. The study discusses the culinary tourism recommendation system. The recommendations are not only aims to minimize the distance but also match the travel choice, taste suitability dining and travel time.
In a study with the same case study, Setiawan [9] try to provide solutions to optimization problems Attraction visit by applying genetic algorithms. Solutions offered by applying the genetic algorithm is considered quite high because of a genetic algorithm to try all the possibilities that exist to obtain the best solution. But there is a lack of such research that is only focused on finding the best route, do not consider the time limit operating hours of these destinations.
There are other studies conducted by Arnesen, et al [11] regarding the scheduling of several tankers in international trade lines anchored at several terminals at the same 3 p-ISSN: 2540-9433; e-ISSN: 2540-9824 port so that no clashes between the ship and the buildup of ships at the terminal, besides that there are times and conditions which is different for each boat to visit the terminal.
Suprayogi and Mahmudy [4] also conducted similar research on the pick-up laundry which has a goal to minimize the distance and also consider the time availability of its customers.
Based on several studies that have been done before, it can be said that the genetic algorithm is an optimization technique that is the most popular and proven to solve problems as complex as that applied to the Travelling Salesman Problem with Time Window for pick-bar [4], the system recommendations culinary tour [2] and the optimization of attraction visit [9]. With these considerations, the authors propose research on optimization TSP with limits on hours of operation as a time window for scheduling case study of tourist destinations in Malang using a genetic algorithm.

Travelling Salesman Problem (TSP)
TSP problems are the problems that exist in the various fields that aim to find the shortest route to expedite travel or minimize costs [6] [11] [12]. The concept of TSP itself is through the points that have been planned at the beginning of the right one, and finally back to the starting point [3]. One form an extension of the TSP problem is more complex in the presence of other variables. Another variable that can be referred to the total travel time, operating hours, time of delivery, time availability [4], service time and arrival time [11]. Such problems can then be referred to as TSP-TW [12].
In this study the concept of TSP-TW is meant is the existence of different operating hours for each destination. So that limits the operating hours to consider the best approach to get optimal solutions rather than just looking for the shortest path alone.
Here are 27 tourist destinations to be set up these travel route for 3 days, where in a day will be scheduled to 9 tourist destinations with the start point from Brawijaya University Malang.

Time Window
In this research there are additional variables to be parameters as limit in the TSP problem that is time window. Time window is meant their operating hours at each destination. For convenience, the author made a 9 time zone starting from 05.00 until 23.00 where each section has a time interval of 2 hours. Below is a table part of the time and also the penalty calculation based on time window.  The purpose of the penalty on the time window is a time traveler arrives destinations outside of operating hours. For example if a destination 6 namely Batu Night Spectacular scheduled on solutions to chromosome 3 2 5 4 1 7 6 9 8 ... 20, means the time that traveler arrives at the third time zone which is 09:00 to 11:00 while the operating hours of these destinations on sixth time zone. It is penalized by 6 because travelers have to wait from time of arrival to the destination operating hours.

Genetic Algorithm
Genetic algorithm is an algorithm to looking for that has a concept as a mechanism of natural selection and biological evolution [2] [3] [4] [13]. Form of the approach taken by the genetic algorithm is to accommodate a wide choice of solutions in a population to obtain selection of the best solution in certain generation with the best fitness values [12]. Fitness value is a value that represents the quality of a chromosome in the population [3] [13]. The main problems in the application of genetic algorithm is to represent a solution to the problem in the form of chromosomes [2]. For TSP problem in this study, the  Each gene in a chromosome above represents a tourist destination then if combined in one string chromosome sequence travel route. In one chromosome there are 27 genes that are divided into three segments. Each of the 9 genes into one segment shows the journey for a day.

5.1
Initialization Initialize the initial population. P (generation) randomly to determine the size of the population (popSize) first. In this study, the authors define popSize = 100. The size of popSize is obtained based on the results of previous studies that has been done by Priandani and Mahmudy [12].

5.2
Reproduction Phase reproduction carried out to produce offspring. In this study, the stage of reproduction using crossover and mutation. Crossover process used is a one-cut-point with 2 randomly selected parent. While the mutation process used is the insertion of genes shift in position as much as 1 to the left. In this mutation process only takes one parent at random. Here's an example of crossover and mutation process on a small scale.

Evaluation
Evaluation phase conducted to evaluate how well a chromosome. How the chromosomes assessment is to calculate the value of fitness. Value of fitness of this research is produced with the following formula :

Information ∑D = Total Distance Traveled ∑T = Total Travel Time ∑P = Total Penalty
The travel time is the time it takes to get to that destination. The travel time of course is directly proportional to the distance. The smaller the travel time, the closer the distance. In this study, a congestion while traveling is not calculated. Total distance traveled is the sum of the overall distance destinations visited are then added to the distance from the start point to the first destination and the distance from the start point to the final destination. While Penalty is a violation of any difference interval time traveler arrives at the destination and destination operating. So that the penalty should be multiplied by 60 to get the number of minutes that is proportional to the travel time.
In this section, P1 become a sample data that chosen by authors. Here is an example of manual calculations in P1 (travel route in a day) with chromosome →11 14 7 22 5 8 3 26 9.  The results of manual calculations previously incorporated into the formula to get the fitness value.

Selection
This selection phase is the phase to select the best chromosome number popSize. The selection method used in this research is the replacement. The workings of the selection method of replacement is every child chromosome of result of reproductive and its fitness value is better than the fitness value of the parent, then the child will replace the parent in the next generation [3].

Testing Scenario
Based on the backgrounds, authors wants to optimize scheduling travel route some destinations in Malang City. To get the best travel route, we have to take the best components in genetic algorithm. So the optimal solution is generated with the best fitness value. The components in genetic algortihm includes the number of generation and the combination of reproduction operator. We can also do testing to get the best number of population, but in this study did not do the test because it has taken the best measure based on previous research. So, the authors conducted two testing scenario which is as follows: a. Generation testing with a multiple of 100 from 100 to 1000, popSize = 100, Crossover Rate (CR) = 0.5 and Mutation Rate (MR) = 0.5. In each test will be 10 times testing. Fitness value of each generation is an average of 10 times testing. The goal is to get a generation with the best fitness value. b. Test the combination of CR and MR between 0 to 1 by iterating the number of generations as much as 100. In each test will be 10 times testing. The goal is to get a combination of CR and MR with the best fitness value. In testing, the authors made 11 combinations of CR and MR as follows:

Conclusion
Based on test results, it was concluded as follows: a. The number of generation with the best fitness value is 800. b. The combination of CR and MR that produces the best fitness value is 8th combination with CR = 0.7 and MR = 0.3.


Implementation during design : Developing understanding about service realisation before implementation

Abstract Design has been mentioned as potential support in the shift from a value-in-exchange to a value-in-use perspective that is part of servitization. However, these discussions pay little attention to the role of design(ers) for implementing 1) the change in perspective of the organisation and 2) specific (product) service systems, which are both required for successful servitization. We argue that implementation as a concept needs to be part of service design processes in order to timely articulate how to implement new services, and what resources need to be shaped in service system(s) involved for successful value co-creation. We analyse a workshop in a technology-dominant service development project and show that using a service (process) perspective and concrete cases could be a way to integrate conversations about implementation in the design phase of PSS and service development. For technology-dominant services specifically, this can uncover factors for successful integration of technology and service.

Introduction
Servitization of a company's offering requires a transition from product to service focus (Vandermerwe & Rada, 1988;Baines, Lightfoot, & Kay, 2009), which means a transition from a value-in-exchange perspective to a value-in-use perspective (Vargo & Lusch, 2008;Grönroos & Gummerus, 2014). The role that design can play in such a transition in technology-dominant development and organisations has been discussed both in general (e.g. Verganti, 2009) and for a service context specifically (Candi, 2007;Sangiorgi et al., 2012;Calabretta et al., 2016). However, the focus in these works is on the design phase of service development projects. When it comes to the contribution of design with regard to implementing services as part of the transition to a service orientation, the complexity of this issue is discussed (e.g. Lin, et al., 2011, Calabretta et al., 2016Overkamp and Holmlid, 2016) but there is still much room for research (Teso and Walters, 2016).
In this paper, we contribute to this discussion by introducing the concept of implementation during design and presenting ways to start conversations about realisation of service as value-in-use (Grönroos & Gummerus, 2014) already during both the design and definition of service and productservice systems development projects.
More specifically, we analyse conversations during a workshop that was part of a technologydominant B2B service development project, which is aimed at improving troubleshooting on trucks and buses. We look specifically at what understanding about service realisation is developed in the conversations.
The paper is set up as follows: first we give a brief background to servitization and product-service systems (PSS) as a part of that transition. We present benefits and barriers of servitization, what design can contribute in this transition and how implementation could be part of the design of product-service systems. Then we present the setup of the workshop that was organised and analyse the results in terms of conversation topics during the workshop and how these are relevant for successful service implementation. Based on this we suggest how implementation as a concept can be(come) part of service design processes and what role designers could have in this.
Servitization thus involves a shift from a value-in-exchange perspective to a value-in-use perspective, where a consumer does not necessarily own the product(s) in the service (Baines et al., 2007). In other words: consumers do not necessarily own the operand resources in the service (Vargo & Lusch, 2008). Becoming what Oliva & Kallenberg (2003) call a "pure service organisation" entails shifting focus from transaction-based services to relationship-based services on the one hand and from professional to operational services on the other hand. The mind-set of a company has to change from increasing market share to developing strong relationships with the most profitable customers (Wise & Baumgartner, 1999). This requires not just a change in offering, but also a change in the focus of the organisation (Brax, 2005, p.152), which entails changes in the company's processes and capabilities (Baines et al., 2009;Huikkola, Kohtamäki, & Rabetino, 2016).
Such a change in mind-set is considered beneficial for the organisation from a financial, strategic and marketing perspective (Vandermerwe & Rada, 1988;Vandermerwe, 2000;Oliva & Kallenberg, 2003;Brax, 2005;Baines et al., 2009). However, there are also challenges and barriers for servitization (Mathieu, 2001) and the level of success that companies can achieve with (a transition towards) offering product-service combinations also depends on the characteristics of the products that these companies produce and the context of use for those products (Jovanovic, Engwall, & Jerbrant, 2016). Furthermore, the required mind-set change can be difficult, both for provider and customer (Baines et al., 2007;Beuren et al., 2013;Mont, 2004). Companies can have difficulties seeing services as a source of income rather than a cost (Gebauer, Fleisch, & Friedli, 2005) or lack the knowledge or human resources to develop and implement services successfully while maintaining a constant level of service quality (Annarelli, Battistella, & Nonino, 2016;Gebauer, Fleisch, & Friedli, 2005). Customers can be reluctant to give up ownership, especially if it has symbolic status (e.g. with cars) (Mylan, 2015).
Still, implementation of product-service systems is proven to be difficult (Jovanovic et al., 2016) and is increasingly being mentioned as a topic for future research (Annarelli et al., 2016). It is acknowledged that "better understanding of issues concerning implementation and monitoring of PSS, definition of the roles and capabilities of the stakeholders involved" are amongst the challenges that PSS development faces (Vasantha, Roy, Lelah, & Brissaud, 2012). Yet, companies often focus their efforts on designing product-service systems, rather than working towards implementing them. (Kindström & Kowalkowski, 2009). Ideally implementation is a topic on the agenda before the project arrives at the delivery and sales stages (ibid.). In other words, during design time or development time of a service, rather than during implementation time or performance time of the service (Holmlid, 2012). Developing this knowledge well in advance can for instance allow managers to anticipate the need for additional staff, which reduces risks of service quality erosion and helps prevent sunk cost fallacies (Gebauer, Fleisch, & Friedli, 2005). Concrete suggestions regarding how to facilitate conversations regarding implementation during design are, however, mostly missing, Halse et al. (2010) being one of the exceptions. Therefore, we investigate how the concept of implementation can be introduced during the design of services and what role design(ers) could have in this.

Method
We are involved in a technology-dominant service development project that is aimed at improving the process of troubleshooting and repairing heavy vehicles (trucks and busses), using a combination of advanced algorithms and the introduction of new steps to the process of troubleshooting. Both the existing and the new service are product-service systems. The existing service of troubleshooting and repairing can be seen as product-oriented service (Mathieu, 2001;Tukker, 2004). Elements of the new service include the possibility to monitor the condition of the vehicle and an extension of the existing call centre role of the organisation's helpdesk (focussed on connecting driver and workshop), to include remote troubleshooting in the future version of this helpdesk role. Both are elements of an intermediate service (Huxtable & Schaefer, 2016).
We conducted a workshop in this development project. During the workshop, five members of the development team participated (the project leader, three engineers and one computer scientist), who are responsible for the development of different parts of the technology required in the service. The workshop was facilitated by one of the authors. The workshop took four hours and the workshop programme and times for each part are detailed in Table 1.
The workshop was video recorded and this recording was transcribed verbatim. The author who facilitated the workshop went through the transcript once and inductively coded it (Bernard, 2006), in an approach based on Grounded Theory (Strauss & Corbin, 1998): the codes were iteratively made and grouped, and the emerging categories tested on the remainder of the data, to end up with a small number of themes in the end (Creswell, 2014). Then, the authors held an analysis meeting where they went through the transcript and discussed their findings. Finally, a compilation was made of the initial and shared insights from the data. The focus of this paper is on the conversations that took place in the group during assignments 2 and 3. Since assignment 1 formed the warm-up for assignments 2 and 3, we briefly discuss its setup and contents here. During assignment 1, participants were given an A3-size paper on which two steps in the process were pre-printed (see Figure 1): problem with a truck (left) and problem solved (right). Each participant was asked to draw what they thought the future process of troubleshooting and repair would look like if the technology is successfully developed and deployed. The aim with this assignment was to let each participant individually think about what the service process should look like according to them. This allowed them to form their own opinion, before the conversation in the group in assignment 2.
At the end of the assignment, each participant presented his/her individual view on the service process, to let all participants get an idea of each other's views on the process. Assignment 2 -Mapping of the collective process view During this assignment, the individual views were combined into one collective, generic process view for the service process, which was developed on a whiteboard. For this process view, the workshop leader used a template where the process was divided into four rows (see also Figure 2), lightly based on Grönroos' (2008) definition of service: • Actions: what happens in a specific step in the process?
• Goals: what is the aim of the step?
• Actors: who/what is involved in each step?
• Resources: what is needed in each step, in terms of tools, information, etc.?
The participants were first asked to look for similarities amongst their individual process views from assignment 1 and then mention steps to fill possible gaps that remained in the process. The collective view was built up layer by layer: the layer actions was completed before moving on to goals, etc. These layers were not pre-printed, to be able to deal with them one at the time, to prevent that people would directly go into details for one step and to allow flexibility for the workshop facilitator in terms of what layers to focus on. The beginning and endpoint we printed and glued on post-it notes. The author who facilitated workshop facilitated the dialogue, but had a passive role in the creation of the content of the process view. Assignment 3 -Testing the collective view In this assignment, the collective, generic view was assessed using scenario cards. The scenario cards contained information about an aspect of the context in which a problem with a vehicle occurred (see Figure 3). These contexts were described from the perspective of one of the actors involved (e.g. driver, owner, mechanic, etc.). During the assignment, the group members discussed what the specific instance of the generic service process from assignment 2 would look like, given the particular situation described on the scenario card. The situation descriptions on the cards were based on observational and interview data collected by of one of the authors during a one-week contextual study at a garage for trucks and buses.

Resources
For this assignment, the participants were divided into two groups, where people working together on a specific aspect of the technology were distributed over the two groups, to create a spread in the views and perspectives during the dialogues in the two groups. Both groups drew their scenario cards randomly from one stack of 17 cards. The instructions were given verbally and handed out in print, as reference for the groups.

Results
Here, we present what was discussed during assignments 2 and 3. We focus on the dialogues regarding value (co-)creation and roles of the service actors.

Assignment 2
The second assignment led to the formation of a collective, generic view of the service process, based on the individual views from assignment 1 (see Figure 4).

Figure 4. Result of assignment 2, where the individual views are combined into one collective view, starting from when there is a problem with a truck (left-hand side) and ending when the problem is resolved (right-hand side) The process view on the whiteboard contains information from the dialogue regarding what actions should be taken in the service process, by which actors and what information is needed in those actions.
On a general level, the development of the collective view of the service process meant that participants made aspects of the service more concrete, which lead to questions and the discovery of knowledge gaps: More specifically, the participants mostly talked about: value creation and co-creation, roles of the service actors, relations between the existing and the new service, and context of the service process. Due to space limitations, we focus on first two topics, below.
The participants talked both about value co-creation through direct interaction between actors and value creation through indirect interactions (Grönroos & Ravald, 2011). Value co-creation was, for instance, discussed by participant #2: Situations where an actor uses information provided by the software as a resource for value creation were also discussed: Participant #3: it is some person there with some skill, taking the information and making something useful of it.
Participant #2: the backoffice support or the algorithmic explanations that you can assist this person with.
Furthermore, participants talked about the specific interactions that would take place in a touchpoint and what the outcomes of those interactions should be: Participant #4: as I see it, when the truck comes to the workshop, everything is prepared with spare parts and tools and… set up and everything and then they just fix it and send it When defining value (co-)creation and interactions in touchpoints, participants also discussed who would interact with whom and how. They talked about (their view of) actors in the service today: Participant #2: that's the person or the call centre the driver contact when they get a problem and they hook up the driver with the appropriate workshop.
Participant #2: they might have at the workshop some person that has the role of preparing the jobs.
The participants also defined actor roles for the future service: Participants also defined the responsibility, decision making, and tasks of the actors:

Participant #3:
Probably it's the mechanic, together with the driver that decides "okay, now it is okay, this truck." Participant #1: that when you schedule a time and when you have a handover to the workshop then who is going to take care? So, it's kind of a decision of who is going to solve this problem.

Assignment 3
Just as during the development of the generic process view, participants voiced questions and uncertainties regarding the dynamics between different actors and what would be ideal from the perspective of a certain actor: Participant #2: how does the system learn that we have frozen goods? (…) We need to ask that, I guess. And of course, being able to input and…do something useful with it. Participant #5: But the driver must tell [the future] helpdesk that.

Participant #3:
When I thought about this, I didn't think the system had this information. That was the [future] helpdesk who knew this.
Besides this, the conversations focused on the concerns of actors: Participant #2: So, driver is stressed, I guess. Or concerned, at least.

Participant #4:
Shortly the card says that it's a demanding customer that wants to know every next step: what the cost will be and what to do.
Related to this, participants discussed how the technology could (be made to) support value creation of different actors: Participants #2: you have this information that you have a work plan and that you have all the deadlines, in order to get the troubleshooting tool useful in making the recommendations. In some way, [the troubleshooting tool] needs to consider these circumstances.
Participant #3: it might be possible to design the system like that, that the system doesn't have [contextual information], but then it needs to be able to give sufficient decision support so that the user that has this additional information can still make a decision.

Discussion
Based on existing literature, we identified a need to make implementation as a concept part of service design, in order to timely articulate how to implement a new service, and what (and how) resources need to be shaped in the service systems involved, for successful value (co-)creation. The dialogues during the workshop include aspects that are relevant for successful realisation of the service.
Firstly, roles and responsibilities of the different actors (including non-human actors) were defined, including whether these actors co-create value in direct interactions or create value for themselves through indirect interactions (Grönroos & Ravald, 2011). This points to what resources need to be shaped in which service system to make this value co-creation and value creation possible.
Secondly, the participants discussed how the technology should be integrated in the service, in order to successfully realise the technology's role in value (co-)creation. This provided insights and questions that are relevant for further development of the technology and defining which functions should be included in the software. For technology-dominant service development processes in particular, such conversations are valuable for further technology development and deployment.
Thirdly, the service perspective taken in the workshop made it possible to discuss functions on service level, rather than a technology level alone. This meant that it could be discussed whether a certain function of the service should be achieved through deployment of the technology or realised by a human actor. For instance: To be able to give good advice on a course of action, should knowledge regarding the context (e.g. truck has frozen cargo) be entered into and considered by the software or should this information remain with a human actor (e.g. the helpdesk personnel). Thereafter, it is possible to discuss what resources thus need to be shaped in which service system, to make them available for either value co-creation or value creation.
A common denominator in these dialogues is that they surfaced when making elements of the service process concrete, which participants were asked to do in the workshop. During this process, the participants made assumptions and raised questions about elements of the service -today and in the future -that the participants themselves did not know enough about. Towards implementation, such assumptions need to be checked and the knowledge gaps need to be filled. If an incomplete image of current service systems remains in place throughout the service development process, this poses the risk of wrongly defining which resources need to be shaped in today's service systems (and how), in order to prepare these systems for (their role in) value (co-)creation in the future.
A role for designers in implementation during design could be to collect these assumptions and test them, as well as gathering unanswered questions, finding out who can answer them and involving these actors in the service development and implementation.
The combination of the generic service process perspective and the specific cases on the scenario cards also made it possible to discuss the variety that could take place in the service. Yet, not all elements of a service were caught during the workshop. In part, the participants were aware of this: Several actors in the service were not mentioned in the dialogues (e.g. customer of the transport company). It is not clear whether the participants were aware of this.

Conclusion
Servitization and the transition towards offering product-service systems is potentially beneficial for production-based companies. However, there are barriers for this shift to take place. Furthermore, to increase the odds of achieving successful value (co-)creation in product-service systems and services, their realisation should be a topic of discussion before they are being implemented.
Therefore, we argue that in order to timely articulate how to implement service systems, and what resources need to be shaped in the service systems involved, implementation as a concept needs to be part of service design processes.
In this paper, we investigated how conversations regarding realisation of a service could become part of the development process for these services. We have shown how making a generic representation of a future service process and assessing this with specific scenarios, can provide support for articulating value (co-)creation process, actor roles and responsibilities, as well as point out questions and knowledge gaps that need to be considered for successful service realisation. This research thus contributes to addressing the challenges in PSS and service development that are related to implementation in general as well as the definition of service (actor) roles and capabilities specifically.
Since service implementation has not been researched extensively in service design research, there are ample interesting topics for future research: How can an implementation focus be introduced early stages of a service development project? What understanding of future value co-creation situations can be developed in such early stages of service development and how could this knowledge be used towards service implementation? How do service designers already work with implementation during early stages of service development and what are additional ways in which they can do so?
For technology-dominant services and product-service systems in particular, we have shown that mapping the service process can also uncover aspects that are relevant for successful integration of the technology in the service process. Discussing technology development from a service perspective also opens up for a dialogue regarding where certain service functions should lie; in the technology or with another service actor.


MODELING INFORMATION FLOW IN THE SUPPLY CHAIN OF STRUCTURAL STEEL COMPONENTS

Accessing the required information in the supply chain of structural steel components is critical for minimizing costly reworks and delays. This paper identifies the information items generated in the different phases of the supply chain related to structural steel components and formalizes the process of producing and using this information. Precise details about different features of the components (e.g., their geometry and weight, connection details, cutting/bending/ punching requirements, and the type and grade of the material) are set in the various tasks performed in the different phases of the supply chain. Regardless of whether one uses paper-based systems or advanced technologies such as smart tags and radio-frequency identification (RFID), a better understanding is achieved of the processes through which a structural steel component passes. The results of this research can be used to streamline the information flow in the supply chain of structural steel components, regardless of the type of tracking technology used, hence reducing delays and reworks.

Introduction
A variety of information items about building components need to be generated by, and transferred between designers, fabricators, and contractors in the various phases of the supply chain such as procurement, shipment, and erection. Accessing and exchanging component-specific information is important in streamlining the information flow between parties and in reducing costly reworks and delays (Ergen, Akinci 2008). For structural steel components that are fabricated off-site and shipped to job sites, access to and exchange of information becomes even more critical as structural steel components are costly to reproduce in case of a rework. For a standard steel building project, it takes about 15 hours, on average, to produce a ton of fabricated components (which corresponds to 18.6 m 2 of a steel building's area); fabrication costs are variable with materials constituting 30-35% of the fabrication cost (AISC 2016). Given that a large highrise steel building requires tens of thousands of tons of steel, the rework associated with these components could be quite high (AISC 2016).
A structural steel component consists of either single members such as profiles and plates that have been punched or bent according to specifications, or assemblies that have been fabricated using profiles and plates. During fabrication, shipment, and erection, various questions about components must be answered in a timely manner. Examples of such questions include: "where is a component of interest with respect to the supply chain?", "what are the connecting components to an assembly of interest?", and "in which truck will a component of interest be delivered?". In current practice, information about structural steel components is generally exchanged on paper-based documents, such as a cutting sheet attached to a component during fabrication or a delivery invoice during shipment or at the erection stage. This practice is not efficient, as these documents can potentially get lost while components are being transferred from one location to another. It is not easy to access and exchange information in a paper-based approach. Consequently, it is difficult to see at what phase of the supply chain these information items are generated, and at what phases (and in which specific tasks) these information items are used/modified as components move in the supply chain. Modifications made to components during the preceding phases are either not recorded or are stored on different documents, which also make it difficult to locate and access the information in succeeding phases. Hence, various location identification technologies have been used that can provide component information efficiently whenever needed, and that can streamline the information flow accessed by and exchanged between parties during the life cycle of a component. To implement such technologies for structural steel components, an essential first step is to identify what information is generated and shared as structural steel components move in the supply chain, and to identify the tasks in the supply chain that necessitate generation of such information. Therefore, the research questions are: "What are the information items generated in the different phases of the supply chain related to structural steel components?" and "How is the information flow set up within and between the phases of the supply chain?". For this purpose, a process model is proposed in this paper to manage the flow of structural steel components through the supply chain, from design to erection.
Although all engineered-to-order components (such as escalators, elevators, Heating, Ventilation and Air-Conditioning (HVAC) systems, precast concrete components, and structural steel components) go through the generic phases of the supply chain such as design, fabrication, shipment, and erection/assembly, this research takes a step further to detail the processes in each of these phases for structural steel components and to define the information items that are generated and exchanged throughout the processes. While all engineered-to-order components go through the generic phases of the supply chain, the processes largely depend on the type of engineered-toorder component (e.g., escalator, HVAC, concrete components, steel components). The processes that are typical to structural steel components (such as using plates and profiles, cutting, bending, punching, drilling, riveting, welding, etc.) are unique when compared to the processes typical to precast concrete components (such as preparing molds, placing reinforcements, mixing concrete, pouring concrete, vibrating, curing, testing concrete, etc.) and cer-tainly much different when compared to mechanical systems. Recognizing these processes in the supply chain of structural steel components along with the information needed to perform these processes adequately would be most welcome for practitioners in the steel construction field. This research is performed in response to this need and is unique. Its objective is to investigate the information flow in the supply chain of structural steel components by identifying the information items in each phase of the supply chain and providing an analysis of when and where information is generated and used.

Assembly fabrication process
A structural steel assembly is composed of several individual members that are bolted or welded together. If one traces a structural steel component in the design, fabrication, shipment, and erection phases, one can observe that information items generated in early phases of the supply chain are used frequently in downstream phases. For example, in the manufacturing plant, various design-related information items are needed in order to cut, bend, and weld the raw steel materials into assemblies such as the one seen in Figure 1, with an assembly identification number of "A/216".
The information items created and used in the various phases of the supply chain are provided in Table 1. This table shows that the information items are often  Information about connecting plates and profiles (such as the location of connecting plates/profiles, the shape and dimensions of the plates/profiles, the dimensions and shape of the resulting assembly) is specified in the design phase. This information is needed to make the connections by cutting, punching, and welding individual members. In the traditional system, workers get the related information from hard or digital copies of relevant drawings. Such manual searches result in unnecessary time spent to access information. If one considers a large project with hundreds (maybe thousands) of assemblies, the manual search process becomes very cumbersome. Technology can help to eliminate such inefficiency.
In addition to the information generated in the design and fabrication phases, new information is generated in the shipment phase to be used not only in the shipment phase but also in the erection phase. For example, information must be available about the size, weight, shape and identification (ID) number of the assemblies to locate them in the storage yard, and to develop package lists for shipping, including package IDs, the list of assemblies and connections in each package, on which truck each package is loaded, etc. Such information is needed when a truck reaches the job site. Making packages for shipment is a complex operation that may require timeconsuming visual searches to locate the assemblies in the storage yard and that may end up with packages that contain the wrong or missing assemblies.
Once the structural steel assemblies arrive at a job site, they are stored at a storage yard until the day they are needed for erection. At the job site, workers need to know where the assemblies are stored, their final erection location (e.g., on which floor, at which column/beam intersection), and connection details (e.g., the number of bolts, size and type of bolts, welding specifications). If a manual search is used to locate an assembly in the storage yard and access the related information, mistakes are inevitable, leading to inefficiencies such as lost assemblies and reworks.
To summarize, in steel building construction, assemblies are designed by design firms, put together by fabricators, sent to the construction site by shipping agencies, and erected on site by contractors. Each one of these participants generates information to be used not only by themselves but also by participants involved in downstream activities. The current manual system of accessing and exchanging this information is prone to mistakes, causing delays, costly reworks, and inefficiencies. These problems can be minimized if the four participants know the nature of the information that is to be generated at each phase of the supply chain and if this information is exchanged in an efficient way.

Background research
This research builds on and extends studies performed in relation to: (a) structural steel supply chains, (b) data standards for information exchange, and (c) representation and exchange of structural steel information in steel building construction.
Research into lean principles and techniques indicates that construction supply chains are different than manufacturing supply chains. This research investigates on-site/ off-site manufacturing, the types of parties involved in the chain, inter-organizational relationships, and volumes of production (e.g., Aziz, Hafez 2013;Vrijhoef, Koskela 1999;Koskela 1992;Bertelsen 2004;O'Brien et al. 2002;Arbulu et al. 2003;Naim et al. 1999). Lean principles that are suggested for improving construction supply chains include just-in-time manufacturing, dependability and variability analysis (e.g., Tommelein et al. 1999), standardization of preassembly practices (e.g., Arbulu, Ballard 2004), bringing a systems perspective to the supply chain (e.g., Wang, Riley 2016;Bashford et al. 2003;Wegelius-Lehtonen, Pakkala 1998), and flow modeling (e.g., Tommelein et al. 1999). These studies provide an understanding of the bottlenecks in construction supply chains, and of the factors that affect the flow of materials and components through the supply chain. The research presented in this work builds on this foundation and focuses on the identification of the information that should be flowing along with the components in the supply chain for structural steel components. There is only a limited number of studies that focus on the supply chain of structural steel components (e.g., Tommelein, Weissenberger 1999;Furlani, Pfeffer 2000). The need persists to identify the information that is critical to tracking structural steel components and to improving the process in the supply chain.
Research into the utilization of information technology (IT) and tracking technologies in improving construction supply chains, include information systems that capture the status of the order and information about components (e.g., Omar, Ballal 2009;Jang, Skibniewski 2008;Lin, Tserng 2001), and tracking technologies to identify the location of components (e.g., Park et al. 2016;Ergen et al. 2007;Wang et al. 2007;Shin et al. 2011;Furlani, Pfeffer 2000). Using empirical approaches, these studies demonstrate tangible improvements over traditional supply chain management practices in terms of time and money. Some of these studies identified what information to track for different types of components, such as precast concrete members, but not structural steel components. These studies are complementary in nature to the research presented in this paper in terms of flow modeling, but the information that is needed to track structural steel components needs to be identified. Hence, the research presented in this paper focuses on the identification of information needs for the structural steel supply chain.

Research on data standards for information exchange
The architecture/engineering/construction and facility management (AEC/FM) domain is rich in terms of data standards and parametric modeling systems. Among these, the data standards that are specific to structural steel include industry foundation classes (IFCs) and CIMSteel Integration Standards (CIS/2). These two major data standards help with the exchange of structural steel component information between parties throughout the supply chain. CIS/2 is an aspect model that is aimed at exchanging structural steel project information for all the parties involved in the supply chain (Eastman 1999) whereas IFCs target all phases of a construction project to support information needs for all parties involved, hence are more generic in scope (BuildingSmart 2015). With CIS/2, it is possible to exchange information about (a) analysis results such as nodes, element connectivity, section profiles, loads, material properties, forces and displacements; (b) a detailed design model, which incorporates physical representation with materials all the way to stairs, decking, and clip angles; and (c) a detailed model with fabrication information about bolts, welds and holes, their locations with respect to parts/assemblies, assembly information (what parts belong to what main member, location relative to the assembly, and location of assemblies in a global coordinate system) (Lipman 2009).
Though IFC does not focus on structural steel members specifically, it is capable of representing geometric, material and connection-specific information explicitly. For example, for a T beam, IFC is capable of representing all information associated with that beam using ifcBeam.
The data standards and delivery manuals can be leveraged to identify information items about structural steel components. However, these standards and manuals do not necessarily show in what phases of the supply chain these information items are generated. The study presented in this paper provides an overview of where each information item is generated in the supply chain, and which information is referred to in the subsequent phases, so that it will be possible to track the information to its origin, hence eliminating bottlenecks in the information flow process.

Research on information flow and modeling approaches
Various researchers have studied the information flow and process modeling of supply chains of different types of components such as pipe supports, precast concrete members, mechanical, electrical and plumbing components (e.g., Zheng et al. 2015;Arbulu, Tommelein 2002;Cheng et al. 2010;Ergen, Akinci 2008;Sacks et al. 2002). For example, Ergen and Akinci (2008) created an information flow for precast concrete components. By setting up four different information flow matrices, one for each phase of the supply chain (i.e., design, fabrication, shipment, and erection). They categorized the information items into design information, material information, component quality control (QC) reports, and coordination information. On the other hand, Arbulu and Tommelein (2002) showed five possible supply chain configurations for pipe supports used in power plants. Although they illustrated the process models for each configuration of pipe supports, they did not present the information items. These studies focus on pinpointing inefficiencies in the supply chains by developing detailed models of the processes (e.g., Arbulu, Tommelein 2002) and identifying information that flows with the components, as components move in the supply chain (e.g., Zheng et al. 2015;Ergen, Akinci 2008;Sacks et al. 2002). The research presented in this paper is complementary to these research studies in terms of process model development. However, it differs from the existing studies in that it studies the supply chain of structural steel components.
In addition to the research studies that focus on information flow modeling in AEC/FM supply chains, some research studies propose process/workflow modeling and data flow modeling techniques and approaches. Process modeling approaches are of various types, and are mainly developed for business process modeling. For example, The Action Port Model workflow enables the capturing of work processes using actions/tasks (as input, process, output) including time (e.g., absolute time, delays), resources (e.g., actors, tools, objects), external actors (e.g., people, systems), various flow types (e.g., triggering, terminating, singular) and conditions (e.g., a statement to be checked as true or false) (Traetteberg 1999;Carlsen 1998). Similar content is captured by various other workflow models such as Trigger models (Joosten 1994), State charts (Schumann, Michael 2009), FlowMake (Sadiq, Orlofka 1999), Action workflow (Medina-mora et al. 1992) and UML (Wirtz et al. 2000). The majority of these modeling approaches are task specific, but have limited capabilities in terms of information representation. The modeling tools that are specific to representing information flow processes include C-Wf models that are capable of capturing information in a domain and mapping this information to processes (Bastos, Ruiz 2001), data flow diagrams that are capable of showing the flow of data in an information system (Ambler 2004), design structure matrices that show the information generated in processes leading to its use in a given set of processes (Browning 2001), and unified modeling language (UML) that has a wide variety of standard modeling tools that can be integrated to represent process and information models (Hruby 1998a(Hruby , 1998bWirtz et al. 2000). In this research project, a UML based process modeling tool is used to show the dependencies between activities.

Methodology of the study
In order to identify the information about structural steel components that is accessed by and exchanged between various parties, first of all, the process and the information flow within this process need to be identified. A process model is roughly the anticipation of what the process will look like (Rolland, Pernici 1998). Here, the process model incorporates the stages that a structural steel component passes through from design to erection. In order to identify the process and the information that is generated at each phase and that is accessed and exchanged in each subsequent phase, three different companies were contacted (see Table 2). Company A was an engineering design and fabrication firm, specializing in the design of heavy steel structures used in airports, bridges, commercial buildings and industrial plants. Company B was also an engineering design and fabrication firm, but specializing in the design of energy structures such as energy transmission lines, energy distribution networks and power distribution centers. Company C specialized in light weight steel fabrication for warehouses and housing units. All three companies were directly involved in the shipping of the components, and worked closely with contractors in the erection phase. As can be seen in Table 2, the company specializations, as well as the types of components being designed and fabricated, were different. This variety helped in constructing a generic process and information flow that can also be generalized for other companies working in the same field.
Three different methods were used to access and extract information from the said companies. The research methods included face-to-face interviews, ethnographic observations, and examination of frequently used documents. A summary of these research methods is provided below.
Face to face interviews: A face-to-face interview is a qualitative research method that involves in person interaction with a participant through a semi structured questionnaire (Opdenakker 2006). This method was selected because it eliminates misunderstandings and misinterpretations of the questions posed. Face to face interviews were conducted with site managers, site engineers, engineers, foremen and workers throughout the design, fabrication, shipment, and erection phases: -In the design phase, nine design engineers were interviewed.
They were asked what information items best characterize their tasks, and what information they generate for structural steel assemblies. -In the fabrication phase, three foremen and twelve workers were interviewed. They were asked what information they expect to receive from design engineers when they procure structural steel assemblies and what additional information they generate in the fabrication phase that is to be used in upcoming phases. -In the shipment phase, two foremen and three workers were interviewed. They were asked how they locate structural steel assemblies on the storage yard of the fabricator, what information they expect to receive from design engineers and fabricators, and what additional information they generate for use in the erection phase. -In the erection phase, two site engineers, three foremen and fifteen workers were interviewed. They were asked how they locate components stored on the construction site, what information they expect from design engineers, fabricators, and shippers, and what additional information they generate for use by the inspection team and facility managers.
Ethnographic observations: This method is an important part of qualitative research, allowing researchers to closely observe and study a particular culture or group in order to better understand the customs, social structure and habits of the people (Richards 2010). This method was used to closely observe and study the works performed during the design, fabrication, shipment and erection of structural steel assemblies in order to define the tasks that are necessary to put together a structural steel assembly, as well as the information generated and used in these tasks.

Examination of project documents generated:
In this research method, the contents of the documents issued in the different phases of the supply chain were analyzed. These documents included assembly lists, drawings, fabrication details, packaging and shipment documentation, and on-site paperwork.

Proposed information flow model
A detailed process model is presented in Figure 2, in which structural steel components go through the design, fabrication, shipment, and erection phases of the supply chain. This figure expressed in a UML (Unified Modeling Language) activity diagram provides a stand- In this diagram, each task is given an ID composed of a letter that identifies the phase (D for design, F for fabrication, S for shipment, and E for erection) and a number that denotes the order in the process. For example, task F4 represents "check dimensions", the fourth task in the fabrication phase. The information generated in each task and used in subsequent tasks is shown in Table 3 with references to tasks in the process model with task IDs.
The design phase starts with a request for a steel structure from an owner (task D1). Upon this request, the design firm obtains the information such as loads, soil conditions, location and wind information, etc. required for an initial feasibility analysis (task D2). After, the agreement between the design firm and the owner is signed, the detailed structural design and analyses are performed to determine dimensions, cross sections, and types of the structural component (task D3). Shop drawings are prepared for the fabrication of plates, profiles, and assemblies (task D5) when the design is approved by the owner (task D4). Most of the information items related to structural steel components are generated in the design phase.
The fabrication phase starts with sanding and blasting the raw materials before fabricating the structural steel components (task F1). Raw materials are cut into profiles or plates (tasks F2 and F3) and after passing from a quality control in terms of cut dimensions (task F4), they are given unique cold pressed plate/profile IDs (task F5). Next, if the component needs a hole, it is sent to a hole-bench (task F7) equipped with a punching machine (task F8). Otherwise, it is sent directly to the bend-bench (task F9) for bending (task F10) if the component has a bending requirement. The punched and/or bended structural steel components pass through another quality control to double check the location and size of the punching and bending (task F11). Once the components are good in terms of cutting, punching and bending, they are kept in storage until they are picked for pre-assembly (task F12). Pre-assembly starts by locating the profiles and plates kept in storage and bringing them for pre-assembly (tasks F13 and F14). During pre-assembly, workers center the profiles and plates according to the shop drawing of the assembly, tentatively weld the plates/profiles to main components and cold press ID numbers on the assembly (task F15). The quality control crew checks the pre-assemblies for their correctness before the final assembly (task F16). Checked and preassembled structural steel components are welded in to their final forms (task F17) and cleaned to remove excess weld. Final welds are also checked against the thickness and size stated in the design drawings (task F18). All checked assemblies are sent to the paint shop (task F19), pass through a paint quality control for required thickness (task F20), and are kept in storage until shipment day (task F21).
The shipment phase is the third phase that a structural steel component passes through in the supply chain. It starts with preparing packaging lists that show which structural steel components and associated connection members will be in a package (task S1). The assemblies that are stored in the yard are found and sent to the shipping area (task S2) for packaging. Each package is set up such that similar components (in terms of size and shape) are put together. Each package is also given a unique ID. Once all components in a package are found in the yard, the package is prepared and sealed (task S3). The packaged assemblies and other components are loaded on tractor-trailers (task S4). Each tractor-trailer is weighed in order to record the total weight of the material (task S5) before it is shipped to the job site (task S6). When the steel components arrive on a job site (E1), packages are counted (task E2) and components in each package are found by matching cold pressed numbers to the numbers listed on the delivery receipt. All components are checked for any apparent damage or discrepancies before being accepted (task E3). All delivered structural steel components are stored in a location on the construction site unless it a just-in-time system is in place (task E4). For final erection, the required structural steel components and connections are located in the storage yard (task E5) and by using the erection information in the drawings, they are erected in their final locations (tasks E6 and E7).
The information items generated and used in each task are listed separately in Table 3. This information is organized in terms of component type (plates/profiles, assemblies and packages). As shown in Table 3, the information generated and used can be grouped under identification (ID) information (to identify and locate a plate, profile or assembly in the supply chain); geometric information (such as dimensions, shapes, areas of plates, profiles or assemblies,); weight information (weight of each plate, profile or assembly to keep track of produced, shipped, and erected components); connection information (types, location and size of connections between plates/profiles and assemblies, and between assemblies); cutting/bending/punching information (any information required to cut, bend and punch plates, profiles and assemblies); and material information (any information related to material characteristics, such as steel grade and type). This categorization is quite different than the categorization set up by Ergen and Akinci (2008) for precast concrete components because of the special conditions in the supply chain of structural steel components.
The information generated in the design phase constitutes as much as 86% of the total information generated about the supply chain management process, and is used not only in the design phase but also in the subsequent three phases (i.e., fabrication, shipment, and erection). On the other hand, the information generated in the fabrication phase constitutes only 8% of the total, and is used in the subsequent two phases. (i.e., shipment and erection). Similarly, the information generated in the shipment phase constitutes only 6% of the total, and is used in the last phase (i.e., erection). As seen in Figure 3a, of the information generated in the design phase, most is either geometry-related (33%) or cutting/bending/ punching-related (23%). The information generated in the design phase is used in all the phases considered in this research, including fabrication, shipment, and erection.
According to Figure 3b, 75% of the information generated during the fabrication phase is related to cutting/bending/punching, and 25% to the type and grade of the materials used. On the other hand, Figure 3c indicates that 66% of the information generated during the shipment phase is related to weight, a very important piece of information for trucks with limited capacities; only 34% of the information relates to identification. The information generated in the fabrication and shipment phases is used only in these phases.
It is observed that the information generated in the design phase is frequently used in the remaining phases and should be paid extra attention to in terms of correctness and accuracy. An approach that streamlines the flow of design-related information throughout the supply chain is expected to improve supply chain efficiency. One can see in Table 3 the phase in which an information is first generated, and whether it is used in other phases.

Validation of the model
The information flow model presented in this paper was used in field tests in five different projects that used RFID technology in the design, fabrication, shipping, and erection of various steel components in heavy steel structures (Akcay, Ergan 2013). The projects consisted of a highrise residential building of 40 floors, a stadium that could hold 30,000 spectators, an international airport terminal, a financial and trade center, and a shopping mall. The RFID system was used in all of the five projects as an experimental tool. Figure 4 shows a steel assembly with an RFID tag being unloaded in one of the construction sites. Five different types of projects undertaken for five different owners by five different designers and contractors were selected for the study in order to assess the effectiveness of the system in different environments.
The project manager of each project and a total of 14 designers, 21 foremen, 17 site engineers, and 36 workers were interviewed on the average three times each for periods ranging from half an hour to two hours, concerning supply chain activities in the design, fabrication, shipment, and erection phases. A semi-structured questionnaire survey was administered to the participants to elicit Fig. 3(a). Information generated in the design phase  information about the benefits of the RFID system and the information flow model used in the implementation.
The reactions from all the participants in the survey were favorable. They pointed out that compared to the traditional manual system, the RFID-based system had tangible advantages in terms of reduction in time to locate components, reduction of human errors, increased accuracy for accessing information about components, and ease of handling the many different components. The participants indicated that the information flow model presented in this paper and that was used to populate the RFID tags was considered to be one of the most important factors that contributed to the success of the system. Many of the advantages of the RFID system could not have been realized was it not for the information flow model that allowed the participants to have access to the right information in a timely fashion. In addition to these interviews, ethnographic observations were conducted. The feedback received from the participants interviewed indicates that the outcome of this research can be used to streamline the information flow in the supply chain of structural steel components, regardless of the type of tracking technology used, hence reducing delays and reworks.

Conclusions
This paper presents a typical information flow model of structural steel components through the four phases of a supply chain that include design, fabrication, shipment, and erection. The information items used in the model are generated and referred to in various phases of the supply chain. The primary contributions of this research include: (a) the formulation of an information flow process for heavy and light weight structural steel components (profiles, plates, and assemblies), a process that is extensively discussed in the literature for precast concrete components, but seldom for structural steel components; (b) the identification of information items generated and exchanged in the different phases of the supply chain, drawing attention to the work of the professionals generating the information in each phase; and (c) the analysis of the source and the destination of information from design to erection, highlighting the importance of efficiently exchanging information between phases.
The information generated and used in the supply chain of structural steel components is grouped for component type (plate/profile, assembly and packages) relative to: geometry, ID, weight, type and grade of the material, type of connection, and cutting/bending/punching information. Geometry and connection-related information dominates the supply chain of structural steel components.
The information generated during the design phase is used in the fabrication, shipping, and erection phases. The information generated in the fabrication phase is related mostly to cutting/bending/punching and to a lesser extent to the type and grade of the material used. The information generated in the shipment phase is related to weight and to the components' IDs, both important for packaging and trucking operations, as well as receiving operations at the construction site. This distribution shows that design-related information is used in all phases of the supply chain and should receive extra attention in terms of correctness and accuracy. The proposed approach to streamline the flow of design-related information throughout the supply chain is expected to improve the efficiency of the supply chain and reduce the document based access and control of design information. The feedback from the participants of five different projects and from the documents examined validated the usefulness of the information flow model and of the information items generated and used in the design, fabrication, shipment, and erection phases of the supply chain of structural steel components.
It should be noted that the information flow presented in this paper does not cover the post-erection phase. Further research could look into this phase. Also, the information flow presented in this paper could be expanded to cover specific types of steel construction such as industrial buildings and bridges.

Disclosure statement
Authors do not have any competing financial, professional, or personal interests from other parties.