Referenzarchitektur elektronische Verwaltungsarbeit

Transkript

1 Referenzarchitektur elektronische Verwaltungsarbeit RA 11/2013

2

3 Impressum Herausgeber Die Beauftragte der Bundesregierung für Informationstechnik Ansprechpartner Referat IT2 Alt-Moabit 101 D Berlin It2@bmi.bund.de Stand November 2013 Bildnachweis istockphoto, Shutterstock Nachdruck, auch auszugsweise, ist genehmigungspflichtig.

4 Zusammenfassung Das Organisationskonzept elektronische Verwaltungsarbeit hat im letzten Jahr das Gestaltungsfeld der elektronischen Schriftgutverwaltung in der Bundesverwaltung wieder in Bewegung gebracht. Das vorliegende Konzept nimmt diesen Impuls auf und betrachtet aus der technischen Perspektive die Auswirkungen auf die Architektur von Dokumentenmanagement- und Vorgangsbearbeitungssystemen in der Bundesverwaltung. Ziel ist es, den Behörden und Einrichtungen Leitlinien an die Hand zu geben, die teure Fehlentwicklungen verhindern sollen. Wesentliche Eckpunkte und Empfehlungen dieses Papiers sind: Modularisierung: Ziel ist eine modulare Architektur, die den Austausch von Komponenten und die Zusammensetzung der Lösungen vereinfacht. Die Bündelung der Anforderungen nach Rollen und Entkopplung von Benutzerschnittstellen unterstützt dieses Ziel, indem es den Nutzern je nach ihrer Rolle das jeweils angemessene Werkzeug an die Hand gibt. Lebenszyklus des Schriftguts: Ziel ist es, die elektronische Verwaltungsarbeit aus Sicht der Anwender möglichst weitgehend und bruchfrei zu unterstützen. Es wird daher der gesamte Lebenszyklus von Schriftgut von der informellen Bearbeitung in unterschiedlichen Systemen, über die Phase der Bearbeitung von registriertem Schriftgut und die Phase der Langzeitspeicherung bis hin zur Aussonderung und Archivierung beim zuständigen Bundes- bzw. Landesarchiv betrachtet. Nutzung internationaler Standards der Schriftgutverwaltung: Langfristiges Ziel ist, dass innovative und am Markt verfügbare Produkte in der Bundesverwaltung eingesetzt werden. Produkte, die internationale Standards berücksichtigen, können einen hohen Verbreitungsgrad erreichen, werden dann intensiver weiterentwickelt, und sind i. d. R. zukunftsfähiger und interoperabler (Schnittstellenstandards) als nationale Nischenprodukte. Das Konzept Referenzarchitektur Elektronische Verwaltungsarbeit für die Bundesverwaltung leitet zunächst aus dem Organisationskonzept und einem international verbreiteteten Modell- Standard (ECM-Modell der AIIM) Grundelemente der Referenzarchitektur für die elektronische Verwaltungsarbeit ab. Dabei werden alle Phasen des Schriftgut-Lebenszyklus und die spezifischen Anforderungen der Nutzer in unterschiedlichen Rollen (Wissensarbeiter, Fallbearbeiter und Registraturkräfte) besonders berücksichtigt. Schließlich werden die Eckpunkte der Referenzarchitektur und ein Anwendungsbeispiel vorgestellt.

5 Inhaltsverzeichnis 2 Inhaltsverzeichnis Zusammenfassung...1 Inhaltsverzeichnis Einleitung Motivation und Ausgangssituation Zielstellung des Dokuments Vorgehensweise Herleitung der Referenzarchitektur Schritt 1: Fachliche Anforderungen Schritt 2: Anforderungen aus Sicht unterschiedlicher Rollen Schritt 3: Einordnung in das ECM-Modell der AIIM Schritt 4: Ableitung der Grundelemente Schritt 5: Berücksichtigung von Standardschnittstellen Schritt 6: Abgrenzung der Grundelemente Vollständige Referenzarchitektur und Einsatzbeispiel Fazit Verzeichnisse Abbildungsverzeichnis Tabellenverzeichnis Literaturverzeichnis Abkürzungsverzeichnis... 26

6 1 Einleitung 1.1 Motivation und Ausgangssituation Das Organisationskonzept elektronische Verwaltungsarbeit (OeV) hat in 2012 das Fachkonzept DOMEA als konzeptionelle organisatorische Basis für die Gestaltung und Einführung von Dokumentenmanagement- bzw. Vorgangsbearbeitungssystemen (DMS/VBS) abgelöst. Damit wurde eine neue Grundlage geschaffen, die erheblich größere Freiheitsgrade für die Einführung von DMS/VBS aufweist als der Vorgänger. Neuere Entwicklungen und Aspekte aus den Bereichen Kollaboration, Scannen und Archivieren wurden dabei berücksichtigt. Handlungsbedarf bezüglich einer technischen Standardisierung besteht zudem durch die anstehende Umsetzung des neuen E-Government-Gesetzes (EGovG). Hierdurch wird der Bedarf an Lösungen zur Unterstützung der elektronischen Verwaltungsarbeit innerhalb der Bundesverwaltung in absehbarer Zeit deutlich steigen. Mit dem OeV sollen Behörden individuelle Einführungsstrategien für die Komponenten der elektronischen Verwaltungsarbeit definieren können, die ihr spezifisches Anforderungsprofil berücksichtigen. Dadurch werden in den Bundesbehörden modulare Lösungen möglich, die ihre Vorteile wie Flexibilität, Interoperabilität und große Herstellerunabhängigkeit nur erreichen, wenn sowohl Schnittstellen als auch Funktionsumfangsstandards für einzelne DMS/VBS- Module festgelegt werden. Die vorliegende Referenzarchitektur für elektronische Verwaltungsarbeit (ReV) präzisiert das OeV und genügt dabei den Gestaltungsprinzipien die Rahmenarchitektur IT-Steuerung Bund. Referenzarchitektur meint in diesem Kontext eine grobgranulare technische Musterlösung ohne Detailbetrachtung im Hinblick auf einzusetzende Tools oder Produkte. Der Hauptbezugspunkt der ReV zum OeV liegt im Konzeptionsbaustein E-Akte. Detaillierte Erweiterungen in Richtung der Bausteine E-Vorgangsbearbeitung und E-Zusammenarbeit sowie die Berücksichtigung von Fachverfahren sind nicht Gegenstand dieses Dokuments und sollten ggf. in weiteren Ausbaustufen bzw. Versionen folgen. 1.2 Zielstellung des Dokuments Im vorliegenden Dokument wird eine Referenzarchitektur zur technischen Unterstützung der elektronischen Verwaltungsarbeit entworfen. Den inhaltlichen Schwerpunkt bildet dabei die technische Strukturierung der elektronischen Akte (E-Akte), die die Basis der elektronischen Verwaltungsarbeit darstellt.

