Interview mit Bernhard Zöller zu Archivierungsfragen

Aufgrund der Corona-Pandemie und dem damit verbundenen Arbeiten im Home-Office mussten viele Unternehmen in den letzten beiden Jahren relativ schnell Lösungen zur Digitalisierung wie Collaboration-Lösungen einführen. Inwieweit wurden dabei aus Ihrer Sicht die rechtskonforme Aufbewahrung von digitalen Dokumenten berücksichtigt?

Zöller: Ich denke, die meisten Anwender werden sicherlich keine Dokumente in »OneDrive« beziehungsweise »MS Teams« oder vergleichbaren Collaboration-Lösungen aufbewahren, wenn die Dokumente »revisionssicher« aufzubewahren sind. Es spricht nichts dagegen solche Lösungen für die Zusammenarbeit zu nutzen zum Beispiel für die Rechnungsprüfung oder die Vertragserstellung, auch wenn die Aktenführung oder die eigentliche Aufbewahrung in einem DMS/Archiv stattfindet. Meine Antwort wäre daher: aus unserer Kenntnis als ECM-Beratungsunternehmen werden bei den Digitalisierungsprojekten – egal ob Collaboration, DMS, ECM – regulatorische Rahmenbedingungen berücksichtigt. Die Produktangebote geben das ja schon lange her: ordnungsgemäße Aufbewahrung ist bereits seit Jahren für jeden Geldbeutel verfügbar. Die Pandemie hat hier sicher die Dringlichkeit verschärft. Kommt es aufgrund der Eile zu nicht-konformen Lösungen? Denkbar, aber da sehe ich keinen signifikanten Unterschied zu den Vor-Corona-Zeiten. Auch da gab es immer mal Lösungen, die zum Startzeitpunkt noch nicht in allen Facetten final waren. In solchen Fällen findet sich aber immer ein Ausweg: Papier noch drei Monate länger aufbewahren, fehlende Verfahrensdokus nachreichen etc.

Ist es aber nicht generell empfehlenswert, Collaboration-Lösungen mit DMS- und ECM-Systemen zu koppeln?

Zöller: Es wäre vielleicht dann empfehlenswert, wenn beispielsweise Dokumente einer DMS-/ECM-Lösung in einer Collaboration-Lösung per Co-Editing gleichzeitig bearbeitet werden sollen. Dieses Co-Editing geht in Google Docs, OneDrive/Sharepoint etc. aber nicht originär in den DMS-Lösungen. Also checkt man Dokumente aus dem DMS in eine Collaboration-Lösung aus und checkt sie nach dem Co-Editing wieder in das DMS ein. Aber ehrlich gesagt: sehr viel mehr Anwendungsfälle kenne ich nicht, wo ich eine »technische« Kopplung haben möchte. Beispiel: Ich möchte mich in MS Teams oder Zoom über ein Dokument unterhalten, welches im DMS liegt. Dazu benötige ich keinerlei technische Kopplung. Dokument in DMS-Anwendung öffnen, Bildschirm in Zoom-Anwendung teilen, fertig. Und an dieser Stelle noch eine Anmerkung zu Co-Editing: der Nutzen dieser Funktion wird nicht von jedem Unternehmen gesehen. Möchte ich wirklich, dass eine andere Person die Gliederung gerade neu erstellt, während ich gerade im Kapitel X Text bearbeite? Sollen zwei Personen wirklich gleichzeitig auf der gleichen Seite tippen? Wir haben intern und mit vielen Kunden diskutiert, ob Co-Editing nützlich ist und es blieben nur wenige Anwendungsfälle übrig, wo Bildschirm-Sharing nicht ausreichend war. Aber ja: wenn das Autorenteam verteilt ist und jeder Mit-Autor situativ eigenen Text beitragen möchte, ist Co-Editing eine sehr komfortable Funktion.

Welche weiteren Lösungen sollte man vor dem Hintergrund der rechtskonformen Aufbewahrung außerdem mit DMS- und ECM-Lösungen koppeln?

