Am 8.Juni 2011 veröffentlichte das DLM Forum die Core Services und Plug-in Module für die  Modular Requirements for Record Systems (MoReq2010®) Spezifikation für  elektronische  Records Management Systeme (ERMS). Kaum veröffentlicht, spalten sich die Meinungen hinsichtlich Funktionalität und Nützlichkeit des neuen Standards. Ist eine Neu-Vermessung der ERM-Systeme notwendig, oder wird mit MoReq2010 lediglich ein weiterer  Records Management – Standard übers Knie gebrochen?

Was ist MoReq2010?

Im Herbst 2009 wurde vom DLM-Forum und dem MGB Moreq Governance Board  eine Überarbeitung von MoReq2 beschlossen. Der überarbeitete Standard trägt die Bezeichnung MoReq2010. MoReq2010 wurde in zwei Schritten öffentlich zur Diskussion gestellt. Die neue Version der Spezifikation orientiert sich stärker an den heute verfügbaren Technologien des elektronischen Dokumentenmanagements und hat sich deutlich von den eher papierorientierten Vorläuferstandards entfernt.

Am 8. Juni 2011 wurde die MoReq2010 Spezifikation  als PDF veröffentlicht. Es handelt sich dabei um die "MoReq2010 Modular Requirements for Records Systems, Volume 1, Core Services & Plug-in Modules, Version 1.0". Diese Version ist noch nicht vollständig und soll um weitere Module ergänzt werden. Die Bezeichnung MoReq wurde mit MoReq2010 auch neu interpretiert. Stand MoReq ursprünglich für „Model Requirements for Electronic Records Management“ so wird heute MoReq für „Modular Requirements for Records Systems“ verwendet. Auch die Änderung des Akronyms verdeutlicht den Wandel.

Die neue Spezifikation bricht mit einer Reihe von Prinzipien des Records Management, die noch MoReq2 dominierten. MoReq2010 ist modularer und als Services strukturiert. Der Titel der 520-seitigen Spezifikation wurde der veränderten Zielrichtung angepasst. In 2011 wird mit der Publikation weiterer Module, von Schulungsprogrammen und eines Zertifizierungsverfahrens für Records-Management-Softwareprodukte gerechnet.

Die vorerst gültige Fassung der MoReq2010 Spezifikation folgt auf zwei öffentliche Konsultationen, die über 500 Kommentare und Beiträge von Einzelpersonen, von Experts Review Groups Europäischer  Kommissionen, Anbietern und Verbänden hervorriefen. MoReq ist eine der wichtigsten Spezifikationen für elektronisches Dokumenten- und Records Management in Europa, die sowohl funktionale als auch nichtfunktionale Anforderungen an Records-Management-Systeme beschreibt und gleichermaßen für Organisationen des öffentlichen und privaten Sektors gültig ist. Der Vorgängerstandard MoReq2 wurde allerdings nicht sehr gut angenommen.

Unterschiede zwischen MoReq2010 und MoReq2

Frühere Versionen von MoReq (MoReq, heute meistens als MoReq1 bezeichnet, und MoReq2) waren darauf ausgerichtet alle Records Management-Anforderungen in jedem Bereich eines jeden Unternehmens zu erfüllen.  Sie schufen die Idee des Informationssystems namens EDRMS (Electronic Document and Records Management Systems), das auch den Lebenszyklus von Informationsobjekten vor dem Records Management (Dokumentenmanagement) und nach dem Records Management in der elektronischen Archivierung abdeckt. Die Idee von MoReq2010 ist, dass ein EDRM-System allen Arten von Benutzern einfach zugänglich gemacht  werden sollte. Ziel war dabei, alle Formen von Arbeitsprozessen in der öffentlichen Verwaltung, in Unternehmen und allgemeinen Organisationen abzudecken. Content, Daten, Dokumente und E-Mails, die als Records wichtig sind, werden innerhalb des Electronic Records Management Systems erfasst, verwaltet und aufbewahrt. MoReq und MoReq2 waren auf die Umsetzung traditioneller Records Management Prinzipien und Verfahren ausgelegt. Hierzu gehörten Konzepte, wie der Aktenplan und hierarchische Klassifikationsschemata.