7 Kapitel 1: Einleitung 4 Das Dokument soll insbesondere Neueinführungen von Dokumentenmanagementsystemen in Behörden unterstützen und vereinheitlichen. Auf diesem Dokument aufbauend, können weitere Detaillierungen vorgenommen werden, die dann z. B. in Ausschreibungen einfließen können. Es bildet einen konzeptionellen Rahmen für die technische Architektur von Systemen für elektronische Verwaltungsarbeit und benennt Vorgaben, Standards und Strukturen für die individuelle Anforderungserhebung. 1.3 Vorgehensweise Im Kapitel 2 soll die Referenzarchitektur schrittweise hergeleitet werden. Den fachlichorganisatorischen Rahmen der ReV liefert das OeV und die darin referenzierten Vorschriften zur Dokumentenverwaltung. Der dort beschriebene Lebenszyklus von Dokumenten, Vorgängen und Akten ist in Kapitel 2.1 dargestellt und bestimmt wesentliche Anforderungen und Rahmenbedingungen an die zu entwickelnde Referenzarchitektur (Schritt 1). Sie werden in Kapitel 2.2 durch rollenspezifische Anforderungen erweitert (Schritt 2). Die Anforderungen werden in Kapitel 2.3 in das Enterprise-Content-Management-Modell der Association for Information and Image Management (ECM-Modell) eingebettet (Schritt 3) (vgl. [1]). Dieser international anerkannte Anforderungsstandard definiert den Begriffsrahmen und klassifiziert die wesentlichen Komponenten für die elektronische Bearbeitung von Dokumenten, Informations- und Arbeitsinhalten. Auf Basis des ECM-Modells werden in Kapitel 2.4 die Grundelemente des Architekturrahmens für die elektronische Verwaltungsarbeit in der Bundesverwaltung abgeleitet (Schritt 4). Dieser Rahmen stellt die für die Zielstellung relevanten Systemkomponenten dar und ermöglicht unter Berücksichtigung vorhandener Abhängigkeiten die Bündelung von Anforderungen. In Kapitel 2.5 werden die wesentlichen Standardschnittstellen des DMS-Kerns beschrieben (Schritt 5). Die für die Referenzarchitektur gesammelten Anforderungen stammen wesentlich aus dem OeV, aus dem sich die funktionalen Anforderungen ableiten lassen. Die Grundelemente der ReV werden in Kapitel 2.6 näher dargestellt und weiter ausgebaut, um für eine Anforderungserhebung eine klare Abgrenzung und Beschreibung der Einsatzszenarien zu ermöglichen. Dabei soll auf internationale Anforderungsstandards für DMS (z B. MoReq2010, DoD ; vgl. [2], [3]) referenziert werden, die weitergehende technische Anforderungen enthalten. In Kapitel 3 wird die vollständige Referenzarchitektur nochmals zusammenfassend dargestellt. Abschließend werden die wichtigsten Leitgedanken formuliert und ein Fazit gezogen (Kapitel 0).

8 2 Herleitung der Referenzarchitektur 2.1 Schritt 1: Fachliche Anforderungen Die wesentlichen funktionalen Anforderungsbereiche für die Referenzarchitektur stammen aus dem OeV. Dieses gliedert die Anforderungen in zielgruppenorientierten Bausteinen (vgl. Abbildung 1): Abbildung 1: Bausteine des Organisationskonzepts elektronische Verwaltungsarbeit Im Baustein E-Akte des OeV werden fachliche Anforderungen an die Schriftgutverwaltung beschrieben und anhand von Beispielen konkretisiert. Dieser Baustein behandelt die Prozessbereiche Ordnen, Registrieren, Bereitstellen sowie Langzeitspeicherung und Aussonderung. Um die Elemente für die ReV herausarbeiten zu können, werden zunächst die Lebenszyklen von Dokument, Vorgang und Akte sowie deren organisatorische und technische Implikationen aufgezeigt: Ein aktenrelevantes elektronisches Dokument, das von einer Bundesbehörde nach 10 der Richtlinie für das Bearbeiten und Verwalten von Schriftgut in Bundesministerien (RegR) einer elektronischen Akte zugeordnet wird, durchläuft in seinem Lebenszyklus unterschiedliche Phasen, mit denen gegebenenfalls unterschiedliche Zuständigkeiten und Speicherorte zusammenhängen. Abbildung 2 stellt die relevanten Phasen im Lebenszyklus von elektronischem Schriftgut (in Form von Dokumenten, Vorgängen und Akten) einer aktenführenden Behörde mit den zugehö-

9 Kapitel 2: Herleitung der Referenzarchitektur 6 rigen Zuständigkeiten dar: Informelle Bearbeitung, Bearbeitung, Langzeitspeichung und Archivierung. Zur Schärfung und Abgrenzung der Begrifflichkeiten um den Komplex Langzeitspeicherung und Archiv wurde die Archivierung von elektronischem Schriftgut in der Archivbehörde ebenfalls als Phase in die Betrachtung einbezogen. Das OeV spricht in diesem Zusammenhang nur von den Phasen Bearbeitung, Langzeitspeicherung und Aussonderung (vgl. [4], S. 89ff). Das Aussondern von Akten bzw. Vorgängen wird hier als einer von drei Übergangsprozessen verstanden. Die Unterscheidung von informeller und formeller Bearbeitung wird im nächsten Unterkapitel erläutert. Um architektonische Ableitungen treffen zu können, wurden diese Phasen zusammen mit den Perspektiven wichtige Fristen, Zuständigkeit und Speicherort dargestellt. Abbildung 2: Lebenszyklus von elektronischen Dokumenten, Vorgängen und Akten Im Folgenden werden die in der Abbildung dargestellten Phasen näher erläutert Informelle Bearbeitung Die erste Phase des Informationslebenszyklus beginnt mit dem Erzeugen des Dokuments bzw. der Information und endet mit dem Registrieren des ab dann aktenrelevanten Dokuments im DMS inkl. der Zuordnung zu einer Akte und zu einem Vorgang. Sobald die zur Erstellung zugehörigen entscheidungsrelevanten Bearbeitungsschritte zur späteren Nachvollziehbarkeit und Transparenz des Verwaltungshandelns aufzubewahren sind (vgl. [4], S. 13), endet die informelle Bearbeitung des Dokumentes. Vorher ist ein Dokument eher als Entwurf, Skizze, Fragment, Dialog oder Notiz zu bezeichnen. Aufgrund neuer Arbeitsgewohnheiten und netzbasierter Dienste

