Vorgehensmodell zur Einführung von CMS

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Dortmund
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Content Management Systeme
Autor(en):	Hossein Tahmaz, Stefan Klopocki, Andre Ifland
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:
Studiensemester:	4
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einleitung 3.1 Motivation 3.2 Zielsetzung 3.3 Aufbau der Arbeit 4 Grundlagen 4.1 Begriffsdefinitionen 4.1.1 Content 4.1.2 Content Management 4.1.3 Content Management System 4.1.4 Open Source Syteme 4.1.5 Content Life Cycle 4.1.6 Vorgehensmodell 4.2 Abgrenzung 4.2.1 DMS 4.2.2 CMS 4.2.3 WCMS 5 Vorgehensmodell bei Softwareeinführung 5.1 Vorgehensmodelle 5.1.1 Wasserfallmodell 5.1.2 V-Modell 5.1.3 Spiralmodell 5.1.4 Agile Modelle 5.2 Projektphasen 5.2.1 Analyse 5.2.1.1 Ist Analyse 5.2.1.2 Prozessanalyse 5.2.1.3 Anforderungsanalyse 5.2.1.4 Soll-Konzept 5.2.1.5 Aufwandsabschätzung 5.2.1.6 Kostenanalyse 5.2.1.7 Nutzwertanalyse / Wirtschaftlichkeitsbetrachtung 5.2.2 Konzeption 5.2.2.1 Übersicht über die unterschiedlichen CMS 5.2.2.2 Auswahl des richtigen CMS 5.2.2.3 Sicherheit 5.2.3 Realisierung 5.2.3.1 Leistungserstellung 5.2.3.2 Test 5.2.3.3 Dokumentation 5.2.4 Implementierung 5.2.4.1 Vorbereitung 5.2.4.2 Schulung 5.2.4.3 Inproduktionsnahme 5.2.4.4 Projektabschluss/ Abnahme 5.2.5 Wartung 5.2.5.1 Stabilisierung/ Korrektur 5.2.5.2 Optimierung/ Leistungsverbesserung 5.2.5.3 Anpassungen/ Änderungen 5.2.5.4 Erweiterungen 6 Fazit 7 Fußnoten 8 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung	zusätzliche Erläuterung
APM	agiles Projektmanagement	-
CD	Compact Disc	-
CD-R	Compact Disc Recordable	-
CLC	Content Life Cycle	-
CMS	Content Management System	-
CRM	Customer-Relationship-Management	-
DMS	Dokumenten Management System	-
DVD	Digital Versatile Disc	-
DVD-R	Digital Versatile Disc Recordable	-
E-Business	electronic business	-
E-Commerce	electronic commerce	-
ERP	Enterprise Resource Planning	-
HTML	Hypertext Markup Language	-
ISO	Internationale Organisation für Normung	-
LDAP	Lightweight Directory Access Protocol	-
SCM	Supply-Chain-Management	-
TCO	Total Cost of Ownership	-
WCMS	Web Content Management System	-
WORM	write once read multiple	-
WWW	world wide web	-
XP	Extreme Programming	-

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Die elektronischen Geschäftskonzepte in der Net Economy
2	Grundkonzept des Content Management
3	Der Content Life Cycle
4	Vorgehensmodell/Phasenkonzept
5	Schema des Publishings mit einem CMS
6	Wasserfallmodell
7	V-Modell
8	Spiralmodell
9	Ablauf eines Scrum Prozesses
10	Ablauf eines Extreme Programming Projektes
11	Die Iterations-Wolken:Schrittweise Zielklärung und -näherung
12	Mikroprozessmodell einer Iteration
13	Planungsebenen und Feedback-Schleifen
14	Struktur von Wirtschaftlichkeitsvergleichen
15	Content Management Systeme im Überblick
16	Der Prozess des Customizing im weiteren Sinn
17	Schlagartige Implementierung

3 Einleitung

3.1 Motivation

Nach einer Studie des Marktforschungsunternehmen IDC wird das digitale Universum jährlich um ca. 60 % wachsen. ^[1] Bis 2020 wird ein Anwachsen des Informationsvolumens auf 35 Zettabyte erwartet. ^[2] Um diese Informationen zu verwalten, werden leistungsstarke Systeme benötigt. Einen Lösungsansatz für diese Aufgabe können Content Management Systeme bieten. Derzeit existieren einige hundert verschiedene Content Management Systeme auf dem Markt.^[3] Die Einführung dieser Content Management Systeme stellt für die Unternehmen eine große Herausforderung dar. Es ist ein strukturiertes Vorgehen für die erfolgreiche Einführung notwendig, welches durch Vorgehensmodelle unterstützt werden sollte.

3.2 Zielsetzung

Zielsetzung dieser Arbeit ist es, mögliche Vorgehensmodelle zur Einführung eines Content Management Systems darzustellen. Diese sollen in die allgemeingültigen Phasen aufgegliedert werden, um einen Überblick über möglichst alle Gesichtspunkte, die bei einer Einführung eines Content Management Systems berücksichtigt werden müssen, zu geben. Aus den dargestellten Modellen und Phasen können für jedes individuelle CMS Projekt die zutreffenden Aspekte gewählt werden. Die Arbeit soll bei der Auswahl unterstützen und Möglichkeiten der Projektdurchführung aufzeigen. Es ist somit nicht Ziel, ein einziges konkretes Vorgehensmodell für sämtliche CMS Einführungen zu entwickeln. Folgende Fragestellungen könnte als Grundidee der Arbeit formuliert werden: Was ist bei der Einführung von Content Management Systemen zu berücksichtigen? Welches Vorgehensmodell kann ich verwenden?

3.3 Aufbau der Arbeit

Die Arbeit gliedert sich in acht Teile und wurde zusammen von Andre Ifland, Stefan Klopocki sowie Hossein Tahmaz geschrieben. Kapitel eins und zwei enthalten das Abkürzungsverzeichnis und das Abbildungsverzeichnis. Nach der Darstellung der Motivation für die Thematik, der Zielsetzung und des Aufbaus im dritten Kapitel werden im vierten Kapitel die Grundlagen zum Verständnis der Arbeit dargestellt. Hier werden die Begriffsdefinitionen (Abschnitt 4.1) erläutert und es findet eine Abgrenzung der zentralen Grundbegriffe DMS, CMS und WCMS (Abschnitt 4.2) statt. Im fünften Teil, welcher den Hauptteil der Arbeit darstellt, werden verschiedene Vorgehensmodelle für die Einführung von Content Managementsystemen erläutert (Abschnitt 5.1). Anhand von Projektphasen wird in Abschnitt 5.2 die Vorgehensweise zur Durchführung einer Content Management System Einführung dargestellt. In den Unterpunkten wird detailliert auf bei der Einführung zu berücksichtigende Aspekte eingegangen. Die Unteren Abschnitte orientierten sich am Phasenkonzept eines Projektes und stellen alle üblichen Phasen dar. Der sechste Teil bildet das Fazit der Arbeit. Hier werden die Ergebnisse zusammengefasst und ein Ausblick auf mögliche zukünftige Entwicklungen gegeben. Die Teile sieben bis acht bilden mit Fußnoten sowie Literatur und Quellenverzeichnis den formalen Abschluss der Arbeit.

4 Grundlagen

4.1 Begriffsdefinitionen

4.1.1 Content

Content ist ein Begriff, der aus dem Englischen stammt und bedeutet soviel wie Inhalt oder Gehalt. ^[4] Die Begrifflichkeit Content ist nicht klar definiert. "Mit Content wird oft der Inhalt bezeichnet, der sich dem Betrachter auf einem Informationsträger optisch repräsentiert."^[5] Insbesondere sind hier digitale Bücher, digitale Videos, digitale Musik gemeint, die verwaltet, abgerechnet, geschützt und verteilt werden sollen. Im wesentlichen umfasst der Begriff eine Kumulierung der Einzelinformationen mit Struktur & Darstellungsform.^[6] "Diese elementare Einteilung findet auch Eingang in die Verwaltung des eigentlichen Contents, seines Zugriffs und seiner Aktualisierung und Verteilung."^[7]

Werden die Informationen an andere weitergegeben, so kommt der Begriff Content ins Spiel. Die Informationen können wir als Objekte oder Austauschgegenstände verstehen.^[9] "Content oder Inhalt ist der Oberbegriff für Informationen, die in digitalen Medien vorliegen. Die meisten Inhalte werden im Internet in Textform angeboten, aber durch die immer schnellere Anbindung der Nutzer an die Netzwerke und vor allem das Internet, können zunehmend die spezifischen Vorteile der anderen Medien wie Bilder, Töne, Animationen und Filme für einen optimalen Wissenstransport genutzt werden."^[10] Kopp, Jäckel und van Offern sprechen ebenfalls von Medien und bezeichnen diese auch als Content.^[11] Die Inhalte können online oder offline zur Verfügung gestellt werden. Die Onlineinhalte werden unmittelbar im Browser dargestellt und die Offline-Inhalte müssen erst heruntergeladen und mit der passenden Software geöffnet werden.^[12] "Liegt eine Information also in einer Form vor, in der ich sie an Andere weitergeben kann, sprechen wir von Content."^[13]

4.1.2 Content Management

Das Grundkonzept des Content Managements ist die systematische und strukturierte Beschaffung bzw. Erzeugung von Informationen. Im weiteren Verlauf erfolgt die Aufbereitung, wobei man auch von einer Inhaltlichen und Strukturellen Veredelung spricht. Die anschließende Präsentation und Verarbeitung führt den Prozess zur Publikation fort. Am Ende des Prozesses steht die Distribution, die Verteilung der Inhalte zur Wiederverwendung. Vom Prinzip her kommt das Content Management ohne jegliche elektronischen Hilfsmittel aus, wie es uns die traditionellen, karteikartenbasierten Schlagwortkataloge zeigen, jedoch ist in der heutigen Zeit eine softwarebasierte Lösung nicht mehr wegzudenken.^[14]

"Content Management greift den Content-Begriff auf und fügt Managementtätigkeiten zur Verwaltung sowie spezifische Funktionen zur Nutzung hinzu, um ein Konzept zur definieren. Management wird hierbei in seiner funktionalen Sicht für eine sachbezogene Dimension betrachtet."^[15] Hierbei ist zur berücksichtigen, dass die Gestaltung, Steuerung und Kontrolle als Querschnittsfunktion des Managements betrachtet wird.^[16]

Die letztendliche Nutzung der Daten gehört streng genommen nicht zum Content Management, es werden lediglich die notwendigen Voraussetzungen für eine spätere Nutzung geschaffen.^[17]

Zur der Abbildung 2 werden folgende Zutaten benötigt:

1. Einen Speicher für Ansammlung von Informationen, den sogenannten Content Base

2. Eine Beschreibung der Information, Struktur und Bedeutung sowie aller Zusatzinformation, die sogenannten Daten, Datenstruktur und Metadaten

3. Eine Methode zur Beschreibung von Beziehungen zwischen den Informationen, den sogenannten Hyperlink-Mechanismen

4. Eine Beschreibung der Verarbeitungszustände und Übergänge, der sogenannten state maschine zur Abbildung des Workflow

5. Einen Methode, mit der Rohbausteine ausgewählt und erstellt werden, die sogenannte Redaktionsfunktion

6. Eine Methode zur Gestaltung, des Publikationsergebnis, anhand von Daten, Datenstrukturen und Metadaten, der sogenannten formatting engine^[19]

4.1.3 Content Management System

Unter einem Content Management System versteht man ein Software-basiertes System/Tool, um die Prozesse des Content Managements auszuführen. Es ist weder ein Redaktionssystem noch ein Knowledge Management-System.^[20]

Anders formuliert handelt es sich bei dem Content Management System um eine Software, welche hilft, die abstrakte Content-Management-Aufgabe zu lösen. Da die Content Management-Aufgaben recht unterschiedlich sind, findet man meistens individuell konfigurierte und angepasste Varianten von Content-Management-Produkten im Einsatz.^[21]

"Content Management-Systeme können in allen drei Bereichen der netzbasierten Kommunikation eingesetzt werden: Im Intranet werden Mitarbeiter über Neuigkeiten des Unternehmens informiert, über das Extranet erhalten Partner und der eigene Außendienst benötigte Informationen und im World Wide Web wird der breiten Öffentlichkeit eine Website bereit gestellt."^[22]

Das Content Management-System ist ein Teil des Intranets, gegebenenfalls auch des Extranets sofern Kunden, Lieferanten oder sonstige Dritte in das Systems eingebunden sind. Für die Integration ins Intranet können z.B. folgende Punkte gezählt gehören:

• Kommunikationsinfrastruktur
• Plattform-unabhängige Oberfläche
• Informationsmanagement
• Applikationspool
• Kooperationsunterstützung
• Prozessmanagement

Die Aufgabe für ein Content Management-System ist die Zielsetzung für ein echtes Content Management (Reliabilität, Aktualität, inhaltliche Konsistenz usw.) sowie die Durchführung des Content Management möglichst effizient durchführen zu können.^[23] Bei dem Content Management-System werden Layout und Inhalte strikt von einander getrennt. Diese Trennung ermöglicht auch ein neues Layout zu entwickeln und live zu schalten, ohne dass der darunter liegende Inhalt zerstört wird.^[24] Die Grundideen für ein Content Management-System sind vereinfacht gesagt folgendes: Es wird alles nur einmal abgespeichert, d.h. wenn sich etwas ändert, wie ein Messwert, eine Farbe usw. dann ändert dies sich sofort in allen Produktionen (Dokument, Broschüre, Web-Seite, CD ...). Die Zeiten sind vorbei, wo man mühsam in unterschiedlichen Systemen die Daten suchen, finden und ändern musste. Alle relevanten Contens müssen strukturiert und wieder findbar sein, ähnlich wie die Suchmaschine im Internet. So können ähnliche Contens gefunden und in neue generiert werden. Es gibt viele Möglichkeiten und Optionen für den Einsatz von Content Management-Systemen in Unternehmen.^[25]