Die Vorgängerversion von MoReq2010, die 2008 veröffentlichte MoReq2 Spezifikation, war im Vergleich mit MoReq1 bereits ein substanziell  verbesserter und an die elektronische Schriftgutverwaltung angepasste Richtlinie für das Records Management, der zahlreiche andere Standards inkorporiert. MoReq2 beinhaltet ein differenziertes Metadatenmodell, XML-Schemas und ein Test-Framework. Letzteres machte eine offizielle Zertifizierung von ERM-Systemen erst möglich. MoReq2 beinhaltet obligatorische und optionale Anforderungen.

MoReq2010 setzt dagegen auf modulares Konzept, dass sich an einer SOA (Service Oriented Architecture) orientiert. MoReq2010 soll so eine größere Variabilität für unterschiedliche Anwendungsfelder und Größenordnungen von Records Management Lösungen bieten. Dies schlägt sich in einem neuen Konzept für Records Management nieder, das allerdings in der traditionellen Gemeinschaft der Records Manager, Dokumentare und Archivare bisher nicht auf große Akzeptanz gestoßen ist. Dies erklärt auch die langen Abstimmungsprozesse, die zur 6-monatigen Verspätung der Veröffentlichung von MoReq2010 führten.

MoReq2010 ist in Version 1.0 noch nicht vollständig, es fehlen noch weitere Module. Besonders wird das Fehlen von XML-Schema, Schnittstellenstandards (z.B. CMIS) und Testkriterien bemängelt. Ein weiteres Problem dürfte die Abwärtskompatibilität von MoReq2010 zu MoReq2 sein. Die Unterschiede in der Architektur sind erheblich. Viele Funktionen, die detailliert in MoReq2 als obligatorisch vorgesehen sind, gibt es in MoReq2010 nicht oder handelt sich um optionale Module. Zumindest für das umfangreiche MoReq2 Datenmodell, das sich an ISO 23001 orientiert, soll es ein Mapping geben.

Wesentliche Konzepte von MoReq2010

Die Einführung eines Service-orientierten Architekturmodells

Alle Anforderung sind innerhalb der MoReq2010 Kernanforderungen in zehn Dienste (Services) gebündelt. Ein MoReq2010 konformes System wird in der Lage seine Funktionalitäten als Dienste anzubieten, die von einem oder mehreren Informationssystemen gleichzeitig innerhalb einer Organisation benutzt werden können.

Zehn funktionale Grundmodule

Ein MoReq2010 konformes System muss den zehn grundlegenden funktionalen Anforderungen gerecht werden und diese anbieten können:

• Ein Records Service, der die Fähigkeit besitzt aggregierte Records zu verwalten.
• Ein Metadaten Service, der die einzelnen Metadatenobjekte innerhalb des Sys-tems managed.
• Ein Klassifikationssystem, das zum einen fähig ist die Records ihren jeweiligen Aggregaten/Ansammlungen von Datensätzen zu zuordnen und zum anderen Hinweise auf Regeln für die Speicherung enthält (retention rules).
• Ein Entsorgungs-, bzw. Disposal-Service, der zwar die Regeln zur Speicherung von Records befolgt, dies aber in Übereinstimmung mit den Regeln für die Entsorgung oder Vernichtung von Records durchführt.
• Die Möglichkeit dem Disposal-Service Ausnahmeregeln hinzuzufügen, die eine potenzielle Erhaltung von Records für Rechtsstreitigkeiten etc. ermöglicht.
• Eine ausgereifte Suchfunktion, die das schnelle Auffinden von Records und der dazugehörigen Metadaten aufgrund einer spezifischen Anfrage sichert.
• Ein Einzelnutzer- und Gruppen-konformer Berechtigungs-Service, der Informatio-nen über die Nutzer und ihre Zugangsberechtigungen enthält.
• Ein Rollenzuweisungsservice, der Zugangsberechtigungen und Aufgaben der Nutzer koordiniert.
• Ein allgemeiner System-Service, der die Pflege der Historie (Event Histories), und Beziehungen der einzelnen Entitäten ermöglicht.
• Ein Export-Service, der Records mitsamt ihrer Metadatenstrukturen und Metada-ten in andere Systeme transferiert, so dass andere MCRS die Daten interpretieren können (XML)

