PSI - Issue 62

Emerenziana Locatelli et al. / Procedia Structural Integrity 62 (2024) 209–216 Author name / Structural Integrity Procedia 00 (2019) 000 – 000

213

5

The flux shows the steps required in a digital environment, the intervention of each actor - technicians, bridge owner, Ministry - in the working chain and the solutions that can be implemented in a BMS to simplify the process. Red boxes represent the instruments that help users in data management, as example a copy system for repetitive data in Level 0 and 1 and integrated algorithms in Level 2 for the automatic calculation of the Overall Attention Class. Other tools permit to generate automatic report that can instantaneously combine data to support the bridge owner in the evaluation process, or files suitable with AINOP, to reduce the effort in the transmission of information between bridge owner and Ministry. However, due to the numerous interactions among the involved actors, the architecture of a BMS requires a great atten tion on users’ relationships. Thus, green boxes underline all the passages in which it is possible to adopt solutions for the creation of a collaborative workplace to reduce errors, incongruences, transmission time and, once again, speed up the whole flux. Following paragraphs give a deep analysis of the whole process with practical examples and describe how management of actors’ have been implemented in the web platform INBEE, which is based on the proposed operative flux. 3.1. Data access levels Starting from the top of the operative flux in Figure 2, the first step is the identification of a space into the database that represents the folder to fill whit all the information related to the bridge. It corresponds to the creation of the bridge folders into the BMS, generally done by the bridge owner. However, as anticipated, in case of a huge infrastructural heritage, manager of the bridge owner’s administrative area subdivides bridges among his internal collaborators, as example, according to geographical zones. Consequently, the next step can be the assignation of the folders, previously created, to the collaborators so they can work independently on their projects. The solution adopted into the platform has a folder and subfolders approach. The main folder, as introduced, corresponds to the whole archive of the bridge, the space into the database that will collect all the subfolders. Indeed, for each bridge, it is possible to create infinite subfolders, which collect the information of each activity that succeeds in the useful life of the bridge. The set of subfolders represent the bridge archive. This architecture permits to operate differently on the two scales: the entire bridge or the single activity. Subsequently, it is possible to share a single subfolder (activity) or the main folder (bridge). Furthermore, at a bridge scale, it is possible to distinguish users between operative and only consulting. The described structure allows, for instance, to enable some users to create new activities, others only to visualize documents, others to input information in a single activity. To make a practical example, after the creation of the bridge folders, the bridge owner can rapidly share these main folders to collaborators for the management of the heritage. In this way, collaborators can create a new activity where input data. Subsequently, if they need to collaborate with other technicians, especially as happened for inspection data (Level 1), they can share the single activity with other users. Thus, each contributes to feed the archive according to his own knowledge and defined access permissions, both in terms of content visibility and allowed actions. In addition, the time required to share information can be drastically reduced. 3.2. Management of working groups As previously explained, the administration of a huge infrastructural heritage is generally subdivided, in the bridge owner society, among organised groups, where each group manage a well-defined set of bridges. In these cases, it is important to guarantee an easy teams organization in the internal hierarchy of the bridge owner. For this requirement, in the platform, there is a dedicated area comparable to an address book. The card of each collaborator recaps the projects in which he is involved and is the place where master ’s account can share new ones. In addition, as reported in the example presented in Figure 3, for each bridge associated to the collaborator, it is possible to define different access permissions and deadlines. Finally, master can also distinguish between internal or external collaborators, including as internal all those who works in his company and as external all professionals that collaborate only on specific projects. In this way, master’s profile can rapidly organize work distributing it among collaborators and easily managing working teams. This function also contribute in reducing operative time.