Similarities for efficient Information Management

what is a product type

Most manufacturing businesses manage their products by grouping them according to functional, design and market similarities. These groupings are normally called ‘product lines’ or ‘product ranges’. Generally, this measure is necessary due to numerous benefits including faster time to market, reduced cost for producing and delivering a product, increased scalability, better product quality and optimised information management. This article discusses in detail how a similar logic applies to the PDT mechanism devised and practiced by coBuilder in the digital world of product data, especially when it comes to optimised information management.

What is a PDT?

Let’s start by briefly reminding you what a PDTs is. A Product DATA Template is a common data structure defining the properties (essential product characteristics, attributes representing the features or the quality of an object, e.g. fire rating or water tightness) that describe a product in a way that a machine can understand. As each construction (or any kind of) product is different, it has a different set of characteristics. In many cases even if the characteristics of a product are similar, they are tested and measured differently. In different countries and within different organisations, these characteristics do not share the same name and are therefore deemed different by various software programmes. The PDT methodology though takes into account all these differences. Through the use of different standards and intricate mapping mechanisms, the PDT methodology aims to produce a common structure that can be used across different applications, keeping the data accurate regardless of the specific use.

How common is a common structure?

From a birds eye view the ‘story’ of Product Data Templates is a story of similarities, much like the ones needed to define a product line. A specific Product Data Template can only be a common data structure for a specific set of similar products. This set of similar products is what we call a ‘Product Type’ or PT.

Where do Product Types come from?

The easy answer to this question is standards! CEN/CENELEC, ISO standards are the ‘handbook’ that coBuilder’s experts use to define everything from the product type down to the relevant property sets and the proper language that has to be used within the PDT structure in order to achieve consistency and accuracy. However, it is important to understand here that product types are developed by people.

Construction industry experts such as architects, MEP, HVAC & Structural Engineers research different resources in order to collect enough information for creating a functional product type.

What are the benefits of a PDT based on a Product Type?

The Product Type is can be defined as the technical skeleton of a PDT. Here comes the efficient information management part: The idea behind PDTs and the main reason they were developed was to provide the construction industry with an efficient way to manage and utilize manufacturer’s data. A PDT holds the potential to collect and organise data so it answers to different needs such as ensuring seamless data flows, ensuring regulatory compliance or consistent naming of product properties within the international subsidiaries of a company. In oder to acheive this, a the content of a PDT has to be meaningfully linked to different classifications, market requirements and legislative norms as well as peer reviewed definitions of concepts collected in digital data dictionaries. The Product Type is the central piece that links everything together.

So what are the implications?

When a manufacturer digitizes their data through coBuilder’s PDT-based tool goBIM, they can use the Product Type defined by our R&D experts to load the relevant properties for their product. This template carries all standard-based, national and legislative requirements in its structure so that the system will notify the manufacturer if there are missing documents such as the Declaration of Performance in case the PT is covered by the CPR (Construction Product Regulation).

Furthermore, on the basis of PTs, systems such as ProductXchange can create automatic filters that can validate whether any instance of a product is supplemented by documents required by the particular organisation (client/contractor) and verify if the values that were declared by the manufacturer fullfill the required ranges. Only through the use of Product Types, machines can do such large-scale assessments and checks that are vital for closing the performance gap in the construction sector.

So there you have it – PTs are very awesome!