"Content Management erlaubt die schnelle Pflege von Webinhalten ohne Programmierkenntnisse. Schon viele Tools haben dies versprochen, sind jedoch meist im Ansatz stecken geblieben. Bei Content Management wird nicht auf die Programmierung verzichtet, sondern jeder Mitarbeiter an einer Website kann sich wieder auf seine Kernkompetenzen konzentrieren. Der Programmierer muss keine Inhalte mehr pflegen, sondern kümmert sich um den technischen Part und der Redakteur braucht keine HTML-Seiten zu erstellen, um Inhalte zu veröffentlichen."^[26]

4.1.4 Open Source Syteme

Bei Open Source handelt es sich um Programme, dessen Quellcode im Klartext frei verfügbar ist. Die Open-Source-Software kann durch jeden an jeden verteilt werden. Je nach Lizenz, müssen verbesserte Versionen der Software (Änderungen bzw. Erweiterungen am Quellcode) unter anderem Namen als die Originalsoftware verteilt werden. Gewöhnlich wird die Software in öffentlichen Kooperationen von vielen Programmierern entwickelt. Es besteht keine kommerzielle oder entwicklungstechnische Bindung. In der Regel ist dadurch eine schnelle und bedarfsorientierte Weiterentwicklung der Software gegeben, jedoch gibt es keinerlei Garantien. Hier sehen Kritiker auch die größte Schwäche in der Open-Source-Software, dass aufgrund fehlender finanzieller Unterstützung die Software nicht professionell und zukunftssicher entwickelt werden kann - aber Anwendungen wie Linux zeigen es uns anders.

Vorteile:

• Laut Definition ist die Software kostenlos und in der Regel aktuell.
• Durch den frei verfügbaren Quellcode und die zumeist große Gemeinde werden neue Standards schnell integriert.
• Bei entsprechenden Kenntnissen, können Anpassungen selbst integriert werden.

Nachteile:

• Es gibt keinerlei Garantien über Weiterentwicklung des Programmes oder Implementierung von neuen Funktionen.
• Support gibt es wenn überhaupt nur von Drittanbietern, welche wiederum keinen direkten Einfluss auf die komplette Entwicklung der Software haben.^[27]

Am CMS-Markt existiert kein echter Standard. Der Verdrängungswettbewerb zwischen den verschiedenen kommerziellen Content Management Systemen ist schon zu heftig, als dass eine gemeinsame Front gegenüber den Open Source Alternativen (allen voran TYPO3) aufgebaut werden könnte. Immer mehr mittelständische Unternehmen, die erstmals ein CMS einführen steigen auf die Open Source Lösungen, angelockt durch die entfallende Lizenz- und Erwerbskosten und den kostenlosen Erweiterungen.^[28]

Die Offenlegung des Software-Quelltextes erlaubt es jedem, Änderungen und Verbesserungen der Software vorzunehmen. Ursprünglich kommen die Lizenzmodelle aus dem universitären Umfeld und hatten zum Ziel, die Weiterentwicklung der Software unabhängig von Copyrights zu ermöglichen. Auch sollte die Haftung des Autors ausgeschlossen sein, da durch die große und unkontrollierte Verbreitung der Software eine Kontrolle nicht möglich ist. Durch das Lizenzmodell hat der Erfinder keine Möglichkeit, an den Softwarelizenzen Geld zu verdienen. Profit ist lediglich im Bereich Service und Support oder am Einsatz der Software selbst möglich. Anschaffung- und Unterhaltskosten sind bei Open Source günstiger, so liegen die TCO (Unterhaltskosten) bei Content-Management-Systemen bis zu 25 Prozent niedriger. Da viele Entwickler im Open Source Bereich die Software selber einsetzen, bestehen oft ein direkter Praxisbezug und eine laufende Qualitätskontrolle. Kommerzielle Anbieter sind hier auf Testumgebungen angewiesen. Während sich bei kommerzieller Software der Kunde in eine Abhängigkeit Vertriebspartner / Hersteller begibt, hat man bei Open Source die Möglichkeit, aus einer Vielzahl von Dienstleistern einen potentiellen Partner zu finden.^[29]

4.1.5 Content Life Cycle

Wie zuvor beschrieben kann der Content Management Prozess als eine idealisierte lineare Abfolge von Funktionen betrachtet werden.^[30] Im Gegensatz dazu "[...] wird mit der Betrachtung des Lebenszyklus von Content, dem sogenannten Content Life Cycle (CLC), der einzelne Content detallierter betrachtet. Dabei stehen die Übergänge und Iterationen von der Entstehung bis zur Eliminierung im Zentrum der Darstellung."^[31]

Der Content Life Cycle besteht aus den Abschnitten Erstellung, Kontrolle, Freigabe oder Wiedervorlage, Publikation und Archivierung. Je nach Art der Information erstellt der Autor mit einem oder mehreren geeigneten Programmen (z.B. Text - Textverarbeitung, HTML - Webeditor, Grafik - Zeichenprogramm) seine eigene Idee oder die eines anderen ins Werk. Die Informationen werden zur Kontrolle und Freigabe einer höheren Instanz vorgelegt. Sind die Informationen korrekt, werden sie freigegeben und gelangen zum nächsten Abschnitt, der Publikation. Nicht korrekte Inhalte gehen zwecks Überarbeitung zurück an den Autor. Bei der Publikation werden die Informationen je nach Zweck in- oder und extern zur Verfügung gestellt. Am Ende des Zyklus, wenn die Informationen nicht mehr benötigt werden, können sie gelöscht werden. Sinnvoller ist jedoch eine Archivierung, je nach Bedarf intern oder öffentlich. Hier können die Informationen ggf. als Vorlage für neue Dokumente oder als Informationsquelle dienen, wenn ein historischer Informationswert vorhanden ist.^[32]

Die Abfolge der einzelnen Schritte wird in Abbildung 3 dargestellt. Der Content Life Cycle ist nicht nur ein theoretisches Modell, sondern auch ein Hilfsmittel, Prozesse zu verstehen, zu analysieren und zu optimieren. Wie effektiv der Prozess ist, kann man anhand der einzelnen Stationen leicht überprüfen.^[34]

4.1.6 Vorgehensmodell

Vorgehensmodelle zählen zu den Referenzmodellen. Es sind modellhafte, abstrahierte Beschreibungen von Vorgehensweisen, Richtlinien, Empfehlungen oder Prozessen. Sie beschreiben Konzepte und Aktivitäten die zur erfolgreichen Durchführung eines Projektes erforderlich sind. Zusätzlich geben sie an, wie im Projekt Prinzipien, Methoden, Verfahren und Werkzeuge genutzt werden können.

Beispiele für Vorgehensmodelle in der Anwendung sind:

• Vorgehensmodelle zur Systementwicklung
• Vorgehensmodelle zur Einführung von Standardsoftware
• Das ISO-Referenzmodell
• Beschreibungsmodelle für funktions- oder prozessorientierte Anwendungssysteme

Vorgehensmodelle beinhalten meist ein Phasenkonzept, welches in unterschiedlicher Reihenfolge oder auch in Zyklen angewendet werden kann. Häufig werden Analyse, Entwurf (Konzeption), Realisierung und Einführung (Implementierung) als vier Hauptphasen genannt.^[36] Das "Vorgehensmodell orientiert sich [hierbei] am zeitlichen Ablauf eines Projektes."^[37] Teilweise findet man auch eine differenziertere Aufteilung des Phasenkonzeptes (Abb. 4). Das Phasenkonzept liefert Planungshilfen durch Strukturierung mit dem Vorgehensleitfaden. Es handelt sich beim Phasenkonzept um einen Standardablauf, der an das jeweilige Projekt angepasst werden muss. Durch die Anwendung von Vorgehensmodellen wird der Umgang mit komplexen Projekten erleichtert.^[38] Vorgehensmodelle unterliegen einem zeitlichen Wandel, es werden kontinuierlich Weiterentwicklungen an bestehenden Modellen vorgenommen, sowie neue Modelle entwickelt.^[39]

4.2 Abgrenzung

4.2.1 DMS

Die DMS sind bereits seit Jahrzehnten auf dem Markt verfügbar. Die Aufgabe besteht darin, komplexe Dokumente zentral zu verwalten und zugänglich zu machen. Des Weiteren bietet das DMS Funktionalitäten wie Freigabeverfahren, Verschlagwortung, Indexierung, Versionierung und andere Funktionalitäten, die mittlerweile auch in den meisten WCMS vorhanden sind. Viele WCMS bieten auch die Funktionalitäten von DMS an, jedoch wird die Verwaltung von Inhalten im Internet dargestellt. Die Unterscheidung zwischen DMS und WCMS kann man konkret in zwei Punkten darstellen:

1. die Art der verwalteten Dokumente

2. die Art des Zugriffs auf die Dokumente

Die DMS Dokumente werden komplett einschließlich Formatierung und Grafik abgelegt. Insbesondere sind die DMS Dokumente nicht mit Funktionalität ausgestattet, wie sie für das WCMS-Umfeld zwingend notwendig ist, die Trennung von Inhalt und Layout.^[40] Aus juristischen Gründen müssen Dokumente über längeren Zeitraum aufbewahrt werden, es fallen immer schneller, immer größere Datenmengen aus unterschiedlichen Quellen an. Auf diese Informationen müssen schnell und effizient zugegriffen werden können. DMS Systeme werden auch als Archiv-Systeme bezeichnet, dort werden die Dokumente langfristig archiviert und abgelegt. Die Daten werden auf optische Datenträger (WORM_Platten, CD-R, DVD-R, optische wiederbeschreibbare Platten) geschrieben. Bei DMS steht der volle Lebenszyklus der Dokumente im Vordergrund. Die Zugriffsberechtigung, die Versionierung und die Volltextrecherche spielen eine wesentliche Rolle^[41]

4.2.2 CMS

CMS bietet eine Überkategorie zu verschiedenen Weiterentwicklungen des DMS. Die zentrale Rolle beim CMS ist die Aufteilung von Dokumenten in einzelne Inhaltsobjekte, wo auch der hauptsächliche Unterschied zu den DMS-Lösungen liegt.^[42] Ein CMS ist eim Daten Management System mit Handhabung von Inhalten (Contens) die in der Regel aufs Internet und Intranet Inhalten beziehen.^[43] Die Verwaltung beim CMS gestaltet sich wie beim DMS entlang eines Lebenssyklus. Die Teilprozesse gliedern sich wie folgt auf:

1 collect - Erstellen eines Contens

2 manage - Speicherung des erstellten Contens

3 publishing - Veröffentlichung des Inhalts^[44]

4.2.3 WCMS

Unter dem Begriff Web Content Management System haben sich viele Anwendungen eingruppiert, welche als zentrale Aufgabe das Erstellen, Strukturieren und Verwalten von Webinhalten haben. Dabei wird ein großer Wert auf die Automatisierung des Content Life Cycles gelegt, womit sich das WCMS stark von anderen Applikationen wie z.B. Webeditoren abgrenzt, welche nur Teilbereiche unterstützen. Die Abgrenzung zu anderen Softwaredomänen, wie z.B. Wissens- und Dokumentenmanagement hingegen wird indes immer schwieriger, da die Softwareanbieter dem Trend zur Integration mehrerer Applikationen folgen und sich als umfassende Websysteme positionieren. Auch haben sich die Technologie und der Funktionsumfang der WCMS analog zum Web weiterentwickelt. War ursprünglich die Verwaltung der Webdokumente im Vordergrund, so spielen heute dynamische und personalisierte Inhalte eine große Rolle. Dazu kommt die Verknüpfung mit Inhalten aus anderen IT-Systemen. Um alle Prozesse des E-Business abbilden zu können, müssen im WCMS Schnittstellen und Connectoren zu anderen Web-Anwendungen wie z.B. E-Commerce-Lösungen integriert werden. Damit entwickelt sich das WCMS zunehmend zu einer integralen Komponente einer E-Business-Infrastruktur.^[46]

5 Vorgehensmodell bei Softwareeinführung

5.1 Vorgehensmodelle

In diesem Abschnitt werden einige Vorgehensmodelle beschrieben. Die Modelle beinhalten in unterschiedlichen Ausprägungen, die im Abschnitt 5.2 beschriebenen Projektphasen. In dem jeweiligen Vorgehensmodell werden Vor- und Nachteile genannt, gleichzeitig wird ein Bezug von den allgemeinen Grundideen des Vorgehensmodells auf die spezielle Anwendung bei der Einführung von CMS hergestellt.

5.1.1 Wasserfallmodell

Das Wasserfallmodell wurde 1970 durch Dr. Winston W. Royce erstmals veröffentlicht. Royce hat es von anderen Softwareentwicklungsmodellen abgeleitet. Das Wasserfallmodell wird auch Softwarelebenszyklus genannt. Die Phasen des Wasserfallmodells sind nacheinander kaskadiert, dies bedeutet das Hinzufügen folgender Schritte (siehe Abb. 6) führt uns zum sequentiellen Wasserfallmodell und lassen sich auf die grundlegenden Entwicklungsaktivitäten zurückführen, die im Folgenden weiter erläutert werden. ^[47]