Zöller: Seit vielen Jahren Best Practice sind Verknüpfungsschnittstellen zwischen ERP- und Fachanwendungen, die selbst keine ordnungsgemäße Aufbewahrungsfunktion und ein Archiv/DMS mit ebendiesen Archivfunktionen bieten. Worauf man hier achten sollte, ist die Release-Fähigkeit dieser Schnittstellen, damit die dauerhafte Betriebsfähigkeit – und somit auch Ordnungsmäßigkeit – auch nach Release-Wechsel der Fachanwendung oder der DMS-Lösung sichergestellt ist. Manchmal geht die Integration aber über diese einfache Archivverknüpfung hinaus. Wenn in der Fachanwendung eine Aktensicht fehlt, kann eine DMS-Lösung hier ergänzen. Wenn in der ERP- oder Fachanwendung keine Arbeitsliste (Workflow-Postkorb) für Frühes-Scan-Szenarien verfügbar ist, kann ein DMS diese Lücke schließen. Fehlen in der Fachanwendung Workflow-Komponenten für die Prozessmodellierung von Dokumenten-Prozessen (häufiges Beispiel: Rechnungsworkflow) kann man diese Dokumenten-Prozesse mit einem DMS abbilden. Das hat jetzt aber weniger mit der Ausgangsfrage der rechtskonformen Aufbewahrung zu tun, ist aber mindestens mittelbar relevant, weil die Prüfung der Ordnungsmäßigkeit natürlich den Gesamtprozess betrachtet und nicht nur die geschützte Aufbewahrung.

Inwieweit ist den Unternehmensverantwortlichen die Notwendigkeit entsprechender Integrationen bewusst?

Zöller: Ich kenne eigentlich keine DMS/ECM-Projekte, in denen die Forderung nach Integration mit einer ERP- oder Fachanwendung nicht von Beginn an Teil des Anforderungskataloges war. Es gibt zwar immer sehr unterschiedliche Einschätzungen zum technisch-funktionalen Umfang und den Kosten, aber die Notwendigkeit ist aus meiner Wahrnehmung immer unstrittig.

Worin bestehen die meisten Fehleinschätzungen bezüglich der geltenden Rechtsgrundlagen zur Archivierung wie GoBD?

Zöller: Die Vorläufer-Dokumente der GoBD, die GoBS, sind ja bereits am 7. November 1995 veröffentlicht worden, die erste Version der GDPDU im Sommer 2001 und trotzdem gibt es immer noch viele Mythen und Legenden zu dem Thema: Man müsse WORM-Speicher verwenden, man müsse in PDF/A archivieren, man müsse jedes geschäftlich relevant Dokument revisionssicher archivieren, man dürfe keine MS Office Formate archivieren, TIFF sei Pflicht, Journal-Archivierung bei E-Mail erfülle die GoBD-Anforderungen, man müsse nach zehn Jahren löschen, jedes Dokument mit Unterschrift müsse kryptografisch signiert aufbewahrt werden etc. Die Liste dieser Falschaussagen ist zu lang, um sie hier einzeln zu erläutern. Wir sind immer wieder erstaunt, wieso sich diese krassen Fehleinschätzungen nicht ausrotten lassen, die Recherche der Primärquellen ist ja nicht schwierig und es gibt kostenlose Downloads von Stellungnahmen renommierter Fachleute aus Steuerberatungs- und Wirtschaftsprüfungsgesellschaften.

Und wie sieht es mit dem Verständnis im Hinblick auf die DSGVO aus?

