Submittal-goedkeuringen traceren per sectie

Een projectteam kan in Procore nagaan welke submittal-revisie is goedgekeurd tegen welke specificatiesectie, zolang elke revisie met Create Revision wordt gemaakt en de goedkeuringshistorie niet wordt herschreven door Ball in Court terug te zetten. Wij zouden de nummering per specificatiesectie en de goedkeuringsstatussen aanzetten voordat de eerste submittal de deur uitgaat, en het terugdraaien van een workflow behandelen als een gelogde uitzondering. Dit is gebaseerd op vier Procore-supportpagina’s: What is a submittal revision?, Create a Submittal Revision, Best Practices: Submittals en Best Practices: Submittal Workflow Management.

Welke revisie geldt voor deze specificatiesectie?

Neem een illustratief geval: een uitvoerder vraagt welke werktekeningen zijn goedgekeurd voor specificatiesectie 03 30 00. Documentbeheer vindt drie revisies, alle met de status Closed, en een reactie van een beoordelaar die na een reset is aangepast. De submittal bestaat dus. Wat ontbreekt is een duidelijk dossier van welke revisie geldt, voor welke sectie, en wie die heeft goedgekeurd.

De Procore-supportpagina What is a submittal revision? beschrijft hoe dit begint. Als een team een nieuwe submittal maakt en gegevens met de hand uit de vorige overneemt, kunnen dubbele revisies ontstaan waarvan de relatie met eerdere revisies niet eenvoudig is vast te stellen of te koppelen. De pagina voegt toe dat er geen beperkingen waren op het revisieveld, zodat numerieke of alfabetische waarden, of zelfs woorden, tot inconsistente en verwarrende resultaten konden leiden.

Hoe Procore een revisie aan een specificatiesectie koppelt

What is a submittal revision? noemt de regel: om een revisie aan een submittal te koppelen moet die dezelfde Spec Section en hetzelfde nummer hebben, en dat gebeurt automatisch als je de gedocumenteerde stappen volgt. Create a Submittal Revision voegt de beperkingen toe. Je kunt alleen een revisie maken vanuit de meest actuele revisie, algemene gegevens worden overgenomen en het revisienummer loopt met één op. Bijlagen worden niet meegenomen tussen revisies.

Best Practices: Submittals beschrijft de instelling ‘Number Submittals by Spec Section’. Als die aanstaat, wordt specificatiesectie 03 30 00 met submittal 007 en revisie 01 weergegeven als #03 30 00-007.01; staat de instelling uit, dan wordt het #007.01. Dezelfde handleiding waarschuwt dat het zonder eigen statussen zoals ‘Approved / No Exceptions’ of ‘Rejected’ lastig kan zijn om de definitieve versie te vinden als alle revisies ‘Closed’ als status hebben. Het filter ‘Current Revision’ beperkt de weergave tot het laatste item.

Onze lezing: de specificatiesectie zit in het nummer, en de goedkeuring zit in de status en de reactie. Beide moet je instellen voordat submittals worden verstuurd.

Waar kan de goedkeuringshistorie worden overschreven?

Best Practices: Submittal Workflow Management behandelt het terugzetten van Ball in Court naar een eerdere stap. Als je dat doet en er nieuwe gegevens worden ingevoerd, worden eerder vastgelegde data, opmerkingen, reacties en bijlagen overschreven. De wijzigingen blijven bewaard in de wijzigingshistorie van het item, maar zijn niet direct zichtbaar, en de rapportage in Procore toont alleen de meest actuele gegevens. Best Practices: Submittals zegt dat de bewerkingsacties niet rapporteerbaar zijn in de rapportagetools, en raadt aan de submittal af te sluiten en te distribueren en een nieuwe revisie te maken als historische gegevens ertoe doen.

Create Revision werkt andersom. Volgens de workflowhandleiding kopieert het de details van het oorspronkelijke item onder een revisienummer, laat het eerder ingevoerde workflowgegevens weg en start het de workflow opnieuw bij stap één, zodat historische gegevens in het oorspronkelijke item bewaard blijven. Nog een risico zit in de configuratie: Best Practices: Submittals merkt op dat een aangepaste reactie die wordt bewerkt, de vorige reactie vervangt overal waar die is gebruikt.

Wie beslist hoe revisies op het project worden gemaakt?

De beslissing is welke revisiepraktijk het project als standaard hanteert, met als eigenaar de Submittal Manager, afgestemd met documentbeheer; Create a Submittal Revision merkt op dat alleen een gebruiker met ‘Admin’-rechten de status van een submittal kan wijzigen.

Wat je dit kwartaal doet

• Haal het submittal-logboek van één lopend project op, pas het filter Current Revision toe en maak een lijst van items waarvan Closed de enige status is.
• Controleer of Number Submittals by Spec Section aanstaat, en beslis dat voordat Submittal Builder draait op de volgende revisie van een specificatiesectie.
• Wijs één eigenaar aan voor eigen statussen en reacties, want een bewerkte reactie vervangt de oude overal.
• Meet per maand het aantal terugzettingen van Ball in Court ten opzichte van het aantal gemaakte revisies, aan de hand van de wijzigingshistorie.
• Controleer steekproefsgewijs of bijlagen bij elke nieuwe revisie opnieuw zijn toegevoegd.

Wat dit betekent voor een knelpunt van $1M of meer

Dit is de moeite waard om als één domein te herontwerpen wanneer fouten in submittal-revisies leiden tot herstelwerk, late materialen en claims op veel projecten. We zouden eerst de stroom op orde brengen: één eigenaar en één dossier per goedkeuring, genummerd per specificatiesectie. Regels doen de voorspelbare controles, zoals het matchen van specificatiesectie en nummer. AI leest het rommelige deel, zoals opmerkingen van beoordelaars op een pakket. Mensen nemen de beslissingen met gevolgen, en AI beslist nooit alleen. Lees hoe we revisies en RFI’s als één knelpunt aanpakken binnen projectinformatie-operaties; dezelfde dossierdiscipline geldt voor offerte- en orderrevisies.

Grenzen van dit bewijs

Dit zijn supportpagina’s van de leverancier. Ze beschrijven configuratie en aanbevolen werkwijze in Procore, niet hoe projectteams goedkeuringen in de praktijk vastleggen over specificatiesecties heen. Ze laten niet zien hoe vaak het terugzetten van Ball in Court goedkeuringsgegevens overschrijft, of wat dat kost aan herstelwerk of claims. Ze zeggen niets over andere documentbeheerproducten en geven geen benchmarks voor aantallen revisies of doorlooptijden van beoordelingen.