Het fundament waar elk ander deel op rust.

Deel 1 vertelt u niet hoe u een project draait, dat is de taak van Deel 2. Het doet iets wat belangrijker is. Het legt de begrippen vast, de hiërarchie van eisen, het Common Data Environment en de Level of Information Need waar elk ander deel van ISO 19650 op steunt. Krijg Deel 1 niet goed en de rest houdt geen stand.

Vier ideeën doen het meeste werk: de cascade, het CDE, LOIN en naamgeving, plus de partijen die ze bedienen. Ongeveer achttien minuten lezen.

Hoe zorgen we dat de informatie op een project ook echt bruikbaar is?

Het antwoord is een cascade. Eisen stromen naar beneden, van de strategische behoeften van de eigenaar, via wat elke asset en elk project vraagt, naar een formele opdracht aan het deliveryteam, dat antwoordt met een leverplan. Elk niveau vertaalt brede doelen naar concretere instructies. De herleidbaarheid loopt van de doelstellingen van de eigenaar bovenaan tot elk afzonderlijk bestand dat bij een toetspoort wordt ingediend.

OIR, Organisational Information Requirements

De OIR staat bovenaan. Hij benoemt wat een organisatie van haar informatie nodig heeft, over al haar projecten en assets heen, niet voor één project maar voor de hele portefeuille.

OIR's komen voort uit bedrijfsdoelen: kostenbenchmarking, onderhoudsstrategie, naleving van regelgeving, ESG-rapportage, planning van assetafstoting. De directie, het assetmanagement en het FM-team stellen ze op, met ondersteuning van een BIM-adviseur.

Jaarlijks herzien. Op elk project hergebruikt.

AIR + PIR, per asset, per project

Onder de OIR splitst de cascade in tweeën.

AIR (Asset Information Requirements) vertaalt de OIR naar wat een bepaald assettype vanaf de oplevering nodig heeft. Een ziekenhuis verschilt fundamenteel van een woontoren, andere apparatuurgegevens, andere keuringsschema's, andere operationele prioriteiten. De AIR legt die verschillen één keer vast; elk project van dat assettype hergebruikt ze.

PIR (Project Information Requirements) loopt ernaast mee, maar beantwoordt een andere vraag: wat moet de opdrachtgever weten om in elke projectfase de beslissingen te nemen? Haalbaarheid, concept, uitgewerkt ontwerp, technisch ontwerp, oplevering, elke fase kent een zakelijke vraag, en de PIR bepaalt wat die beantwoordt.

ILS, de informatieleveringsspecificatie

De ILS is het operationeel belangrijkste document in de cascade. Het is de formele specificatie die de aanbestedende partij uitgeeft aan het deliveryteam, adviesbureaus, aannemers en gespecialiseerde partijen, en die precies vastlegt welke informatie zij moeten produceren, in welk formaat en wanneer. Elke levering verderop in de keten erft de kwaliteit ervan, en daarom levert een vage ILS een vaag project op.

Uitgegeven bij de tender. Bindend bij aanstelling.

Een volledige ILS dekt drie gebieden. Technisch: authoring-software, bestandsformaten, modeloorsprong en coördinatensysteem, eenheden, naamgevingsconventie, LOIN per fase. Management: CDE-platform, informatiestatussen en poortgoedkeuringen, rollen, leveringsmijlpalen, MIDP-verwachtingen. Commercieel: indieningseisen voor de BUP, QA-procedures, leveringen per aanstellingsfase, acceptatiecriteria.

BUP, MIDP, TIDP, het team antwoordt

Niveau 4 is het antwoord van het deliveryteam op de ILS.

BUP (BIM-uitvoeringsplan) wordt twee keer uitgebracht, eerst als tenderbelofte die capaciteit aantoont, daarna na aanstelling als het contractuele leverplan. In eigendom van de Lead Appointed Party.

MIDP (Master Information Delivery Plan) is het gebundelde register van elke informatiecontainer op het project: alle teams, alle leveringen, alle data, alle formaten. In eigendom van en onderhouden door de Lead Appointed Party gedurende de hele delivery.

TIDP (Task Information Delivery Plan) is het eigen deel van elk taakteam binnen de MIDP, hun leveringen, controleurs en data. Meerdere TIDP's bundelen samen tot de MIDP.