Das in Abbildung 6 dargestellte Wasserfallmodell symbolisiert durch Pfeile den Prozessablauf. Die Pfeile von der jeweils nachfolgenden Phase zurück zum jeweiligen Vorgänger stellen dar, dass nach jeder realisierten Phase ggf. ein Rücksprung zur vorherigen Phase notwendig sein kann. Ein Grund hierfür kann beispielsweise eine nicht leistungsgerechte Implementierung einer Komponente sein, dabei wird dann ein erneuter Entwurf unter Berücksichtigung der nötigen Effizienz und Anforderungen benötigt. ^[49]

Die Phasen:

"Analyse und Definition der Anforderung: Die Dienstleistungen, Einschränkungen und Ziele des Systems werden in Zusammenarbeit mit den Systembenutzern aufgestellt. Dann werden sie detaillierter definiert und dienen so als Systemspezifikation.

System- und Softwareentwurf: Der Systementwurfsprozess teilt die Anforderungen in Hard- und Softwaresysteme auf. Er legt eine allgemeine Systemarchitektur fest. Beim Softwareentwurf geht es um das Erkennen und Beschreiben der grundlegenden abstrakten Softwaresysteme und ihrer Beziehung zueinander.

Implementierung und Komponententest: In dieser Phase wird der Softwareentwurf in eine Reihe von Programmen oder Programmeinheiten umgesetzt. Das Testen der Einheiten stellt sicher, dass jede Einheit ihre Spezifikationen erfüllt.

Integration und Systemtest: Die einzelnen Programme oder Programmeinheiten werden zusammengeführt bzw. integriert und als Ganzes getestet, um sicherzustellen, dass die Softwareanforderungen erfüllt werden. Nach den Tests wird das Softwaresystem an den Kunden ausgeliefert.

Betrieb und Wartung: Normalerweise (aber nicht unbedingt) ist dies die längste Phase innerhalb des Lebenszyklus. Das System wird installiert und zum Gebrauch frei gegeben. Zur Wartung gehören das Korrigieren von Fehlern, die in den früheren Phasen nicht entdeckt wurden, die Verbesserung der Implementierung von Systemeinheiten und die Verbesserung des Systems, falls neue Anforderungen entdeckt werden." ^[50]

Innerhalb der Phasen werden jeweils ein oder mehrere Dokumente erstellt, die durch den Auftraggeber abgenommen werden und ggf. für die nächsten Phasen wichtig sind. Mit der nachfolgenden Phase sollte erst begonnen werden, wenn das Dokument der Vorgängerphase abgenommen ist. In der Praxis sieht dies allerdings anderes aus und kann oft nicht realisiert werden, da sich die Phasen überlappen und Informationen miteinander austauschen werden. Beispielsweise werden während des Entwurfs Probleme bei den Anforderungen festgestellt, oder in der Programmierphase werden Fehler im Entwurf entdeckt. In der Wartungsphase werden Verbesserungen an der Software vorgenommen und teilweise werden alle Prozessschritte des Wasserfallmodells erneut durchlaufen. Hierbei ist der Vorteil des Wasserfallmodells, dass aus jeder Phase eine Dokumentation erzeugt wurde. Ein weiterer Vorteil des Wasserfallmodells ist, dass es zu vielen Systementwicklungsprozessen passt und daher oft einfach angewendet werden kann. Problematisch im Wasserfallmodell ist allerdings, dass es eine starre Aufteilung der einzelnen Phasen aufweist. Es werden zu einem frühen Zeitpunkt Verpflichtungen eingegangen, die es schwer machen neue Anforderungen des Kunden einzustellen. Fazit Wasserfallmodell: Das Wasserfallmodell sollte eingesetzt werden, wenn die Anforderungen weitestgehend feststehen und es eher unwahrscheinlich ist, dass gravierende Änderungen notwendig sind. Das Wasserfallmodell entspricht auch dem Vorgehensmodell von Ingenieursprojekten und wird auch bei der Einführung von größeren Softwareprojekten verwendet. ^[51]

5.1.2 V-Modell

Als Weiterentwicklung des Wasserfallmodells wurde Anfang der 90er Jahre in Deutschland das V-Modell vorgestellt. Auch das V-Modell stellt den Softwarelebenszyklus dar. Es kann sowohl für Softwareprojekte als auch für andere Projekte verwendet werden. Das standardisierte V-Modell verbessert die Nachvollziehbarkeit und die Übersichtlichkeit. Zusätzlich ermöglicht es auch die Bewältigung von komplexen Projekten. Für den Auftraggeber sowie für den Auftragnehmer wird das gesamte Projekt besser planbar und transparenter. ^[53] Die primären Ziele des V-Modells sind die Minimierung der Projektrisiken, die Verbesserung sowie Gewährleistung der Qualität, Gesamtkosten über das Projekt bzw. den Softwarelebenszyklus eindämmen und die Verbesserung der Kommunikation zwischen allen Beteiligten. ^[54] Auf der linken Seite des V-Modells sind die Phasen eins bis drei dargestellt.. Die Phasen vier bis sechs sind auf der rechten Seite dargestellt. Im V-Modell werden die jeweils linken Phasen von den rechten Phasen überprüft. Der Modultest überprüft die Implementierung, die Systemintegration überprüft den Systementwurf und die Systemabnahme überprüft die Anforderungsanalyse. Werden bei der Überprüfung der jeweiligen Phasen Probleme festgestellt, wird wieder zur geprüften Phase zurückgekehrt. Tritt eine Unstimmigkeit in Phase sechs (Systemabnahme) auf, muss bei größeren Problemen in Phase eins zurückgesprungen werden. Im Modultest muss bei Unstimmigkeiten nur zur Implementierung zurückgesprungen werden. ^[55]

5.1.3 Spiralmodell

Bei heutigen Projekten existieren immer kürzere Phase für Entwicklung und Realisierung. Aufgrund dieser Anforderungen muss auch das Vorgehensmodell für das Projektmanagement an den aktuellen Trend angepasst werden. Es treten häufig kurzfristige Änderungen bei einem engen Zeitplan auf, wodurch ein dynamisches und flexibles Vorgehen im Projekt erforderlich wird.^[56] Immer mehr Projekte scheitern an diesen Anforderungen, weil die traditionellen Vorgehensmodelle diese Ansprüche nicht erfüllen können. Es sind neue evolutionäre Modelle nötig. ^[57] Die Vorgehensmodelle müssen agiler werden. Bei den in den vorangegangenen Abschnitten beschriebenen traditionellen Vorgehensmodellen erfolgt eine umfassende Anfangsplanung, welche über den Projektverlauf eingehalten werden muss. Jede Phase wird einmal durchlaufen und bildet die Voraussetzung für die folgenden Phasen (Wasserfallmodell). Bei spontan auftretenden Änderungen der Anforderungen treten Probleme auf. Diese Probleme werden meist erst in den letzten Phasen erkannt. Änderungen und Korrekturen in diesen späten Phasen ziehen meist einen erheblichen Änderungsaufwand verbunden mit hohen Kosten nach sich.^[58] Evolutionäre Vorgehensmodelle sind im Gegensatz dazu selbstorganisierte Systeme deren Verlauf nur begrenzt durch die Planung vorbestimmt wird. Die detaillierte Phasenplanung erfolgt meist kurzfristig am Beginn der jeweiligen Phase. Zudem wird ein inkrementelles oder ein iteratives Vorgehen verwendet. Es wird auf gemachte Erfahrungen aufgebaut und teilweise nach dem Prinzip Versuch und Irrtum gearbeitet. Für diese Vorgehensmodelle ist es notwendig, dass sich Arbeits- und Koordinationsphasen abwechseln. Es existiert somit kein starrer Ablauf wie in den traditionellen Modellen. Dies erfordert ein hohes Maß an Flexibilität und Kompetenz bei den beteiligten Mitarbeitern.^[59]

Das Spiralmodell wurde 1986 von Barry Boehm entwickelt. Es ist ein Metamodell, welches ein iteratives Vorgehen unter besonderer Berücksichtigung der Aspekte Evaluation und Risikomanagement beschreibt.^[60] Charakteristisch ist die inkrementelle Vorgehensweise mit zyklischem Ablauf (siehe Abbildung 8). Das Spiralmodell besteht dabei aus standardisierten Zyklen. Innerhalb der einzelnen Spiralrunde können andere Vorgehensmodelle verwendet werden, zum Beispiel das Wasserfallmodell.
Jeder Zyklus besteht aus 4 Schritten:

• Bestimmung der Ziele, Alternativen und Einschränkungen des Projektes
• Bewertung von Alternativen und Risiken, Prototyp entwickeln
• Weiterentwicklung und Überprüfung
• Planung des nächsten Zyklus ^[62]

Nach jedem Zyklus, auch bereits nach dem ersten, steht eine neue Version des Prototyps zur Verfügung. Es kann somit schon früh mit den Prototypen gearbeitet werden.^[63] Dadurch können Ziele für den nächsten Zyklus aus dem Prototyp abgeleitet werden und Änderungen kurzfristig im neuen Zyklus berücksichtigt werden. ^[64] Jede neue Version des Prototyps wächst in ihrem Umfang und insbesondere die Einsatzaspekte können voll berücksichtigt werden. Die Entwicklung sollte hierbei von allgemeinen Grundfunktionen zu besonderen Spezialfällen erfolgen. Durch den zyklischen Ablauf und der regelmäßigen Erstellung von Prototypen kann das Projekt theoretisch nach jedem Zyklus gestoppt werden und der aktuelle Prototyp als Endversion verwendet werden. Es ermöglicht sich dadurch ein design to cost und eine verbesserte Abschätzung der Risiken und des Aufwandes.^[65]
Vorteile:

• Schnelle einsatzfähige Software ^[66]
• Minimierung der Risiken ^[67]
• Frühzeitig Fehlerkorrektur ^[68]
• Schnell steigende Prozesssicherheit ^[69]

Nachteile:

• Aufgrund des Aufwands nicht geeignet für kleine oder mittlere Projekte ^[70]
• Hoher Managementaufwand (da ständiger Entscheidungsprozess) ^[71]
• Aufwandschätzung zu Beginn teilweise schwierig, da keine genaue Zieldefinition ^[72]

Bei der Einführung eines CMS kann die frühzeitige Erstellung eines Prototyps des CMS, wie es im Spiralmodell gefordert wird, den Entscheidungsprozess unterstützen. Ebenfalls lassen sich frühzeitig Herausforderungen erkennen und beheben. Durch den zyklischen Ablauf kann früh Content in das System eingearbeitet werden, auch wenn im Hintergrund noch Optimierungen am CMS vorgenommen werden (z.B.: Anpassung des Berechtigungskonzeptes, Absicherung des CMS Systems etc.). Da das Spiralmodell in den einzelnen Zyklen auf traditionelle Vorgehensmodelle zurückgreift, ist es immer in Kombination mit diesen Modellen zu betrachten.^[73]

5.1.4 Agile Modelle

Es existiert eine Vielzahl von agilen Vorgehensmodellen. Der Großteil der Modelle bezieht sich auf die Softwareentwicklung und lässt sich nur bedingt auf die Einführung einer Software anwenden. Jedoch lassen sich Teilaspekte aus den Vorgehensmodellen auch auf Softwareimplementierungen übertragen. Grundsätzlich basieren die agilen Vorgehensmodelle auf dem im Jahr 2001 von 17 Softwareentwicklern beschlossenen agilen Manifest.^[74] In diesem Manifest wurden folgende grundsätzliche Prinzipien und Kernaussagen der agilen Vorgehensmodelle formuliert: "Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung helfen. Durch diese Tätigkeiten haben wir gelernt, das uns:

• Individuen und Interaktion wichtiger sind als Prozesse und Werkzeuge,
• funktionierende Software wichtiger ist als umfangreiche Dokumentation,
• Kooperation mit Projektbetroffenen wichtiger ist als Vertragsverhandlungen,
• Reaktion auf Änderungen wichtiger ist als Festhalten an einem starren Plan.

Natürlich sind auch die Dinge auf der rechten Seite wichtig, aber im Zweifelsfall schätzen wir die der linken Seite höher ein."^[75]

Alle agilen Vorgehensmodelle orientieren sich an den Modellen der "leichtgewichtigen Entwicklungsprozessen" (Lean Production) aus der produzierenden Industrie.^[76]

Die bekanntesten Vorgehensmodelle sind APM (Timeboxing-Verfahren), XP (eXtreme Programming) und Scrum.

Das Vorgehensmodell Scrum wurde 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle entwickelt. In einem Scrum-Projekt existieren nur drei Rollen, der Product Owner, der Scrum-Master und das Team. Es finden Iterationszyklen ("Sprints") von ca. zwei bis vier Wochen statt in denen das Scrum-Team arbeitet. In der Story werden in einem Scrum-Projekt die Anforderungen sowie der fachliche Bedarf und der Geschäftsnutzen beschrieben (siehe Abbildung 9). Eine Art der Umsetzung wird in der Story nicht festgelegt. Die oben genannten Rollen lassen sich mit den klassischen Rollen im Projektmanagement vergleichen. Der Product Owner ist der Auftraggeber (KPV). Er definiert die Anforderungen und priorisiert diese. Der Scrum-Master ist vergleichbar mit dem Projektleiter, welcher das Team bei der Umsetzung sowie der Problembehebung unterstützt. Er nimmt aber keine Leitungsfunktion ein. Scrum erfordert sowohl von dem einzelnen Mitarbeiter als auch vom Team ein eigenverantwortliches und selbstorganisiertes Arbeiten. Dem Team wird ein Großteil der Projektverantwortung mit sämtlichen dazugehörigen Rechten und Pflichten übertragen. Dies bedeutet ebenfalls, dass das IT-Management keinen direkt Einfluss mehr auf die im Projekt beteiligten Mitarbeiter hat.^[78]

