Embed Size (px)
Citation preview
Konzeption einer Dokumentationsrichtlinie für
betriebliche Informationssysteme
Diplomarbeit zur Erlangung des Grades eines Diplom-Wirtschaftsinformatikers an der
Technischen Universität Chemnitz Professur Wirtschaftsinformatik I
Prof. Dr. Bernd Stöckert
Betreut von Herrn Dipl.-Kfm. Uwe Wendt (TU-Chemnitz) und Herrn Dr. Werner Ocker (Siemens Power Generation)
Rainer Fischer
Matrikelnummer: 68666
Zur Kirche 22
04626 Schmölln
Tel: 0160 68 74 984
E-Mail: [email protected]
8. Fachsemester Wirtschaftsinformatik
Abgegeben am 28.09.2006
- I -
Inhaltsverzeichnis
Inhaltsverzeichnis .................................................................................................. I
Abkürzungsverzeichnis ...................................................................................... III
Abbildungsverzeichnis........................................................................................ IV
1 Hintergrund und Überblick ........................................................................1
2 Dokumentenmanagement ............................................................................2
2.1 Begriffsabgrenzung..................................................................................2
2.2 Dokumente im Wissensmanagement.......................................................6
2.2.1 Wissensmanagement ............................................................................................ 6 2.2.2 Dokumente und Wissen ....................................................................................... 9
2.3 Entwicklung der Dokumentenverwaltung .............................................10
2.4 Dokumentenmanagementsysteme .........................................................13
2.4.1 Einordnung......................................................................................................... 13 2.4.2 Ziele und Nutzen ................................................................................................ 14 2.4.3 Dokumente ......................................................................................................... 15 2.4.4 Aufbau................................................................................................................ 17 2.4.5 Funktionen ......................................................................................................... 22
2.5 Einführungsprojekte...............................................................................28
2.5.1 Phasenmodell ..................................................................................................... 28 2.5.2 Randbedingungen............................................................................................... 30 2.5.3 Risiken ............................................................................................................... 31
3 Dokumentation ...........................................................................................34
3.1 Dokumentation technischer Systeme.....................................................34
3.2 Dokumentation betrieblicher Informationssysteme...............................35
4 Dokumentationsrichtlinie ..........................................................................37
4.1 Aufgabe..................................................................................................37
4.2 Einordnung.............................................................................................38
4.3 Besonderheiten.......................................................................................41
4.4 Ziele .......................................................................................................43
4.5 Ist-Analyse .............................................................................................46
4.5.1 Systemlandschaft................................................................................................ 46 4.5.2 Befragung........................................................................................................... 48 4.5.3 Auswertung ........................................................................................................ 51
- II -
4.5.4 Prozesse.............................................................................................................. 55
4.6 Dokumentationskonzept ........................................................................57
4.6.1 Allgemeine Inhalte ............................................................................................. 57 4.6.2 Sichtenkonzept ................................................................................................... 58 4.6.3 Verbindung der Sichten...................................................................................... 62 4.6.4 Dokumentationsarten ......................................................................................... 65 4.6.5 Inhaltliche Festlegungen .................................................................................... 69 4.6.6 Dokumentenstatus .............................................................................................. 73
4.7 Konzeptumsetzung.................................................................................74
4.7.1 Der SAP Solution Manager................................................................................ 74 4.7.2 Dokumentation im SAP Solution Manager........................................................ 77 4.7.3 Grundlegende Konzeptumsetzung ..................................................................... 81 4.7.4 Strukturdefinition ............................................................................................... 81 4.7.5 Inhaltsbezogene Vorgaben ................................................................................. 84 4.7.6 Statuswertschema und Berechtigungen.............................................................. 85
4.8 Migration bestehender Dokumentation .................................................86
5 Ergebnisse und Ausblick............................................................................88
Glossar ..................................................................................................................91
Anhang..................................................................................................................94
Literaturverzeichnis ..........................................................................................160
Versicherung ......................................................................................................163
- III -
Abkürzungsverzeichnis
AIIM Association for Information and Image Management
ASAP Accelerated SAP
CI Codierte Informationen
CIO Chief Information Officer
DMS Dokumentenmanagementsystem
EBP Enterprise Buyer Professional, SAP-System für elektronischen Einkauf
ECM Enterprise Content Management
ERP Enterprise Ressource Planning
GoB Grundsätze ordnungsmäßiger Buchführung
HTML Hypertext Markup Language
IT Informationstechnik
NCI Nichtcodierte Informationen
OCR Optical Character Recognition
PG Power Generation
PKI Public Key Infrastructure
RFC Remote Function Call
SECI Socialisation, Externalization, Combination, Internalization
SOA / SOX Sarbanes Oxley Act
WORM Write Once Read Multiple times, Write Once Read Many
- IV -
Abbildungsverzeichnis
Abbildung 1: Beziehung des Dokumentenmanagement zu anderen Fachgebieten.5
Abbildung 2: Gliederung betriebswirtschaftlicher Anwendungssysteme .............13
Abbildung 3: Verhältnis von Präzision zur Trefferquote ......................................21
Abbildung 4: Komponenten eines Dokumentenmanagementsystems...................22
Abbildung 5: Projektphasen eines Softwareprojektes ...........................................28
Abbildung 6: Organisationsstruktur der Siemens AG ...........................................39
Abbildung 7: Systemlandschaft bei Siemens PG ..................................................47
Abbildung 8: Dominanz des Dateisystems zur Ablage der Dokumentation .........52
Abbildung 9: Anzahl funktional strukturierter Dokumentationsverfahren............54
Abbildung 10: Sichtenkonzept...............................................................................58
Abbildung 11: Ausschnitt einer Geschäftsprozesshierarchie bei Siemens PG......61
Abbildung 12: Schemadarstellung Verknüpfungskonzept....................................63
Abbildung 13: Antizipierte Verwendung der Dokumentationsarten nach Sichten68
Abbildung 14: Statuswertschema ..........................................................................74
Abbildung 15: Darstellung der Funktionalität des SAP Solution Manager...........76
Abbildung 16: Prinzip der strukturunabhängigen Ablage .....................................78
Abbildung 17: Auswahlebenen für Stichwörter und Dokumentationsarten..........80
Abbildung 18: Beispiel einer Strukturdefinition (gekürzt)....................................83
- 1 -
1 Hintergrund und Überblick
Diese Diplomarbeit zum Abschluss des Studiums der Wirtschaftsinformatik an
der Technischen Universität Chemnitz entstand in Zusammenarbeit mit Siemens
Power Generation. Das Thema ging aus einer aktuellen Problemstellung innerhalb
der IT-Abteilung hervor, die im Zuge eines großen Migrationsprojektes die
Dokumentation verschiedener Informationssysteme des Herstellers SAP
vereinheitlichen möchte. Da es sich vorrangig um betriebliche
Informationssysteme handelt, sind betriebswirtschaftliche und informations-
technische Kenntnisse hilfreich. Das Thema bietet sich daher besonders für den
Abschluss eines Wirtschaftsinformatikstudiums an.
Die Arbeit gliedert sich in drei Teile. Etwas mehr als das erste Drittel der Arbeit
widmet sich den theoretischen Grundlagen der beiden Themen Dokumenten-
management und Dokumentation. Im zweiten Teil werden die gewonnenen
Erkenntnisse zu einem Dokumentationskonzept verarbeitet. Dieser kreativ-
theoretische Abschnitt umfasst ein reichliches Drittel und beginnt ab Kapitel 4 mit
einer genauen Untersuchung der Aufgabe und einer umfangreichen Ist-Analyse,
bevor in Kapitel 4.6 das eigentliche Dokumentationskonzept erarbeitet wird. Mit
ungefähr einem Sechstel der Arbeit bildet die Beschreibung der praktischen
Umsetzung ab Kapitel 4.7 den kleinsten Teil, bevor zum Abschluss die
Ergebnisse und ein Ausblick präsentiert werden. Neben der Diplomarbeit selbst
entstanden viele weitere Dokumente zur Lösung der Aufgabe. Ein kleiner
Ausschnitt dieser Dokumente befindet sich im Anhang, auf den an passenden
Stellen verwiesen wird.
Die verwendete Literatur entstammt aus verschiedenen angrenzenden Disziplinen,
wodurch oft nur wenige Abschnitte eines Werkes relevant waren. Die Auswahl an
spezifischer Literatur zum Thema Dokumentation betrieblicher
Informationssysteme während der aktiven Nutzung ist beschränkt. Umfangreiche
Werke findet man zu den Themen Softwaredokumentation während der
Entwicklung, Dokumentenmanagement und Projektdokumentation. Nur durch
- 2 -
Kombination dieser Werke konnten die notwendigen Grundlagen erarbeitet
werden.
2 Dokumentenmanagement
2.1 Begriffsabgrenzung
Dokumentenmanagement ist ein Begriff der modernen Wirtschaftsinformatik und
hat keine einheitliche Definition. Gründe dafür sind das Fehlen einer zentralen,
allseits anerkannten Organisation zur Definition der Begriffe und die Veränderung
des Begriffsverständnisses im Laufe der Zeit.
Ohne den Anspruch auf eine allgemeine Gültigkeit zu erheben, wird
Dokumentenmanagement im Rahmen dieser Arbeit als die Schaffung,
Bearbeitung, Steuerung, Verfolgung und Aufbewahrung von Dokumenten über
deren gesamten Existenzzeitraum definiert. Theoretische Ausarbeitungen zum
Dokumentenmanagement beziehen sich dabei oft nur auf die Dokumente selbst,
nicht aber auf deren Inhalt. Das soll an dieser Stelle anders gehandhabt werden.
Dokumente und deren Inhalt werden als Einheit gesehen.
Zum Begriff des Dokuments genügt vorerst die weite Definition als Objekt,
welches zusammenhängende Informationen trägt. Eine engere Fassung des
Begriffs erfolgt im Kapitel 2.4.3 Dokumente, dann aus Sicht der Dokumenten-
managementsysteme1. DMS sind eine Klasse von Anwendungssystemen, die mit
ihren Funktionen das Dokumentationsmanagement ganzheitlich unterstützen.
In Abgrenzung zur Archivierung enthält die Definition des Dokumenten-
managements den Bezug auf den gesamten Lebenszyklus des Dokuments. Archiv-
systeme bilden zumeist nur die letzte Station vor der Entsorgung des Dokuments.
Ein klassisches Archiv nimmt Dokumente also erst dann auf, wenn diese nicht
mehr regelmäßig benötigt werden. Dieser Umstand führt zur Spezialisierung der
1 Dokumentenmanagementsystem wird im Folgenden mit DMS abgekürzt.
- 3 -
Archive auf die Aufnahme großer Dokumentenmengen bei nur vereinzelter
Extraktion.
Im betriebswirtschaftlichen Umfeld gilt das ganz besonders. Hier bestimmen vor
allem gesetzliche Regelungen die Aufbewahrungsdauer eines Dokuments. Ein
frühzeitiges Aussortieren veralteter und nicht mehr benötigter Einträge darf nicht
erfolgen, Unternehmensarchive beinhalten somit eine große Anzahl an
Dokumenten, die im Normalfall nicht wieder gebraucht werden. Viele Archive
stünden deshalb vor einem Performanzproblem, müssten sie auch nur ein Prozent
der enthaltenen Dokumente innerhalb eines Tages ausgeben.
Im Gegensatz dazu zielen DMS darauf ab, Dokumente zu einem möglichst frühen
Zeitpunkt aufzunehmen und sie dann bis zur Vernichtung zu begleiten. Dabei ist
die Ausgabe bzw. Anzeige des Dokumentes im Gegensatz zum Archiv eine der
am häufigsten durchgeführten Aktionen.
Die Frage, ob Dokumentenmanagement den Begriff der Archivierung komplett
einschließt, bleibt umstritten. Je nach Auslegung umfasst der Begriff der
Archivierung mehr als nur die Organisation der Ablage und Herausgabe von
Dokumenten. Beispielsweise werden bauliche Aspekte, wie Einbruchssicherheit
und Feuerschutz, oft der Archivierung, nicht aber dem Dokumentenmanagement
zugeordnet, womit die Begriffe nur eine Schnittmenge besitzen, keiner der
Begriffe aber eine Untermenge des anderen bildet.
Unabhängig von dieser akademischen Diskussion können bei der technischen
Umsetzung Archivsysteme eine Komponente eines DMS bilden. In einem solchen
Fall wird die Archivfunktionalität eingeschlossen und durch Funktionen für den
aktiven Teil des Dokumentenlebens erweitert.
Konträr zur Archivierung ist das Verhältnis des Dokumentenmanagements zum
Workflowmanagement. Workflowsysteme können, je nach Einsatzgebiet,
sämtliche Funktionen eines DMS enthalten. DMS der klassischen Art unterstützen
nur die Arbeitsabläufe in direktem Zusammenhang mit Dokumenten. Eine
- 4 -
explizite Abbildung der Prozesse ist dabei nicht erforderlich. Workflowsysteme
hingegen stellen diese explizite Abbildung von Prozessen in den Mittelpunkt, dies
kann ebenfalls die Gesamtheit der dokumentenbezogenen Prozesse betreffen.
Die Prozesse im direkten Zusammenhang mit Dokumenten werden beim
Workflowmanagement mit Prozessen aus anderen Bereichen verbunden. Diese
Verbindung fällt dabei in den klassischen „Dokumentenverarbeitungsfabriken“2,
wie Banken und Versicherungen, noch weniger ins Gewicht als beispielsweise im
Anlagenbau. In dieser Branche gilt es, dokumentenbasierte und nicht-
dokumentenbasierte Arbeitsabläufe sinnvoll miteinander zu verbinden.
Das Schlagwort Enterprise Content Management erhebt ebenfalls den Anspruch,
das Dokumentenmanagement komplett zu umfassen.3 Die Definition des AIIM
beschränkt sich dabei auf Technologien. In Erweiterung zum Dokumenten-
management ist die Erfassung von Informationen ohne Beschränkung von deren
Form, also der Hinweis auf Dokumente, enthalten. Es wird dabei ein wesentlich
stärkerer Fokus auf den Inhalt und dessen Publikation in verschiedenen Medien
gelegt. Dokumente als Informationsträger treten dabei in den Hintergrund. Sie
bilden nur eines von vielen Medien, in denen die verwalteten Informationen
auftauchen können.
Insgesamt ist eine scharfe Abgrenzung der einzelnen Begriffe schwierig. Selbst
konkrete Softwareprodukte haben trotz überschaubarer Änderungen der
Funktionen einen Wechsel der Bezeichnung mit dem Versionswechsel erlebt. Da
werden aus DMS in der nächsten Version schon ECM-Systeme oder Wissens-
managementsysteme. Ganz entsprechend des aktuellen Zeitgeschmacks existiert
aber auch die Gegenrichtung. So haben Hersteller die Bezeichnung ihrer Systeme
2 Vgl. Klingelhöller, Harald, Dokumenten Management Systeme, Handbuch zur Einführung, Berlin u.a., 2001, S. 15 f. 3 Vgl. AIIM – Association for Information and Image Management, What is ECM?, http://www.aiim.org/about-ecm.asp, It's not enough to "manage" content, [01.07.2006].
- 5 -
ohne Verlust von Funktionalität von Wissensmanagementsystemen zu
Dokumentenmanagementsystemen geändert.4
Abbildung 1 zeigt eine mögliche grafische Darstellung zu den Beziehungen der
einzelnen Begriffe zueinander.
Abbildung 1: Beziehung des Dokumentenmanagements zu anderen
Fachgebieten5
Im Bild fokussiert das Dokumentenmanagement auf den dynamischen Teil des
Dokumentenlebenszyklus und streift dabei die Fachgebiete Workflow-
management und Archivierung. Auf Grund der angedeuteten Form ergibt sich
eine noch stärkere Überlappung des Dokumentenmanagements mit dem Content
Management.
4 Vgl. Götzer Klaus u.a., Dokumentenmanagement, Informationen im Unternehmen effizient nutzen, 3. Aufl., Heidelberg, 2004, S. V. 5 Vgl. Born, Achim / Diercks, Jürgen, Mutationen, Klassische DMS-Anbieter suchen neue Aufgaben, in: iX, Magazin für professionelle Informationstechnik, Jg. 13 (2000), Ausg. 11, S. 84.
Portal/Publikation
Geschäftsprozess
Dynamischer Teil des Dokumentenlebenszyklus
Langzeitarchiv
Workflow-managament
Content-management
Wissens-management
Dokumentenmanagement
Elektronische Archivierung
- 6 -
Ganz im Vordergrund der Abbildung ist das Wissensmanagement platziert. Der
besonderen Beziehung des Dokumentenmanagements zum Wissensmanagement
wird im folgenden Kapitel Rechnung getragen.
2.2 Dokumente im Wissensmanagement
2.2.1 Wissensmanagement
In der englischsprachigen Literatur tritt Knowledge Management bereits in den
achtziger Jahren auf. Anfänglich im Zusammenhang mit künstlicher Intelligenz
verwendet, setzte sich der Begriff im betriebswirtschaftlichen Umfeld erst in der
zweiten Hälfte der neunziger Jahre durch. Der Durchbruch begann 1996 mit
einem starken Ansteigen an Publikationen zu diesem Thema.6 Das Verständnis
des Begriffs Wissensmanagement änderte sich mit der Zeit und ist von Autor zu
Autor verschieden. Um eine aktuelle Definition zu erhalten, lohnt sich die
Referenz auf eine öffentlich bearbeitbare Quelle. Nach Wikipedia ist das Wissens-
management ein Teil der Managementlehre, der auf den Aufbau und die Nutzung
von Wissen in Organisationen abzielt.7
Die Wirtschaftswissenschaften sehen Wissen neben Land, Arbeit und Kapital als
neuen Produktionsfaktor. Dementsprechend hoch ist die Bedeutung des Wissens
in einer wirtschaftlich tätigen Organisation. Um diesen Produktionsfaktor zu
vermehren, muss das Lernen einer Organisation durch geeignete Maßnahmen
gefördert und damit verbundene soziale Hürden überwunden werden.8
6 Vgl. Wilson, Thomas Daniel, The nonsense of ‚knowledge management’, in: Information Research, Jg. 8, Ausg. 1 (2002), http://informationr.net/ir/8-1/paper144.html, What is knowledge management?, [21.07.2006]. 7 Vgl. Wikipedia, Wissensmanagement, http://de.wikipedia.org/wiki/Wissensmanagement, [01.07.2006]. 8 Vgl. Fried, Andrea / Baitsch, Christof, Mutmaßungen zu einem überraschenden Erfolg, Zum Verhältnis von Wissensmanagement und organisationalem Lernen, in: Götz, Klaus (Hrsg.), Wissensmanagement, Zwischen Wissen und nicht Wissen, Seite 33ff.
- 7 -
Wissen steht dabei für Kenntnisse und Fähigkeiten von Menschen und
Organisationen für die Lösung von Problemen.9 Michael Polanyi klassifizierte
Wissen bereits in den fünfziger Jahren des zwanzigsten Jahrhundert in seinem
Werk The tacit dimension nach seinen Erscheinungsformen in implizites und
explizites Wissen. Explizites Wissen ist dieser Klassifikation zufolge
artikulierbar, es kann also von einem Menschen ausgesprochen, niedergeschrieben
oder formalisiert werden. Implizites Wissen bezeichnet im Gegensatz dazu die
Fähigkeiten eines Menschen, die nicht ohne weiteres weitergegeben werden
können. Dazu zählen vor allem methodische Kompetenzen.10
Nonaka und Takeuchi übernahmen diese Einteilung rund vierzig Jahre später und
identifizierten vier Phasen der Wissensschaffung. Damit erschufen die beiden
japanischen Professoren das nach den Phasen benannten SECI-Modell.
Vorhandenes Wissen wird in jeder Phase zu neuem Wissen der gleichen oder
anderen Form spiralartig kumuliert. Die Phase der Sozialisation schafft aus
implizitem Wissen neues implizites Wissen. Externalisierung bringt implizites
Wissen in eine explizite Form. Durch Kombination wird dieses explizite Wissen
zu neuem expliziten Wissen verbreitet und vermehrt, bevor es in der Phase der
Internalisierung durch Menschen zu impliziten Wissen verarbeitet wird.11
Probst identifizierte die sechs Kernprozesse des Wissensmanagements Wissens-
identifikation, -erwerb, -entwicklung, -verteilung, -nutzung und -bewahrung.12
Aus Sicht der Informationstechnologie gilt es, diese Prozesse durch Technik zu
unterstützen oder vollständig abzubilden. Die direkte Unterstützung ist in der
Regel nur auf explizites Wissen beschränkt. Der Umgang mit implizitem Wissen
gestaltet sich aus informationstechnischer Sicht schwierig. Versuche, implizites
Wissen mit Hilfe künstlicher Intelligenz abzubilden, sind im Wissens-
managementumfeld bisher kaum von Bedeutung. Immerhin kann durch
9 Vgl. Probst, Gilbert / Raub, Steffen / Romhardt, Kai, Wissen managen, Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 5. Aufl., Wiesbaden, 2006, S. 22. 10 Vgl. weiterführend Polanyi, Michael, The tacit dimension, New York, 1967. 11 Vgl. Nonaka, Ikujiro / Takeuchi, Hirotaka, Die Organisation des Wissens, Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen, Frankfurt / New York, 1997. 12 Vgl. Probst 2006, S. 28.
- 8 -
Technologieeinsatz eine Verbesserung von Kommunikation und Lernen erreicht
und dadurch die Schaffung von neuem Wissen angeregt werden.
Praktiker sehen das Wissensmanagement oft kritisch. Die Proklamation der
Wissensfokussierung sei in Unternehmen ein reines Mundbekenntnis. Belegen
lässt sich diese Aussage durch verschiedene Studien. Bei einer Befragung von
Managern gaben 80 Prozent an, Wissensmanagement habe bei Ihnen eine hohe
Priorität, jedoch arbeiten nur 30 Prozent an dessen Umsetzung.13 Wird eine
Umsetzung dann doch in Angriff genommen, sind es oft reine IT-Projekte mit
fehlender organisatorischer Integration.14
Noch gewaltiger klafft der Unterschied zwischen Theorie und Praxis laut einer
anderen Studie auseinander. Demzufolge sind neunzehn von zwanzig Führungs-
kräften an Wissensmanagement interessiert. Trotzdem behandeln nur fünf Prozent
der befragten kleinen und mittleren Unternehmen das Thema Wissens-
management in ihrer Weiterbildung.15
Sogar das Wissensmanagement an sich steht in der Kritik. Der Vorwurf lautet, die
Beraterbranche nutze diesen Begriff gewinnbringend für sich selbst und nicht für
ihre Kunden.16 Damit reihe sich das Wissensmanagement in eine Folge von
„Managementmarotten“ ein, die genauso schnell verschwinden, wie sie
gekommen sind.17 Zumindest in der englischsprachigen Literatur ist ein
Aussterben des Begriffes jedoch bisher nicht zu erkennen.18
Tatsächlich brachte der schnelle Erfolg des Wortes Wissensmanagement eine
Verwendung für sehr unterschiedliche Bereiche mit sich. Begriffe wie Weiter- 13 Vgl. Schneider, Ursula, Die 7 Todsünden im Wissensmanagement, Kardinaltugenden für die Wissensökonomie, Frankfurt, 2001, S. 25f. 14 Vgl. ebenda, Seite 144. 15 Vgl. Pawlowsky, Peter, Wozu Wissensmanagement?, in: Götz, Klaus (Hrsg.), Wissensmanagement, Zwischen Wissen und Nichtwissen, 4. Aufl., München, 2002, S. 109. 16 Vgl. ebenda. 17 Vgl. Wilson 2002, Introduction. 18 Vgl. Ponzi, Leonard J., / Koenig, Michael, Knowledge management: another management fad?, in: Information Research, Jg. 8 (2002), Ausg. 1, http://informationr.net/ir/8-1/paper145.html, [05.06.2006].
- 9 -
bildung, Datenverwaltung, Vorschlagswesen, aber auch Dokumentenmanagement
wurden an einigen Stellen durch Wissensmanagement ersetzt, um die
dazugehörigen Produkte besser vermarkten zu können.19
2.2.2 Dokumente und Wissen
Dokumente können Wissen enthalten. Es kann sich dabei nur um explizites
Wissen handeln, da implizites Wissen eben nicht artikulierbar ist. Für das
Wissensmanagement sind Dokumente eine unter vielen Formen, in denen Wissen
auftritt. Der Theorie zufolge können Dokumente damit als Wissensobjekte
bezeichnet werden.20
Dokumente lassen sich in der Wissensspirale des SECI-Modells verschiedenen
Phasen zuordnen. Vor allem treten Dokumente in der Phase der Kombination in
Erscheinung. Das Lesen, Nutzen und Fortschreiben von Dokumenten lässt neues
explizites Wissen in Form neuer Dokumente entstehen. Zusätzlich kann bei der
Erstellung von Dokumenten eine Externalisierung von implizitem Wissen
stattfinden.21
In den sechs Kernprozessen des Wissensmanagement nach Probst dienen
Dokumente vorrangig der Wissensverteilung und -bewahrung. Die Verteilung
gestaltet sich besonders bei digitalen Formaten unkompliziert. Diese lassen sich
einfach kopieren und über Netzwerke in sekundenschnelle über den gesamten
Erdball verteilen. In Unternehmen sind es oft Handbücher, Richtlinien und Lehr-
materialien, die in Dokumentenform abgelegt sind.22
Für die Bewahrung von Wissen bieten sich Dokumente aus zwei Gründen an.
Erstens entstehen im täglichen Betrieb bereits diverse Dokumente, so zum
19 Vgl. Wilson 2002, IBM Systems Journal u.a. 20 Vgl. Oertel, Regina / Knosp, Achim, Ich weiß du weißt, was wissen wir?, Die virtuelle Plattform und Referenzprozesse zur Entwicklung von Wissensprodukten, in: Pawlowsky, Peter / Reinhardt, Rüdiger (Hrsg.), Wissensmanagement für die Praxis, Methoden und Instrumente für die Umsetzung, Neuwied / Kriftel, 2002, S. 98 f. 21 Vgl. Nonaka 1997, S. 74 ff. 22 Vgl. Probst 2006, S. 150.
- 10 -
Beispiel durch Protokollierung. Zum anderen können Dokumente schwach
strukturierte Informationen enthalten, die sich nur schwer in Datenbanken
speichern lassen.23 Das Problem ist die Rückgewinnung von Wissen aus der
Vielzahl an Dokumenten.
Dokumente sind eine in der Vergangenheit bereits viel beachtete Quelle für
Wissen. Genau aus diesem Grund beschäftigt sich das theoretische Wissens-
management heute zunehmend mit anderen Wissensformen. Dokumente bilden
die sichtbare, leicht zu fassende Spitze des Eisbergs beim Wissen.24 Vor allem in
der Praxis bieten Dokumente jedoch weiterhin eine starke Grundlage für Wissens-
management.
Aus technologischer Sicht kann Wissensmanagement als Oberbegriff für eine
Menge von unterstützenden Systemen stehen. Aus diesem Blickwinkel bilden
DMS einen Teil eines solchen Systems. Als konsequente Fortführung dieser
Sichtweise, kombiniert mit der Sicht auf Dokumente als Grundlage für Wissen,
existiert bereits eine Architektur für ein Wissensmanagementsystem, welches den
Inhalt von Dokumenten nutzt. Es wird dabei zwischen zwei Unterräumen
(Subspaces) unterschieden. Der Wissensunterraum speichert das im Wissens-
managementsystem gespeicherte Wissen. Der Dokumentenunterraum wird als
Entwicklungsgrundlage für das gespeicherte Wissen genutzt. Dokumente dienen
danach als Rechtfertigung (Justification) des Wissens.25
2.3 Entwicklung der Dokumentenverwaltung
Dokumentenmanagement in Unternehmen ist nur unter diesem Namen ein neues
Thema. Schon in den sechziger Jahren wurden Dokumente in Unternehmen
23 Vgl. Probst 2006, S. 202 ff. 24 Vgl. Geißler, Harald, Wissensmanagement durch Assessment-Center, Ein unterschätztes Diagnose- und Vermittlungsinstrument für das Wissen und Können einer Organisation, in: Pawlowsky, Peter / Reinhardt, Rüdiger (Hrsg.), Wissensmanagement für die Praxis, Methoden und Instrumente für die Umsetzung, Neuwied / Kriftel, 2002, S. 62. 25 Vgl. Feng, Ling / Jeusfeld, Manfred A., /Hoppenbrouwers, Jeroen, Beyond information searching and browsing, acquiring knowledge from digital libraries, in: Information Processing and Management, Jg. 41 Ausg. 1, 2005, S. 101ff.
- 11 -
technisch gestützt aufbewahrt. Die zentrale Aufgabe war die Lagerung und Suche,
um beispielsweise doppelte Forschungsarbeit zu verhindern. Als technische Hilfs-
mittel wurden zu dieser Zeit neben Lochkarten auch schon Computer mit nicht-
mechanischen Speichern eingesetzt. Die Suche basierte damals wie heute auf
Deskriptoren. Die Lagerung der Dokumente erfolgte physisch als Papier oder auf
Mikrofilmen. Das Ergebnis einer Suchanfrage war der Aufbewahrungsort des
Dokuments.26
Die Entwicklung hin zu einem Dokumentenmanagement nach der heutigen
Definition wurde durch Verbesserungen der Technologie möglich. Getrieben von
der Idee, ein papierloses Büro zu schaffen, wurden Dokumente digitalisiert und in
elektronischer Form verteilt. Hier beginnt die technische Abbildung des aktiven
Teils des Dokumentenlebenszyklus. Als Vorreiter begannen vor allem Banken
und Versicherungen bereits in den achtziger Jahren mit dem Einsatz dieser echten
DMS.
In den neunziger Jahren fanden diese noch sehr aufwendigen und teuren Systeme
eine Verbreitung innerhalb von Großunternehmen. Der wachsende Markt ließ die
Zahl der Anbieter stark ansteigen. Zu große Hoffnungen und ein übertriebener
Technikeinsatz führten jedoch selten zur Verwirklichung der ehrgeizigen Ziele.27
Mit der Zeit entwickelten sich DMS weiter und bieten heute Funktionen, die über
die Verwaltung von Dokumenten hinausgehen. Im Gegenzug erweiterten andere
betriebswirtschaftliche Anwendungen ihren Funktionsumfang um den Bereich
Dokumentenmanagement, was zu einer starken Konkurrenz führte. Schon im Jahr
2000 waren dann die Grenzen zwischen Dokumentenmanagement, Workflow-
management und anderen Gebieten praktisch aufgelöst.28
26 Vgl. Mertens, Peter, Betriebliche Dokumentation und Information, Meisenheim am Glan, 1965, S. 118 ff. 27 Vgl. Götzer 2004, S. 2. 28 Vgl. Born 2000, S. 84.
- 12 -
Trotz guter Wachstumsprognosen folgte eine starke Abnahme der Anbieterzahl.
Das Überangebot, die steigenden Anforderungen und die starke Konkurrenz durch
Fremdsysteme mit Dokumentenmanagementfunktionen ließ vor allem kleine
Anbieter verschwinden.29
Das prognostizierte Wachstum fand ungeachtet dessen statt. Davon profitieren
konnten vorrangig große Anbieter mit der Kapazität zur Erweiterung ihrer
Lösungen. Nur so besitzt ein Unternehmen einen Wettbewerbsvorteil gegenüber
den fachfremden Anbietern, welche die Kernfunktionen des Dokumenten-
managements in ihre Anwendung integrieren.30
Eine neue Entwicklung im Bereich der Dokumente sind elektronische
Unterschriften. Deutschland war 1997 mit dem digitalen Signaturgesetz ein
Vorreiter auf diesem Gebiet. Wegen rechtlicher Bedenken und umfangreicher
Anforderungen setzten allerdings nur wenige Unternehmen die neuen Regelungen
um. Die juristische Situation hat sich mit der Neufassung im Jahr 2001 zwar
gebessert,31 eine breite Nutzung der Möglichkeiten lässt aber weiter auf sich
warten. Besonders elektronisch abgewickelte Geschäfte profitieren derzeit von der
rechtlichen Gleichstellung digitaler Unterschriften.32 Heutige DMS unterstützen
diese bereits vielfach.
Insgesamt ist der Markt für DMS heute für den Kunden besser denn je. Das
Marktangebot ist breit und bietet auch Raum für Sonderwünsche. Einfache DMS
sind im Preis stark gesunken und damit auch für mittelständische Unternehmen
interessant. Wichtig ist die Auswahl des richtigen Anbieters, denn die Bindung an
ein DMS kann eine strategische Entscheidung sein. Auf Grund der Entwicklung
hin zur Integration von Dokumentenmanagementfunktionen in andere
29 Vgl. Schüler, Peter, Dokumentierte Flaute, Einzelne Highlights retten die DMS Expo 2002, in: c’t – Magazin für Computertechnik, Jg. 20 (2002), Ausg. 20, S. 42. 30 Vgl. Schüler, Peter, Arbeit im Fluss, Neue Software-Schwerpunkte auf der DMS-Expo, in: c’t – Magazin für Computertechnik, Jg. 23 (2005), Ausg. 22, S. 60. 31 Vgl. zur Vertiefung Signaturgesetz der BRD 1997, 2001, EG-Signaturrichtlinie 1999/93/EG. 32 Vgl. zur Vertiefung Handelsgesetzbuch der BRD, §§ 239, 257 und Abgabenordnung, §§ 146, 147.
- 13 -
Anwendungssysteme geht die Nachfrage nach DMS stellenweise zurück. Viele
Unternehmen sind mit den angebotenen Funktionen anderer Applikationen
zufrieden und benötigen kein zusätzliches DMS.
2.4 Dokumentenmanagementsysteme
2.4.1 Einordnung
Dokumentenmanagementsysteme lassen sich in die Gruppe der betriebs-
wirtschaftlichen Anwendungssysteme einordnen. Abbildung 2 zeigt die
Einordnung der DMS nach Stahlknecht und Hasenkamp.
Abbildung 2: Gliederung betriebswirtschaftlicher
Anwendungssysteme33
Die Einordnung der DMS als Bürosysteme bleibt im Kern auch vor dem
Hintergrund aktueller Entwicklungen gültig. Allein der Begriff Anwendungs-
system darf nicht zu eng gesehen werden. Mit dem Aufweichen der Grenzen von
DMS zu anderen Applikationen kann auch eine scharfe Trennung in einzelne
Systeme nicht mehr erfolgen. Es handelt sich also nicht unbedingt um
abgeschlossene Systeme, sondern um eine Sammlung von Funktionen, die sich
33 Vgl. Stahlknecht, Peter / Hasenkamp, Ulrich, Einführung in die Wirtschaftsinformatik, 10. Auflage, Berlin u.a., 2002.
Administrations- und Dispositions-systeme
Anwendungs-systeme
Führungssysteme Querschnitts-systeme
Branchen-neutral
Branchen-spezifisch
Infor-mations-austausch
Führungs-informa-tion
Planungs-systeme
Multi-media-systeme
Wissens-basierte Systeme
Büro-systeme
DDookkuummeenntteennmmaannaaggeemmeennttssyysstteemmee
- 14 -
dem Dokumentenmanagement zuordnen lassen. Im englischen Sprachraum hat
sich hierfür der Begriff Document Related Technologies durchgesetzt.
Für den Umgang mit DMS gibt es keine spezielle Ausbildung, die Einordnung
nach diesem Kriterium gestaltet sich demnach schwierig. Die meisten Experten
haben verschiedene Ausbildungen im IT-Bereich. Dazu kommen viele
ausgebildeten Archivare und Bibliothekare. Auf internationaler Ebene stellt die
Computer Technology Industry Association (CompTIA) das Zertifikat Certified
Document Imaging Architech (CDIA+) für Berater zu den Themen elektronische
Archivierung, Dokumenten- und Contentmanagement aus, doch nur ein kleiner
Teil der Experten besitzt dieses Zertifikat.
2.4.2 Ziele und Nutzen
Die klassischen Ziele bei der Einführung eines DMS sind die Reduktion der
Liege- und Transportzeit durch die Einführung einer elektronischen Version eines
Dokuments. Daneben verbessert sich die Verfügbarkeit, weil ein Dokument auch
während seiner Bearbeitung von anderen gelesen werden kann.34 Mit einem
vollwertigen Archiv lassen sich zusätzliche Ziele wie die revisionssichere Ablage
großer Mengen von Dokumenten über einen Zeitraum von mehreren
Jahrzehnten35 realisieren. Damit löst das DMS ein teures Papierarchiv ab.36 Je
nach Ausführung und Komponenten können eine Vielzahl weiterer Ziele genannt
werden. Die wichtigsten sind für Europa in einer Norm festgehalten:
„Der potentielle Nutzen [elektronischer Dokumentenmanagement-systeme] umfasst:
● effiziente Suche und Beschaffung bestimmter Dokumente;
● schnelle und direkte Weitergabe von Änderungen;
● automatische Arbeitsabläufe;
● Erstellung von Sammeldokumenten zu sachbezogenen Informationen;
34 Vgl. Klingelhöller 2001, S. 15 f. 35 Ein Beispiel hierfür sind Patientendaten. 36 Vgl. Götzer, S. 70 f.
- 15 -
● Reduzierter Verwaltungsaufwand durch Integration von Dokumentenerstellung und –management;
● Zugriff auf Erkenntnisse aus früheren Projekten und aus allgemein verfügbaren Quellen der Industrie;
● Unterstützung von Datenaustausch und Data Sharing;
● Förderung der Zusammenarbeit im Engineering“37
2.4.3 Dokumente
Die intuitive Vorstellung eines Dokuments ist ein mit Buchstaben bedrucktes
Papier mit wichtigem Inhalt. Dieser eng gefasste Dokumentenbegriff soll im
Folgenden erweitert werden. Dokumente speichern ihren Inhalt nicht mehr nur auf
Papier. Neben der relativ neuen elektronischen Form setzen Archive seit Jahr-
zehnten Mikrofilme ein.38
Eine zweite Erweiterung des Dokumentenbegriffs betrifft die Form der
Informationen. Neben Schrift sind Bild-, Audio- und Videoaufzeichnungen
ebenfalls Träger von Information. Diese Formen spielen beim Dokumenten-
management bisher nur in Spezialanwendungen eine Rolle. Der übergroße Anteil
der DMS behandelt weiterhin Schriftstücke, deswegen konzentriert sich die
vorliegende Arbeit auch auf diese und behandelt keine Alternativen.
Dokumente haben eine Informations- und Nachweisfunktion. Bei der
Informationsfunktion werden Inhalte vom Autor niedergeschrieben und vom
Leser aufgenommen. Unterschieden wird hierbei noch nach der Zeit zwischen
Erstellung und Nutzung des Dokuments. Geschieht beides ohne großen
Zeitverzug hintereinander, wird von reiner Informationsverteilung gesprochen, bei
zeitlicher Verzögerung handelt es sich nebenbei auch um Informationsbewahrung.
Eine reine Informationskonservierung liegt dann vor, wenn Autor und Leser die
selbe Person sind.
37 DIN EN 82045-1:2001, Dokumentenmanagement, S. 5. 38 Deutsches Institut für Normung, Normenausschuss Qualitätsmanagement NA 147, Statistik und Zertifizierungsgrundlagen (NQSZ), ISO 9000 Unterstützungsanleitung, http://www.nqsz.din.de/sixcms_upload/media/1832/ISO9000-Unterstuetzungsanleitungen.pdf, [02.07.2006], S. 15.
- 16 -
Der Erfüllung der Nachweisfunktion dienen Dokumente, indem sie Fakten zur
nachträglichen Revision festhalten. Der Inhalt ist dann zumeist bekannt, im
Vordergrund steht hier das Vorhandensein des Dokuments. Zum Schutz gegen
Fälschung sind Dokumente mit Nachweisfunktion oft mit Signaturen versehen.
Elektronische Dokumente unterscheidet die Fachliteratur unter anderem nach der
Art der gespeicherten Informationen in NCI- und CI-Dokumente. Nichtcodierte
Informationen (NCI) machen eine elektronische Verarbeitung des Inhalts
unmöglich. Es handelt sich dabei meist um Papierdokumente, die bildpunktweise
gespeichert werden. Die Bedeutung der einzelnen Punkte als Teile von Zeichen
geht dabei verloren. Der Vorteil von NCI-Dokumenten gegenüber der Papierform
beschränkt sich auf eine schnelle Weitergabe, eine erhöhte Verfügbarkeit und eine
Platz sparende Archivierung. Außerdem können anhand der nichtcodierten
Informationen optisch identische Kopien des Originals ohne großen Aufwand
erstellt werden.
CI-Dokumente codieren den Inhalt eines Dokuments, das heißt, einzelne Zeichen
werden als solche digital repräsentiert und gespeichert. Häufige Vertreter sind
Dateien einer Textverarbeitung mit den Endungen wie txt oder doc. Derartige
Dokumente lassen sich gut elektronisch bearbeiten. Ein Problem kann die optisch
exakt gleiche Ausgabe auf verschiedenen Computern sein. Nur die Wahl eines
geeigneten Formats beugt Problemen wie fehlenden Schriftarten oder Miss-
interpretation von Layoutinformationen vor.
Die Formen CI und NCI lassen sich ineinander überführen. CI-Dokumente
können ohne weiteres als Bilddatei gespeichert werden. Einige Textverarbeitungs-
programme verfügen von Hause aus über die entsprechende Funktion. Ist das
nicht der Fall, kommt eine spezielle Konvertierungssoftware oder die technisch
wenig versierte und doch angewandte Methode des Ausdruckens und darauf
folgendem Scannen zum Einsatz.
- 17 -
Der Weg vom NCI- zum CI-Dokument ist ungleich schwieriger. Texte lassen sich
mit Software zur Texterkennung39 in CI-Dokumente überführen. Das Problem
bleiben die fehlerbehafteten Erkennungsalgorithmen sowie die Abstraktion und
Übertragung des Layouts. Bei gescannten Bildern werden Vektorisierungs- und
Bilderkennungsprogramme eingesetzt. Diese versuchen anhand der Bildpunkte
Linien, geometrische Figuren und komplizierte Objekte zu erkennen. Vollständig
ausgereift sind auch deren Algorithmen nicht.40
Die Änderung der Form eines Dokumentes ist aus juristischer Sicht immer
schwierig. Selbst wenn die eingesetzte Unterschrift alle rechtlichen Vorgaben für
eine qualifizierte Unterschrift erfüllt, kann deren Einsatz problematisch sein.
Beim Einlesen von Papierdokumenten kann eine Veränderung zwischen dem
Scannvorgang und der Vergabe einer elektronischen Signatur nicht einfach
ausgeschlossen werden.41 Selbiges gilt für den Wandel von CI- in NCI-
Dokumente und umgekehrt. Eine Veränderung zwischen dem Zeitpunkt der
Umwandlung und der Vergabe einer Signatur für das neu entstandene Dokument
lässt sich nur schwer verhindern und nachweisen.
2.4.4 Aufbau
Der typische Aufbau von Dokumentenmanagementsystemen orientiert sich an den
Phasen, die ein Dokument durchläuft. Nach der deutschen Norm zum
Dokumentenmanagement ist eine Einteilung in die fünf Phasen Erstellung,
Übernahme, aktive Nutzung, Archivierung und Löschung vorgesehen. Die
meisten Komponenten eines DMS lassen sich problemlos diesen Phasen
zuordnen.42
Für die Dokumentenerstellung kommen in der Regel Büroanwendungen zum
Einsatz. Diese haben nicht immer eine direkte Verbindung zum DMS. Noch
39 So genannte OCR-Software. 40 Vgl. Klingelhöller 2001, S. 10 ff. 41 Götzer 2004, S. 239. 42 Deutsches Institut für Normung, DIN 82045-1:2001, S. 7 ff.
- 18 -
seltener stellt das DMS selbst eine eigene Komponente zur Schaffung von
Dokumenten zur Verfügung. Ein Beispiel für eine gelungene Integration von
fremder Software in das DMS ist die von Microsoftprodukten in den SAP
Solution Manager. Beim Betrieb des Solution Managers wird zur Erstellung und
Bearbeitung ein Teil des aktiven Fensters mit der bekannten Oberfläche eines MS
Word oder PowerPoint gefüllt. Die nutzbaren Funktionen sind dabei nach dem
Einsatzzweck beschränkt.
Wird die erste Phase nicht ausschließlich im DMS abgewickelt, muss eine
Übernahme von bereits vorhandenen Dokumenten möglich sein. Bei Papier-
dokumenten sind dies Scanner. Sie erzeugen die für ein DMS lesbare Form.
Mittlerweile wird bei der dazugehörigen Software ebenfalls zunehmend auf die
Integration von Fremdsoftware anstelle von Eigenentwicklungen des DMS-
Anbieters gesetzt. Sollen die Scannerinformationen als codierte Informationen
weiter verarbeitet werden, ist dafür die passende Software notwendig. Sind die
Dokumente bereits als Dateien vorhanden, reicht ein Hochladen dieser in das
DMS.
Ebenfalls in die Phase der Übernahme gehört die Einordnung des neuen Objekts.
Metadaten, also Informationen über das Dokument, spielen hier die wichtigste
Rolle. Sie müssen erstellt und gespeichert werden.
Nach der Übernahme befindet sich das Dokument in der Ablage. Technisch gibt
es hier große Unterschiede. Traditionell ist die Ablage in einer Datenbank. Hier
werden die Dokumente zumeist getrennt von ihren Metadaten aufbewahrt und
gemäß den Prinzipien einer relationalen Ablagestruktur verbunden. Bei großen
Dokumenten lohnt sich die getrennte Aufbewahrung in darauf spezialisierten
Dateiservern. Wenn keine Datenbank genutzt werden soll, kann das Dateisystem
des Betriebssystems genutzt werden. Ein DMS kann seine eigene interne
Strukturierung auf das Dateisystem übertragen. In diesem Fall wird indirekt über
das DMS auf die einzelnen Dateien zugegriffen. Welche Informationen in welcher
Datei gehalten werden, muss dabei nicht erkennbar sein. Eine relativ neue
Möglichkeit ist die direkte Nutzung des Dateisystems. Hier wird die Dokumenten-
- 19 -
managementfunktionalität in das Betriebssystem integriert. Der Vorteil liegt in der
gewohnten Nutzung des Dateisystems über die verschiedensten Anwendungen
hinweg.43
Ist ein Dokument im DMS abgelegt, beginnt die aktive Phase der Bearbeitung. Es
werden Komponenten für die Workflowunterstützung oder eine Anbindung an ein
Workflowmanagementsystem benötigt. Zusätzlich kommen Bausteine wie
Editoren, Signatursoftware, Indexserver für die Volltextsuche, eine Nutzer-
verwaltung mit einem Berechtigungssystem und Komponenten für die Ausgabe
zum Einsatz.44
Die Suche von Dokumenten spielt sowohl in der Phase der aktiven Bearbeitung
als auch nach der Archivierung eine entscheidende Rolle in einem DMS. Die
zugehörigen Bausteine für diese Aufgabe heißen Retrieval-Komponenten. Diese
werden anhand zweier grundlegender Suchstrategien unterschieden.
Als Browsen wird der Versuch bezeichnet, relevante Objekte anhand von
Verbindungen zu finden. So hangelt sich der Anwender beispielsweise in einem
Dateisystem durch die Verzeichnisse bis zum gewünschten Dokument. In einer
Bibliothek kann sich der interessierte Leser in die richtige Abteilung begeben und
die einzelnen Regale durchsuchen, welche thematisch geordnet sind. Im Internet
folgt der Surfer den einzelnen Links, bis die aktuelle Seite die gewünschten
Informationen enthält. Jedes dieser drei Beispiele illustriert die Suche durch
Browsen. Dabei fallen noch zwei Unterarten des Browsen auf. Im Dateisystem
und einer Bibliothek wird in einer Hierarchie deduktiv gesucht. Im Internet gibt es
eine solche Ordnung nicht, hier wird von Punkt zu Punkt gesprungen.
Neben dem Browsen gibt es das Suchen durch Anfragen (auch Quering). Hier ist
die Wissenschaft des Information Retrieval eigentlich zu Hause. Sie beschäftigt
43 Windream GmbH, DMS mit VFS Technology, http://www.windream.com/cgi-bin/winmain.ais?PAGE=de110, [10.05.2006]. 44 Götzer 2004, S. 70 ff.
- 20 -
sich mit dem Finden relevanter Objekte in einer strukturierten Sammlung
unstrukturierter Daten.45 Die behandelten Objekte sind dabei Textdokumente.46
Bei einer Anfrage werden Dokumente in der Regel anhand von Schlüsselwörtern
identifiziert. Die Anfrage besteht deshalb aus einer Ansammlung von Wörtern,
ähnlich der Anwendung einer Suchmaschine im Internet. Dabei zielen die
Algorithmen auf eine hohe Präzision bei gleichzeitig hoher Trefferquote ab.
Präzision errechnet sich aus dem Verhältnis der Anzahl gefundener relevanter
Dokumente zu der Anzahl aller gefundenen Dokumente. Eine Suche mit zehn
Treffern, von denen drei offensichtlich nichts mit dem gesuchten Thema zu tun
haben, ergibt eine Präzision von 70 Prozent.
Die Trefferquote lässt sich dagegen kaum bestimmen. Sie misst die
Vollständigkeit der Suchergebnisse als Quotient aus der Anzahl gefundener
relevanter Dokumente durch die Gesamtzahl relevanter Dokumente in der
Datenbasis. Enthält die Datenbasis zum Beispiel zehn für die Suche relevante
Dokumente und nur sechs werden gefunden, ergibt sich eine Trefferquote von 60
Prozent. Die Bestimmung der Gesamtanzahl relevanter Dokumente ist jedoch nur
in Testfällen möglich. Könnte ein Algorithmus alle relevanten Dokumente aus
einer Datenbasis immer verlässlich ermitteln, wäre dieses Verfahren die
Ideallösung für die Suche.
In der Praxis erreichen Information Retrieval Systeme in der Regel ein Verhältnis
von Präzision und Trefferquote gemäß Abbildung 3.
45 Im Gegensatz zum Datenretrieval, bei denen die Daten strukturiert abgelegt sind. 46 Kroha, Petr, Information Retrieval Systeme, Skript zur gleichnamigen Vorlesung, Chemnitz, 2004, S. 4.
- 21 -
Abbildung 3: Verhältnis von Präzision zur Trefferquote47
Ausgehend vom Idealzustand lässt sich nur ein Kompromiss zwischen Präzision
und Trefferquote erreichen. Klassifiziert ein Retrieval-System Dokumente schon
beim kleinsten Verdacht als relevant, ist die Chance hoch, dass alle relevanten
Dokumente gefunden werden und sich daraus eine hohe Trefferquote ergibt. Das
Problem ist in einem solchen Fall die große Anzahl an falsch klassifizierten
Dokumenten, die die Präzision sinken lassen. Je nach Anwendung muss der
Schwerpunkt auf eine der beiden Größen gelegt werden.
Nach dem aktiven Teil des Dokumentenlebens macht es die Archivierung über
mehrere Jahre erforderlich, dass die Dokumente vor ihrer Einlagerung in ein
langlebiges Datenformat überführt werden. Im elektronischen Archiv werden die
digitalen Daten dann langfristig aufbewahrt. Verschiedene Datenträgersysteme
sind magnetische Bänder oder Platten sowie optische Speichermedien wie CD,
DVD oder WORM.
Ist die Aufbewahrungsfrist für ein Dokument abgelaufen, wird es gelöscht. Bei
der Speicherung auf nur einmal beschreibbaren Medien können die Datenträger
physisch vernichten werden. Soll der Datenträger nochmals verwendet werden,
wird für die unwiederbringliche Löschung eine entsprechende Software benötigt.
47Kroha 2004, S. 265.
100%
100%
Präzision
Trefferquote
Idealzustand
- 22 -
Abbildung 4 gibt einen Überblick über die behandelten Komponenten eines DMS.
Ein DMS muss nicht jede Komponente beinhalten, zusätzlich sind Erweiterungen
in jede beliebige Richtung möglich.
Abbildung 4: Komponenten eines Dokumentenmanagementsystems
2.4.5 Funktionen
Seit der Verbreitung von DMS hat sich deren Funktionsumfang stark
diversifiziert. Es sollen hier deshalb nur die wichtigsten Funktionen behandelt
werden. Die Ordnung entspricht dabei weitestgehend dem Dokumentenlebens-
zyklus und den Komponenten, ähnlich dem vorherigen Kapitel.
Die Erstellung von Dokumenten kann ein DMS mit der Bereitstellung von
Vorlagen effektiv unterstützen. Das funktioniert selbst dann, wenn keine
Textverarbeitung integriert ist. Bei speziellen Anwendungen können DMS
eigenständig enthaltene Dokumente mit Inhalt füllen. So können Messwerte von
anderen Anwendungen weitergeleitet werden, aus denen dann ein Dokument
geschaffen wird. Klassische DMS besitzen solche Funktionen jedoch nicht.
Dokumente erstellen
Scanner
Dokumente
einsortieren
Retrieval
(Browsing)
Berechtigungs-
system Digitale Signatur
Ausgabe
Konvertierung für Langzeitarchivierung
Archiv
Löschen
NCI/CI-Wandler Dokumente
bearbeiten
Ablage
Retrieval (Anfrage)
Indexserver
DDookkuummeenntteenn--mmaannaaggeemmeenntt--
ssyysstteemmee
- 23 -
Bei der Übernahme von Papierdokumenten kann eine Scannersteuerung im DMS
enthalten sein. Außerdem sind hier Funktionen zum automatischen Zusammen-
fügen einzelner Seiten und ähnliches möglich. Ist ein Dokument dann in einer
digitalen Form verfügbar, sorgen Funktionen für die Eingliederung in bestehende
Strukturen. Anschließend werden verschiedene Metadaten zum Dokument erstellt.
Dazu gehören Informationen wie Dokumentensprache, Autor, Art, Priorität,
Gültigkeitsdauer und -bereich usw.
Besondere Metadaten sind der Status und die zugeordneten Stichwörter. Ein
Statusschema, also eine vordefinierte Abfolge von Statuswerten, wird häufig mit
weiteren Funktionen, z.B. einer Berechtigungsprüfung, verbunden. Die
Stichwörter eines Dokuments bilden die Grundlage für die inhaltsbezogene Suche
durch Abfragen. Die Auswahl sollte dementsprechend durchdacht sein. Zum
einen gilt es zu überlegen, ob die Verstichwortung eine freie Wahl der Stichwörter
gewährt oder eine vordefinierte Liste benutzt, um die Verwendung von
Synonymen zu verhindern. Danach stellt sich die Frage, wer die passenden
Stichwörter für ein konkretes Dokument auswählt. Soll dieser Vorgang manuell
durch den Autor oder eine Fachkraft geschehen, ist das Ergebnis meist von hoher
Qualität, aber entsprechend teuer. Nutzt ein Verstichwortungssystem die
schnelleren, aber unzuverlässigeren computergestützten Indizierungsverfahren,
sind Kosteneinsparungen zu Lasten der Qualität möglich. Zu beachten ist, dass
Verfahren zur automatischen Verstichwortung in der Lage sein müssen, die
Dokumente zu lesen. Diese müssen also in einem CI-Format vorliegen.
Ist ein Dokument mit seinen Metadaten erst einmal gespeichert, wird es
bearbeitet. Ein Mitarbeiter muss dazu das Dokument lesen können, d.h. die
Bildschirmdarstellung oder das Drucken muss möglich sein. Zum Lesen können
Übersetzungsprogramme hilfreich sein. Zur Veränderung des Inhalts sind
Funktionen einer Textverarbeitung oder Tabellenkalkulation notwendig.
Über die Funktionen eines Berechtigungssystems können anhand des aktuellen
Status oder anderer Kriterien Rechte zum Lesen, Schreiben und Löschen vergeben
- 24 -
werden. Bei geschäftskritischen Dokumenten kann das sogar gesetzlich
vorgeschrieben sein.
Anhand des Statusschemas kann der aktuelle Bearbeitungsstand innerhalb des
Arbeitsablaufs abgelesen werden. Soll das DMS den gesamten Arbeitsablauf
abbilden, handelt es sich um ein Workflowmanagementsystem. Hier werden
Funktionen wie eine elektronische Arbeitsmappe benötigt, die vordefinierte
Stationen abläuft. Zur Weiterleitung ist eine Schnittstelle zu einem Computernetz
notwendig. Häufig geschieht das über eine internetbasierte Portaldarstellung.
Erfordert ein gewisser Bearbeitungsschritt die Unterschrift einer Person oder eines
Personenkreises, ist eine Funktion zum digitalen Signieren hilfreich. Verknüpft
mit den Statuswerten kann bei Auftreten eines gewissen Status die Bearbeitung
unterbrochen werden, eine Fortsetzung geschieht dann erst nach dem Leisten der
entsprechenden Unterschrift.
Um die Veränderungen eines Dokuments während der Bearbeitung nachvoll-
ziehbar zu machen, existiert eine Versionierung. Hierfür werden entweder die
einzelnen Bearbeitungsschritte gespeichert oder verschiedene Versionen des
Dokuments verfügbar gemacht. Unabhängig von der Realisierung sollten
Informationen wie Zeit, Grund und Autor der Veränderung dokumentiert werden.
Für eine effiziente Suche ist eine Reihe von Funktionen notwendig. Suchen durch
Browsen erfordert Verbindungen zwischen einzelnen Objekten. Dies kann wie
beim Hypertext im Informationsobjekt selbst geschehen. Das heißt, ein Dokument
beinhaltet selbst einen Verweis. Die andere Möglichkeit ist, dass Verweise auf
andere Dokumente ein spezielles Metadatum eines Dokumentes bilden.
Sollen Strukturen angelegt werden, sind logische Objekte wie Verzeichnisse
notwendig. Streng genommen handelt es sich bei der Zuordnung eines Dokuments
zu einem logischen Objekt um nichts anderes als ein Metadatum. Die Ablage
geschieht meist geschachtelt, das bedeutet, ein logisches Objekt kann Dokumente
oder weitere logische Objekte enthalten. Darf einem logischen Objekt nur
- 25 -
maximal ein anderes übergeordnet sein, entsteht eine Baumstruktur. Sie bildet die
häufigste Art der Strukturierung.
Der Grund für den häufigen Einsatz einer Baumstruktur liegt in ihrer Fähigkeit
zur Komplexitätsreduktion. Ein kleines Rechenbeispiel soll dies verdeutlichen.
Eine Liste von 3125 Dokumenten ist kaum zu überblicken. Sind diese jedoch in
der untersten Ebene einer Baumstruktur abgelegt, werden lediglich fünf Ebenen
mit jeweils fünf Unterknoten benötigt, um alle Dokumente aufzunehmen. Beim
Browsen muss dann, eine eindeutige Zuordnung vorausgesetzt, fünf mal ein
Eintrag aus fünf Einträgen ausgewählt werden, um das gewünschte Dokument zu
erhalten. Darüber hinaus sind die meisten Menschen den Umgang mit
Baumstrukturen gewöhnt. Vom Inhaltsverzeichnis eines Buches, über
Organisationsstrukturen bis hin zum Dateisystem der bekannten Betriebssysteme,
Baumstrukturen sind in vielen Situationen hilfreich.
Möchten die Benutzer eines DMS Dokumente automatisch finden lassen,
erfordert das Funktionen zur Bildung und Verarbeitung von Anfragen. Die
einfachste Variante ist die Aufzählung von Stichwörtern, die dann mit logischen
Operatoren verknüpft und mit einem Index abgeglichen werden. Neben
Stichwörtern können auch andere Metadaten wie Autoren oder der Titel
herangezogen werden. Es gibt Versuche, erweiterte Suchansätze zu finden.
Internetsuchmaschinen arbeiten mit komplizierten mathematischen Verfahren, um
die Ergebnisse in eine Reihenfolge zu bringen. Sie beziehen dabei Daten wie
Internetadresse, Änderungsdatum und -häufigkeit und Verweisstruktur in das
Ergebnis mit ein.
Die Forschung auf diesem Gebiet versucht darüber hinaus, Funktionen zu
entwickeln, die es dem Anwender ermöglichen, nicht nur einfache Stichwörter
einzugeben, sondern komplexe natürlichsprachige Fragen zu stellen. Andere
Ansätze versuchen, die Ergebnisse bei der Stichwortsuche nachträglich zu
verbessern. Bekannte Funktionen zur Erhöhung der Trefferquote sind Stemming
sowie der Einsatz von Thesauri und Platzhaltern. Stemming erweitert die
Suchfunktion um Wörter der gleichen Familie. Besonders in Sprachen mit den
- 26 -
verschiedenen Wortformen, die durch Konjugation, Deklination,
Substantivierungen oder den Plural entstehen, lohnt sich der Einsatz dieser
Technik.
Bei Suchfunktionen, die Thesauri nutzen, wird die Suche auf Synonyme und
Antonyme ausgeweitet, um mehr relevante Dokumente zu finden. Die
Platzhalterfunktion ermöglicht es dem Nutzer, die Suche eigenhändig zu
erweitern. Bestimmte Zeichen ersetzen dabei innerhalb eines Stichwortes einen
oder mehrere Buchstaben. Die Suche wird dann auf alle Stichwörter erweitert, die
beliebige Schriftzeichen an der Stelle des Platzhalters besitzen.
Der Einsatz solcher umfangreicher Suchtechniken wird vor allem bei Internet-
suchmaschinen und digitalen Bibliotheken verwendet. Der Einsatz im
Dokumentenmanagement wird sich in naher Zukunft stark erhöhen, gerade dann,
wenn das DMS als Grundlage für das Wissensmanagement dienen soll. Schon
jetzt vermarktet eine bekannte Internetsuchmaschine ihr Wissen auf diesem
Gebiet und bietet ihre erfolgreichen Algorithmen für den Unternehmenseinsatz
an.48
Ist die primäre Nutzung eines Dokuments abgeschlossen, wird es für die
Archivierung vorbereitet. Je nach Archiv ist dazu eine Konvertierung in ein neues
Format notwendig. Bei der herkömmlichen Archivierung sind das oft Mikrofilme,
die dann im Archiv physisch gelagert werden. Der Aufwand, die digitalisierten
Daten eines DMS wieder in eine körperliche Form zu überführen, kann gespart
werden, wenn digital archiviert wird. Es empfehlen sich hierfür nur langlebige
digitale Formate. Denn wer kann heute schon sagen, ob ein gewisses Text-
verarbeitungsprogramm in zehn Jahren noch existiert. Damit erstellte Dokumente
müssen dennoch lesbar bleiben. Bei Daten, die über viele Jahrzehnte aufbewahrt
werden müssen, ist dieser Punkt ganz besonders wichtig. Allein beim Gedanken
an die letzten dreißig Jahre zeigt sich, wie viele Formate zwischenzeitlich
aufgetaucht und wieder untergegangen sind. 48 Google Inc., Enterprise Solutions: Google Search Appliance, http://www.google.de/enterprise/gsa/index.html [09.06.2006].
- 27 -
Ein anderes Kriterium für die Auswahl des Ablageformates ist dessen Größe.
Durch effiziente Komprimierungsverfahren ist eine starke Reduktion der
Datenmenge möglich. Das hilft zum einen, Kosten zu sparen, und erlaubt zum
anderen die Archivierung in einer besonders hohen Qualität.
Die digitale Archivierung ist eine eigenständige Wissenschaft und füllt Bände.
Mehrstufige Archivierungsfunktionen mit Speicherhierarchien aus Cache-
Speichern, Platten, Bändern und optischen Datenträgern bilden dabei nur die
Grundlage. Dazu kommen Sicherungssysteme wie mehrfache Datenhaltung in
bunkerartigen Bauten für besonders sensible Daten. Beim Aufbau eines Archivs
für die revisionssichere Ablage müssen die Funktionen unbedingt die rechtlichen
Bedingungen erfüllen. Das macht die Konsultation von Experten unausweichlich.
Funktionen für das endgültige Löschen von Daten hängen stark von der Art der
Speicherung ab. Wenn eine Wiederherstellung der Daten ausgeschlossen werden
soll, kann das unter Umständen mit großem Aufwand verbunden sein. Bei Papier-
archiven wurden Schredder in verschiedene Sicherheitskategorien eingeteilt49, bei
digitalen Medien fehlt eine derart detaillierte Norm. Absolute Sicherheit
garantieren nach wie vor nur die Verbrennung oder ähnlich radikale Methoden.
Ansonsten verwenden die entsprechenden Programme Funktionen wie das
mehrfache Löschen und Überschreiben nach verschiedenen Zufallsmechanismen.
Alternativ zum sicheren Löschen können Daten von Anfang an verschlüsselt
gespeichert werden. Mit der Vernichtung des Schlüssels sind die Daten praktisch
unbrauchbar. Längerfristig gedacht sollte aber auch hier die Klarheit herrschen,
dass dreißig Jahre alte Verschlüsselungstechniken heute vielleicht genauso
einfach zu brechen sind wie aktuelle Verfahren in dreißig Jahren.
Zusammengefasst sind dies die Grundfunktionen eines DMS. Je nach Anwendung
müssen nicht alle Funktionen vorhanden sein oder können beliebig erweitert
49 Vgl. Deutsches Institut für Normung, DIN 32757.
- 28 -
werden. Gerade diese Wahlmöglichkeit macht eine genaue Analyse der
Anforderungen vor einer DMS-Einführung eminent wichtig.
2.5 Einführungsprojekte
2.5.1 Phasenmodell
Im Grunde lässt sich die Einführung eines DMS in die gleichen Phasen einteilen
wie die meisten anderen Softwareprojekte. Folgende Abbildung zeigt eine
mögliche Untergliederung und deren zeitlichen Ablauf.
Abbildung 5: Projektphasen eines Softwareprojektes50
In der ersten Phase, der Projektbegründung, stellen die Verantwortlichen die
Weichen für die Finanzierung des Projektes. Daneben gilt es, Überzeugungsarbeit
bei den Beteiligten zu leisten. Diese Phase kann psychologisch einen großen
Einfluss auf die Motivation und damit auf das Endergebnis haben. Außerdem
werden zu diesem Zeitpunkt die notwendigen organisatorischen Fragen geklärt.
Wie bereits angesprochen ist eine Analyse auf Grund der großen Vielfalt an
möglichen Funktionen wichtig. Die Ist-Analyse ist eine Bestandsaufnahme der
50 Vgl. Stahlknecht 2002, S. 221.
Projektbegründung
Istanalyse
Sollkonzept
Systementwurf Auswahl/Anschaffung Standardsoftware
Programmentwurf
Programmierung/Test
Systemeinführung
Anpassung Standardsoftware
Fremdbezug Eigenentwicklung
Analyse
Entwurf
Realisierung
Einführung
Vorphase
- 29 -
bisherigen Prozessabläufe und der eingesetzten Hilfsmittel. Daraus leitet sich das
Sollkonzept ab. Es enthält verbesserte Arbeitsabläufe und die notwendigen
Funktionen für das zukünftige DMS. Die Anforderungen werden normalerweise
in einem Lastenheft gesammelt.
Danach steht die Frage an, ob eine Lösung selbst entwickelt werden soll oder ob
ein Fremdprodukt eingesetzt wird. Gibt es keine sehr speziellen Anforderungen,
setzt sich hier in der Regel die Fremdbeschaffung durch. Eventuell lassen sich
besondere Anforderungen durch eine Eigenentwicklung abdecken, die dann als
Erweiterung für ein gekauftes DMS dient. Hier muss auf eine offene Architektur
der gewählten Software geachtet werden.
Für die Produktentscheidung sollte sich ein Unternehmen Zeit nehmen und
Experten zu Rate ziehen. Es kommt selten vor, dass die passgenaue Ideallösung
schon am Markt ist. Die Flexibilität der Software kann daher ein wichtiges
Kriterium sein. Die Anpassungen werden entsprechend dem Sollkonzept von
internen oder externen Mitarbeitern durchgeführt. Besonders bei einer gekauften
Software muss sich das Projektteam zu einem gewissen Grad von seinen Wunsch-
vorstellungen verabschieden. Funktionen, auf die verzichtet werden kann und die
nur mit unverhältnismäßig großem Aufwand zu realisieren sind, sollten nicht
umgesetzt werden. Die Entscheidung über die Umsetzung setzt eine
Kosten-/Nutzenanalyse voraus.
Schon vor der Fertigstellung des Systems beginnt die Phase der Einführung. Die
Projektmitarbeiter entwickeln dazu eine Strategie mit den notwendigen Schritten.
Vor allem der Übergang von den alten auf die neuen Prozessabläufe und die
Schulung der Anwender sollten detailliert geplant werden. Dazu kommen Aspekte
wie die Sicherung der Anwenderbetreuung und der technischen Pflege nach dem
Projektabschluss.
- 30 -
2.5.2 Randbedingungen
DMS müssen in bestehende Prozesse eingebunden werden. Es werden nach den
Kriterien Häufigkeit und Strukturierungsgrad vier Arten von Prozessen
unterschieden. Dabei sind situative Prozesse solche, die selten auftreten und
unstrukturiert ablaufen, beispielsweise eine Umorganisation. Diese können mit
einem DMS nur bedingt unterstützt werden. Hier lohnt sich allenfalls der Einsatz
als zentrales Ablagesystem. Treten diese unstrukturierten Prozesse häufig auf,
kann sich der Einsatz in größerem Umfang lohnen. Voraussetzung dafür ist die
Möglichkeit einer flexiblen Gestaltung der Arbeitsabläufe im DMS.
Besonders lohnend ist der Einsatz von DMS bei stark strukturierten Prozessen.
Dies gilt sowohl für häufig auftretende Prozesse, wie die Bearbeitung eines
Schadensfalls bei einer Versicherung, aber auch für weniger zahlreich auftretende
Prozesse wie beispielsweise Projekte im Anlagenbau.51
Weitere wichtige Randbedingungen beim Umgang mit Dokumenten sind der
Datenschutz sowie die Wahrung von Geschäftsgeheimnissen. Diese ethisch und
juristisch brisanten Themen müssen in jedem Fall betrachtet werden. Je nach
Betätigungsfeld finden verschiedene nationale und internationale Gesetze
Anwendung. Die Bandbreite reicht dabei vom Persönlichkeitsschutz bei
personenbezogenen Informationen bis hin zur Einhaltung von Handelsembargos,
die es Mitarbeitern einer gewissen Herkunft verbietet, in bestimmte Dokumente
Einsicht zu nehmen. Ein genereller Hinweis kann dabei nur sein, im Zweifelsfall
juristischen Rat einzuholen.
Neben Vorschriften, die per Gesetz von außen vorgegeben sind, gilt es, interne
Regelungen zu beachten. Normalerweise werden diese schon während einer
gründlichen Ist-Analyse identifiziert und dann in das Sollkonzept eingearbeitet.
Beispiele für solche Regelungen können Dokumentationsrichtlinien oder
-handbücher sein. Es ist empfehlenswert, eine solche Richtlinie aufzugreifen und
das DMS sowie die Richtlinie entsprechend anzupassen. 51 Klingelhöller 2001, S. 58 f.
- 31 -
2.5.3 Risiken
Entscheidet sich ein Unternehmen zur Eigenentwicklung eines DMS, muss es sich
über die Tragweiter dieser Entscheidung im Klaren sein. Die Weiterentwicklung
eines DMS kann gewaltige Summen und Ressourcen verschlingen, vor allem
wenn es sich um ein vollständiges System vom Scanner bis zum Archiv handelt.
Das Risiko, bei der Fremdanbieterauswahl auf das falsche Pferd zu setzen, hat
zwei maßgebende Gründe - zum einen der Markt für DMS selbst, zum anderen
das Wesen der Software. Die Zahl der Anbieter ist in den letzten Jahren stark
geschrumpft. Diese Reduktion brachte ein Auslaufen der Wartung und Weiter-
entwicklung vieler Produkte mit sich. Hat sich ein Unternehmen für ein solches
DMS entschieden, ist es früher oder später gezwungen, auf ein anderes System
umzusteigen.
Ein solcher Wechsel der Software ist bei DMS besonders aufwendig. DMS sind
keine autarken Systeme und erfüllen allein keine betriebswirtschaftliche Aufgabe.
Sie sind oft in eine Vielzahl von Unternehmensprozessen eingebunden und eine
große Anzahl an Mitarbeitern arbeitet mit ihnen.52
Wird ein DMS abgelöst, stellt sich als erstes die Frage, was mit dem darin
enthaltenen Inhalt geschieht. Aktive Dokumente laufender Geschäftsprozesse
müssen in das neue System übernommen und der Zugriff auf das Archiv
gewährleistet werden. Der Übergang muss dabei vollkommen fließend sein, da
ohne das DMS und den Inhalten die damit unterstützten Geschäftsprozesse nicht
effizient durchführbar sind.
Das zweite große Risiko bei DMS sind Akzeptanzprobleme. Die wichtigsten
Gründe sind Ergonomie, Vertrauen und Degeneration. An erster Stelle steht die
Ergonomie. Soll Papier durch elektronische Dokumente abgelöst werden, müssen
sich die Vorteile des Papiers vor Augen geführt werden. Nichts lässt sich so
angenehm lesen wie Papier. Es muss nicht selbst leuchten wie ein Bildschirm und
52 Götzer 2004, Seite 100 ff.
- 32 -
hat im Normalfall keine Probleme mit Kontrast und Auflösung. Jeder kann
Papierdokumente ohne elektronische Hilfsmittel anfassen, darin blättern, leicht
überall mit hinnehmen und handschriftliche Notizen darauf machen. Soll der
Inhalt lange aufbewahrt und für Unbefugte unzugänglich gemacht werden, wird
das Papier in einen Tresor geschlossen oder anderweitig physisch unzugänglich
gemacht.
All diese Vorteile tragen dazu bei, dass Papier auch heute noch in großen Mengen
eingesetzt wird. Versuche, Papier mit technischen Mitteln komplett zu ersetzen,
sind bisher meist gescheitert. Es müssen sich für den Einsatz von DMS also
Anwendungsfälle überlegt werden, bei denen die Vorteile des elektronischen
Abbilds überwiegen. Zusätzlich darf das DMS keinen unnötigen Aufwand
erfordern und muss so leicht wie möglich zu bedienen sein. Dazu gehört eine
angenehme Benutzerführung sowie eine ergonomische Einrichtung der
Arbeitsplätze.
In einem DMS werden mehr Informationen erfasst, als bei der Bearbeitung von
Papierdokumenten. Einzelne Bearbeitungsschritte werden mitprotokolliert und
Fehler lassen sich leicht den Verursachern zuordnen. Die Arbeit der Mitarbeiter
wird damit durchsichtiger, was vom Management zwar positiv, von den
Mitarbeitern selbst eventuell jedoch negativ beurteilt wird. Das Vertrauen in das
System und die Unbeschwertheit bei der Benutzung sinken. Soll das DMS als
Grundlage für das Wissensmanagement eingesetzt werden, ist diese Gefahr noch
wesentlich größer.53 Mitarbeiter ohne das Vertrauen, dem System alle geforderten
Informationen preiszugeben, weil sie eine Ersetzbarkeit befürchten, schaden der
Qualität des Inhalts.54
Akzeptanzprobleme sind nicht unbedingt auf die Einführung des DMS begrenzt.
Mit der Degeneration besteht die Gefahr, dass die Nutzung eines anfangs
erfolgreichen Systems mit der Zeit abgelehnt oder unwirtschaftlich wird. Ein
53 Siehe hierzu Kapitel 2.2 Dokumente im Wissensmanagement. 54 Vgl. weiterführend Huotari, Maija-Leena / Iivonen, Mirja, Trust in Knowledge Management & Systems in Organizations, Hershey, 2004.
- 33 -
neues DMS enthält im Normalfall keine Dokumente, während des Einführungs-
projektes kommt dann ein Grundstock an Dokumenten hinzu. Danach werden
Dokumente zumeist einzeln oder in kleinen Gruppen in das DMS eingespielt. Oft
geschieht diese Übernahme durch verschiedene Mitarbeiter. Folglich können
flexible Systeme durch mangelhafte Anwendung an Qualität verlieren.
Ist zum Beispiel eine Hierarchie zur Sortierung implementiert, sollte diese flexibel
sein und im Laufe der Zeit an aktuelle Entwicklungen angepasst werden können.
Diese Freiheit kann jedoch zu einem völligen Wildwuchs führen. Aber auch die
Zuordnung der Stichwörter ist bei manueller Indizierung durch Subjektivität
geprägt. Selbst der Inhalt ist in vielen Anwendungsfällen nicht hundertprozentig
objektiv. Werden lediglich Rechnungen, Anträge und ähnliche Dokumente
elektronisch erfasst, ist deren Inhalt unflexibel. Bei der Dokumentation von
Sachverhalten gibt es hingegen einen Ermessungsspielraum bei der Erstellung der
Dokumente. Das betrifft einerseits die Vollständigkeit, also die Einschätzung,
welcher Inhalt erfasst werden muss und welcher nicht. Das betrifft aber auch die
Zuordnung des Inhalts zu den einzelnen Dokumenten. Trennt ein Mitarbeiter
beispielsweise eine Programmspezifikation von der Beschreibung der Umsetzung,
kann diese Abgrenzung subjektiv gefärbt sein.
Technisch nur schwer einzugrenzen bedarf es organisatorischer Regelungen, die
diesen Arten der Degeneration vorbeugen. Das Dokumentenmanagement ist also
mehr als nur der Einsatz eines DMS. Regeln müssen aufgestellt und deren
Einhaltung von einem Verantwortlichen überprüft werden. Diese Regeln können
verbindlich in Form einer Richtlinie formuliert werden. Diese enthält dann
Anweisungen zur richtigen Benutzung des DMS. Von der Pflicht zur Benutzung
des DMS, über die Einengung der Ermessenspielräume sowie der Erfüllung von
gesetzlichen und internen Vorgaben bis hin zur Definition des gesamten
Dokumentationskonzepts kann eine Dokumentationsrichtlinie eine umfangreiche
Aufgabe sein und sich deshalb gut für eine Diplomarbeit eignen.
- 34 -
3 Dokumentation
3.1 Dokumentation technischer Systeme
Der Begriff der Dokumentation bezeichnet die Nutzbarmachung von
Informationen. Bedeutsam wurde die Dokumentation im Bereich technischer
Systeme durch steigende Komplexität der Entwicklung und Anwendung.
Heute ist die technische Dokumentation mit einer Vielzahl von Normen
standardisiert und in einigen Fällen durch Gesetze erforderlich. So zählt
beispielsweise eine angemessene Dokumentation juristisch als Produktbestandteil.
Ein Fehlen kann also zu einem erheblichen Sachmangel nach bürgerlichem Recht
führen.
Eine grobe Einteilung der Dokumentation lässt sich nach der Zielgruppe
vornehmen. Die typischen Zielgruppen sind Entwickler und Anwender, eine
genauere Unterteilung ist von den Eigenschaften des technischen Systems
abhängig. Zur Erstellung technischer Dokumentation stellt der Markt eine große
Auswahl an Literatur zur Verfügung.
Das Wort Dokumentation muss trotz der linguistischen Verwandtschaft zum
Begriff Dokument nicht unbedingt viel damit zu tun haben. Dokumentation ist
nicht an die Dokumentenform gebunden, obgleich sie den Regelfall bildet. Ein
DMS verlangt Dokumente, es lässt sich demnach nur einsetzen, wenn die
Dokumentation in Dokumentenform vorhanden ist. Ein Gegenbeispiel ist eine
eingebettete Dokumentation. Hier ist die Dokumentation fest mit dem System
verbunden, es existieren keine einzelnen Dokumente. Im Bereich der Software
können dies Hilfetexte sein, die fest mit der Anwenderschnittstelle verankert sind
und nicht ohne weiteres extrahiert werden können. Diese Fälle werden an dieser
Stelle nicht weiter betrachtet.
Die Bedeutung der Dokumentation als Kostenfaktor wird häufig unterschätzt. In
der Softwareentwicklung kann eine gute Anwenderdokumentation zwischen 20
- 35 -
und 30 Prozent der Projektkosten ausmachen. Steht die Erstellung der
Dokumentation als letzter Punkt im Projektplan und wurde sie dann nicht mit den
notwendigen Ressourcen eingeplant, fehlt es häufig an Zeit und Geld.55 Außerdem
empfinden Programmierer Dokumentationspflichten erfahrungsgemäß als lästige
Arbeit, deren unmittelbarer Nutzen nicht sofort gesehen wird.
Um dieses Problem zu lösen, wird Dokumentation in die Programmierung mit
eingebunden und technische Hilfsmittel zur Dokumentation eingesetzt. Beispiele
sind die automatische Erstellung von Dokumentationsstrukturen auf Grundlage
von Quellcode, die automatische Sammlung von Kommentaren aus der
Programmierung oder computergestützte Erstellung von Videofilmen bei der
Benutzung der Software zur Erstellung einer Anleitung.
3.2 Dokumentation betrieblicher Informationssysteme
Betriebliche Informationssysteme umfassen Hard- und Software, die für die
Unterstützung betriebswirtschaftlicher Vorgänge in Unternehmen eingesetzt
werden. Ein erster großer Teil der technischen Dokumentation wird von den
Herstellern, ein zweiter bei der Einführung im Unternehmen erstellt.
Die während des Einführungsprojekts entstandene technische Dokumentation
bildet dabei einen Teil der Projektdokumentation, in Umkehrung umfasst die
Projektdokumentation nicht die gesamte technische Dokumentation, geht aber an
anderen Stellen über sie hinaus. Genau hierin liegt ein Problem. Eine
Projektdokumentation umfasst umfangreiche Sammlungen von Dokumenten für
viele Aspekt des Projektes. Es werden Kostenschätzungen, Machbarkeitsstudien,
Projektpläne und viele weitere Dokumente erstellt, die das fertige System in
keiner Weise beschreiben.
55 Vgl. Krcmar, Helmut, Informationsmanagement, 4. Aufl., Berlin / Heidelberg, 2005, S. 164.
- 36 -
Literatur zur Dokumentation während der Softwareerstellung gibt es in Hülle und
Fülle. Dieser Bereich ist durch verschiedene Normen bereits standardisiert.56
Auch auf der Seite der Projekte ist Dokumentation ein ausgiebig behandeltes
Thema. Richtlinien zur Projektdokumentation finden sich in vielen Werken zum
Projektmanagement.
Ein Mangel herrscht hingegen an Literatur zur Dokumentation von in Betrieb
befindlicher Software. Die Betreuung des Systems übernimmt in der Regel eine
andere Organisation als die Projektdurchführung, da sich eine Projektorganisation
nicht für die längerfristige Wartung und Pflege eignet. Außerdem werden zur
Wartung meist weniger Ressourcen als für die Einführung benötigt.
Die Entwicklung der Dokumentation nach Abschluss des Einführungsprojektes
geschieht häufig auf Grundlage gewachsener Methoden innerhalb der
Supportorganisation. Die inhaltliche Grundlage der Dokumentation bildet zumeist
die Projektdokumentation des Einführungsprojekts. Das Problem bei der
Übergabe sind die typische Einteilung der Dokumente nach Projektphasen und die
vielen Projektdokumente ohne direkten Bezug zum System. Weitere externe
Quellen sind die vom Hersteller mitgelieferte Systemdokumentation, Dokumente
aus Prozessdokumentationsprojekten sowie eine Vielzahl von Dokumentationen
fremder Systeme, zu denen Schnittstellen existieren.
Dieser Grundstock an Informationen wird im Laufe der Zeit durch die Support-
mitarbeiter ergänzt und verändert. Ohne die Definition klarer Regeln besteht die
Gefahr eines schleichenden Qualitätsverlustes. Dies kann sich zum Beispiel in der
Degeneration der Strukturierung, schlechterer inhaltlicher Qualität sowie
fehlender Vergleichbarkeit äußern.
Die beiden typischen Nutzergruppen der Dokumentation, Entwickler und
Anwender, werden bei betrieblichen Informationssystemen um Administratoren,
interne Revisoren, externe Wirtschaftsprüfer und Supportmitarbeiter ergänzt. Die
56 Vgl. weiterführend Deutsches Institut für Normung, DIN 66230: Programmdokumentation, DIN 66231 Programmentwicklungsdokumentation.
- 37 -
Ziele der Nutzergruppen sind sehr unterschiedlich. Revisoren und Prüfer
benötigen möglichst formale Informationen für einen Vergleich mit den
gesetzlichen bzw. internen Vorgaben. Für Administratoren und Support-
mitarbeiter dient die Dokumentation zur Erleichterung der Arbeit. Das Ziel ist, für
den reibungslosen Betrieb relevante Informationen schnell zu finden. Dies
umfasst stark formales Wissen, wie Tabelleninhalte und vorgenommene
Einstellungen, aber auch wenig formales Problemlösungswissen.
Das nachfolgende Kapitel beschreibt eine konkrete Dokumentationsrichtlinie und
deren Umsetzung für laufende betriebliche Informationssysteme. Zentraler
Ausgangspunkt des dazugehörigen Konzepts bildet die Supportorganisation. Zu
den Mitgliedern dieser Organisation zählen Systemverantwortliche,
Administratoren und Programmierer. Weitere Nutzer sind interne und externe
Prüfer sowie Projekte zur Erweiterung oder Konsolidierung der Systeme.
4 Dokumentationsrichtlinie
4.1 Aufgabe
Im Rahmen der Diplomarbeit ist es die Aufgabe, die theoretischen Erkenntnisse
eines modernen Dokumentations- und Dokumentenmanagementkonzeptes in
einem praktischen Fall anzuwenden. Dabei handelt es sich im Konkreten um eine
Problemstellung bei Siemens Power Generation. Im Rahmen eines
Migrationsprojekts soll die Dokumentation der dort aktiven Applikationen
vereinheitlicht werden.
Die Aufgabenstellung ist dabei die Schaffung einer Dokumentationsrichtlinie.
Diese Richtlinie wird verbindliche Regelungen für die Erstellung, Ablage und
Verwaltung verschiedener Dokumente enthalten. Neben den eigentlichen Normen
sind zur Einhaltung notwendige Informationen beigefügt.
Umgesetzt wird diese Dokumentationsrichtlinie durch Softwareunterstützung
mittels der Software Solution Manager der Firma SAP. Aus Sicht einer
- 38 -
Projektorganisation dient die Richtlinie als Vorgabe, die durch die Software
abgebildet wird. Nach Abschluss des Projektes dient die Richtlinie als Vorschrift
zur Verwendung der Software. So werden beispielsweise die nach der
Dokumentationsrichtlinie definierten Statuswerte durch Anpassung der Software
voreingestellt. Bei der Benutzung schlägt die Software diese definierten
Statuswerte vor. Der richtige Status ist natürlich inhaltlich bestimmt. Der
Benutzer wählt dann nach den Vorgaben der Richtlinie den passenden Wert aus.
Der letzte Teil der Aufgabenstellung beinhaltet die erste praktische Nutzung der
Diplomarbeit. Das Ziel ist die Übernahme der gesamten Dokumentation eines
betriebswirtschaftlichen Anwendungssystems in die Dokumentationssoftware
unter Einhaltung der Dokumentationsrichtlinie. Mit dieser ersten Verwendung soll
die Dokumentationsrichtlinie ihre Praktikabilität nachweisen, ein Prototyp als
Referenz für weitere Systeme geschaffen und erste Erfahrungen im Umgang mit
der Richtlinie gesammelt werden.
4.2 Einordnung
Wie bereits erwähnt, wurde das Thema dieser Diplomarbeit von Siemens Power
Generation vorgegeben. Power Generation bezeichnet die Sparte der Kraftwerk-
technik innerhalb des Siemenskonzerns. Abbildung 6 zeigt die Organisations-
hierarchie der Siemens AG.
- 39 -
Abbildung 6: Organisationsstruktur der Siemens AG
Der weltweit in über 190 Ländern aktive Siemenskonzern mit mehr als 400.000
Beschäftigten ist in fünf Arbeitsgebieten tätig, eines davon ist Power und umfasst
die Geschäftsbereiche Power Transmission and Distribution sowie Power
Generation. Siemens Power Generation ist der Nutzer dieser Dokumentations-
richtlinie. Mit seinen rund 33.000 Mitarbeitern ist Siemens Power Generation ein
mittelgroßer Geschäftsbereich. Jedes bei Siemens Power Generation aktive SAP-
System soll anhand dieser Richtlinie dokumentiert werden. Verantwortlich für die
Betreuung der SAP-Systeme ist der Fachzweig Information Technology, der in
Zusammenarbeit mit externen Unternehmen die Anwendungssysteme für die
Fachabteilungen bereitstellt.
Innerhalb des Fachzweigs Information Technology werden Segmente und
dazugehörige Abteilungen unterschieden. Die kleinsten organisatorischen
Einheiten bilden die Gruppen. Sie sind hierarchisch unterhalb der Abteilungen
angeordnet.
s Arbeitsgebiet
Geschäftsbereich
Fachzweig
Segment
Abteilung
Gruppe
PPOOWWEERR TTRRAANNSSPPOORRTTAATTIIOONN MMEEDDIICCAALL
PPOOWWEERR
GGEENNEERRAATTIIOONN PPOOWWEERR TTRRAANNSSMMIISSSSIIOONN &&
DDIISSTTRRIIBBUUTTIIOONN
IINNFFOORRMMAATTIIOONN
TTEECCHHNNOOLLOOGGYY HHUUMMAANN
RREESSSSOOUURRCCEE WWIINNDD
PPOOWWEERR IINNDDUUSSTTRRIIAALL
AAPPPPLLIICCAATTIIOONN
IITT 11 EEuurrooppaa,, mmiittttlleerreerr OOsstteenn,,
AAssiieenn,, ffüürr PPGG EE,, LL,, uunndd
ggeemmeeiinnssaammee AAuuffggaabbeenn
IITT 22 EEuurrooppaa,, mmiittttlleerreerr OOsstteenn,,
AAssiieenn,, ffüürr PPGG PP,, RR,,
IITT 1122 SSeerrvviiccee ffüürr ggeemmeeiinnssaammee
AAuuffggaabbeenn
IITT 1133 SSeerrvviiccee ffüürr PPGG EE
IITT 112211 FFiinnaannzzeenn,, BBuucchhffüühhrruunngg,,
CCoonnttrroolllliinngg
IITT 112222 FFiinnaannzzooppeerraattiioonn,, SSAAPP
CCaattss,, eexxtteerrnneerr SSuuppppoorrtt
- 40 -
Projekte bei Siemens Power Generation werden über die Grenzen der
organisatorischen Einheiten hinweg durchgeführt. Mit dem Ziel eines heterogenen
Projektteams werden Mitarbeiter aus verschiedenen internen Organisationen
durch externes Personal unterstützt. Der Ursprung der Dokumentationsrichtlinie
ist eine Initiative des Techforum. Dieses Gremium besteht aus den System-
verantwortlichen und erstellt Empfehlungen zu einem breiten Spektrum an
technischen Themen.
Parallel zur Initiative des Techforums wurde ein Projekt zur Einführung des SAP
Solution Manager gestartet. Dieses Projekt ist Teil der sogenannten SAP
Roadmap. Dieses Projektprogramm hat zum Ziel, SAP-Systeme zu konsolidieren,
um die Anzahl von aktuell vierzehn, teilweise Multimandantensystemen, auf drei
Einmandantensysteme zu reduzieren. Im Zuge dieser Migration ergibt sich die
Notwendigkeit, die Dokumentation der zu integrierenden Systeme zu
vereinheitlichen.
Die Einführung des SAP Solution Managers ist ein Teilschritt bei dieser System-
zusammenführung. So sollen die aktuell aktiven Systeme in den SAP Solution
Manager eingebunden werden, der dann als zentrale Verwaltungsinstanz dienen
wird. Die Projektleitung hat entschieden, die vom SAP Solution Manager
bereitgestellten Funktionen für die Dokumentation und das Dokumenten-
management zu nutzen und unter einheitlichen Vorgaben für alle angebundenen
Systeme anzuwenden. Der Projektleiter hat die Verantwortung für den Projektteil
Dokumentenmanagement an Herrn Dr. Ocker von der IT 121 übertragen. Er
veröffentlichte die Problemstellung als Diplomarbeitsthema und übernahm die
fachliche Betreuung.
Zeitlich lässt sich die Diplomarbeit in die zweite Hälfte des SAP Solution
Manager-Einführungsprojektes einordnen. Der ursprüngliche Plan des Projektes
sieht einen Start am 1.12.2005 und ein Ende am 2.10.2006 vor.
- 41 -
4.3 Besonderheiten
„Der Unterschied zwischen Theorie und Praxis ist in der Praxis viel höher als in der Theorie“
ERNST FERSTEL
Wer kann diesem Zitat widersprechen? Trotzdem soll dieser Spruch nicht als
Ausrede zur Vernachlässigung der Theorie herhalten. Ein Wirtschaftsinformatiker
befindet sich immerhin in der glücklichen Lage, einer zum großen Teil
praxisorientierten Wissenschaft nachzugehen, in der die Umsetzung erarbeiteter
Theorie selten viele Jahre auf sich warten lässt.57
Wissenschaftliche Ausarbeitungen für die Dokumentation und das Dokumenten-
management sind daher zumeist praxisorientiert formuliert. Daneben existiert eine
Vielzahl an wenig wissenschaftlichen Handlungsanleitungen ohne theoretisches
Fundament. Diese fehlende Basis schränkt vor allem deren Übertragbarkeit auf
andere Umstände ein.
Bei der in Kapitel 4.1 beschriebenen Aufgabe handelt es sich nicht um ein
Bilderbuchprojekt für das Dokumentenmanagement, eine Übertragbarkeit von
wissenschaftlicher Literatur ist daher umso wichtiger. Die geplante Nutzung der
Dokumentationsrichtlinie ist auf die Dokumentation von im Betrieb befindlichen
Softwaresystemen gedacht. Es handelt sich also nur um einen kleinen Teil der im
Unternehmen anfallenden Dokumente. Für die Dokumentation von Kraftwerks-
projekten existiert bereits seit vielen Jahren ein unternehmensinternes
Dokumentationshandbuch. Dieses ist sehr umfassend und erfüllt alle rechtlichen
Anforderungen. Zur Unterstützung dieser Dokumentation kommen bereits
Dokumentenmanagementsysteme zum Einsatz. Dieses Handbuch mit seiner Fülle
an Vorschriften und der Fokussierung auf den Anlagenbau macht es für die
Dokumentation von Softwaresystemen jedoch ungeeignet. Um diesem
57 Die Physik mit ihrer Relativitätstheorie bildet hier das klassische Gegenbeispiel. Deren praktische Relevanz wurde erst Jahrzehnte später spürbar.
- 42 -
Dokumentationshandbuch trotzdem Rechnung zu tragen, wurden die Begriffe der
Richtlinie der Begriffswelt des Dokumentationshandbuchs zugeordnet.
Zum Vergleich der Größe eines typischen Projektes zum Dokumenten-
management und der vorliegenden Aufgabe zur Schaffung und Umsetzung der
Dokumentationsrichtlinie soll folgendes Zitat dienen: „Als Dokumenten-
management-Projektleiter oder als Sponsor eines Dokumentenmanagement-
projektes sind Sie Kapitän eines Tankers, nicht eines Schlauchbootes“.58 Dieses
Zitat geht von einem Dokumentenmanagementsystem aus, welches einen großen
Teil der im Unternehmen anfallenden Dokumente beinhaltet. Im Rahmen dieser
Arbeit wird nur ein kleiner Ausschnitt der Dokumente im Unternehmen
betrachtet. Es handelt sich im Gegensatz zu dem Zitat also eher um einen
Fischkutter als einen Tanker. Um den Vergleich mit Wasserfahrzeugen auf die
Spitze zu treiben: Es wird ein Fischkutter behandelt, aus dem eine Jacht werden
soll.
Ein Fakt zur Verringerung des Projektumfangs betrifft die Umsetzung der
Dokumentationsrichtlinie. Denn die bisherige Dokumentation liegt bereits
ausschließlich in digitaler Form vor. Es handelt sich dabei fast ausnahmslos um
kodierte Informationen in Form von Textdateien, die eine weitere Bearbeitung
zulassen.
Eine weitere Besonderheit des Projektes sind die späteren Nutzer. Die
Dokumentation wird vorrangig von IT-Experten genutzt. Ein Zugriff wird dabei
regelmäßig erfolgen, wodurch sich ein schneller Lerneffekt einstellen sollte,
zumal der Ausbildungshintergrund auf eine hohe Adaptionsfähigkeit von
technologiebasierten Handlungen schließen lässt. Auf Grund des wenig
heterogenen Benutzerkreises wird mit den typischen Problemen der Information
Retrieval Systeme, wie die Unkenntnis von logischen Operatoren oder
unbekannten Fachbegriffen, daher nicht gerechnet.59 Andere Nutzer, zum Beispiel
58 Klingelhöller 2001, S. 35. 59 Kroha 2004, S. 50 f.
- 43 -
die für die Revision tätigen Mitarbeiter, werden bei ihrer Suche ohnehin durch IT-
Fachkräfte unterstützt.
Inhaltlich wird eine Systemdokumentation entsprechend ihrer Natur häufigen
Änderungen unterworfen sein. Es wird sogar versucht, dies zu forcieren, indem
der Grundsatz in der Richtlinie enthalten ist, bestehende Dokumentation
fortzuschreiben anstatt neue Dokumente zu erstellen. Anders als zum Beispiel
beim Umgang mit Bewegungsdaten, werden keine riesigen Datenmengen
erwartet. Andererseits ist es sehr wichtig, relevante Information zu finden. Die
Anforderungen an die Trefferquote sind deshalb im Verhältnis zur benötigten
Präzision sehr hoch.
Ein weiterer besonderer Umstand ist die Produktentscheidung. Diese ist nämlich
im Umfeld des Projektes bereits getroffen.60 Einerseits erspart sich das Projekt-
team dadurch den mühsamen Auswahlprozess, andererseits kann es nicht das
beste Produkt wählen, sondern muss mit der bereits getroffenen Entscheidung
leben. Dabei wurde die Entscheidung unter einem anderen Fokus als dem
Dokumentenmanagement gefällt, denn beim SAP Solution Manager handelt es
sich vorrangig um ein Administrationsprogramm.
4.4 Ziele
Wie die Aufgabenstellung und die Einordnung in das Konsolidierungsprojekt
vermuten lassen, ist das Ziel eine einheitliche Dokumentation der produktiven
Anwendungssysteme innerhalb Siemens Power Generation. Im Falle der
Zusammenführung zweier Systeme gibt eine aussagekräftige Dokumentation
Hilfestellung bei der Migration, außerdem wird die Migration der Dokumentation
selbst bei einheitlicher Sortierung vereinfacht. Eine Vereinheitlichung der
Dokumentation erhöht ebenfalls die Vergleichbarkeit, was zu einem geringeren
Suchaufwand in einem fremden System führt, wenn ein anderes System bereits
bekannt ist.
60 Vgl. Kapitel „4.2 Einordnung“ und „4.3 Besonderheiten“.
- 44 -
Ein weiteres Ziel ist die Verbesserung der allgemeinen Qualität der
Dokumentation. Schon vor der Ist-Analyse war klar, dass es hier Lücken gibt. Zur
Erhöhung der Qualität sollen die bisher zum Teil vagen Vorschriften explizit
niedergeschrieben, als verbindlich deklariert und deren Umsetzung kontrolliert
werden.
Im Hinblick auf Prozessoptimierung und nicht zuletzt auf die Akzeptanzsicherung
ist es ein festgeschriebenes Ziel, ein möglichst einfaches Konzept zu erstellen.
Dazu gehört eine Ablage der Dokumentation mit möglichst wenigen Einzel-
schritten. Dem gegenüber steht die Forderung nach einer effizienten Möglichkeit,
eine abgelegte Dokumentation wieder zu finden. Beim Suchen nach
Informationen steht dabei nicht immer ein einzelnes Dokument als Ziel fest.
Deshalb wird ein besonderes Augenmerk darauf gelegt, dass ein inhaltlicher
Zusammenhang zwischen Dokumenten explizit erkennbar ist.
Zur weiteren Erhöhung der Qualität soll eine inhaltliche und gestalterische
Unterstützung bereitgestellt werden. Mit der gestalterischen Unterstützung soll ein
einheitliches Erscheinungsbild erreicht werden, ohne dass sich der einzelne
Mitarbeiter bei der Erstellung darum kümmern muss. Inhaltliche Unterstützung
soll bereitgestellt werden, indem auf die erforderlichen Punkte bei der Erstellung
hingewiesen wird. So soll ausgeschlossen werden, dass notwendige Informationen
bei der Erstellung eines Dokuments vergessen werden.
Im Bezug auf die Sprache der Dokumentation wird vom Dokumentationskonzept
Neutralität verlangt. Siemens Power Generation ist ein internationales
Unternehmen. Durch seine deutschen Wurzeln ist nach wie vor ein Großteil der
Dokumentation in Deutsch. Durch Zukäufe in anderen Ländern kamen andere
Sprachen hinzu. Vor allem Englisch ist durch große Akquisitionen in den USA
und durch die häufige Verwendung bei Kommunikation unter Mitarbeitern
verschiedener Nationen ein wichtiger Faktor, den es zu beachten gilt. Es ist nicht
sinnvoll, Englisch als verbindlich für die Benutzung in jeglichen Bereichen
vorzuschreiben. Das Ziel ist also, mit dem Dokumentationskonzept der Richtlinie
nicht auf eine Sprache festgelegt zu sein. Englisch kann dabei zwar in gewissem
- 45 -
Rahmen bei jedem Mitarbeiter vorausgesetzt werden, ein Zwang zur vollständigen
Arbeit in einer Fremdsprache soll jedoch nicht ausgeübt werden.
Die Dokumentationsrichtlinie soll die Qualitätssicherung unterstützen. Für ein
Qualitätsmanagementsystem sind in den dafür üblichen Normen Dokumentations-
pflichten enthalten. In diesem Rahmen hat vor allem die DIN EN ISO 9000er
Normreihe viel Aufsehen erregt. Obwohl die derzeitige Bedeutung des
Zertifikates nicht immer die Erwartungen erfüllt hat,61 ist zumindest dessen
Verbreitung in Deutschland über die Erwartungen hinaus gewachsen.62 Die
angesprochenen Normen schreiben ein dokumentiertes Qualitätssicherungssystem
vor.63 Die aktuell enthaltenen Pflichten sind dabei zwar gegenüber der 1994
veröffentlichen Ausgabe vereinfacht worden, stellen aber immer noch
umfangreiche Anforderungen. Nach der ISO-9000-Unterstützungsanleitung des
Deutschen Instituts für Normung wird ausdrücklich erwähnt, dass Dokumente zu
erstellen sind, wenn diese das Qualitätsmanagement unterstützen. Dazu sind unter
anderem Prozesspläne, Spezifikation und Testanleitungen angeführt.64 Diese
Dokumente sollen innerhalb der Dokumentationsrichtlinie gefordert und deren
Auffindbarkeit sichergestellt werden.
Noch umfangreichere Dokumentationspflichten sind in dem für Siemens
obligatorischen Sarbanes-Oxley-Act enthalten. Dieses Gesetz aus dem Jahre 2002
ist als Reaktion auf die großen Bilanzskandale von amerikanischen Unternehmen
entstanden und ist für alle aktienemittierenden Unternehmen gültig, die an US-
amerikanischen Börsen notiert sind. Die Siemens AG ist seit 2001 am New York
Stock Exchange gelistet, womit das Gesetz Anwendung findet.
Die Sektionen 302 und 404 des Sarbanes-Oxley-Act schreiben eine Prozess-
dokumentation für bilanzkritische Prozesse vor. Im Fokus stehen hier Prozesse,
61 Vgl. Walgenbach, Peter, Die normgerechte Organisation, eine Studie über die Entstehung, Verbreitung und Nutzung der DIN EN ISO 9000er Normreihe, Stuttgart, 2000, Seite 415 ff. 62 Vgl. ebenda, S. 3f. 63 Deutsches Institut für Normung, DIN EN ISO 9001:2000, Abschnitt 4.1. 64 Deutsches Institut für Normung, ISO 9000 Unterstützungsanleitung, S. 17 f.
- 46 -
aus der Risiken für die Finanzberichterstattung und entsprechende Kontrollen
abgeleitet werden.65 Eine zusätzliche Forderung des Sarbanes-Oxley-Act ist die
Nachvollziehbarkeit bei der Entwicklung der Dokumente. Diese Vorgaben sind
bei der Erstellung der Dokumentationsrichtlinie zu beachten.
Ein eigentlich selbstverständliches Ziel bei der Schaffung einer Dokumentation ist
die Bereitstellung einer Wissensquelle. Schließlich soll die Dokumentation für
Mitarbeiter die erste Anlaufstelle bei Fragen zu den Systemen sein. Dieses Ziel
setzt voraus, dass jegliche sinnvolle Information dokumentiert werden kann. Es
sollen nicht nur technische Fakten, sondern auch der Umgang mit der Software
dokumentiert werden. Das geht soweit, dass Mitarbeitern der Freiraum gegeben
wird, ihre persönlichen Erfahrungen niederzuschreiben, wenn diese im
Zusammenhang mit dem System auch für andere Mitarbeiter interessant sind.
Eine solche Dokumentation muss von technischen Fakten jedoch erkennbar
getrennt werden.
4.5 Ist-Analyse
4.5.1 Systemlandschaft
Der Erstellung der Dokumentationsrichtlinie ist eine umfangreiche Ist-Analyse
vorausgegangen. Die Richtlinie soll alle aktiven SAP-Systeme betreffen, die nach
einheitlichen Kriterien dokumentiert werden sollen. Die derzeitige System-
landschaft umfasst vierzehn Systemlinien. Zu einer Systemlinie gehören mehrere
gleichartige Installationen von SAP-Systemen. Innerhalb einer solchen Linie ist
jeweils ein Produktivsystem enthalten, auf dem der Tagesbetrieb abgewickelt
wird. Dazu kommen je nach Umfang der Lösung Entwicklungs-, Test-, Qualitäts-
sicherungs-, Schulungs- und Demonstrationssysteme. Aus Sicht der
Administration und Dokumentation gehören die einzelnen Installationen einer
Systemlinie soweit zusammen, dass zwischen ihnen nicht unterschieden wird und
65 Menzies, Christoph, Sarbanes-Oxley-Act, Professionelles Management interner Kontrollen, Stuttgart, 2004, S. 277.
- 47 -
eine gesamte Linie als System bezeichnet wird. So wird es auch im Rahmen
dieser Arbeit gehandhabt.
Die einzelnen Systeme sind mit einer Vielzahl an Schnittstellen untereinander
verbunden. Abbildung 7 stellt die Systemlandschaft innerhalb von Siemens Power
Generation grafisch dar. Das Ziel dieser Abbildung ist, einen Eindruck über die
Komplexität zu vermitteln. Zur Wahrung des Betriebsgeheimnisses ist die
Darstellung um einige Informationen erleichtert worden. Die verlorenen
Informationen sind aber in keiner Weise für diesen Rahmen wichtig. Die Pfeile
zwischen den einzelnen Objekten muten zwar recht chaotisch an, sind aber
keineswegs zufällig eingezeichnet. Sie zeigen die Verbindungen der einzelnen
Systeme.
Abbildung 7: Systemlandschaft bei Siemens PG66
Für alle aktiven Systeme existiert eine Dokumentation. Durch die unterschiedliche
Größe der einzelnen Systeme ist auch der Umfang der Systemdokumentationen
verschieden. Selbst bei den kleineren Systemen ist die Fülle an Informationen
66 Hertel, Hellmut, Kick-Off-Meeting Solution Manager-Projekt, Erlangen, 2006, S. 3 (Abbildung teilweise geschwärzt).
- 48 -
nicht mehr ohne weiteres beherrschbar. Zur Verdeutlichung sollen zwei Zahlen-
beispiele dienen. Das im Durchschnitt eher kleine System mit der Identifikation
P29, ein SAP EBP-System, besitzt zur Dokumentation rund 1500 Dateien in rund
200 Ordnern und einer Gesamtgröße von fast einem Gigabyte. Diese
Dokumentation soll im Rahmen dieser Diplomarbeit unter Anwendung der
Dokumentationsrichtlinie übertragen werden. Eines der größeren Systeme
übertrifft die Größe des EBP-Systems bei weitem. Hier sind 23.000 Dokumente
auf 5.200 Ordner verteilt. Die Dateien haben eine Gesamtgröße von 15 Gigabyte.
Die Verteilung der Dateien auf die einzelnen Ordner ist dabei nicht gleichmäßig.
Neben vielen leeren Ordnern existieren solche mit über hundert Dateien.
4.5.2 Befragung
Da kein Zugriff auf die Dokumentation aller Systeme existiert, und zur
Erforschung der Meinungen über die Dokumentation, wurde eine Befragung
durchgeführt. Die Fachliteratur kennt drei Formen der Befragung: Das persönliche
Interview, ein telefonisches Interview und das Questionaire, also die schriftliche
Befragung. Prinzipiell sind alle drei Formen für diesen Zweck denkbar.67 Als
Grundlage für eine umfassende Analyse wurde zur schriftlichen Befragung ein
Questionaire erarbeitet.
Die wissenschaftliche Grundlage für die Erstellung des Fragebogens bildeten
Quellen aus der Soziologie, da diese Disziplin über sehr große Erfahrung auf
diesem Gebiet verfügt. Die Problematik bestand in der Anpassung an die
gegebenen Bedingungen, die für die empirische Forschung keinen klassischen
Anwendungsfall darstellen. Von den vier existierenden Fragetypen konnten
lediglich zwei sinnvoll verwendet werden.
Auf Fragen zur Sammlung statistischer Angaben konnte verzichtet werden, weil
die angesprochene Zielgruppe sowohl vom Namen also auch von der Position her
bekannt war. Verhaltensfragen der Personen hätten durchaus Informationen
liefern können, hätten den Fragebogen aber stark vergrößert, weshalb auch diese 67 Diekmann, Andreas, Empirische Sozialforschung, 10. Auflage, Reinbek, 2003, Seite 373.
- 49 -
ausgespart wurden. Zum großen Teil wurde nach den Überzeugungen gefragt.
Dazu zählen an erster Stelle Fakten- und Wissensfragen. Weil sich die Fragen auf
das Fachgebiet der einzelnen Person beziehen, kann bei den Antworten von
Richtigkeit ausgegangen werden. Einen kleineren Teil nehmen Einstellungen und
Bewertungen ein. Hier zielen die Fragen auf eine subjektive Bewertung anhand
eigener Erfahrungen ab.68
Die Fragen und ihre Antwortmöglichkeiten im Einzelnen sind:69
1. Gibt es eine Anweisung für die Handhabung Ihrer SAP Dokumentation, aus der ein Teil unserer Fragen beantwortet werden könnte?
● Antwortmöglichkeiten: nein, ja - welche:…
2. Welche Arten von Dokumenten verwenden Sie?
● Antwortmöglichkeiten: Prozessbeschreibung, Spezifikation, Testbeschreibungen, Bedienungsanleitungen/Verfahrensdokumentation, Servicedokumentation, Weitere:…
3. Welches System für die Ablage der Dokumentation des SAP Systems wird verwendet?
● Antwortmöglichkeiten: Dateisystem, MS-Sharepoint, SAP Solution Manager, Anderes:…
4. Erfolgt dabei eine Steuerung des Zugriffs - z.B. über Zugriffsrechte?
● Antwortmöglichkeiten: nein, ja
5. Nach welchem Kriterium ist dort sortiert oder kann sortiert werden?
● Antwortmöglichkeiten: nach inhaltlich zusammengefassten Themen, Modulen/Funktion, Dokumentenartarten, Prozessabläufen, Autoren, Anderes:…
6. Wie erfolgt die Berücksichtigung von Veränderungen der Dokumente?
● Antwortmöglichkeiten:
• Unterscheidung von Versionen je Dokument - auf alle Versionen kann im o.g. System zugegriffen werden
• Nur aktueller Stand des Dokuments ist verfügbar
• Nur aktueller Stand des Dokuments ist im o.g. Ablagesystem verfügbar, aber ältere Stände können bei Bedarf beschafft werden.
68 Diekmann 2003, S. 404 ff. 69 Um Erläuterungen gekürzte Fassung, vollständiger Fragebogen siehe Anhang 1, S. 95ff.
- 50 -
• Nur aktueller Stand des Dokuments ist im o.g. Ablagesystem verfügbar, aber alte Stände sind lückenlos archiviert
7. Erfahrungen
● Wiederfinden von Dokumenten:
• Antwortmöglichkeiten: Gut, Mäßig, Weniger gut
● Änderungshistorie / Versionsverfolgung
• Antwortmöglichkeiten: Gut, Mäßig, Weniger gut
● Zuordnung zusammengehöriger Dokumente
• Antwortmöglichkeiten: Gut, Mäßig, Weniger gut
8. Pflegezustand der Daten
● Aktualität
• Antwortmöglichkeiten: Aktuell, Teilweise nicht aktuell, Große Teile veraltet
● Vollständigkeit
• Antwortmöglichkeiten: Vollständig, Teilweise unvollständig, Große Lücken
9. Allgemeine Bewertung
● Verfahren/System
• Antwortmöglichkeiten: Gut, Mäßig, Weniger gut
● Qualität der Dokumentation
• Antwortmöglichkeiten: Gut, Mäßig, Weniger gut
10. Hinweise, Besonderheiten, Erläuterungen
● keine vorgegebenen Antwortmöglichkeiten
Geschlossene Fragen bilden die Mehrheit. Die enthaltenen Hybridfragen bieten
mit Ausnahme der ersten Frage lediglich die Möglichkeit, die vorgegebenen
Antwortmöglichkeiten um weitere zu ergänzen. Die Beantwortung der letzten
Frage ist klar und deutlich als freiwillig gekennzeichnet worden. Als offene Frage
gibt sie die Möglichkeit, ohne festen Rahmen verbale Erläuterungen festzuhalten.
Die Beantwortung der geschlossenen und halboffenen Fragen wurde absichtlich
nicht auf eine Alternative beschränkt, auch wenn dies teilweise inhaltlich
plausibel erscheint. Den Befragten wurde insofern Vertrauen entgegengebracht.
Im Nachhinein stellte sich das als Vorteil heraus, da wider Erwarten in mehreren
- 51 -
Fällen für ein System verschiedene Dokumentationskonzepte verwendet werden.
Diese konnten so differenziert bewertet werden.
Die Fragen 1 bis 6 sowie 8 dienen dazu, objektive Daten über die bisherige
Dokumentation zu sammeln. Anhand dieser Informationen können die Überein-
stimmungen der bisher verwendeten Systeme abgeschätzt werden. Eine große
Vielfalt an vorhandenen Systemen bedeutet einen erhöhten Integrationsaufwand,
weil dann viele Migrationsstrategien zu entwickeln sind. Wenn der Fall
eingetreten wäre, dass jemand bereits den SAP Solution Manager einsetzt, hätte
bereits auf ein Musterverfahren zurückgegriffen werden können. Durch Abfrage
der bisher vorhandenen Funktionalität in Bezug auf Sortierkriterien und Versions-
verfügbarkeit können wertvolle Hinweise auf die Mindestanforderungen eines
neuen Konzeptes abgeleitet werden. Mit den Fragen 7, 8 und 9 sollte der Zustand
und die Zufriedenheit mit der bisherigen Dokumentation in Erfahrung gebracht
werden. Das lässt bereits in dieser frühen Phase Rückschlüsse auf die Akzeptanz-
bereitschaft zu. Weil bereits klar war, auf welcher technischen Grundlage die
zukünftige Dokumentationsrichtlinie basiert, wurde rein retrospektiv gefragt.
Nach der Erstellung in Deutsch wurde der Fragebogen übersetzt und an 24
Personen in einer zweisprachigen Version weitergeleitet. Die Anzahl von 24
Empfängern gilt hierbei aber nicht als die Gesamtbefragungsmenge. Da es sich
weiterhin um nur vierzehn Systeme handelt, wurden auch nur maximal vierzehn
Antworten erwartet. Die Rücklaufquote wird demnach auf Basis von N=14
berechnet.
4.5.3 Auswertung70
Mit zehn Rückläufen vor dem festgesetzten Rückgabetermin und einer
Verspätung ergibt sich eine Rücklaufquote von fast 80 Prozent und liegt damit
über den Erwartungen. Wie die Versendung wurde auch die Auswertung nicht
anonymisiert.
70 Vollständige Ergebnisse siehe Anhang 2, S. 99 ff.
- 52 -
Eine komplexe mathematische Bearbeitung der Ergebnisse ist bei der
überschaubaren Anzahl von elf Fragebögen nicht sinnvoll. Weder eine
Bereinigung der Daten noch eine Item-Konsistenzanalyse wurde durchgeführt.
Einzig und allein anhand des zweiten Teils der neunten Frage konnte in einem
begrenzten Rahmen die Plausibilität der vorherigen Antworten überprüft werden.
Die Beantwortung war bis auf wenige Ausnahmen vollständig, den Platz für
weitere Anmerkungen nutzten lediglich drei Befragte. Die Qualität der Antworten
war hoch, teilweise wurden zusätzliche Kommentare zur Erläuterung im
Fragebogen eingefügt. Die wenigen unverständlichen Mehrfachantworten werden
bei der Auswertung übergangen oder gesondert erwähnt.
Die Auswertung der ersten Frage führte lediglich zur Konsultation der eventuell
vorhandenen Vorschriften. Die Frage nach den Dokumentationsarten zeigte, dass
alle vorgegebenen Dokumentationsarten von mindestens der Hälfte benutzt und
keine Dokumente einer anderen Art verwendet werden.
Die dritte Frage brachte als Ergebnis die Dominanz des Dateisystems zur Ablage
der Dokumentation zum Vorschein. Die folgende Abbildung stellt das Verhältnis
der Nutzung des Dateisystems zur Gesamtheit der Alternativen dar.
Nutzung des Dateisystems
5
1
5
exklusive Nutzung parallele Nutzung keine Nutzung
Abbildung 8: Dominanz des Dateisystems zur Ablage der Dokumentation
- 53 -
Nur ein System wird vollständig mit Hilfe von Lotus Notes dokumentiert. Zur
Unterstützung des Dateisystems nutzen zwei Befragte Lotus Notes, einer
Microsoft-Sharepoint, ein anderer das Intranet und ein letztes System nutzt eine
Vielzahl verschiedener weiterer Systeme. In fünf Fällen legen die
Verantwortlichen sämtliche Dokumentation im Dateisystem ab. Dieses Ergebnis
ist Studien zufolge nicht ungewöhnlich.71 Über Erfahrungen mit dem SAP
Solution Manager verfügt offenbar keiner der Befragten.
Die Frage nach der Zugriffssteuerung ergab, dass fünf Systeme, und damit fast die
Hälfte, zumindest teilweise einen ungeschützten Zugriff auf die Dokumentation
erlauben.
Die fünfte Frage zeigte ohne große Überraschung, dass die Strukturierung nach
funktionalen Einheiten tonangebend ist. Mit nur drei Nennungen war die
Prozessorientierung bei dieser Frage nur schwach vertreten. Die anderen
Möglichkeiten wurden jeweils zwei mal genannt. Abbildung 9 stellt die besondere
Bedeutung der funktionalen Strukturierung grafisch dar. Parallel zum vorherigen
Kreisdiagramm erfolgt eine Illustration des Verhältnisses der dominierenden
Antwortmöglichkeit zu allen Alternativen.
71 Hinrichts, Joachim, Kontextindexierung – Dokumentenmanagement im Spannungsfeld zwischen arbeitsorganisatorischer Kompetenz und Knowledge Engineering, Ein Dokumentationskonzept zur Indexierung von Kontexten und Arbeitsständen auf Basis elektronischer Ordnerstrukturen, Dissertation, Aachen 2003, Seite: 43 f.
- 54 -
Funktional orientierte Strukturierung
4
1
1
5
Ausschließlich funktional Unter anderem FunktionalNicht funktional Keine Antwort
Abbildung 9: Anzahl funktional strukturierter
Dokumentationsverfahren
Um es vorweg zu nehmen, sowohl die Bedeutung des Dateisystems als auch die
der funktionalen Strukturierung beeinflussen das zu entwickelnde
Dokumentationskonzept. Diese Einflussnahme begründet sich mit der These, dass
sich die Dominanzen auf Grund von Überlegenheit gegenüber anderen Konzepten
entwickelt haben. Immerhin geschahen die Entwicklungen ohne zentrale Weisung
unabhängig voneinander. Außerdem verringert sich so der Integrationsaufwand,
da vorhandene Strukturen teilweise übernommen werden können.
Die Möglichkeiten zur Rückverfolgung von Änderungen zeigen deutliche
Schwächen. In nur zwei Fällen können die Dokumentationsverantwortlichen der
einzelnen Systeme lückenlos, in drei Fällen teilweise auf alte Stände
zurückgreifen. Fünf Dokumentationsverfahren stellen nur die jeweils aktuelle
Version zur Verfügung. Ein Befragter ließ diese Frage unbeantwortet.
Die Erfahrungen in Bezug auf die Lokalisierung abgelegter Dokumente und dem
Finden von dazugehörigen Informationen in anderen Dokumenten wurden im
Schnitt mit mäßig bewertet. Parallel zur Frage nach verfügbaren Dokumenten-
versionen ist die Nachverfolgung der Änderungen eher schwierig und wurde
demzufolge eher schlecht bewertet.
- 55 -
Nach der Auswertung der achten Frage ergibt sich im Durchschnitt eine mittlere
bis gute Aktualität und eine mittlere Vollständigkeit. Trotzdem gibt es einen Fall
mit stark veralteten und drei Fälle mit sehr lückenhaften Daten.72 Besonders
brisant ist das Zusammentreffen von schlechter Aktualität und großen Schwächen
bei der Vollständigkeit in einer Dokumentation.
Vom eigenen System zur Dokumentation sind fünf überzeugt und sechs halten es
für mäßig gut. Nur zwei sind mit dem eigenen Verfahren unzufrieden. Das
spiegelt das Vorhandensein hinreichend guter Konzepte wider, es mangelt
demnach eher an der notwendigen Umsetzung. Dass bei der letzten Frage, trotz
der eher mäßigen Ergebnisse vorher, der Zustand der Dokumentation von
ungefähr der Hälfte als gut eingeschätzt wird, lässt sich nicht vollständig
nachvollziehen. Die Antworten lassen sich nur zum Teil damit erklären, dass eine
Versionierung als unwichtig erachtet wird. Alles in allem müssten die Antworten
auf diese Frage negativer ausfallen.
Insgesamt ergibt sich eine große Streubreite an vorhandenen Systemen. Daneben
wurden auch qualitativ sehr unterschiedliche Stände erreicht. Für die angestrebte
Vereinheitlichung ergibt sich damit eine breite Rechtfertigungsgrundlage. Auf der
anderen Seite wird sich so keine einheitliche Strategie zur Überführung von den
alten auf das neue Verfahren finden lassen.
4.5.4 Prozesse
Die bisherigen Dokumentationsprozesse sind über die Systeme hinweg nicht
einheitlich. Das liegt zum einen an den verschiedenen Plattformen, die für die
Dokumentation genutzt werden. Zum anderen haben sich die Prozesse dezentral
entwickelt. Wie auch der Befragung zu entnehmen ist, verfügen einige System-
linien bereits über eine Richtlinie. Bei anderen haben sich ungeschriebene Regeln
zur Dokumentation entwickelt.
72 Ein Ankreuzen aller drei Möglichkeiten wurde bei der Auswertung nicht beachtet.
- 56 -
Der grobe Ablauf der funktionalen Dokumentation ist jedoch bei allen Beteiligten
gleich. Ein Mitarbeiter, der eine Änderung vornimmt, ist, explizit oder nicht, dazu
angehalten, die vorgenommene Entwicklung zu dokumentieren. Wohin die
Informationen abgelegt werden, entspricht dabei keinem einheitlichen Muster.
Sollte ein Mitarbeiter die zu bearbeitende Einheit nicht vollends kennen, wird er
zum passiven Nutzer der Dokumentation. Dann beginnt die Suche nach relevanten
Informationen. Zu diesem Zeitpunkt entsteht der eigentliche Wert der
Dokumentation, der Mitarbeiter begibt sich innerhalb der Dokumentation auf die
Suche nach geeigneten Informationen.
Eine gewisse Hilfe beim Aufbau der Dokumentation ist der Fakt, dass die aktiven
Nutzer, das heißt die Verfasser, oftmals auch die passiven Nutzer, also die
Suchenden, sind. Getreu dem Sprichwort „Wie man sich bettet, so liegt man“,
haben die Mitarbeiter demnach selbst ein Interesse an einer guten Dokumentation.
Durchbrochen wird dieses Prinzip der Eigenverantwortung durch externe
Mitarbeiter, die innerhalb eines Projektes an der Dokumentation arbeiten. Diese
sind zwar ebenfalls passive und aktive Nutzer, der zeitliche Ablauf bringt jedoch
mit sich, dass ein solcher externer Mitarbeiter die Dokumentation zuerst nutzt und
dann verändert. Ist das Projekt abgeschlossen, erfolgt kein weiterer Rückgriff auf
die selbst niedergeschriebenen Informationen. Das Interesse der externen
Mitarbeiter, bei der Dokumentation kundenorientiert vorzugehen, ist daher gering
und muss erzwungen werden.
Neben der gemächlichen Entwicklung der Dokumentation während der Wartung
der Systeme, haben Projekte zur Erweiterung der Anwendungssysteme großen
Einfluss auf die Dokumentation. Der Prozess der Dokumentation innerhalb dieser
Projekte basiert auf zwei unterschiedlichen Herangehensweisen. Einige Projekte
nutzen die bestehende Dokumentation in ihrer aktuellen Form und verändern
deren Inhalt. Andere Projekte entnehmen der gesamten Dokumentation den
relevanten Teil und führen die Veränderungen außerhalb durch. Danach sollten
die neu geschaffenen Informationen zurück in die bestehende Dokumentation
überführt werden, was erfahrungsgemäß nicht immer zuverlässig gelingt.
- 57 -
Mit dem Vorgehen einer externen Bearbeitung der Dokumente ist auf Grund
einheitlicher Projektmanagementmethoden verstärkt zu rechnen. Die Projekte
selbst stellen allerdings oft keine Ressourcen für die Überführung der neu
geschaffenen Inhalte zur Verfügung. Das führt dann zu einem einfachen Kopieren
der Projektdokumente, die natürlich nicht zur Struktur der bisherigen
Dokumentation passen. Diesem Problem wurde mit der Pflicht zum Fortführen
von Dokumenten in der Richtlinie Rechnung getragen.
4.6 Dokumentationskonzept
4.6.1 Allgemeine Inhalte
Das Dokumentationskonzept bildet den Sollzustand auf der Ebene eines
Fachkonzeptes. Es enthält keine technische Umsetzung. Das Konzept orientiert
sich dabei nur schwach an der angestrebten Zielarchitektur. Auf den Punkt
gebracht bedeutet dies, dass der SAP Solution Manager das Konzept zwar
umzusetzen vermag, sich das Konzept aber keineswegs nach der Software richtet.
Es ist so allgemein formuliert, dass es unabhängig von der technischen Plattform
einsetzbar ist. Erst im Kapitel 4.7 Konzeptumsetzung wird die spezifische
Umsetzung auf den SAP Solution Manager beschrieben und erst dann wird sich
an der Technik orientiert.
Die unabhängige Entstehung des Konzeptes bringt Vor- und Nachteile mit sich.
Zu den Vorteilen zählt die Umsetzbarkeit auf verschiedenen Plattformen. Der
SAP Solution Manager bildet demnach nur eine Möglichkeit der Abbildung.
Außerdem bleibt die Freiheit so erhalten, sich konsequent an der Problemstellung
orientieren zu können, ohne den Zwängen der Software unterworfen zu sein.
Diese Vorteile werden im Allgemeinen durch eine schwierigere Umsetzung
erkauft. Um die gewollten Funktionen abzubilden, muss die Zielarchitektur
angepasst und eventuell erweitert werden.
Eine grundlegende Festlegung der Dokumentationsrichtlinie bleibt die
Organisation der Dokumente in Form einzelner Dateien. Wie bei der Auswertung
- 58 -
der Befragung im Kapitel bereits erwähnt, liegt die bisherige Dokumentation
vorrangig in Dateien vor. Eine Datei entspricht dabei einem Dokument und bildet
die kleinste Einheit der Strukturierung. Diese Organisation in Dateien entspricht
der intuitiven Abbildung einer Papierdokumentation in einem elektronischen
System. Ansätze wie die Trennung von Inhalt und Gestaltung in verschiedenen
Dateien sind deshalb nicht Teil des Konzeptes.
Wichtig für die Dokumentation ist die Erfassung von Änderungen. Mit jeder
Modifikation am System muss sich die Dokumentation ändern. Ein endgültiger
Stand wird bis zum Abschalten des Systems nie erreicht. Die Änderungen an den
einzelnen Dokumenten sollten automatisch mit Informationen zum Autor und den
Änderungen erfasst werden. Diese gesammelten Informationen müssen dann
revisionssicher abgelegt werden.
4.6.2 Sichtenkonzept
Die zentrale Idee bei der strukturierten Ablage der Dokumente ist die Einteilung
in Sichten. Das heißt, jeder Sicht sind Dokumente zugeordnet, umgekehrt gehört
jedes Dokument zu mindestens einer Sicht. Diese Sichten spiegeln die
verschiedenen Szenarien bei der Nutzung der Dokumentation wider. Abbildung
10 zeigt die einzelnen Sichten. Unterhalb jeder Sicht existiert eine Strukturierung
in Form einer Hierarchie.
Abbildung 10: Sichtenkonzept
Sichten
Funktions-sicht
Prozess-sicht
Zeitsicht
Gliederung funktionaler Einheiten
Übergreifende Einheiten
Prozess-ebenen
Inhaltliche Gliederung
Geschäftsfall
Prozess
Teilprozess
Jahr
Quartal
Modul
Transaktion
Funktionsbaustein
Beispiel-gliederung
- 59 -
Die zentrale Sicht ist funktional orientiert. Wie die Ist-Analyse ergab, ist eine
funktionale Strukturierung der Dokumentation weiterhin das Maß der Dinge bei
der Systembetreuung. Die typische Anfrage an die Systembetreuer beginnt mit der
Beschreibung einer Fehlermeldung. Ausgangspunkt für die Behebung der
Probleme bildet dann die betroffene Transaktion, ein Funktionsbaustein oder eine
sonstige funktionale Einheit. Die zumeist kleinen Fehler befinden sich innerhalb
dieser Einheit und können durch deren Änderung behoben werden.
Der Aufbau der Sicht entspricht der Struktur der Software und somit einer
konstruktionsorientierten Herangehensweise. Nahezu jede Software lässt sich in
technische Einheiten aufteilen. Art, Umfang und Gliederung der einzelnen
Elemente unterscheiden sich zwar stark in Abhängigkeit vom angewendeten
Programmierparadigma, dennoch besteht nahezu kein Programm mehr aus einem
einzelnen Block von Anweisungen. Damit ergibt sich die Anwendbarkeit auf ein
sehr breites Spektrum von Softwaresystemen.
Innerhalb der funktionalen Sicht befindet sich eine Unterteilung der funktionalen
Einheiten, sofern eine weitere hierarchische Anordnung möglich ist. Bei vielen
SAP-Systemen ist eine Gliederung in Module, Transaktionen und
Funktionsbausteine üblich. Parallel zu dieser Struktur werden übergreifende
Elemente definiert. Ein gutes Beispiel für diese übergreifenden Elemente sind
Schnittstellen, die sich nicht in eine Hierarchie einordnen lassen, da ihre Aufgabe
ja gerade darin besteht, zwei Elemente aus verschiedenen Orten in der Hierarchie
zu verbinden. Bei einer vollständigen Dokumentation existiert zu jedem der
Bausteine eine Beschreibung in Form einer oder mehrerer Dokumente. Ein starkes
Anwachsen einer einzelnen funktionalen Einheit geht oft mit der weiteren
Strukturierung und Auslagerung einher. Um diesen dynamischen Prozess zu
unterstützen, kann die Gliederung der funktionalen Einheiten verändert und eine
umfangreiche Beschreibung aufgeteilt werden.
Die zweite Sicht bildet die Prozesssicht. Aus betriebswirtschaftlicher Sicht laufen
Unternehmen und einzelne Geschäfte in Prozessen ab. Das geschieht im Übrigen
unabhängig davon, ob sich ein Unternehmen der Prozessorientierung verschrieben
- 60 -
hat oder nicht. Ein Geschäftsfall wird in einer Reihenfolge von Aktivitäten
abgewickelt. Ähnliche Geschäftsfälle durchlaufen dabei die gleichen Schritte.
Egal ob explizit im Unternehmen festgehalten oder nicht, es ergibt sich stets eine
logische Abfolge von Schritten, die auch Verzweigungen oder Schleifen enthalten
kann. Ein bekannter Ansatz zur prozessorientierten Modellierung ist ARIS, die
Architektur integrierter Informationssysteme.73 Damit erstellte Prozessmodelle
können die Grundlage der Prozessstruktur bilden.
Prozesse werden je nach Detaillierungsgrad in verschiedenen Ebenen modelliert.
Wie bei Siemens PG üblich, werden im Dokumentationskonzept drei Ebenen
unterschieden. Wichtig ist, dass die unterste der drei Ebenen einen Detaillierungs-
grad aufweist, dem sich eine oder wenige funktionale Einheiten bei der
Softwareunterstützung zuordnen lassen. Wenn bereits eine Prozessmodellierung
mit mehr als drei Ebenen vorliegt, werden die untersten drei Ebenen genutzt,
wenn diese die Forderung nach dem Detaillierungsgrad erfüllen.
Abbildung 11 zeigt beispielhaft einen Ausschnitt aus den Geschäftsprozessen bei
Siemens Power Generation. Die Bezeichnungen der Ebenen sind dabei
Geschäftsfall, Geschäftsprozess und Teilprozess. Die Darstellung soll zum
besseren Verständnis der Ebenen dienen. Bei der Betrachtung gilt es stets zu
beachten, dass im Geschäft mit Kraftwerken auch ein Teilprozess wie Auftrag
anlegen eine umfangreiche Arbeit erfordert.
73 Vgl. weiterführend Scheer, August-Wilhelm, ARIS – vom Geschäftsprozess zum Anwendungssystem, 4. Aufl., Berlin u.a., 2002.
- 61 -
Abbildung 11: Ausschnitt einer Geschäftsprozesshierarchie bei
Siemens PG
Die Prozesssicht kann vielfältig genutzt werden. In der Anwenderbetreuung
können mit einer prozessorientierten Herangehensweise logische Fehler im
Prozessablauf identifiziert werden. Außerdem kann zur Reproduktion von
Fehlern, die nur sporadisch auftreten, das Umfeld, das heißt der Prozess der
fehlerhaften Transaktion, nachkonstruiert werden. Zusätzlich dient die Prozess-
sicht zur Unterstützung von Tests. Während die Funktionssicht nur bei Funktions-
tests hilfreich sein kann, können hier ganze Prozesse zum Testen nachvollzogen
werden, da die Beschreibung der Prozesssicht im Idealfall alle möglichen Schritte
enthält.
Prozessbeschreibungen unterstützen in besonderem Maße die siemensweite
Wissensstrategie, den sogenannten Knowledge Strategy Process. Als Teil dieser
Strategie ist Siemens an Prozesswissen interessiert, das in den Verhaltensweisen
und Strukturen des Unternehmens steckt. Dieses Wissen steckt zum Teil bereits in
Prozessdokumenten, beispielsweise in Form von formulierten Best Practices.74
Die dritte Sicht wird mit Zeitsicht bezeichnet. Die darin abgelegten Dokumente
beschreiben die Entwicklung im Laufe der Zeit. Während die beiden anderen 74 Vgl. Diestelkamp, Antje, Wissensstrategien in Organisationen, Reflexion vor dem Hintergrund des Wandels der Siemens AG zum wissensbasierten Unternehmen, Diplomarbeit Ludwig-Maximilians-Universität München, 2001, S. 61.
Geschäftsfall Geschäftsprozess Teilprozess Anlagengeschäft Angebotsbearbeitung Angebotserfassung
Exportkontrolle
Technische Klärung
Kaufmännische Klärung
...
Projektanschub Auftrag anlegen
Exportkontrolle
Vertragsanalyse
Terminplanung
...
Projektcontrolling
Fakturierung
...
Produktgeschäft
Servicegeschäft
...
- 62 -
Sichten den aktuellen Stand beschreiben, werden in der Zeitsicht Dokumente
aufbewahrt, welche Änderungen auslösen, dokumentieren oder auch zurück-
nehmen. Während die Versionierung der Dokumente der beiden anderen Sichten
nur die Änderungen von Dokumenten sichtbar macht, können die Gründe durch
die Zeitsicht nachvollzogen werden.
Das zentrale Element der Zeitsicht wird die Ablage von Änderungsanforderungen
sein. Der Nutzen ist, dass damit diese Dokumente durch Integration und eine
sinnvolle Verknüpfung die inhaltliche Verbindung zu den beeinflussten
Dokumenten aufzeigen. Bei der Nutzerbetreuung lassen sich so Fehler genauer
identifizieren. Wenn ein neuer Fehler auftritt, kann der Systembetreuer
nachvollziehen, wann und wie die betreffende Stelle geändert wurde. Diese
Möglichkeit verringert den Suchaufwand nach Fehlern enorm. Eingebunden in ein
Management von Änderungsanforderungen liefert die Zeitsicht wertvolle
Unterstützung beim Anpassen oder Erweitern der Software.
Insgesamt besteht das Konzept aus drei Sichten, ist aber ohne Probleme um
weitere erweiterbar. Ein Vorschlag für die Erweiterung wäre eine Datensicht, die
den Aufbau der Stamm- und Bewegungsdaten beschreibt.75 Neben der
Erweiterbarkeit besitzt das Konzept eine gewisse Lückenresistenz. Selbst wenn
eine Sicht nicht in ihrer gesamten Breite definiert wurde, bleibt die
Dokumentation nutzbar. Lediglich die Vorteile der einzelnen Sicht geht verloren.
Die Informationen dieser Sicht müssen dann in eine der anderen Sichten
eingegliedert werden.
4.6.3 Verbindung der Sichten
Während die Sichten im Konzept unabhängig voneinander existieren, sind sie
inhaltlich stark voneinander abhängig. Zum Beispiel benutzen die Prozesse die
beschriebenen Elemente der Funktionssicht. Ein anderes Beispiel sind die
Änderungsanforderungen der Zeitsicht. Sie beeinflussen funktionale Einheiten
75 Vgl. Grupp, Bruno, EDV-Projekte richtig dokumentieren, Dokumentationstechniken, Dokumentationsrichtlinien, Dokumentationssoftware, Köln, 1991, S. 222.
- 63 -
oder verändern den Ablauf der Geschäftsprozesse. Es muss also eine Verbindung
der Sichten untereinander realisiert werden.
Verknüpfungen zwischen einzelnen Dokumenten schaffen diese Verbindung der
Sichten. Eine Verknüpfung verbindet dabei genau zwei Dokumente. Die Mindest-
anforderung an die Verbindung der einzelnen Sichten ist in Abbildung 12 grafisch
dargestellt.
Abbildung 12: Schemadarstellung Verknüpfungskonzept
In der Abbildung ist die zentrale Bedeutung der Funktionssicht erkennbar.
Letztlich ist die eigentliche Dokumentation des Systems in ihr abgelegt. Die
Dokumente der anderen Sichten haben mit ihrem Inhalt einen Einfluss auf diese
Systemdokumentation. Um diesen Einfluss nachvollziehen zu können, werden
Verknüpfungen von den anderen Sichten zu der funktionalen Beschreibung
angelegt.
Die Abbildung zeigt dabei ausschließlich Doppelpfeile. Das heißt, die einzelnen
Dokumente sind sowohl Quelle als auch Ziel der Verknüpfung. Das ermöglicht
eine Nachverfolgung in beide Richtungen. Eine Verknüpfung entspricht damit
Prozesssicht
Funktionssicht
Zeitsicht
Prozess-beschreibungen
Beschreibungen funktionaler Einheiten
Schnittstellen-beschreibungen
ausgelagerte Beschreibungen
Änderungs-anforderungen
11
22
33 44 55
- 64 -
nicht einem einfachen Link, wie ihn jeder Internetnutzer aus HTML-Dokumenten
kennt und millionenfach im World Wide Web findet. HTML-Links lassen keine
Rückverfolgung zu. Für eine einzelne Internetseite ist es demnach nicht möglich
herauszufinden, welche anderen Seiten auf diese verweisen. In dem
Dokumentationskonzept ist diese Möglichkeit zur Rückverfolgung eine
unverzichtbare Forderung, wie nachfolgend verdeutlicht wird.
Pfeil 1 der Abbildung verbindet die Dokumente der Prozess- und Funktionssicht.
Funktionen unterstützen die Durchführung der Prozesse. Folglich verweisen die
Dokumente der Prozesse auf die entsprechenden Beschreibungen der funktionalen
Einheiten. In der Umkehrrichtung ist für jede funktionale Einheit ersichtlich, in
welchen Prozessen sie verwendet werden. Dies ist unerlässlich, um die Bedeutung
der funktionalen Einheit im Geschäftsbetrieb einschätzen zu können und ihr bei
Änderungen Rechnung zu tragen.
Der zweite Pfeil verbindet die Zeitsicht mit der Funktionssicht. Änderungs-
anforderungen für Funktionsänderungen enthalten einen Wunschzustand. Bei der
Umsetzung werden bestehende Funktionen geändert oder neue Funktionseinheiten
erstellt. Um die Umsetzung für eine Änderungsanforderung nachzuvollziehen,
verknüpft der entsprechende Mitarbeiter die Änderungsanforderung mit der
Beschreibung der funktionalen Einheiten, die verändert wurde. Nur dadurch lässt
sich ein Abgleich zwischen dem formulierten Wunsch und der Implementierung
durchführen.
Neben dem zukünftigen Wunschzustand enthält eine Änderungsanforderung noch
eine betriebswirtschaftliche Begründung. Die im Zuge der Änderungs-
anforderungen durchgeführten Neuentwicklungen und Modifikationen lassen sich
zwar durch die geforderte automatische Versionierung nachverfolgen, die Gründe
lassen sich aber nicht nachvollziehen. Dazu benötigt ein Mitarbeiter die
Gegenrichtung der Verknüpfung. Diese ermöglicht ihm, alle Änderungs-
anforderungen zu identifizieren, die jemals einen Einfluss auf eine bestimmte
funktionale Einheit hatten, da sie mit ihr verknüpft sind.
- 65 -
Änderungsanforderungen können neben einfachen Funktionsänderungen auch die
Umgestaltung von Prozessen enthalten. Aus Sicht der Dokumentation verändern
sich in diesem Fall Prozessbeschreibungen. Die Gestaltung der Verknüpfungen
und ihre Begründung erfolgt dabei weitestgehend ähnlich den Änderungs-
anforderungen, die nur einen Einfluss auf funktionale Einheiten haben. Der
Unterschied ist lediglich, dass Prozessbeschreibungen anstelle von Funktions-
beschreibungen das Ziel der Verknüpfung bilden. Oft beeinflussen Änderungs-
anforderungen sowohl Prozesse als auch Funktionen. Dann werden alle
betroffenen Dokumente mit der Änderungsanforderung verknüpft.
Innerhalb der Funktionssicht werden ebenfalls Verknüpfungen benötigt. Die
Beschreibung einer Schnittstelle, die zwei funktionale Einheiten miteinander
verbindet, muss auf die Beschreibungen der betroffenen Einheiten verweisen. Ein
Entwickler leitet dann bei der Änderung von funktionalen Einheiten mögliche
Quereinflüsse ab. Ebenfalls innerhalb der Funktionssicht werden Verknüpfungen
zu ausgelagerten Beschreibungen benötigt, sofern der Zusammenhang nicht durch
die Struktur ersichtlich wird.
4.6.4 Dokumentationsarten
Jedes Dokument hat als Attribut eine Dokumentationsart. Ein Benutzer erhält
daraus Hinweise auf den Inhalt, und automatische Suchvorgänge lassen sich nach
der Dokumentationsart einschränken. Um Verwechslungen vorzubeugen, bezieht
sich der Begriff Dokumentationsart auf die Kategorisierung des Inhaltes. Der
Begriff Dokumentart oder Dokumentenart soll hier nicht verwendet werden. Mit
ihm werden Dokumente meist nach technischen Kriterien unterschieden. So
finden sich in der Literatur die Unterscheidung nach Bild-, Ton- oder Text-
dokumenten, eine Einordnung nach Textverarbeitung, Tabellenkalkulation und
Präsentationen oder sogar die Unterscheidung nach CI- und NCI-Dokumenten.
Der wichtigste Grundsatz des Dokumentationskonzeptes ist die Begrenzung auf
eine möglichst kleine Anzahl unterschiedlicher Dokumentationsarten. Dieser
Grundsatz hat den ganz praktischen Grund, dass jeder Mitarbeiter bei der
- 66 -
Erstellung eines Dokuments eine Dokumentationsart auswählen muss.
Erfahrungen aus der Vergangenheit haben gezeigt, dass viele Mitarbeiter nicht
bereit sind, eine Liste von mehr als fünfzehn Einträgen zu lesen. Der
Auswahlpunkt wird dann oft leer gelassen.
Aus psychologischer Sicht ist eine Begrenzung auf sieben verschiedene
Dokumentationsarten sinnvoll. Die Zahl Sieben ist die durchschnittliche
Aufnahmekapazität ohne Wiederholung.76 Das Vergessen von Einträgen während
des Lesens lässt den Aufwand zur Auswahl einer Dokumentationsart
überproportional ansteigen. Während eine Liste mit sieben Einträgen im
Durchschnitt einmal gelesen werden muss, müssen längere Listen teilweise oder
vollständig wiederholt gelesen werden, was sich zum proportionalen Ansteigen
des Aufwandes in Relation zur Listenlänge addiert.
Außerdem fällt die Abgrenzung der einzelnen Dokumentationsarten bei einer
kleinen Liste generell leichter. Der Ermessensspielraum wird bei wenigen
umfassenden Kategorien kleiner und es treten weniger Grenzfälle auf. Diese
Beschränkung auf wenige Dokumentationsarten soll nicht die Dokumentation
selbst einschränken. Es sollen weiterhin alle relevanten Informationen abgelegt
werden, die Dokumentationsarten sind dementsprechend weit gefasst.
Das bereits erwähnte Dokumentationshandbuch bei Siemens enthält ebenfalls
Dokumentationsarten. Diese richten sich nach DIN 61355. Der
Anwendungsbereich für diese Norm ist dabei wie folgt definiert:
„Sie [die Norm] dient als Grundlage für Vereinbarungen zur Erstellung einer strukturierten Dokumentation, wie sie hauptsächlich für größere Einrichtungen, wie z.B. Anlagen mit ihren Systemen und Ausrüstungen, benötigt wird.“77
Eine Verwendung für die Dokumentation betrieblicher Informationssysteme
schließt die Norm zwar nicht konkret aus, es fehlt jedoch an Passgenauigkeit.
76 Vgl. Miller, George A., The Magical Number Seven Plus or Minus Two, Some Limits on Our Capacity for Processing Information, in: The Psychological Review, Jg. 63, 1956, S. 81 ff. 77 Vgl. Deutsches Institut für Normung, DIN EN 61355:1997, S. 3.
- 67 -
Darum wurden die Dokumentationsarten dem Anwendungsfall entsprechend
formuliert. Danach erfolgte eine Zuordnung der Dokumentationsarten der
Dokumentationsrichtlinie zu denen aus der Norm. Dabei entspricht ein Dokument
in einigen Fällen nur einem Teil eines entsprechenden Dokuments der Industrie-
norm. Die folgende Tabelle enthält alle definierten Dokumentationsarten der
Richtlinie und ihre Entsprechung nach DIN EN 61335.78
Dokumentationsart Beschreibung Zuweisung Dokumenten-arten nach DIN 61355
Business Blueprint Prozessdokumentation zur Beschrei-bung eines Prozessablaufs.
AXQ
Spezifikation Beschreibung einer Sollfunktion für funktionale Einheiten, usw.
AFE
Programm-dokumentation
Beschreibung der technischen Realisierung einer Erweiterung
AFT
Testdokument Testpläne und Testdokumente, d.h. eine Beschreibung was getestet wird, welche Testergebnisse erwartet werden und welche tatsächlich erzielt wurden.
AXK
Anwender-dokumentation
Alle Dokumente, die an die Anwender herausgegeben werden und welche die Handhabung des SAP-Systems beschreiben.
AXF
Supportdokumentation Alle Dokumente, die für IT-interne Zwecke zur Betreuung des laufenden Betriebs dienlich sind, z. B. Sammlungen bekannter Fehler, Lösungen für in der Vergangenheit aufgetretene Probleme, Hinweise zu Parametereinstellungen etc.
AXA
Protokoll Alle Dokumente, die als Ergebnis einer Systemaktivität erzeugt werden, z. B. Jobprotokolle, Security Audit
AWT
78 Siehe Anhang 3, S. 103ff.
- 68 -
Logs etc. Diese Dokumentationsart dient auch dazu, die von Prüfungsgremien (SOA, GoB) vorgeschriebenen Überprüfungen ablegen zu können.
Tabelle 1: Dokumentationsarten der Richtlinie
Die Dokumentationsarten werden nicht spezifisch für die einzelnen Sichten
definiert. Eine Änderungsanforderung ist ihrem Wesen nach eine Spezifikation
und wird auch als solche klassifiziert. Trotzdem werden verschiedene
Dokumentationsarten in einigen Sichten häufiger anzutreffen sein als in anderen.
Die folgende Abbildung zeigt die Sichten, in denen die einzelnen
Dokumentationsarten wahrscheinlich gehäuft vorkommen. Eine Regelung, die
verbietet, ein Dokument einer anderen Sicht zuzuordnen, existiert nicht.
Abbildung 13: Antizipierte Verwendung der Dokumentationsarten
nach Sichten
Außer der bereits erklärten Verwendung von Spezifikationen in der Zeit- und
Funktionssicht werden vor allem Protokolle in mehreren Sichten erwartet. Wie
bereits der Beschreibung in der Tabelle zu entnehmen ist, subsumiert diese
Dokumentationsart ein breites Spektrum von Dokumenten.
Testdokumente und Anwenderdokumentation werden sowohl in der Funktions-
als auch in der Prozesssicht erwartet. Tests einer neuen oder geänderten Funktion
beginnen normalerweise mit einem isolierten Funktionstest. Diese Tests werden in
der Funktionssicht dokumentiert. Erst wenn diese erfolgreich verlaufen sind,
werden ganze Geschäftsprozesse simuliert, um die Interoperabilität, das heißt das
Prozessicht Funktionssicht Zeitsicht
Supportdokument
Testdokument
Business Blueprint
Anwenderdokumentation
Protokoll
Spezifikation
Testdokument
Anwenderdokumentation
Supportdokument
Protokoll
Spezifikation
Supportdokument
Protokoll
- 69 -
Zusammenwirken einzelner Elemente, zu testen. Diese umfangreichen Tests
werden dann der Prozesssicht zugeordnet.
Die Supportdokumentation ist im besonderen Maße zur Erfüllung des Ziels zur
Schaffung einer Wissensquelle angedacht. Diese Dokumentationsart gibt den
Freiraum, Wissen ohne große Vorgaben zu formulieren und für andere zugänglich
zu machen. Da jeder erdenkliche dokumentierte Hinweis Supportdokumentation
ist, kann eine Zuordnung zu einer Sicht nicht erfolgen.
Entsprechend der Ist-Analyse und der durchgeführten Befragung spiegeln die
Dokumentationsarten weitestgehend das Umfrageergebnis wider. Auf die Frage,
welche Dokumentationsarten bisher verwendet werden, nutzten die Befragten die
vorgegebenen Antwortmöglichkeiten und erweiterten diese nicht.
4.6.5 Inhaltliche Festlegungen
Die Dokumentationsrichtlinie schreibt den Inhalt nur in sehr begrenztem Rahmen
vor. Das Ziel ist eine Unterstützung anstelle einengender Regelungen. Es handelt
sich deshalb um wenige generelle Vorgaben.
Grundsätzlich besteht die Pflicht zum Fortschreiben vorhandener Dokumente,
wenn der beschriebene Inhalt eine Änderung erfährt. Zum Beispiel muss eine
Spezifikationen angepasst werden, falls die beschriebene funktionale Einheit
modifiziert wurde. Die bisherige Praxis, ein Dokument anzulegen, welches nur
die Änderungen selbst beschreibt, wird damit beendet. Die Entwicklung selbst ist
durch den Zugriff auf alte Dokumentenversionen nachvollziehbar. Für
Änderungsanforderungen gilt das Prinzip ebenfalls. In einem solchen Dokument
werden die Änderungswünsche festgehalten. Ändern sich diese Wünsche muss
das Dokument verändert werden.
Ein Ziel dieser Regel ist die Dezimierung der Anzahl relevanter Dokumente. Bei
der Suche sind damit insgesamt weniger Zieldokumente vorhanden, die gefunden
werden müssen. Die Wahrscheinlichkeit, wichtige Dokumente zu übersehen, wird
- 70 -
geringer, weil das Fehlen eines einzelnen Dokuments schneller bemerkt und die
Suche fortgesetzt wird. In der Theorie der Retrieval-Systeme entspricht dies einer
Erhöhung der Trefferquote.
Das zweite Ziel dieser Regel ist eine Verbesserung der Aktualität. Verändert sich
das zu beschreibende System und diese Änderung wird in einem einzelnen
Dokument festgehalten, anstatt die Beschreibung des funktionalen Teils
fortzuschreiben, veraltet diese. Nur zusammen mit dem Dokument, welches die
Änderung beschreibt, erhält man den aktuellen Stand. Nach einiger Zeit entstehen
so viele veraltete Dokumente, die nur in Verbindung mit anderen Dokumenten
den aktuellen Stand dokumentieren. Wird bei einer Änderung sofort die
Beschreibung des funktionalen Teils geändert, beschreibt dieses einzelne
Dokument den aktuellen Stand.
Eine zweite Regelung ist die Pflicht zur Beschreibung einzelner Funktions-
einheiten und Prozessschritte. Es soll also auf den untersten Ebenen der einzelnen
Sichten dokumentiert werden. Damit beschreibt ein Dokument die kleinsten Teile
des Systems. Ausnahmen kommen nur dann in Frage, wenn die Beschreibung
eines funktionalen Teils extrem kurz ausfällt.
Im Gegensatz zur Fortschreibepflicht der ersten erhöht diese zweite Regel die
Anzahl an Dokumenten. Gemäß der Theorie der Information Retrieval Systeme
wird dadurch sogar die Präzision bei der Suche verringert. Es handelt sich dabei
aber lediglich um eine Schwäche der Theorie. Die Theorie der Information
Retrieval Systeme nimmt Dokumente als gegeben hin und sieht keine Möglichkeit
der Einflussnahme. Information Retrieval Systeme zielen auf das Finden von
relevanten und das Übergehen von irrelevanten Dokumenten ab. Nur wenn die
Anzahl und der Inhalt der Dokumente als gegeben angenommen werden, ist die
Theorie anwendbar.
Im vorliegenden Fall hingegen kann auf den Erstellungsprozess von Dokumenten
Einfluss genommen werden. Mit einem einfachen Beispiel lassen sich die Ziele
einer perfekten Trefferquote und Präzision leicht erreichen und doch ad absurdum
- 71 -
führen. Wird das gesamte System in einem einzelnen riesigen Dokument
beschrieben, führt jede Suche genau zu diesem Dokument. Damit ergibt sich rein
rechnerisch eine ideale Präzision und ein ebenso idealer Trefferquote von 100
Prozent. Trotzdem hilft dieses Ergebnis dem Anwender nicht bei der Erfüllung
seiner Aufgaben. Der Suchaufwand innerhalb des riesigen Dokuments wäre
enorm.
Präzision klassifiziert Dokumente in zwei Kategorien: relevant oder nicht
relevant. Es müsste eine zweite Rechengröße eingeführt werden, welche zwischen
relevanten und irrelevanten Teilen innerhalb eines Dokuments unterscheidet. Für
ein aussagekräftiges Ergebnis muss diese neue Relevanzeinteilung dann mit der
Präzision kombiniert werden.
Die Pflicht zum Dokumentieren möglichst kleiner Teile zielt darauf ab, den
Suchaufwand innerhalb eines Dokuments zu verringern. Ein Absenken der
rechnerischen Präzision kann dafür in Kauf genommen werden, sofern die
gewonnene Zeit beim Suchen innerhalb eines Dokuments größer ist als die
zusätzlich benötigte Zeit bei der Suche nach relevanten Dokumenten.
In Fortführung zur zweiten Regel gibt es die ausdrückliche Anweisung, komplexe
Dokumentation zu teilen. Wenn eine Funktionseinheit aus verschiedenen
technischen Komponenten besteht und deren Dokumentation einen gewissen
Umfang überschreitet, wird eine neue Unterebene gebildet, die dann die
Dokumentation einzelner technischer Komponenten einer funktionalen Einheit
umfasst. Ein Beispiel soll diesen Vorgang verdeutlichen. SAP R/3-Systeme sind
in Modulen und Transaktionen aufgebaut. Innerhalb der Transaktion besteht die
Möglichkeit, Unterbrechungen, so genannte Userexits zu definieren. Bei
bestimmten Ereignissen, beispielsweise vor dem Speichern der Daten, wird die
Bearbeitung unterbrochen und der Userexit verweist auf Programmierlogik, die
dann ausgeführt wird. Dieser Userexit kann zum Beispiel zu einer Plausibilitäts-
prüfung der Eingabedaten genutzt werden. Ist die enthaltene Logik sehr komplex,
müssen beispielsweise Datenbanken geöffnet, Schnittstellen benutzt und große
- 72 -
Schleifen durchlaufen werden, nimmt die Dokumentation dieses Userexits einen
Umfang an, der dann entsprechend der Richtlinie ausgelagert werden soll.
Gedacht zur Unterstützung und trotzdem als Pflicht formuliert ist die Anwendung
von Dokumentenvorlagen. Jeder Dokumentationsart können mehrere Vorlagen
zugeordnet werden. Das hat den Grund, dass die Dokumentationsarten sehr weit
gefasst sind und beispielsweise Spezifikationen für Änderungsanforderungen und
für funktionale Einheiten verwendet werden. Ein anderer Grund ist die
Mehrsprachigkeit. Ein und dieselbe Vorlage kann in verschiedenen Sprachversion
existieren. Diese Vorlagen werden zentral abgelegt.
Für eine Suche und vor allem für die Klassifikation können Dokumenten
Stichwörter zugewiesen werden. Diese müssen manuell vom Autor aus einer
vorgegebenen Liste ausgewählt werden. Auf eine automatische Auswahl der
Stichwörter wird verzichtet, weil die Stichwörter der Dokumentation teilweise
keinen direkten Zusammenhang mit dem Inhalt haben. So ist es einer künstlichen
Intelligenz beispielsweise nicht möglich, aus dem Inhalt eines Dokuments auf die
verantwortliche Organisationseinheit zu schließen.
Für die Stichwörter wird vorher eine Liste definiert, aus denen sich der Autor die
passenden Einträge aussucht. Diese typische Art der Indizierung dient einerseits
als Gedankenstütze, weil so keine wichtigen Stichwörter vergessen werden.
Andererseits wird so versucht, Problemen wie der Verwendung von Synonymen
vorzubeugen.
Zur verbesserten Vergleichbarkeit wird nur eine Stichwortliste für alle Systeme
definiert. Im Unterschied zu klassischen Information Retrieval Systemen spielen
die Stichwörter bei der Suche eine eher untergeordnete Rolle, da das gesamte
Dokumentationskonzept mehr auf Browsen als auf Abfragen (Quering) ausgelegt
ist. Das heißt, die Suche nach einem Dokument wird vorrangig anhand der
vorgegebenen Struktur erfolgen, die hierarchisch hinab gestiegen wird. Nur selten
wird ein Suchbegriff in eine Suchmaschine eingegeben, die dann die
entsprechenden Ergebnisse liefert. Dies erfolgt dann allenfalls auf Basis einer
- 73 -
Volltextsuche oder mit dem Dokumentennamen. Das einzige derzeit definierte
Stichwort ist SOA-relevant. Es ergibt sich aus der gesetzlichen Vorgabe des
Sarbanes-Oxley-Act, bilanzrelevante Dokumente als solche zu kennzeichnen.
4.6.6 Dokumentenstatus
Um die Arbeitsabläufe zu unterstützen, wird jedem Dokument ein Status
zugeordnet, der den aktuellen Arbeitsstand dokumentiert. Da die Abläufe einfach
gehalten werden sollen, gibt es nur die fünf Statuswerte In Bearbeitung, Fertig,
Endgültig, Freigegeben, Ungültig. Das wesentlich komplexere Siemens
Dokumentationshandbuch für Kundenprojekte unterscheidet den Arbeitsfortschritt
nach einem Dokumentenstatus und nach einer Zustandsart. Um diesem Rechnung
zu tragen, werden jedem der fünf Statuswerte ein Dokumentenstatus und eine
Zustandsart nach Dokumentationshandbuch zugeordnet, sofern dies möglich ist.
Folgende Tabelle zeigt diese Zuordnung. Die zum Teil fehlende Passgenauigkeit
ist zu erkennen.
Definierter Dokumentenstatuswert
Zugeordneter Dokumentenstatus nach Dokumentationshandbuch
Zugeordnete Zustandsart nach Dokumentationshandbuch
Draft / In Bearbeitung EN (Entwurf) Noch keine Zustandsart
Ready / Fertig EZ (Entwurf/Zwischenpause)
SEEN (Einsicht genommen)
Final / Endgültig FR (Freigegeben) CHCK (Checked)
Released / Freigegeben FR (Freigegeben) APPR (Dokument von Partner freigegeben)
Invalid / Ungültig UN (Ungültig) UN (Ungültig)
Tabelle 2: Zuordnung der Statuswerte zu den Begriffen des Siemens PG-Dokumentationshandbuch
Für die fünf Statuswerte ergibt sich eine logische Reihenfolge. Dokumente sind
bei ihrer Erstellung im Status In Bearbeitung, bei ihrer Fertigstellung wechseln sie
in den Status Fertig. Werden die Dokumente in absehbarer Zeit nicht mehr
verändert, werden sie als Endgültig gekennzeichnet. Dieser Status lässt eine
- 74 -
weitere Bearbeitung aber dennoch zu. Dokumente, die von einer Autorität
freigegeben werden müssen, werden nach einer Prüfung mit Freigegeben
versehen. Dies kann nur von Nutzern mit der dazu erforderlichen Berechtigung
geschehen, die das Dokument dann mit einer digitalen Unterschrift versehen. Den
Status ungültig kann ein Dokument zu jeder Zeit erhalten. Dies kann geschehen,
wenn die Unterschrift zur Freigabe verweigert wurde, oder wenn ein Dokument
funktionale Teile beschreibt, die zwischenzeitlich abgeschaltet wurden.
Abbildung 14 stellt den eben beschriebenen Verlauf der Statuswerte grafisch dar.
Abbildung 14: Statuswertschema
4.7 Konzeptumsetzung
4.7.1 Der SAP Solution Manager
Die SAP AG ist der größte Softwarehersteller Europas und mit 36 Prozent
Marktanteil weltweiter Marktführer bei ERP-Software.79 SAP bietet eine Vielzahl
von betriebswirtschaftlichen Softwarelösungen und damit verbundene Dienst-
leistungen an. Vor allem im Geschäft mit Großkonzernen ist SAP sehr
erfolgreich. Konzerne, besonders wenn sie durch Zukäufe gewachsen sind,
79 Vgl. Born, Achim, Neu sortiert, Oracle: Mit Project Fusion in die Zukunft, iX, Magazin für professionelle Informationstechnik, Jg. 18 (2005), Ausg. 3, S. 28.
In Arbeit (initial)
Fertig Endgültig
Released
Dokument bearbeitbar
Dokument gesperrt
Berechtigung erforderlich
keine Berechtigung
erforderlich
digitale Signatur
Ungültig
- 75 -
unterhalten in ihren Unternehmen oft eine Vielzahl an verschiedenen SAP-
Lösungen, so wie es auch bei Siemens Power Generation der Fall ist.
An diesem Punkt setzt der SAP Solution Manager an. Er ist ein umfangreiches
Werkzeug für die Administration einer gesamten Lösungslandschaft in einem
Unternehmen. Der Schwerpunkt liegt dabei auf der Verwaltung von SAP-
Systemen. Bei den enthaltenen Funktionen handelt es sich zum Teil um bereits
bekannte Entwicklungen, die zusammengeführt und durch neue Funktionen
erweitert wurden.
Der Solution Manager soll die verwalteten Systeme von der Einführung bis zur
Abschaltung begleiten. So sind zum Beispiel die bekannte Einführungsmethode
ASAP und Projektmanagementfunktionalität enthalten. Danach stellt der SAP
Solution Manager Funktionen für den laufenden Betrieb zum Beispiel eine
Supportfunktion bereit. Dabei ist eine direkte Anbindung an die
Anwenderbetreuung der SAP AG möglich.
Eine gesamte Auflistung der Funktionen kann an dieser Stelle auf Grund des
Umfangs nicht erfolgen. Es soll an dieser Stelle nur noch erwähnt werden, dass
sich der Einsatz vor allem bei sehr komplexen Systemlandschaften lohnt, wie sie
in der Regel nur bei Großunternehmen vorkommen. Als Überblick über den
gedachten Einsatz soll folgendes Schaubild dienen. Zum tieferen Verständnis
kann die dazugehörige Quelle als Einstieg dienen.
- 76 -
Abbildung 15: Darstellung der Funktionalität des SAP Solution
Manager80
Die aktuelle Version des Solution Managers ist 4.0. Die starke Verbreitung des
Solution Managers begann mit der Vorgängerversion 3.2, die außer einem
geringeren Funktionsumfang keine grundlegenden Unterschiede zur Version 4.0
aufweist. Die starke Verbreitung hat vor allem drei Gründe. Erstens wird der SAP
Solution Manager ohne Zusatzkosten mit einem Wartungsvertrag verteilt.
Zweitens stoppt SAP die Weiterentwicklung von Werkzeugen, wenn deren
Funktionen in den SAP Solution Manager integriert werden. Drittens existiert
80 Schröder, Heinz, Solution Manager: Pfleger für SAP-Landschaften, in: Computerwoche.de, http://www.computerwoche.de/knowledge_center/enterprise_resource_planning/551367/ [24.07.2006], 2004.
- 77 -
bereits seit langer Zeit ein Bedarf an einem effektiven Programm zur Verwaltung
komplexer Systemlandschaften.
Der Erfolg ist spürbar. Die deutschsprachige SAP-Anwendergruppe führte 2005
eine Umfrage unter 300 Anwendern zum Investitionsverhalten durch. Dabei
wurde überraschend festgestellt, dass zu diesem Zeitpunkt 17,1 Prozent der
Befragten in den Solution Manager investieren wollten. Das ergab Platz vier unter
allen SAP-Produkten.81
4.7.2 Dokumentation im SAP Solution Manager
Der SAP Solution Manager ist kein eigentliches DMS, der Anwendungsbereich
ist daher auch nicht vorrangig das Dokumentenmanagement. Auf Funktionen zum
Dokumentenmanagement kann dennoch zurückgegriffen werden, da es sich um
eine sinnvolle Ergänzung zum Einsatzgebiet des Solution Managers handelt.
Diese Funktionen stellt der SAP Solution Manager dabei nicht selbst zur
Verfügung, sondern nutzt eine SAP-Anwendung namens Knowledge Warehouse.
Dieser Zusammenschluss der Software ist für den Benutzer beinahe unsichtbar,
alle relevanten Arbeitsvorgänge lassen sich vom Solution Manager aus
bewerkstelligen.
Der Vorteil der Integration des Dokumentenmanagements liegt in einer
ganzheitlichen Verwendung des Solution Managers, ohne für Belange der
Dokumentation das Programm wechseln zu müssen. Außerdem entsteht kein
Aufwand für den Aufbau einer externen Lösung. So entfällt durch die große
Nutzungsbandbreite des Solution Managers nur ein kleiner Teil des Einrichtungs-
aufwand auf das Dokumentenmanagement.
Die Integration der Dokumentenverwaltung bringt allerdings die Isolation der
Dokumente von anderen DMS mit sich. Dieser Nachteil kann nur durch eine
81 Investitionsverhalten von SAP-Anwendern, o.V., in: iX, Magazin für professionelle Informationstechnik, Jg. 18 (2005), Ausg. 5, Seite 52, Anmerkung: Der Artikel spricht von der DAG, der korrekte Titel ist DSAG (deutschsprachige SAP-Anwendergruppe).
- 78 -
Schnittstelle aufgehoben werden. Ein zweites Manko ist der erhöhte
Einarbeitungsaufwand, um die Software effizient zu nutzen.
Die Ablage der Dokumente erfolgt für den Nutzer unsichtbar im bereits
erwähnten Knowledge Warehouse, einem Content Server. Die Speicherung
erfolgt damit außerhalb des Dateisystems. Vom Solution Manager aus wird dabei
nur auf die Dokumente verwiesen. Die Ordnungsstruktur im Solution Manager ist
somit unabhängig von der Lagerung. Abbildung 16 zeigt die Vorteile dieses
Prinzips.
Abbildung 16: Prinzip der strukturunabhängigen Ablage
Ist das Dokument einem Ordnungsknoten fest zugeteilt, so wie eine Datei fest
einem Ordner zugeordnet ist, werden Verweise bei der Änderung der Struktur
ungültig, da das Dokument nicht mehr an seinem originärem Platz auffindbar ist.
Feste Zuordnung: Knoten 1
Knoten 1-1
Knoten 1-2 DOKUMENT.pdf
Knoten 2
Knoten 2-1
Verweis
Feste Zuordnung: (Tote Verweise)
Knoten 1
Knoten 1-1
Knoten 1-2
Knoten 2
Knoten 2-1
Verweis ins Leere
DOKUMENT.pdf Dokument verschoben
Struktur-unabhängige Ablage:
Knoten 1
Knoten 1-1
Knoten 1-2
Knoten 2
Knoten 2-1
DOKUMENT.pdf
Ablage
- 79 -
Wird, wie beim Solution Manager, das Dokument außerhalb der Ordnungsstruktur
gelagert, sind Verweise auf das Dokumente bis zu seiner Löschung gültig.
Der Solution Manager ist projektorientiert. Für eine ständige Wartung ohne
absehbares Ende sieht die Software die Projektart Wartungsprojekt vor. Zur
Ordnung können innerhalb eines Projekts zwei Baumstrukturen aufgebaut
werden. Der so genannte Business Blueprint entspricht dabei einer Prozessstruktur
mit drei Ebenen. Diese Struktur dient neben dem Dokumentenmanagement als
Ausgangspunkt für viele weitere Funktionen des Solution Managers. Zum
Beispiel werden vom Blueprint aus Funktionsaufrufe in den Satellitensystemen
gestartet, welche die Prozesse abbilden. Für Dokumente bildet der Business
Blueprint eine erste Ordnungsstruktur.
Die zweite Ordnungshierarchie ist die Konfigurationsstruktur. Gedacht ist diese
zur Ablage systemweiter Informationen, wie dem Berechtigungssystem. Eine
Ebenenbegrenzung existiert im Konfigurationsbaum nicht. Für das Dokumenten-
management bietet er die gleichen Funktionen wie der Business Blueprint.
Ein einzelnes Dokument kann durch Integration von MS-Office direkt im Solution
Manager erstellt werden. Zusätzlich bietet die Software die Möglichkeit, Dateien
aus dem Dateisystem in den Solution Manager zu laden oder Verweise auf
Internetseiten einzurichten.
Jedem Dokument werden verschiedene Metainformationen zugeordnet. Neben
dem Titel existieren ein technischer Name, eine Dokumentationsart, ein Status,
eine Priorität, ein Verantwortlicher, eine Stichwortliste, Kommentare und
Verweise. Zusätzlich ist eine Versionshistorie abrufbar, die jede Änderung mit
einem Zeitstempel sowie dem Autor versieht und abspeichert. Es kann auf jede
Version zugegriffen werden.
Bei der Erstellung eines Dokuments ist die Liste an Stichwörter und
Dokumentationsarten in Abhängigkeit vom Projekt begrenzt. Welche Auswahl
besteht, muss auf verschiedenen Ebenen vordefiniert werden. Jedes Projekt hat
- 80 -
eine Projektart; wie bereits erwähnt, ist die Projektart für den laufenden Betrieb
einer Lösung das Wartungsprojekt. Für jede Art existiert ein Projekttemplate,
welches eine erste Vorauswahl zu den Dokumentationsarten und Stichwörtern
bietet. Das Knowledge Warehouse enthält die Gesamtauswahl an Stichwörtern
und Dokumentationsarten, von denen eine Teilmenge in das Projekttemplate
übernommen wird. Vom Projekttemplate wird wiederum eine Teilmenge in das
einzelne Projekt übernommen. Diese letzte Teilmenge ergibt dann die Auswahl-
möglichkeit für den Nutzer. Einzige Ausnahme sind als global definierte
Dokumentationsarten. Diese werden automatisch vom Projekttemplate in jedes
Projekt des entsprechenden Typs übernommen. Abbildung 17 zeigt diesen
Zusammenhang grafisch.
Abbildung 17: Auswahlebenen für Stichwörter und
Dokumentationsarten
Jeder Dokumentationsart ist genau ein Vorlagendokument zugeordnet. Bei der
Erstellung eines neuen Dokuments mit dem SAP Solution Manager wird diese
Vorlage automatisch benutzt. Eine Zuordnung mehrer Vorlagen, wie vom
Dokumentationskonzept vorgesehen, ist nicht möglich.
Knowledge Warehouse
Projekt-template
Projekt
Globale Dokumentationsarten
Komplettes
Stichwörterverzeichnis
Projektart-
spezifische Stichwörter
Projekt-
stich-wörter
Komplettes Doku-artenverzeichnis
Projektart-
spezifische Doku.-Arten
Projekt-
doku.-Arten
- 81 -
Jedes Dokument hat einen Status. Statuswerte für Dokumente werden zentral, also
nicht für jedes Projekt einzeln, definiert. Daneben können Statusschemata und
Signaturstrategien für digitale Unterschriften definiert und Dokumentationsarten
zugewiesen werden. Ein Dokument einer bestimmten Dokumentationsart kann
dann nur noch die Statuswerte des dazugehörigen Statusschemas in der
festgelegten Reihenfolge erhalten.
4.7.3 Grundlegende Konzeptumsetzung
Zur Umsetzung des Dokumentationskonzeptes mit dem SAP Solution Manager
wird jedem Anwendungssystem ein Wartungsprojekt zugeordnet. Eine Ablage in
Dateien, die Zuordnung von Stichwörtern und eine automatische Versionierung
bietet der Solution Manager von Hause aus. Die Versionierung hält allerdings bei
Inhaltsänderungen nicht die genaue Änderung fest. Da aber auf alte Versionen
zugegriffen werden kann, wird der Vergleich von alter und neuer Version unter
Zuhilfenahme von Funktionen eines Office-Programms realisiert. Eine Volltext-
suche kann im Solution Manager nur durch Einrichtung einer Verbindung zu
einem Indexserver realisiert werden. Die Installation dieses Servers steht zur Zeit
noch aus.
Die geforderte Sprachunabhängigkeit lässt sich mit dem Solution Manager nur
fast vollständig lösen. Jedem Projekt ist eine Projektsprache fest zugeordnet.
Diese ist bei allen Projekten Englisch, was eine vollständige Sprach-
unabhängigkeit ausschließt. Der Einfluss der Projektsprache ist für die
Dokumentation aber eher gering. Nur wenige Anzeigen und vor allem die von
SAP mitgelieferten Prozessvorlagen werden von dieser Projektsprache
beeinflusst. Menüs und Navigation sind von der gewählten Sprache bei der
Anmeldung abhängig und eine Nutzung der Prozessvorlagen ist nicht vorgesehen.
4.7.4 Strukturdefinition
Der Solution Manager sieht genau wie das Konzept drei Ebenen bei der Prozess-
hierarchie vor. Lediglich die Bezeichnungen der Ebenen sind verschieden. Um
Einrichtungsaufwand zu sparen, wurden die SAP-Begriffe Geschäftsszenario,
- 82 -
Geschäftsprozess und Prozessschritt als Ebenenbezeichnungen übernommen. Den
Prozessschritten werden dann die Prozessbeschreibungen mit der
Dokumentationsart Business Blueprint angehängt.
Die Funktionssicht und die Zeitsicht werden beide im Konfigurationsbaum
abgebildet. Unter dem Knoten Change Request wird für jede Änderungs-
anforderung ein Knoten definiert. Zusätzliche inhaltliche Gliederungen mit
Zwischenebenen sind jedoch möglich. Die Funktionssicht existiert in der Baum-
struktur neben der Zeitsicht. Die Knoten Interfaces und Customizing enthalten die
Dokumentation der übergreifenden Einheiten, eben die der Schnittstellen sowie
der Customizingtabellen. Daneben befinden sich die Knoten der funktionalen
Gliederung. Entsprechend dem Konzept darf die funktionale Gliederung auf den
Zwischenebenen nicht verändert, auf der untersten Ebene für die Auslagerung von
Spezifikationen jedoch erweitert werden.
Zur Verknüpfung der einzelnen Sichten wird die Funktion zum Anlegen von
Verweisen von einem Dokument auf ein anderes genutzt. Die Verweise des
Solution Managers haben dabei, anders als im Konzept vorgesehen, eine
Richtung. Die Gegenrichtung ist dennoch nachvollziehbar. Zu jedem Verweis
einen zweiten für die Gegenrichtung anzulegen, um die Bedingungen des
Dokumentationskonzeptes zu realisieren, ist also nicht notwendig.
Die Richtung der Verweise wird wie folgt festgelegt: Von der Zeitsicht wird in
Richtung der anderen beiden Sichten verwiesen und von der Prozesssicht auf die
Funktionssicht. Innerhalb der Funktionssicht wird von den Schnittstellen auf die
betroffenen Elemente, ansonsten von der höheren auf die tiefere Ebene verwiesen.
Die jeweilige Gegenrichtung wird durch die Funktion Verwendungsnachweis
bestimmt. Hier kann für ein Dokument eine Liste aller Quellen angezeigt werden,
die auf dieses Dokument verweisen.
Zur eindeutigen Identifikation der Knoten und zur Unterstützung der Suche
mittels einer Suchmaske, wie es zum Beispiel beim Erstellen eines Verweises
notwendig wird, wurde eine Namenskonvention eingeführt. Jeder Knoten erhält
- 83 -
einen einmaligen Schlüssel, mit dem seine Bezeichnung beginnt. So können
beispielsweise Prozessschritte mit gleichem Namen voneinander unterschieden
werden. Das ist besonders für häufig auftretende Prozessschritte, wie Auftrag
anlegen, notwendig. Die Schlüssel setzen sich aus den zwei Buchstaben BB oder
FU für den Prozess- bzw. den Konfigurationsbaum und einer zweistelligen
Nummer für jede Ebene zusammen. Damit bezeichnet beispielsweise BB030405
den fünften Prozessschritt des vierten Prozesses im dritten Geschäftsszenario im
Business Blueprint. Zur Verdeutlichung enthält Abbildung 18 die Kopie einer
Bildschirmdarstellung des Solution Managers mit einer Beispielstruktur gemäß
den Namenskonventionen.
Abbildung 18: Beispiel einer Strukturdefinition (gekürzt)
- 84 -
4.7.5 Inhaltsbezogene Vorgaben
Die Dokumentationsarten des Konzeptes wurden angelegt und dem
Projekttemplate für Wartungsprojekte hinzugefügt. Durch die Deklaration als
globale Dokumentationsarten sind nun in allen Wartungsprojekten automatisch
alle sieben relevanten Dokumentationsarten enthalten.
Der Solution Manager sieht für jede Dokumentationsart eine Vorlage vor, die
dann bei einer Neuerstellung automatisch benutzt werden. Aus dem Konzept
heraus ergibt sich aber die Notwendigkeit von mehreren Vorlagen je
Dokumentationsart. Der Grund ist, dass eine Dokumentationsart verschieden-
artigen Dokumenten zugeordnet werden kann. Ein Testdokument kann sowohl ein
Testplan als auch ein Testergebnis sein, eine Spezifikation kann eine Transaktion
oder eine Customizingeinstellung beinhalten. Würde man jedem dieser
Dokumente eine Dokumentationsart zuweisen, würde sich deren Anzahl
vervielfachen. Außerdem ist es erforderlich, Vorlagen in verschiedenen Sprachen
vorzuhalten.
Zur Lösung der Vorlagenproblematik wurden die definierten Vorlagen an einer
zentralen Stelle angelegt und können bei Bedarf kopiert und dann mit Inhalt
gefüllt werden. Die Vorlagen existieren dabei global für alle Projekte. Der Inhalt
der Vorlagen entstammt verschiedenen Quellen. Das Layout und die Titelseite
wurden von der Siemens PG Projektmethode übernommen. Die angegebenen
Überschriften, Tabellen und so weiter sind aus existierenden Dokumenten
verschiedener Projekte und Abteilungen entnommen und auf den neuen Zweck
angepasst worden. Teilweise sind die Vorlagedokumente bereits mit einer
umfangreichen Dokumentstruktur ausgestattet, die dann inhaltlich gefüllt werden
müssen. Die vorgegebenen Überschriften sind dabei als Gedankenstütze zu sehen
und nicht in jedem Fall notwendig.82
82 Siehe Anhang 4, Beispiel einer Vorlage, S. 109ff.
- 85 -
4.7.6 Statuswertschema und Berechtigungen
Jedes Dokument erhält im SAP Solution Manager genau einen Status als
Metadatum. Die möglichen Statuswerte wurden entsprechend des
Dokumentationskonzepts eingerichtet. Zusätzlich wurden sie in einem Statuswert-
schema zusammengefasst, welches die Einhaltung der vordefinierten Reihenfolge
systemtechnisch erzwingt. Es können aus einem Status heraus also nur bestimmte
andere Statuswerte als Nachfolger gewählt werden. Lediglich ein Speichern und
ein damit verbundenes Protokollieren der getätigten Änderungen erlaubt den
Sprung in den Folgestatus des neu gewählten Statuswertes.
Der Übergang von einem Status in einen anderen zählt als normale Veränderung
des Dokuments. Die Ausnahme bildet der Wechsel in den Status Freigegeben.
Diesem Status ist eine Signaturstrategie zugeordnet. Diese Signaturstrategie
besteht lediglich aus einer Einzelunterschrift. Nur Angehörige einer speziellen
Berechtigungsgruppe sind zum Leisten dieser Unterschrift berechtigt. Die
zugehörige Berechtigungsprüfung erfolgt stets mit dem Versuch, die Unterschrift
zu leisten. Derzeit wird die Signatur des Benutzers durch Eingabe seines Zugangs-
passworts geleistet. Danach ist das Dokument für die Bearbeitung gesperrt. Zur
Aufhebung der Sperre ist die gleiche Berechtigungsgruppe wie zum Leisten der
Unterschrift notwendig.
Neben dieser speziellen Berechtigung zum Leisten digitaler Unterschriften
existiert für Dokumentation im Solution Manager ein dreigliedriges
Rollenkonzept. Grundlage bildete die Standardrolle, die jedem Mitarbeiter
zugeordnet wird. Sie enthält die Berechtigungen zur Einsichtnahme in die
gesamte technische Dokumentation, welche im Solution Manager abgelegt ist. Es
erfolgt dabei keine Unterscheidung nach Systemen.
Zusätzlich existiert zu jedem dokumentierten SAP-System eine Mitarbeiter-Rolle.
Diese enthält die prinzipielle Berechtigung zum Verändern von Dokumenten
eines Systems, sofern diese nicht durch den Status oder Bereichsprüfungen
gesperrt sind. Bereichsprüfungen betreffen nur Systeme, bei denen diese aktiviert
- 86 -
wurden. Hier wird je nach Lage des Dokuments in der Projektstruktur
unterschieden. Sind zum Beispiel die Bereichsprüfungen in einem System
aktiviert worden und ein Mitarbeiter ist nur dem Bereich eines Geschäftsszenarios
zugeordnet, so erhält er nur die Berechtigung zum Bearbeiten der
Prozessdokumentation dieses Geschäftsszenarios. Dokumente anderer
Geschäftsszenarien oder der Funktionssicht bleiben dann für die Veränderung
gesperrt.
Als drittes Glied in dem Rollensystem dient die Rolle des System-
verantwortlichen. Er besitzt weitgehende Rechte, wie die Zuordnung zusätzlicher
Dokumentationsarten oder Stichwörter für sein System. Darüber hinaus kann er
die Bereichsprüfung aktivieren und Mitarbeiter den einzelnen Bereichen
zuordnen, während er selbst unabhängig von der Bereichsprüfung agieren kann.
Externe Mitarbeiter und Prüfer werden gesondert behandelt. Ist eine Einsicht-
nahme in wenige Dokumente notwendig, werden diese außerhalb des Solution
Managers zur Verfügung gestellt. Ist diese Methode nicht wirtschaftlich, muss im
Einzelfall entschieden und gegebenenfalls eine neue Rolle kreiert werden.
Insgesamt ist das Berechtigungssystem im Vergleich zu den dokumentierten SAP-
Systemen sehr einfach gehalten. Es werden lediglich zwei Anwendertypen und
die einzelnen Projekte unterschieden. Trotz strenger Sicherheitsanforderungen im
internationalen Kraftwerksgeschäft reicht ein derart einfaches Berechtigungs-
konzept, da die technische Dokumentation keinerlei Bewegungsdaten enthält.
Sollte sich dies ändern, wäre eine generelle Leseberechtigung undenkbar.
4.8 Migration bestehender Dokumentation
Laufende Systeme besitzen bereits eine Dokumentation, die in den SAP-Solution
Manager überführt werden muss. Expliziter Teil der Diplomarbeit ist dabei die
Übernahme der Dokumentation eines speziellen SAP-Systems. Die
Dokumentation dieses Systems besteht derzeit aus rund 1500 Dateien, die
- 87 -
zusammen fast ein Gigabyte Speicher in Anspruch nehmen. Strukturiert ist die
Dokumentation durch rund 200 Ordner.
Der Aufbau der Struktur kann seine Projektherkunft und Phaseneinteilung nicht
verleugnen. Während des laufenden Betriebs wurde die Struktur mit der Zeit
schleichend umorganisiert, so dass sich in Teilen der Struktur Ansätze einer
funktionsorientierten Sortierung erkennen lassen. Da verschiedene Mitarbeiter an
verschiedenen Teilen der Struktur die für sie wichtige Dokumentation
aufbewahren, unterscheiden sich die Strukturierungen erheblich voneinander.
Auch der Inhalt der Dateien variiert stark. Während sich in einigen Teilen wenige
Dokumente pro Ordner befinden, wurde in anderen der gesamte E-Mail-Verkehr
zu den speziellen Themen als Dokumentation gespeichert.
Was für dieses System im Kleinen gilt, lässt sich verallgemeinern. Sowohl
innerhalb der Dokumentation eines Systems als auch im Vergleich der Systeme
untereinander ergibt sich eine große Streubreite an Dokumentationsansätzen. Eine
einheitliche Migrationsstrategie ist daher unrealistisch. Eine Vollautomatisierung
schließt sich praktisch aus.
Im Falle des EBP-Systems wurde die Strukturierung des Prozess- und
Konfigurationsbaums mittels einzelner Dokumenten und nicht anhand der
Strukturierung der bisherigen Dokumentation erstellt. Zur Erstellung der
Strukturen bietet sich eine Teilautomatisierung an. So sind zum Beispiel Prozesse
eines Systems bei Siemens Power Generation oft in einem zentralen Dokument
festgehalten. Das Inhaltsverzeichnis entspricht dabei der Prozessstruktur. Durch
Makroprogrammierung lässt sich die Struktur effizient extrahieren, mit dem
Schlüssel der Namenskonvention versehen und in den Solution Manager kopieren.
So geschah es sowohl beim EBP-System als auch einem weiteren System mit
mehreren hundert Prozessschritten.83
83 Siehe Anhang 5, Beispiele Makros zur Extraktion der Prozessstruktur, S. 126 ff.
- 88 -
5 Ergebnisse und Ausblick
Zentrales Ergebnis der Diplomarbeit ist die Dokumentationsrichtlinie selbst.84 Da
es sich bei einer Richtlinie um einen Standard handelt, war nach der Freigabe
durch die Projektleitung des Solution Manager-Projektes und des Techforums
eine Freigabe durch ein Gremium namens Architecture Review Board notwendig.
Danach wurde die Richtlinie durch den CIO von Siemens Power Generation, Frau
Christy Woodruff, als Rundschreiben veröffentlicht. Sie ist nun das verbindliche
Regelwerk für die Dokumentation aller aktiven und zukünftigen SAP-Systeme bei
Siemens Power Generation.
Der Inhalt ist in Form von Regeln mit Zusätzen zum besseren Verständnis
formuliert. Die Richtlinie bildet das Ergebnis des Optimierungsproblems
zwischen dem Grade der Freiheit und einer umfassenden Regulierung. Es werden
für die Vergleichbarkeit der Dokumentation notwendige Regeln definiert, die
genug Freiheit geben, auf Eigenarten der einzelnen Systeme und Organisationen
einzugehen.
Zusätzlich zur Richtlinie wird eine Plattform zur Umsetzung bereitgestellt. Der
SAP Solution Manager wurde so angepasst, dass jeder Aspekt der Richtlinie
abgebildet werden kann. Der Nachweis über die Nutzbarkeit wurde mit der
Übernahme einer Systemdokumentation bereits erbracht. Um mit gutem Beispiel
voran zu gehen, wurde der Teil des Solution Manager, der sich mit
Dokumentation beschäftigt, ebenfalls gemäß der Richtlinie dokumentiert. Das
heißt, der Solution Manager enthält die Dokumentation über sich selbst. Die
abgebildeten Prozesse sowie vorgenommene technische Anpassungen sind damit
festgehalten.85 Die Form entspricht dabei nicht den Vorlagendokumenten, weil
diese zu diesem Zeitpunkt noch in der Entwicklung waren. Neben der technischen
84 Siehe Anhang 6, Dokumentationsrichtlinie, S. 130 ff. 85 Siehe Anhang 7, Beispiel einer Prozessbeschreibung, S. 153.
- 89 -
und der Prozessdokumentation entstand eine Anwenderdokumentation zur
Schulung der Mitarbeiter im Umgang mit dem Solution Manager.86
Im Gegensatz zu vorher existiert nun ein einheitliches Dokumentationsverfahren
für alle aktiven SAP-Systeme. Die Vorteile sind Vergleichbarkeit und
vereinfachte Zusammenführung von Dokumentation verschiedener Systeme. Die
Strukturierung der bereits übernommenen Dokumentation ist im Vergleich zu
vorher qualitativ höher einzustufen, da sie den Aufgaben der Supportorganisation
besser Rechnung trägt als eine projektorientierte Strukturierung mit der
Aufteilung in Phasen. Außerdem konnte die Qualität durch Reduzierung von
obsoleten Dokumenten verbessert werden. Wird die Migration anderer System-
dokumentationen ähnlich verlaufen, kann davon ausgegangen werden, dass auch
dort die Qualität steigt. Eine fertige Dokumentation entspricht, korrekte
Anwendung der Vorgaben vorausgesetzt, den Anforderungen einer
Dokumentation im Sinne der DIN EN ISO 9000er Reihe sowie dem Sarbanes-
Oxley-Act
Für die Erstellung neuer Dokumente kann in Zukunft auf Vorlagen
zurückgegriffen werden, die bereits ein Layout und eine Strukturierung vorgeben,
was die Mitarbeiter entlastet. Dabei ist die Auswahl an Vorlagen nicht auf ein
Dokument pro Dokumentationsart oder eine bestimmte Sprache beschränkt.
Zusätzlich ist mit dem Solution Manager eine Plattform geschaffen worden, die
als umfangreiche Wissensquelle zu den dokumentierten Systemen dienen kann.
Die offenen Architekturen des Solution Managers und des Knowledge Warehouse
lassen darüber hinaus eine Verwendung der Dokumente in Wissensmanagement-
systemen zu.
Die größte Aufgabe für die nahe Zukunft ist die Übernahme bestehender
Dokumentation in den Solution Manager unter Beachtung der Richtlinie. Dieser
Teil ist weder Teil der Diplomarbeit noch des Solution Manager-Einführungs-
86 Siehe Anhang 8, Beispiel für Lehrmaterial, S. 154 ff.
- 90 -
projektes. Es ist eine wirksame organisatorische Regelung notwendig, die
zukünftige Projekte dazu bringt, die Projektdokumentation in die Form der
Richtlinie zu überführen und sie im Solution Manager abzulegen. So wird die
Dokumentation stückweise in den Solution Manager überführt.
Als zukünftige Erweiterung sind die Anbindung an die Siemens-PKI zur Leistung
der digitalen Unterschriften, die Nutzung der Dokumentationsrichtlinie für Nicht-
SAP-Systeme und eine Anbindung eines zentralen Wissensmanagementsystems
denkbar. Besonders die beiden letzten Punkte setzen jedoch erhebliche
Ressourcen voraus.
Der langfristige Blick in die Zukunft setzt vor allem eine Umsetzung der
Richtlinie voraus. Nach der Einführung mit entsprechenden Schulungen ist es
insbesondere bei den größeren Systemen unvermeidlich, Dokumentations-
verantwortliche zu bestimmen, welche die Qualität sicherstellen. Wenn das Ziel,
die derzeit vierzehn Systeme auf drei zu migrieren, erreicht ist, wird es
ausschließlich große Systeme geben. Im Zuge dessen müssen dann wahrscheinlich
große Teile der Dokumentation übersetzt werden.
Abschließend möchte ich festhalten, dass mit der Dokumentationsrichtlinie und
der dazugehörigen Plattform eine Basis für eine qualitativ hochwertige
Dokumentation entstanden ist. Die Richtlinie hielt allen fachlichen
Überprüfungen der zuständigen Gremien stand und wurde danach durch den CIO
persönlich veröffentlicht, was mich stolz macht, daran mitgewirkt zu haben.
- 91 -
Glossar
AIIM AIIM, Association for Information and Image Management, Dachverband für Enterprise Content Management.
ASAP Accelerated SAP, phasenorientierte Einführungs-methode zur Einführung von SAP-Systemen.
Bildpunkt Kleinste Einheit eines Bildes, z.B. nach dem Scannen, aus dem ein Bild zusammengesetzt wird.
Browsen / Browsing Suchmethode auf Basis von Verweisen, anhand derer von einem auf das nächste Dokument gesprungen werden kann.
Cache-Speicher Schneller Zwischenspeicher zur Lagerung häufig benötigter Daten.
Content Management Ansatz zur Verwaltung von Inhalten, beinhaltet in der Regel die Trennung von Inhalten und Darstellung.
Content Server Ermöglicht den Zugriff und Ablage von verwalteten Daten, die in Form von Inhalten nach dem Content Management abgelegt sind.
Dateisystem Von den gängigen Betriebssystemen bereitgestellter Dienst zu Ablage und Sortierung von Daten in Dateiform.
Deskriptoren Metadatum eines Dokuments, welches das Dokument beschreibt. Häufigste Form sind Stichwörter.
Dokumenten-managementsystem
System zur Verwaltung von Dokumente über deren gesamten Existenzzeitraum hinweg.
Enterprise Content Management
Auf ein gesamtes Unternehmen ausgeweitetes Content Management, beinhaltet zumeist Dokumenten-management.
ERP-Software Enterprise Ressource Planning-Software. Software zur Verwaltung der Unternehmensressourcen auf betriebswirtschaftlicher Ebene.
HTML Hypertext Markup Language, Auszeichnungssprache für Dokumente zur Bildschirmdarstellung, häufigste Darstellungsform im World Wide Web.
- 92 -
Hybridfrage Mischform zwischen einer offenen und geschlossenen Frage. Gibt häufig die Möglichkeit, geschlossene Fragen um Angaben zu ergänzen.
Information Retrieval System
Systeme zur Informationsbeschaffung auf Basis von Dokumenten, häufig in Bibliotheken im Einsatz.
Metadaten Daten, die zu einem Objekt gehören, aber nicht unmittelbarer Teil des Objektes sind. Bei Dokumenten sind das z.B. Autor oder Erstellungsdatum.
Multimandantensysteme Ein Mandant entspricht einem virtuellen System. Ein Multimandantensystem ist ein physisches System, das mehrere virtuelle Systeme umfasst.
OCR-Software Optical Character Recognition-Software. Text-erkennung, Software zur Erkennung einzelner Buchstaben anhand von Bildpunkten.
Public Key Infra-structure
System zur Ausstellung von Zertifikaten, die Echtheit digitaler Medien garantieren können
Quering Suchanfragen, Suchform, bei der Anfragen gestellt werden, die dann treffende Ergebnisse anzeigen. Gegenstück zum Browsen.
Questionaire Schriftlicher Fragebogen.
Recall Trefferquote bei Suchanfragen. Errechnet sich aus der Anzahl gefundener relevanter Dokumente geteilt durch die Anzahl an relevanten Dokumenten in der Datenbasis.
RFC-Verbindung Remote Function Call-Verbindung, Funktionsaufrufe, die von anderen Programmen durchgeführt werden können. Typische Schnittstelle bei SAP-Systemen.
Roadmap Kann als Teil von ASAP dienen. Beinhaltet nach Phasen gegliederte Aktivitäten bei Software-Projekten.
Sarbanes Oxley Act US-amerikanisches Gesetz, welches im Zuge von Bilanzskandalen an amerikanischen Börsen erarbeitet wurde und strengere Vorschriften für die Wirtschaftsprüfung von Aktiengesellschaften enthält.
SECI-Modell Wissensschaffungsmodell mit den Phasen Sozialisation, Externalisierung, Kombination, Internalisierung.
- 93 -
Siemens PG Siemens Power Generation, Kraftwerksparte des Siemens-Konzerns
Suchmaschine System zur Bildung und Beantwortung von Suchanfragen (Queries) auf einer definierten Datenbasis. Die Antworten sind Verweise auf Dokumente.
Thesaurus Synonymwörterbuch
Vektorisierung Vektorisierte Bilder speichern Informationen nicht anhand von Bildpunkten sondern anhand geometrischer Figuren, die zur Visualisierung rekonstruiert werden.
Versionierung Unterscheidung verschiedener Versionen ein und desselben Objekts. Beinhaltet oft die Speicherung älterer Versionen oder die Möglichkeit zur Rückverfolgung getätigter Änderungen.
Wikipedia Online-Enzyklopädie, in der sich jeder als Autor betätigen darf.
WORM Write Once Read Multiple times, Write Once Reade Many. Speichermedium zur langfristigen Speicherung von Daten
- 94 -
Anhang
Anhang 1: Umfrage ...............................................................................................95
Anhang 2: Umfrageauswertung .............................................................................99
Anhang 3: Auszug DIN EN 61355:1997.............................................................103
Anhang 4: Vorlage Business Blueprint ...............................................................109
Anhang 5: Beispiele für Makros zur Extraktion der Prozessstruktur aus Dokumenten ..................................................................................126
Anhang 6: Dokumentationsrichtlinie (freigegebene englische Version).............130
Anhang 7: Beipiel eines Dokuments zur Beschreibung eines Dokumentationsprozesses .............................................................153
Anhang 8: Beispiel für Lehrmaterial ...................................................................154
- 95 -
Anhang 1: Umfrage
- 96 -
- 97 -
- 98 -
- 99 -
Anhang 2: Umfrageauswertung
- 100 -
- 101 -
- 102 -
- 103 -
Anhang 3: Auszug DIN EN 61355:1997
Kennbuchstaben für technische Bereiche (Datenstelle A1) gemäß DIN EN 61355 : 1997-11
A Übergeordnetes Management
B Übergeordnete Technologie
C Bauwesen (Hoch- und Tiefbauwesen)
E Elektrotechnik (einschließlich Steuerungs-, Informations- und Kommunikationstechnik)
M Maschinenbau (im Regelfall einschließlich Prozeßtechnik)
P Prozesstechnik (nur falls Trennung von M erforderlich)
Kennbuchstaben für Hauptklassen (Datenstelle A2) gemäß DIN EN 61355 : 1997-11
Hauptklasse Informationsinhalt
A Dokumentations-beschreibende Dokumente
Dokumente, die Informationen über die Dokumentation selbst bereitstellen
B Management Dokumente
Dokumente, die hauptsächlich Informationen über Ressourcen, wie Personal, Kosten, Material, Zeit usw., bereitstellen, die erforderlich sind für die verschiedenen Tätigkeiten, wie Planung, Fertigung, Versand, Errichtung, Inbetriebnahme, Betrieb usw., und/oder Dokumente, die hauptsächlich Informationen über Abläufe und Regeln für die verschiedenen Tätigkeiten beinhalten
C Vertragliche und nicht-technische Dokumente
Dokumente, die hauptsächlich Informationen über vertragliche (technische und kaufmännische) und nicht-technische Aspekte von Anlagen, Systemen oder Ausrüstungen beinhalten
D
Dokumente mit allgemeiner technischer Information
Dokumente, die hauptsächlich Informationen über allgemeine technische Aspekte einer Anlage, eines Systems oder einer Ausrüstung bereitstellen und die nicht durch eine der anderen, weitergehend
- 104 -
spezifizierten, Dokumentenartklassen abgedeckt sind
E
Dokumente für technische Anforderungen und Auslegung
Dokumente, die hauptsächlich Informationen über allgemeine technische Aspekte für eine Anlage, ein System oder für Ausrüstungen oder über zugehörige Tätigkeiten im Lebenszyklus bereitstellen
F Funktions-beschreibende Dokumente
Dokumente, die hauptsächlich Funktion, Aufgabe oder Verhalten eines Objekts graphisch oder verbal beschreiben
L Ortsbezogene Dokumente
Dokumente, die hauptsächlich die topographische oder geometrische Lage von Objekten beschreiben
M Verbindungs-beschreibende Dokumente
Dokumente, die hauptsächlich physikalische Verbindungen zwischen Objekten beschreiben, mit Betonung der Verbindungen selbst und deren Art der Realisierung
P Produktlisten Dokumente, die hauptsächlich Material und Teile auflisten, die verwendet werden, um eine Anlage, ein System oder Einrichtungen zu bauen
Q
Qualitäts-management-dokumente; sicherheits-beschreibende Dokumente
Dokumente, die hauptsächlich Informationen bereitstellen, welche die Erfüllung von Qualitätsanforderungen nd die Wirksamkeit des Qualitätssicherungssystem nachweisen und Dokumente, die hauptsächlich Informationen über die Verhinderung von Schäden von Personen, Umwelt und Einrichtungen bereitstellen
T
Dokumente zur Beschreibung geometrischer Formen
Dokumente, die hauptsächlich Informationen über die geometrische Form von zu fertigenden Objekten und über deren Zusammenhänge bereitstellen
W Betriebliche Protokolle und Aufzeichnungen
Dokumente, die hauptsächlich Informationen über Einstellwerte, Ereignisse und Werte bereitstellen, die fortlaufend oder zyklisch während der Betriebsphase von Anlagen oder Systemen aufgezeichnet werden, sowie deren Auswertungen
Dokumentenartenklassen (Datenstellen A2 und A3)
A2 A3 Dokumentenartenklasse
A Dokumentationsbeschreibende Dokumente
- 105 -
B A Verwaltungstechnische Dokumente
B B Verzeichnisse von Informationszusammenstellungen
B Managementdokumente
B A Verzeichnisse
B B Berichte
B C Schriftwechsel
B D Dokumente zu Projektorganisation und -steuerung
B E Dokumente zur Ressourcenplanung
B F Dokumente für Versand, Lagerung, Transport
B G Dokumente zur Baustellenplanung/-organisation
B H Dokumente zum Änderungswesen
C S Dokumente zum Objektschutz (Personen, Anlagen, Umwelt)
C T Schulungsdokumente
C Vertragliche und nichttechnische Dokumente
C A Anfrage-, Kalkulations- und Angebotsdokumente
C B Genehmigungsdokumente
C C Vertragsdokumente
C D Bestell-, Lieferdokumente
C E Rechnungsdokumente
C F Versicherungsdokumente
D G Gewährleistungsdokumente
D H Gutachten und Studien
D Dokumente mit allgemeinen technischen Informationen
D A Datenblätter
D B Erläuternde Dokumente
- 106 -
D C Handhabungsanweisungen (Technische Beschreibungen)
D D Technische Berichte
E E Kataloge, Werbeschriften
E F Technische Veröffentlichungen
E Technische Anforderungs- und Auslegungsdokumente
E A Gesetze, Verordnungen, gesetzliche Vorschriften
E B Normen, technische Regeln, Richtlinien
F C Technische Spezifkations-/Anforderungsdokumente
F D Dimensionierungsdokumente
F Funktionsbeschreibende Dokumente
F A Funktionsübersichten
F B Fliessschemata
F C MMS Dokumente (MMS=Mensch-Maschine-Schnittstelle)
F E Funktionsbeschreibungen
F F Funktionsschaltpläne
F P Signalbeschreibende Dokumente
F Q Einstellwertdokumente
L S Schaltkreisdokumente
L T Softwarespezifische Dokumente
L Ortsbeschreibende Dokumente
L A Erschließungs- und Vermessungsdokumente
L B Erdbau- und Fundamentbaudokumente
L C Rohbaudokumente
L D Anordnungsdokumente für Gesamtanlage
M H Anordnungsdokumente für Ausbau (in Gebäuden)
- 107 -
M U Anordnungsdokumente in/auf Baueinheiten
M Verbindungsbeschreibende Dokumente
P A Verbindungsbezogene Dokumente
P B Verkabelungs- und Rohrleitungsdokumente
P Produktlisten
P A Materiallisten
P B Teilelisten
Q C Stücklisten
Q D Produktlisten und Produkttyplisten
Q Qualitätsmanagementdokumente und sicherheitsbeschreibende Dokumente
Q A Qualitätsmanagementdokumente
T B Sicherheitsbeschreibende Dokumente
T C Qualitätsnachweisdokumente
T Geometriebezogene Dokumente
T A Entwurfszeichnungen
T B Konstruktionszeichnungen
W C Fertigungs- und Errichtungszeichnungen
W L Anodnungsdokumente, Zusammenbaudokumente
W Betriebliche Protokolle und Aufzeichnungen
X A Einstellwertdokumente
X T Logbücher
X X Dokumentenpakete
X A Betriebshandbuch
X B Produkthandbuch
X C Projekthandbuch
- 108 -
X D Planungshandbuch
X E Beschaffungshandbuch
X F Schulungshandbuch
X G Instandhaltungshandbuch
X H Inbetriebsetzungshandbuch
X J Montagehandbuch
- 109 -
Anhang 4: Vorlage Business Blueprint
- 110 -
- 111 -
- 112 -
- 113 -
- 114 -
- 115 -
- 116 -
- 117 -
- 118 -
- 119 -
- 120 -
- 121 -
- 122 -
- 123 -
- 124 -
- 125 -
- 126 -
Anhang 5: Beispiele für Makros zur Extraktion der Prozessstruktur aus Dokumenten
Sub Bezeichnungsbereinigung() ' Makro am 05.06.2006 von fisch01r (Rainer Fische r) erstellt ' Makro zum Bereinigen Prozessbezeichnungen aus
Prozessdokumentation KSP zeilen = 500 For i = 1 To zeilen If ActiveCell.FormulaR1C1 > "Prozess" And
ActiveCell.FormulaR1C1 < "Prozessz" Then x = ActiveCell.FormulaR1C1 y = Split(x) z = "" For j = 1 To UBound(y) z = z + y(j) + " " Next j ActiveCell.FormulaR1C1 = z End If ActiveCell.Offset(1, 0).Range("A1").Select Next i End Sub
- 127 -
Sub BennenungHinzufuegen() ' Makro am 09.06.2006 von fisch01r (Rainer Fische r) erstellt ' Makro zum Hinzufügen der Prozessbenennung Namen skonvention ' Dokumentationsrichtlinie Grundlage Prozessdokum entation KSP zeilen = 500 a = 0 b = 0 c = 0 For i = 1 To zeilen If ActiveCell.FormulaR1C1 <> "" Then a = a + 1 b = 0 c = 0 If a < 10 Then ActiveCell.FormulaR1C1 = "BB0" +
CStr(a) + " " + ActiveCell.FormulaR1C1 If a > 9 Then ActiveCell.FormulaR1C1 = "BB" + CStr(a)
+ " " + ActiveCell.FormulaR1C1 End If ActiveCell.Offset(0, 1).Range("A1").Select If ActiveCell.FormulaR1C1 <> "" Then b = b + 1 c = 0 If a < 10 And b < 10 Then ActiveCell.Fo rmulaR1C1 =
"BB0" + CStr(a) + "0" + CStr(b) + " " + ActiveCell.FormulaR1C1
If a < 10 And b > 9 Then ActiveCell.For mulaR1C1 = "BB0" + CStr(a) + CStr(b) + " " + ActiveCell.FormulaR1C1
If a > 9 And b < 10 Then ActiveCell.For mulaR1C1 = "BB" + CStr(a) + "0" + CStr(b) + " " + ActiveCell.FormulaR1C1
If a > 9 And b > 9 Then ActiveCell.Form ulaR1C1 = "BB" + CStr(a) + CStr(b) + " " + ActiveCell.FormulaR1C1
End If ActiveCell.Offset(0, 1).Range("A1").Select If ActiveCell.FormulaR1C1 <> "" Then c = c + 1 If a < 10 And b < 10 And c < 10 Then
ActiveCell.FormulaR1C1 = "BB0" + CStr(a) + "0" + CStr(b) + "0" + CStr(c) + " " + ActiveCell.FormulaR1C1
If a < 10 And b < 10 And c > 9 Then ActiveCell.FormulaR1C1 = "BB0" + CStr(a) + "0" + CStr(b) + CStr(c) + " " + ActiveCell.FormulaR1C1
If a < 10 And b > 9 And c < 10 Then ActiveCell.FormulaR1C1 = "BB0" + CStr(a) + CStr(b) + "0" + CStr(c) + " " + ActiveCell.FormulaR1C1
If a < 10 And b > 9 And c > 9 Then ActiveCell.FormulaR1C1 = "BB0" + CStr(a) + CStr(b) + CStr(c) + " " + ActiveCell.FormulaR1C1
If a > 9 And b < 10 And c < 10 Then ActiveCell.FormulaR1C1 = "BB" + CStr(a) + "0" + CStr(b) + "0" + CStr(c) + " " + ActiveCell.FormulaR1C1
- 128 -
If a > 9 And b < 10 And c > 9 Then ActiveCell.FormulaR1C1 = "BB" + CStr(a) + "0" + CStr(b) + CStr(c) + " " + ActiveCell.FormulaR1C1
If a > 9 And b > 9 And c < 10 Then ActiveCell.FormulaR1C1 = "BB" + CStr(a) + CStr(b) + "0" + CStr(c) + " " + ActiveCell.FormulaR1C1
If a > 9 And b > 9 And c > 9 Then ActiveCell.FormulaR1C1 = "BB" + CStr(a) + CStr(b) + CStr(c) + " " + ActiveCell.FormulaR1C1
End If ActiveCell.Offset(1, -2).Range("A1").Select Next i End Sub
- 129 -
Sub Leerzeichenersetzen() ' Makro am 20.06.2006 von fisch01r (Rainer Fisc her) erstellt ' Makro zum Ersetzen der Leerzeichen durch Unte rstricht gemäß ' Namenskonvention Dokumentationsrichtlinie zeilen = 200 For i = 1 To zeilen For j = 1 To 3 x = ActiveCell.FormulaR1C1 y = Split(x) z = "" If UBound(y) >= 0 Then z = y(0) For k = 1 To UBound(y) If y(k) <> "" Then z = z + "_" + y( k) Next k ActiveCell.FormulaR1C1 = z ActiveCell.Offset(0, 1).Range("A1").Sel ect Next j ActiveCell.Offset(1, -3).Range("A1").Select Next i End Sub
- 130 -
Anhang 6: Dokumentationsrichtlinie (freigegebene englische Version)
- 131 -
- 132 -
- 133 -
- 134 -
- 135 -
- 136 -
- 137 -
- 138 -
- 139 -
- 140 -
- 141 -
- 142 -
- 143 -
- 144 -
- 145 -
- 146 -
- 147 -
- 148 -
- 149 -
- 150 -
- 151 -
- 152 -
- 153 -
Anhang 7: Beipiel eines Dokuments zur Beschreibung eines Dokumentationsprozesses
Dokumente anlegen
Pflicht zur Fortschreibung Dokumente werden nur für bisher nicht dokumentierte Sachverhalte angelegt! Die Anzahl relevanter Dokumente soll gering gehalten werden. Dazu sollen Dokumente fortgeschrieben werden, anstatt neue Dokumente zu erstellen. Das verringert den Suchaufwand.Bestehenden Dokumenten sollen daher fortgeschrieben werden, wenn an einer bereits dokumentierten Stelle im System eine Änderung vorgenommen wurden. Diese Regel umfasst dabei sowohl kleine Änderungen wie Fehlerbehebungen, als auch großer Änderungen wie Projekte.
Dokumentationsart Siehe hierzu den Link auf die Dokumentation der definierten Dokumentationsarten
Vorlagen Die Vorlagen befinden sich an den Knoten „Configuration“ bzw. „Business Scenarios“. Die Vorlagen des Solution Manager für eine Dokumentationsart können nicht verwendet werden, da nur eine Vorlage pro Dokumentationsart vorgesehen ist. Der Name von Vorlagen beginnt immer mit dem Wort „Template“
Dokumentenname Der Dokumentenname darf keine der Zeichen enthalten, die nicht Teil des Dateinamens von Windows sein können. Dazu zählen: \ / : * ? > < Der Grund ist, dass der Dokumentenname als Dateiname vorgeschlagen wird, wenn das Dokument im Dateisystem abgespeichert oder ausgechecked werden soll. Als Trennzeichen sind nur Unterstriche, keine Leerzeichen zugelassen! Der Name eines Dokumentes muss mit der Schlüsselbezeichnung des Knotens beginnen
4.8 QUELLEN FÜR DOKUMENTE: o Erstellung im SAP Solution Manager (Word-Integration)
Hinweis: Nur wenn für das Dokument keine Vorlage existiert o Link auf ein im SAP Solution Manager bestehendes Dokument
Hinweis: nur wenn das selbe Dokumente mehreren Knoten zugeordnet wird (Ausnahme!)
o Datei hochladen Hinweis: Für die Verwendung extern erstellter Dokumentation
o Link auf eine Internetseite Hinweis: Solche Links sind nicht für die System und Servicedokumentation anzuwenden (dies muss im Solution Manager abgelegt sein!) sondern ausschließlich für Hinweise auf Dokumentationen und Vorgaben anderer Abteilungen.
o Kopie eines bestehenden Dokumentes Dies ist nur zur Übernahme eines Layouts oder einer Vorlage (also ohne Inhalt) gestattet, um Redundanzen zu vermeiden.
Ablage von Dokumenten Dokumente werden an einen Knoten angehängt, nur in Ausnahmefällen wird ein Dokument an mehrere Knoten angehängt Testdokumente werden unter der Registerkarte „Testfälle“ abgelegt Dokumente, die in den Konfigurationsleitfaden (siehe Glossar) übernommen werden sollen, müssen unter der Registerkarte „Konfiguration“ abgelegt werden. Anwerderdokumentation wird unter der Registerkarte „Lernmaterial“ abgelegt
- 154 -
Anhang 8: Beispiel für Lehrmaterial
- 155 -
- 156 -
- 157 -
- 158 -
- 159 -
- 160 -
Literaturverzeichnis
Abgabenordnung der BRD, §§146, 147.
AIIM – Association for Information and Image Management, http://www.aiim.org, http://www.aiim.org/about-ecm.asp, It's not enough to "manage" content, [01.07.2006].
Born, Achim / Diercks, Jürgen, Mutationen, Klassische DMS-Anbieter suchen neue Aufgaben, in iX, Magazin für professionelle Informationstechnik, Jg. 13 (2000), Ausg. 11, S. 84 ff.
Born, Achim, Neu sortiert, Oracle: Mit Project Fusion in die Zukunft, iX, Magazin für professionelle Informationstechnik, 18. Jg. (2005), Ausg. 3, S. 28.
Deutsches Institut für Normung, DIN 32757, Büro- und Datentechnik – Vernichten von Informationsträgern.
Deutsches Institut für Normung, DIN 66230.
Deutsches Institut für Normung, DIN 66231 Programmentwicklungs-dokumentation.
Deutsches Institut für Normung, DIN EN 61355:1997.
Deutsches Institut für Normung, DIN EN 82045-1:2001, Dokumenten-management, S. 5.
Deutsches Institut für Normung, DIN EN ISO 9001:2000, Abschnitt 4.1.
Deutsches Institut für Normung, Normenausschuss Qualitätsmanagement NA 147, Statistik und Zertifizierungsgrundlagen (NQSZ), ISO 9000 Unterstützungsanleitung, http://www.nqsz.din.de/sixcms_upload/media/1832/ISO9000-Unterstuetzungsanleitungen.pdf, [02.07.2006].
Diekmann, Andreas, Empirische Sozialforschung, 10. Auflage, Reinbek, 2003.
Diestelkamp, Antje, Seite 61, Wissensstrategien in Organisationen, Reflexion vor dem Hintergrund des Wandels der Siemens AG zum wissensbasierten Unternehmen, Diplomarbeit Ludwig-Maximilians-Universität München, 2001.
Feng, Ling / Jeusfeld, Manfred A., /Hoppenbrouwers, Jeroen, Beyond information searching and browsing, acquiring knowledge from digital libraries, in: Information Processing and Management, Jg. 41 Nr. 1, 2005.
Fried, Andrea / Baitsch, Christof, Mutmaßungen zu einem überraschenden Erfolg, Zum Verhältnis von Wissensmanagement und organisationalem Lernen, in: Götz, Klaus (Hrsg.), Wissensmanagement, Zwischen Wissen und nicht Wissen, Seite 33 ff.
Geißler, Harald, Wissensmanagement durch Assessment-Center, Ein unterschätztes Diagnose- und Vermittlungsinstrument für das Wissen und Können einer Organisation, in: Pawlowsky, Peter / Reinhardt, Rüdiger (Hrsg.), Wissensmanagement für die Praxis, Methoden und Instrumente für die Umsetzung, Neuwied / Kriftel, 2002, S. 58 ff.
- 161 -
Google Inc, Enterprise Solutions: Google Search Appliance, http://www.google.de/enterprise/gsa/index.html [09.06.2006].
Götzer, Klaus u.a., Dokumentenmanagement, Informationen im Unternehmen effizient nutzen, 3. Auflage, Heidelberg, 2004.
Grupp, Bruno, EDV-Projekte richtig dokumentieren, Dokumentationstechniken, Dokumentationsrichtlinien, Dokumentationssoftware, Köln, 1991.
Handelsgesetzbuch der BRD, §§ 239, 257.
Hertel, Hellmut, Kick-Off-Meeting Solution Manager-Projekt, Erlangen, 2006.
Hinrichts, Joachim, Kontextindexierung – Dokumentenmanagement im Spannungsfeld zwischen arbeitsorganisatorischer Kompetenz und Knowledge Engineering, Ein Dokumentationskonzept zur Indexierung von Kontexten und Arbeitsständen auf Basis elektronischer Ordnerstrukturen, Dissertation, Aachen, 2003.
Huotari, Maija-Leena / Iivonen, Mirja, Trust in Knowledge Management & Systems in Organizations, Hershey, 2004.
Investitionsverhalten von SAP-Anwendern, o.V., in: iX, Magazin für professionelle Informationstechnik, Jg. 18 (2005), Ausg. 5, Seite 52.
EG-Signaurrichtlinie 1999/93/EG.
Klingelhöller, Harald, Dokumenten Management Systeme, Handbuch zur Einführung, Berlin u.a., 2001.
Krcmar, Helmut, Informationsmanagement, 4. Aufl., Berlin / Heidelberg, 2005.
Kroha, Petr, Information Retrieval systeme, Skript zur gleichnamigen Vorlesung an der TU-Chemnitz, 2004.
Menzies, Christoph, Sarbanes-Oxley-Act, Professionelles Management interner Kontrollen, Stuttgart, 2004.
Mertens, Peter, Betriebliche Dokumentation und Information, Schriften zur wissenschaftlichen Forschung Band 14. Meisenheim am Glan, 1965.
Miller, George A., The Magical Number Seven Plus or Minus Two, Some Limits on Our Capacity for Processing Information, in: The Psychological Review, Jg 63, 1956, S. 81 ff.Nonaka, Ikujiro / Takeuchi, Hirotaka, Die Organisation des Wissens, Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen, Frankfurt / New York, 1997.
Oertel, Regina / Knosp, Achim, Ich weiß, du weißt, was wissen wir?, Die virtuelle Plattform und Referenzprozesse zur Entwicklung von Wissensprodukten, in: Pawlowsky, Peter (Hrsg.), Wissensmanagement für die Praxis, Methoden und Instrumente für die Umsetzung, Neuwied / Kriftel, 2002, S. 98 f.
Pawlowsky, Peter, Wozu Wissensmanagement?, in: Götz, Klaus (Hrsg.), Wissensmanagment, Zwischen Wissen und Nichtwissen, 4. Aufl., München, 2002, S. 109 ff.
Polanyi, Michael, The tacit dimension, New York, 1967.
- 162 -
Ponzi, Leonard J., / Koenig, Michael, Knowledge management: another management fad?, in: Information Research, Jg. 8 (2002), Ausg. 1, http://informationr.net/ir/8-1/paper145.html, [05.06.2006].
Probst, Gilbert / Raub, Steffen / Romhardt, Kai, Wissen managen, Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 5. Aufl., Wiesbaden, 2006.
SAP-Bibilothek, SAP Solution Manager, Dokumentation, http://help.sap.com/saphelp_sm40/helpdata/de/ae/64c33af662c514e10000000a114084/frameset.htm [25.07.2006].
Scheer, August-Wilhelm, ARIS – vom Geschäftsprozess zum Anwendungs-system, 4. Aufl, Berlin u.a., 2002.
Schneider, Ursula, Die 7 Todsünden im Wissensmanagement, Kardinaltugenden für die Wissensökonomie, Frankfurt, 2001.
Schüler, Peter, Dokumentierte Flaute, Einzelne Highlights retten die DMS Expo 2002, in: c’t – Magazin für Computertechnik, Jg. 20 (2002), Ausg. 20, S. 42 ff.
Schüler, Peter, Arbeit im Fluss, Neue Software-Schwerpunkte auf der DMS-Expo, in: c’t – Magazin für Computertechnik, Jg. 23 (2005), Ausg. 22, S. 60 ff.
Signaturgesetz der BRD 1997 und 2001.
Siemens Power Generation Dokumentationshandbuch, o. V., o. O., 2001.
Stahlknecht, Peter / Hasenkamp, Ulrich, Einführung in die Wirtschaftsinformatik, 10. Auflage, Berlin u.a., 2002.
Walgenbach, Peter, Die normgerechte Organisation, eine Studie über die Entstehung, Verbreitung und Nutzung der DIN EN ISO 9000er Normreihe, Stuttgart, 2000.
Wilson, Thomas Daniel, The nonsense of ‚knowledge management’, in: Information Research, Jg. 8, Ausg. 1 (2002), http://informationr.net/ir/8 1/paper144.html, [21.07.2006].
Windream GmbH, DMS mit VFS Technology, http://www.windream.com/cgi-bin/winmain.ais?PAGE=de110, [10.05.2006].
- 163 -
Versicherung
Ich versichere durch meine Unterschrift, dass ich die vorliegende Arbeit
selbstständig angefertigt habe. Alle Aussagen, die wörtlich oder sinngemäß aus
Veröffentlichungen entnommen wurden, sind als solche kenntlich gemacht. Diese
Arbeit hat in dieser oder ähnlicher Form noch keiner anderen Prüfungsbehörde
vorgelegen.
Chemnitz, am 25.09.2006 (Rainer Fischer)