10 7 Kapitel 2: Herleitung der Referenzarchitektur können sich diese Dokumente in unterschiedlichen Quellen befinden: Wiki, Groupware, Portale, Dateiablage etc. Sie können jedoch sofort oder später Aktenrelevanz erlangen. Das OeV sieht für Dokumente, die noch nicht bzw. nur potenziell aktenrelevant sind, die Festlegung einer Wiedervorlagefrist vor, nach der die Aktenrelevanz neu zu beurteilen ist (vgl. [4], S. 10ff). Dokumente sind in der informellen Bearbeitungsphase meist noch größeren Änderungen unterworfen. Zunehmend erwarten die Anwender jedoch bereits in dieser Phase die Unterstützung durch die Komfortfunktionen eines DMS (z. B. Versionierung, Check-In/Check-Out). So ermöglicht beispielsweise die Versionierung von Dokumenten bereits bei der informellen Bearbeitung alle Bearbeitungsschritte nachzuvollziehen, die zur Entstehung des Dokuments geführt haben, was die Transparenz und Nachvollziehbarkeit erhöht. In der Phase der informellen Bearbeitung können unterschiedliche Elemente der Referenzarchitektur eine Rolle spielen. Immer häufiger wird Schriftgut nicht nur als Scan- oder gespeichertes Office-Dokument entstehen, sondern kollaborativ in Team-Rooms, Blogs, Wikis o. ä. gemeinsam entwickelt werden. Daher sollten Elemente der Referenzarchitektur Anforderungen für das kollaborative Erarbeiten von Dokumenten sowie für die informelle Abstimmung und Zusammenarbeit bei der Bearbeitung von Dokumenten, bis diese einen aktenwürdigen Reifegrad erlangt haben, berücksichtigen. Nach Beendigung der informellen Bearbeitung sollte das Dokument, sobald es aktenrelevant wird, durch die bearbeitende Person oder einer zuständigen Registraturkraft einem Vorgang zugeordnet, und mit zusätzlichen Metadaten versehen werden (Dokument registrieren). Ab diesem Zeitpunkt befindet sich das Dokument in der Phase der Bearbeitung Phase der Bearbeitung Während der Phase der (formalen) Bearbeitung befindet sich das aktenrelevante elektronische Schriftgut im Zuständigkeitsbereich der aktenführenden Behörde und wird im DMS der aktenführenden Behörde verwaltet. Änderungen am Dokument werden zu neuen Versionen zusammengefasst. Spätestens nach Abschluss der Bearbeitung sind für das Schriftgut neben den weiteren Metadaten wie z. B. Aktenzeichen, Betreff und Eingangsdatum auch die Aufbewahrungsfristen festzulegen. Das Festsetzen der Aufbewahrungsfristen kann zur Vereinfachung bereits im Vorfeld erfolgen. Für die geltende Aufbewahrungsdauer ist abschließend bearbeitetes Schriftgut gemäß 18 RegR bis zur Aussonderung unverändert und vollständig im Aktenbestand zu bewahren. Die abschließende Bearbeitung von Schriftgut wird auf Vorgangsebene durch die Verfügung zda

11 Kapitel 2: Herleitung der Referenzarchitektur 8 deklariert. Mit der zda-verfügung beginnen sowohl die Aufbewahrungsfrist als auch die Transferfrist. Als Transferfrist wird der Zeitraum bezeichnet, in dem die abgeschlossenen Akten und Vorgänge im aktiven Aktenbestand verbleiben, bevor sie in den passiven Aktenbestand, z. B. auf langsamere Speichermedien oder einen externen Langzeitspeicher, überführt werden. (vgl. [4], S. 92) Für die Dauer der Transferfrist bleiben die Inhalte des abschließend bearbeiteten elektronischen Schriftguts im aktenführenden DMS gespeichert. Nach Ablauf der Transferfrist beginnt die Phase der Langzeitspeicherung. Die Transferfrist ist von fachlichen und technischen Überlegungen bestimmt: Fachlich kann es sinnvoll sein, eine Transferfrist einzurichten, wenn zda-verfügte Dokumente häufig doch noch Änderungen unterworfen sind. Die Länge der Transferfrist kann durch technische Überlegungen zum Transferprozess bestimmt werden: Zu transferierende Dokumente können gesammelt und erst zu definierten Zeitpunkten oder bei Erreichen bestimmter Volumina in den Langzeitspeicher verschoben werden. Die Transferfrist kann minimal sein, wenn das zda-verfügte Dokument sofort verschoben werden kann. Verbleibt das Dokument für die Langzeitspeicherung im selben DMS entfällt die Transferfrist Phase der Langzeitspeicherung Nach 18 RegR sind bei elektronisch gespeichertem Schriftgut Vollständigkeit, Integrität, Authentizität sowie Lesbarkeit für die geltende Aufbewahrungsdauer durch dafür geeignete Maßnahmen zu gewährleisten. Um die Authentizität (Erkennen der Echtheit) und Integrität (Erkennen von Modifikationen) bei elektronisch gespeichertem Schriftgut zu verifizieren sind entsprechende organisatorische und technische Maßnahmen zu treffen. Diese sind durch das BSI in der technischen Richtlinie TR Beweiswerterhaltung kryptografisch signierter Dokumente definiert. (vgl. [5]). Die Richtlinie spezifiziert die sicherheitstechnischen Anforderungen an eine langfristige, vertrauenswürdige und rechtssichere elektronische Speicherung von aufbewahrungspflichtigen elektronischen Dokumenten und Daten zur Erfüllung der gesetzlichen Aufbewahrungspflichten. Die Datenhaltung während der Phase der Langzeitspeicherung kann entweder im aktenführenden (aktiven) DMS oder in einem dedizierten (passiven) System zur Langzeitspeicherung erfolgen. Bei Verwendung eines dedizierten Systems verbleiben alle Metainformationen der Akten, Vorgänge und Dokumente üblicherweise im aktenführenden DMS, der Dokumentencontent (Word-Dokument, Excel-Arbeitsmappe, etc.) wird an das dedizierte System übergeben und aus dem aktiven DMS entfernt.

12 9 Kapitel 2: Herleitung der Referenzarchitektur Der lesende Zugriff auf die Inhalte von Akten und Vorgängen, die sich in der Phase der Langzeitspeicherung befinden, sollte für die anwendende Person ohne weiteres aus dem aktenführenden System heraus möglich sein. Daraus leitet sich bei Verwendung eines dedizierten Systems zur Langzeitspeicherung insbesondere die Anforderung einer unmittelbaren Integration dieses Systems in das aktenführende DMS ab. Weitere Anforderungen zu organisatorischen Aspekten bei der Langzeitspeicherung werden demnächst im OeV-Modul E-Langzeitspeicherung veröffentlicht. Zudem ist geplant, ein digitales Zwischenarchiv als Basisdienst für die Bundesverwaltung bereitzustellen. Dieses Zwischenarchiv ist ein System zur Langzeitspeicherung und soll den Aussonderungs- und Übergabeprozess an das Bundesarchiv erleichtern und somit das OeV-Modul E- Langzeitspeicherung technisch realisieren. Nach Ablauf der Aufbewahrungsdauer erfolgt die Aussonderung des elektronischen Schriftguts. Dabei wird das Schriftgut dem Bundesarchiv angeboten. Nach deren Maßgabe wird Schriftgut, das vom Bundesarchiv als archivwürdig bewertet wurde, an das Bundesarchiv übergeben. Danach wird das ausgesonderte Schriftgut in der aktenführenden Behörde gelöscht bzw. vernichtet Phase der Archivierung Die Phase der Archivierung ist das Ergebnis der Aussonderung des elektronischen Schriftguts nach 21 RegR. Nach Ablauf der Aufbewahrungsfrist ist dem Bundesarchiv elektronisch gespeichertes Schriftgut mit einem Anbieteverzeichnis anzubieten. In diesem Verzeichnis vermerkt das Bundesarchiv, ob die Unterlagen archivwürdig sind oder das Schriftgut zu vernichten ist. Archivwürdiges Schriftgut wird an das Bundesarchiv übergeben. Schriftgut, auf dessen Übernahme das Bundesarchiv im Vorfeld bereits schriftlich verzichtet hat, kann in der aktenführenden Behörde sofort vernichtet werden. Der Nachweis darüber wird im Aussonderungsverzeichnis geführt. Im Gegensatz zur Phase der Langzeitspeicherung, deren Motivation gesetzlich geregelte Aufbewahrungspflichten sind, ist die Phase der Archivierung durch eher kulturhistorisches Interesse motiviert. Daraus ergeben sich ggf. andere Anforderungen z. B. zum Erhalt der Verkehrsfähigkeit 2.2 Schritt 2: Anforderungen aus Sicht unterschiedlicher Rollen Aus den einzelnen Phasen des Lebenszyklus lassen sich Bereiche identifizieren, die besondere Anforderungen (vor allem im Bereich Ergonomie) an die ECM-Komponenten haben. Für die Behörden der Bundesverwaltung lassen sich drei typische Rollen für die Nutzung eines DMS identifizieren:

