A Fájlok űrlapon lehetőségünk van egy kétszintű könyvtárstruktúra létrehozására. Ez egy fastruktúra, elvében és működésében is pontosan olyan, mint amit az operációs rendszerünk mappaszerkezetében már megszoktunk.

Az alábbi ábra egy lehetséges könyvtárszerkezetet szemléltet:

Itt 3 főkönyvtárunk és mindegyiknek 2-2 alkönyvtára van, ez azonban csak egy példa. A gyakorlatban tetszőleges számú főkönyvtárt hozhatunk létre és szintúgy, bármely főkönyvtáron belül készíthetünk tetszőleges számú alkönyvtárat.

Az egyetlen kitétel a struktúra mélységére vonatkozik; tehát egy alkönyvtáron belül már nem lehet al-alkönyvtárat létrehozni. A gyakorlati tapasztalatunk azt mutatja, hogy ez a kétszintű struktúra elegendő még nagyszámú fájl tárolásához is.

Egy fő- vagy alkönyvtárban tetszőleges számú fájlt tudunk elhelyezni. Egy állományt elhelyezhetünk egy főkönyvtárban is, egy alkönyvtárban is - de akár a legfelső szinten is, azaz egyik fő- vagy alkönyvtárat sem jelöljük ki a feltöltéskor.

Tippek és tanácsok a rendszerezéshez

A rendszerezés lehetősége tehát adott, a leggyakoribb kérdések egyike azonban éppen az, milyen struktúra a legjobb? Ezúton szeretnénk tippeket, tanácsokat adni a rendszerezéshez. Ezek ajánlások, nem muszáj követni ezeket, de mindenképpen érdemes elolvasni.

1. Rendszerezés már az indulástól

Rend a dolgok veleje - valljuk mi az Online Cégmenedzsernél. Már az első fájlunk feltöltésekor gondolkodjunk előre és alkossuk meg a fő- és alkönyvtárunkat.

Praktikus, ha a cég operatív ügyeit felülről látó és átlátó munkatársunkat bízzuk meg a könyvtárszerkezet kialakításával és erről előre tájékoztatjuk a rendszerhez hozzáférő felhasználóinkat is.
Így két legyet ütünk egy csapásra:

  • eleve elkerüljük a későbbi bosszúságokat
  • ismertetjük a felhasználókkal a rendszer használatának módját

Régóta ismert tapasztalat az ERP szakmában, hogy minden rendszer annyit ér, amennyire lelkiismeretesen bevezették azt.

Eleinte apróságnak tűnik ez a tipp, de higgyük el, amikor 10 felhasználó 10 különböző nevezéktannal, önkényesen nevezi el a könyvtárakat és 1000 fájl rendszertelenül, néha ide, máskor amoda került feltöltésre, akkor kezd átláthatatlan lenni ez az állományhalmaz.

Továbbá jellemzően mindig hetekkel vagy hónapokkal a feltöltés után kellene megkeresni egy rendkívül fontos állományt, ám ott nincs, ahol kellene, a feltöltője pedig már nem is emlékszik hova tette azt. Kerüljük el ezt, rengeteg időpazarló művelettől kíméljük meg magunkat!

2. A "legjobb" struktúra

Röviden a legjobb struktúra az, ami

  • pontosan modellezi a cégünk működését
  • minden felhasználó számára egyértelmű, rövid, ráutaló könyvtár-elnevezéseket használ
  • a könyvtárak neve egységes nevezéktannal készülnek, olyannal, amit a cég működésében minden felhasználó jól ismer és ért
  • a fájlok eloszlása a könyvtárakban hozzávetőlegesen egyenletes. Ha az egyik könyvtárban 1000 fájlunk van, az összes többiben 1-1, akkor erős a gyanú, hogy ez a struktúra nem a legjobb.
  • a főkönyvtárak száma nagyságrendileg kevesebb, mint az alkönyvtáraké - azaz a struktúra vizuálisan leginkább egy piramishoz hasonlítana. Ha van 200 db főkönyvtárunk és mindössze 5 alkönyvtárunk, gyanakodhatunk arra,  hogy ennél van optimálisabb megoldás. A felhasználói felület kezelhetősége szempontjából sem praktikus, ha a legördülő főkönyvtár listában 200 elemet kell görgetnünk. Érdemes átgondolni az átszervezésüket, inkább legyen 20 főkönyvtárunk, és mindegyikben 2-10 alkönyvtár. Sokkal gyorsabb lesz a rendszerezés és a keresés is.

3. A projektfókuszú könyvtárszerkezet

Az előző pontban vázolt elméleti tanácsok után néhány konkrét, a gyakorlatban is jól bevált könyvtárstruktúrát ismertetünk, ami egy projektalapú szolgáltatócég működését hatékonyan támogatja. A javaslatunk szerint a projektek kulcsfontosságú paramétereiből kell kiindulnunk, ezek képezhetik a rendszerezés alapját:

Ügyfélnév
Praktikus, ha az üzleti partnercég vagy intézmény rövid nevéből indulunk ki. Például a 'OCM Systems Kereskedelmi Korlátolt Felelősségű Társaság' a könyvtárstruktúra elnevezésében legyen csak 'OCM'.