VerdiepingWie wat maakt, de levenscyclus waarop het draait, en drie manieren waarop de cascade misgaat

Wie wat maakt

Document	Eigenaar	Wanneer
OIR	Directie + assetmanagement, met ondersteuning van een BIM-adviseur	Eén keer per organisatie; jaarlijks herzien
AIR	FM-team + assetmanager	Eén keer per assettype; hergebruikt over projecten
PIR	Projectteam van de opdrachtgever	Bij de start van het project
ILS	BIM-manager of informatiemanager van de opdrachtgever	Uitgegeven bij de tender; bindend bij aanstelling
BUP	Lead Appointed Party	Vóór aanstelling (tender) + na aanstelling (contract)
MIDP	Lead Appointed Party	Doorlopend onderhouden tijdens delivery
TIDP	Elke Appointed Party	Bij aanstelling; bijgewerkt tijdens delivery

De vier levenscyclusfasen die de cascade bedient

De cascade is geen doel op zich, ze voedt een levenscyclus. ISO 19650 verdeelt het leven van de asset in vier werkfasen: Aanstellen (de eisen vastleggen vóór de tender), Mobiliseren (het CDE, de naamgeving, de verantwoordelijkheden en de beveiliging inrichten vóór de delivery), Leveren (de productiecyclus draaien en elke uitwisseling auditen) en Opleveren & beheren (het Project Information Model aanvaarden in het Asset Information Model en het in gebruik beheren). De informatie die u bij Aanstellen specificeert, bepaalt wat u bij Leveren ontvangt en wat u bij Opleveren auditeert.

Die laatste stap heeft een naam. Tijdens ontwerp en bouw is de levering het PIM (Project Information Model). Bij oplevering verandert het in het AIM (Asset Information Model), het dossier waarmee het beheerteam het gebouw de komende vijftig jaar bestuurt. ISO 19650-3 beheerst die overgang en de beheerfase daarna.

Drie veelvoorkomende faalpatronen

OIR en AIR overslaan. Veel projecten gaan meteen naar de ILS. Het gevolg: een ILS die technische output specificeert die het FM-team nooit zal gebruiken, en die juist de gegevens mist die het hard nodig heeft. Het symptoom komt na de oplevering naar boven, als het FM-team het assetregister vanaf nul opnieuw opbouwt.

Een BUP die te veel belooft. De BUP van vóór aanstelling verbindt zich aan LOIN-niveaus of leverritmes die het team niet kan halen. Tegen Fase 3 mist het team mijlpalen, en het contractuele risico zat al bij ondertekening ingebakken.

Een statische MIDP. De MIDP wordt bij aanstelling opgesteld en daarna nooit bijgewerkt. Tegen de vierde maand vertrouwt niemand hem meer, valt de wekelijkse leveringsbespreking terug op e-mail en WhatsApp, en stort de cascade in.

Wie is wie

De cascade vertelt u wat er wordt geproduceerd. Dit vertelt u door wie. ISO 19650 benoemt een kleine, bewuste set partijen, en het hele raamwerk gaat ervan uit dat u weet wie welke is.

Als niemand een proces bezit, faalt het. Als twee partijen er allebei van uitgaan dat zij het bezitten, wordt het werk dubbel gedaan of valt het tussen wal en schip. Daarom legt de norm de hiërarchie vooraf vast.

De organisatorische rollen

• Aanbestedende partij, de opdrachtgever. Geeft het project opdracht, stelt de eisen (OIR, PIR, AIR, ILS), kiest het CDE en houdt de uiteindelijke goedkeuringsbevoegdheid. Op de meeste projecten delegeert de opdrachtgever de dagelijkse taken aan een PM-adviseur, maar houdt zelf het laatste woord over goedkeuringen.
• Lead Appointed Party, het leidend adviesbureau tijdens het ontwerp, de hoofdaannemer tijdens de bouw. Draagt de primaire contractuele verantwoordelijkheid voor het leveren van informatie, coördineert iedereen daaronder en bezit de BUP en de MIDP.
• Appointed Parties, onderadviseurs en onderaannemers. Leveren hun informatie tegen de ILS; elk bezit de eigen TIDP.
• Taakteams, de disciplineteams die het productiewerk doen.