Bei dem Vorgehensmodell XP (eXtreme Programming) handelt es sich hauptsächlich um eine Methode zur agilen Softwareentwicklung. Bei der Entwicklung steht die Implementierung der Software im Mittelpunkt. eXtreme Programming formuliert vier Grundwerte, aus denen sich 12 Grundpraktiken ableiten lassen. Die vier Grundwerte sind: Kommunikation, Einfachheit, Feedback und Mut.^[79] Aus diesen Grundwerten ergeben sich folgende Praktiken:

• Versionsplanung

Die Story/ Anforderungen werden durch Kunden für jede Version (Zyklus) formuliert.

• Kurze Releasezyklen

Der Releasezyklus dauert ca. ein bis zwei Monaten. Der Kunde legt hierbei die Prioritäten der Geschäftsanforderungen und somit den Inhalt der Release fest.

• Metapher für das System

Die Metapher wird zur abstrakten Beschreibung der Architektur verwendet. Sie soll allen Beteiligten ein modellhaftes Verständnis ermöglichen.

• Einfaches Design

Die einfachste voll funktionsfähige Lösung soll umgesetzt werden. Es sollen Redundanzen vermieden werden und eine möglichst geringe Anzahl an Klassen und Methoden verwendet werden.

• Testen

Funktions- und Komponententests sollen durchgeführt werden, welche durch den Kunden definiert sind.^[80]

• Refaktorisierung

Es erfolgt eine ständige Überarbeitung des Systems, um Fehler frühzeitig zu erkennen und die innere Struktur einfach und leicht verständlich zu halten.^[81]

• Programmieren in Paaren

Zwei Mitarbeiter programmieren gemeinsam an einem Rechner. Hierdurch wird die Kommunikation gefördert. Ein voneinander Lernen ist möglich.

• Gemeinsame Verantwortlichkeit

Jeder Mitarbeiter ist für die Qualität der gesamten Codes verantwortlich.

• Fortlaufende Integration

Nach erfolgreichem Test werden Änderungen oder Neuerungen kurzfristig integriert. Ist der Test nicht erfolgreich wird der Code verworfen. Durch die fortlaufenden Integration liegt immer eine auslieferbare Version vor.

• 40-Stunden-Woche

Überstunden sollen vermieden werden, da diese sich auf längere Sicht kontraproduktiv auswirken.

• Kunde vor Ort

Der Kunde unterstützt direkt bei Rückfragen, Problemen oder Setzung von Prioritäten. Er wird als positiv wirkender Partner gesehen.

• Programmierstandards

Es muss sich auf gemeinsame Programmierstandards im Team geeinigt werden.^[82]

Beim APM-Verfahren wird mit Iterationen (Timeboxen) gearbeitet. Zentrale Idee ist es hierbei, Versionen (Meilensteine) in festen Zeitabständen zu erarbeiten. Die Zeiträume (Timeboxen) werden im Vorfeld festgelegt und müssen eingehalten werden. Es kommt bei diesem Modell eher zu Kürzungen der Version als zur Verschiebung der Timeboxen. Hierdurch wird eine absolute Planungssicherheit erreicht. ^[84]

Über den Projektverlauf erfolgt beim APM-Verfahren eine inkrementelle Annährung an ein bewegliches Ziel (Siehe Abbildung 11). Innerhalb jeder Iteration existiert ein Mikroprozess, welcher selbst aus einem Phasenzyklus besteht (Siehe Abbildung 12). Am Ende jedes Phasenzyklus steht immer ein messbares Ergebnis. Eine Metaplanung über sämtliche Planungsebenen des gesamten Projektes wird erstellt und in Zyklen aktualisiert. Hierzu werden die Planungsebenen in die drei Ebenen Projektebene, Releaseebene und Team-/ Iterationsebene aufgeteilt. In der Projektebene erfolgt eine Definition der Projektziele und Releasefeatures. Aus diesen Definitionen werden ein Projekt- und ein Releaseplan erstellt. Die Definitionen und auch die erstellten Pläne werden über die Projektlaufzeit regelmäßig aktualisiert. In der Releaseebene der Planung werden Ziele und Anforderungen aus den Releasefeatures abgeleitet und einem Team zur Bearbeitung zugewiesen. Hier erfolgt ebenfalls eine Priorisierung der Anforderungen. Als Gesamtergebnis wird der Iterationsplan entwickelt. Auf der Team-/ Iterationsebene werden die Ergebnisse der Releaseebene weiter verfeinert. Es erfolgt eine Aufgabenzuordnung zu einzelne Mitarbeitern und eine Grobplanung der Folge-Iteration wird vorgenommen. Diese drei Ebene werden über den Projektverlauf mehrfach zyklisch durchlaufen (siehe Abbildung 13).^[87]

Durch diese agilen Vorgehensmodelle soll das Risiko in Projekten minimiert werden, da der Auftraggeber von Anfang an in die Entwicklung involviert ist. Durch die enge Zusammenarbeit von Projektteam und Auftraggeber wird in agilen Projekten ein hohes Maß an Transparenz erreicht, jedoch wird vom Auftraggeber im Gegenzug Vertrauen erwartet, da zu Projektbeginn nur ein grober finanzieller Rahmen und die grundlegenden Projektziele definiert werden.^[89]

5.2 Projektphasen

In vielen Modellen, die im Abschnitt Vorgehensmodelle erläutert werden, bildet ein Phasenkonzept die Grundlage. Durch die Gliederung in Projektphasen wird die Komplexität eines Projektes verringert. Die fünf Phasen Analyse, Konzeption, Realisierung, Implementierung und Wartung finden sich in allen Vorgehensmodellen wieder. Teilweise werden die Phasen einmalig oder auch in Zyklen durchlaufen. In dem folgenden Abschnitt wird jede Phase genauer erläutert und aufgegliedert. Ebenfalls findet eine Übertragung der allgemeinen Kriterien auf CMS Projekte statt.

5.2.1 Analyse

5.2.1.1 Ist Analyse

Die Ist-Analyse befasst sich mit der Untersuchung des Unternehmens. Hierbei werden die organisatorischen sowie technischen Aspekte untersucht und ein besonderes Augenmerk auf Schwachstellen gelegt. Diese werden dann in einer Potentialanalyse zusammengefasst. Als Abschlussdokumente der Ist-Analyse entstehen die Systembeschreibung und der Schwachstellenbericht. Unterteilen lässt sich die Ist-Analyse noch in die Systemabgrenzung, Systemerhebung und die Potentialanalyse. In der Systemabgrenzung wird festgelegt, welche Teile des Unternehmens in die Untersuchung mit einbezogen werden. ^[90] Die aufgedeckten organisatorischen oder technischen Schwachstellen aus der Potentialanalyse werden als Verbesserungspotentiale verstanden. Schwachstellen sind beispielsweise die fehlende IT-Unterstützung bei einer manuellen Suche in Karteien oder fehlende Informationen über einzelne Funktionen eines Prozesses. ^[91]

5.2.1.2 Prozessanalyse

Die Prozessanalyse untersucht die Merkmale der aktuellen Content Management Prozesse. Hierbei werden die etablierten Prozesse untersucht, unterschiedliche Aspekte hinterfragt:

• Wer ist für den Content verantwortlich, bzw. wer ist Content-Eigner?
• Lassen sich Verantwortungsbereiche definieren?
• Wie groß ist der Zeitraum zwischen der Erstellung eines Contents und seiner Veröffentlichung? (Durchlaufzeiten)
• Welche Informationsklassen gibt es und wie hoch ist ihr jeweiliges Aufkommen?
• Wie sehen vorgelagerte Prozesse aus, welche Schnittstellen gibt es?
• Kommt die Information auf Papier oder als Datei und ist der Content strukturiert oder unstrukturiert?
• Welche Medienbrüche gibt es?
• Wie wird der Content selbst verarbeitet und welche Hilfsmittel werden verwendet?
• Welche Qualifikationen sind nötig um den Content verarbeiten zu können?
• Wer bekommt das Ergebnis der Arbeit und welcher Prozess schließt sich nachgelagert an?
• Welche Ziele werden verfolgt?

Die Prozessanalyse erfolgt in der Regel durch Interviews mit den beteiligten Personen. Dabei sind die Kompetenz des Interviewers sowie die der befragten Person entscheidend für die gewonnenen Informationen. ^[92]

5.2.1.3 Anforderungsanalyse

Die Anforderungsanalyse befasst sich mit den konkreten Anforderungen des Auftraggebers an das CMS. Die individuellen Anforderungen können von Unternehmen zu Unternehmen sehr unterschiedlich sein. Dennoch gibt es einige Kernanforderungen die ein CMS erfüllen sollte. Dazu zählen unter anderem: ^[93]

• leichte Bedienbarkeit: Das CMS sollte ohne größere Einschränkungen von den Mitarbeitern gepflegt werden, die den Prozess begleiten und das fachliche Know-How haben. Außerdem erhöht eine leichte Bedienbarkeit die Akzeptanz der Mitarbeiter gegenüber dem neuen Produkt. Ein einheitliches Erscheinungsbild der Benutzeroberfläche erleichtert zusätzlich die Bedienbarkeit und verbessert die Übersichtlichkeit. Die Anwender finden sich dadurch schneller zurecht, wodurch übermäßig viele Schulungsmaßnahmen eingespart werden können. Außerdem sollte sich das System möglichst so einfach bedienen lassen, dass nicht unnötig viele Dienstleister zu Rate gezogen werden müssen. Dies spart Kosten für Speziallisten und erhöht die Flexibilität und Reaktionsfähigkeit, da nicht auf externe Reaktionen gewartet werden muss.^[94]
• hohe Integrationsfähigkeit und Flexibilität: Für die Anbindung weiterer Systeme und Informationsquellen ist es sehr wichtig, dass das Produkt offene und technisch flexible Schnittstellen aufweist, sodass die Integration des neuen CMS in die bestehende Systemlandschaft gut eingebettet werden kann. Wichtig sind zum Beispiel Schnittstellen zu unterschiedlichen ERP-, CRM-, SCM-, Shop- oder Branchen-Lösungen. Ohne gute Schnittstellen lässt sich das CMS nur schwer anbinden und integrieren. Ein weiterer wichtiger Aspekt ist die modulare Erweiterbarkeit des CMS. Das CMS sollte im Laufe des Unternehmenswachstums mitwachsen können. Dadurch wird die Investitionssicherheit gewährleistet und das CMS kann den Anforderungen des Managements sowie der Belegschaft erfüllen. Neue Applikationen sollten sich ohne größere Probleme integrieren lassen. Bei der Optimierung von Geschäftsprozessen werden häufig neue Funktionalitäten benötigt, sodass sich das System unkompliziert und kosteneffektiv erweitern lassen könnte. ^[95]
• internationale Mehrsprachigkeit: Ein CMS sollte ohne größere Aufwendungen mit mehreren Sprachen umgehen können. Dadurch entsteht die Möglichkeit, internationale Tochterfirmen oder Kunden an das System anbinden zu können. Außerdem lassen sich je nach Anwendungsfall auch sehr einfach neue Märkte erschließen. ^[96]
• solider und vertrauenswürdiger Hersteller: Um das System in Zukunft sicher betreiben zu können und auch weiterhin Support für das CMS zu bekommen, sollte bei der Auswahl des richtigen CMS auch der Hersteller berücksichtigt werden. Ein solider und finanzkräftiger Anbieter kann längerfristig den Support garantieren und auch regelmäßige Updates und neue Technologien liefern. Weiterhin sollte der Hersteller, Referenzkunden für das Produkt vorweisen können. Die Referenzkunden - möglichst aus der eigenen Branche - können oft eine bessere und langläufigere Meinung zu dem CMS abgeben als es der Verkäufer seblst. ^[97]
• Kosten: Bei der Auswahl des CMS werden sicherlich auch die Kosten eine Rolle spielen, dabei gilt aber immer zu beachten, dass auch Folgekosten wie Lizens und Wartungsgebühren für eine Software anfallen. Diese sollten für auch vorher schon für den Kunden transparent sein, sodass nachher keine unerwarteten Kosten auftreten. ^[98]

5.2.1.4 Soll-Konzept

Im Sollkonzept wird ein grober Softwareentwurf aus Benutzersicht erstellt. Der Schwerpunkt der Phase liegt eher in der Reorganisation und den organisatorischen Ablauf- bzw. Aufbaustrukturen. ^[99] Das technische Systemkonzept beschränkt sich zunächst nur auf die Ermittlung der Kosten für die technischen Anforderungen, sodass für die folgenden Wirtschaftlichkeitsbetrachtungen genügend Informationen zur Verfügung stehen. ^[100] Die in der Ist-Analyse herauskristallisierten Schwächen werden im Sollkonzept noch mal aufgegriffen und mögliche Verbesserungen sowie Leistungsmerkmale des neuen CMS ausgearbeitet. Außerdem werden die wirtschaftlichen Vorteile, die vom neuen CMS zu erwarten sind herausgearbeitet. ^[101] Im Pflichtenheft, das größtenteils in der Phase des Sollkonzepts erstellt wird, werden ferner die folgenden Informationen für den Auftraggeber zusammengestellt::