13 Kapitel 2: Herleitung der Referenzarchitektur 10 Wissensarbeiter (engl. Knowledge-Worker) Fallbearbeiter (engl. Case-Worker) Registraturkräfte In Abbildung 3 sind Hauptbedarfe für diese Rollen sowie eine Charakterisierung ihrer Aufgaben aufgelistet. Diese Rollen können sich überschneiden. So können sich für einen konkreten Arbeitsplatz Anforderungen aus allen drei Rollen ergeben. Rolle Aufgabencharakter ECM-Hauptbedarfe Planerisch Operativ Unterstützend Wissensarbeiter (Knowledge Worker) Fallbearbeiter (Case worker) Flexibel Agil Projektorientiert Wenig-strukturierte Prozesse Fallorientiert Hoher Datendurchsatz Hochstrukturierte Prozesse Registraturkraft Regelkonform Strukturiert Bewahrend Flexibles Instrumentarium / Toolbox-Charakter Große Freiheitsgrade Hohe Integration in die sonstige Arbeitsumgebung (insbes. Office, ) Zunehmender Bedarf an mobilem Arbeiten Hohe Integration in Fach-/Querschnittsverfahren (rollenspezifisch konfigurierbar) Hohe Unterstützung für strukturierte Prozesse Effiziente Unterstützung der Regeldefinitionen Ablageorientierung Effiziente Unterstützung der Aussonderung Langfristig tragfähige Archivstrukturen Abbildung 3: Hauptbedarfe der elektronischen Verwaltungsarbeit nach Rollen Die Wissensarbeiter arbeiten eher entscheidungsvorbereitend und teilweise in Ad-hoc- Prozessen. Ihnen soll ein System zur Verfügung gestellt werden, das den Übergang zur E-Akte fließend und nahtlos macht. Sie wollen Dokumente erstellen und bearbeiten, ohne sie sofort verakten zu müssen (informelle Bearbeitung). Wissensarbeiter sollten die DMS Funktionen zur Versionskontrolle nutzen, um ihre Bearbeitungsschritte nachvollziehbar und transparent zu machen. Gleichzeitig sind für diese Rolle verstärkt Möglichkeiten der mobilen Bearbeitung von Akten vorzusehen. Die Fallbearbeiter arbeiten operativer, in strukturierten Prozessen und mit Dokumenten, die in der Regel von Beginn an aktenrelevant sind. In den meisten Fällen nutzen sie Fach- oder Querschnittverfahren zur Bearbeitung ihrer Vorgänge. Das DMS ist für sie ein unsichtbarer Dienst, den sie durch die Integration in ihre Hauptanwendungen nicht als eigenständiges System wahrnehmen. Das Tätigkeitsspektrum der Registraturkräfte teilt sich in administrative und unterstützende Aktivitäten: Im administrativen Bereich geht es z. B. um das Hinterlegen von Regeln im DMS

14 11 Kapitel 2: Herleitung der Referenzarchitektur (z. B. Geschäftszeichenbildungsregeln); der unterstützende Bereich umfasst z. B. das Registrieren von Dokumenten oder Anlegen von Akten. Für Wissensarbeiter und Fallbearbeiter ist das DMS ein unsichtbarer Dienst, d. h. diese Nutzer, die diese Rolle einnehmen nutzen die DMS Funktionalitäten indirekt durch deren Integration in ihre Hauptanwendungen (z. B. Office-Produkte bei Wissensarbeitern bzw. Fachanwendungen bei Fallbearbeitern). Registraturkräfte benötigen in der Regel spezifische Oberflächen des DMS zur Bewältigung ihrer Aufgaben. Selbstverständlich kann ein Nutzer in der Praxis mehr als eine der vorgenannten Rollen einnehmen. Für das vorliegende Konzept ist jedoch wichtig, dass diese Rollen unterschiedliche Anforderungen an den Basisdienst E-Akte stellen, was am Beispiel unterschiedlicher Anforderungen an die Benutzeroberfläche illustriert werden soll: Der Wissensarbeiter arbeitet mit dem DMS indirekt über Standardsysteme, z. B. über ein Portal oder das im Dateimanager eingebundene Netzlaufwerk. Der Fallbearbeiter arbeitet mit dem DMS indirekt über spezifische VBS, z. B. über das Fachverfahren, das das DMS direkt anbindet. Die Registraturkraft arbeitet mit dem DMS direkt, z. B. über Oberflächen, die vom DMS selbst bereitgestellt werden (u. a. Administration des Aktenplans). Trotz dieser verschiedenen Zugänge kann und sollte sich dahinter ein zentrales DMS verbergen, das über Schnittstellen und unterschiedliche Oberflächen diese Anforderungen erfüllt. Das gilt langfristig ebenso für die Fachverfahren, die DMS-Funktionen benötigen. 2.3 Schritt 3: Einordnung in das ECM-Modell der AIIM Einen De-facto-Standard für international agierende Produkthersteller, der die Aspekte rund um das Thema unstrukturierte Informationen und elektronische Dokumente definiert und ordnet, liefert das Enterprise-Content-Management-Modell der AIIM, das nachfolgend frei übersetzt dargestellt ist.

15 Kapitel 2: Herleitung der Referenzarchitektur 12 Abbildung 4: ECM-Modell nach AIIM (übersetzt aus dem Englischen) Grundsätzlich umfasst dieses ECM-Modell alle Werkzeuge, Techniken und Prozesse, die notwendig sind, um unstrukturierte Informationen und elektronische Dokumente zu erfassen (capture), zu managen (manage), bereitzustellen (delivery), zu speichern (store) und zu bewahren (preserve). Tabelle 1 beschreibt diese Bereiche im Detail. Bereich Erfassen Managen Charakterisierung Im Mittelpunkt stehen die Möglichkeiten zur Erfassung und Aufbereitung papiergebundener und elektronischer Informationen, um sie anschließend elektronisch weiterzuverarbeiten. Die Informationsverteilung innerhalb einer Organisation wird hier behandelt. Es kommen dabei fünf wesentliche Ansätze zum Einsatz: Dokumente / Informationen (Document Management) Wie werden relevante elektronische Informationen/Dokumente verwaltet? Zusammenarbeit (Collaboration) Wie arbeiten mehrere Personen(-gruppen) an gleichen Inhalten zusammen? Netzinhalte (Web Content Management) Wie werden web-basierte Inhalte erstellt, überprüft, genehmigt und der Veröffentlichungsprozess organisiert? Schriftgut / Aktenplan (Records Management) Wie werden Dokumente im Verlauf des Lebenszyklus behandelt?

