Drei Entscheidungen prägen eine Einführung stärker als die Produktwahl, und alle drei fallen in den ersten Wochen. Wie fein die Ablage gegliedert wird, wann die Berechtigungen festgelegt werden und was mit dem Altbestand geschieht. Zu allen dreien hat sich meine Haltung über die Jahre verschoben, und der Maßstab dafür ist jeweils derselbe geblieben. Wie sich das System im fünften Betriebsjahr anfühlt, nach zwei Umorganisationen und einem Wechsel in der IT-Leitung.
Die Ablage weniger fein gliedern
Der Reflex zu Beginn einer Einführung ist der Katalog. Dokumentarten, Ordnerebenen, Pflichtfelder, jede Abteilung bringt ihre Besonderheiten ein, und am Ende steht ein Schema mit vielen Dokumentarten und einem Ordnerbaum, der die Organisation abbildet. Das Schema ist am Tag der Freigabe vollständig. Mit der ersten Umorganisation passt der Ordnerbaum nicht mehr, und von den Dokumentarten wird im Alltag ein Teil benutzt, während der Rest Auswahllisten füllt, in denen das Erstbeste genommen wird.
Ich würde heute mit drei Pflichtangaben beginnen, wie in der Frage nach der Ablagestruktur beschrieben, und den Rest dem Dokument und der Suche überlassen. Eine Dokumentart kommt erst dazu, wenn sie eine eigene Frist, ein eigenes Recht oder einen eigenen Prozess hat. Alles andere ist Gliederung um der Gliederung willen, und sie veraltet mit der nächsten Umorganisation.
Die Berechtigungen zuerst festlegen
Berechtigungen werden gern am Ende konfiguriert, aus dem Organigramm abgeleitet, kurz vor dem Start. Das ist verständlich, weil das System erst dann steht. Die Folge ist ein Berechtigungsmodell, das die Linie abbildet und den Vorgang nicht kennt. Wer in einem Vorgang mitarbeitet, aber in einer anderen Abteilung sitzt, bekommt zu viel oder zu wenig. Nach dem Start wird nachgebessert, und jede Nachbesserung ist eine Ausnahme, die nach ein paar Jahren niemand mehr überblickt.
Ich würde die Berechtigungen heute vor der ersten Konfiguration festlegen, entlang der Vorgänge, und sie mit echten Fällen testen, bevor ein Dokument im System liegt. Der Grund ist derselbe, den ich für KI-Vorhaben in Berechtigungen gehören an den Anfang beschrieben habe. Ein Berechtigungsmodell lässt sich nachträglich nur mühsam korrigieren, und mit einer KI-Suche über dem Bestand wird jede Lücke sichtbar.
Den Altbestand nach Nutzung übernehmen
Die dritte Entscheidung betrifft die Migration. Die Erwartung ist oft, dass alles aus dem Altsystem in das neue kommt, jede Version, jeder Vorgang, jeder Ordner. Das kostet einen erheblichen Teil des Budgets und der Zeit, und ein Teil des übernommenen Bestands wird danach nicht wieder geöffnet. Was bleibt, sind Dokumente mit halb passenden Metadaten in einem System, das für sie nicht gebaut wurde.
Ich würde heute nach Nutzung, Fristen und Nachweispflichten entscheiden, was übernommen wird. Offene Vorgänge und das, was im Tagesgeschäft gebraucht wird, kommen in das neue System. Abgeschlossene Vorgänge, die nur noch für Nachweise gebraucht werden, können in ein schreibgeschütztes Auslaufarchiv gehen, in dem die Fristen ablaufen und die Löschung stattfindet. Und ich würde den Ausstieg aus dem neuen System bereits bei der Auswahl testen, mit einem vollständigen Export eines Teilbestands, weil diese Frage Jahre später teuer wird, wie in Ein auslaufender ECM-Vertrag beschrieben.
Was bleibt, wie es war
Zwei Dinge haben sich bewährt. Der Fachbereich entscheidet über Dokumentarten, Fristen und Rechte, die IT setzt um. Und der Start erfolgt mit einem Bereich und einem Prozess, weil die ersten Wochen im Betrieb mehr über die Anforderungen sagen als jedes Fachkonzept.
Die drei Entscheidungen haben einen gemeinsamen Nenner. Sie ziehen Festlegungen an den Anfang, die sich später nur mit großem Aufwand ändern lassen, und sie sparen dafür die Nacharbeit im Betrieb. Eine Einführung zeigt ihren Wert im fünften Jahr. Der Starttermin ist nur der Tag, an dem diese Rechnung zu laufen beginnt.