Autoren: Ulrich Gerke, Volker Halstenbach, Bernhard Zöller

Die Einführung eines Enterprise Content Management (ECM) bzw. eines Dokumenten Management Systems (DMS) umfasst weit mehr als die bloße Bereitstellung und Verteilung der erworbenen Softwarelizenzen. Es ist immer ein technisch-organisatorisches Projekt, welches tief in die Arbeitsweise von Unternehmens- bzw. Verwaltungsbereichen und Abteilungen eingreift. Ein DMS/ECM verändert, wie Informationen entstehen, wie sie verarbeitet, dokumentiert und abgelegt werden. Damit beeinflusst es typischerweise die Zusammenarbeit, Verantwortlichkeiten und Entscheidungswege in einem Unternehmen bzw. einer Verwaltung.

Deshalb ist die Einführung eines DMS/ECM zwar auch ein IT-Projekt, aber vor allem ein Organisations- und Modernisierungsprojekt, welches an mehreren Stellen „alte Zöpfe abschneidet“ und überholte Geschäftsabläufe ablöst.

Das klingt vielleicht eher abschreckend. Aber mit der konsequenten Beachtung einiger zentraler Leitlinien lässt sich die Einführung gut steuern, Probleme und Risiken frühzeitig erkennen und der Einführungsaufwand minimieren.

I. Vor der Einführung: Die passende DMS/ECM-Lösung auswählen

Die Einführung einer DMS/ECM-Lösung muss frühzeitig und umfassend geplant werden. Im Rahmen der Ist-Aufnahme sollten nicht ausschließlich fachliche und funktionale Anforderungen betrachtet werden. Mindestens ebenso relevant sind Themenfelder wie:

• Betriebsmodell: Kann ich das System auch zukünftig OnPremise betreiben oder werden neue Funktionen nur noch in der Cloud zur Verfügung gestellt?
• Lizenzkosten: Kaufen oder Mieten? Ist beides möglich? Viele Anbieter gehen konsequent in Richtung Abo/Subscription. Wer noch kaufen kann muss vom Anbieter erfahren, wie die Konditionen aussehen, wenn dieser – aus welchen Gründen auch immer – in das Mietmodell wechselt. Grundregel für Kauf-Bestandskunden: es wird viel teurer, wenn man nicht vorher eine Regelung gefunden hat.
• Personelle Ressourcen: Das größte Problem aller DMS/ECM-Hersteller ist der Mangel an qualifiziertem Personal.
• Berechtigungssteuerung: Eine derjenigen Aspekte, die häufig so komplex vereinbart werden, dass kaum noch pflegbare Berechtigungslösungen entstehen.
• Workflows: Hier muss zwingend im Detail definiert werden, was damit gemeint ist und wie die Workflows erstellt und gepflegt werden.
• Integration mit externen Anwendungen: Für jede externe Anwendung muss im Detail geklärt werden, was unter „Integration“ zu verstehen ist, z. B. die Verknüpfung und Ablage von Eingangs- und Ausgangspost, die Übernahme von Daten von System A nach System B oder das Anstoßen von DMS-/ECM-Funktionen (z. B. „Lege Kunde X mit den folgenden Attributen an“)

Eine Fehlentscheidung bei der Systemauswahl wirkt wie ein Konstruktionsfehler im Fundament: Sie zeigt sich nicht nur kurzfristig, sondern zieht oft hohe Folgekosten, Leistungseinbußen und dauerhafte strukturelle Abhängigkeiten nach sich – Schäden, die später nur mit erheblichem Aufwand oder teilweise gar nicht mehr zu reparieren sind. Hauptgrund: Bedarfe an eine DMS/ECM-Lösung werden nur oberflächlich beschrieben und erlauben es allen Anbietern, eine „positive“ Zusage zu machen, ohne dass ersichtlich wird:

• ob eine Funktion standardmäßig verfügbar ist oder individuell entwickelt werden muss,
• ob sie bewährt und vielfach im Einsatz ist oder erstmals realisiert wird,
• wie funktional umfangreich, im Betrieb stabil oder integriert die Lösung tatsächlich ist.

Tatsächlich benötigt der Kunde eine detaillierte Beschreibung, z.B. über welche Technik die Integration erfolgt (dies berührt IT-Strategie und Sicherheitsaspekte), welche Funktionen sie liefert und wie sie zu bedienen ist (dies berührt das Benutzererlebnis). Dieser Detailgrad kann nur durch mehrere, gezielte Fragestellungen erreicht werden, z.B., ob eine Funktion:

