PDI in de Nederlandse bouwsector

Om de concurrentiepositie van Nederlandse bedrijven te versterken voert het ministerie van Economische Zaken een telematicabeleid gericht op de versterking van de telematica-infra structuur van ons land. Onderdeel van dit beleid zijn subsidies voor projecten op het gebied van Product Data Interchange. Product Data Interchange ( pdi) is een geavanceerde informatietechnologie gericht op de interne en externe uitwisse ling van produkt- en produktiegegevens. Het is een logisch gevolg op Electronic Data Interchange (edi) dat met name gericht is op de uitwisseling en standaardisatie van handelstransacties. Aan de hand van recent afgesloten pdi-projecten zal in dit artikel worden ingegaan op ervaringen met deze technologie in een specifieke sector, namelijk de Nederlandse bouwsector. Ondanks het ambachte lijk imago van de bouw wordt ook in deze sector geëxperimenteerd met pdi.

Twee vragen staan in dit artikel centraal: hoe maakt pdi een koppeling van bedrijfsfuncties mogelijk en wat zijn de knelpunten bij de implemen tatie van pdi. De relevantie van dit artikel gaat echter verder dan de bouw omdat ervaringen met pdi in deze sector exemplarisch zijn voor die in verschillende andere bedrijfstakken. Alvorens in te gaan op de ervaringen met pdi in de bouw wordt in de volgende paragraaf kort een aantal algemene kenmerken van pdi aangegeven. Vervolgens komen pdi -projecten in de bouw aan de orde en wordt behandeld hoe deze technologie een be drijfsoverstijgende koppeling van bedrijfsfuncties mogelijk maakt. Tenslotte wordt ingegaan op knelpunten bij de implementatie van pdi in de bouw.

Product Data Interchange

pdi heeft ten doel tot een koppeling van cad-sys temen onderling en het koppelen van cad met cam-systemen te komen. Bij pdi wordt door middel van genormeerde en gestructureerde gegevens in berichten de vorm, samenstelling en bouw van een produkt beschreven. In deze paragraaf wordt kort ingegaan op de ontwikkeling van (internationale) standaarden voor de uitwisseling van grafi sche en niet-grafische informatie. Deze standaardisatie van pdi bevindt zich nog in een beginstadium.

Bij implementatie van pdi is het een probleem dat electronische berichten, die ontwerpinformatie bevatten over eenzelfde produkt, in een veelheid aan verschillende vormen voorkomen. De gege vens in de berichten, waarvoor men bij pdi stan daarden wil vastleggen, hebben echter betrekking op één en hetzelfde produkt dat ontworpen, ge maakt en onderhouden moet worden. Om tot standaardisatie van de gegevensoverdracht te ko men wordt bij diverse experimentele pdi-projecten dan ook eerst een model van een specifiek produkt gedefinieerd, waarin dit produkt volledig en eenduidig wordt vastgelegd. Dit wil zeggen dat alle informatie over een produkt voor alle betrokken partijen in dit model is beschreven.

Deze zogenaamde produktmodellen vormen de basis voor standaarden voor electronische commu nicatie tussen diverse partijen betrokken bij een produktieproces. Het produktmodel is een com putermodel dat een aantal gegevens bevat. In essentie is het een volledige, consistente en ondub belzinnige beschrijving van een produkt of project. Het produkt- of gegevensmodel bevat informatie over de structuur van een produkt, materialen en kwaliteitsnormen, bewerkingskenmerken en administratieve gegevens. Het is mogelijk dat delen van het produktmodel bij informatiesystemen van verschillende ondernemingen liggen opgeslagen. Men spreekt dan van een gedistribueerde database. Met een gemeenschappelijk gegevens- of produktmodel kunnen uiteenlopende ondernemingen uit verschillende branches voor uiteenlopende toepassin gen informatie uitwisselen.