De twee functionele rollen

Twee rollen werken dwars door die hiërarchie heen in plaats van erbinnen:

• Informatiemanager, bezit het informatiemanagementproces zelf: CDE-governance, datakwaliteit, de poortgoedkeuringen per fase. Op grote programma's zijn er vaak twee, één aan de kant van de aanbestedende partij, één aan de kant van de Lead Appointed Party.
• BIM-coördinator, bezit de dagelijkse modelcoördinatie binnen en tussen disciplines, draait de clashdetectie en voert de Poort 1-controles uit voordat informatie wordt gedeeld.

De verantwoordelijkheid volgt de hiërarchie: de aanbestedende partij is verantwoordelijk voor eisen, goedkeuring en acceptatie bij oplevering; de Lead Appointed Party voor de delivery; de Appointed Parties en taakteams voor de productie. De volledige RACI-matrices staan in Deel 2 en de rollenpakketten, Deel 1 legt alleen de begrippen vast.

Het Common Data Environment

Het CDE vervangt versnipperde uitwisseling, gemailde bijlagen, USB-sticks, WhatsApp-deelacties, persoonlijke mappen, door één beheerd platform waarop alle projectinformatie wordt opgeslagen, gecontroleerd en verdeeld. Het platform is de techniek; het CDE is de techniek plus het proces.

De vier statussen

Elke informatiecontainer bestaat in één van vier statussen. De status bepaalt wie hem mag zien en waarvoor hij mag worden gebruikt.

• WIP, work in progress. Privé voor het producerende taakteam. Mag fouten, plaatshouders en concepten bevatten. Niet om door anderen op te bouwen.
• Gedeeld, Poort 1 gepasseerd. Zichtbaar voor andere projectteams ter coördinatie. Niet voor inkoop- of bouwbeslissingen.
• Gepubliceerd, Poort 2 gepasseerd. De goedgekeurde, actuele versie van het dossier. Van contractuele kwaliteit. Gebruikt voor de bouw, indiening bij de overheid, commerciële beslissingen.
• Gearchiveerd, vervangen door een nieuwere versie, of het as-builtdossier. Bewaard voor het audittrail. Historisch, niet actueel.

De twee poorten

De poorten zijn wat het CDE beheerd maakt. Het zijn de kwaliteitscontroles die voorkomen dat ongecontroleerde informatie voor coördinatie of bouw wordt gebruikt.

Poort 1, WIP naar Gedeeld. Uitgevoerd door de BIM-coördinator van het producerende team. Controleert naamgevingsconventie, modelgezondheid (geen waarschuwingen, opgeschoonde inhoud, juiste oorsprong) en LOIN tegen de specificatie. Afgekeurde inzendingen gaan terug voor herstel.

Poort 2, Gedeeld naar Gepubliceerd. Uitgevoerd door de Lead Appointed Party namens de aanbestedende partij. Controleert naleving van de ILS, coördinatie tegen het coördinatiemodel en formele goedkeuring. Goedgekeurde informatie gaat naar Gepubliceerd met de bijbehorende geschiktheidscode.

VerdiepingStatuscodes, de goedkeuringsworkflow, en waarom een gedeelde schijf geen CDE is

Geschiktheidscodes (statuscodes)

De status van een document zegt waar het leeft; de statuscode zegt waarvoor het is goedgekeurd. De code reist mee met de container en verandert bij elke overgang. De standaardset:

Code	Status	Wat het betekent	Wie erop mag bouwen
S0	Work in progress	In ontwikkeling; niet om te delen	Auteur / opstellend team
S1	Geschikt voor coördinatie	Gedeeld voor ontwerpcoördinatie	Heel het ontwerpteam
S2	Geschikt ter informatie	Alleen ter informatie gedeeld, geen actie	Volledig projectteam
S3	Geschikt voor beoordeling & commentaar	Uitgegeven voor formele beoordeling, reactie vereist	Beoordelaars opdrachtgever / adviseur
S4	Geschikt voor fasegoedkeuring	Ingediend voor formele fase-/poortgoedkeuring	Goedkeurende instantie
S5	Geschikt voor calculatie	Vrijgegeven voor calculatie / kostenraming	Calculatie + commercieel
S6	Geschikt voor fabricage	Vrijgegeven voor fabricage / inkoop	Aannemers / fabrikanten
S7	Geschikt voor de bouw	Goedgekeurd voor gebruik op de bouwplaats	Bouwteams / aannemers
A1–An	Goedgekeurd / aanvaard	Formeel geautoriseerd; vervangt eerdere revisies	Volledig team + opdrachtgever
CR	As-builtdossier	Definitieve vastlegging van wat is gebouwd	Gearchiveerd voor FM / beheer