Helyszín
Ha az üzleti partnerünknek több telephelye/irodája van szerte az országban vagy a határokon kívül és várhatóan több telephelyen is fogunk projektet végezni, akkor egyrészt ezeket célszerű külön projektként kezelni, másrészt a könyvtár elnevezésekben is érvényesíteni ezt. Például:

  • OCM Budapest, vagy OCM Bp.
  • OCM Debrecen
  • OCM Ausztria

Ha egy településen is több telephely van, az utca nevével és házszámmal is megtoldhatjuk: OCM Bp. Fűrész utca.

Évszám
Az évszám feltüntetése magától értetődően hasznos és informatív, jól rendszerezi a fájljainkat. Ha egy esztendő alatt nagyon nagy számú projektet végzünk el, jó ötlet az évet megtoldani a negyedév feltüntetésével; így még átláthatóbb lesz a könyvtárszerkezetünk.

Projekt típusa
Ha a szolgáltatásaink és projektjeink tipizálhatók, tehát néhány (3-10) kategóriába besorolhatóak, akkor ezek rövid elnevezése is képezheti a rendszerezés alapját. Például a kipróbálható Demo rendszerben a villamossági cég tipikusan az alábbi projekteket végzi:

  • led világítás
  • riasztó
  • szellőzés
  • fűtéstechnika

Ez a típusalapú rendszerezés elvethető, amennyiben a projektjeink jellemzően vegyesek, tehát az ügyfelek rendszerint 2 vagy több típust rendelnek meg egyszerre, egy projektben.

Most rakjuk össze a nagy képet
Négy elemünk van és kétszintű könyvtárstruktúránk, tehát egészséges kompromisszumot kell kötni. Nem kötelező minden elemet felhasználni és az egyes elemek össze is vonhatók.

Kisszámú, állandó ügyfélkör esetén

Ha kisszámú, állandó ügyfélkörrel dolgozunk több éven keresztül változatos projekteken, akkor célravezető lehet ez a séma:

  • főkönyvtárak neve: [ügyfél neve] + [év], például: OCM 2020
  • alkönyvtárak neve: [projekt neve], például: Riasztószerelés

Ha az ügyfelünknek sok telephelyén végzünk projekteket, akkor a helyszínt is belehelyezzük a főkönyvtár nevébe:

  • főkönyvtárak neve: [ügyfél neve] + [helyszín] + [év], például: OCM Bp. 2020
  • alkönyvtárak neve: [projekt neve], például: Szellőzéstechnika

Pár tipikus projekt, sok ügyfélnek

Ha a projektjeinket tudjuk tipizálni, ám nagyszámú ügyfélkörnek dolgozunk és mindig újabb és újabb ügyfelek rendelnek meg projekteket, akkor célszerű a főkönyvtárak esetében a projekt típusával és az évszámokkal operálni, az alkönyvtárak neve lehet az ügyfél neve és alternatívaként a helyszín.

  • főkönyvtárak neve: [projekt típusa] + [év], például: LED 2020
  • alkönyvtárak neve: [ügyfél neve] + [projekt neve], például: OCM Bp. világítás modernizáció

Nem tipizálható projektek, sok ügyfél

Ha a projektjeink pedig nem tipizálhatók, mert összetettek és változatosak, akkor az első rendezési elv lehet az év, a második az ügyfél, az alábbi séma alapján:

  • főkönyvtárak neve: [év], például: 2020
  • alkönyvtárak neve: [ügyfél neve] + [helyszín], például: OCM Bp. Fűrész utca

Ha egy adott évben nagyon nagy számú projektünk van, áttekinthetetlenül hosszúvá válhat az alkönyvtáraink listája, ez esetben az évet akár negyedévekre is bonthatjuk és a nemzetközi szabvány szerint Q1, Q2, Q3 és Q4 (Q = quarter, negyedév) jelölésekkel illethetjük.

  • főkönyvtárak neve: [év] + [negyedév], például: 2020 Q1
  • alkönyvtárak neve: [ügyfél neve] + [projekt neve]: OCM Debrecen világítás és riasztó

A fenti elvek alapján más nyerő kombináció is elképzelhető. Javasoljuk, hogy gondolja végig a saját céges működését és a bemutatott példák alapján alkossa meg az Ön cégének legmegfelelőbb rendszerezést.

A fájlok javasolt nevezéktana

A fájlok nevei szinték akkor lesznek a szoftverben jól kereshetőek és emberi szemmel is gyorsan értelmezhetőek, ha bevezetünk egy ún. nevezéktant. Praktikusan itt is a fenti elvet követjük:

[ügyfél] + [helyszín] + [fájl tartalma]

Például: 'OCM Bp. Fűrész utca riasztó bekötési rajz.pdf'

Mindenképpen kerüljük el azt, hogy a fájlokat létrehozó szoftver alapértelmezett, semmitmondó fájlneveivel kerüljenek fel az állományok. Például az 'Új dokumentum 34.docx' nevű fájl később sok fejtörést fog okozni a rendszer minden felhasználója számára.