Organisaties uit diverse branches kunnen hun eigen produktmodel definiëren. Voorbeelden hier van in de bouw zijn de modellen constructies, architect en installaties. Laatstgenoemde modellen zijn weer verder te specialiseren. Zo is het model constructies te specialiseren in beton- en in staal constructies. Deze modellen moeten, om uitwisseling te kunnen garanderen, eenzelfde structuur be vatten. Dit maakt het mogelijk dat de diverse produktmodellen via het kernmodel met elkaar kun nen communiceren (zie figuur 1). Het produktmodel is in dit voorbeeld geen grote centrale gege vensverzameling die door één partij wordt beheerd maar een 'gedistribueerde database': bij diverse on dernemingen zijn stukjes van het totale model aanwezig.

Standaarden

Programma's die gebruik maken van het produktmodel of dit model opbouwen, kunnen dat slechts doen als de structuur van de informatie aan standaarden voor de uitwisseling van produktinforma tie voldoet. In de Verenigde Staten is het initiatief genomen voor de ontwikkeling van een 'Product Data Exchange Specification' ( pdes). pdes vormt de basis voor de ontwikkeling van de belangrijke internationale pdi-standaard step (Standard for the Exchange of Product Model Data). Voor het ontwikkelingen van pdes/step is veel gebruik gemaakt van het werk uitgevoerd voor de Ameri kaanse luchtmacht.

step/pdes beogen uitwisseling van produktmo dellen die voldoende informatie bevatten om direct door geavanceerde cad/cam-systemen en applicatie-programma's begrepen te worden. De term 'produkt' wordt in het algemeen gebruikt voor iets dat gefabriceerd of gebouwd wordt en gebouw kernmodel waarvoor data noodzakelijk zijn. De data bevatten niet alleen grafische informatie maar ook attributen of kenmerken die een onderdeel, een geheel van onderdelen of het finale produkt definiëren. Daarbij streeft men naar een 'complete representation of a product as stored in a computer database' (nedc, 1990, blz. 75). Doel is gedurende de gehele produktlevenscyclus een geïntegreerde informatie voorziening mogelijk te maken.

Het internationale produktmodelleringsonder zoek (waarin Nederland een bijdrage heeft vanuit het meerjarenonderzoek van Rijkswaterstaat en tno-Bouw) heeft in het kader van step de basis gelegd voor standaarden voor produktmodellen. Produktmodellering voor de bouwsector vindt bij step in een commissie plaats gericht op 'aec' (Architecture Engineering and Construction) toepas singen.

PDI in de Nederlandse bouw

Het in 1985 ingestelde Innovatiegericht Onderzoeks Programma voor de Bouw ( iop-Bouw) is een belangrijk overheidsinitiatief geweest voor het stimuleren van informatisering in de Nederlandse bouw. 1 Beoogd doel van iop-Bouw is enerzijds geweest dat bedrijven, universiteiten en onderzoek sinstellingen met elkaar leerden samenwerken op het gebied van informatica-ontwikkelingsprojec ten. Anderzijds heeft iop-Bouw zich gericht op de totstandkoming van een telematica-infrastructuur, dat wil zeggen een stelsel van afspraken waarmee communicatie tussen bouwpartners via geautoma tiseerde systemen mogelijk wordt.

Er is in de bouw nu nog vaak sprake van eiland automatisering. Gegevens voortkomend uit of nodig voor een programma worden handmatig over gedragen van of naar een ander programma. De telematica-infrastructuur biedt uiteindelijk de mo gelijkheid voor communicatie tussen computersystemen. De informatie van de ene participant kan gebruikt worden door een andere participant en vice versa (zie figuur 2).

Het in 1989 afgekomen en door iop-Bouw ontwikkelde Bouw Informatie Model ( bim) had als standaard produktmodel dan ook als doel de basis te vormen voor een telematica-infrastructuur in de bouw. Met het bim-model is geprobeerd tot deze infrastructuur te komen door een sector omvatten de methodiek of standaard te ontwikkelen. In de perceptie van de bouwwereld is het bim door zijn abstracte karakter, noodzakelijk om de standaard sector omvattend te doen zijn, niet echt succesvol geweest. Wel wijst het Algemeen Verbond Bouwbedrijven ( avbb) erop dat het iop-Bouw ertoe geleid heeft dat mensen in de onderzoeks- en bouw wereld elkaar hebben leren kennen en nu op verschillende niveaus intensief met elkaar samenwer ken. Daarnaast wordt het denken in produktmodellen als een belangrijk resultaat van iop-Bouw gezien.

