Volgende: PDT: information structuring Omhoog: Analysis of current information Vorige: Introduction Inhoudsopgave
For many years already Specifications and technical drawings, the Tender Documents, form the core of a project IS. The basis of Specifications is formed by systems for Classification and Coding. Though ICT has been successfully applied in the area of technical drawings (Autocad c.s.) and Specifications, these first generation instruments only play a minor role in inter- and intra- project communication, i.e. even if an electronic document is exchanged, humans have to transfer the information by hand into the next application.
The previous chapter concluded that there is a need in BC for improved electronic co-operation and communication. Also, there has to be a way of communication that is tolerant of changes: supporting a more dynamic BC.
In this section, first Classifications will be analysed, being the basis for most information structuring done in practice nowadays. Second, Specification systems, as an important user of Classifications and as a system that often has a central place in current BC. Third and last, two examples are analysed.
In the BC industry, Classification systems saw increased adoption in the fifties. Most prominent example is the Swedish SfB Classification and Coding system, which, in one form or another, has been in use ever since. It has received CIB endorsement and is used in many countries. Recently, the formalisms behind the SfB family of Classifications were standardised in the ISO 12006-2 standard [25].
A more rigorous variant of the original SfB, CBC, was created in Denmark by Bjørn Bindslev [26], mainly with computer-based support in mind. It used very strict boundaries between classes for that aim. This fits in well with the Merriam-Webster dictionary definition `a systematic arrangement in groups or categories according to established criteria'.
Classification is a grouping of entities according to some external criteria. The grouping will be quite natural, as it is mostly made from a specific viewpoint. Classification is basically a set of boxes (with labels) to sort things into and can be used as a user-friendly view on other kinds of information storages [27].
Goal of a Classification is to allow information, documents and drawings to be ordered [11]. The level of granularity is quite low, an example is the use of Classifications in naming layers of CAD drawings. Doors and windows can be described in layer 30 for instance; a more granular subdivision is not normally feasible in drawing practice.
For improved co-operation and more knowledge utilisation, this granularity level seems low. Alternatively, if a Classification can be seen as a user-friendly way of ordering information, it can also be used as a user-friendly way of presenting information stored in more elaborate systems.
Looking at the design problem in the design stage from only one viewpoint is not enough [28]. A wall can be part of the main load-bearing construction; provide sound and heat insulation; provide safety; serve as a space separator--all at the same time. Looking at the problem from just one side is too restricted. When ordering information from just one viewpoint, a similar problem exists: one Classification is not enough for all information needs.
Classification systems are in wide-spread use and seem to fulfill an important information-ordering role in the BC industry. One single Classification system is, however, not enough for the fine-grained identification and ordering of information needed. Handling more than one Classification at the same time (to get a better combined `resolution') is a lot of work and probably not feasible to do consistently. An ICT approach is not, however, restricted in this way and is able to present multiple Classification views5.1 on the same information, using Classification as a user-friendly view on the data.
A building Specification5.2 (Dutch: bestekstekst) is usually understood as a central document in a building process. It, traditionally, functions between the design phase and the actual construction phase. It is a contract document, part of the Tender Documents, detailing the agreements made between the Client and the Contractor.
Essential properties of the Specification text are the formal description, (references to) conditions and regulations, a Classification structure and references to Specification drawings [29].
The standard (technical or administrative) conditions are typically valid for every building project. Standard administrative texts make sure that contract-wise a lot of commonly used safeguards are included. The correct legal terminology is used to invoke protection under certain laws. This way, what needs to be said is said simply by including it automatically in the Specification. Typically, the standard conditions are available pre-printed in book form and simply included with the rest of the Specification.
Additional administrative conditions describe the administrative conditions that are specific to this project. Delivery time, payment agreements, steering of the project. Additional technical conditions describe things like delivery of samples for the Client to agree upon.
One common way of subdividing the textual Specification is subdivision into parts called chapters. Traditionally chapters often correspond with branches of the industry or types of work. All paint work is in one chapter, groundwork in another and doors & windows in a third. This makes it easier to provide a cost estimation by allowing different experts to estimate their part. This kind of subdivision is common in the housing and utility construction sector, traditionally subdivided in specific crafts.
On the down side, much information gets scattered all over the place when there are Specification items that impact more than one kind of work. For instance, an inner wall with masonry, a door and wall finishing might end up in three different chapters [30].
A second common way of subdivision is by following normal execution patterns. Reason for this is that detailed cost estimations (in the ground/water/road sector) are normally made that way. A good match between cost estimation and Specification text is desired.
The Classification structure used by the Specification is sometimes also used to structure other information. Links, made that way, are however on chapter/section/subsection level, not really on the level of actual Specification units.
There are--roughly--two kinds of Specifications: result Specifications and functional Specifications. Result Specifications specify in detail what the desired end-result is. Functional Specifications specify functional requirements on certain parts. A functional Specification allows the Contractor more decisions.
A mix between result Specifications and functional Specifications is possible. In the Dutch building Specification system it is, for example, normal to see functional requirements for the installation side of a building (heating, ventilation), with the rest of the Specification being a very detailed result description.
Functional Specifications can also be seen as dynamic documents. An initial high-level functional Specification is made and, throughout the design process, more detail is worked out. In this process, Specification items are often coupled with initial cost estimates that become more and more reliable with the increase in detail.
Traditional Specifications are static. Changes do occur, but usually meet resistance, which hinders a dynamic connection between the Client's wishes and the eventual finalised project. Contractors are often selected on lowest price and often look for inevitable errors or omissions in the acsingularTender Documents (and more specifically the Specification) for sources of additional work. This contract document--in reaction--is nailed down as much as possible. The concept becomes everybody's boss instead of being an effective agent for collaboration. [9]
Premature nailing-down of what amounts to uncertainties costs a lot of money. Traditionally, a finished design is distilled into a Specification drawing and Specification text. The design often is changed to a bigger or lesser degree during construction. But especially the Specification text contains a lot of product descriptions that aren't certainties, as realities encountered during the actual construction phase often make changes necessary. This information is prematurely set in stone, leading to friction and reduced flexibility in the resulting construction phase; despite the fact that missing out on flexibility can mean missing out on reduced costs and that friction can mean increased costs.
The role of Specifications in the future BC industry can go two ways. The importance of the Specification as a separate document can become lower, as a good product model should be able to export a lot of information normally contained in a Specification, though probably not all. On the other hand, a Specification can be seen as a set of agreements between two parties. When the process becomes much more dynamic, the number of agreements (as opposed to the number of `plain' building data) is bound to go up, strengthening Specification's position. This needs more detailed research, part of which is done in the next chapter.
Specifications have a quite central place in the building process, with many information links to other documents which are owned by many different parties (figure 3.1). This makes it an ideal target for research on improved instrumentation, as Specifications naturally include a lot of interaction between various sources of information. Links exist to: Classification systems, (Specification) drawings, laws, regulations, costing applications, etcetera.
 |
In a traditional construction process, where a Specification is a one-off textual document, reasonable simple textual Specifications are adequate. In a dynamic process, though, the Specification is, initially at least, much more a work-in-progress. This dramatically raises the cost of having to extract the Specification's information manually, should the Specification still be purely text-based.
In this section, two Dutch systems are discussed. The first is ETIM, a Classification system from the electro-technical and mechanical sectors. The second is STABU's building Specification system. The goal is to improve the analysis by observing two real-world examples.
As an example of a current Classification-based system, ETIM is developed by the electro-technical and mechanical contractors organisation acsingularUNETO/VNI from the Netherlands, but now also internationally. ETIM uses a very simple structure to hold items with synonyms, an explanation, a few attributes (like `voltage') plus units, but without parts. See figure 3.2.
This simple structure sees very widespread use in the electro-technical and installation sector, mostly as a basis for catalogs and catalog lookups. This usage level attests to the usefulness and acceptability of the Classification system.
 |
Interesting to note is that one of the attributes for the items is always `price'. A common conception is that this is not something that will be accepted by the supply side of the market, mostly due to `items not being comparable on price' or because `price is something that has to be negotiated'. Initially, no vendor included the price in his catalog entries. Until a few `broke rank', after which it became common to include a price within a few months [31].
The Classification--all items, including attributes--is freely available, at least in the international version5.3[32]. This makes it easy for software vendors to support this Classification.
There are some drawbacks. ETIM does not support easy information sharing and integration outside the current use case of catalog lookups. The current implementation does not (on a technical level) keep track of changes in attributes of items between different versions of the Classification, which means that the biannually Classification update leads to a manual update of many catalogs [31]. Also there is, for instance, no link to the Dutch Specification system. A second restriction is that the Classification only supports single components. As long as it is one item that you can buy, the item fits in: an electrical socket or a light switch. Complex items that consist of sub-components (like a heating system) do not fit in [31].
As an example of a Specification system, the STABU system is discussed. This originally paper-based system was given a renewed basis in 1991 with a fully database-based implementation. It successfully penetrated the Dutch Building industry and remains in use till this date.
The fact that an almost 15 year old computer-based system still has a 100% market share testifies to the quality of the original design. Implemented as a relational database, it consists on the one hand of a chapter structure, ordered by kind of work (masonry, painting). On the other hand it consists of Specification items, which are a combination of materials, activities and result descriptions. Specification items have properties (attributes) attached to them. See figure 3.3.
 |
In the Dutch building industry, STABU's Specification system is widely accepted. There are numerous catalogs that offer their catalog items as STABU Specification items. The introduction of the STABU system brought semantic integration a step closer. An important reason for acceptance, probably, is the inherent simpleness of the system. As a second reason, STABU's market position is helped by the law-backed requirement for certain government bodies to use a standard Specification system for their building activities.
In order to use the STABU system, a license has to be bought. Likewise, software vendors have to buy a license before they receive the development kit and are allowed to access the system's database.
As with the aforementioned ETIM system, technical restrictions hamper the emergence of ubiquitous information exchange in BC based on this Specification system. On a technical level, like ETIM, attributes of the Specification items are not identifiable. The biannual update therefore means a manual update of a lot of specification items and catalog items. Result is that software vendors are practically unable to link information in a Specification with for instance a costing application.
STABU's Specification system is geared towards generating a paper Specification document. Many other Specification systems are even more explicitly aiming at paper documents as they are a collection of macros for Microsoft Word [33]. These paper documents documents are just representations of the real Specification contents. A system that exposes the real content, instead of a representation, will prove more useful and valuable.
Both examples, ETIM and STABU, have a quite simple internal structure, which helps in the adoption of the system. In both cases, the implementation prevents--on a technical level--easy sharing of information within the BC process. If this technical restriction could be lifted, it would help both systems to integrate more fully in BC's information landscape.
A closing comment has to be that both systems discussed are database-driven systems. This means that they have a good basis for communication when compared with a lot of other systems. A lot of Specification systems, for instance, are based on word processors (mostly Microsoft Word) [33] and lack, therefore, any Semantics that can be reused by other applications.