• im Standard-Umfang der angebotenen Lizenzen funktional und preislich enthalten und für den Kunden nutzbar eingerichtet ist. Standard heißt auch, dass diese Komponenten vom Anbieter Release-gepflegt und bei (möglichst vielen) anderen Kunden produktiv im Einsatz ist,
• durch Vornahme von Konfigurationseinstellungen in ihrer Verfügbarkeit, Erscheinungs- oder Funktionsweise verändert werden kann. Konfiguration heißt auch, dass diese „Einstellungen“ auch nach Release-Wechsel noch funktionieren, weil keine neue Funktion individuell programmiert wurde, sondern nur eine im Standard verfügbare Funktion ein/ausgeschaltet und innerhalb der vorhandenen Funktionalität eingerichtet wird,
• projektindividuell, z.B. durch Programmierung, umgesetzt werden muss. Bei solchen Anpassungen ist mit dem Anbieter zu klären, welche Voraussetzungen erfüllt sein müssen, damit diese Individualentwicklung den nächsten Release-Wechsel überlebt, oder aber gar nicht mit dem Produkt abgebildet werden kann.

Wer die Anforderungen im Vorfeld zu grob definiert, wird in der Einführungsphase unweigerlich dafür „bestraft“ – durch z.B. unerwartete Zusatzentwicklungen, Verzögerungen, Funktionslücken und erhöhten Schulungsaufwand

II. Teambildung – fehlendes Branchenwissen – ein unterschätztes Risiko in DMS/ECM-Projekten

In vielen DMS/ECM-Einführungsprojekten zeigt sich ein wiederkehrendes Muster: häufig fehlt das Verständnis für die fachlichen, rechtlichen und organisatorischen Rahmenbedingungen, die für eine erfolgreiche DMS/ECM-Implementierung unverzichtbar sind.

Dazu ein Beispiel aus dem öffentlichen Bereich:

Die öffentliche Verwaltung kennt eine Reihe sehr spezieller funktionaler und regulatorischer Anforderungen mit unmittelbaren Konsequenzen für die DMS/ECM-Lösung, die im privaten Sektor praktisch nicht vorkommen. Das Team sollte mit diesen Anforderungen und dem Bezug zu DMS/ECM vertraut sein. Beispiele sind die Aktenplansystematik (Aktenplan -> Akte – Vorgang – Dokument), die Archivgesetze der Länder, Lösch- und Aufbewahrungskonzepte sowie die Anforderungen an die Scanverarbeitung nach TR-RESISCAN. Hinzu kommen benötigte Kenntnisse über spezifische Fachverfahren im öffentlichen Bereich (vor allem im kommunalen Bereich), die angebunden werden müssen, und über die besonderen Kommunikationswege wie z.B. das Elektronische Gerichts- und Verwaltungspostfach (EGVP) sowie insbesondere das besondere elektronische Behördenpostfach (beBPo).

Fehlt dieses Fachwissen, zieht sich das Projekt in die Länge und wird für alle Beteiligten teurer: langwierige Diskussionen über Grundlagenwissen, Missverständnisse bei der Modellierung von Aktenplänen, Aktenstrukturen, unpassende Konfigurationen oder Integrationsfehler. Entscheidungen müssen revidiert und neu getroffen werden, weil die fachlichen Anforderungen nicht korrekt verstanden wurden. Die Folge sind Projektverzögerungen, Fehlkonfigurationen und teure Nacharbeiten, die sich oft erst dann zeigen, wenn die Korrektur besonders aufwendig ist.

Was hier beispielhaft für die öffentliche Verwaltung genannt wurde, gilt auch für andere Branchen (Banken, Anwaltskanzleien, Wirtschaftsprüfer, Handelsunternehmen, Herstellende Industrie und andere) die sich in ihren Dokumentprozessen und Regularien voneinander unterscheiden mit direkten Auswirkungen auf die Gestaltung dieser Prozesse in einem DMS/ECM-Lösungskonzept.

Darum ist es entscheidend, dass das Projektteam die DMS/ECM-Besonderheiten der Branche kennt. Fehlt das spezielle DMS/ECM-Branchenwissen, kann es sinnvoll sein, auf externes Wissen zurückzugreifen, um die manchmal sehr generischen Anforderungen des Kunden in DMS/ECM-Anforderungen zu übersetzen, die mit den am Markt verfügbaren Produkten auch umsetzbar sind.

III. Teilaufgaben bei der Einführungsplanung

Die Planung der Einführung muss folgende Teilaufgaben beinhalten:

Projektplanung /-steuerung