Eind 1989 liep het iop-Bouw programma af en stelde het Ministerie van Economische Zaken geld beschikbaar voor een vervolg op dit bim-model. Verschillende organisaties kwamen hiervoor met initiatieven. Het igbi, de Initiatief Groep Bouw Informatica, was bedoeld om verschillende initia tieven te coördineren.2 Het Nationaal Ontwikkel plan Bouw Informatie Systeem (nobis) van igbi was een eerste opzet, gericht op een vervolg van de top-down benadering zoals die tot nu toe was gevolgd. Ongeveer tegelijkertijd werd door vier on derzoeksinstellingen uit de bouw het Nationaal Onderzoekskader Bouwinformatica ( nobi) opgezet.3 In tegenstelling tot het nobis kenmerkte het nobi zich door een bottom-up benadering waarbij ervaringen en problemen van bedrijven in de bouw het uitgangspunt waren. nobis is uit beeld geraakt en in het kader van het nobi hebben een groot aantal bedrijven en instellingen aan de ont wikkeling van een telematica-infrastructuur in de bouw gewerkt. Voor de ontwikkeling van bouwin formatica in Nederland is het igbi meer het beleidsplatform geworden waar bedrijven en organi saties elkaar kunnen informeren en het nobi de uitvoerende instantie.

Nationaal Onderzoekskader Bouwinformatica

In het dilemma ­ tussen sectoromvattende afspra ken versus snelheid ­ heeft nobi gekozen voor een concrete, relatief snelle en operationele oplossing voor een deel van de infrastructuur met de moge lijkheid van uitbouw op lange termijn. Het in één stap tot stand brengen van een volledige telematica-infrastructuur voor de gehele sector, zou gerui me tijd in beslag nemen. Een dergelijke top-down benadering zou pas op langere termijn kans van slagen bieden. Men verwacht dat de bottom-up aanpak het op korte termijn mogelijk maakt dat bedrijven op beperkte schaal electronisch informatie met elkaar uitwisselen. Het idee is dat de ont wikkeling van een telematica-infrastructuur het beste binnen de bedrijven, beroepsverenigingen en branches kan geschieden. Waar individuele projecten elkaar tegen komen moeten afspraken op een hoger niveau gemaakt worden. Daarbij moet aangesloten worden op internationale standaarden. Deze implementatiestrategie is gebaseerd op het inzicht dat uniformiteit in de bouw onhaalbaar is. Men hoopt dat de concrete informatiseringspro jecten een uitbouw naar een grootschalige infrastructuur tot gevolg hebben. Daartoe zijn in 1992 en 1993 vijf pdi-projecten uitgevoerd in diverse branches binnen de bouw. Betrokken partijen waren bedrijven, onderzoeksinstellingen en branche -organisaties. De praktijkprojecten waren:

1 Data-Uitwisselingssysteem (dus): project gericht op de ontwikkeling van een gebouwmodel installatietechniek voor de gegevensuitwisseling tussen installatietechnisch ontwerper en uitvoerend installateur;

2 Budgetteren, Bestekken en Begroten (bbb): pro ject gericht op de ontwikkeling van een produktmodel voor de uitwisseling van kostengege vens tussen ontwerpende en uitvoerende partijen;

3 Wapening en Informatisering (wapinfo): pro ject gericht op de gegevensoverdracht tussen constructie-ontwerpers en producenten van be tonwapening;

4 Tekening-Verkeer van de Weg (tvw): project gericht op de structurering van informatiestromen tussen teken- en ontwerpsystemen bij de bouw van een (spoor)weg;

5 Wegontwerp En Electronische Theodoliet (weet ): project gericht op de structurering van informatiestormen tussen teken- en ontwerpsys temen en inmeet- en uitzetsystemen.4

