Vault installeren is zelden het probleem. De server draait binnen een dag en de eerste check-in lukt meteen. Of het team er over een halfjaar nog soepel mee werkt, wordt ergens anders beslist: in de inrichtingskeuzes van de eerste weken. Precies daar gaat het bij beginnende teams vaak mis, en precies die keuzes zijn later het lastigst terug te draaien.
In dit artikel zetten we de vijf Vault-valkuilen voor beginnende teams op een rij die in de praktijk het vaakst opduiken: te veel statussen, te veel rechten, de oude schijf één-op-één overnemen, bibliotheken tussen het projectwerk en het beruchte "even snel buitenom". Per valkuil lees je wat het gevolg is en hoe de omweg eruitziet. Geen van de vijf vraagt om extra software; een toolbox als Thundercad maakt het dagelijkse werk rond de kluis wel sneller, maar de valkuilen zelf omzeil je met afspraken.
Over de migratie zelf, dus het moment waarop de oude netwerkschijf leeg moet, schreven we eerder in Van Windows-mappen naar Vault: de overstap zonder drama. Hier gaan we ervan uit dat Vault draait en dat het team erin werkt, of dat althans probeert.
Valkuil 1: te veel statussen op dag één
Het overkomt bijna elk team: bij de inrichting wordt een prachtige levenscyclus ontworpen. Concept, in bewerking, ter controle, goedgekeurd, vrijgegeven, vervallen, en voor elke overgang een regel over wie hem mag uitvoeren. Op papier klopt het helemaal. Na een maand blijkt de helft van de documenten in een tussenstatus te hangen waarvan niemand meer weet waarom, en durft niemand iets vrij te geven omdat onduidelijk is wie "ter controle" eigenlijk moet afhandelen. Vrijgeven duurt ineens langer dan vroeger op de schijf, en dat was nou net niet de bedoeling.
De omweg: begin met de kleinste set die werkt. Voor de meeste teams is dat in bewerking en vrijgegeven, eventueel met één controlestatus ertussen. Uitbreiden is later een kleine ingreep; terugsnoeien is veel lastiger, omdat er dan al duizenden documenten in een status hangen die je wilt opheffen. Hoe je zo'n minimale set kiest en wanneer een extra status zijn plek wél verdient, werkten we uit in Lifecycles en statussen in Vault: pragmatisch, niet meer dan nodig.
Valkuil 2: iedereen adminrechten
Tijdens de inrichting is het zo handig: geef iedereen even administratorrechten, dan loopt niemand ergens tegenaan. Alleen wordt dat "even" daarna nooit meer teruggedraaid. Het gevolg laat zich raden: instellingen veranderen zonder dat iemand weet door wie, een categorie krijgt er ongemerkt een eigenschap bij, en op een dag blijkt een complete map definitief verwijderd. Niet uit kwade wil, maar omdat met adminrechten elke vergissing meteen een grote vergissing is.
De omweg: wijs twee beheerders aan, plus een reserve voor afwezigheid, en geef alle anderen een gewone rol met check-in, check-out en leesrechten. De beheerders gebruiken hun beheeraccount alleen voor beheer en werken de rest van de dag onder hun eigen naam. Rechten verruimen blijft mogelijk, maar het is dan een verzoek met een reden, geen zelfbediening. Dat klinkt formeler dan het is: in de praktijk gaat het om een paar verzoeken per maand.
Valkuil 3: de oude schijfstructuur één-op-één overnemen
De netwerkschijf na tien jaar organische groei: projectkopieën naast elkaar, persoonlijke mappen, "definitief" naast "definitief2", normdelen in vier varianten op zes plekken. Wie die structuur ongewijzigd in Vault zet, conserveert de chaos alleen maar in een beter systeem. Erger nog: het team blijft zoeken zoals het altijd zocht, bladerend door mappen, terwijl de kracht van Vault juist in het zoeken op eigenschappen zit.
De omweg: houd de mappenboom klein en saai, en laat metadata het echte werk doen. Een indeling die bij veel machinebouwers en plaatwerkbedrijven goed werkt:
- één tak voor projecten, met per project hetzelfde vaste rijtje submappen;
- één tak voor bibliotheken: normdelen, koopdelen en Content Center-bestanden;
- één tak voor sjablonen en beheer;
- één afgeschermde tak voor het oude archief, alleen-lezen.
Alles wat verder over een document te zeggen valt, projectnummer, klantorder, materiaal, status, hoort in eigenschappen en niet in mapnamen. Dan vindt een collega een onderdeel terug zonder te hoeven weten in welke map het ooit is beland.
Zoeken op eigenschappen werkt pas als die eigenschappen ook gevuld zijn. Met iProperty Panel vult je team metadata gestructureerd in via een vaste datakaart per documenttype, en dat went sneller dan mappen doorspitten.
Probeer 30 dagen gratisValkuil 4: bibliotheken niet apart zetten
Normdelen, koopdelen en Content Center-bestanden tussen het projectwerk zetten lijkt onschuldig, tot iemand voor één klant een koopdeel "even aanpast". Dat deel zit ook in veertig andere samenstellingen, en die veranderen ongevraagd mee. Of andersom: een bibliotheekdeel hangt nog in de status in bewerking, en ineens is een complete machine niet vrij te geven omdat één boutje formeel niet af is.
De omweg: zet bibliotheken in een eigen tak met eigen, strengere regels. Bibliotheekdelen staan standaard op vrijgegeven en zijn voor de meeste collega's alleen-lezen; wijzigen loopt via één verantwoordelijke. Wil een engineer een variant, dan wordt dat een nieuw bestand in plaats van een bewerking van het origineel. Zo blijft de bibliotheek wat hij moet zijn: een verzameling delen waar je blind op kunt vertrouwen.
Valkuil 5: "even snel" naast de kluis werken
De gevaarlijkste valkuil komt als laatste, want hij sluipt erin via uitzonderingen. Een spoedje vlak voor een deadline, een bestand naar het bureaublad kopiëren omdat dat sneller voelt, een export voor de klant die buiten Vault om wordt gemaakt. Elke keer ontstaat er een tweede waarheid: een bestand dat nieuwer is dan wat er in de kluis staat. Twee weken later bouwt een collega verder op de kluisversie, en het verschil komt pas boven water als de werkplaats twee tekeningen met hetzelfde nummer en verschillende maten in handen heeft.
De omweg bestaat uit twee delen. Regel de uitzonderingen expliciet: wie alleen hoeft te kijken krijgt een leesrol of een viewer, en voor externe partijen is er een vaste uitgifteroute. En maak de nette route de snelle route, want buitenom werken begint bijna altijd bij een klus die via Vault traag voelt. Bulkwerk is daarbij de hoofdverdachte: met Batch Publish van Thundercad publiceer je tekeningen in bulk naar PDF, DWG, DXF en STEP, en dat werkt samen met Vault. Dan is er ook onder tijdsdruk geen reden meer om buiten de kluis om te exporteren.
Veelgestelde vragen
Hoeveel statussen heb je minimaal nodig?
Twee kunnen genoeg zijn: in bewerking en vrijgegeven. Veel teams voegen daar één controlestatus aan toe zodra vrijgave langs een tweede paar ogen moet. Begin daar en breid pas uit als een concreet probleem erom vraagt, niet omdat het schema er mooier van wordt.
Hoe krijg je het team terug in Vault als iedereen eromheen werkt?
Zoek eerst uit waarom er buitenom gewerkt wordt; bijna altijd is de nette route ergens trager of onduidelijker dan de sluiproute. Los dat op, spreek daarna één heldere regel af (alles wat telt staat in de kluis) en kijk de eerste weken vriendelijk maar zichtbaar mee op de check-ins.
Kun je een verkeerde inrichting later nog rechtzetten?
Ja, maar de rekening groeit met elke maand wachten: statussen opheffen en mappen herschikken raakt dan duizenden documenten. Begin dus klein en simpel, dat is vrijwel altijd goed te repareren. Het dagelijkse werk rond de kluis versnellen kan intussen gewoon: probeer Thundercad 30 dagen gratis.