Een typische constructietekening loopt S0 → S1 (coördineren met installaties) → S3 (beoordeling opdrachtgever) → S4 (fasegoedkeuring) → A1 (goedgekeurd) → S7 (vrijgegeven voor de bouw). Het CDE legt vast wie de status wijzigde, wanneer en met welke instructie, en die vastlegging kan achteraf niet worden aangepast.

De codes voor gepubliceerd/goedgekeurd worden in de ILS gedefinieerd en verschillen per raamwerk, sommige projecten gebruiken A1–A5 voor goedkeuringsgradaties plus B1 (bouw) en B2 (as-built) in plaats van S7/CR. Kies één schema per project en dwing het af in het CDE.

VerdiepingGa dieper

De goedkeuringsworkflow, drie rollen, één beslissing

Elk document doorloopt een gestructureerde beoordeling voordat het mag worden gebruikt. Drie rollen, bewust gescheiden gehouden:

• Auteur, maakt en uploadt de container met de juiste metadata, naamgeving en status, en wijst de controleur aan.
• Controleur, een vakgenoot binnen dezelfde discipline. Verifieert technische juistheid, naleving van de standaarden en volledigheid; stuurt door als het in orde is, stuurt terug met vastgelegd commentaar als dat niet zo is.
• Goedkeurder, hoofdontwerper, PM-adviseur of vertegenwoordiger van de opdrachtgever. Neemt de definitieve beslissing.

De beslissing van de goedkeurder is zelf gecodeerd: A goedgekeurd (gaat naar Gepubliceerd) · B goedgekeurd met commentaar (gaat door, commentaar verwerkt in de volgende revisie) · C afgekeurd, herzien & opnieuw indienen · D afgekeurd, niet opnieuw indienen (het concept moet worden heroverwogen). De ene regel die er onder alles ligt, functiescheiding, is dat een auteur nooit zijn eigen document mag goedkeuren. Het CDE dwingt het af.

Waarom een gedeelde schijf geen CDE is

ISO 19650 schrijft geen product voor. Autodesk Construction Cloud, Oracle Aconex, Asite, Trimble Connect, een ingerichte SharePoint, ze worden allemaal in de praktijk gebruikt. Wat de norm wel eist, is een set niet-onderhandelbare functies:

• Vier gescheiden statusgebieden, WIP, Gedeeld, Gepubliceerd, Gearchiveerd afgedwongen als statussen, niet als mappen.
• Rolgebaseerde toegangscontrole, elke gebruiker ziet alleen wat zijn rol vereist.
• Volledig audittrail, elke upload, download, statuswijziging en rechtenwijziging vastgelegd met gebruiker en tijdstip.
• Versiebeheer, vervangen versies gearchiveerd, nooit overschreven; de actuele versie altijd vindbaar.
• Naamgevingsvalidatie, niet-conforme bestandsnamen geweigerd bij upload.

Dropbox, Google Drive, OneDrive, zonder een governance-laag erbovenop zijn het gedeelde mappen. Submappen met de namen "WIP" en "Gepubliceerd" maken nog geen CDE; de statussen moeten worden afgedwongen, niet alleen gelabeld. De discipline komt neer op één regel die het waard is om aan de muur te hangen: als het niet in het CDE staat, bestaat het niet.

LOIN vervangt LOD

Het oude Level of Development-systeem perste drie verschillende dingen samen tot één getal. Een deur kon "LOD 400" zijn in vorm en nul bruikbare data dragen; een pomp kon datarijk zijn en geometrisch te zwaar voor coördinatie in een vroege fase. Het ene getal kon u niet vertellen welke van de twee.

LOIN, gedefinieerd in EN 17412-1:2020 en aangehaald door ISO 19650-1, scheidt de drie expliciet. Elk wordt per element en per fase gespecificeerd en bij elke data drop getoetst.