Zöller: Obwohl die DSGVO spätestens seit Mai 2018 nach Auslauf der Übergangsfristen gilt, besteht heute noch viel Unklarheit. Weitgehende Einigkeit besteht darin, dass eine DMS-/ECM-Lösung ein exzellentes Werkzeug ist, um zentrale Anforderungen der DSGVO zu erfüllen: Sowohl Artikel 17 – Recht auf Vergessenwerden – als auch Artikel 20 – Recht auf Datenübertragbarkeit – sind in den chaotischen Ablagen in Gruppenlaufwerken und Mailsystemen kaum zu erfüllen, weil die Attribute fehlen, um personenbezogene Unterlagen herauszufischen und – nach Prüfung gegen überwiegende Schutzfristen wie beispielsweise gesetzliche Aufbewahrungspflichten – einem geordneten Löschverfahren zuzuführen. Diese Funktionen sind bei einer DMS-/ECM-Lösung schon immer Kernaufgaben gewesen. Worin aber eher weniger Einigkeit besteht, ist die Interpretation der DSGVO selbst zu zahlreichen Fragen, die in fast jedem DMS-/ECM-Projekt diskutiert werden: Dürfen immer noch WORM-Speicher zum Einsatz kommen, die ein selektives Löschen gar nicht zulassen – wobei ein früher praktiziertes »logisches Löschen« nicht mehr zulässig ist? Wenn nicht: müssen dann laufende Altlösungen migriert werden? Sind Mail-Journal-Archive noch zulässig, die gar keine Möglichkeit vorsehen, einen Personenbezug aus den Header-Daten der E-Mail herzustellen, um zielgenau finden und löschen zu können? Was ist mit Logfiles und Reports, aus denen man einzelne Datensätze gar nicht löschen oder anonymisieren kann? Sind Jahres- und Monatsbackups noch zulässig, wenn andererseits ein unverzügliches Löschen gefordert wird und nicht erst, wenn mal wieder ein Fullbackup ansteht? In beinahe jeder Diskussion – auch mit Juristen aus dem privaten Sektor und der öffentlichen Hand – wird immer wieder festgestellt, dass solche Fragen bisher nicht gelöst sind und in den meisten Rechts-Kommentaren auch nicht angesprochen werden.

Was sind die größten Herausforderungen bei der Integration von Drittprodukten in bestehende DMS- und ECM-Lösungen?

Zöller: Wir sind es im täglichen Leben gewohnt, dass die einzelnen Komponenten der Produkte, die wir nutzen (Auto, SmartPhone) von sehr vielen unterschiedlichen Herstellern kommen. Unser Vertragspartner ist aber nur ein Unternehmen, mit dem wir bei Problemen kommunizieren würden. Das ist bei DMS-/ECM-Lösungen in der Regel ebenso, wenn die Gesamtlösung von einem einzigen Unternehmen (dem DMS-Anbieter) gekauft wird. Es ist nicht nur akzeptabel, sondern auch zum großen Nutzen der Anwender, dass ein DMS-Hersteller nicht auf die Idee kommt, bei allen Zuliefer-Komponenten in Wettbewerb mit den globalen Lieferanten treten zu können. Daher sind die relationale und Volltextdatenbank, Viewing-Komponenten im DMS-Client, die Bibliotheken für die Bedienelemente meistens von Dritten, die in die DMS-Lösung integriert werden. Daneben gibt es Komponenten, wie beispielsweise Scan-Software, Workflow-Engines, Archivschnittstellen zu Fremdanwendungen die manchmal vom DMS-Hersteller kommen, manchmal aber auch von Dritten bezogen werden. Und es gibt natürlich alle jene Fälle, in denen die Lösung in eine DMS-fremde Anwendung auf dem PC – beispielsweise MS Office – oder einer externen IT-Anwendung – ERP oder Fachanwendung – integriert ist. In all diesen Fällen muss der Kunde darauf achten, wie »release-fähig« die Gesamtlösung ist. Was passiert, wenn eine der Parteien in diesem Zusammenspiel ihre Komponente ändert? Funktioniert die Lösung dann noch? Wie schnell reagiert der Hersteller, wenn sich eine der Komponenten ändert. Wie lange muss der Anwender beispielsweise mit dem Upgrade seiner IT-Ausstattung auf die neue Version vom SQL-Server oder von MS Office warten, bis sichergestellt ist, dass die Gesamtlösung läuft und offiziell vom DMS-Support unterstützt wird? Wie lange nach Verfügbarkeit eines neuen Releases wird die »alte« Lösung noch supported, weil der Anwender aus bestimmten Gründen nicht sofort auf die neuen Komponenten upgraden möchte? Im Normalfall werden diese Release-Abhängigkeiten besprochen, sodass Planungssicherheit besteht.