Specificaties aan objecten

nl-digigo / contractspecificaties

Uitwisselen van contractspecificaties, functies, objecten, werkzaamheden en informatieproducten.

https://nl-digigo.github.io/contractspecificaties/

1 stars 1 forks source link

Specificaties aan objecten #2

Closed ElisabethKloren closed 2 years ago

ElisabethKloren commented 4 years ago

Vragen aan de deelnemers van de gebruikersbijeenkomst Contract als data op 3 april 2020:

Hoe worden specificaties aan objecten aangeboden door opdrachtgevers in de uitvraag of na gunning? ~ Contract, vraagspecificatie eisen in PDF; ~ Als CSV bestand of anderszins als data; Wordt onderscheid gemaakt tussen objecttypes ("een brug") en individuele objecten ("Brug over de Zee")? Hoe zijn de objecten gedefinieerd? Zijn de objecten herkenbaar in de meegeleverde geometrische bestanden (GIS, IFC, CAD, Revit enzovoorts)? Hoe wordt de koppeling gelegd? Zijn de specificaties gerelateerd aan eigenschappen van de objecten?

Hebben opdrachtnemers behoefte aan afspraken, standaarden of handleidingen?

redmer commented 4 years ago

In sommige gevallen: opdrachtnemers hebben een eigen OTL waarnaar leverings-OTL of contractinformatie gemapt wordt, omdat verschillende opdrachtgevers erg verschillende informatiemodellen te maken hebben.
- Dat komt natuurlijk omdat opdrachtgevers en -nemers verschillende perspectieven op dezelfde zaak hebben. Ook de verschillende informatiebehoefte bij realisatie en beheer & onderhoud zorgt ervoor dat deze informatiemodellen nooit 100% overeen zullen komen.
Het ter beschikking stellen vh informatiemodel helpt al bij het goed kunnen mappen, zodat we in de toekomst wel geïntegreerder kunnen werken, zonder dat we nu nu met dezelfde structuur kunnen werken.
Het uitwisselformaat kan dan ook heel 'dom' zijn, als je maar opschrijft (liever gestructureerd dan alleen maar een PDF) wat de kolommen en types betekenen.

Tim-VI commented 4 years ago

Goed samengevat door Redmer. Om nog even terug te komen op een vraag uit de comment van Elisabeth; in erg weinig gevallen zijn objecten te herkennen in de meegeleverde geometrische bestanden. Als opdrachtgevers dat niet op orde brengen, dan zal het moeten groeien doordat opdrachtnemers dat moeten doen.

ElisabethKloren commented 4 years ago

objectnaam, objectbeschrijving, ??

RiX012 commented 4 years ago

Eens dat er een 'uitwisselingsmodel' moet komen wat super simpel is. De inhoud en het gebruik hiervan zijn wat mij betreft behoorlijk afhankelijk van het 'beoogd gebruik'. Terloops wordt het verschil tussen uitvraag en gunning genoemd, maar dat is volgens mij al een hele behoorlijke. Ik denk dat hier dan ook niet zozeer de focus moet liggen op HOE je het doet, maar WAT je doet. Dus welke stappen zijn er te nemen en hoe kunnen we die zo simpel mogelijk zetten. (een gestandaardiseerde Excel sheet is al heel wat).

RiX012 commented 4 years ago

Daarnaast nog een punt over de herkenbaarheid. Vaak en ook in de moderne wereld wordt dit natuurlijk opgelost met naamgevingsconventies (van individuele objecten). Dit is een makkelijke en veelgebruikte techniek om de uitwisseling en herkenbaarheid te vergroten. Ik ben hier persoonlijk geen fan van, maar ik denk dat het bekeken moet worden als optie. Al is het alleen maar om de voor- en nadelen inzichtelijk te maken.

ElisabethKloren commented 2 years ago

In de technische documentatie zal worden uitgegaan van "objecten" zoals die in de pdfs van contracten staan: zonder relatie naar geometrische representaties.