Ein belastbarer Projektplan bildet die Grundlage jeder DMS/ECM-Einführung. Er umfasst klare Zeitachsen, definierte Meilensteine und eine transparente Zuordnung der benötigten Ressourcen. Fachbereiche, IT, Projektleitung und externe Dienstleister müssen frühzeitig eingebunden werden, um Engpässe zu vermeiden. Ebenso wichtig ist die Priorisierung der Teilprojekte: Welche Organisationseinheiten werden zuerst eingeführt, welche Prozesse folgen in späteren Rollout-Wellen, und welche Abhängigkeiten bestehen zwischen ihnen. Der Anbieter (oder ein externer Berater) kann hier aufgrund seiner Erfahrungen aus anderen Einführungsprojekten praktikable Hinweise und Vorschläge machen und helfen, die richtigen Prioritäten zu setzen.

Technische Systembereitstellung und Installationsplanung

Die Einrichtung einer stabilen technischen DMS/ECM-Infrastruktur, die von der IT des Anwenders dauerhaft betrieben und gepflegt werden kann, ist Voraussetzung für eine kontrollierte Einführung (z.B. Betriebssysteme, Datenbanken, Speichersysteme, Netzwerkinfrastruktur etc.). Dies betrifft Entwicklungs-, Test-, ggf. Schulungssystem und später auch die eigentlich Produktivumgebung und die Transportwerkzeuge. Darauf aufbauend ist eine geordnete Installationsplanung vorzunehmen. Alle im Projekt beschafften Module müssen sowohl im Entwicklungs- bzw. Test- als auch im Produktivsystem installiert sein. Nur so lässt sich sicherstellen, dass die Lösung vollständig ausgeliefert wurde und keine späteren „Überraschungen“ auftreten – etwa fehlende Funktionen, die erst im laufenden Betrieb auffallen.

Darüber hinaus ist ein Preis- und Leistungsabgleich erforderlich. Die gelieferten Leistungen und Preise müssen mit den Angebotspositionen und den Ausschreibungspreisen abgeglichen werden.  Dadurch wird gewährleistet, dass der Auftragnehmer die vertraglich vereinbarte Leistung erbringt und keine verdeckten Zusatzkosten entstehen.

Test und Abnahme

Nach der Installation müssen alle gelieferten Module fachlich und technisch getestet und abgenommen werden. Dazu gehören die Erstellung von Testplänen, die Durchführung definierter Testszenarien sowie die Dokumentation der Ergebnisse. Fehler müssen kategorisiert und dokumentiert werden. Typische Werkzeuge sind Ticket-Systeme zur Fehlerdokumentation/-klassifikation und Fehlerhistorie, sowie zur Nachverfolgung offener Punkte.

Auch muss entschieden werden, was ein P1, P2, P3 Fehler ist (oder was auch immer die Dringlichkeitsziffer ist)? Wer trifft die Entscheidung: Anbieter oder Kunde? Was sind die Konsequenzen je nach Fehler-Kritikalität auf Zahlungen, Fristen, etc.?

Häufig werden auch beim Testen Aspekte der Anwendung entdeckt, die eine erneute Rücksprache mit IT und/oder Fachbereich erfordern. Daher sind erfahrungsgemäß alle im Vorfeld Beteiligten auch während der Testphase weiterhin im Projekt eingebunden, wenn auch mit geringerem Zeitaufwand.

Letztendlich erfolgen die Abnahmen auf Basis klar definierter Abnahmekriterien, werden terminlich abgestimmt, protokolliert und nachvollziehbar dokumentiert.

Schnittstellen und Integrationen

DMS/ECM-Einführungen betreffen immer auch andere IT-Anwendungen und Plattformen, die in irgendeiner Form technisch zu integrieren sind.

Dies betrifft in der Regel sowohl lokale PC-Anwendungen wie E-Mail, Office und Fileshare als auch ERP- und Fachanwendungen, die häufig mit einem hohen Individualisierungsaufwand verbunden sind. Darüber hinaus sind verschiedene Systeme der IT-Infrastruktur zu berücksichtigen. Hierzu zählen insbesondere Verzeichnisdienste zur Berechtigungssteuerung, die Nutzung vorhandener Speichersysteme zur ordnungsgemäßen Ablage sowie Maßnahmen zur Hochverfügbarkeit und Datensicherung. Ebenfalls relevant sind Themen wie Backup-Strategien, Softwareverteilung und weitere infrastrukturelle Anforderungen. Diese sind regelmäßig zu prüfen und zu berücksichtigen.