• Personalbedarf (Anzahl und Qualifikation) für die Projektabwicklung
• Entwicklungs- / Anpassungskosten (Projektkosten)
• ein grober Zeitplan für die Realisierung und Einführung
• Schulungs- und Einarbeitungsaufwand für die Anwender
• Kosten für zusätzliche / neue Infrastruktur
• Folgekosten für Wartung und Pflege
• mögliche Einsparungen und erwarteter Nutzen (Return on Investment)

Aufgrund dieser Angaben muss der Auftraggeber entschieden, ob das Projekt durchgeführt wird ^[102] und ob eine Individuallösung geschaffen werden muss oder eine Standardsoftware die Anforderungen erfüllen kann. ^[103]

5.2.1.5 Aufwandsabschätzung

Die Aufwandsabschätzung befasst sich damit, die während der Projektplanung unterteilten Phasen bzw. Aufgaben zu bewerten und die dafür aufzuwendende Zeit zu ermitteln. Der Projektverantwortliche muss dabei einige Antworten auf die folgenden Fragen einschätzen: Wie viel Aufwand ist für die Erledigung einer Aufgabe erforderlich? Wie viel Zeit ist für die Erledigung einer Aufgabe erforderlich? Wie hoch sind die für eine Aufgabe anfallenden Gesamtkosten? ^[104] Wird von einem neu zu entwickelten System ausgegangen, kann der Umfang der Arbeit anhand der Lines of Code (LOC) angeschätzt werden. Diese werden dann für eine monetäre Bewertung umgerechnet in Mitarbeitermonate. Die wichtigsten Einflussfaktoren auf den zu kalkulierenden Aufwand sind: die geforderte Qualität, Bedienbarkeit, Quantität, Entwicklungsdauer und Kosten. ^[105] Welche Methode letztendlich für die Aufwandsabschätzung verwendet wird, ist vom Projekt abhängig. Die Analogiemethode und Relationsmethode bestimmt den Aufwand durch den Vergleich mit ähnlichen Entwicklungen. Die Multiplikatormethode bestimmt den Aufwand, indem das Gesamtsystem soweit in Teile zerlegt wird, bis ein bereits bekannter feststehender Aufwand zugeordnet werden kann, z.B. Lines of Code für E/A-Programme. Bei der Gewichtungsmethode werden Faktoren definiert, die für die Schätzung relevant sind. Diese werden dann mit einer vorgegeben Formel verknüpft und ergeben den Gesamtaufwand. Die Prozentansatzmethode basiert auf bereits abgeschlossenen Entwicklungsschritten und vergleicht den bisherigen Aufwand mit dem restlichen noch umzusetzenden Entwicklungen und bestimmt den Gesamtaufwand. ^[106]

5.2.1.6 Kostenanalyse

In der Kostenanalyse soll eine der wichtigsten Fragen überhaupt beantwortet werden: "Was kostet ein Content Management System?". Diese Frage lässt sich allerdings nicht pauschal beantworten, da je nach Einsatzbereich, Funktionsumfang, Positionierung und Offenheit des Systems das Preisniveau sehr unterschiedlich ist. Außerdem gibt es große Unterschiede in den Lizenzmodellen der unterschiedlichen Hersteller. Dabei wird unterscheiden zwischen eigentlichen Kauf der Applikation und der Beauftragung einer Dienstleistung, bei der ein Komplettsystem bereitgestellt wird. Hierbei wird die Software von einem so genannten Application Service Provider (ASP) gemietet, anstatt die Software zu kaufen. Die Vorteile und Nachteile der unterschiedlichen Möglichkeiten müssen dabei abgewogen werden. Weiterhin gibt es unterschiedliche Modelle was die Userlizenzierung betrifft, dabei gibt es häufig "Concurrent User" oder "Named User" Lizenzierungsmodelle. Pauschal kann nicht festgelegt werden, welches Modell das Günstigere ist, dies ist wiederum abhängig von der Nutzung des Applikation. ^[107] Neben den kommerziellen Produkten gibt es auch Open-Source-Appliationen, die eventuell auch den Anforderungen entsprechen. Open-Source Software hat allerdings den Nachteil, dass es schwieriger ist, Support Verträge zu bekommen. ^[108]

Die Kostenanalyse ist ein wichtiger Aspekt der Analysephase. Die Ergebnisse fließen mit in das Sollkonzept ein. Es können unterschiedliche Vergleiche durchgeführt werden, zunächst nur reine Kostenvergleiche. Hierbei werden nur die einmaligen Kosten (Entwicklung, Einführung, Lizenzen) und die laufenden Kosten (Wartung, Pflege, Änderung, Erweiterung) der unterschiedlichen Alternativen miteinander verglichen. Nachteilig an der reinen Kostenvergleichsrechnung ist, dass der Nutzen des neuen Produkts außer Acht gelassen wird. Der Nutzen oder auch die Wirtschaftlichkeit einer Anschaffung wird durch eine Nutzwertanalyse ermittelt, auf die im folgenden Abschnitt eingegangen wird.^[109]

5.2.1.7 Nutzwertanalyse / Wirtschaftlichkeitsbetrachtung

Nach Zangemeister: "Nutzwertanalyse ist die Analyse einer Menge komplexer Handlungsalternativen mit dem Zweck, die Elemente dieser Menge entsprechend den Präferenzen des Entscheidungsträgers bezüglich eines multidimensionalen Zielsystems zu ordnen."^[111]

Um die Wirtschaftlichkeit besser vergleichen zu können wird meist eine Kosten-/ Nutzenanalyse durchgeführt. Dabei wird der Nutzern in quantifizierbaren Nutzen und nicht quantifizierbaren Nutzern unterteilt. Der quantifizierbare Nutzen lässt sich jedoch teilweise nicht monetär bewerten. Dieser Nutzen wird dann als qualitative Effekte bezeichnet. Die Hauptschwierigkeit bei dem Kosten/Nutzenvergleich ist es, den nicht monetäre Nutzen durch Multiplikatorverfahren mit in die Betrachtung einzubeziehen. ^[112]

5.2.2 Konzeption

Die Abläufe in der Einführung eines WCMS gliedern sich in die Phasen Briefing, Konzeption, Testphase, Abnahme bzw. Freigabe, Onlinebetrieb.^[113] "Die eigentliche Feinarbeit der Planung ist die Konzeption, wobei sich Projekte ohne WCMS von Projekten mit einem WCMS unterscheiden. Hierbei sollte außer einer genauen Projektdefinition auch die optimale Vorgehensweise geklärt werden. Organisatorische Aufgaben werden geplant, die benötigten Ressourcen abgeschätzt und die jeweiligen Kompetenzen verteilt."^[114]

5.2.2.1 Übersicht über die unterschiedlichen CMS

In der folgenden Abbildung sehen Sie einige CMS im Vergleich.

5.2.2.2 Auswahl des richtigen CMS

Die Auswahl des richtigen CMS ist von strategischer Bedeutung abhängig, da ein späterer Wechsel hohe Kosten verursacht. Die Anforderungen müssen zum System passen, es sollen auch K. o. -Kriterien definiert werden, also Punkte die unbedingt in dem CMS vorhanden sein sollten.^[116] Die Grundlage zur Auswahl des passenden Systems, ist das Beschreiben der Probleme, die gelöst werden sollten. Der Einsatz des Systems wird taktisch oder strategisch erfolgen.

• taktisch: Probleme sollen kurzfristig ohne Aufwand gelöst werden
• strategisch: Probleme sollen ganzheitlich, langfristigen Ansatz begegnet werden

Aus Gründen des Investitionsschutzes sollte der strategische Ansatz gewählt werden. Hohe Bedeutung erhält bei der Einführung eines Web Content Managements die projektorientierte Arbeit. Hier wird häufig von einer Wechselbeziehung zwischen Auftraggeber und Auftragnehmer gesprochen. Beim Auftraggeber kann es sich um einen Website-Betreiber oder Kunden handeln, beim Auftragnehmer um ein Projektteam, die interne IT-Abteilung oder ein externes Unternehmen. Ein WCMS sollte nicht zum Selbstzweck eingeführt werden, da andere Unternehmen dies auch tun. Wichtig sind eine einfache Bedienung und die Umsetzung individueller Anforderungen an die Verfügbarkeit der Inhalte. Dabei sollte man eine zukunftsorientierte und investitionssichere Denkweise nicht aus den Augen verlieren. Die Vorgehensweise in der Planung ist vergleichbar, wie bei einem normalen Webauftritt, abgesehen davon, dass eine stärkere Ausarbeitung der Details notwendig ist. In der Praxis wird in unterschiedlichen Konzeptarten unterteilt, diese werden von den Verantwortlichen erstellt und in das Gesamtkonzept zusammengefasst. Bei der Erstellung muss eine bestimmte Reihenfolge eingehalten werden, die wie folgt untergliedert ist:

• Zielsetzung - Es wird festgelegt, was mit dem System erreicht werden soll
• inhaltliches Konzept - Welche Inhalte werden integriert bzw. produziert
• Informationsmanagement-Konzept - Welche Datenformate im Repository verwaltet bzw. weiterverarbeitet werden
• Redaktionskonzept - zeigt die Prozesse, die den Weg des Life-Cycle-Modell durchlaufen
• Rechtekonzept - Rechte, Rollen und Pflichten werden hier vergeben
• Mediakonzept - Überlegungen zur späteren grafischen Oberfäche (GUI)
• Technisches Konzept - Was wird vom System geleistet? Welche Hardware, welche Software?
• Deployment Konzept - Serverstrategie, einzelne Systeme unterteilen und installieren
• Schulungskonzept - Schulungen für Redaktionen, Anwender, Administratoren, Agenturen Entwickler etc.
• Betriebskonzept - Wartung, Verfügbarkeit, Ansprechpartner u.a. ^[117]

5.2.2.3 Sicherheit

Um eine optimale Sicherheit zur garantieren, muss das CMS System von außen und innen vor Systemangriffen gesichert werden. Die sichere Datenhaltung und der sichere Datentransfer an dritte erfolgt über die aktuellen Sicherheitsstandards. Für unvorhergesehenen Systemausfällen sollte es sowohl Ersatzhardware als auch Software zur Verfügung stehen.^[118] "Eine entsprechend hohe IT-Sicherheit vorausgesetzt sollte das Content Management-System diese Standards nicht torpedieren oder ad absurdum führen. Daher und wegen derteilweise sensiblen Inhalte des Contens sind System-immanente Sicherheitskriterien wichtig. Darüber hinaus sollte das Content Management-System ohne allzu große Probleme in die hauseigene IT-Infrastruktur passen und sich sowohl betriebssicher als auch stabil präsentieren."^[119]

5.2.3 Realisierung

In der Realisierungsphase werden die Konzeptionen umgesetzt. Die Phase beinhaltet außer der Leistungserstellung auch den Test und die Dokumentation des erstellten Systems. ^[120]

5.2.3.1 Leistungserstellung

Bei der Leistungserstellung unter Verwendung einer Standardsoftware steht die Installation und Konfiguration des Systems im Vordergrund. Nach erfolgreicher Installation erfolgt das Anpassen an die individuellen Anforderungen des Auftraggebers. Die Hauptaufgaben bei der Systemanpassung, auch als Customizing bezeichnet, sind die Parametrisierung, die Konfigurierung und die Ergänzungsprogrammierung. Bei der Parametrisierung werden alle benötigten systeminternen Parameter auf die Anforderungen angepasst. In der Konfigurierung (auch als Modularisierung bezeichnet) werden die benötigten Module aus einer Auswahl selektiert und dem Programm hinzugefügt. Im Rahmen der Ergänzungsprogrammierung werden individuelle Anpassungen und Erweiterungen entwickelt. Je höher der Grad der Anpassung ist, desto teurer wird die angepasste Lösung. ^[121] Bei der Realisierung einer Eigenentwicklung bildet die Programmierung die Hauptaufgabe der Leistungserstellung. Der Ablauf der Programmierung ist abhängig von den benutzten Vorgehensmodellen, Methoden und Prinzipien. ^[122] Unter der Voraussetzung der Verwendung einer Standardsoftware als CMS erfolgt in diesem Schritt die Installation des CMS auf einer Hardware. Meist reichen das Kopieren der Programmpakete auf einem Webserver und der Start der Installationsroutine. Die benötigte Datenbank und die grundlegende Konfiguration werden meist von der Installationsroutine eingerichtet. Nachdem das CMS installiert wurde, kann das Customizing des CMS erfolgen (siehe Abbildung 16). Im Rahmen der Modularisierung werden die benötigten Module installiert. Des Weiteren müssen, falls benötigt, Schnittstellen zu vorhandenen Systemen eingerichtet und parametrisiert werden. Beispielsweise die Schnittstelle zu einem LDAP Server für das Berechtigungssystem oder die Schnittstelle zu einem DMS dessen Daten im CMS dargestellt werden sollen. Weitere Anpassungen wie beispielsweise die Anpassung an das Corporate Design, Gestaltung der Menüs und Templates sowie die Einrichtung der Benutzer und Berechtigungen sollten vorgenommen werden. ^[123] Falls weitere Funktionen oder Anpassungen benötigt werden, die der Funktionsumfang des CMS nicht abdeckt, können diese durch Ergänzungsprogrammierung hinzugefügt werden. ^[124]

5.2.3.2 Test