Drie dimensies

• Geometrisch, de 3D-vorm, afmeting en visuele detaillering in het model. EN 17412-1 splitst dit in vijf subaspecten die u apart kunt instellen: detail, dimensionaliteit, locatie, weergave, parametrisch gedrag.
• Alfanumeriek, de data die aan het element hangt: identificatie, materiaal, prestatie, classificatie (Uniclass / OmniClass), commerciële en FM-data.
• Documentatie, de onderliggende bestanden die in het CDE aan het element zijn gekoppeld: datasheets, certificaten, berekeningen, O&M-handleidingen, garanties.

De een specificeren zonder de andere levert modellen op die er goed uitzien maar verderop onbruikbaar zijn, of modellen die de data dragen maar te zwaar zijn om te coördineren.

Over de fasen heen, een deur

In de conceptfase heeft een deur alleen een eenvoudig paneel met globale afmetingen nodig, de geometrie is minimaal, maar hij heeft nog steeds brandwerendheids- en akoestische data nodig. Documentatie: geen.

In het detailontwerp haalt de geometrie in: kozijn, draairichting, beglazing, krukken, scharnieren, dorpel. De data verdiept: materiaal, U-waarde, fabrikant, modelnummer. Documentatie komt erbij: productdatasheet, brandtestcertificaat.

Geometrie en data ontwikkelen zich op onafhankelijke curven. LOIN volgt elk apart, zodat de ILS in elke fase de juiste hoeveelheid van elk kan eisen zonder de ander te dwingen mee te lopen.

VerdiepingDe brug naar LOD, de grens met COBie, en een uitgewerkt voorbeeld

Als uw BUP nog in LOD spreekt

U hoeft niet te kiezen. LOD valt nauw genoeg samen met LOIN om een bestaande BUP te vertalen:

LOD	Geometrisch	Alfanumeriek	Documentatie	RIBA-fase
100	Symbolisch / schematisch; geen gemeten geometrie	Alleen type-identificatie	Geen	1 Voorbereiding & opdracht
200	Benaderd; geschatte afmeting, vorm, locatie	Basis, geschat oppervlak, indicatief materiaal	Conceptschetsen, oppervlakteschema's	2 Concept
300	Nauwkeurig, gemeten vanuit het ontwerp	Gespecificeerd, kwaliteit, belasting, brand, thermisch	Specificaties, globale datasheets	3 Ruimtelijke coördinatie
350	300 + aansluitingen en coördinatievrijslagen	300 + coördinatiedata	Coördinatierapporten, clashlog	4 Technisch
400	Fabricageniveau, verbindingen, profielen, bouten	Volledige fabricagedata	Werktekeningen, fabricageschema's	4/5 Technisch / bouw
500	As-built, ingemeten geverifieerd	Geverifieerd as-installed, serienummers, inbedrijfstelling	As-builts, O&M, certificaten, garanties	6 Oplevering

Het voordeel van LOIN is precisie. In plaats van "LOD 300 voor alle wanden" kunt u zeggen "nauwkeurige geometrie en exacte thermische eigenschappen, maar geen installatievolgorde of fabrikantsdatasheets tot het technisch ontwerp", en produceren teams alleen wat werkelijk nodig is.

LOIN is geen COBie

Een veelgemaakte verwarring: LOIN is het raamwerk om behoefte te specificeren over drie dimensies. COBie, beheerst door ISO 19650-4, is een gestructureerd dataschema om assetdata bij oplevering aan FM-systemen te leveren. COBie-velden komen overeen met de alfanumerieke en documentatie-LOIN die voor de opleverfase is gedefinieerd. Ze vullen elkaar aan, ze zijn niet uitwisselbaar.

Uitgewerkt voorbeeld, een luchtbehandelingskast over de fasen heen

Hetzelfde element gevolgd door elke fase. Elke rij is wat de LOIN voor dat element in die fase specificeert.