Ein besonderes Merkmal – Verzicht auf eine primäre Klassifikation

MoReq2010 beabsichtigt keine primäre Klassifikation der Records im Sinne einer grundlegenden Hauptklassifikation. Stattdessen wird ein Record einer Klassifikati-onsebene zugeteilt und erbt die Retention Rules dieser Ebene. Für Nutzer mit ent-sprechenden Berechtigungen sind diese Zuweisungen modifizierbar und die Records können anderweitig zugeordnet werden und andere Aufbewahrungsregeln zugeteilt bekommen.

Die 10 Grundmodule und Services von MoReq2010

1.  System Services

1.1  Servicebasierte Architektur

Die funktionalen Anforderungen von MoReq2010 beinhalten insgesamt neun Service Definitionen, die dem neu definierten „MoReq2010 Compliant Records System“ (MCRS) entsprechen. Ob als einzelne Applikation, eine eng integrierte oder eine separate Sammlung von integrierten Dienstleistungen, alle MCRS Lösungen müssen gegen die gleichen Compliance-Kriterien getestet werden.

1.2  Model Services und Plug-in Modules

Zwei der wesentlichen Services von MoReq2010 sind Model Services. Das bedeutet, dass die einzelnen funktionalen Anforderungen und Dienste von MoReq2010 nicht unbedingt von den Anbietern in ihren Produkten umgesetzt werden müssen aber adaptiert  werden können, für den Fall, dass der Anbieter an einem der fortgeschrittenen Services, wie z.B. dem Import Service, interessiert ist. Die Plug-In Elemente von MoReq2010 ermöglichen eine zusätzliche individuelle Umsetzung des Standards.

1.3  Die Anwenderoberfläche

MoReq2010 ist sowohl auf die direkte Interaktion der Nutzer via GUI (Graphical User Interface), als auch auf den Zugang via API (Application Programming Interface) ausgerichtet. Das MCRS ermöglicht die simultane Anwendung unterschiedlicher Interface-Typen. Diese Funktion kann vor allem nützlich sein, wenn es sich bei dem Nutzer um keine Person, sondern um ein automatisch arbeitendes Business Sys-tem handelt. Weitere wichtige Bestandteile der System Services sind die Entity types and sub-types, Event Histories, Zeitstempel und ein universeller Sprachen Support.

2.  Benutzer, Rollen und Berechtigungen

Corporate Directory Service oder eines benutzerdefinierten Verzeichnis-Dienstes, der in das MCRS integriert ist. Abgesehen von den grundlegenden Konzepten be-züglich der Benutzer und einer Gruppe, sieht MoReq2010 keine Weiteren Eingriffe in die individuelle Systemverwaltung vor.

2.1  Berechtigungsanforderungen an das Records Management System

MoReq2010 erfordert, dass die MCRS zusätzliche und stabile Daten über Benutzer und Gruppen einschließlich historischer Informationen enthält. Dazu gehört vor allem das Erstellen von Datensätzen, die alle Nutzer und Nutzergruppen innerhalb des MCRS abbilden, indem  universelle MoReq2010 – System-IDs verwendet werden. Abgesehen davon wird das Nachverfolgen von Änderungen an den Metadaten angestellt,  der Entitäten und Aufbewahrung von Informationen sowie die Aufbewahrung von Informationen durch die Auflösung von Nutzer-IDs und Gruppen anstatt sie ganz aus dem System zu löschen, wenn sie nicht mehr aktiv sind (Lifecycle of an entity).

