I found an old write-up of the 2002 ecppm conference, in Dutch only unfortunately. But I'll post it here anyway as it is the best place to store the info.
All Dutchmen: enjoy :-) Opmerking vooraf: dit was een weekje na de conferentie geschreven i/d vorm van een email naar de STABU-collega's en m'n prof. Als er namen instaan zijn die duidelijk voor de oorspronkelijke ontvangers. Ik ga het nu niet meer herschrijven.
Afgelopen week zijn Kees en ik op de Europese Conferentie voor
Product- en ProcesModelleren geweest. Om een indruk ervan te geven
heb ik een deel van mijn aantekeningen van de presentaties
overgetypt. Als het bevalt kan ik het vaker doen, maar je mag ook
gelijk op delete drukken.
Ik heb veel dingen begrijpelijk op proberen te schrijven. Aan de ene kant gebruik daarmee niet de eigenlijke "officiele" termen die op de conferentie gebruikt zijn, aan de andere kant blijft het toch nog steeds stevige materie.
Er wordt vaak gezegd dat de bouwindustrie zo verspintert is zonder
een grote speler die mooie standaards door kan drukken. Maar
feitelijk is die er wel, namenlijk de overheid! (Later merkte iemand
op dat de overheid ook weer uit meerde relatief onafhankelijke
koninkrijkjes bestaat, met dus minder macht. Maar toch kan de
overheid veel sturen en opdringen).
Hij maakte twee opmerkingen over netwerken om aan te geven waarom de EU investeringen in IT, internet, communicatiestandaarden (zoals lexicon) zo belangrijk vind.
Zelf had ik al eens zoiets op het internet gelezen, maar daar stond het wat botter verwoord (maar niet noodzakerlijkerwijs verkeerd). http://www.cluetrain.org. De beginpagina is gelijk het "cluetrain manifesto", dus de samenvatting in 2 a4-tjes.
Hij voorspelde dat het zogenaamde semantic web er aan komt. Langzaam, maar zeker. Het huidige internet is een paradox van aan de ene kant een enorme stapel data waar je aan de andere kant maar mondjesmaat iets in vind. Google wordt steeds beter, maar toch. Hoe meer er bekend is over de documenten, hoe beter je er informatie uit kan halen. Google kan niets met bestekken, maar zodra google onze besteksystematiek kent... Dat is het idee van het semantic web ("internet met betekenis"). En het lexicon kan daar goed op aansluiten.
Zelf zou ik verder willen gaan door te zeggen dat het lexicon voor de bouwwereld een onmisbaar onderdeel is voor dat semantic web. (Plaatje ervan hangt trouwens al maanden op mijn whiteboard, uitleg is daar ook verkrijgbaar :-)
Zijn (eerste) praatje ging over het integreren. Het integreren van systemen/oplossingen. Een systeem bestaat uit meerdere onderdelen, zoals een besteksysteem, calculatieprogramma's, enz. En zo eens in de tien jaar komt bij onderzoekers de neiging bovendrijven om het hele gebeuren te integreren. Het idee is dan het volgende:
Elk onderdeel is met elk ander onderdeel verbonden. Bij 6 onderdelen hebben die 6!/2=360 onderlinge verbindingen. Elk extra onderdeel voegt weer meer verbindingen toe. Dat kan je op twee manieren oplossen.
Maar... velen gaan uit van de theorie van "alle mogelijke verbindingen". Maar als je kijkt wat voor communicatie er in de bouw mogelijk is kom je op veel minder communicatieverbindingen uit. Kijk, dat is al gemakkelijker. En als je kijkt naar wat er in de praktijk aan communicatie plaats vind worden de verbindingen nog minder. Als dat klopt betekent dat dat de bovenstaande twee oplossingen (met hun nadelen) niet nodig zijn, je kan voor de paar overblijvende verbindingen apart iets bouwen.
Een "grijze eminentie" (die ook aanwezig was) had ooit eens tegen hem gezegd dat de onderzoekers moesten stoppen "with that pipe-dream of integrating, lets get some software done!"
Hij zei nog meer, maar het kwam er op neer om pragmatisch en eenvoudig te werk te gaan. Vat bestaande programmatuur en werkprocessen op als gegeven en plak het geheel met losse stukjes software-lijm aan elkaar.
Twee ontnuchteringen voor de onderzoekers: vraag je af of
Er kan al aardig wat qua informatie opslag, maar het is nog tijdrovend om iedereen de info op te laten slaan en om de informatie makkelijk bruikbaar te maken. haar tip: gebruik metaforen.
Meest stabu-gerelateerde voorbeeld: geef een hierarchie (zoals lexicon) weer als een landkaart (met vierkante vlakken, die weer verder opgedeeld, enzovoort. Kleurcodes en grootte naar gelang de hoeveelheid info die erin zit).
Goed nieuws: er schuilt een onderzoeker in dat zoontje wat de hele nacht monsters afschiet op de PC. Sommige van die spellen kan je met meerdere mensen over het internet spelen EN ze kunnen 3d beelden aan. voila, instant programma om samen met je client eens gezellig door het niewe huis te wandelen. "Press fire to start".
IT = verandering = jammer en rampspoed.
Dat vindt de gebruiker vaak. Denk er bij alle leuke nieuwe oplossingen dan ook aan DAT je de gebruiker goed de hele zaak (inclusief nut) uit moet leggen.
Classificaties zijn ervoor gemaakt om documenten te archiveren. En om ze weer terug te vinden. (rr: een of meerdere bestaande classificaties als gebruikersvriendelijke ingang voor de "koele" lexicondata gebruiken? De referenties zijn ervoor geknipt.)
Het gedrag van een gebruiker van een systeem kan je op verschillende niveaus bekijken.
Voorbeeld voor de stabu: observeer hoe men nu bestekken maakt en hoe men er nu mee omgaat. Probeer aan de hand daarvan achter hogerliggende tactieken/strategien te komen, zodat een eventueel nieuw systeem daar zijn voordeel mee kan doen.
Wil productmodellen (jargon: het lexicon model is de structuur van het lexicon) zo flexibel en intelligent mogelijk zijn. Niet mijn onderzoeksrichting, niet de richting die het lexicon op gaat, maar er zijn meerdere onderzoekers deze richting aan het opgaan. Bijna allemaal bouwkundigen die het leven v/d architect in de eerste fase willen versimpelen (of hem in die fase zoveel mogelijk data willen ontlokken).
Vraag: hoe nodig is dat in de rest van het proces als de bouwtekening al vaststaat.
Benadrukte het belang van een "common ground", een gemeenschappelijk begrippenkader.
Lexicon is geknipt voor die functie. (Danwel: lexicon = een/het begrippenkader)
Ging over het berekenen van de complete kosten van constructiedelen over de gehele levensloop.
De data haalde hij uit IFC (model voor het opslaan van gegevens over een gebouw, begonnen als 3D CAD objecten uitwisselformaat). Maar dan IFC opgeslagen als ontologie in een kennis-uitwisselformaat.
Nu ben ik zelf wel een voorstander van dat kennis-uitwisselformaat omdat het een standaardmanier is van informatieopslag qua modellen. Het lexicon zou je er prima in uit kunnen drukken met als beslissende voordeel dat anderen gemakkelijker van jouw data gebruik kunnen maken en dat je ook gemakkelijker data uit andermans modellen kan halen. Als vni-uneto bijvoorbeeld hun gegevens in zo'n formaat zouden opslaan zou je gemakkelijk aan kunnen geven welke dingen aan elkaar gelijk zijn. Daar is het formaat namenlijk voor gemaakt. Zelf ga ik er verder naar kijken.
IFC is gemaakt voor gebouw-gegevens. Hij komt uit de verkeers-hoek en er zitten geen viaducten, middenbermen enz. in het IFC model. Daar proberen ze in Toronto wat aan te doen. Als het succesvol is zou het ook een betere samenwerking van CROW-data en STABU-data kunnen betekenen.
Zijn inschatting: de GWW sector is er qua informatiestandaarden nog slechter aan toe dan de B&U sector. Met uitzondering van de gasindustrie, die moeten wel absoluut correcte informatie uitwisselen!
Verder meende hij dat in dat IFC gebouwmodel al veel beschikbaar en herbruikbaar was. Hij was niet van plan zelf iets te schrijven.
Ook een iso-standaardisatie project: de Process Specification Language (PSL). Om te kunnen specificeren hoe processen verlopen in de bouw. De kern van het verhaal is een ontologie (weer zo'n model zoals het lexicon er ook eentje is) met slechts 3 klassen (object, activiteit, nog_eentje), 2 functies en 7 relaties. Klein modelletje, maar ze wilden per se ook niet meer hebben. Met behulp van die gegevens kunnen ze veel beschrijven.
Een voordeel van zo'n ontologie is ook dat hij uitbreidbaar is, daar draait die ontologie-techniek om. Definitie die ze gaf: ontology = the basic terms and relations comprising the vocabulary of a topic area.
Dit klonk als een goedlopend project. Zelf wil ik daarom een kleine test uitvoeren om te kijken in hoeverre het lexicon geholpen is bij een weergave in zo'n ontologie-taal. Het lijkt 1-op-1 te passen op het eerste gezicht.
Godfried Augenbroe verbaasde zich erover dat in veel onderzoek kennis en processen bijna als een twee-eenheid werden opgevat. Op zich vond hij wel dat in de bouwwereld de echte kennis in de processen zit.
Verder was er een discussie over hoe je met die processen om moet gaan. De twee meningen waren:
Verder werd gezegt dat veel bedrijven miljoenen uitgeven om een hele stapel data bijeen te graaien en er vervolgens braafjes (en sufjes) op gaan zitten en er niets mee doen.
Werkt nu in het eCognos project. Presenteerde de "eCognos knowledge management infrastructure". En: jahoor, alweer een ontologie. Hij verdeelde de kennis over drie niveaus:
Had het over een ontologie, kennis, enzovoort, maar bedoelde een "ordinaire" classificatie (unspsc, +/- streepjescodes).
Tijdens het ontwerpproces voeg je steeds meer eigenschappen toe aan je objecten. Het doel van zijn systeem was om gaandeweg meer objecten aan een ontwerp toe te kunnen voegen en ook gaandeweg meer eigenschappen aan die objecten toe te kennen.
Via meervoudige overerving van eigenschappen kon je via een bepaald systeem bekijken welke objecten je eigenlijk onder handen hebt ("lattices"). Volgens hem moesten we niet meer object-georienteerd werken maar eigenschap-georienteerd.
Hij zag het geheel ook als een drie-deling:
deur,
wat is een hoogte, wat is beukenhout.deur
met een hoogte van....Voor hem is de centrale vraag: "het" heeft deze en deze eigenschappen. Wat is het?.
Van een eigenschap-georienteerd systeem verwacht hij:
Weer een dynamisch systeem wat je voornamenlijk in de architekten-hoek van het onderzoek tegenkomt. Ik vroeg hem of dit in de latere fases van het project (als het ontwerp vaststaat) ook handig is of dat het dan een blok a/h been vormt. Wist hij het antwoord niet echt op. Het kan dus vriezen of dooien.
Hij gaat ervanuit dat de definities van de klassen (deur, raam) vastgebakken zitten in het programma waar je mee werkt. Je creativiteit wordt daarmee ingeperkt. Wat hij eigenlijk wil is dat de ISO een basisset objecten en eigenschappen definieert waar anderen op voort kunnen bouwen. De programmatuur zou daar verder flexibel mee om moeten gaan.
Ik weet niet of hij met "ISO" ook op het lexicon doelt.
Prachtig (want werkend!) verhaal over het ontwerpen van een woonwijk. Aan de ene kant wil je geen oostblok-achtige monotonie, aan de andere kant wil je geen ongeregeld zooitje van stijlen. Tegelijkertijd is het te veel werk om voor iedereen een huis naar eigen wensen door de architect te laten ontwerpen. Een paar types gaat nog wel, maar veel meer kan niet.
In dit onderzoek hebben ze de ontwerpen van een bekende portugese architect zoveel mogelijk in regels, formules enz. proberen te vatten op basis van een grote hoeveelheid ontwerpen die hij reeds gemaakt had. Vervolgens konden de gebruikers aan de hand van uitgebreide vragenlijsten aangeven wat ze wilden (1 of 2 verdiepingen, hoeveel personen, extra wc of niet) en zo ontstond er langzamerhand een ontwerp.
De grote test kwam toen ze na afloop van het onderzoek de resultaten aan de architect lieten zien. Tot hun vreugde zei hij dat hij het verschil eigenlijk niet kon zien tussen de door hem zelf ontworpen woningen en de uitgerekende woningen. Het lukt op deze manier dus om zowel naar de gebruikerswensen te luisteren als een uniform uitziende wijk te krijgen.
Ik laat de verhalen van david/kees/mezelf weg.
Als de bouw overstapt op productmodellen en 3d modellen (en 3d cad-applicaties) zal er heel veel veranderen in de bouwpraktijk en in de manier waarop mensen hun geld verdienen. Let daarop, want zodra dit duidelijk wordt zal het voor veel weerstand zorgen. Kees: "we zitten in de informatie revolutie, er zal veel veranderen en het zal pijnlijk zijn".
Van 40 tekenaars naar 10 autocadders. Zodra het zichtbaar geld oplevert gaat het snel.
De een zegt dat je processen moet modelleren, de ander dat je producten moet modelleren. Nee, vond iemand, processen zijn eeuwenoud, ze modelleren maakt ze niet beter. Dus moeten we ons richten op het uitwisselen van informatie (voornamenlijk over producten).
We moeten niet zoveel (en teveel) beloven. Mensen worden er moe van. Als er telang gezegd wordt dat iets fantastisch is en er komt maar steeds niets uit... dan gaan mensen je negeren (en terecht).
Discussie over wat nou DE "killer application" is van al ons onderzoek. De spreadsheet was de killer app die de pc tot grote hoogtes opstootte bijvoorbeeld. Er kwamen wat suggesties, maar Kees noemde steeds dat je hele leuke applicaties kan hebben, maar zonder een standaard set definities... kom je nergens.
De gebruiker is niet geinteresseerd in al het onderzoek, die wil werkende programma's op z'n pc. We moeten als onderzoekers dus de softwarebouwers van onze zaken overtuigen.
Ook een geldige opmerking: kijken we wel voldoende naar de 97% kleine bedrijven in de bouwwereld? Zoveel onderzoek richt zich op zaken die alleen door grote bedrijven gebruikt kunnen worden vanwege de kosten of de complexiteit.
Teveel info om op te schrijven. Hoe kan je bedrijven lekker laten samenwerken en info uit laten wisselen. Zijn conclusies waren wel:
Een documentenbeheer systeem is al lastig te verkopen, maanden vasthoudend de deur platlopen is nodig. Verwacht veel meer moeite bij het verkopen van modelleren enzo.
WebSpec, een besteksysteem, lopend op het internet, gebaseerd op het lexicon. Klonk goed. In IJsland is er nog geen systeem. Copy-paste met word.
In de bestektekst zijn de verwijzingen naar de normen/wetten enzo klikbaar gemaakt. Handig. Dit kan je met een modern internet- en xml-gebaseerd systeem. Tijd dat we opschieten met het geschikt maken van het lexicon voor bestekken! Dit zag er goed uit.
Het hele systeem draait op het internet, hoewel je delen ook lokaal zou kunnen draaien.
Toen ik hoorde dat het niet commercieel verkocht zou worden dacht ik makkelijk aan herbruikbare onderdelen te kunnen komen alleen:
Oh ja, als ik documentatie rondom het lexicon maak is het dus in het engels...
Praatte over UDDI, een soort gouden gids voor catalogi. Op zich werkt het wel, het is een standaard formaat met bedrijfsgegevens en productgegevens. Verschillende UDDI servers kunnen nog met elkaar de gegevens uitwisselen ook. Zet je bedrijf er een keer in en je bent theoretisch voor iedereen vindbaar.
Maar er zitten nog een paar haken en ogen aan.
Op zich aardig dus, maar met beperkingen.
UDDI wordt het niet. Niet veel bedrijven doen er aan mee, een van de grote drie die een database bijhielden is er al mee gestopt. Een ad-hoc methode werkt waarschijnlijk beter.
Wel eiste hij het gebruik van standaarden, standaarden, standaarden.
Benadrukte het belang van onafhankelijke gereedschappen. Losse programma's die je kan gebruiken zonder gelijk een hele stapel naar binnen te halen aan programma's waar je dan ook nog eens aan vast zit.
Belangrijk: ze hebben onderzoek gedaan naar eConstruct en bcXML is goed genoeg voor catalogusdata!
Belangrijkste van zijn praatje was de 80/20 regel:
Als je dit in gedachten houdt betekent het dat je die 80% van de gevallen op de eenvoudige eConstruct-manier kan oplossen en dat de de overige 20% kan laten zitten omdat dat voer voor de experts is!
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):