Records Management. Integration von Prozessführung und Dossierführung
Gastbeitrag von Dr. Peter M. Toebak,
Geschäftsführer von Toebak DM+A GmbH, Senior Business Consultant bei Sispace AG und Modulleiter für Records Management an der Uni in Bern (Masterausbildung AIS)
E-Mail: toebak@toebak.ch
Webseite: www.toebak.ch
Herausforderungen und Erfolgsfaktoren Integration von Records Management mit der Prozessführung und der Terminüberwachung ist von kritischer Bedeutung. Gelingt diese Herausforderung, steht der wirtschaftlichen, revisions- und rechtssicheren Informationsbewirtschaftung in Unternehmungen, Verwaltungen und anderen Organisationen nichts mehr im Wege. Es darf in diesem Jubiläumsheft gesagt werden: Ulrich Kampffmeyer spielt in Deutschland und in Europa eine wichtige Rolle für die Verbreitung und Verbesserung des Records Management – nicht selten gegen den Strom. Die Zeichen stehen trotz allem günstig. Philip Bantin meint dazu: „Consequently, I believe we are entering a decade when more emphasis will be placed on developing better recordkeeping systems. I think there is a strong sense that society has lost control of its information resource, and that we need to step back and rethink how we manage it”. Michael Dertouzos sieht gerade im Office-Bereich hervorragende Möglichkeiten. Nach einer Übersicht über die weltweite Wertschöpfung zieht er den Schluss: „But we should be able to raise human productivity by perhaps 300 percent during the 21st century. This gain will appear primarily in that broad category of human activity we call office work” . Erst mit Records Management ist dieser Quantensprung der Informationsgesellschaft möglich.
Records Management gilt als Fundament für das betriebliche Informationsmanagement, inklusive des Dokumenten- und Wissensmanagements. Es gibt dem Qualitäts- und Compliance Management Substanz. Die Datensysteme in einem Betrieb, seien es Office-, ERP-, Workflow-Systeme, Workgrouping oder Fach-anwendungen, produzieren und bearbeiten Daten- und Unterlagen-Records. Sie müssen zeitgerecht entlastet werden. Können Verwaltungen, Unternehmungen und andere Organisationen ihre Prozesse – nicht nur einzelne Prozessschritte – authentisch, verlässlich, vollständig, integer, benutzbar, interpretierbar, sicher, haltbar und vertrauenswürdig dokumentieren, und dies auf effiziente Weise? Sie können es und müssen es, aber die Vorinvestition ist logisch-organisatorisch, technisch und juristisch anspruchsvoll. Records Management ist mit dem Prozessmanagement vollends zu integrieren, die vorherrschende Datenentropie muss beseitigt werden.
Halbwissen und handgestricktes, „pragmatisches“ Vorgehen reichen nicht aus. Hier liegt gar eine Ursache mancher Fehlstarts im Bereich des betrieblichen Informationsmanagements. „Design deficiences“ rächen sich unausweichlich in Form von „operation deficiences“. Schnellschüsse sind Kurzschlüsse. Ich werde in diesem Artikel auf zwei Elemente der Integration des Records Management eingehen, auf die Erfassung der Daten und Dokumente mit Records-Status und auf das mögliche Zusammenspiel von Produktivsystemen und Records-Management-System (RMS). Andere wichtige Elemente, wie die Prozess- und Dossiergestaltung, das Basisdatenmodell des Records Management und die grundlegende Datenarchitektur, bleiben hier ausser Betracht. Für weitere Ausführungen verweise ich auf ausführlichere Behandlungen.
Datenerfassung, Versionierung und Fixation
Die Datenerfassung ist ein “moment of risk” in der Terminologie von David Bearman. Andere betreffen die Dossierbildung, den Transfer und die Konversion/Migration. Die Datenerfassung muss sicher sein: „Records cannot [should not] be lost or changed during the capture process“, so formuliert Bantin es. Drei Punkte springen hier aus Sicht des Records Management ins Auge, wobei das Risikoelement teilweise logisch, teilweise technisch erscheint und auch die Perspektive des kleinen und grossen Lebenszyklus mitmischt:
| | | |
| | · | Wie geht man mit dem Versionsmanagement der Dokumente um? |
| | · | Wie werden dynamische Daten mit Records-Status erfasst und verfestigt? |
| | · | Und was heisst die Technik der Deduplizierung der Informationsobjekte für das Records Management und Compliance Management? |
Der kleine Lebenszyklus bezieht sich auf Transition Records bzw. auf Unterlagen-Records vor Dossierabschluss/-abbruch; er ist im ersten Fall deckungsgleich mit dem Versionsmanagement. Die administrativ-operative Dynamik (Buchführung) steht im Vordergrund. Der grosse Lebenszyklus betrifft die Unterlagen-Records nach Abschluss bzw. Abbruch des Dossiers. Die dokumentarisch-archivische Statik (Aufbewahrung) steht im Zentrum. Die Ablage, Verwaltung, Kassation und Aufbewahrung erfolgt nach einem prospektiv ausgerichteten Aufbewahrungs-, Verjährungs- und Vernichtungsschema.
Ich fange mit der ersten Frage an. Zum Versionsmanagement eignet sich das DMS oder die Fachanwendung mit DM-Funktionalitäten. Es bewegt sich auf „item level“ innerhalb des kleinen Lebenszyklus der Unterlagen-Records. Notwendig ist die Integration mit der Office-Welt, mit jeder Form von Workgrouping, der Workflow, dem ERP und den Fachanwendungen. Ein RMS stellt Funktionalitäten auf „above item level“ zur Verfügung und richtet sich primär auf den grossen Lebenszyklus der Informationsobjekte mit Geschäfts- und Rechtsrelevanz aus. Wesentliche Aktivitäten sind hierbei Dossierbildung, Klassifikation, Zugriffskontrolle und Aufbewahrungsplanung. Der kleine Lebenszyklus auf Dokumentebene ist für das Records Management genauso unerlässlich. Dafür setzt es jedoch auf einem DMS auf. DMS werden öfters auch für direkte „Archivierung“ eingesetzt. Sie unterliegen dabei Fachanwendungen oder ERP-Systemen und fungieren als Applikationen zur revisionssicheren Ablage auf „item level“. Für homogene Geschäftsbereiche mit Massen-Output kann es ausreichen, obwohl ein integriertes Informationsmanagement der Daten- und Unterlagen-Records über die Gesamtorganisation hinweg fehlt. Die Kombination von einem DMS und RMS hat als EDRMS immer den Vorzug.
Schauen wir uns das Versionsmanagement logisch genauer an. Zwei Relationen sind in einem betrieblichen Datensystem essentiell, sowohl aus Sicht der Prozessführung als aus Sicht des Dokumenten- und Records Management: Ablauf und Herkunft. Chris Hurley spricht von „sequencing“ und „provenance“, von „succession“ und „belonging“ bzw. von „succession link“ und „ownership link“. Ich gehe nur auf den Ablauf ein. Der Ablauf bestimmt die Chronologie und die übersichtliche Darstellung eines Prozesses. Er erfolgt sequentiell und/oder parallel. Systemisch und ablauforganisatorisch heisst dies: Operationen, Transaktionen, Prozessschritte wechseln einander sukzessive, manchmal auch synchron ab. Sie bilden die Basisobjekte oder Grundbausteine eines Prozesses. Das Versionsmanagement der Dokumente muss sich danach vollständig richten. Es beschränkt sich genau auf jene kleinsten Prozessentitäten. Übersteigt das Dokument ein solches Basiselement, ist schematisch nicht mehr von einer Version des gleichen Dokuments, sondern von einem weiteren Entwicklungsstadium, also von einem folgenden Dokument mit allenfalls eigenen Versionen die Rede. Die Chronologie bzw. die rechtssichere Übersicht des Prozesses würde sonst durchbrochen und intransparent.
Abb. 1: Versionen, Entwicklungsstadien und eigenständige Dokumente
Das Versionsmanagement eines Dokuments darf nicht „missbraucht“ werden, um Prozesse abzubilden. Dokumente befinden sich auf „item level“, der Prozess jedoch auf „above item level“. Ein Dokument bezieht sich auf einen Prozessschritt, nicht auf mehrere. Der MoReq2-Standard besagt es wie folgt: „(...) version control [is] to be used where a history of document development is required. In areas where this history is not required, the number of versions stored – and hence the storage required – can be reduced“. Wenn ein Dokument in mehreren Prozessschritten eine Rolle spielt, ist (wie gesagt) nicht von Versionen, sondern von Entwicklungsstadien die Rede. Zwar werden diese nicht immer geschäfts- oder rechtsrelevant sein, was grundsätzlich vom Gewicht des Geschäfts, des Projekts, des Falls, der Geschäftshandlung oder der Geschäftsbeziehung abhängt. Sind sie es wohl, werden neue Dokumente abgelegt, nicht Versionen bereits bestehender. Bei sauberer Prozessmodellierung erhalten mehrere Versionen desselben Dokuments höchst selten Records-Status. Obwohl der Unterschied zwischen Version und Entwicklungsstadium sowie zwischen Prozessschritt und Sequenz von Prozessschritten klar ist, bleibt der Ermessensentscheid bezüglich Erfassung letztlich dem Sachbearbeitenden (logisch) oder dem Prozessmanager und Records Manager (systemisch) überlassen.
Über die Granularität der Prozessgestaltung kann gestritten werden. Bereits T.H. Davenpoort sprach über „process definition is more art than science“. Die Alltagspraxis und das Mengengerüst an Daten und Dokumenten sind jedoch richtige Indikatoren. Henry Gladney hat recht, wenn er schreibt: „Only producers have the authority and insight to estimate when users will appreciate that a new document is sufficiently closely related to a prior document to do this (deciding, whether to use a new Digital Resource Identifier or the DRI of some existing Trustworthy Digital Object); machines cannot do it without human guidance”. Er bezieht sich auf Publikationen, also auf betriebsexterne Informationen. Bei Workflow-Management und detaillierter Prozessdefinition ist die Sache anders, wenn beim Design Schemen und Regeln hinterlegt werden, welche die Sachbearbeitenden lenken. Der Autor hat übrigens unrecht, wo er ferner meint: „If each TDO embeds all its prior versions, the consumer will quickly be able to identify the specific changes made by each producer“. Dies bleibt sogar beim besten Versionsmanagement, bei Einbettung aller Dokumentversionen im TDO oder bei „shared resource identifiers“ logisch und organisatorisch schwierig und aufwendig.
Abb. 2: Zusammenspiel von Daten-Records und Unterlagen-Records
Nun zur zweiten Frage: Wie erfasst man strukturierte Daten mit Records-Status? Bantin sieht hier eine grosse Herausforderungen für Records Manager (und Archivare). Wie können Fachanwendungen und Informationssysteme in das Records Management eingebunden werden, wo „database views, dynamic and virtual documents, complex software linkages, hypermedia documents, and multilayered geographical information systems“ grundsätzlich nicht für Erstarrung konstitutiver, informativer, kommunikativer, organisatorischer Momente sorgen? Es geht um nicht-redundant ausgelegte, aktuelle Datensysteme mit „discrete data elements organized in relational tables“. Die Daten liegen physisch, „discrete and identifiable“, in den Zellen (Datenfelder) einer Matrix von Reihen und Spalten (Datentabelle) vor. Die Feldinhalte werden bedingt historisiert. Die „Dokumente“, die situativ entstehen als „logically constructed entities, [provisionally] created by combining and reusing data“, materialisieren und sedimentieren sich nicht. Das Datensystem bildet zwar die Geschäftsrealität ab: „Database transactions reflect real-world transactions like registering for a course or buying a product“. Es ist jedoch vor allem ein Basisinformationssystem für Entscheide und Handlungen im Arbeitsalltag.
Erstellte Dokumente in Fachanwendung oder ERP-System mit Records-Status müssen genauso „discrete and identifiable“ sein. Sie umfassen Suchergebnisse, Hitlisten und Reports strukturierter Daten und bezeichnen Momentaufnahmen. (Die Grafik zeigt nur eine Datentabelle, in der Praxis geht es um viele kombinierte). Werden Dokumente mit Records-Status provisorisch ausgegeben, lassen sie als Unterlagen-Records keine Spuren von Entscheidungsfindung oder Geschäftshandlung nach. Bleiben nur die „reinen Daten“ in Fachanwendungen und ERP-Systemen gespeichert, braucht es für die nachträgliche richtige und gültige Dokumentausgabe „on the fly“ auch die Erhaltung des einschlägigen Original-Template oder -Formulars. Sind die Daten akribisch historisiert und ist die Templates-Verwaltung nachvollziehbar, lässt sich diese Lösung während des kleinen Lebenszyklus (Dynamik) verteidigen. Ganz „unproblematisch“ erachte ich sie nicht. Bei mittelfristiger oder langfristiger Aufbewahrung, also während des langen Lebenszyklus (Statik), erhöht sich die technische Komplexität der Lösung nämlich schnell. Einscannen des Massenoutputs oder Coldierung der Ausgangspost usw. erfordert ein weniger „high tech“-Vorgehen und macht Unternehmungen, Verwaltungen und andere Organisationen auf die Dauer unabhängiger der (zeitgebundenen) Software-Produkte.
Nun die dritte Frage: Was bedeutet Deduplizierung von Informationsobjekten für das Records Management und Compliance Management? Dokumente umfassen auch unstrukturierte Daten: Berichte, Briefe, E-Mails, Protokolle, Verträge und Weisungen; Vermischungen von strukturierten und unstrukturierten Daten präsentieren sich z.B. bei Rechnungen, Mahnungen und Lieferscheinen. Records sind im Gegensatz zu Dokumenten statisch. Da ist noch ein wichtiger Unterschied, der Ähnlichkeiten mit dem Zusammenspiel zwischen Daten- und Unterlagen-Records aufweist. Die meisten Dokumente kommen im Rahmen der Kommunikation, Koordination und Kooperation physisch und logisch vielfach vor. Bis zu zehn oder noch mehr Kopien sind eher Regel als Ausnahme. Bei den Unterlagen-Records ist die Situation anders. Sie sind in jedem Fall einmalig, auch wenn sie in mehreren Geschäftskontexten (wieder) benutzt werden. Sie können als Objekt mit Informationswert zwar redundant sein (Inhalt), sie können es sogar formal, äusserlich sein (Form), bei sauberer Dossier- und Serienbildung sind sie es als Objekt mit Evidenz- und Beweiswert nie (Kontext) ebundenheit der Records – Prozesse generieren, strukturieren Daten- und Unterlagen-Records – vermeidet, dass die „Mehrfachablage“ von Dokumenten mit Records-Status in einem gut geführten RMS häufig vorkommen muss.
Gegen Single-Instance-Ablagen ist vor der Erfassung der Informationsobjekte als Unterlagen-Records nichts einzuwenden. Deduplizierung räumt mechanisch ohne Informationsverlust, während des kleinen Lebenszyklus, kurzfristig auf. Während des langen Lebenszyklus sollten die Masterdossiers jedoch vollständig sein. Eine allzu grosse Abhängigkeit von komplexen Verknüpfungsgeflechten führt auch hier zu unnötigen und unrichtigen Risiken. Datenobjekte fallen in den Produktivsystemen an (Fachanwendungen, ERP, Office-Systeme), sie werden bei Records-Status in das Masterdossier (RMS) abgelegt. Physische Redundanz ist noch keine logische Redundanz. Der Begriff „Original“ ist im elektronischen Umfeld nicht verloren gegangen! Über den genauen Moment der Ablage kann diskutiert werden: Früherfassung im Masterdossier (das Beste aus Sicht des Records Management)? Erst bei Prozess-/Dossierabschluss? Noch später, z.B. bei Anbietung/Ablieferung an das Verwaltungs-, Unternehmungs- oder Organisationsarchiv?
Zwei Ziele stehen hierbei immer im Vordergrund: Der Prozess muss über das Masterdossier lückenlos dokumentiert werden (Revisions-, Rechtssicherheit) und die frühzeitige Auslagerung von Datenobjekten aus den Produktivsystemen (Vieraugen-Prinzip, Dateneffizienz und Datensicherheit) sollte die einfache Wiederverwertung der Dokumente nicht beeinträchtigen.
Integration von Funktionalitäten
Ein DMS/ECM (besser EDRMS) unterstützt Desktop- und Web-Client-Anwendungen. Auch werden EDRMS-Funktionalitäten ergänzend in Fachanwendungen, Office- oder E-Mail-Systeme eingebunden. Sie zeigen sich durch erweiterte Menüleisten, Kontextmenüs, Datenmasken oder durch ein zusätzliches logisches Laufwerk. Die Erfassungs- und Archivierungsmöglichkeiten der Spezialsysteme nehmen zu, die Anwender behalten aber ihre vertraute Arbeitsoberfläche. Die Daten- und Unterlagen-Records, die auf Prozessebene beisammen gehören, bleiben verbunden („processual bond“ nach Analogie von „archival bond“). Dies kann mittels Reporting (MIS-Kennzahlen und Datensichten werden generiert, bei Bedarf ausgegeben und in das Dossier als Unterlage aufgenommen) oder durch parallele Ablage von Stammdaten in den Datenbanken und Fachanwendungen als Metadaten im EDRMS erfolgen. Eine Personalnummer in einem PIS oder eine Kundennummer in einem CRM- oder ERP-System lässt sich z.B. mit den einschlägigen Adressdaten als Personal- oder Kundendossiernummer und -beschrieb im EDRMS verwenden.
Abb. 3: Integration von EDRMS mit Fachanwendung (Business System)
Die Integration kann weiter gehen. Das Dossier (physisch, statisch) befindet sich im EDRMS, es wird in die Fachanwendung oder das ERP-System eingeblendet. Oder aus dem Dossier heraus lassen sich aktuelle Transaktionen im ERP-System durchführen. In allen Fällen gilt, dass Links bei Geschäfts- und Rechtsrelevanz expliziert werden und dass geschäftsrelevante Reports physisch vorhanden bleiben. Sie müssen nicht nur nach dem EDRMS, sondern unter Umständen auch nach anderen Datenhaltungssystemen, z.B. in einer späteren Phase des Lebenszyklus nach einem Archivverwaltungssystem (AVS), exportiert werden können. Einfache Verknüpfungen, Hitlisten als reine Suchergebnisse und Datenviews genügen (wie virtuelle, dynamische Dossiers) vielleicht dem Informationsmanagement, dem Records Management tun sie es nicht. Diese Tatsache hat nicht jeder bereits verstanden
Schauen wir die Funktionalitäten eines RMS genauer an, ist einerseits die Entwicklung ersichtlich, dass Fachanwendungen und ERP-Systeme Basisfunktionalitäten des Records Management – insbesondere die Klassifikation und Dossierbildung – abdecken (wollen) eschäftslogiken. Dedizierte RMS und AVS haben den Vorzug. Sie verlängern nicht eine Silobildung bis in den grossen Lebenszyklus und lassen auch die getrennte Verantwortung zwischen dem Records-Produzent und dem Records-Verwalter frühzeitig, stringent und ersichtlich organisieren. Gerade die formale und materielle Trennung zwischen Dynamik (Prozessführung, Buchführung, kurzer Lebenszyklus) und Statik (Dossierführung, Aufbewahrung, grosser Lebenszyklus) macht aus rechtlichen Gründen (Datenschutz, Handelsrecht, Qualität der Produktdokumentation) Sinn.
Schlussfolgerung
Die Datenerfassung hat Scharnierfunktion zwischen Prozess und Dossier, zwischen Dynamik (Prozessführung) und Statik (Dossierführung). Sie soll so automatisch, authentisch und verlässlich wie möglich vorgehen. Damit dies erreicht werden kann, muss technisch und logisch-organisatorisch einiges geleistet werden. Ich bin aus Sicht des Records Management drei Frage nachgegangen bezüglich Versionsmanagement der Dokumente, Erfassung von strukturierten Daten mit Records-Status und Deduplizierung. Informatiker (die nur die Dynamik sehen, nicht die Statik, und bei Redundanz fast panisch werden) und Juristen (die sich auf „item level“ bewegen und die Kraft des Dossiers und der Archivtektonik auf „above item level“ übersehen) sind gerade bei solchen Fragen schlechte Berater. Am Records Management führt kein Weg vorbei, es bringt grossen Gewinn. Halbwissen und Widerstände gegen die Modernisierung in Verwaltungen, Unternehmungen und anderen Organisationen gehen manchmal Hand in Hand. Records Management bringt Qualität (Effektivität) und Quantität (Effizienz). Ohne Records Management gibt es kein Compliance Management. Dokumentenmanagement und Wissensmanagement reichen alleine nie aus. Records Management muss in die Geschäftsprozesse vollends integriert werden. Bei richtiger Datenqualität fällt es dann arbeitsmässig nicht mehr in das Gewicht.
Metadata