16 13 Kapitel 2: Herleitung der Referenzarchitektur Bereich Speichern Bewahren Bereit stellen Charakterisierung Geschäftsprozesse (Workflow / Business Process Management) Wie können Prozesse, an den mehrere Akteure beteiligt sind, vollständig oder teilweise automatisiert ablaufen? Hierbei geht es um die Aufbewahrung und das Wiederfinden nichtarchivierungswürdiger oder nicht-archivierungspflichtiger Inhalte. Dieser Bereich fokussiert die langzeitig stabile, statisch und unveränderte Aufbewahrung und Speicherung von Informationen. In diesem Bereich wird geklärt, welche Informationen aus den vorher genannten Bereichen bereitgestellt werden, ggf. auch zur Weitergabe an weitere Medien oder Dritte. Tabelle 1: Charakterisierung der ECM-Bereiche nach AIIM Das ECM-Modell der AIIM liefert den Nukleus für den Aufbau der Referenzarchitektur und die Strukturierung seiner Elemente. Dieser Nukleus muss mit für die Bundesverwaltung relevanten Architektur-Grundelementen bzw. Basisdiensten gefüllt werden (z. B. Dokumenten- Management, Records-Management, Scanning, Kollaboration). 2.4 Schritt 4: Ableitung der Grundelemente Abbildung 5 zeigt den aus den bisherigen Überlegungen abgeleiteten konzeptuellen Architekturrahmen für einen DMS-Basisdienst mit seinen angrenzenden Systemen, die im Folgenden weiter ausgearbeitet werden. Abbildung 5: Konzeptioneller Architekturrahmen mit AIIM-ECM-Modell

17 Kapitel 2: Herleitung der Referenzarchitektur 14 Als praktische Vereinfachung wurden die AIIM-ECM-Module Dokumente und Speichern zum Dokumenten-Management-Kern (DM-Kern) zusammengefasst und als Kernkomponente der Referenzarchitektur ausgewählt. In der Praxis sind diese i. d. R. auch eng verzahnt und der Zugriff auf die Dokumentanablage (Storage) erfolgt über die DMS-Funktionalität. Regelkonformität der Schriftgutverwaltung ist für die öffentliche Verwaltung essentiell. Im Hinblick auf ein integriertes DMS kommt daher dem Modul Schriftgutverwaltung (Records Management / RM) eine besondere Bedeutung zu. In diesem Modul werden die Regeln der Schriftgutverwaltung definiert und kontrolliert. Das Modul wird vor allem von Nutzern der Rolle Registraturkräfte benötigt. Hier werden z. B. Aktenpläne, Aufbewahrungsfristen, Konvertierungsregeln (z. B. bei Umstrukturierung von Aktenplänen aufgrund organisatorischer Änderungen etc.) definiert, die dann im DM-Kern, für aktenrelevante Dokumente von den anderen Nutzern der Rollen Wissensarbeiter und Fallbearbeiter verwendet werden. Durch die Aufteilung in DM-Kern und RM-Modul, wird eine funktionale Entkopplung zwischen dem Arbeiten mit Schriftgut und dem Verwalten von Regeln zur Schriftgutverwaltung geschaffen. Diese technische Trennung erlaubt, das für den jeweiligen Einsatzbereich optimale Werkzeug einzusetzen. Die initiale, noch nicht zwingend aktenrelevante Erstellung von Dokumenten, z. B. als erste Entwürfe, wird damit möglich. Durch die Aufteilung in zwei Module wird die strukturelle Grundlage geschaffen, den z. T. divergierenden Anforderungen der Rollen Registraturkräfte, Wissensarbeiter und Fallbearbeiter individuell Rechnung tragen zu können und damit die Akzeptanz der einzelnen Nutzer zu erhöhen. Die marktführenden Hersteller von ECM-Produkten bieten heute entsprechende RM-Module an. Der Markt für Records Management ist seit ca stark gewachsen. Auslöser hierfür waren vor allem die US-amerikanischen Bilanzskandale und der daraus resultierende Sarbanes-Oxley-Act. In der Folge wurden die Compliance-Richtlinien (Richtlinien zur Regelkonformität) in den Unternehmen verschärft, betriebliche Prozesse und Entscheidungen mussten nachvollziehbar dokumentiert und archiviert werden. Durch den Sarbanes-Oxley-Act ist die Anforderungsdomäne der Nachvollziehbarkeit des (elektronischen) Verwaltungshandeln keine Spezialität des öffentlichen Sektors mehr. Die Forderung der Nachvollziehbarkeit von unternehmerischen und geschäftlichen Entscheidungen führte zu breit verfügbaren, branchenunabhängigen Records- Management-Systemen, in denen nahezu alle Regeln zum Umgang mit elektronischem Schriftgut konfiguriert werden können und die im o. g. Sinne zu einer Entkopplung der technischen Module für die verschiedenen Rollen beitragen. Diese Systeme können beschafft und als Fertigkomponenten in das Gesamtsystem integriert werden. Durch die weite Verbreitung der Module

18 15 Kapitel 2: Herleitung der Referenzarchitektur in der Wirtschaft ist gleichzeitig auch deren Weiterentwicklung gegeben, wodurch die Verwaltung langfristig von neuen Technologien profitieren kann. Der Bereich Erfassen wird durch das Scanning-Modul bedient (Erfassung papiergebundener Dokumente). Jedoch können ebenso die Module Explorer, Personal Information Management (PIM) / und Office dem Bereich Erfassen zugeordnet werden (Erfassung elektronischer Dokumente). Diese Systeme sollen Möglichkeiten bieten, dem DM-Kern Dokumente und andere Informationsobjekte zu übergeben. Der Bereich Bewahren wird durch die Komponente Langzeitspeicherung repräsentiert (technische Archivsysteme). Die Managen-Module WF/BPM (Workflow und Business Process Management) und WCM (Web Content Management) des ECM-Modells sind ebenfalls direkt in den konzeptionellen Architekturrahmen überführt worden. Die Module Portal und Kollaboration sind, wenn sie als externe Systeme betrachtet werden, wie Office oder Explorer sowohl Quelle als auch Senke von Dokumenten und damit den beiden Bereichen Erfassen und Bereitstellen zuzuordnen. Die bereinigte, grundlegende Referenzarchitektur ist in Abbildung 6 dargestellt. Zu den einzelnen Elementen der Referenzarchitektur werden in Kapitel 2.6 die jeweiligen Anforderungsklassen detaillierter beschrieben. Abbildung 6: Grundlegende Referenzarchitektur für den DMS-Basisdienst 2.5 Schritt 5: Berücksichtigung von Standardschnittstellen Die aufgeführten peripheren technischen Module und der DM-Kern sollten über einschlägige Standard-Schnittstellen zueinander integriert sein. Der Grund hierfür ist eine möglichst hohe potenzielle Austauschbarkeit der Module. Als wesentliche Schnittstellenstandards, die bei Pro-