2.2  Many – to – many – Relationship der Nutzer

Die Beziehungen innerhalb des MCRS lassen es zu, dass jeder Nutzer zu vielen Gruppen gehören kann und ebenso viele Nutzer zu der gleichen Gruppe gehören können (siehe Abbildung 2).

2.3  Zugangskontrollen durch Rollendefinition

Durch eine eindeutige Rollenzuweisung innerhalb des Systems sowie die Vergabe von Autoritäten, wird ein kontrollierter Umgang mit den Datensätzen gewährleistet. Damit sich mehrere autorisierte Personen bei der Bearbeitung von Daten nicht in die Quere kommen, werden zusätzlich Rollen definiert, in denen fest gelegt wird, welcher Nutzer welche Funktion innerhalb des Systems einnimmt. Die Rollen können mit samt ihrer Funktionen „vererbt“ werden. Des Weiteren werden sie in administrative- und nicht-administrative Rollen unterschieden.

3.  Klassifikation von Records

Die Klassifikation von Records bedeutet in MoReq2010, dass jedes Record mit einer klassifizierten Entität assoziiert werden muss. Records können in aggregierten Sta-peln aufbewahrt werden und als Ansammlung oder einzelner Datensatz innerhalb des Systems bewegt werden, unabhängig davon, ob es sich um homogene Inhalte, also solche, die zur gleichen Business Klassifikation gehören, oder nicht. Die Klassifikationen sind ähnlich, wie die Rollen vererbbar (siehe Abbildung 3).

Ein typisches dreistufiges Klassifikationsschema kann durch Business – Funktionen organisiert werden, und dann innerhalb jeder Funktion durch die Business – Aktivität selbst und schließlich innerhalb einer jeden Aktion durch eine Transaktion. Ein dreistufiges Klassifikationsschema ist die übliche Vorgehensweise für funktionale Klassifikationssysteme. MoReq2010 begrenzt die maximale Tiefe eines hierarchischen Klassifikationssystems nicht und erlaubt die variable Anwendung von den einzelnen Anzahlen der Levels.

4.  Record Service

Der Record Service übernimmt innerhalb des MCRS das Managen der Records, das heißt die einzelne Zuordnung der Dateien sowie das Management der aggregierten Stapel. Hierbei werden automatische Restriktionen vorgenommen, wenn der Nutzer beispielsweise ein Record außerhalb eines Stapels ablegen möchte, zu dem es aber ursprünglich gehört.

5.  System-Metadaten und kontextuelle Metadaten

Die System-Metadaten beinhalten ausschließlich die Metadatenelemente, welche für die Erfüllung der funktionalen Anforderungen von MoReq2010 benötigt werden. Abgesehen von den technischen Metadaten werden kontextuelle Metadaten vergeben, die sich unmittelbar auf die Inhalte der Records beziehen. Die Vergabe von Metadaten erleichtert den Umgang mit den Records innerhalb des MCRS allgemein, insbesondere aber das Retrieval. MoReq2010 beinhaltet einen Metadaten-Service, der Entitätstypen und ihre dazugehörigen Metadaten – Element – Definitio-nen verwaltet. Der Metadaten-Dienst kann aufgeteilt und gleichzeitig von mehreren Records Management Systemen oder Business – Systems verwendet werden. Es kann aber auch komplett in eine bestimmtes Records Management System integriert werden, so dass es nicht von dem MCRS als Ganzes unterscheidbar ist.
 
6.  Das MoReq2010  Record Lifecycle Management

In MoReq2010 werden Aufbewahrungs- und Entsorgungspläne verwendet, um den Lebenszyklus von Datensätzen in allen MCRS Lösungen zu verwalten. Grundsätzlich verschwinden im RMCS die Records trotz Löschen nie vollständig, denn es wird immer zum einen ein „Beleg“ für die Existenz des Records aufbewahrt und zum anderen eine ordnungsgemäße Entsorgung dokumentiert. Der eigentliche Inhalt und die Datei an sich können aber eliminiert werden.