De eerste drie praktijkprojecten zijn gericht op de utiliteitsbouw, de laatste twee op de grond-, weg- en waterbouw. Bij de eerste drie projecten is gebruik gemaakt van eenzelfde kantoorgebouwont werp. De laatste twee projecten hebben zich gericht op de bouw van een (spoor)weg. De projec ten in de utiliteitsbouw liepen van eind 1991 tot eind 1993, die in de grond-, weg- en waterbouw van eind 1992 tot eind 1993. De praktijkprojecten hebben naast concrete oplossingen ook produktmodellen gegenereerd. Deze produktmodellen zijn opgenomen in een samenhangend kader, het zogenaamde Afsprakenstelsel Bouwinformatica ( abi). Het abi integreert de algemeen bruikbare resulta ten van de praktijkprojecten in één architectuur. Daarnaast heeft het abi de opzet van de produktmodellen voor de praktijkprojecten ondersteund.

De pdi-projecten zijn aanzetten tot de ontwik keling van een collectieve bouwtaal. Die formele bouwtaal kan men tegenover de huidige wijze van communiceren zetten. Aan de ene kant staat informatie-overdracht door middel van vrije tekst en beeld van mens tot mens. Aan de andere kant staat een gestructureerde vorm van informatie-uitwisse ling via een formele taal, die is geïmplementeerd in software (zie figuur 3).

PDI en de herstructurering van het bouwproces

Produktmodellering maakt in principe een koppeling van functies van verschillende bedrijven mo gelijk. De pdi-projecten in de utiliteitsbouw, dus, bbb en wapinfo, betekenen een verandering van relaties tussen de architecten, installatie- en con structie-ontwerpers, installateurs, aannemers en fa brikanten van betonelementen (zie figuur 4).5

De architect is het startpunt van de informatie stromen over te bouwen objecten. Bij de architect ontstaat het ontwerp in de vorm van tekeningen, berekeningen en specificaties waar de overige disciplines mee verder moeten werken. Het inge nieursbureau moet zijn ontwerp baseren op dat van de architect. Juist voor het ingenieursbureau is pdi interessant omdat het zowel aan de inputzijde als aan de outputzijde met technische informatie-uitwisseling te maken heeft (De Groot, 1993). Aan de inputzijde krijgt het ingenieursbureau het ont werp van de architect. De output bestaat uit specifieke constructie of installatie ontwer pen. Met deze output worden de maatprodukten in de fa briek (installaties, betonelementen of betonwapening) geprodu ceerd of uitvoeringswerkzaamheden op de bouwplaats (bekisting, landmetingen of gronduitgravingen) in gang gezet. De koppeling tussen ontwerp en fabricage kan voordelig zijn voor toeleveranciers die maatprodukten leveren. Als ontwerpspecificaties door het ingenieursbureau electronisch worden aangeleverd en de toeleverancier heeft zijn produktieproces geautomatiseerd met cam-systemen dan kunnen voordelen ontstaan als doorlooptijdverkorting en snellere pro duktinnovatie.

Voor een architect kan pdi een middel zijn om meer kostenbewust te ontwerpen. Het project bbb (Budgetteren Bestekken en Begroten) kan hiertoe bijdragen. Het kernmodel maakt een koppeling mogelijk tussen specifieke detailmodellen. Gezien de eisen van de opdrachtgever kan een architect er bijvoorbeeld voor kiezen het gebouw uit te voeren in een bepaald type baksteen, bijvoorbeeld een ge glazuurde baksteen van een zekere kwaliteitsklasse en een bepaalde kleur. Om te controleren of de gekozen technische oplossing (geglazuurde bak steen) voldoet aan de budgeteisen, die door de op drachtgever zijn gesteld, kan met behulp van pdi worden gecontroleerd of de realisatie van het ge bouw volgens de opgestelde specificaties binnen het budget mogelijk is.