19 Kapitel 2: Herleitung der Referenzarchitektur 16 duktauswahl für das DMS berücksichtigt werden sollen, sind hier insbesondere die Folgenden zu nennen: WebDAV: Die Abkürzung steht für Web-based Distributed Authoring and Versioning und wurde ursprünglich für die allgemeine Bereitstellung von Inhalten (Dateien) im Internet konzipiert. Technisch stellt WebDAV eine Erweiterung des http-protokolls dar. Über WebDAV können Informationssysteme (wie z. B. ein DMS) in Dateimanager (z. B. Microsoft Explorer) wie ein Netzlaufwerk integriert werden. WebDAV ist ein offener Standard und wird von Arbeitsgruppen der Internet Engineering Task Force (IETF) weiter entwickelt. WebDAV ist ein SAGA-Standard mit der Leitstufe Empfohlen. CMIS: CMIS steht für Content Management Interoperability Services und ist ein offener Standard. CMIS stellt ein WebService-Interface dar, das Objekte und Methoden für Dokumentenmanagement bietet. Namhafte Hersteller von DMS haben sich an der Entwicklung des Standards beteiligt und statten ihre Produkte mit CMIS aus. Der CMIS-Standard liefert damit einen Beitrag zur Interoperabilität zwischen den verschiedenen DMS- Komponenten. Damit können Dokumente im Rahmen einer ggf. nötigen Produktablösung von einem Quell- auf ein Zielsystem übertragen werden. CMIS ist ein SAGA- Standard mit der Stufe Beobachtet. CIFS: CIFS steht für Common Internet Filesystem und wurde 1996 von Microsoft eingeführt. CIFS baut auf NetBIOS over TCP/IP und SMB auf und wurde an die Internet Engineering Task Force zur Standardisierung übergeben. Es soll eine Ergänzung und Verbesserung für das FTP-Protokoll darstellen und als Netzwerkdateisystem für Internetanwendungen dienen. IMAP: Das Internet Message Access Protocol (IMAP) ist ein textbasiertes Netzwerkprotokoll für den Zugriff und die Verwaltung von empfangenen s. IMAP wird von fast allen Clients unterstützt. Es erweitert die Funktionen von Post Office Protocol (POP) derart, dass die Daten auf den Mail-Servern belassen werden können und auch über mehrere Clients ein einheitlicher Zugriff auf s ermöglicht werden kann. IMAP ist ein SAGA-Standard mit der Stufe Empfohlen. Die folgende Abbildung 7 zeigt, zwischen welchen Elementen welche Schnittstellen zum Einsatz kommen. Diese Darstellung erhebt keinen Anspruch auf Vollständigkeit. Wichtig im Rahmen von Ausschreibungssituationen ist es, das Einsatzszenario genau zu definieren und die Standardschnittstellen zu benennen, die darin erforderlich sind. Die unten genannten Schnittstellen sollten jedoch mindestens dazu gehören.

20 17 Kapitel 2: Herleitung der Referenzarchitektur Abbildung 7: Referenzarchitektur mit Standardschnittstellen 2.6 Schritt 6: Abgrenzung der Grundelemente Anforderungen müssen im Rahmen jeder Analyse zielgerichtet gebündelt werden. Es bietet sich an, die Anforderungsbündel an den Grundelementen der Referenzarchitektur auszurichten. Damit werden modulare Systemarchitekturen unterstützt. Das OeV nimmt einen organisatorischen Blickwinkel ein und lässt Spielräume für eine konkrete technische Umsetzung. Diese Spielräume müssen im Rahmen einer Ausschreibung mit konkreten technischen Anforderungen gefüllt werden. Dazu eignen sich internationale Standards wie z. B. DoD und MoReq2010. Diese Standards liefern heute bereits die Grundlage für erfolgreiche, praxiserprobte technische Lösungen innerhalb der öffentlichen Verwaltung in anderen Ländern. Die Anlehnung an diese Standards ermöglicht, dass Standardsoftwarekomponenten zum Einsatz kommen können und kostenintensive Zusatzprogrammierung weitgehend vermieden werden. Im Folgenden werden die Elemente der Referenzarchitektur kurz erläutert und abgegrenzt DM-Kern Im Mittelpunkt der ReV steht der DM-Kern. Wie schon in Kapitel 2.4 erwähnt, werden in diesem Element die ECM-Bereiche Dokumente managen und Speichern (inkl. Versionierung sowie Check-In/Check-Out) zusammengefasst. Der DM-Kern kümmert sich rein um die Verwaltung und Behandlung von Dokumenten. Dieses Grundelement wird vom OeV-Baustein E-Akte fachlich und funktional umrissen. In MoReq2010 und DoD5015 wird es sehr detailliert fachlich und technisch spezifiziert. Anforderungen können von dort übernommen oder entsprechend referenziert werden.

21 Kapitel 2: Herleitung der Referenzarchitektur Records Management Records Management stellt im Sinne der AIIM einen eigenen Dienst dar, der Regeln für die Verwaltung von Akten und Vorgängen bereithält (z. B. Aktenpläne). Es werden zudem Fristen im Lebenszyklus von Akten, Vorgängen und Dokumenten überwacht. In MoReq2010 werden dazu logisch getrennte Dienste vorgeschlagen. Auch in DoD5015 existieren zu diesem Thema drei getrennte Anforderungsbereiche. Wenn dem modularen Aufbau dieser Anforderungsstandards gefolgt wird, kann prinzipiell eine Trennung in unterschiedliche Systeme für DM und RM erfolgen Langzeitspeicherung Die Langzeitspeicherung bezeichnet einen Dienst, der den passiven (nicht mehr aktiv genutzten) Dokumentenbestand innerhalb der Aufbewahrungsfrist verwaltet. Das OeV widmet der Langzeitspeicherung bereits im Baustein E-Akte einen ausführlichen Anhang, der in einem eigenen Baustein präzisiert werden wird. In MoReq2010 sind hierzu Anforderungen zu finden, die nahe am deutschen Entwicklungsstand liegen und dadurch künftig in den großen Standardanwendungen stärker berücksichtigt werden wird Office, PIM / und Explorer Die Dienste Office, PIM/ und Explorer dienen gleichermaßen als Quelle und Ziel von Dokumenten und Informationen. Das OeV behandelt diese Bereiche als wichtig für die Akzeptanz des E-Akte-Systems. Bei MoReq2010 und DoD5015 werden sie als Schnittstellen unter dem Blickwinkel der Interoperabilität betrachtet (vgl. zu beiden Standards [1], [2]). Dieser Bereich war in den letzten Jahren auf der Anforderungsseite sehr dynamisch. Die gesetzten Standards werden stetig von den Nutzeranforderungen überholt. Die einführenden Behörden werden hierzu eigene Anforderungsprofile entwickeln müssen. Grundzüge dazu können jedoch in einer Pilotierung validiert und festgelegt werden Portal Ein Portal im Sinne der ECM-Strategie ist ein IT-System, das Anwendungen, Prozesse und Dienste integriert und dem Benutzer ggf. personalisiert einen sicheren Zugang zu Unternehmensdaten und -funktionen bietet. Externe Daten und Funktionen können ebenfalls angebunden sein. Ein Portal ist erster Anlaufpunkt für die Informationsgewinnung und eine anwendungsübergreifende Suche. Portale können auch den Zugang zu Systemen zur Kollaboration (OeV-Modul E-

22 19 Kapitel 2: Herleitung der Referenzarchitektur Zusammenarbeit) liefern. In MoReq2010 werden hierzu Schnittstellen beschrieben. In DoD5015 sind dazu Anforderungen an die Interoperabilität aufgeführt Kollaboration Die ECM-Komponente Kollaboration managen umfasst Systeme, die die Zusammenarbeit unterstützen sollen. Ursprünglich wurden darunter Groupware-Lösungen verstanden. Heute geht man funktionell weiter und fasst darunter alle Formen der formellen und informellen Zusammenarbeit. Im Sinne eines dynamischen Wissensaufbaus gehört auch Wissensmanagement dazu. Wichtige Funktionen sind: synchrones Kommunizieren (Audio- und Video-Konferenzen, Chat) asynchrones Kommunizieren (Blog, Teamroom) Bereitstellen und gemeinsames Bearbeiten von Informationen und Dateien (Wiki, Clouddienste) Schnittstellen zu den anderen Elementen der Referenzarchitektur, insbesondere zum DM-Kern, sind hier oft noch proprietär (z. B. MS-SharePoint-Protokoll). Wichtig ist daher die Anforderung, dass Systeme zusätzlich offene Standardschnittstellen anbieten (z. B. CMIS) Workflow / BPM Im OeV werden die Begriffe Workflow und Business-Process-Management in den Baustein E-Vorgangsbearbeitung eingeordnet. Unter Workflows versteht das OeV die technische Realisierung von Geschäftsprozessen in Software. Das OeV unterscheidet strukturierte und teilstrukturierte Geschäftsprozesse. Während bei strukturierten Geschäftsprozessen der Workflow i. d. R. stabil ist, können teilstrukturierte Geschäftsprozesse häufig nur durch sog. Ad-hoc-Workflows unterstützt werden. Das sind Workflows, die für jeden Fall einzeln definiert werden und sich noch während des Ablaufs des Workflows verändern lassen (z. B. veränderte Mitzeichnung) Scanning Die Komponente Scanning bezeichnet die elektronische Erfassung papiergebundener Dokumente. Nach dem Erstellen eines grafischen Abbilds (Bilddatei, Faksimile) können zudem Verfahren zu Texterkennung eingesetzt werden. Damit können aus unstrukturierten Daten strukturierte Daten (Meta-Daten) gewonnen werden (z. B. Erkennung von Aktenzeichen oder Kontaktdaten via Mustererkennung). Während des Scan-Prozesses kann es nötig werden, Meta-Daten manuell erfassen zu lassen, weil sie nicht automatisch erkannt wurden oder auf dem Original nicht vorhanden waren (z. B. Aktenzeichen).

