Im Newsletter 20080630 haben wir in einem ausführlichen Artikel dargestellt, was zu einer Verfahrensdokumentation gehört und wie man diese am besten anlegt.
Für die Erstellung von Verfahrensdokumentationen gibt es unterschiedliche Ansätze: die Einen arbeiten mit Word-Vorlagen oder Excel-Templates, Andere bauen sich eine Notes-Datenbank auf, Dritte kaufen sich ein kleines Spezialwerkzeug, z.B. von H+P (http://www.h-und-p-consulting.de/) oder Vater Procon (http://www.docsetminder.de/) eine Anwendung zur Erstellung und Pflege von Verfahrensdokumentationen), wiederum Andere integrieren das Thema Verfahrensdokumentation in Ihre IT-Governance-Ansätze und nutzen ITIL-Werkzeuge. Alle Ansätze haben einen entscheidenden Nachteil: sie erfordern eine aufwändige Ersterstellung und eine ständige manuelle Nachpflege.
Ich persönlich favorisiere seit Jahren einen ganz anderen Ansatz – selbstdokumentierende Systeme. In GRC-Infrastrukturen (Governance, Risk Management & Compliance) werden automatisiert Protokolle erstellt, professionelle ECM-Systeme verwalten ihre Konfigurations-, Parameter-, Berechtigungs- und Ablagestrukturen sowie andere Informationen datenbankgestützt – diese Informationen gilt es zu nutzen. Alle systemseitig verfügbaren Daten sollten in vorbereitete Strukturen einer Verfahrensdokumentation automatisiert eingeladen, versioniert und historisiert werden. Die Anwender müssten in dieser vorbereiteten Anwendung "nur" ihre allgemeinen Informationen eingeben und die beteiligten, auszuwertenden Systemkomponenten festlegen. Ein Großteil der manuellen Fortschreibung der Verfahrensdokumentation entfällt, da Veränderungen automatisch erkannt und aktualisiert (bzw. die zuständigen Anwender über Veränderungen und notwendigen Nachdokumentationsbedarf informiert) werden. Mit geeigneten Werkzeugen kann so aus einer integrierten Verfahrensdokumentationsdatenbank auch entsprechende Reports generiert werden, z.B. durch Werkzeuge von Coextant (http://www.doxtop.com/download.axd?DOC_UNID=20e8cb292cd7421800257478005678c7&pid=f8f48a75), die eine immer aktuelle Verfahrensdokumentation auch in Gestalt von formatierten Dokumenten ausgeben kann. In der ECM- oder GRC-Anwendung würde so eine kleine vorgefertigte "virtuelle Akte"nanwendung im Lieferumfang enthalten sein, in die die Daten des Systems und die vom Anwender eingestellten Informationen zusammenlaufen. Dies können Änderungen an Auswahllisten, Umstrukturierungen im Aktenplan, Geänderte Administrationskomponenten, neue Scanner-Profile, XML-Schemas zu Schnittstellen, Anlegen neuer Tabellen, Änderung von Berechtigungsstrukturen, Einspielen von Updates, Veränderung von Workflow-Prozessen, Anlegen und Löschen von Dokumentenklassen, Umlegung von Speicherpfaden, Auslagerung von Datenbeständen und zahlreiche andere für die Verfahrensdokumentation relevante Informationen sein.
Besonders für SaaS-, ASP- und Mandanten-Systeme sind solche automatisierten oder teilautomatisierten Verfahrensdokumentationen essentiell, da der Anwender selbst keine Veränderungen an den Einstellungen und der internen Funktionsweise des genutzten Systems mitbekommt und man bei vielen Mandanten im Betrieb einer größeren Lösung schnell die Übersicht verliert. So ist die teilautomatisierte Verfahrensdokumentation von Nutzen sowohl für die Fachabteilungen wie auch für den IT-Betrieb: fehlerträchtige manuelle Eingaben werden reduziert, Aktualisierungen und Fortschreibung werden automatisiert, die Vollständigkeit und Nachvollziehbarkeit wird sichergestellt. Daher sollten ECM-, Archiv- und Dokumentenmanagement-Lösungen standardmäßig mit einer integrierten Anwendung zur Erstellung und Pflege von Verfahrensdokumentationen ausgeliefert werden. Nur so lässt sich wirklich auf Seiten der Anwender Nachvollziehbarkeit, Vollständigkeit, Aktualität und Revisionssicherheit sicherstellen – und dies mit deutlich verringertem manuellen Aufwand.
Hierfür sind allerdings seitens der Anbieter entsprechende Voraussetzungen zu schaffen. Zum einen ist ein zentrales, datenbankgestütztes Repository notwendig, in dem alle Konfigurationsinformationen zentral verwaltet werden. In diesem sind Systemparameter, beteiligte Anwendungen, Parameter, Berechtigungen, Dokumentenklassen, Aktenstrukturen, Aufbewahrungsregeln etc. vorzuhalten. Diese können dann mit Technologien wie Agenten, BI Business Intelligence und anderen in Bezug auf technische Daten der Systeme ständig aktualisiert und versioniert werden, wohingegen die fachlichen Definitionen wie Berechtigungen, Klassen, Taxonomien, Auswahllisten etc. direkt in dieser Verwaltungsdatenbank gepflegt und von dort aus dem oder den beteiligten Systeme/n bereitgestellt werden. Solche zentralen Repositories für die interne Verwaltung und als Basis der Administrationswerkzeuge für Archiv-, Records- und Dokumenten-Management-Lösungen fehlen bei den meisten Systemen – und damit fehlt auch die Grundlage zur Gewinnung der benötigten Informationen für die automatisch gepflegte Verfahrensdokumentation. Auch wenn verschiedentlich bereits die Forderung nach solchen (teil)automatisierten Verfahrensdokumentationen erhoben wurde, z.B. in meinem Artikel „Verfahrensdokumentation nach GoBS auf Basis selbstdokumentierender Archivsysteme“ in der DoQ aus dem Jahre 2001, in meinem Beitrag „Dokumentationspflichten“ (http://www.doxtop.com/magazines/6607ead5/5359f7f9/13/project-consult-newsletter-2005/ausgabe-20072005/dokumentationspflichten.aspx) oder in den „18 Thesen zur Verfahrensdokumentation“ von Gerhard Schmidt, dem Herausgeber von „Elektronische Steuerprüfung“
(http://www.elektronische-Steuerpruefung.de/verfahrensdokumentation/schmidt_thesen.htm), sieht es im Markt zum Thema selbstdokumentierende Systeme noch sehr „mau“ aus. (Kff)

PROJECT CONSULT Newsletter 20080716