Berechtigungs- und Rollenmodelle

Ein dauerhaft tragfähiges Berechtigungskonzept ist entscheidend für Sicherheit, Compliance und Akzeptanz. Organisatorische Strukturen wie Rollen und Rechte müssen abgebildet werden. Dazu gehören auch Vertretungsregelungen, temporäre und weitere Sonderberechtigungen und die Pflege all der Berechtigungen im laufenden Betrieb. Darüber hinaus ist zu klären, ob es tiefer gehende Berechtigungen auf Akten-, Dokument- und Vorgangsebene geben muss. Im öffentlichen Bereich ist zudem festzulegen, wer Akten und Vorgänge überhaupt anlegen darf, wer Akten bzw. Vorgänge zur dauerhaften Aufbewahrung (z.d.A.) schreiben darf und wer berechtigt ist, Aussonderungen von Unterlagen vorzunehmen.

Dokumentation

Alle technischen und fachlichen Aspekte der Einführung müssen dokumentiert werden: Systemkonfigurationen, Prozesse, Testprotokolle, Schulungsunterlagen und Abnahmedokumente inkl. der Dokument- oder Kapitelhistorie (wer hat wann welche Version erstellt). Eine gute Dokumentation ist nicht nur Projektergebnis, sondern Grundlage für den späteren Betrieb und Teil der Betriebs- oder Verfahrensdokumentation, die sowieso zu erstellen ist.

Schulung und Einführung in den Organisationseinheiten

Was sich IT-affine Teams ausdenken, muss von anders ausgebildeten Menschen dauerhaft genutzt werden. Projektprobleme entstehen häufig, weil End-User schlecht oder gar nicht zu bestimmten Funktionen geschult wurden oder weil die Bedienkonzepte und Klickwege so verwirrend sind, dass man bei nur gelegentlicher Nutzung vergisst, wie eine Funktion zu nutzen ist. Die Konsequenz ist die Verweigerung der Nutzung durch „alternative“ Wege.

Schulungskonzepte umfassen sowohl die Grundlagen der Standardfunktionen, aber vor allem auch die für den Anwender individuell geschaffenen Anpassungen. Letztere beziehen sich auf praktisch alle Aspekte einer DMS/ECM-Lösung: Aktenstrukturen, Dokumentarten, Workflows, Berechtigungen. In einer Organisation mit z.B. 5 Bereichen kann es daher sein, dass es 5 verschiedene Schulungen gibt, da sich die Lösungen fachlich-funktional erheblich unterscheiden.

Schulungskonzepte müssen daher zielgruppenspezifisch aufgebaut sein und sowohl die Grundlagen als auch Individuallösungen umfassen. Häufig dienen die Testsysteme auch als Schulungssystem, die Remote-Teilnahme ist heute einfach. Wichtig: kein Frontal-Monolog sondern aufbauend auf den Grundlagen konkrete Use-Cases im Test-/Schulungs-System mit interaktiver Beteiligung der Teilnehmer. Handbücher oder textlastige „Bedienhandbücher“ liest niemand mehr. Menschen lernen lieber visuell. Die Lösung sind einfache, schnell zu erstellende How-to-Videos zu den Use-Cases. Bewährt hat sich, Power-User zu benennen, die IT-affin sind und die Anwendung gut kennen. Sie sind die erste Anlaufstelle, wenn man vergessen hat, wie eine bestimmte Funktion verwendet wird. Mit der neuen Technik kommen häufig auch neue Abläufe. Diese organisatorischen Änderungen – die technisch mit der DMS/ECM-Lösung wenig zu tun haben, wie beispielsweise der Umstieg auf „Frühes Scannen“ oder eine neue Form der parallelen Antragsbearbeitung (statt sequenziell in der Papierwelt) oder das Vorkontieren von EN16931-Eingangsrechnungen – müssen natürlich ebenso geschult werden.

Dabei ist entscheidend, dass die Mitarbeitenden verstehen, wie sich ihre zukünftigen Arbeitsprozesse durch den Einsatz des DMS/ECM verändern. Menschen bringen unterschiedliche IT-Affinität mit beim Start einer neuen IT-Lösung. Das Schulungs- und spätere Betreuungskonzept muss alle abholen. Aufgabe des Projektteams ist es, bereits bei der Implementierung und dann bei der Einführung darauf zu achten, dass unnötige Komplexitäten in der Bedienführung vermieden und, wenn unvermeidlich, entsprechend vermittelt werden.

IV. Weiß die linke Hand, was die rechte Hand tut? Wissensbruch zwischen Auswahl- und Umsetzungsphase