23 Kapitel 2: Herleitung der Referenzarchitektur 20 Eine besondere Bedeutung nimmt das ersetzende Scannen im E-Government-Gesetz ein. Ziel ist es, die Möglichkeit zu schaffen, die eingescannten Dokumente vernichten bzw. zurücksenden zu können und dabei gleichzeitig deren Beweiswert zu erhalten Web Content Management Der ECM-Bereich Netzinhalte managen (Web Content Management / WCM) wird vom OeV nur im Sinne behördeninterner Zusammenarbeit berührt. Die Webangebote der Bundesverwaltung werden in der Regel mithilfe des Government-Site-Builders (GSB) mit Inhalten versorgt. Der GSB wurde vom Bundesverwaltungsamt als zentrale WCM-Lösung für die Bundesverwaltung entwickelt. Im Hinblick auf eine integrierte ECM-Lösung sind Schnittstellen zwischen ECM-Basisdiensten und dem GSB zu spezifizieren. Dabei sollten folgende Anwendungsfälle betrachtet werden: Übergabe und ggf. Konvertierung von Dokumenten, die im internen oder externen Web- Angebot verfügbar gemacht werden sollen. Abstimmung von Texten, die in internen virtuellen Arbeitsräumen entwickelt und abgestimmt wurden und im internen oder externen Web-Angebot veröffentlicht werden sollen.

24 3 Vollständige Referenzarchitektur und Einsatzbeispiel In Kapitel 2 wurden die aus strukturellen Anforderungen und dem Begriffsrahmen des AIIM- ECM-Modells abgeleiteten Grundelemente der Referenzarchitektur hergeleitet und dargestellt. Nun soll darauf aufbauend eine vollständige, den Gesamtkontext der Rahmenarchitektur IT- Steuerung Bund berücksichtigende, Referenzarchitektur dargestellt werden. Die grundlegende Überlegung ist, dass ein DMS als Basisdienst von anderen Fach-, Querschnittsund Basisdiensten verwendet werden kann. Dienste sind in diesem Sinne zunächst logische Konstrukte, die durch entsprechende IT-Lösungen oder Komponenten realisiert werden. Die wichtigsten Basis- und Querschnittsdienste der Bundesverwaltung sind in einem gemeinsamen Bebauungsplan dokumentiert (vgl. [6]). Abbildung 8 zeigt eine Erweiterung der in Abbildung 5 aufgezeigten Referenzarchitektur (bzw. deren Grundelemente) um Fach-, Querschnitts- und weitere Basisdienste. Eine Integration direkt über Standard-Schnittstellen wird bei diesen Diensten nur im Ausnahmefall sinnvoll gelingen. Für solche Schnittstellen sind i. d. R. fachliche Standards festzulegen und wenn möglich durch die gesamte Bundesverwaltung zu nutzen. Abbildung 8: Vollständige Referenzarchitektur für den DMS-Basisdienst Die in Kapitel 2.5 aufgeführten Standard-Schnittstellen sind i. d. R. als sehr spezifische Application Programming Interfaces (APIs) realisiert und unterstützen in dieser Form nur einen hohen Kopplungsgrad. Für die Anbindung von Fach- und Querschnittsdiensten ist jedoch ein geringerer Kopplungsgrad empfehlenswert (lose Kopplung), um u. a. die gegenseitigen Abhängigkeiten

25 Kapitel 3: Vollständige Referenzarchitektur und Einsatzbeispiel 22 und damit den Komplexitätsgrad der behördenweiten Gesamtarchitektur zu reduzieren. Eine sinnvolle Integration erfolgt zweckmäßigerweise so, dass auf Basis der Standard-Schnittstellen fachlich motivierte Interfaces konzipiert und realisiert werden, die passgenau auf die (Behörden-) individuellen Fach- und Querschnittdienste abgestimmt sind. Diese Interfaces sollten im Kontext einer Service-orientierten Architektur (SOA) realisiert werden (vgl. Abbildung 8, oben; [7]). Die konkrete Kopplung der SOA-Services, die die Funktionalitäten und technischen Schnittstellen abstrahieren und den anderen Diensten, kann auf direktem Wege oder unter Verwendung von Integrationsplattformen erfolgen (z. B. Enterprise Service Bus). Ein wesentlicher Nutzen der Referenzarchitektur ist die transparente Beschreibung des gewünschten Einsatzszenarios für die elektronische Verwaltungsarbeit. Es beantwortet die Frage: In welchem technischen Kontext soll das DMS/VBS eingesetzt werden? Soll es z. B. gleichzeitig kollaborative Funktionen enthalten und Workflows abbilden oder soll es sich auf klassisches Dokumentenmanagement konzentrieren. Abbildung 9: Einsatzszenario Kollaborationssystem plus DMS Außerdem ist damit darstellbar, mit welchen Produkten welche Grundelemente der Referenzarchitektur abgedeckt werden sollen. So können ggf. Lücken oder Überschneidungen feststellt werden. In die Darstellung können zudem die relevanten Schnittstellen-Standards aufgenommen werden.

