We are now conditioned to expect a simple answer to any question; just “google it” – but how often do we go beyond page 1 of a Google Search? ©activeplan consulting ltd 2022
Google does the complex work in the background, so it can deliver the simple answer. Google, and the rest of the information ecosystem, deals with the detail, using standardisation and protocols to allow machines to engage with humans, respond to variables and deliver a simple answer – on Page 1.
To achieve, this Google replaced 20th Century data management processes. They started by cataloguing existing documents and data sets to make them easier to find and then helped create an ecosystem in which any newly created information would be machine-readable.
As consumers, we didn’t need to know any of that. Just rely on the fact it was done.
Other search providers, even Microsoft, tried to do the same, but they don’t seem to have been able to deal with the complexity. So, we found that the simple answers delivered by Bing were often wrong.
In Property and Construction, traditionally slow to adopt technology, we are still using outdated methods and processes, that are heavily dependent on people doing the right thing at the right time.
Very complex, decisions made by experts applying knowledge and experience, but impossible to automate - unless we introduce a data-driven ecosystem.
Anyone who has been asked to compare the carbon footprint of a building will confirm that this is very complex. The embodied carbon of every product that it includes – manufacture, shipping, installation, operations – and how to support those making decisions at key stages, is required to choose lower emission solutions.
There are so many variables, it is virtually impossible for people to consider them all – plus ESG reporting will increasingly require a digital record of those selections.
Fire safety is equally complex, with many different products, from different suppliers, being assembled to mitigate risks.
Many variables that require different decisions based on different circumstances. Complex inter-relationships of data, driven by context and dynamic connections.
Reducing Waste and Cost are significant drivers for construction. However, designers and constructors often waste enormous amounts of time and effort in handling and managing duplicated information which often has poor quality or superfluous information.
A data- driven ecosystem can provide the solution by providing the requirement, specification, and manufacturers information in their respective parts, reducing waste in data handling, supporting change management, and enabling supply chain members to focus on the deliverables required.
This will also facilitate the specification, delivery and installation of the correct products, enabling timely delivery and reducing cost.
20th Century software solutions
Although there are some great software solutions for design, construction planning/management, procurement, inspection, and asset management, they all share a common weakness. The data they use is created uniquely by each customer.
There is a lot of guidance and standards that customers are expected to follow, but our practical experience is that many don’t – and the problem is that you only need one person to add the wrong character to a field for the information thread to break and require manual intervention.
Amazon’s amazing delivery model would fail without standardised data.
Activeplan’s 21st Century software solutions
The same software can be used, with one change.
All of the non-geometric data about “things” - assets, products, spaces, buildings – come from a common master database library via dynamic connectors (Application programming interface or API).
The master database environment includes a data dictionary so alternative terms (synonyms), that make more sense to individual stakeholders, can be presented.
The “things” still exists in the individual applications, and where they need the data to be held in the “object” that is simply synced with the master data model.
Requirements, specification, and manufacturers information is all handled through their respective silos, ensuring information is still authored by experienced people, with the appropriate levels of robustness and quality control.
This common shared database removes the need to translate the non-geometric data using schemas like IFC and thereby removes the risk of data being changed and consequential actions.
The market
There is enormous, and growing, demand for this asset information.
Currently, there seems no way of satisfying that demand.
Types of Information
Where possible, we should create data once, and use it many times. This reduces waste and complexity.
If we have an object, perhaps a door, we create a single database object of that door (AP SmartData), connect to it all the different properties or documents required for different purposes, and filter the selected information that is required by each different stakeholder.
Some of this information will be “fixed” and some “variable”.
Fixed information – doesn’t change project by project – e.g. manufacturers product information. Adding fixed data into Building Information Models (BIM) is unnecessary, introduces complexity and risk of data loss.
Variable information – project-specific – can be added into models, depending on workflow
Where is the variable data created.
Installers - database applications and spreadsheets (seldom BIM)
Designers – specification and design analysis applications – and BIM
Activeplan adds structure to things that others are already authoring, making it simple to retrieve and update. We create a data Ecosystem that allows information to be created and maintained in different databases, by different people, using different applications.
The Ecosystem includes objects that are “things” – buildings, spaces, systems, asset types, assets, products and tasks – and “things” about “things” – fire rating, carbon, warranties, certificates, data sheets, installation records and photos. From a technical perspective, the Ecosystem is application agnostic, focusing on the data, not the application that are creating/using it.
For “fixed” data, in most cases, having the right data sheet, for the right product, is adequate – and long as it is properly referenced, using categories and meta data, it can be automatically connected. The meta data can be defined in the Templater data dictionary solution, so the classification, and the key searchable data/properties that are agreed by experts and defined in the Templater, can be added to the document.
The metadata can include “tags” that automatically connect the documents to “variable” data – perhaps elements in the models and also related data – such as task lists and photos.
This is a quick win because the model produced by BIM is automatically connected to the documents in the O&M/H&S file, where it has been compiled as a separate commission.
Who does what?
Some asset data is created and added from the BIM author/modeller (perhaps 20%). This will include the x,y,z location, geometry, a unique ID and any data that is naturally added by the BIM author.
The rest (perhaps 80%) is provided by manufacturers and installers.
The determination of what data is provided by whom can be set in the Templates and allocated by the project team. Activeplan’s Project Information Model (PIM) solution will provide that functionality and enable it to be issued through the Common Data Environment or CDE (ASITE, Aconex, ViewPoint) and the delivery tracked.
Fixed data - The standard product data will be “fixed” and therefore doesn’t need to be added to the BIM objects, as long as there is a dynamic connection to the manufacturers data for that specific product. In today’s connected world, it is unnecessary for each firm, and each project, to collect and retain copies of a manufacturers product datasheet. This is both wasteful and unmanageable.
Ideally the manufacturer should generate data sheets from databases, using standardised data templates, that make them machine-readable. These initiatives have started but that is a long journey. To remove what has proven to be a barrier in our progress, for now, this can be satisfied by a pdf datasheet of each specific product, with some key properties attached to that file, in an machine-readable form, allowing it to be searched and connectable.
Manufacturers will say that their data sheets can be downloaded from their websites but they are sometimes difficult to find and downloading is a manual process.
Manufacturers will discontinue products, making the data sheets difficult to find, so a permanent library of manufacturers products in a pdf format should be created.
These product datasheets need to be stored in a “Warehouse”
The Foundation can provide the hosting for free and require the manufacturers to provide a published data sheet for each of the products that are identified by its members.
Activeplan’s Product Library could be used as the platform to store these data sheets. The Entity could license it to the Foundation, where it is simply used as a free service for members to store data sheets for the products they identify. This helps “curate” a relevant subset of all the products that are available. The Entity also provides the Foundation with Templater for free, which creates the categorisation of the Products, so they can be connected to the other data libraries.
In return for providing the Product Library for free, the Entity provides free API access to the Foundation members. This grows the value of being a member (perhaps different levels?). The Entity will gather information about which product types, and which products, are viewed. This product type (provided by Templater) is an important innovation because currently there is no universal practice of relating manufactured products to types.
The Templater can include standard task lists for installation, inspection or maintenance. These can be applied to asset types, using the Templater and to the Product Library.
Collecting the data sheets – we could start with the 250 asset types in the AP Housing master library and ask project teams to start loading up the products they have used on recent projects. This can be seen as a collaborative initiative to build the records they will need to draw on at a later stage to evidence what they have installed.
Once manufacturers become aware that there is a free “information warehouse” that their competitors’ products are being added to, they should be willing to add their data sheets. We might also ask them to add other documents, like Declaration of Performance (DoPs) and Environmental Product Declarations (EPDs). If either, or both, of these can be self-certified, is there a means for the Foundation to provide them with templates to lead them through the process (like BAMB).
Manufacturers will see this as a free resource that they can use to be considered for specification, and we could provide them with the option to tag the data sheets with additional metadata from Templater, making their products more easily “found”. We can also add GS1 and/or BSI references.
In terms of designers and procurement people, we could provide standardised schedules that they can use to map objects to products in the Product Library. Each user registers for free as an individual and company. Asking them to reveal the project they are working on is probably too far (and they could be working on several) but we should also make it possible to add a project and tag the products to that project, so that colleagues from other firms working on that project can see what is being curated.
Variable data - Installers will author what is “variable” data in databases or Excel e.g. record which actual model and serial number of a pump was installed, alone with a photo. The commissioning engineer, the settings based on the performance curve of that pump in that system. The values will be impacted by other elements, for example the electric motor powering the pump. This detailed information will be required by the maintenance team, to ensure the system will continue to perform as designed and commissioned.
They have ownership and traceability that needs to be retained. If they hand that onto a 3rd party to add to the BIM, that “chain of custody” is broken – plus it is unnecessary waste.
So, in summary, we have several different types of asset data:
1. Fixed data
2. Variable but common data (e.g. reusable libraries for installation/inspection procedures)
3. Variable but unique data (serial numbers, commissioning settings - and documents, commissioning certificates, photos)
4. Geometric files – need federating and perhaps translating via ifc.
5. Documents – certificates, data sheets, photos.
We can call this “Evergreen” asset data – constantly refreshed.
Change management
Procurement processes mean there can be three or four different teams involved in delivering a project. Perhaps pre-gateway 1, pre-gateway 2, pre-gateway 3 and then Operations.
The only constant thread is the data, but currently each of these individual firms in each team at each stage creates its own data in its own applications, using its own terminology. This makes any comparison between the different stages completely manual – and very difficult.
Each firm may store its own files for contractual/insurance purposes but they are probably of little practical use.
The Golden Thread recognises the need to address this but the current way of addressing this challenge doesn’t work.
We clearly need a common, persistent, data Ecosystem that bridges all four work stages, irrespective of the software applications that each of the dozens (or hundreds) of firms working on the project at different stages, are using.
This data Ecosystem therefore needs to be connected to all of the different applications (easily achieved using APIs) but contain all of the non-geometric data and documents.
Data engineering
Some data is critical, and its absence can undermine safety. It can certainly undermine decision-making.
Design and construction projects generate far too much data to check it all manually. The Grenfell inquiry highlighted the importance of competent persons, but even they can make the wrong choices if the data they are given is wrong.
Other industries have reduced the need for manual checking, by implementing automated processes that generate the required data, in the required format – and using technology that automatically validates and verifies the data, ensuring it satisfies what is required by the decision makers.
This means that the key data needs to be machine-readable.
Given that the BIM will be a federation of files that are produced by different BIM authors in different ways, the structure of the data each BIM author is producing is critical. For the information to be machine-readable, the taxonomy must be exactly compliant and consistent.
Each “thing” in each building will have a unique ID (GUID), managed in the Activeplan database.
Data that is confidential – e.g., tenant details – can be held in separate, secure databases, but connected to the property by means of the GUID. Tenants could be provided the means to view selective information (a portal?) and also upload their own data – perhaps photos of risks, asset lists,