Nu bedient u het fundament.
Deel 1 legde het fundament: de cascade, de CDE, LOIN, naamgeving en de partijen die meedoen. Het vertelde u wat er wordt geproduceerd en door wie. Deel 2 is de andere helft: hoe u een project draait daartegen. De aanstelling, de mobilisatie, de productiecyclus en de fasepoorten die een set eisen omzetten in een opgeleverd, geaudit informatiemodel.
ISO 19650-2 ordent dat alles in acht activiteiten: vier om de aanstelling op te zetten, vier die zich elke fase herhalen. Ongeveer zeventien minuten lezen. Hebt u Deel 1 nog niet gelezen, begin daar; dit deel gaat uit van die woordenschat.
Hoe verplaatst een project informatie nu echt van eis naar dossier?
Via een cyclus. ISO 19650-2 beschrijft de leveringsfase als acht activiteiten. De eerste vier bouwen de aanstelling op: de opdrachtgever benoemt de behoefte, nodigt uit tot inschrijving, leest de reacties, en tekent. De laatste vier zijn de motor die daarna draait: mobiliseren, produceren, leveren, en uiteindelijk afsluiten. Activiteiten vijf tot en met zeven herhalen zich in elke projectfase, en dat is wat er een cyclus van maakt in plaats van een rechte lijn.
De opbouw van de aanstelling beantwoordt wie, op welke voorwaarden, tot welke spec. De productielus beantwoordt en doe het nu, fase na fase, met elke uitwisseling gecontroleerd.
1, Beoordeling & behoefte
De aanstellende partij begint. Ze bevestigt haar eisen, de OIR, AIR en PIR uit de cascade van Deel 1, en zet die om in de ILS, de formele specificatie die ze aan de markt uitbrengt.
ISO 19650-2 legt drie dingen vast die de ILS moet dragen: de informatie-eisen, de informatieleveringsstandaarden, en de productiemethoden en -procedures voor informatie. De opdrachtgever maakt hier ook de fundamentele keuzes, het CDE-platform en de informatiemanagement-functie, want niets aan de levering werkt als die langs de tender glippen.
2, Uitnodiging tot inschrijving
De ILS gaat mee in het tenderpakket, met de referentie-informatie die een inschrijver nodig heeft om goed te reageren en de criteria waarop de inschrijvingen worden gescoord.
Dit is het moment waarop de eisencascade de markt ontmoet. Een vage ILS hier levert vage inschrijvingen op, en een vaag project. De helderheid van wat u vraagt, bepaalt het plafond van wat u ontvangt.
3, Tenderreactie
Elke kandidaat-lead-appointed-party antwoordt met een pBUP, de BUP vóór aanstelling. Die laat zien hoe ze van plan zijn te leveren: het benoemde team en de capaciteit, de techniekstack, de coördinatiestrategie, een concept-uittreksel van de MIDP, en een mobilisatieplan.
De pBUP is de enige betrouwbaarste voorspeller van hoe het team daadwerkelijk zal presteren, en daarom scoort de aanstellende partij hem, zwaar, voordat er iemand tekent.
4, Aanstelling
De winnende pBUP wordt uitgewerkt tot de bevestigde BUP, het contractuele leveringsplan dat ook echt wordt uitgevoerd. De aanstelling wordt getekend. De informatiestandaard, de methoden en procedures, de verantwoordelijkheden en de eisen worden allemaal bindend.
Dit is het scharnier van de hele norm. Alles ervoor is voorbereiding; alles erna is uitvoering tegen wat zojuist is vastgelegd.
5, Mobilisatie
Voordat er één levering wordt geproduceerd, mobiliseert de lead appointed party, het venster van vier tot zes weken tussen gunning en productief werk. Ze bevestigt de BUP, configureert de CDE, stelt de MIDP samen uit de plannen van de taakteams, en zet elk team op gang. Sla het over en het project besteedt maanden aan herstel van geïmproviseerde setups.
6, Samenwerkende productie
De taakteams produceren. Elke container wordt opgesteld in WIP, gecontroleerd bij Poort 1, en daarna verplaatst naar Shared voor coördinatie, de CDE-stroom die Deel 1 beschreef. De productie volgt de TIDP van elk team: het eigen deel van wat er moet komen, tegen welke termijn, op welk Level of Information Need.
7, Levering van het informatiemodel
Bij elke fasepoort beoordeelt en autoriseert de lead appointed party de informatie tegen de ILS en het coördinatiemodel, Poort 2, en levert die vervolgens aan de aanstellende partij als een formele informatie-uitwisseling, bijgehouden tegen de MIDP. Dan draait de lus: de volgende fase begint. (De kwaliteitsmechaniek van die uitwisseling, de Five Cs, de review Beslissing A/B, is de taak van ISO 19650-4; dat is Deel 4.)
8, Projectafsluiting
Bij de laatste fase stroomt de cyclus uit. Het geaccepteerde informatiemodel wordt gearchiveerd, geleerde lessen worden vastgelegd, en het PIM gaat over in het AIM, het beheerdossier waar het gebouw op draait. Die overdracht, en alles daarna, is het terrein van Deel 3.
VerdiepingDe acht activiteiten in één oogopslag, en wie er elke leidt
| # | Activiteit | Leiding | Belangrijkste output |
|---|---|---|---|
| 1 | Beoordeling & behoefte | Aanstellende partij | ILS opgesteld (3 componenten); CDE & standaarden gekozen; IM-functie toegewezen |
| 2 | Uitnodiging tot inschrijving | Aanstellende partij | ILS + referentie-informatie uitgebracht; beoordelingscriteria vastgelegd |
| 3 | Tenderreactie | Kandidaat-lead appointed party | BUP vóór aanstelling; benoemd team; concept-MIDP; mobilisatieplan |
| 4 | Aanstelling | Aanstellende + lead appointed party | Bevestigde BUP; aanstelling getekend; eisen bindend |
| 5 | Mobilisatie | Lead appointed party | CDE geconfigureerd; MIDP samengesteld; teams op gang; methoden getest |
| 6 | Samenwerkende productie | Taakteams | Containers geproduceerd WIP → Poort 1 → Shared, per TIDP |
| 7 | Levering van het informatiemodel | Lead appointed party | Poort 2 autoriseren; uitwisseling geleverd tegen MIDP; gepubliceerd |
| 8 | Projectafsluiting | Aanstellende + lead appointed party | Archiveren; geleerde lessen; PIM → AIM |
Activiteiten 5–7 herhalen zich in elke projectfase. De aanstellende partij kan meerdere lead appointed parties aanstellen; elke draait hetzelfde patroon tender → reactie → aanstelling met de eigen appointed parties eronder. De cascade van eisen in Deel 1 wordt hier weerspiegeld door een cascade van aanstellingen.
Een project heeft twee BUP's, geen één. De eerste wint het werk. De tweede levert het. Ze verwarren is hoe teams zich te ver vastleggen.
De BUP, twee keer geproduceerd
Deel 1 merkte op dat de BUP twee keer wordt geproduceerd. Hier is waarom dat onderscheid operationeel telt. De BUP vóór aanstelling is geschreven om te winnen, hij laat de aanstellende partij zien hoe het team zou leveren als het wordt gekozen. De bevestigde BUP is geschreven om te leveren, hij is het contractuele plan waar het team aan wordt gehouden, en hij vervangt de pBUP. Dezelfde documentfamilie, twee heel verschillende taken, twee heel verschillende belangen.
BUP vóór aanstelling, de inschrijving
Ingediend met de tenderreactie, onder ISO 19650-2 Clausule 5.3. Hij toont capaciteit en aanpak aan: hoe het team aan de ILS voldoet, wie erin zit en of ze de capaciteit hebben, de voorgestelde standaarden en software, een coördinatiestrategie, een concept-uittreksel van de MIDP, en een mobilisatieplan. Het is een verbintenis die een inschrijver aangaat om te winnen, precies daarom moet hij leverbaar zijn, niet wensgedreven.
Bevestigde BUP, het contract
Uitgewerkt uit de winnende pBUP na aanstelling (Clausule 5.4), binnen ongeveer vijftien tot twintig werkdagen, voordat de productie start. Hij verhardt alles: de bevestigde verantwoordelijkhedenmatrix en RACI, de afgesproken informatiestandaard en methoden, de TIDP's samengevoegd tot de MIDP, de CDE-configuratie, het LOIN per fase, de QA-procedure, en de opleverstrategie. Dit is het document waar de leveringsfase ook echt op draait.
VerdiepingWat er in een BUP staat, het QA-raamwerk erin, en de twee manieren waarop hij misgaat
De secties die de bevestigde BUP draagt
Projectinformatie · team en verantwoordelijkheden (organigram, benoemde rollen, RACI, scope van de sub-adviseurs) · informatiestandaarden (softwareversies, IFC-versie, coördinatensysteem, eenheden, Uniclass 2015) · CDE-configuratie (platform, mappen, naamgeving, statuscodes, goedkeuringsworkflow, toegangsmatrix) · de LOIN-specificatie · de MIDP-samenvatting en mijlpalen · kwaliteitsborging · coördinatieprocedures (clashworkflow, federatie, design-freeze-data) · beveiliging en data (een ISO 19650-5-plan waar het project dat rechtvaardigt) · opleverstrategie (FM-data, COBie, as-built, O&M).
De varianten voor adviesbureau en aannemer verschillen vooral in wie er leidt en in de nadruk per fase, het adviesbureau draagt de productie in de ontwerpfase en de multidisciplinaire coördinatie over de RIBA-fasen; de aannemer draagt de levering in de bouwfase: ontwerpmodellen ontvangen op LOD 300, uitgewerkt tot LOD 350 voor coördinatie en LOD 400 voor werktekeningen en fabricage, dan geverifieerd tot LOD 500 as-built, met 4D-fasering en de governance van de taakteams van de onderaannemers er bovenop. De structuur is dezelfde.
Het QA-raamwerk waar de BUP zich aan verbindt
Een serieuze BUP definieert zijn eigen interne kwaliteitspoorten, zodat geen container ongecontroleerd een gedeelde of gepubliceerde status bereikt. De standaard van JES is een raamwerk met vier niveaus: L1 zelfcontrole door de modelleur (naamgeving, modelgezondheid, interne clash) → L2 review per discipline/vak (rules-based model checking, metadata) → L3 coördinatiereview (clashdetectie op het coördinatiemodel, BCF-rapport) → L4 mijlpaal-poortaudit (formele scorekaart voor naleving van ILS/BUP, schriftelijke goedkeuring voordat een mijlpaallevering naar de opdrachtgever gaat). Alles wat vóór publicatie niet kan worden opgelost, wordt vastgelegd als een Non-Conformance Report en bijgehouden in de CDE.
Twee faalmodi
Een pBUP die te veel belooft. De inschrijving legt zich vast op LOIN-niveaus of leveringscadansen die het team niet haalt. Tegen fase 3 mist hij mijlpalen, en omdat de overcommitment is getekend, was de contractuele blootstelling al ingebakken bij aanstelling, niet later ontdekt.
Een standaard-BUP waar niemand op draait. Het team kopieert de BUP van het vorige project, laat de kolom voor de BIM-manager op "nog te bevestigen" staan, archiveert hem, en draait het project op routine. Een standaard-BUP versus een serieuze is de duidelijkste voorlopende indicator van projectkwaliteit die er is.
De eerste dertig dagen beslissen het project
Dit is het deel van de levering dat het vaakst wordt overgeslagen en het duurst om over te slaan. Mobilisatie is waar de fundamenten fysiek worden gebouwd: de CDE geconfigureerd, de MIDP samengesteld, de standaarden uitgebracht, de teams getraind. Doe het goed en het project draait vanaf dag één op betrouwbaar proces. Jakker het door, "direct beginnen bij ondertekening", en de eerste echte uitwisseling is de eerste keer dat iemand de workflow probeert, onder deadline.
ISO 19650-2 Clausule 5.4 vereist dat de appointed party in dit venster de BUP bevestigt, de MIDP ontwikkelt, en de CDE inricht. De norm behandelt het als vier weken gedisciplineerde setup, gedraaid als een programma met harde controlepunten.
Week 1–2, de BUP bevestigen
Beoordeel het contract en de ILS in detail. Voer een gat-analyse uit tussen wat de pBUP beloofde en wat het contract vereist. Stel de benoemde BIM-manager formeel aan. Stel de bevestigde BUP op en rond hem af, en dien hem in voor review door de opdrachtgever tegen het eind van week twee.
Week 2–3, de CDE configureren en testen
Richt de CDE in volgens de afgesproken structuur: de vier ISO 19650-statusgebieden, de toegangsmatrix, en, de allerbelangrijkste stap, naamgevingsvalidatie die niet-conforme uploads automatisch weigert. Zonder die stap vallen teams binnen enkele weken terug op hun eigen conventies. Test hem daarna: draai een pilot-uploadworkflow voordat er iemand op vertrouwt.
Week 2–4, de MIDP samenstellen
Bouw de MIDP bottom-up op uit de TIDP's van de taakteams (volgende sectie). Breng de wettelijke indieningsmijlpalen eerst in kaart, vergunningen, brand- en vluchtveiligheid, nutsvoorzieningen, duurzaamheid, en werk dan de ontwerpleveringen terug om elke mijlpaal met voldoende reviewtijd te voeden.
Week 3–4, de teams op gang zetten, dan live
Op gang zetten is niet inloggegevens mailen. Elke gebruiker wordt getraind op de standaarden en de CDE van het project, en moet daarna een test van de upload–review–download-cyclus doorstaan voordat hij productietoegang krijgt. Week vier sluit met de formele BIM-kickoffvergadering; de CDE gaat live; de productie begint.
VerdiepingDe kickoff, het risicoregister, en de val van de samengeperste mobilisatie
De BIM-kickoffvergadering
De formele lancering van het informatiemanagement-proces, gehouden aan het eind van de mobilisatie. Ze loopt het hele team door de goedgekeurde BUP, demonstreert de live CDE, neemt de MIDP en zijn eerste datadrop door, bevestigt de RACI, en bespreekt het mobilisatie-risicoregister met toegewezen eigenaren. Na deze vergadering kent iedereen de spelregels en waar zijn werk heen gaat.
Het mobilisatie-risicoregister
ISO 19650-2 vereist dat de appointed party risico's voor het informatiemanagement-proces benoemt en mitigaties voorstelt, bijgehouden als een levend register Kans × Impact, maandelijks beoordeeld. De terugkerende risico's met hoge impact en hun oplossingen:
| Risico | Mitigatie |
|---|---|
| CDE niet gereed bij go-live | Start CDE-inkoop vóór aanstelling; tijdelijke gelabelde map alleen voor week 1–2 |
| BUP niet goedgekeurd door opdrachtgever | Indienen week 1; aparte reviewvergadering week 2; maximaal twee revisierondes |
| Team niet getraind | Verplichte training week 3; geen productietoegang zonder bevestigde afronding |
| Naamgevingsconventie niet gehandhaafd | Server-side validatie ingeschakeld vóór go-live; niet-conforme uploads geweigerd |
| MIDP niet afgestemd op planning | Samen ontwikkelen met de planningsmanager; wettelijke mijlpalen eerst in kaart |
De val van de samengeperste mobilisatie
Mobilisatietheater is de benoemde faalmodus: veel kickoffvergaderingen, weinig meetbare setup, en dag dertig komt met de CDE ongeconfigureerd, de naamgevingsconventie nog in concept, en de MIDP ongebouwd. Behandel de mobilisatiechecklist als een harde poort op dag 7, 14 en 30, een niet-afgevinkt vakje is een planningsuitloop, geen huishouding. Waar de opdrachtgever echt niet kan wachten, draai dan parallelle mobilisatie: laag-risico vroege taken in een duidelijk gelabelde tijdelijke map terwijl de CDE er naast wordt geconfigureerd, alles ervan gemigreerd naar de live CDE vóór de eerste formele mijlpaal, en de aanpak vastgelegd in de BUP zodat vroege output als voorlopig wordt begrepen.
Hoe het leveringsplan wordt samengesteld
De MIDP wordt niet top-down geschreven. Hij wordt bottom-up samengesteld. Elk taakteam schrijft het plan voor het werk dat het bezit; de lead appointed party consolideert die tot één masterregister. De structuur weerspiegelt de partijen: productie gebeurt in de taakteams, dus het plan wordt gebouwd uit hun verplichtingen en opgerold, niet van bovenaf gedicteerd.
TIDP, het deel van elk team
Het Task Information Delivery Plan is de lijst van één taakteam met de informatiecontainers die het zal produceren: elke container benoemd volgens de conventie, de verantwoordelijke auteur, het Level of Information Need, de einddatum, de status die hij bij levering draagt, en zijn afhankelijkheden. Elk team dient zijn TIDP binnen ongeveer veertien dagen na aanstelling in bij de lead appointed party.
MIDP, het masterregister
De lead appointed party voegt alle TIDP's samen tot het Master Information Delivery Plan: elke container, elk team, elke datum, elk formaat, elke afhankelijkheid, over de hele aanstelling. Elke regel draagt de container-ID, titel, originator, discipline, type, statuscode, revisie, LOIN-referentie, geplande en werkelijke uitgiftedata, doelstatus, uitwisselingsmijlpaal, en afhankelijkheden. Het is het masterschema van de informatielevering, doorlopend onderhouden en bij elke uitwisseling getoetst aan de werkelijkheid.
VerdiepingBouwvolgorde, en de fout die hem fnuikt
Hoe het plan tot stand komt
- Breng de ILS in kaart, haal eruit wat er nodig is, per fase.
- Stel de TIDP's op, elk taakteam plant zijn eigen containers, eigenaren, LOIN, data, afhankelijkheden.
- Consolideer, de lead appointed party voegt de TIDP's samen tot de MIDP.
- Stem af, verzoen met de projectplanning, wettelijke mijlpalen eerst in kaart.
- Keur goed, akkoord van de opdrachtgever, daarna toetsen aan de werkelijkheid bij elke uitwisseling.
De statische MIDP
De allergewoonste leveringsfout: de MIDP wordt in week vier gebouwd tegen een planning die tegen week twaalf achterhaald is, en wordt daarna nooit meer aangeraakt. Tegen maand vier vertrouwt niemand hem nog, de wekelijkse leveringsreview valt terug op e-mail en WhatsApp, en het project verliest het ene register dat vertelde wat er verschuldigd was. Bouw de MIDP opnieuw bij elke informatie-uitwisselingsmijlpaal, niet alleen aan het begin. Een MIDP is alleen zo nuttig als hij actueel is.
De productiecyclus, poort voor poort
Deel 1 beschreef de vier statussen en twee poorten van de CDE. Deel 2 is waar ze hun werk doen. Elke container die een project produceert, loopt hetzelfde pad, privé geproduceerd, gecontroleerd, gedeeld, geautoriseerd, gepubliceerd, uiteindelijk gearchiveerd. De poorten leggen zich neer op de partijen: het producerende team controleert zijn eigen output, de lead appointed party autoriseert de uitwisseling.
Poort 1, WIP naar Shared
De BIM-coördinator van het producerende team draait hem. De controles: naamgevingsconventie, modelgezondheid (geen waarschuwingen, opgeschoonde inhoud, juiste oorsprong en coördinaten), en LOIN tegen de spec. Geslaagd, en de container gaat naar Shared, zichtbaar voor andere teams voor coördinatie, maar nog niet voor inkoop of bouw. Gefaald, en hij gaat terug voor nawerk.
Poort 2, Shared naar Published
De lead appointed party draait hem, namens de aanstellende partij. De controles: naleving van de ILS, coördinatie tegen het coördinatiemodel, en formele goedkeuring. Geslaagd, en de container is Published met de passende geschiktheidscode, geautoriseerd, contractwaardig, de huidige versie van record. Dit is ook het punt van de informatie-uitwisseling bij een fasepoort.
VerdiepingStatuscodes, en waar de regels voor uitwisselingskwaliteit wonen
De geschiktheidscodes (vaste canon, gelijk aan Deel 1)
De status van een container zegt waar hij woont; zijn statuscode zegt waarvoor hij is goedgekeurd. De code reist met de container mee en verandert bij elke overgang.
| Code | Status | Goedgekeurd voor |
|---|---|---|
| S0 | Work in progress | Alleen auteur / originerend team |
| S1 | Geschikt voor coördinatie | Ontwerpcoördinatie |
| S2 | Geschikt voor informatie | Alleen informatie, geen actie |
| S3 | Geschikt voor review & commentaar | Formele review, reactie vereist |
| S4 | Geschikt voor fasegoedkeuring | Fase- / poortgoedkeuring |
| S5 | Geschikt voor calculatie | QS / kostenraming |
| S6 | Geschikt voor fabricage | Fabricage / inkoop |
| S7 | Geschikt voor bouw | Gebruik op de bouwplaats |
| A1–An | Goedgekeurd / geaccepteerd | Volledig team + opdrachtgever; vervangt eerdere |
| CR | As-constructed dossier | Einddossier, gearchiveerd voor FM |
Bij een fase-uitwisseling loopt een container doorgaans S4 (ingediend voor fasegoedkeuring) → A1 (goedgekeurd). De gepubliceerd/goedgekeurd-codes zijn vastgelegd in de ILS en variëren per raamwerk, sommige projecten gebruiken A1–A5 plus B1/B2 in plaats van S7/CR. Kies één schema per project en handhaaf het in de CDE. De beslissing van de goedkeurder is zelf gecodeerd, A goedgekeurd · B goedgekeurd met commentaar · C afgekeurd, herzien & opnieuw indienen · D afgekeurd, niet opnieuw indienen, en de ene regel die er onder ligt, is scheiding van taken: een auteur keurt nooit zijn eigen container goed.
Waar de regels voor uitwisselingskwaliteit wonen
Deel 2 brengt de informatie naar de poort en draait het project eromheen. De mechaniek van de poortreview, de Five Cs waaraan een uitwisseling wordt getoetst, de records Beslissing A / Beslissing B die elke overgang verantwoord maken, het modelreviewrapport, en de controles op formaat en COBie, worden geregeld door ISO 19650-4. Dat is Deel 4. Lees dat voor hoe een uitwisseling daadwerkelijk wordt geborgd; lees dit deel voor hoe het project dat de uitwisseling produceert, wordt gedraaid.
Verder lezen
- ISO 19650-serie, BSI, Deel 2 behandelt de leveringsfase volledig.
- UK BIM Framework, templates voor BUP, MIDP en aanstelling.
Als u een handvol dingen onthoudt, onthoud dan deze.
De acht activiteiten. Vier om de aanstelling te bouwen, beoordelen & behoefte, uitnodigen, reageren, aanstellen. Vier die per fase rondlopen, mobiliseren, produceren, leveren, afsluiten. Eisen cascaderen omlaag; aanstellingen ook.
De twee BUP's. De BUP vóór aanstelling wint het werk; de bevestigde BUP levert het en vervangt hem. Laat de inschrijving niet te veel beloven van wat het contract moet houden, en draai het project niet op een standaardsjabloon.
Mobilisatie is de beslissende fase. Bevestig de BUP, configureer en test de CDE, stel de MIDP samen, train en toetstest elke gebruiker, in de eerste vier weken, gedraaid als een programma met harde controlepunten. Mobilisatietheater is de faalmodus om te vermijden.
TIDP → MIDP, levend gehouden. Elk team plant zijn eigen deel; de lead appointed party rolt ze tot één masterregister en bouwt het opnieuw bij elke uitwisseling. Een statische MIDP is een dode.
De poorten doen het werk. Poort 1 (BIM-coördinator: naamgeving, gezondheid, LOIN) verplaatst WIP naar Shared. Poort 2 (lead appointed party: ILS, coördinatie, goedkeuring) verplaatst Shared naar Published. De mechaniek van de uitwisselingskwaliteit achter de poort is de taak van Deel 4.
Volgende, Deel 3: De beheerfase
Deel 2 draaide het project en leverde het informatiemodel. Deel 3 pakt het op bij de oplevering: hoe het PIM het AIM wordt, hoe de asset-informatie wordt bestuurd en actueel wordt gehouden in gebruik, en wat ISO 19650-3 vereist over de decennia dat het gebouw daadwerkelijk in beheer is. Lees het hierna.
Deel 3 · De beheerfase →