Nach der Leistungserstellung oder Fertigstellung eines Release erfolgt der Test des Systems. "Unter Testen im engeren und klassischen Sinn versteht man die Prüfung von codierten Programmen auf korrekte Formulierung und Ausführung". ^[126] Durch frühe Tests am System können auch schon während der Leistungserstellung Fehler gefunden und behoben werden. Ziel des Tests ist die Verifikation, ob das System die geforderten Leistungen erbringt. Es existieren vielfältige Testverfahren, wie der symbolische Test (Codeüberprüfung) oder das computergestützte Testen, welches sich in die folgenden Stufen aufteilen lässt: Einzeltest (Modul), Integrationstest (Komponenten), Systemtest, Abnahmetest. ^[127] Jede einzelne Stufe lässt sich weitergehend in die Schritte Testvorbereitung, Testdurchführung und Testnachbereitung gliedern. ^[128] Bei einem CMS wäre folgendes Vorgehen denkbar: Als erstes sollte eine Funktionsüberprüfung der Subsysteme (Nutzerzugänge, Templates, Systemfunktionen, Webfunktionen) stattfinden. Ist diese erfolgreich, kann ein Testlauf unter Realbedingungen gestartet werden. Bei diesem Testlauf arbeiten Nutzer mit Testzugängen am System. Dies ermöglicht zu einem späteren Zeitpunkt das leichte Entfernen der Testdaten. Sobald Daten im System vorhanden sind, können Automatismen getestet werden. Während des gesamten Testverlaufs sollte das System beobachtet und auf Fehler überprüft werden. Wichtig ist, dass sowohl der erzeugte Webcontent als auch das Redaktionssystem betrachtet wird. Ebenfalls sollte die Auslastung und Reaktionsgeschwindigkeit der Hardware geprüft werden. Es kann mit gezielter Produktion von Fehlern das Verhalten des Systems im Ernstfall simuliert werden. Am Ende des Testlaufs sollten alle noch vorhandenen Probleme identifiziert sein. Diese sollten korrigiert und einem weiteren Testlauf unterzogen werden. ^[129]

5.2.3.3 Dokumentation

Die Dokumentation beinhaltet sowohl die Benutzerdokumentation als auch die Verfahrensdokumentation. Die Benutzerdokumentation soll dem Benutzer als Hilfe für die Verwendung des Programms dienen. Sie besteht beispielsweise aus den Bedienungsanleitungen, Benutzerhandbüchern und Arbeitsanweisungen. Diese können als Online-Hilfe oder in rein textlicher Form implementiert werden. ^[130] Die Verfahrensdokumentation ist eine technische Dokumentation des Systems. Sie beinhaltet "dv-spezifische Unterlagen wie Programm- und Dateibeschreibungen, Datenflusspläne oder auch technische Dokumentationen wie Schaltpläne, Wartungs- und Reparaturanleitungen für den Kundendienst." ^[131] Generell gilt: "Programme werden umso verständlicher und damit umso leichter wartbar, je besser sie beschrieben (dokumentiert) sind." ^[132] Bei einer Standardsoftware als CMS liegen meist umfangreiche Dokumentationen zu dem System vor. In diesem Fall sind nur die Anpassungen zu dokumentieren, wie beispielsweise ein Berechtigungskonzept oder die verwendeten Parameter für eine Schnittstelle. Es sollte alles dokumentiert werden, was vom Standard abweicht. Bei einer Eigenentwicklung müssen sämtliche Dokumentationen selbst erstellt werden. Hier sollte die Verfahrensdokumentation ausführlich gestaltet werden. Die Benutzerdokumentation sollte zusammen mit einigen Benutzern erstellt werden und kann ggf. als Grundlage für Schulungen in der Implementierungsphase genutzt werden. Ebenfalls zur Dokumentation zählen Testprotokolle. Testprotokolle sind nach der Testdurchführung zur erstellen und bilden ihr Ergebnis. Die Protokolle enthalten allgemeine Informationen zu den durchgeführten Tests. Sie dokumentieren die bei der Testdurchführung festgestellten Abweichungen. "Das Testgeschehen sollte protokolliert werden, damit bei Problemen im späteren Wirkbetrieb eine Datenbasis zur Fehlersuche existiert." ^[133]

5.2.4 Implementierung

"Implementierung bedeutet allgemein die Überführung eines geplanten in ein reales funktionsfähiges System". ^[134] Die Implementierung enthält die Schritte Vorbereitung, Training, Inproduktionsnahme, Projektabschluss und Abnahme. ^[135]

5.2.4.1 Vorbereitung

Die Phase Implementierung startet mit der Vorbereitung. In dieser Teilphase erfolgt eine förmliche Systemfreigabe. Diese setzt die Vollständigkeit der Systemdokumentation und das erfolgreiche absolvieren der Test in der Phase Realisierung voraus. ^[136] Zusätzlich wird in der Vorbereitung eine Auswahl der Personen getroffen, die Träger des Implementierungsprozesses sind. Für dieses Team werden die organisatorische Stellung und die Entscheidungskompetenzen in Bezug auf die Implementierungsaufgaben festgelegt. Letztlich erfolgt in der Vorbereitung die Definition des Zeitpunktes für den Beginn der Implementierung. ^[137]

5.2.4.2 Schulung

Durch Schulungen wird die individuelle Qualifikation der Mitarbeiter erhöht. Sie lernen mit dem System umzugehen und ihre alltäglichen Arbeiten zu erledigen. Durch Schulungen im Vorfeld wird den Benutzern die Angst vor dem neuen System genommen und einer Überforderung der Benutzer verhindert. Schulungsmaßnahmen sollten so strukturiert sein, dass zuerst die grundlegenden Inhalte vermittelt werden, bevor die Details der einzelnen Funktionen geschult werden. Erfolgreich durchgeführte Schulungsmaßnahmen erhöhen die Qualifikation der beteiligten Mitarbeiter und vereinfachen deshalb die Implementierung. ^[138] Bei einem CMS sollten die Anwender gezielt auf die Bereiche geschult werden, mit denen sie arbeiten. Aus diesem Grund macht eine Trennung der Schulung beispielsweise in die Bereiche Backend und Frontend Sinn. Eine weitere Möglichkeit der Trennung sind die Aufgabenbereiche der jeweiligen Nutzer. Ein Onlineredakteur benötigt beispielsweise andere Kenntnisse als ein Entwickler oder ein Systemadministrator. Schulungen für CMS können bei Standardsystemen durch externe Dienstleister oder den Hersteller erfolgen. Sowohl bei Eigenentwicklungen als auch bei Standardsoftware sollte nach dem Keyuser Prinzip verfahren werden. Dies bedeutet, dass Schlüsselpersonen in dem System qualifiziert werden und dann ihr erworbenes Wissen an die übrigen Mitarbeiter weitergeben.
Nach Krüger/ Kopp sollten folgende Kernkompetenzen besonders geschult werden:

• WCMS-Kompetenz: Grundlegendes Wissen zur Bedienung und Administration des WCMS durch den Content-Manager oder Administrator
• Webkompetenz: Kenntnisse über den Aufbau und Funktionen des World Wide Webs sowie aktuelle Entwicklungen, wie beispielsweise Web 3.0
• Designkompetenz: Verständnis für grafisches Gestalten im Web und Wissen über die Usability/Ergonomie von Webseiten
• Projektkompetenz: Wissen über managen der Herausforderungen im Bereich Content Management ^[139]

5.2.4.3 Inproduktionsnahme

Die Inproduktionsnahme lässt sich generell in zwei Punkte aufspalten. Die technische Implementierung beschäftigt sich mit der Überführung des Konzeptes in ein lauffähiges System. Der zweite Punkt ist die organisatorische Implementierung. Diese konzentriert sich auf den organisatorischen Wandel und das Verhalten der zukünftigen Mitarbeiter, die mit dem System arbeiten. ^[140]

Technische Implementierung

stichtagsbezogene/ schlagartige Implementierung

Die schlagartige oder auch stichtagsbezogene Implementierung ist eine Totaleinführung des neuen Systems.
Die Einführung findet zu einem festen Termin statt, an dem alle Prozesse und Systeme auf die Neuen umgestellt werden. Durch die schlagartige Umstellung kommt es zu den wenigsten Brüchen oder Übergangslösungen, jedoch ist sie auch mit dem höchsten Risiko verbunden. Ohne größeres Risiko eignet sich diese Vorgehensweise nur für relativ kleine und einfache Lösungen. Teilweise ist eine schlagartige Einführung unumgänglich, wenn beispielsweise andere Implementierungsformen aus Kapazitäts- oder Kostengründen nicht möglich sind. Manchmal setzen der Betrieb der übrigen Systeme und ihre Abhängigkeit zum zu implementierenden System eine schlagartige Implementierung zwingend voraus. Für eine erfolgreiche Implementierung ist erforderlich, dass alle Mitarbeiter am Tag der Einführung mit dem neuen System arbeiten können. Dies erfordert eine hohe Flexibilität bei den Mitarbeitern und praxisorientierte Schulungen der Mitarbeiter im Vorfeld. ^[142] Bei CMS kann eine schlagartige Implementierung Sinn machen, da meist ein fixer Termin für den Launch einer Webseite besteht. Das alte CMS oder die von Hand gepflegten Webseiten werden zu diesem Zeitpunkt offline genommen.

stufenweise Implementierung
Bei einer stufenweisen Implementierung wird in Implementierungsstufen bei der Einführung gearbeitet. Das Sollkonzept teilt dabei das zu implementierende System in Teilbereiche auf. Die einzelnen Teilbereiche werden nacheinander, mit teilweise geringen Überschneidungen implementiert. Das Risiko ist deshalb geringer als bei einer schlagartigen Implementierung. Die Mitarbeiter können langsam (stufenweise) an das neue System herangeführt werden. Voraussetzung für die stufenweise Einführung ist, dass sich das System in Module aufgliedern lässt und diese unabhängig voneinander funktionieren. Eine stufenweise Implementierung wäre auch durch einen Zeitversatz pro Abteilung bei der Implementierung eines neuen Systems möglich. ^[143] Bei einem CMS ist es schwierig eine modulare Aufteilung vorzunehmen. Es könnte das Grundsystem implementiert werden und den Content pro Bereich stufenweise implementieren. Insgesamt ist diese Methode für ein CMS jedoch eher ungeeignet.

Parallelimplementierung
Bei der Parallelimplementierung existieren Ist- und Sollkonzept eine Übergangszeit lang nebeneinander. In diesem Parallelbetrieb kann das neue System ausführlich auf Brauchbarkeit geprüft werden. Wenn das neue System ausreichend stabil funktioniert, wird die Parallelität aufgegeben. Bei diesem Konzept existiert die höchste Sicherheit, da jederzeit zum alten System zurückgekehrt werden kann. Es ist jedoch auch das aufwendigste Konzept, da Änderungen an beiden Systemen parallel erfolgen sollten, um eine Asymmetrie der Systeme und Inhalte zu vermeiden. ^[144] Für eine CMS Implementierung ist eine parallele Implementierung eine aufwendige, aber praktikable Möglichkeit. Durch die hohen Kosten und Aufwände ist es nur bei geschäftskritischen Anwendungen interessant, da hier der Bedarf an Sicherheit bzw. die möglichen Ausfallkosten bei einem Fehler, die Kosten des Parallelbetriebs aufwiegen. Beispielsweise der Wechsel eines CMS auf den Systemen, die den Webshop des Unternehmens beinhalten.

Versuchsweise Implementierung
Die versuchsweise Implementierung ist die Implementierung eines Pilotsystems mit dem Ziel, aus der probeweisen Einführung, Erfahrungen zu sammeln. Falls eine unsichere Beurteilung bei Anwendung und Brauchbarkeit vorliegt, kann die Pilotinstallation helfen, Erfahrungen mit dem System zu sammeln und die Praxistauglichkeit zu überprüfen. Ziel ist ausschließlich der Praxistest um Erfahrungen zu sammeln und nicht die Implementierung des Systems für den dauerhaften Betrieb. ^[145] Diese Möglichkeit kann in frühen Phasen des Projekts zur Evaluierung von möglichen CMS verwendet werden.

Organisatorische Implementierung

Die organisatorische Implementierung soll bei der Durchsetzung neuer Informationstechniken unterstützen. Durch neue Systeme kommt es meist zur Ablösung alter Arbeitsabläufe und organisatorischen Änderungen. Um neue Systeme erfolgreich zu implementieren, ist die Akzeptanz der zukünftigen Nutzer zwingend erforderlich. Die Akzeptanzskala bewegt sich zwischen Begeisterung sowie freiwilliger Annahme und Nutzung des neuen Systems, bis zur Verweigerung oder sogar Sabotage des Systems. Die persönliche Akzeptanz wird durch die Faktoren Wissen, Können und Wollen beeinflusst. ^[146]
Die Herausforderungen die dabei auftreten können sind:

• Angst vor Neuen und Unbekannten
• Neuerung wird als Beanstandung einer bisher praktizierten Vorgehensweise empfunden
• Vorzugsweise Wahrnehmung positiver Erfahrungen
• Nutzen der Neuerung ist nicht immer sofort erkennbar
• Auftraggeber bzw. Entscheider schlagen sich auf die Seiten von Betroffenen
• Häufigkeit der Reorganisationsmaßnahmen und negative Erfahrung in anderen Projekten
• Psychologische Barrieren
• Person des Projektleiters

Diesen Herausforderungen kann durch Partizipation der Mitarbeiter entgegen gewirkt werden. Die Nutzer sollten schon im Vorfeld direkt oder indirekt an dem Projekt beteiligt sein. Dies bedeutet einerseits, dass alle Mitarbeiter laufend ausführliche und vorbehaltlose Informationen zu dem Projekt erhalten sollen. Andererseits sollten die zukünftigen Nutzer an dem Projekt mitarbeiten und ihre Wünsche und Lösungen einbringen. Nur ein akzeptiertes Projekt oder System kann erfolgreich implementiert werden ^[147]