In vielen Projekten wechseln nach Vertragsabschluss die Ansprechpartner: Vertrieb und Pre-Sales haben ihren Job erledigt. Für die Umsetzung sind andere Personen (Professional Services u.a.) zuständig.

Ein häufiges Problem entsteht, wenn die neuen Protagonisten die bisherigen Ergebnisse – Fachkonzepte, Workshop-Protokolle, E-Mail-Abstimmungen – nur oberflächlich oder gar nicht kennen. In Workshops werden zudem oft mündlich Vereinbarungen getroffen, die wichtige Inhalte des Lösungskonzepts korrigieren oder erweitern. Wenn diese Änderungen nicht konsequent und für alle verbindlich dokumentiert werden, entsteht das Risiko einer fehlerhaften oder unvollständigen Implementierungsgrundlage. Es ist eine typische Aufgabe in der Arbeitsphase, solche Absprachen, Entscheidungen und Vereinbarungen schriftlich für alle Beteiligten in die mitgeltende Dokumentation aufzunehmen, so dass niemand in 6 Monaten sagen kann, das stehe so nicht im ursprünglichen Lösungskonzept. Hierbei wird in der Regel dokumentiert:

• Wer hat wann welche Zusage gemacht?
• Welche Teamentscheidung wurde getroffen?
• Welche Anforderungen aus Lösungskonzept oder Pflichtenheft gelten nicht mehr oder nur noch in geänderter Form?

In der Regel schreiben wir diese Änderungen direkt in das entsprechende Kapitel des Lösungskonzeptes. Mit dem Anbieter ist vereinbart, dass die Änderungen – wenn sie einvernehmlich sind – das gültige, bindende Lösungskonzept sind. Hat der Anbieter selbst ein Dokument als Projektgrundlage (eigenes Pflichtenheft oder dergleichen), gilt die Vereinbarung, dass beide Dokumente gelten: das aktuelle, um Änderungen ergänzte Lösungskonzept und die Dokumentation des Anbieters. Hat dieser den aktuellen Stand nicht in sein Dokument aufgenommen (was leider häufig vorkommt), gilt für die geänderten Aspekte das aktuelle Lösungskonzept des Kunden.

V: Projekt-Monitoring

Wir kennen keine DMS/ECM-Projekte mit unbegrenztem Budget. Spätesten mit Beauftragung des Anbieters sollte klar sein, welche Arbeitspakete mit welchen technischen und personellen Kosten und Aufwendungen verbunden sind.

Der DMS/ECM-Anwender muss sowohl die externen als auch die eigenen Aufwendungen im Blick behalten. In Verbindung mit den oben erläuterten Projektverfahren und Werkzeugen wird mit dem Anbieter eine Vereinbarung getroffen, wie ein Ressourcen-Monitoring für die zu erbringenden Dienstleistungen erfolgt und wie mit Nachforderungen umzugehen ist.

Zum Projekt-Monitoring gehören Termin- und Meilensteinplanung und personelle Zuordnung zu den verschiedenen Arbeitspaketen. Abhängigkeiten müssen kontinuierlich geprüft und mit dem Projektplan abgeglichen werden. Verzögerungen oder Abweichungen werden so früh erkannt und können rechtzeitig korrigiert werden.

Auch sollten Prozesse bei Unstimmigkeiten und Eskalationsverfahren definiert werden, denn häufig möchte die Leitungsebene mit Hinweisen auf Engpässe oder Verzögerungen über den Projektfortschritt informiert werden.

Fazit

Nach der ersten Phase der Anbieter- und Systementscheidung geht die Arbeit erst los. Die nachgelagerte Phase 2, Implementierung und Einführung,  sollte mit der gleichen Aufmerksamkeit für Details geplant und durchgeführt werden, wie für die vorgelagerte Phase.

Wir haben in o.a. Text typische Aufgabenstellungen dieser nachgelagerten Phase benannt und aufgezeigt, wie man die damit verbundenen Stolpersteine umgehen kann. Dasjenige Team, das in der vorangegangenen Phase in einer aufwendigen Lernkurve die Lösung konzipiert und das passende System gefunden hat, sollte auch in inhaltlich verantwortlicher Funktion in der nachgelagerten Phase im Projekt dabei sein, weil das nun vorhandene spezielle DMS/ECM-Know-How unverzichtbar bei Implementierung und Einführung ist. Umso besser, wenn man auf vorhandene Werkzeuge und praxiserprobte Verfahren aus vergleichbaren Einführungsprojekten zurückgreifen kann.