26 4 Fazit Abbildung 10: Leitgedanken zur Referenzarchitektur Die Leitgedanken des vorliegenden Dokuments sind in Abbildung 10 visualisiert. Sie können wie folgt zusammengefasst werden: Das Organisationskonzept elektronische Verwaltungsarbeit bietet neuen Spielraum für die technische Umsetzung eines Basisdienstes E-Akte. Die Beachtung internationaler Standards für ECM/DMS (AIIM, MoReq2010, DoD5015) bzw. deren Referenzieren bei Ausschreibungen soll helfen, interoperable und zukunftsfähige Produkte einzusetzen. Anforderungen sind modular anhand der Grundelemente der Referenzarchitektur zu bündeln. Damit kann die DMS-Lösung aus Komponenten unterschiedlicher Hersteller je nach Einsatzszenario und betrieblichen Rahmenbedingungen zusammengestellt werden. Zudem kann die DMS-Lösung auf die jeweilige Rolle zugeschnitten werden. Konzeptionell ist der komplette Lebenszyklus eines Dokuments zu betrachten. Dies umfasst die Vor-Phase Informelle Bearbeitung und die Nach-Phase Archivierung. So werden ganzheitliche Lösungen möglich, in denen Anforderungen aus allen Phasen einfließen können und Medienbrüche und redundantes Speichern von Dokumenten vermieden werden.

27 Kapitel 4: Fazit 24 Alle modernen Quellen von Dokumenten sind zu berücksichtigen und im Idealfall direkt anzubinden (Mail, Blog, Wiki etc.). Die Arbeitsbedingungen und die eingesetzten Werkzeuge sind in den letzten Jahren und in Zukunft starken Änderungen unterworfen. Der Anwender möchte nicht über Umwege erst Textdokumente erzeugen müssen, um diese dann verakten zu können. Es sind Schnittstellen zu nutzen, die offenen Standards folgen (WebDAV, CMIS, IMAP), damit die Interoperabilität zwischen den DMS-Produkten und den angebundenen Systemen gewährleistet ist.

28 5 Verzeichnisse 5.1 Abbildungsverzeichnis Abbildung 1: Bausteine des Organisationskonzepts elektronische Verwaltungsarbeit... 5 Abbildung 2: Lebenszyklus von elektronischen Dokumenten, Vorgängen und Akten... 6 Abbildung 3: Hauptbedarfe der elektronischen Verwaltungsarbeit nach Rollen...10 Abbildung 4: ECM-Modell nach AIIM (übersetzt aus dem Englischen)...12 Abbildung 5: Konzeptioneller Architekturrahmen mit AIIM-ECM-Modell...13 Abbildung 6: Grundlegende Referenzarchitektur für den DMS-Basisdienst...15 Abbildung 7: Referenzarchitektur mit Standardschnittstellen...17 Abbildung 8: Vollständige Referenzarchitektur für den DMS-Basisdienst...21 Abbildung 9: Einsatzszenario Kollaborationssystem plus DMS...22 Abbildung 10: Leitgedanken zur Referenzarchitektur Tabellenverzeichnis Tabelle 1: Charakterisierung der ECM-Bereiche nach AIIM Literaturverzeichnis [1] Association for Information and Image Management, AIIM - The Global Community of Information Professionals, [Online]. Available: [Zugriff am ]. [2] Modular Requirements for Records Systems, MoReq 2010, [Online]. Available: [Zugriff am ]. [3] Department of Defense Chief Information Officer, "Electronic Records Management Software Applications Deisgn Criteria Standard," Department of Defense, Washington, [4] Bundesministerium des Innern, Organisationskonzept elektronische Verwaltungsarbeit: Baustein E-Akte, Bundesministerium des Innern, Berlin, [5] Bundesamt für Sicherheit in der Informationstechnik, BSI Technische Richtlinie 03125: Beweiswerterhaltung kryptographisch signierter Dokumente, Bundesamt für Sicherheit in

29 Verzeichnisse 26 der Informationstechnik, Bonn, [6] Rat der IT-Beauftragten, IT-Rahmenkonzept des Bundes für das Haushaltsjahr 2014, Bundesministerium des Innern, Berlin, [7] Die Beauftragte der Bundesregierung für Informationstechnik, Ableitung von Diensten aus Geschäftsprozessen: Methodischer Leitfaden der Rahmenarchitektur IT-Steuerung Bund, Bundesministerium des Innern, Berlin, Abkürzungsverzeichnis Akronym Beschreibung AIIM Association for Information and Image Management: internationaler Branchenverband, der sich mit Informationsmanagement beschäftigt API Application Programming Interface: Programmierschnittstelle BPM Business-Process-Management: Steuerung von Geschäftsprozessen BSI Bundesamt für Sicherheit in der Informationstechnik DM Dokumenten-Management: Komponente der Schriftgutverwaltung, hier ist das Verwalten von Schriftgut (Dokumente und andere Informationsträger) gemeint. DMS Dokumenten-Managementsystem DoD Department of Defence, das amerikanische Verteidigungsministerium hat einen weltweit verbreiteten Standard für DMS herausgegeben: DoD DOMEA Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang : vom OeV abgelöstes Fachkonzept für DMS/VBS in der Bundesverwaltung ECM Enterprise-Content-Management: Konzept zur übergreifenden Verwaltung von Dokumenten und Inhalten in Unternehmen und Behörden EGovG Gesetz zur Förderung der elektronischen Verwaltung (E-Government-Gesetz EGovG) GSB Government Site Builder: WCM-System in der Bundesverwaltung HCR Handwritten Character Recognition: Handschrifterkennung ICR Intelligent Character Recognition: Kontextanalyse zur Korrektur der OCR- Ergebnisse MoReq Modular Requirements for Records Systems, in der Version MoReq2010, europäisches Anforderungskonzept für DMS

30 27 Anhänge und Verzeichnisse Akronym OCR OeV PIM ReV RM SAGA SOA VBS WCM WF zda Beschreibung Optical Character Recognition: Optische Zeichenerkennung, Texterkennung Organisationskonzept elektronische Verwaltungsarbeit (Mai 2012) herausgegeben vom Bundesministerium des Innern Personal Information Manager: Software, mit der persönliche Daten verwaltet werden (Kalender, Aufgaben, Kontakte, s, SMS etc.) Referenzarchitektur elektronische Verwaltungsarbeit, dieses Dokument Records Management: Komponente der Schriftgutverwaltung, hier ist die Verwaltung von Regeln zum Arbeiten mit Schriftgut gemeint. Das Arbeiten mit dem Schriftgut fällt dem DM zu. Standards und Architekturen für egovernment-anwendungen Serviceorientierte Architektur: Softwarearchitekturkonzept Vorgangsbearbeitungssystem Web-Content-Management, Netzinhalte verwalten Workflow: durch ein IT-System gesteuerter Prozess zu den Akten : Verfügung zur Beweissicherung. Es beginnt die Aufbewahrungsphase