5.2.4.4 Projektabschluss/ Abnahme

Zum Projektabschluss sind folgende Aktivitäten erforderlich:

• Produktabnahme
• Durchführung einer Projektabschlussanalyse
• Absicherung der gesammelten Erfahrungen
• Auflösen der Projektorganisation

In der Produktabnahme findet ein Abnahmetest des Systems statt. Die Ergebnisse werden in Abnahmetestprotokollen festgehalten und fließen in den Produktabnahmebericht mit ein. Bei der Projektabschlussanalyse werden die Plandaten den realen Daten des Projektverlaufs gegenüber gestellt. Es erfolgt eine detaillierte Analyse des Systems und des Projektverlaufes um aus diesen Erkenntnisse für folgende Projekte zu gewinnen. Aus diesen gesammelten Informationen wird der Projektabschlussbericht verfasst. Die Erfahrungen und Kernergebnisse, die im Projekt gewonnen worden sind, sollten dokumentiert werden, sofern diese für weitere Projekte relevant sind. Die Verfahren, wie beispielsweise Aufwandschätzverfahren können dadurch langfristig optimiert werden. Im letzten Schritt des Projektabschlusses erfolgt die Projektauflösung. Nach einer Abschlusssitzung in der die Übergabe des Abschlussberichtes erfolgt, werden das Projektteam und die projekteigenen Ressourcen aufgelöst und in ihren zukünftigen Arbeitsbereich entlassen.^[148]

5.2.5 Wartung

Nach der erfolgreichen Inbetriebnahme bzw. Einführung einer Software beginnt die Wartungs- und Pflegephase der Software. Durch die Anpassungen an der Basis (z.B.: Betriebssystem) müssen eventuell auch an der Software Anpassungen vorgenommen werden. Im täglichen Betrieb können Fehler auftreten oder der Wunsch nach neuen Funktionen aufkommen. Außerdem wird die Software immer weiter entwickelt und es werden neue Releases veröffentlicht. Wird die Software dann nicht auf dem aktuellen Stand gehalten, altert sie. ^[149] Bezogen auf Content Management Systeme ist die Entwicklung neuer Funktionen sehr schnell, und eine ständige Aktualisierung ist nötig.

5.2.5.1 Stabilisierung/ Korrektur

Unter der Stabilisierung/ Korrektur sind alle Tätigkeiten, die zur Fehlerbehebung dienen, zu verstehen. Hierbei kann es sich um Fehler handeln, die schon während der Entwicklung entstanden sind, aber auch um Fehler, die erst später bei der Wartung neu entstanden sind. Bei der Einführung eines Softwareprodukts können nicht alle Funktionen getestet werden, deshalb kommt es häufiger vor, dass auch nach der Inbetriebnahme und Abnahme noch Fehler auftreten. Die Fehlerbehebung wird allgemein als Wartung bezeichnet, obwohl es sich hier eigentlich noch um Restarbeit der Entwicklung handelt.^[150]

5.2.5.2 Optimierung/ Leistungsverbesserung

Zur Optimierung und Leistungsverbesserung gehören alle Aktivitäten, die dazu dienen, die Leistung des Produktes zu verbessern. Laut Balzert ist frisch eingesetzte Software unzuverlässig. Außerdem verbraucht die Software mehr Zeit und Speicher, als für die Aufgabenerfüllung notwendig wäre. Deshalb wird die Software im Rahmen der Wartung weiterentwickelt. Tuning, Monitoring und Reduzierung des Speicherplatzbedarfes sind entsprechend durchzuführende Aufgaben. Bei größeren Problemen muss eine Restrukturierung der Software vorgenommen werden, damit eine Leistungsverbesserung möglich ist. ^[151]

5.2.5.3 Anpassungen/ Änderungen

Unter Anpassungen und Änderungen sind alle nötigen Veränderungen der Software zu zählen, die aufgrund von Änderungen in der Softwareumgebung hervorgerufen werden. Dazu zählen beispielsweise eine neue Systemsoftware (z.B.: ein neues Betriebssystem), Anpassungen der Benutzeroberfläche oder der Formulare. Weiterhin können neue betriebliche Regelungen oder auch Gesetzesänderungen dazu führen, dass eine Software in ihrer Funktion angepasst werden muss. ^[152]

5.2.5.4 Erweiterungen

Unter Erweiterungen versteht man die funktionale Erweiterung einer Software. Hierbei können Funktionen, die in der Erstentwicklung zunächst geplant aber nicht umsetzt worden sind, implementiert werden. Aus einer neuen betrieblichen Anforderung kann ebenfalls der Erweiterungsbedarf entstehen. ^[153]

6 Fazit

Die vorliegende Seminararbeit hat das Ziel, ein Vorgehensmodell zur Einführung von CMS zu beschreiben. Zu diesem Zweck wurde nach der Definition der Grundbegriffe eine Auswahl von Vorgehensmodellen ausführlich dargestellt. Um diese zu vertiefen, wurde auf Elemente der grundlegenden Projektphasen eingegangen und diese in direktem Bezug zum Thema CMS gesetzt. Vorgehensmodelle, wie das Wasserfallmodell und das V-Modell sind relativ starr und unflexibel in ihrer Vorgehensweise, da die Anforderungen zu einem relativ frühen Zeitpunkt fest definiert werden müssen. Deshalb eignen sich die Vorgehensmodelle für kleine bis mittelgroße Projekte, in denen die Anforderungen gut strukturierbar und überschaubar sind. Beispiele hierfür wären die Einführung eines CMS für Intranetprojekte oder kleine bis mittlere Internetprojekte. Bei den evolutionären Vorgehensmodellen, wie beispielsweise dem Spiralmodell oder den agilen Vorgehensmodellen ist ein flexibles Vorgehen möglich. Durch den zyklischen Ablauf und die in jedem Zyklus überarbeiteten Anforderungen ist eine schnelle Reaktion auch bei "moving targets" (schnell wechselnden Anforderungen) möglich. Diese Vorgehensmodelle eignen sich besonders für die Entwicklung und Einführung von eigen entwickelte CMS oder auch CMS Projekte mit wechselnden Anforderungen oder unklaren Zieldefinitionen. Bei der Einführung von Content Management Systemen sind zu dem zu wählenden Vorgehensmodell auch die Projektphasen, die in diesen Vorgehensmodellen enthalten sind, wichtig. In der Analysephase sollten zunächst die unterschiedlichen Anforderungen des Auftraggebers definiert werden. Diese sollten schriftlich festgehalten werden, beispielsweise in Form eines Pflichtenheftes. Die Definition erfolgt in den Schritten Ist-Analyse, Prozessanalyse und Anforderungsanalyse. Um die Wirtschaftlichkeit des Projektes herauszustellen, kann eine Nutzwertanalyse mit optionaler Kostenanalyse und Aufwandsabschätzung durchgeführt werden. In der Konzeptionsphase erfolgt auf Basis der Analysephase die Erarbeitung eines konkreten Konzepts. Es ist ausgehend von einer Zielsetzung ein Feinkonzept für jeden der Bereichen, wie Inhalt, Informationsmanagement, Redaktion, Rechte, Media, Technik, Deployment, Schulung und Betrieb zu erstellen. Mit Hilfe der Feinkonzeption wird das den Anforderungen am besten entsprechende Produkt ausgewählt. Das erstellte Konzept wird in der Phase Realisierung umgesetzt. In dieser Phase werden die notwendigen Anpassungen an dem CMS vorgenommen und durch den Auftraggeber getestet. Die Erstellung einer ausführlichen Dokumentation des Systems sollte in dieser Phase erfolgen. Nach erfolgreichem Test kann das CMS in der Phase Implementierung in ein produktives System überführt werden. Zwingende Voraussetzung für die Inbetriebnahme ist die Schulung der Mitarbeiter. Die Inbetriebnahme erfolgt im Regelfall stichtagsbezogen, ist aber in Sonderfällen auch mit anderer Strategie möglich. Im produktiven System tauchen während der Nutzung neue Anforderungen oder Fehler auf, welche in der Phase der Wartung behoben werden. Der Aufwand für diese Phase sollte nicht unterschätzt werden. Besonders angepasste Standardsoftware oder Eigenentwicklungen erfordern eine ständige Aktualisierung. Zusammenfassend kann gesagt werden, dass kein einheitliches Vorgehensmodell für die Einführung von Content Management Systemen entwickelt werden kann, da die Projekte sehr heterogene Anforderungen haben. Beispiele hierfür sind unter anderem: CMS im Intranet, Extranet, Webseite (Internet), Webshop, DMS. Eine Kombination aus mehreren Vorgehensmodellen ist denkbar und wird in der Praxis häufig angewendet. In Zukunft werden CMS Projekte weiter an Bedeutung gewinnen, da der Einsatz von CMS große Vorteile für die Unternehmen bringt. Aufgrund dessen werden immer mehr Content Management Systeme in Unternehmungen eingesetzt. Je wichtiger diese Systeme für die Wertschöpfungskette des Unternehmens werden, desto wichtiger wird die reibungslose Einführung von Content Management Systemen. Strukturiertes Vorgehen und ein individuell entwickeltes Vorgehensmodell wird diese Herausforderungen beherrschbar machen.

7 Fußnoten