Volgens de Bond van Nederlandse Architekten (bna) heeft bij architecten lange tijd een grote emotionele aversie bestaan tegenover informatie technologie. Momenteel is in de architectenwereld duidelijk sprake van een omslag. Een reden hier voor is dat informatietechnologie wordt gezien als een belangrijk instrument om de coördinerende rol van de architect te behouden of verder te ontwikkelen. Het dus-project uit de installatiebranche is voor het project Budgetteren Bestekken en Begroten (bbb) van de architecten een belangrijk uitgangspunt geweest. De vca (Vereniging Computergebruik Architektenburo's) was tot voor kort nog niet zover dat processen zodanig in kaart waren gebracht dat de ontwikkeling van produktmodellen mogelijk was. De V abi (Vereniging voor Automatisering in Bouw- en Instal latietechniek) is daarentegen al sinds 1987 bezig met de ontwikke ling van het Data-Uitwisselingssysteem en speelt hier duidelijk een voortrekkersrol. De vca werkt dan ook met de Vabi samen met als doel het ni veau van produktmodellering binnen de architectendiscipline binnen korte tijd op het zelfde ni veau als dat van de installatietechnische discipline te brengen.

De pdi-projecten scheppen ook mogelijkheden voor een snellere feedback tijdens een bouwproces. Een ontwerp van een betonnen balk door de constructeur kan bijvoorbeeld door de installatie-advi seur worden opgehaald. Die bepaalt vervolgens welke sparingen op welke plaats moeten komen ten behoeve van de leidingen. De gegevens over zowel de sparingen als de gehele balk kunnen voor de constructeur invoer zijn voor het berekenen van plaats en eigenschappen van de betonwapening. Deze gegevens over de wapening worden vervol gens weer aan het informatiesysteem toegevoegd, waar de aannemer ze weer op kan halen voor het bestellen van de betonnen balk bij de buig- en vlechtcentrale.

PDI in de grond-, weg- en waterbouw

De pdi-projecten tvw en weet in de grond-, weg- en waterbouw hebben zich gericht op de informa tie-uitwisseling rondom het produkt (spoor)weg. Bij het inmeten en tekenen van een (spoor)weg spelen verschillende partijen een rol: de opdracht gever, het architectenbureau, het landmeetkundig ingenieursbureau en de aannemer. De twee pdi-projecten in de grond-, weg- en waterbouw hebben met name betrekking gehad op de relatie tus sen opdrachtgever, ingenieursbureau en aannemer (zie figuur 5).

Een tendens is dat in de gww-sector grote infra structuurbeheerders zoals Rijkswaterstaat, de ns, provincies en gemeenten, zich beperken tot het stellen van een Programma van Eisen en de aanzet van het ontwerp met behulp van een 3d (drie-di mensionaal) ontwerpsysteem. Dit ontwerp moet vervolgens verder uitgediept bij ingenieursbureaus en aannemers met eigen ontwerpafdelingen, veelal op een ander 3d-ontwerpsysteem. Overdracht van reeds beschikbare digitale informatie ontbreekt hierbij. Verdere detaillering van het ontwerp binnen afdelingen van ingenieursbureaus en aanne mers bedrijven gebeurt doorgaans met een 2d-tekensysteem, eveneens zonder digitale overdracht van gegevens. Bijstelling van ontwerp, aangedragen door opdrachtgever of het ontwerpbureau zelf, gebeurt bij de huidige beperkte communicatiemogelijkheden met hetzelfde 2d-tekensysteem. De overdracht van de gegevens naar de uitvoeringsfase gebeurt eveneens op 2d-niveau.

Doel van de pdi-projecten is een standaard voor informatieoverdracht binnen de grond- weg- en waterbouw. Het betreft hier de informatie-over dracht tussen 3d-ontwerpsystemen onderling, 3d-ontwerpsystemen en 2d-tekensystemen en 2d-tekensystemen onderling. Voor de gegevensuitwisse ling tussen 3d-ontwerpsystemen onderling bestaat reeds het BasisWegModel van Rijkswaterstaat. De pdi-projecten in de gww-sector hebben dan ook betrekking op de informatie uitwisseling tussen 3d-ontwerpsystemen en 2d-tekensystemen en 2d-tekensystemen onderling (trc, 1994).

De deelnemers aan de pdi-projecten hopen dat op termijn de meeste 2d-tekensystemen de pdi-standaard zullen ondersteunen. Hierdoor krijgt de gebruiker de vrije keus om gegevens betreffende ontwerp, uitvoering en beheer van een (spoor)weg op verschillende typen systemen verder te verwerken. Na de introductie en brede acceptatie van een standaard zal er een grotere keuzevrijheid bestaan bij de inzet van cad-systemen en tachymeters.6 Hierdoor zal het uitbesteden van tekenwerk en landmeetkundig werk ­ en inherent daaraan ook de communicatie tussen de verschillende partijen in het bouwproces ­ toenemen.

De te ontwikkelen produktmodellen kunnen zo wel in de utiliteitsbouw als in de grond- weg- en waterbouw een efficiënter tekeningenverkeer mo gelijk maken. Het is nog steeds gebruikelijk dat de architect tekent, de installateur bouwtechnisch moeilijke dingen voor zijn situatie 'hermaakt' en vervolgens de constructeur weer opnieuw begint. Ook de aannemer hermaakt de tekeningen voor toeleveranciers en constructeurs. Door produktmodellering wordt dit dubbelwerk voorkomen en bestaat er minder kans op fouten die het gevolg zijn van het 'hermaken' van tekenin gen.

Gezien het experimentele stadium waarin de ontwikkeling van pdi zich bevindt is nog moeilijk aan te geven op welke wijze pdi tot een herstructurering van de interne organisa tie leidt. Wel is duidelijk dat pdi voor de architect een middel kan zijn om meer kostenbewust te ontwerpen. Tevens lijkt pdi met name voor de ingenieursbureaus belangrijke veranderingen te betekenen omdat deze bedrijven zowel aan de input- als aan de output zijde met pdi te maken krijgen. In de ontwerpfase van een bouwproces kan pdi worden ingezet voor een betere coördinatie van verschillende (architec tonische, constructieve en installatietechnische) ontwerpen. De totale ontwerpfase kan daardoor efficiënter verlopen, waardoor ontwerpkosten ge drukt kunnen worden. Bij de koppeling tussen ontwerpactiviteiten en de produktie van materia len kan een betere informatie-uitwisseling door pdi leiden tot verkorting van de doorlooptijd.

Knelpunten bij implementatie

Bij de ontwikkeling van een telematica-infrastruc tuur in de bouw en de uitvoering van bovengenoemde pdi-projecten is men op een aantal knelpunten gestuit. Produktieprocessen in de bouw sector kenmerken zich door een projectmatige aanpak, locatiegebondenheid en een strikte ar beidsdeling. De complexiteit en tijdelijkheid van processen en de diversiteit van partijen, inherent aan de projectmatige aanpak, bemoeilijken het tot stand komen van een telematica-infrastructuur waarbij verschillende partijen tijdens het bouwproces op basis van dezelfde standaarden met el kaar kunnen communiceren.

In het traditionele bouwproces komt de bouw ondernemer via aanbesteding aan werk (daarom wordt hij 'aannemer' genoemd). De opdrachtgever kiest meestal degene die tegen de laagste prijs inge schreven heeft. Inkopers van de aannemer, aan wie het project gegund is, trachten op hun beurt weer een zo laag mogelijke prijs bij toeleveranciers en onderaannemers te bedingen. Deze prijsconcurrentie, in combinatie met het meestal unieke en gecompliceerde karakter van een bouwproject, heeft tot gevolg dat bij ieder project weer opnieuw namens of door de opdrachtgever met een groot aantal verschillende bedrijven aparte contracten gesloten wordt.

Bedrijven werken steeds in wisselende samen werkingsverbanden aan steeds andere projecten. Ontwerpende, uitvoerende en toeleverende par tijen spreken ieder hun eigen taal en allen hebben een eigen benadering van een bouwwerk. Gedu rende een bouwproces gebruiken deze partijen een groot aantal computersystemen, netwerken, op slagstructuren, protocollen en gegevensdefinities. De afzonderlijke bedrijven, producenten, groot handelaren, architecten, toeleveranciers, onderaannemers, installateurs en dienstverleners hebben allen hun eigen computersystemen voor de interne communicatie. Daarnaast zitten grote bouw bedrijven door overnames en fusies vaak met verschil lende interne standaarden. Contracten met systeemhuizen kunnen soms een belemmering vor men voor het tot stand komen van één standaard voor het gehele bedrijf.

Na voltooiing van een bouwproject valt het team aannemer en onderaannemers weer uiteen. De tijdelijkheid van relaties en de bestaande projectmatige produktiewijze hebben tot een cultuur geleid waarbij men in de bouw sterk op de korte termijn denkt. De bouwcultuur is gericht op im proviseren op de lokatie, de bouwplaats. Er heerst daarbij een voorkeur om alle problemen maar tij dens de uitvoering van de bouw op te lossen. Werken met een visie voor de lange termijn is in veel bedrijven afwezig. Deze improvisatiecultuur vormt een belangrijke belemmering voor het doen van investeringen in een telematica-infrastructuur, in vesteringen die een tijdshorizon voor de langere termijn vragen.

Naast tijdelijkheid van relaties vormt de sectors tructuur een tweede probleem voor het tot stand komen van een telematica-infrastructuur. De sec tor wordt namelijk gedomineerd door het kleinbedrijf en de afwezigheid van een dominante onder neming.

Bij de invoering van een 'industry-wide' auto matiseringssysteem neemt een grote onderneming als Albert Heijn, Philips of Akzo meestal het voor touw. In de Nederlandse bouw is echter geen duidelijke marktleider die een potentiële standaard voor pdi kan zetten, waaraan de bouwwereld zich conformeert. Hierin verschilt Nederland van Frankrijk waar grote bouwbedrijven enorme invloed op technologische ontwikkelingen in de sec tor hebben. Qua omvang is de grootste Nederlandse aannemer, de Hollandsche Beton Groep (HBG), in Europees perspectief klein. HBG komt op de Europese lijst niet bij de eerste twintig bouwbedrijven voor. Daarbij komt ook nog dat de grote Nederlandse concerns in de meeste gevallen uit vele kleinere en los van elkaar opererende werkmaatschappijen bestaan.

Gevolg van de projectmatige produktiewijze en de gefragmenteerde sectorstructuur is dat gebruik van informatietechnologie in de Nederlandse bouw tot nu toe wordt gekenmerkt door geïsoleer de toepassingen. Weliswaar wordt de computer veelvuldig gebruikt in de bouw, maar dat betreft toch hoofdzakelijk de standaard toepassingen in functies als ontwerp, calculatie en administratie. Bij de invoering van deze toepassingen veranderde er organisa torisch weinig, de acceptatie verliep relatief snel en zonder problemen en de voordelen waren eenvoudig aantoonbaar. Met pdi ligt dat anders. Deze technologieën zijn bedrijfsoverschrij dend, dat wil zeggen dat ze alleen kunnen worden toegepast als meerdere functies, bij voorbeeld de aannemer èn architect, gezamenlijk daarvoor kie zen en hun wijze van werken daarop afstemmen. Alleen dan kan het rendement van zo'n bedrijfs overschrijdende technologie optimaal zijn.

De behoefte aan een collectieve instantie

Bij de traditionele bouwcultuur wacht men met pdi totdat het door de markt in zodanige vorm, prijs en kwaliteit wordt aangeboden, dat niet ge bruiken nadeliger wordt dan wel gebruiken. Bouwbedrijven willen graag tegen een lagere prijs hun bouwprodukten aanbieden. Als pdi een middel kan zijn dat een directe kostenbesparing ople vert zullen bedrijven in de bouw tot implementa tie overgaan. Dit betekent dat invoering van pdi zo weinig mogelijk risico in zich moet dragen. Het meest extreme middel om dit risico te beperken is het initiatief en risico van de invoering van deze technologie te verplaatsen van een individueel bedrijf naar een collectieve voorziening. Deze collec tieve instantie zou verantwoordelijk moeten zijn voor ontwikkeling, bouw en exploitatie van een te lematica-infrastructuur.

Deze infrastructuur maakt het mogelijk dat ver schillende applicaties direct gekoppeld worden met de interne applica ties van (bouw)bedrijven. De collectieve instantie die de telematica-infra structuur beheert kan bij grote bouwprojecten een belangrijke rol gaan spelen. Hij maakt het moge lijk dat alle bij deze projecten betrokken partijen optimaal via de infrastructuur met elkaar electronisch kunnen communice ren. Ook partijen als de softwarebranche met bouwapplica tie-software en instanties zoals de belastingdienst, het Sociaal Fonds Bouwnijverheid, banken en verzekeringsmaatschappijen kunnen gebruik maken van de in frastructuur.

Ondertussen blijkt dat het vanzelf ontstaan van een telematica-infrastructuur voor de bouw door het koppelen van bottom-up initiatieven niet erg soepel verloopt. Een groot deel van de bouwbedrijven ziet wel de noodzaak van koppeling en sa menwerking in, maar zijn het oneens over welke afsprakensystemen en benaderingen bepalend moeten zijn. Een groot deel van de bouwwereld kijkt vanaf de zijlijn toe en wacht af.

Conclusie

Beoogd doel van pdi is de koppeling van cad-systemen onderling en het koppelen van cad met cam-systemen. Deze systemen worden met name toegepast in de ontwerpfase van het bouwproces en bij de koppeling van ontwerpactiviteiten met de produktie van bouwmaterialen. Om tot een telematica- infrastructuur te komen is in de bouw gekozen voor de bottom-up aanpak. Binnen de di verse branches die deel uitmaken van de bouwsector wordt aan de ontwikkeling van een telematica -infrastructuur gewerkt. De tijdelijkheid van rela ties in de bouw en de gefragmenteerde sectorstruc tuur zijn echter belangrijke obstakels om tot een dergelijke infrastructuur te komen. Het gevaar is aanwezig dat iedereen voor zichzelf produktmodellen gaat ontwikkelen die niet compatibel zijn met die uit andere delen van de bouw. De voordelen zijn dan voor de verschillende partijen mini maal. De ontwikkeling van een algemeen geaccepteerde stan daard voor produktmodellen vereist dan ook meer afstemming van de verschillende disciplines en daarmee een coördinatie tussen ver schillende sectoren. Er is behoefte aan een collectieve instantie verantwoordelijk voor ontwikke ling, bouw en exploitatie van een telematica-infrastructuur. Organisaties als de Bond van Neder landse Architekten, de Unie van Elektrotechnische Ondernemers, de Adviesraad Tech nologiebeleid Bouwnijverheid en tno-Bouw kunnen hierbij een belangrijke rol spelen.7

Crow (1992), Projectdefinitie nobi-project 'De koppeling tussen Wegontwerp en Elektronische Theodoliet (weet)', Ede.

Groot, R. de (1993), De perspectieven voor edi en pdi in de bouwsector, afstudeerscriptie Technische Universiteit Eindho ven.

Haan, A.J. de (1993), 'Bouwinformatica: Toren van Babel', Automatisering Gids, 9 april 1993, blz. 9.

Koetsveld, M.J., A.A.M. Vermeulen & J.D.I. Wouters ( 1992), pdi, een introductie, Kluwer, Deventer.

nedc (National Economic Development Office) (1990 ), Information Transfer in Building, London.

sbr (Stichting Bouwresearch) (1991), nobi Uitvoeringsplan met Afsprakenstelsel Bouwinformatica, Rotterdam, september 1991.

Taen, R.J.M. & G. Versluis (1990), 'Overkoepelende informa tiesystemen vereisen een collectieve aanpak', De Bouwadviseur , juli/augustus 1990, blz. 26-28.

trc (Telematica Research Centrum) (1994), Product Data Inter change: beschrijvingen van pdi-projecten 1992, trc Report Series, 1994.