Des Weiteren sind an dieser Stelle die Entsorgung Zeitpläne und Entsorgung Aktionen, die Berechnung der Aufbewahrungsfrist, die Bestätigung der Verfügbarkeit eines Records, der
dauerhafte Speicherzyklus, der Rückblick auf den Lebenszyklus (Lifecycle), der Transfer und die Auflösung dessen wesentlich von Bedeutung.

7.  Disposal Holding Service

Das Disposal Holding (z.B. auch für Legal Hold, der dynamisch und unabhängig von vorgegebenen Aufbewahrungs- und Vernichtungsfristen gesetzt werden können muss) vermeidet die unzulässige Vernichtung von Records im MCRS an der Stelle, an der der Nutzer diese zur Vernichtung frei gibt. Disposal Holds sollen so die vorschnelle Vernichtung, Veränderung und Umplatzierung von Records vermeiden, ehe diese nicht automatisch vom MCRS entsorgt wurden.

8.  Searching and Reporting Service

Es gibt zwei Methoden, die Nutzer zur Wiederauffindung von Entitäten im MCRS einsetzen können: zum einen durch das browsen von einer Entität zu verwandten Entitäten (zum Beispiel Eltern/Kind – Verwandtschaft, von Nutzern zu ihren übergeordneten Gruppen, von Records zu ihrer übergeordenten Komponente usw.), zum Anderen kann der Nutzer alternativ eine spezifische Suchabfrage machen und so zu der gewünschten Entität gelangen. Im Prinzip handelt es sich um die Navigation in Strukturen, die Suche über Metadaten, die Volltextsuche und Enterprise Search, die aber nicht konkret differenziert werden.

9.  Export Service

Bei dem Export von Records handelt es sich um den Vorgang, bei dem Entitäten von einem MCRS zum anderen transferiert werden können, ohne dass die Metadaten-Werte, die Event Histories, die Zugangskontrollen und der Inhalt der Records verloren gehen. Dies geschieht in Form von einer detaillierten Abbildung der Entitäten auf ein XML-Datenformat, welches von MCRS zu MCRS bewegt werden kann. Hier setzt der eigentliche Standardisierungsanspruch bei  Austausch von Informationsobjekten einschließlich Struktur und Metadaten an. Das vorgesehene XML-Schema hat daher einen anderen Charakter und einen anderen Nutzungsanspruch als das XML-Schema von MoReq2.

10.  Komponenten und Container

Einige Records können Inhalte haben, die geteilt oder unterbrochen sind und in mehrere Datenbestandteile geteilt sind. IN einem MCRS werden diese Records aus mehreren Informationsobjekten zusammengesetzt, wobei jedes Bestandteil mit seinem benachbarten Bestandteil in Verbindung gesetzt wird. Die Zusammenhän-genden Inhalte könne in einer gemeinsamen Datenablage gespeichert werden (siehe Abbildung 5).

Die Aggregationen bilden dabei ein abgewandeltes Containerkonzept. Bei anderen Records-Management-Ansätzen stellen solche Container eigenständige Informationsobjekte dar, die über einen eigenen Satz von Metadaten verfügen oder über die Metadaten der enthaltenen Records selbst virtuell Container bilden. Der Ansatz mit Aggregationen zu arbeiten, ist im traditionellen Records Management nicht vorhanden. Hier werden hierarchische Einheiten verwendet, z.B. in MoReq2 Folder, File, Volume etc.

Zukünftige Entwicklungen von MoReq2010

MoReq2010 basiert auf einer modularen Struktur und das DLM Forum plant zukünf-tig die Erweiterung der Module um zusätzliche Möglichkeiten für Records-Management-System-Anbieter zu schaffen. Hierzu sind weitere Services aber auch Plug-In-Module denkbar. Die ersten Erweiterungen der Module für MoReq2010 sind für Dezember 2011 vorgesehen. Im Gegensatz zu den Core Requirements werden die zusätzlichen Module nicht verpflichtend für die Anbieter sein, sondern zur freiwilligen Implementierung vorgesehen.

