Category: ecm

erst vor kurzem hatte ich ein wenig über die versionierung geschrieben – ok, es war heute – (btw: mehr unterschiede zwischen einem dms und einem fileshare habe ich hier in 5 teilen zusammengeschrieben: 1, 2, 3, 4, 5); und wie es halt nun mal so ist, gibt es auch details, die nicht so perfekt sind – wie z.b. die minor versions…

wichtig ist, dass man folgendes im hinterkopf behält:

– man kann die anzahl der major versions festlegen

– man kann die anzahl der major version festlegen, die minor versions haben

– man kann aber nicht die maximale anzahl der minor versions einer major version festlegen!

man erwartet nur bei der zweiten option die anzahl der minor versions festzulegen, tatsächlich ist dem aber eben nicht so:

Was passiert also, wenn man wie im Beispiel oben die einstellung 5/3 wählt? angenommen von einem dokument gibt es folgende versionen:

6.0 – 6.1

5.0 – 5.1 – 5.2

4.0 – 4.1

3.0 – 3.1 – 3.2 – 3.3

2.0

1.0

und man published eine neue major version, dann erhält man folgendes:

7.0

6.0 – 6.1

5.0 – 5.1 – 5.2

4.0 – 4.1

3.0 – 3.1 -3.2 – 3.3

2.0

warum? nun, die version 1.0 wurde gelöscht, weil es die 6 major version ist, jedoch ja nur 5 aufgehoben werden. wenn man nun die nächste minor version, also 7.1, erstellt so werden 3.1 – 3.3 ebenfalls gelöscht; weil ja nur von 3 major die minor versions aufbehoben werden; also eigentlich ziemlich einfach, oder?

ein ganz eindeutiger vorteil eines dms gegenüber einem normalen fileshare ist die möglichkeit, dokumente zu versionieren und damit zum einen änderungen nachvollziehen, aber auch zum anderen unabsichtliche” änderungen ohne restore wieder rückgängig machen zu können, indem man einfach die vorherige version wiederherstellt.

nicht alle anwender sind sofort davon begeistert – doch wenn man erst einmal begonnen hat, sich damit zu beschäftigen, lernt man es sehr schnell schätzen; üblicherweise durchläuft man folgende stufen:

stufe 0: keine versionierung

für manche anwendungsgebiete völlig ausreichend, trotzdem aber technologische steinzeit: willkommen am fileshare – wollten wir nicht eigentlich schon längst weg davon?

stufe 1: major versions

mit der aktivierung von major versions haben endlich die endlosen dateilisten a la “20080731 Angebot XY V0.3.doc” ein ende – zumindest, wenn man das feature richtig einsetzt. wozu eine versionsnummer, wozu ein datum im filenamen? dies übernimmt die versionierung!

denken wir an folgendes beispiel: in einer library liegt neben vielen anderen ein file namens “incentive.doc”. wäre es nicht fein, wenn man per mail informiert wird, sobald es eine änderung in dieser datei gibt?

hier kann uns ein weiteres dms feature namens “alert me” helfen – in unserem beispiel aktivieren wir die alertierung nur auf das eine dokument, weil uns änderungen an allen anderen dokumenten nicht interessieren:

sobald nun also eine neue version des dokumentes hinzugefügt wird, erhalten wir eine benachrichtigung per e-mail. praktisch, oder?

ein weiterer großer vorteil: der link zu dem dokument bleibt immer gleich, und es öffnet sich immer die aktuelle version…

stufe 2: minor/major versions

nachdem der link zu dem dokument immer gleich bleibt und andere anwender sich vielleicht über änderungen an dokumenten, die in ihrer verantwortung liegen, benachrichtigen lassen kommt schnell eine weitere anforderung: solange sie noch an zwischenversionen arbeiten, soll diese für andere anwender nicht sichtbar sein – für diese soll weiterhin nur die letzte major version sichtbar sein.

kein problem: verwenden sie minor/major versionierung!

stufe 3: check in / check out

zuletzt möchte man normalerweise verhindern, dass jemand anders ebenfalls ein dokument bearbeitet während man selbst änderungen vornimmt – damit sind sie bei der letzten stufe angekommen: aktivieren sie check in /check out!

natürlich ist das weit nicht alles; zum einen sind diese stufen nur fiktiv – d.h. man kann natürlich z.b. check in / check out auch ohne versionierung oder nur mit major versions verwenden. zum anderen bietet sharepoint aber auch noch weit mehr in diese richtung, wie z.b. einen approval workflow: eine major version muss so z.b. von ein oder mehreren personen abgenickt werden, bevor diese gültig ist. selbstverständlich bleibt die workflow history ersichtlich, sodass alle schritte zu jedem zeitpunkt nachvollzogen werden können. bist du bereit?