Fase	Geometrie	Data	Documentatie
1 Haalbaarheid	Plaatshoudervolume dat de ruimte in de technische ruimte vastlegt	Bereik koelcapaciteit, systeemtype	,
2 Concept	Generieke LBK-vorm, globale afmetingen en aansluitpunten	Capaciteit, luchtdebiet, afmetingen toevoer-/retourkanaal, vermogensvraag	,
3 Uitgewerkt ontwerp	Bevestigde afmetingen met spoelposities, filtersecties, ventilatorlocaties	Fabrikant, modelnummer, gewicht, akoestische data, GBS-regelpunten	Productdatasheet, akoestisch testrapport
4 Technisch ontwerp	Fabricagegereed: exacte afmetingen, onderhoudsruimtes, hijspunten, aansluitspecificaties	Data uit fase 3 plus installatievolgorde, inbedrijfstellingsparameters, reserveonderdelenlijst	Installatiehandleiding, inbedrijfstellingschecklist
5–6 Oplevering	As-built geverifieerd: werkelijke geïnstalleerde positie, alle wijzigingen op de bouwplaats	Serienummer, installatiedatum, vervaldatum garantie, onderhoudsinterval, filterwisselschema	O&M-handleiding, garantiecertificaat, T&C-rapport, GBS-puntenschema

Direct te gebruiken om ILS-clausules te schrijven: kies de faserij, somt de afmetingen op, voeg de tabel als bijlage toe.

Informatiecontainers en naamgeving

Deel 1 introduceert informatiecontainer als de term voor alles wat in het CDE wordt beheerd, een model, tekening, schema, certificaat of foto. De term is bewust generiek.

Elke container volgt de naamgevingsconventie die in de BUP is afgesproken. Op een project van enige omvang houdt het CDE er tienduizend of meer. Zonder consistente naamgeving betekent het juiste bestand vinden dat u de opsteller moet vragen, blijven versieconflicten onzichtbaar, worden automatische validatie en zoeken en rapporteren en hoeveelhedenextractie onhaalbaar, en is de opleverdata onbruikbaar voor het CAFM of CMMS van het FM-team.

De standaardconventie van acht velden, gescheiden door koppeltekens:

[Project] - [Opsteller] - [Discipline] - [Zone] - [Type] - [Volgnr.] - [Status] - [Revisie]

Voorbeeld: DXB-MR-AEC-AR-ZZ-M3-0001-S2-P03

Van links naar rechts geeft die naam het project, de opsteller (de producerende organisatie), de discipline (Architectuur), de zone (ZZ = alle zones), het type (M3 = 3D-model), het volgnummer, de geschiktheidsstatus (S2 = gedeeld ter informatie) en de revisie (P03). Niemand opent het bestand om te weten wat het is.

VerdiepingDe veldcodes en de regels die ze machineleesbaar houden

Disciplinecodes

AR Architectuur	ST Constructie	ME Werktuigbouw
EL Elektra	PL Sanitair	FP Brandbeveiliging
LN Landschap	CV Civiel	GE Geotechniek
SV Inmeting	AC Akoestiek	FA Gevel
VT Verticaal transport	EN Milieu	BM BIM-management
PM Projectmanagement	QS Calculatie	ZZ Meerdere / alle

Containertypecodes

M3 3D-model · M2 2D-model · IF IFC · DR tekening · SP specificatie · SH schema · RP rapport · VS visualisatie · CR certificaat · RI RFI · BQ hoeveelhedenstaat · PC puntenwolk · PH foto · FN notitie.

Scheidingsregels

Koppelteken tussen velden; nooit een koppelteken binnen een veld; alles HOOFDLETTERS; geen spaties; geen speciale tekens. Een samengestelde projectcode als DXB-MR telt als één veld. Het CDE dwingt dit af bij upload, een niet-conforme naam wordt geweigerd, niet stilzwijgend aanvaard.

Sommige platforms gebruiken een variant met negen velden die Zone en Verdieping splitst en een rolcode van één teken toevoegt. De conventie van acht velden hierboven is de canonieke; welke een project ook aanneemt, gaat in de BUP en in de validatieregels van het CDE.

Verder lezen

• ISO 19650-1:2018, concepten en principes, de bronnorm voor dit deel.
• UK BIM Framework, gratis implementatierichtlijnen, templates en de cascade uitgelegd.
• BSI, ISO 19650 / BIM, de volledige normfamilie.
• EN 17412-1:2020 definieert de Level of Information Need (LOIN) die in dit deel doorlopend wordt aangehaald.