Folgende Zusatzmodule sind derzeit geplant:

• Import-Service, der den Import von Records inklusive ihrer Metadaten ermöglicht, so dass die Daten von dem MCRS interpretiert werden können. Ein Import-Service ist aus dem Grund nicht in den Core Requirements zu finden und wird erst „nachgeliefert“, weil davon ausgegangen wird, dass die Anwender der MCRS diese zum ersten Mal implementieren und der Bedarf Daten zu importieren daher nicht vorhanden sei. Dieser stellt das Äquivalent zum Export-Service dar und muss das gleiche Schema nutzen.
• Module, die Abwärtskompatibilität  zu  MoReq2 unterstützen, da in einigen Euro-päischen Ländern die Kompatibilität von neuen Systemen nach MoReq2010 mit MoReq2 aus rechtlichen Gründen oder sogar gesetzlichen Vorgaben notwendig ist, wie z.B. Tschechische Republik oder Slowenien. Von mehreren Organisatio-nen wird nicht nur ein Mapping des Datenmodells und eine Export-/Importschnittstelle gefordert, sondern auch die Sicherstellung der obligatorischen Funktionalität.

Weitere geplante Aktivitäten seitens des DLM Forums zur Förderung und Weiterentwicklung des MoReq2010 Standards sind:

• Die Veröffentlichung der Test Center Akkreditierungen und Zertifizierungsprozesse der MGB Testing Group
• MoReq2010 Trainings – Programme, die durch die National-Archive und Ausbil-dungsorganisationen in ganz Europa geplant sind
• Auch MoReq2010 soll gegebenenfalls übersetzt werden. Maßgeblich – besonders für Test und Zertifizierung – wird aber immer die englische Version der Spezifikation bleiben (derzeit laufen die MoReq2-Übersetzungsprojekte weiter).

Jon Garde, der Verfasser der MoReq2010 Spezifikation, sieht für die Zukunft zudem Module, die das Cloud Computing berücksichtigen und die auf Mobile Devices und Social Software eingehen können (Vortrag auf dem DLM Forum Member Meeting am 13.0.52011). Er forderte jeden auf, der individuelle Bedürfnisse hinsichtlich weiterer Module hat, beispielsweise spezielle Branchen wie das Gesundheits- oder Finanzwesen, hierfür Vorschläge zu unterbreiten. Konkret soll auch eine Gruppe für die Abbildung der Anforderungen der Pharma-Industrie ins Leben gerufen werden.

Es besteht auch die Möglichkeit, Module und Schnittstellen zu entwickeln, die die Kompatibilität von MoReq2010 mit anderen Standards und Spezifikationen ermöglichen, wie zum Beispiel der US-Amerikanischen Records Management Spezifikation DoD 5015.2. Hier gab es bereits eine Diskussion im Internet, die nachfragte, ob MoReq2010 auch DoD 5015.2 ersetzen könne . Hiervon ist aber die noch nicht fertige MoReq2010 Spezifikation noch weit entfernt .

Von einem konsolidierten Stand kann man erst ausgehen, wenn sich die Europäische Kommission entschließt, auch MoReq2010 zu drucken. Bisher gibt es die Spezifikation nur elektronisch und ohne offizielle ISBN der Europäischen Kommission. Dies unterstreicht, dass die Diskussion um die Spezifikation noch nicht abgeschlossen ist. Zumindest auf der eigens eingerichteten Diskussionsplattform  des DLM Forums wird eifrig weiter diskutiert. Dies ist positiv zu bewerten, denn trotz der langen Wartezeit und der elementaren Änderungen im MoReq-Records-Management-Konzept setzt sich nunmehr die Branche mit der Spezifikation auseinander.