Met de introductie van PDM, waarbij files in een database en door de applicatie gemanaged worden, lijkt er een eind gekomen aan file naamconventies. Helaas, er zijn vele redenen waarom we nog steeds afspraken moeten maken over filenamen.

De belangrijkste reden is natuurlijk dat files niet per definitie in het PDM systeem blijven. Toeleveranciers, co-developers, klanten en andere 3de partijen in het algemeen hebben in veel gevallen nog geen toegang tot de database.

Ja, je wilt je informatie graag toegankelijk maken. Maar dat houdt in dat licenties verstrekt moeten worden, firewall toegang geregeld moet worden, mogelijk VPN verbindingen moeten worden toegelaten. En dat moet allemaal natuurlijk wel met het doel de informatie veilig aan alleen de juiste partijen aan te kunnen bieden. Dus de eenvoudigste weg is nog steeds om informatie op de traditionele manier te communiceren. Ik sla hier het communiceren op basis van papier bewust over vanwege de hoge kosten en omdat dit mijns inziens in deze tijd van digitale media en netwerken niet meer nodig is. In sommige gevallen moeten file namen ook ondubbelzinnig zijn binnen uw bedrijf. Veel PDM systemen verzorgen import/export en checkin/checkout van files automatisch, maar veel ook niet waarbij een file nog steeds lokaal bij een gebruiker op zijn systeem terecht komt en gewijzigd gaat worden. Niet in de laatste plaats zullen file ook eerst lokaal gemaakt worden of van buiten af aangeleverd worden.

Er is dus nog steeds een behoefte aan afspraken over file naamconventies. Wat zijn de basis voorwaarden?

• De basis identificatie van elke file is een uniek identificatie nummer dus dat zal altijd onderdeel moeten zijn van de file naam.
• Aangenomen dat er een revisie mechanisme van toepassing is, zal dit ook onderdeel van de file naam moeten zijn. Dit is niet strikt noodzakelijk, aangenomen dat revisies van een file vrijelijk door elkaar te gebruiken zijn (ref. heridentificatie regels volgens CMII). Voor traceerbaarheid van wijzigingen is verwerking aanbevolen ook al omdat de file zelf waarschijnlijk een referentie bevat naar het referentie nummer. Omdat we dit niet standaard kunnen aannemen in een generiek datamodel, zal de revisie toch onderdeel moeten zijn van de file naam.
• Als gevolg van een aantal besluiten in het verleden genomen en actuele processen hebben veel bedrijven een datamodel waarbij meerdere documenten -file dus- een enkel business object beschrijven. In dit geval moet er onderscheid gemaakt kunnen worden om verschillende files voor eenzeflde document met uniek identificatie nummer gebruikt worden. Ik ga er hierbij voor de vorm van uit dat dit het volgnummer is.
• In aanvulling op het feit dat meerdere files een enkel document kunnen beschrijven, kunnen meerdere files die in principe gelijk zijn ook een enkel document beschrijven als de files in meerdere talen beschikbaar zijn. Ook hier geld dat als files uniek gemanaged en geidentificeerd moeten kunnen worden, de taal indicatie onderdeel moet zijn van de file naam.
• Om een file herkenbaar te maken, dat wil zeggen dat een gebruiker aan de file naam kan zien wat de inhoud van de file is, zal een korte beschrijving moeten worden toegevoegd. Op dit punt aangekomen ontstaat een extra probleem. Verschillende revisies van een file hebben hetzelfde unieke referentie identificatie nummer, maar hebben mogelijk een verschillende beschrijving. Ik moet aangeven dat dit niet zozeer een probleem voor identificatie oplevert als wel hoe filenaam en de filenaam attributen in het PDM systeem synchroon gehouden moeten worden. Mijn voorkeur is om de file naam automatisch te updaten met de attribuut gegevens zoals dit bij release in het PDM systeem aanwezig zijn. Tot aan release is een afwijking toegestaan, wat het voor de gebruiker makkelijker maakt.

In het kort komt leidt dit tot een file naamconventie die als volgt is opgebouwd:

<ID>-<Revisie>-<Taal>-<Beschrijving>.<extensie>

In dit geval heb ik het min-teken als scheidingsteken opgevoerd om de verschillende velden makkelijk te kunnen onderscheiden.