1. ↑ Vgl. Gantz et al., 2007, Seite 3
2. ↑ Vgl. IDC, 2010
3. ↑ Vgl. Zschau, 2010
4. ↑ Vgl. Ehlers, 2002, Seite 25
5. ↑ Riggert, 2009, Seite 1
6. ↑ Vgl. Riggert, 2009, Seite 1
7. ↑ Riggert, 2009, Seite 1
8. ↑ Quelle: Kollmann, 2009, Seite 42
9. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 9
10. ↑ Friedrich, 2006, Seite 1
11. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 9
12. ↑ Vgl. Friedrich, 2006, Seite 1
13. ↑ Koop/ Jäckel/ van Offern, 2001, Seite 9
14. ↑ Vgl. Rothfuss/ Ried, 2001, Seite 52
15. ↑ Ehlers, 2002, Seite 105
16. ↑ Vgl. Ehlers, 2002, Seite 105 f.
17. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 14
18. ↑ Quelle: Rothfuss/ Ried, 2001, Seite 22
19. ↑ Vgl. Rothfuss/ Ried, 2001, Seite 22 f.
20. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 16
21. ↑ Vgl. Rothfuss/ Ried, 2001, Seite 57
22. ↑ Friedrich, 2006, Seite 7
23. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 18 f.
24. ↑ Vgl. Adler, 2009, Seite 200
25. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 18 f.
26. ↑ Zachau, 1999, Seite 71
27. ↑ Vgl. Krüger/ Kopp, 2002, Seite 72
28. ↑ Vgl. Stojanovic, 2006
29. ↑ Vgl. Altman/ Fritz/ Hinderink, 2008
30. ↑ Vgl. Ehlers, 2002, Seite 108
31. ↑ Ehlers, 2002, Seite 108 f.
32. ↑ Vgl. Zschau/ Traub/ Zahradka, 2002, Seite 54 ff.
33. ↑ Quelle: Zschau/ Traub/ Zahradka, 2002, Seite 56
34. ↑ Vgl. Zschau/ Traub/ Zahradka, 2002, Seite 56
35. ↑ Quelle: Mangler, 2006, Seite 74
36. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 215 f.
37. ↑ Mangler, 2006, Seite 73
38. ↑ Vgl. Mangler, 2006, Seite 73 ff.
39. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
40. ↑ Vgl. Krüger/ Kopp, 2002, Seite 55
41. ↑ Vgl. Gulbins/ Seyfried/ Strack-Zimmermann, 2002, Seite 5, 10 f.
42. ↑ Vgl. Krüger/ Kopp, 2002, Seite 55
43. ↑ Vgl. Gulbins/ Seyfried/ Strack-Zimmermann, 2002, Seite 11
44. ↑ Vgl. Lehner, 2009, Seite 250
45. ↑ Quelle: Lehner, 2009, Seite 251
46. ↑ Vgl. Zschau/ Traub/ Zahradka, 2002, Seite 71, 97
47. ↑ Vgl. Sommerville, 2008, Seite 96
48. ↑ Quelle: Sommerville, 2008, Seite 97
49. ↑ Vgl. Dumke, 2000, Seite 104
50. ↑ Sommerville, 2008, Seite 96 f.
51. ↑ Sommerville, 2008, Seite 97 f.
52. ↑ Quelle: Stein, 2004, Seite 41
53. ↑ Vgl. Stein, 2004, Seite 5 ff.
54. ↑ Vgl. BRD, 2004, Seite 6 f.
55. ↑ Vgl. Stein, 2004, Seite 41
56. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
57. ↑ Vgl. Litke, 2007, Seite 257 ff.
58. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
59. ↑ Vgl. Litke, 2007, Seite 257 ff.
60. ↑ Vgl. Buhl, 2004, Seite 15
61. ↑ Quelle: Abts/ Mülder, 2009, Seite 306
62. ↑ Vgl. Abts,Mülder 2009, Seite 306 f.
63. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
64. ↑ Vgl. Litke, 2007, Seite 257 ff.
65. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
66. ↑ Vgl. Litke, 2007, Seite 257 ff.
67. ↑ Vgl. Litke, 2007, Seite 257 ff.
68. ↑ Vgl. Buhl, 2004, Seite 15
69. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
70. ↑ Vgl. Buhl, 2004, Seite 15
71. ↑ Vgl. Litke, 2007, Seite 257 ff.
72. ↑ Vgl. Litke, 2007, Seite 257 ff.
73. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
74. ↑ Vgl. Beck et al., 2001
75. ↑ Hoffmann, 2007, Seite 5 ff.
76. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
77. ↑ Quelle: Kriegisch, 2006
78. ↑ Vgl. Korsch, 2010, Seite 42 ff.
79. ↑ Vgl. Beck, 2000, Seite 29 ff.
80. ↑ Vgl. Beck, 2000, Seite 53 ff.
81. ↑ Vgl. Fowler, 2000, Seite 41 ff.
82. ↑ Vgl. Beck, 2000, Seite 53 ff.
83. ↑ Quelle: Stein, S. 2004, Seite 55
84. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
85. ↑ Quelle: Oestereich 2007, Seite 20
86. ↑ Quelle: Oestereich, 2007, Seite 20
87. ↑ Vgl. Oestereich, 2007, Seite 18 ff.
88. ↑ Quelle: Oesterreich, 2007, Seite 21
89. ↑ Vgl. Hoffmann, 2007, Seite 5 ff.
90. ↑ Vgl. Fischer, 2000, Seite 351 ff.
91. ↑ Vgl. Fischer, 2000, Seite 358 f.
92. ↑ Wilhems , 2002, Seite 394 ff.
93. ↑ Vgl. Onasch, 2006
94. ↑ Vgl. Onasch, 2006
95. ↑ Vgl. Onasch, 2006
96. ↑ Vgl. Onasch, 2006
97. ↑ Vgl. Onasch, 2006
98. ↑ Vgl. Onasch, 2006
99. ↑ Vgl. Fischer, 2000, Seite 362 f.
100. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 245
101. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 244 f.
102. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 247 f.
103. ↑ Vgl. Fischer, 2000, Seite 362 f.
104. ↑ Vgl. Sommerville, 2008, Seite 660
105. ↑ Vgl. Balzert, 2000, Seite 74 ff.
106. ↑ Vgl. Balzert, 2000, Seite 78 ff.
107. ↑ Vgl. Krüger/ Kopp, 2002, Seite 70 ff
108. ↑ Vgl. Krüger/ Kopp, 2002, Seite 72 ff
109. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 249 ff.
110. ↑ Quelle: Stahlknecht / Hasenkamp, 2005, Seite 252
111. ↑ Zangemeister, 1976, Seite 45
112. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 249 ff.
113. ↑ Vgl. Zachau, 2002, Seite 252
114. ↑ Zachau, 2002, Seite 252
115. ↑ Quelle: Weidner, 2006, Seite 63
116. ↑ Vgl. Koop/ Jäckel/ van Offern, 2001, Seite 99 f.
117. ↑ Vgl. Zachau, 2002, Seite 251-258, 267
118. ↑ Vgl. Zachau, 2002, Seite 311
119. ↑ Koop/ Jäckel/ van Offern, 2001, Seite 108
120. ↑ Vgl. Bendisch / Kern, 2006, Seite 31
121. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 295 ff.
122. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 282
123. ↑ Vgl. Görk, 2001, Seite 126 ff.
124. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 295 ff.
125. ↑ Quelle: Wendt/Lanninger, 2008
126. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 288
127. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 288 ff.
128. ↑ Vgl. Mangler, 2006, Seite 84 f.
129. ↑ Vgl. Krüger / Kopp, 2002, Seite 118 f.
130. ↑ Vgl. Mangler, 2006, Seite 86
131. ↑ Mangler, 2006, Seite 86
132. ↑ Stahlknecht / Hasenkamp, 2005, Seite 283
133. ↑ Krüger / Kopp, 2002, Seite 119
134. ↑ Abts / Mülder, 2009, Seite 388
135. ↑ Bendisch / Kern, 2006, Seite 31
136. ↑ Vgl. Stahlknecht / Hasenkamp, 2005, Seite 317
137. ↑ Vgl. Illigen, 1980, Seite 135
138. ↑ Vgl. Litke, 2007, Seite 237 ff.
139. ↑ Vgl. Krüger / Kopp, 2002, Seite 94 ff.
140. ↑ Vgl. Abts / Mülder, 2009, Seite 388 ff.
141. ↑ Quelle: Mangler, 2006, Seite 90
142. ↑ Vgl. Mangler, 2006, Seite 90 f.
143. ↑ Vgl. Mangler, 2006, Seite 91 f.
144. ↑ Vgl. Mangler, 2006, Seite 92
145. ↑ Vgl. Mangler, 2006, Seite 92 f.
146. ↑ Vgl. Abts / Mülder, 2009, Seite 388 ff.
147. ↑ Vgl. Litke, 2007, Seite 237 ff.
148. ↑ Vgl. Burghardt, 2007, Seite 257 ff.
149. ↑ Vgl. Balzert, 2001, Seite 1090 ff.
150. ↑ Vgl. Balzert, 2001, Seite 1090 f.
151. ↑ Vgl. Balzert, 2001, Seite 1091
152. ↑ Vgl. Balzert, 2001, Seite 1091
153. ↑ Vgl. Balzert, 2001, Seite 1091 f.

8 Literatur- und Quellenverzeichnis

Abts/ Mülder (2009)	Abts, Dietmar/Mülder, Wilhelm: Grundkurs Wirtschaftsinformatik: Eine kompakte und praxisorientierte Einführung, 6. Auflage, Vieweg+Teubner, Wiesbaden 2009
Adler (2009)	Adler, Olivia: Praxiswissen WordPress, 1. Auflage, O'Reilly Verlag, Köln 2009
Altmann et al. (2008)	Altmann, Werner/ Fritz, Rene/ Hinderink, Daniel: Typo3 Enterprice Content Management, 2. aktualisierte Auflage, Open Source Press, München 2008
Balzert (2001)	Balzert, Helmut: Lehrbuch der Softwaretechnik, 2. Auflage, Spektrum Verlag, Heidelberg 2001
Beck et al. (2001)	Beck, Kent et al.: Manifesto for Agile Software Development, http://agilemanifesto.org/ (18.06.2010, 12:45)
Bendisch/ Kern (2006)	Bendisch, Roman/ Kern, Uwe: Projekte managen: Basiswissen kompakt, MA Akademie Verlag, Essen 2006
BRD (2004)	V-Modell XT, http://v-modell.iabg.de/index.php?option=com_docman&task=doc_download&gid=23 (20.06.2010, 11:32)
Burghardt (2007)	Burghardt, Manfred: Einführung in Projektmanagement: Definiton,Planung,Kontrolle und Abschluss, Publicis Corporate Publishing, Erlangen 2007
Dumke (2000)	Dumke, Reiner: Software Engineering, Vieweg Verlag, Braunschweig/Wiesbaden 2000
Ehlers (2002)	Ehlers, Lars H.: Content Management Anwendungen, Logos Verlag, Berlin 2002
Friedrich (2006)	Friedrich, Hans Jörg: Content Management mit Plone, Springer Verlag, Berlin 2006
Fischer et al. (2000)	Fischer, Joachim/Herold, Werner/Danglmaier, Wilhelm/Nastansky, Ludwig/Suhl, Leena: Bausteine der Wirtschaftsinformatik, 2. vollständig überarbeitete und erweiterte Auflage, Erich Schmidt Verlag, Berlin 2000
Gantz et al. (2007)	Gantz, John F. et al.: The Expanding Digital Universe: A Forecast of Worldwide Information Growth Through 2010, http://www.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf (21.06.2010, 21:17)
Görk (2001)	Görk, Manfred: Customizing, in: Mertens, Peter: Lexikon der Wirtschaftsinformatik, Springer Verlag, Berlin 2001
Gulbins et al. (2002)	Gulbins, Jürgen/ Seyfried, Markus/ Strack-Zimmermann, Hans: Dokumenten Management, 3. Auflage, Springer Verlag, Berlin 2002
Hoffmann (2007)	Hoffmann, Karsten: Projektmanagement heute, in: Hoffmann, Karsten/ Mörike, Michael: IT-Projektmanagement im Wandel, dpunkt.verlag, Heidelberg 2007
Hoffmann (2007)	Hoffmann, Karsten/ Mörike, Michael: IT-Projektmanagement im Wandel, dpunkt.verlag, Heidelberg 2007
IDC (2010)	IDC Digital Universe Study: Figure 1: The Digital Universe 2009 - 2020, http://www.emc.com/collateral/demos/microsites/idc-digital-universe/iview.htm (21.06.2010, 21:13)
Illigen (1980)	Illigen, Rolf-Peter: Grundlagen der Entwicklung organisatorischer Regelungen in der Versicherungsunternehmung,in: Schriftenreihe des Instituts für Versicherungswissenschaft an der Universität zu Köln, 1980, Heft 37, Seite 135 bis 136
Kollmann (2009)	Kollmann, Tobias : E-Business, Gabler, Wiesbaden 2009
Koop et al. (2001)	Koop, Hans Jochen/ Jäckel, K. Konrad/ van Offern, Anja L. : Erfolgsfaktor Content Management, Verlag Vieweg, Wiesbaden 2001
Korsch (2010)	Korsch, Stefan : Entwickler müssen sich umstellen. Herausforderung Scrum, in: Computerwoche, 2010, Ausgabe 20, Seite 42 bis 45
Kriegisch (2010)	Kriegisch, Alexander : Scrum - auf einer Seite erklärt, http://scrum-master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert (18.06.2010, 12:33)
Krüger/ Kopp (2002)	Krüger, Jörg Dennis/ Kopp, Matthias: Web Content managen: Professioneller Einsatz von Content-Management-Systemen, Markt+Technik Verlag, München 2002
Lehner (2009)	Lehner, Prof. Dr. Franz: Wissemsmanagement, 3., aktualisierte und erweiterte Aufgabe, Carl Hanser Verlag, München 2009
Litke (2007)	Litke, Hans-D.: Projektmanagement: Methoden, Techniken, Verhaltensweisen, 5. erw. Auflage,Carl Hanser Verlag, München 2007
Mangler (2006)	Mangler, Wolf-Dieter: Prozessorganisation und Organisationsgestaltung, Books on Demand GmbH, Norderstedt 2006
Mertens (2001)	Mertens, Peter: Lexikon der Wirtschaftsinformatik, 4. Auflage, Springer Verlag, Berlin 2001
Oestereich (2007)	Oestereich, Bernd: Agiles Projektmanagement, in: Hoffmann, Karsten/ Mörike, Michael: IT-Projektmanagement im Wandel, dpunkt.verlag, Heidelberg 2007
Onasch (2006)	Onasch, Lars: Spezielle Anforderungen an Content Management Systeme für den Mittelstand, http://www.contentmanager.de/magazin/artikel_917_content_management_mittelstand_auswahl.html (16.06.2010, 19:27)
Riggert (2009)	Riggert, Wolfgang: ECM - Enterprise Content Management, Vieweg+Teubner, Wiesbaden 2009
Rothfuss/ Ried (2001)	Rothfuss, Gunther/ Ried, Christian: Content Management mit XML, Springer Verlag, Berlin 2001
Sommerville (2008)	Sommerville, Ian : Software Engineering, 8. aktualisierte Auflage, Addison-Wesley, München 2008
Stahlknecht/ Hasenkamp (2005)	Stahlknecht, Peter/ Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik, 11. Auflage, Springer Verlag, Berlin 2005
Stein (2004)	Stein, Sebastian: Emergenz in der Softwareentwicklung – bereits verwirklicht oder Chance? http://emergenz.hpfsc.de/html/node42.html (13.06.2010, 20:11)
Stojanovic (2001)	Stojanovic, Aleksander: CMS – Open Source vs. Lizenzsoftware, http://www.contentmanager.de/magazin/artikel_863-420_cms_open_source_lizenzsoftware.html (15.06.2010, 14:15)
Storm/ Faecks (2001)	Storm, Bernd / Faecks, Wolf I: Erfolgskontrolle im Content Management, http://www.contentmanager.de/magazin/artikel_104_content_control_i_-_erfolgskontrolle_im_content.html (13.05.2010, 11:54)
Weidner (2006)	Weidner, Claudia: Content Management Systeme im Überblick, http://www.contentmanager.de/download/contentmanager_ebook_opensource_cms.pdf (20.06.2010, 01:54)
Wendt/ Lanninger (2008)	Wendt, Oliver/ Lanninger, Volker: Customizing von Standardsoftware, http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/is-management/Einsatz-von-Standardanwendungssoftware/Customizing-von-Standardsoftware (20.06.2010, 21:54)
Wilhelm (2002)	Wilhelm, Stephan : Content Management Systeme in: Berres, A./Bullinger, H-J. (Hrsg.),E-Business – Handbuch für Einsteiger, 2. vollständig neu bearbeitete Auflage, Springer Verlag, Berlin u. a. 2002
Zangemeister (1976)	Zangemeister, Christof: Nutzwertanalyse in der Systemtechnik , Wittemannsche Buchhandlung, 4. Auflage, München 1976
Zschau (1999)	Zschau, Oliver: Content Management Systeme - Eine kurze Einführung, http://www.contentmanager.de/magazin/artikel_1_content_management_systeme_-_eine_kurze.html (15.06.2010, 11:57)
Zschau et al.(2002)	Zschau, Oliver/ Traub, Dennis/ Zahradka, Rik: Web Content Management, Galileo Press, Bonn 2002
Zschau (2010)	Zschau, Oliver: Produktübersicht - Content Management: Content Management Systeme, http://www.contentmanager.de/itguide/marktuebersicht_produkte_cms.html (21.06.2010, 21:12)