The concept of enterprise portals, and employee portals in particular, offers a promising approach to providing a centralized platform that integrates multiple in-house applications and processes in a user friendly way. The existing literature suggests a number of models of procedure for introducing enterprise portals, but only very few address the issue of improving already established portals in companies.
The company Finanz Informatik already uses a portal for its internal reporting which is based on SAP NetWeaver Portal. The benefits of this product are not being fully exploited given the fact that the internal business system landscape primarily uses other SAP products which could easily be integrated. For this reason, the current portal named “MIS-Portal”
should be extended to become a new employee portal “POINT” for all business SAP applications, which can be used by all employees.
Against this background, this master thesis designs a model of procedure for the continuous development of employee portals, which is derived from the theoretical fields of “continuous improvement processes”, “general procedure models” and “procedure models for introduction of corporate portals”. The design of the procedure model consists of the five phases “strategy”, “analysis”, “design”, “implementation” and “introduction”, which depend on each other and ensure a continuous improvement due two PDCA-cycles.
In order to test the practical applicability of the procedure model for the continuous development of employee portals, the planned activities within the corresponding phases are applied to the context of Finanz Informatik. The transition from “MIS-Portal” to “POINT” is exemplified as one selected iteration to evaluate the quality of the model. In this practical section it is demonstrated that the procedure model can be successfully applied to Finanz Informatik. Whether the model can also be used in other scenarios in generic company contexts cannot be answered definitively. But the experience with previous uses of the model suggests that it has a high degree of applicability for generic scenarios.
For this reason, we can confidently put forward the hypothesis that this design of the procedure model can be used in other contexts, too.
INHALTSVERZEICHNIS
1 Einleitung
1.1 Untersuchungssituation nach FERSTL
1.2 Untersuchungskontext
1.3 Motivation
1.4 Aufbau der Masterarbeit
2 Grundlagen: Unternehmensportale und Vorgehensmodelle
2.1 Portalbegriff
2.1.1 Definition
2.1.2 Klassifikation
2.1.3 Referenzarchitektur
2.2 SAP NetWeaver Portal
2.2.1 Einordnung im SAP NetWeaver Rahmenwerk
2.2.2 Software-Architektur
2.2.3 Content-Elemente
2.3 Kontinuierlicher Verbesserungsprozess
2.3.1 Process Reengineering vs. Process Improvement
2.3.2 PDCA-Zyklus
2.3.3 Kaizen
2.4 Allgemeine Vorgehensmodelle
2.4.1 Ad-hoc Vorgehen
2.4.2 Sequentielle Vorgehensmodelle
2.4.3 Iterativ-Inkrementelle Vorgehensmodelle
2.4.4 Agile Vorgehensmodelle
2.5 Vorgehensmodelle zur Einführung eines Unternehmensportals
2.5.1 Vorgehensmodell nach Fraunhofer PADEM
2.5.2 Vorgehensmodell nach GROßMANN und KOSCHEK
2.5.3 Vorgehensmodell nach AMBERG, HOLZNER und REMUS
2.5.4 Vorgehensmodell nach GURZKI
2.6 Zwischenfazit
3 Vorgehensmodell zur Weiterentwicklung von Mitarbeiterportalen
3.1 Strategie: Bestimmung der Portalziele
3.1.1 Strategic Alignment Model
3.1.2 Portalschwerpunkt-Analyse
3.1.3 Ermittlung einer Portalstrategie
3.1.4 Ableitung konkreter Portalziele
3.2 Analyse: Untersuchung der Ist-Situation
3.3.1 Stärken-Schwächen-Profil
3.2.2 Prozessanalyse
3.2.3 Anwendungssystemanalyse
3.2.4 Prozess-Anwendungssystem-Matrix
3.2.5 Ableitung konkreter Anforderungen
3.3 Konzeption: Gestaltung des Soll-Zustandes
3.3.1 Voraussetzungen zur Portalintegration
3.3.2 Identifikation fachlicher Themenblöcke
3.3.3 Portal System Engineering
3.3.4 Ableitung eines Integrationskonzepts
3.4 Umsetzung: Technische Realisierung
3.3.1 Integration fachlicher Themenblöcke
3.4.2 Anpassung Portalinfrastruktur
3.4.3 Softwaretest
3.4.4 Portalrelease
3.5 Einführung: Etablierung des neuen Portalreleases
3.3.1 Akzeptanzfaktoren
3.5.2 Change Management
3.5.3 Veröffentlichung
3.6 Zwischenfazit
4 Anwendung des Vorgehensmodells in der Finanz Informatik
4.1 Strategie: SAP NetWeaver Portal als Integrationsplattform
4.1.1 Anwendung in der Praxis
4.1.2 Phasenergebnis: Portalziele
4.1.3 Zwischenfazit
4.2 Analyse: Nutzung des MIS-Portals
4.4.1 Anwendung in der Praxis
4.2.2 Phasenergebnis: Anforderungen
4.2.3 Zwischenfazit
4.3 Konzeption: POINT als zentrales Mitarbeiterportal
4.4.1 Anwendung in der Praxis
4.3.2 Phasenergebnis: Integrationskonzept
4.3.3 Zwischenfazit
4.4 Umsetzung: Aufbau einer modernen Portalinfrastruktur
4.4.1 Anwendung in der Praxis
4.4.2 Phasenergebnis: Portalrelease
4.4.3 Zwischenfazit
4.5 Einführung: Roll-Out im Unternehmen
4.4.1 Anwendung in der Praxis
4.5.2 Phasenergebnis: Veröffentlichung
4.5.3 Zwischenfazit
5 Gesamtfazit
Anhang A: Referenzarchitekur für Unternehmensportale
Anhang B: SAP NetWeaver Rahmenwerk
Anhang C: V-Modell nach BOEHM
Anhang D: Vorgehensmodell nach Fraunhofer PADEM
Anhang E: Vorgehensmodell nach GROßMANN und KOSCHEK
Anhang F: Vorgehensmodell nach AMBERG, HOLZNER und REMU
Anhang G: Vorgehensmodell nach GURZKI
Anhang H: Wertkettenmodell nach PORTER
Anhang I: Integrationspyramide nach MERTENS
Anhang J: Anwendungssysteme nach STAHLKNECHT und HASENKAMP
Anhang K: Fachliches Architekturmodell nach GROßMANN und KOSCHEK
Anhang L: Services der Kaufmännischen Systeme
Anhang M: SAP ERP Solution Map
Anhang N: Kaufmännische Systemlandschaft in der Finanz Informatik
Anhang O: Auszug POINT nach Umsetzung
Anhang P: Releaseprozess für die kaufmännischen Systeme
Literaturverzeichnis
ABBILDUNGSVERZEICHNIS
Abbildung l: Untersuchungssituation nach FERSTL
Abbildung 2: Aufbau der Masterarbeit
Abbildung 3: Unternehmensportal nach Anwendungsschwerpunkt
Abbildung 4: Unternehmensportal nach Benutzerrolle
Abbildung 5: Einordnung SAP NetWeaver Portal
Abbildung 6: SAP NetWeaver Portal Architektur
Abbildung 7: Typische Beziehungen von Content-Elementen
Abbildung 8: PDCA-Zyklus nach DEMING
Abbildung 9: Kaizen-Schirm
Abbildung 10: Wasserfallmodell
Abbildung ll: Iterativ-Inkrementeller Prozess
Abbildung 12: Modellierungssichten und Beschreibungsebenen beim Portal-Engineering
Abbildung 13: l. Schritt zur Entwicklung eines Vorgehensmodells
Abbildung 14: 2. Schritt zur Entwicklung eines Vorgehensmodells
Abbildung 15: 3. Schritt zur Entwicklung eines Vorgehensmodells
Abbildung 16: Vorgehensmodell - Strategiephase
Abbildung 17: Zusammenhang Unternehmens- und Portalstrategie
Abbildung 18: Strategic Alignment Model
Abbildung 19: Portalschwerpunkt-Analyse
Abbildung 20: Vorgehensmodell - Analysephase
Abbildung 21: Elemente der User Experience
Abbildung 22: Bestandteile von Usability, Utility und Joy Of Use
Abbildung 23: Betriebliche Anwendungssystemlandschaft
Abbildung 24: Vorgehensmodell - Konzeptionsphase
Abbildung 25: Vorgehensmodell - Umsetzungsphase
Abbildung 26: Fachliche Integrationsschicht
Abbildung 27: Testklassifizierung
Abbildung 28: Vorgehensmodell - Einführungsphase
Abbildung 29: Akzeptanzfaktoren nach REIß
Abbildung 30: Störungsaufkommen beim Change Management
Abbildung 31: Roadmap POINT
Abbildung 32: Stärken-Schwächen-Profil des MIS-Portals
Abbildung 33: Infrastruktur für POINT
Abbildung 34: Farbspektrum der Finanz Informatik nach Corporate Design
Abbildung 35: Hub and Spoke-Architektur für POINT
Abbildung 36: UWL in POINT
Abbildung 37: Netzwerkarchitektur von POINT
Abbildung 38: Zusammenspiel ITIL-Prozesse
TABELLENVERZEICHNIS
Tabelle 1: Aufgaben des Unternehmensbereiches „Kaufmännische Systeme“
Tabelle 2: Process Reengineering vs. Process Improvement
Tabelle 3: Manifest-Aussagen für Agile Vorgehensmodelle
Tabelle 4: Prozess-Anwendungssystem-Matrix
Tabelle 5: Eigenschaften unterschiedlicher zu integrierender Applikationstypen .51 Tabelle 6: Portalreleases
Tabelle 7: Ziel-Komponenten der Portalziele
Tabelle 8: Anwendbarkeit der Strategiephase70
Tabelle 9: Prozess-Anwendungssystem-Matrix für „Kaufmännische Systeme“
Tabelle 10: Anwendbarkeit der Analysephase
Tabelle ll: Fachliche Themenblöcke für POINT
Tabelle 12: Anwendbarkeit der Konzeptionsphase
Tabelle 13: Anwendbarkeit der Umsetzungsphase
Tabelle 14: Anwendbarkeit der Einführungsphase
ABKÜRZUNGSVERZEICHNIS
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Mitarbeiter in Unternehmen sehen sich häufig einer sehr heterogenen Systemlandschaft konfrontiert, die den Zugang zu den relevanten Anwendungen erschwert. Die vielen ver- teilten Unternehmensanwendungen sorgen für Unübersichtlichkeit und kosten den Mitar- beitern meist unnötig viel Zeit, um den Zugang zu der benötigten Anwendung zu koordi- nieren. Die Konzepte von Unternehmensportalen und insbesondere von Mitarbeiterporta- len bieten hierfür einen vielversprechenden Ansatz, da diese eine zentrale Plattform vorse- hen, in der möglichst viele Anwendungen auf benutzerfreundliche Art integriert werden. Zwar setzen viele Unternehmen bereits spezielle Mitarbeiterportale für bestimmte Funkti- onen ein, nutzen jedoch häufig nicht den vollen Funktionsumfang, sodass meist einige Verbesserungspotentiale vorhanden sind. In der Mitarbeiterportalstudie „Employee Portal Benchmark 2009“ wurde so zum Beispiel festgestellt, dass offenbar hinsichtlich der Sys- temqualität primär der moderat bewertete Aspekt „Zugang zu Unternehmensanwendun- gen“ den größten Raum für Verbesserungen bietet (European Business School, 2009, S. 5).
Auch in der Finanz Informatik sieht man sich mit dieser Situation konfrontiert. Zwar ba- siert der Großteil der kaufmännischen Systemlandschaft bereits auf SAP-Systemen, die in sich hochgradig integriert sind. Allerdings gibt es bisher lediglich ein rudimentäres Portal, dass primär als Plattform für das interne Berichtswesen dient. Um eine zentrale und perso- nalisierte Zugriffsmöglichkeit auf möglichst alle kaufmännisch geprägten Anwendungen zur Durchführung von Arbeitsprozessen zugreifen zu können, ist eine Weiterentwicklung des bisherigen Portals erforderlich.
Vor diesem Hintergrund soll die vorliegende Masterarbeit ein Vorgehensmodell zur konti- nuierlichen Weiterentwicklung von Mitarbeiterportalen entwickeln, das anschließend zum Ausbau des bereits eingesetzten SAP NetWeaver Portals in der Finanz Informatik verwen- det wird, um einen zentralen Einstiegspunkt zur integrierten kaufmännischen Systemland- schaft zu etablieren. Im Mittelpunkt steht dabei die Analyse unterschiedlicher theoretischer Vorgehensmodelle und Verbesserungsprozesse, die daraus abgeleitete Konzeption eines geeigneten Vorgehensmodells zur Weiterentwicklung von Mitarbeiterportalen, sowie die entsprechende praktische Anwendung des Modells in der Finanz Informatik.
Um dem Leser genauer in die Thematik einzuführen, sollen in den folgenden Unterkapiteln die Untersuchungssituation nach F ERSTL und der Untersuchungskontext sowie die persön- liche und unternehmerische Motivation erläutert und der Aufbau der Masterarbeit vorge- stellt werden.
1.1 Untersuchungssituation nach FERSTL
Zur genauen Abgrenzung der Problemstellung, sowie zur konkreten Zielbeschreibung der vorliegenden Masterarbeit, soll die Untersuchungssituation nach FERSTL (1979, S. 43-53) als modelltheoretisches Konzept für die Beschreibung von Problemlösungssituationen verwendet werden. Der Begriff Untersuchungssituation und dessen Komponenten sollen zunächst in Abbildung l in Anlehnung an FERSTL (1979, S. 43) skizziert und anschließend sukzessiv erläutert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Untersuchungssituation nach FERSTL
Wie in der Abbildung l zu erkennen ist, setzt sich die Untersuchungssituation aus dem Untersuchungsobjekt, Untersuchungszielen und einem Untersuchungsverfahren zusam- men. Ein Untersuchungsobjekt bildet dabei zusammen mit darauf bezogenen Untersu- chungszielen ein Untersuchungsproblem. Nach Durchführung eines Untersuchungsverfah- rens liegt ein Untersuchungsergebnis vor, das im Idealfall den Untersuchungszielen ent- spricht.
Untersuchungsproblem
Das Untersuchungsproblem setzt sich aus dem Untersuchungsobjekt und den diesbezüglich verfolgten Untersuchungszielen zusammen, wobei zwischen unterschiedlichen Problemar- ten differenziert werden kann. „Untersuchungsprobleme können hinsichtlich ihres Zielin- halts in Input-Output-Analyseprobleme, Output-Input-Analyseprobleme, Entscheidungs- probleme und Konstruktionsprobleme differenziert werden“ (Jacob & Suchan, 2012, S. 118). Das dieser Arbeit zugrundeliegende Untersuchungsproblem kann dabei als Konstruk- tionsproblem klassifiziert werden, da es sich beim Untersuchungsobjekt um ein noch nicht vollständig ausgebautes Anwendungssystem (Unternehmensportal) handelt. Bei Konstruk- tionsproblemen kann das Verhalten des Systems nur als Anforderung für die Untersuchung definiert werden, um eine Systemstruktur zu erhalten, die zu dem gewünschten Verhalten führt (Rüffer, 2012, S. 74).
Untersuchungsobjekt
Das Untersuchungsobjekt stellt den zu untersuchenden Ausschnitt der realen Welt dar (Jahn, 2009, S. 76). In dieser Masterarbeit stellt das auszubauende SAP NetWeaver Portal als zentrales Mitarbeiterportal das Untersuchungsobjekt dar und steht damit in der vorlie- genden Ausarbeitung im Fokus der Untersuchung.
Untersuchungsziele
Untersuchungsziele sind Zustände, Verhaltens- oder Strukturmerkmale des Untersu- chungsobjekts, die bestimmt bzw. erreicht werden sollen (Jahn, 2009, S. 76). Die Ziele sind dabei differenziert zu betrachten und können hinsichtlich Zielinhalt in Sach- und For- malziele untergliedert werden (Jacob & Suchan, 2012, S. 118). Als Sachziel dient in die- sem Zusammenhang der erfolgreiche Ausbau des SAP NetWeaver Portals und dessen Etablierung in der Finanz Informatik. Dieses erstrebenswerte Sachziel wirkt ebenso auf das Untersuchungsobjekt wie Formalziele. So sollten sich durch den Ausbau möglichst alle internen kaufmännischen Anwendungen über das zentrale Portal ohne separate Passwort- eingabe aufrufen lassen. Darüber hinaus sollte die entsprechende Portalinfrastruktur For- malziele hinsichtlich Performance, Flexibilität, Erweiterbarkeit und Wartbarkeit berück- sichtigen sowie Aspekte hinsichtlich Ausfallsicherheit und Usability einbeziehen, damit die Akzeptanz der Anwender gewährleistet ist.
Untersuchungsverfahren
Durch Anwendung eines Untersuchungsverfahrens wird eine Problemlösung der Untersu- chungsziele erzeugt (Ferstl, 1979, S. 43-53). „Als Untersuchungsverfahren für Konstrukti- onsprobleme werden Kreativitätsverfahren eingesetzt“ (Jahn, 2009, S. 76). Das Untersu- chungsproblem bildet dabei den Input und der daraus generierte Output kann als Problem- lösung gesehen werden (Ferstl, 1979, S. 59). Das Vorgehen orientiert sich am erkenntnis- theoretischen Paradigma der designorientierten Forschung (Wilde & Hess, 2007, S. 281). Hierbei wird aufgrund eines Problems „ein Entwurfsprozess durchlaufen, an dessen Ende ein Artefakt generiert und hinsichtlich seiner Nützlichkeit evaluiert wird“ (Jahn, 2009, S. 82). Als konkretes Untersuchungsverfahren zur Erreichung der Untersuchungsziele soll bei dem Ausbau des SAP NetWeaver Portals ein entsprechendes Vorgehensmodell erarbeitet werden, das allgemeingültig auf unterschiedliche Szenarien anwendbar ist und eine itera- tiv-inkrementelle und somit kontinuierliche Weiterentwicklung gewährleistet. Das Vorge- hen kann dabei auf Grundlage unterschiedlicher theoretischer Konzepte abgeleitet werden. Das Ergebnis kann anschließend durch einen Induktionsschluss in der Praxis überprüft werden. „Als induktive Methode wird ein Schlussfolgerungsverfahren bezeichnet, nach welchem von einer endlichen Zahl beobachteter Einzelsachverhalte zu einer Hypothese mit Allgemeingültigkeit fortgeschritten wird“ (Bea, Schweitzer & Dichtl, 2004, S. 72).
1.2 Untersuchungskontext
Zur besseren Einordnung der vorliegenden praxisnahen Masterarbeit soll die Finanz In- formatik als beteiligtes Unternehmen sowie der persönliche Unternehmensbereich der „Kaufmännischen Systeme“ kurz vorgestellt werden. Anschließend soll der bisherige Ein- satz des SAP NetWeaver Portals unter dem Namen MIS-Portal beschrieben, sowie die ge- plante zukünftige Plattform POINT erläutert werden. Durch die Vorstellung dieses Unter- suchungskontextes wird die Ausgangslage im Unternehmen verdeutlicht und POINT als Hauptauslöser für das Thema hervorgehoben.
Unternehmen: Finanz Informatik GmbH & Co. KG
Die Finanz Informatik GmbH & Co. KG1 ist aus dem Zusammenschluss von FinanzIT und Sparkassen Informatik im Jahr 2008 entstanden und stellt seitdem den einzigen IT- Dienstleister der Sparkassen-Finanzgruppe dar. Die Finanz Informatik mit Sitz in Frankfurt am Main hat deutschlandweit 423 Sparkassen, 8 Landesbank... 10 Landesbausparkassen sowie weitere Unternehmen der Sparkassenorganisation und der Finanzdienstleistungs- branche als Kunden. Das ganzheitliche Angebot der Finanz Informatik umfasst das gesam- te IT-Spektrum – von der Entwicklung und Bereitstellung von IT-Anwendungen, Netz- werken und technischer Infrastruktur über den Rechenzentrumsbetrieb bis hin zu Beratung, Schulung und Support. Das Unternehmen beschäftigt knapp 5.OOO Mitarbeiterinnen und Mitarbeiter bei Umsatzerlösen von rund 1,5 Milliarden Euro pro Jahr.
Unternehmensbereich: Kaufmännische Systeme
Innerhalb der Finanz Informatik kümmert sich der Unternehmensbereich „Kaufmännische Systeme“ mit den entsprechenden Organisationseinheiten um die Einführung und Weiter- entwicklung von IT-Systemen zur Unterstützung unternehmensinterner kaufmännischer Prozesse. Die Strategie des Bereiches sieht dabei mittlerweile eine konsequente Ausrich- tung auf SAP-Systeme vor, sodass die Ziel-Informationssystem-Architektur ausschließlich auf Produkte der SAP AG2 setzt. Im Gegensatz zu einer „Best Of Breed“-Strategie bietet dies den Vorteil eines hohen Integrationsgrades, sodass aufwändige Schnittstellen- programmierungen größtenteils entfallen. Aus diesem Grund wurden in der Vergangenheit bereits alte Legacy-Systeme (Alt-Systeme) bzw. Eigenentwicklungen auf Basis von Lotus- Notes wie zum Beispiel für das interne Bestellwesen (IBW) durch SAP SRM oder für das Elektronische Dienstreisemanagement (EDM) durch SAP FI-TV abgelöst und Produkte von anderen Herstellern wie zum Beispiel PlanView durch SAP PM und cProjects ersetzt. Die folgende tabellarische Übersicht listet die entsprechenden Abteilungen des Unterneh- mensbereiches auf und zeigt in stichpunktartiger Form die jeweiligen Hauptaufgaben.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Aufgaben des Unternehmensbereiches „Kaufmännische Systeme“(eigene Darstellung)
Aktuelle Plattform: MIS-Portal
Das SAP NetWeaver Portal ist bereits in der Finanz Informatik im Einsatz und wird durch die Organisationseinheit (OE) 2331 des Bereiches „Kaufmännische Systeme“ betreut. Die Portallösung wird unter dem Begriff „MIS-Portal“ geführt und dient zur Zeit primär als Plattform für das Berichtswesen auf Basis von SAP BW. MIS steht dabei für „Manage- ment Information System“ und verfolgt somit die Idee einer zentralen Plattform zur Bereit- stellung von internen kaufmännischen Berichten für unterschiedliche Zielgruppen der Fi- nanz Informatik. Als weiteres System wurde bereits vor kurzer Zeit die Jahresplanung, die technisch durch SAP SEM-BPS umgesetzt wird, in das MIS-Portal integriert.
Zukünftige Plattform: POINT
POINT steht für „Portal Interne Kaufmännische Systeme“ und soll zukünftig sämtliche Anwendungssysteme des Bereiches integrieren. Ziel ist die Etablierung eines zentralen Einstiegspunktes für den direkten und personalisierten Zugang auf die kaufmännische An- wendungslandschaft. Die Funktionen des bisherigen MIS-Portals sollen dabei bestehen bleiben und durch die Anbindung weiterer Anwendungen ergänzt werden. In diesem Zuge soll der Name des Portals von MIS-Portal auf POINT geändert werden und allen Mitarbei- tern der Finanz Informatik zugänglich gemacht werden. Der entsprechend geplante Ausbau des SAP NetWeaver Portals ist letztlich der Auslöser für die vorliegende Masterarbeit.
1.3 Motivation
Da sowohl persönliche als auch unternehmerische Motivationsgründe zur Bearbeitung des Themas vorliegen, sollen die beiden Sichtweisen entsprechend differenziert werden.
Persönliche Motivation
Die persönliche Motivation zur Konzeption eines Vorgehensmodells zur kontinuierlichen Weiterwicklung von Mitarbeiterportalen ist hauptsächlich dadurch begründet, dass durch den Ausbau des SAP NetWeaver Portals ein neues zentrales Werkzeug im Unternehmen entsteht, dass alle Mitarbeiter betrifft und somit einen hohen Stellenwert einnimmt. Dies ist nicht nur eine große Herausforderung und Verantwortung, sondern auch ein erheblicher Motivationsgrund, um einen kontinuierlichen Verbesserungsprozess zur ständigen Weiter- entwicklung des Portals zu etablieren und so insgesamt einen positiven Beitrag für das Unternehmen zu leisten. Gleichzeitig werden sowohl konzeptionelle Fähigkeiten gefordert, als auch technisches Know-How benötigt, das bisher im Unternehmensbereich in dieser speziellen Form noch nicht vorhanden ist. So bietet die intensive Einarbeitung in die Tech- niken des SAP NetWeaver Portals große persönliche Perspektiven in der Finanz Informa- tik. Darüber hinaus kann bei der Integration der unterschiedlichen Anwendungen der Wis- senshorizont deutlich erweitert werden, da man sich in verschiedene bisher teils unbekann- te SAP-Systeme einarbeiten muss, um beurteilen zu können, ob und in welcher Form eine Portalintegration möglich bzw. sinnvoll ist.
Unternehmerische Motivation
Die Schaffung einer zentralen Plattform für den Zugriff auf die interne kaufmännische Sys- temlandschaft wurde aus Zeitgründen immer wieder verschoben und ist mittlerweile längst überfällig. Durch die Fusion zur Finanz Informatik sowie diversen anderen Projekten zur Ablösung von Legacy-Systemen fehlten die entsprechenden Kapazitäten im Unterneh- mensbereich, um das Thema voran treiben zu können. Der Ausbau des SAP NetWeaver Portals stellt dabei ein großes Vorhaben dar, das ohne organisatorischen Projektrahmen in mehreren Iterationen durchgeführt werden soll. Durch die kontinuierliche Weiterentwick- lung des SAP NetWeaver Portals soll insgesamt die Produktivität bei den Mitarbeitern ge- steigert werden, da der Zugang zu den komplexen kaufmännischen Systemen erleichtert wird. Durch die ausführliche Bearbeitung des Themas im Rahmen einer Masterarbeit ist dabei gewährleistet, dass ein methodisches und strukturiertes Vorgehen angewendet wird. Darüber hinaus können Randgebiete aus der Theorie, die wahrscheinlich aus Zeitgründen ohne Bezug zu einer wissenschaftlichen Arbeit nicht betrachtet worden wären, stärker in die praktische Arbeit einfließen.
1.4 Aufbau der Masterarbeit
Um den Leser mit möglichst allen relevanten Bereichen des Themengebietes vertraut zu machen, soll in Kapitel 2 zunächst eine Einführung in Integrierte Unternehmensportale und Vorgehensmodellen erfolgen. Hier stehen der Portalbegriff, das SAP NetWeaver Por- tal sowie theoretische Erkenntnisse in den Bereichen kontinuierlicher Verbesserungspro- zesse, allgemeiner Vorgehensmodelle und Vorgehensmodelle zur Einführung von Unter- nehmensportalen im Fokus.
Dieses Grundlagenkapitel bildet das Fundament für die Ableitung eines konkreten Vorge- hensmodells zur Weiterentwicklung von Mitarbeiterportalen, das in Kapitel 3 im Mittel- punkt steht. Hier wird ein Vorgehensmodell zunächst auf Metaebene erarbeitet und an- schließend die jeweiligen Phasen konkretisiert.
Nachdem das Vorgehensmodell aus theoretischer Sicht konzipiert wurde, erfolgt in Kapi- tel 4 die Anwendung des Vorgehensmodells in der Finanz Informatik. Durch die Darstel- lung der konkreten Anwendung in der Praxis und anschließender Reflektion der einzelnen Phasen, werden die wesentlichen Erkenntnisse in einer einheitlichen Form formuliert.
Darauf aufbauend werden in Kapitel 5 im Rahmen eines Gesamtfazits die ursprünglich aufgestellten Untersuchungsziele bewertet und ein Ausblick auf das weitere Vorgehen ge- liefert.
Die folgende grafische Aufbereitung in Abbildung 2 fasst das Vorgehen der Masterarbeit zusammen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Aufbau der Masterarbeit (eigene Darstellung)
2 Grundlagen: Unternehmensportale und Vorgehensmodelle
In diesem Kapitel sollen zunächst die Grundlagen für das Verständnis von Unternehmens- portalen und Vorgehensmodellen gelegt werden. Hierfür steht im ersten Schritt der Portal- begriff im Fokus der Betrachtung. Da in dieser Ausarbeitung die Lösung der SAP AG im Mittelpunkt steht, soll im Anschluss das SAP NetWeaver Portal als konkretes Produkt vor- gestellt werden. Im nächsten Schritt werden der Kontinuierliche Verbesserungsprozess, Allgemeine Vorgehensmodelle und konkretere Vorgehensmodelle zur Einführung eines Unternehmensportals analysiert, um eine fundierte Basis zur Ableitung eines praktischen Modells zu erarbeiten, das für die weitere methodische Vorgehensweise eine Referenz- struktur darstellen soll. Ein abschließendes Zwischenfazit fasst die wesentlichen Erkennt- nisse zusammen.
2.1 Portalbegriff
Zur Erläuterung des Portalbegriffs werden zunächst unterschiedliche Möglichkeiten zur Definition diskutiert und somit eine angemessene Ausgangssituation geschaffen. Anschlie- ßend werden verbreitete Möglichkeiten zur Klassifikation erläutert und insbesondere die Rolle von Mitarbeiterportalen herausgestellt. Damit eine ganzheitliche Sicht für den Por- talbegriff gewährleistet ist, wird zuletzt eine anerkannte Referenzarchitektur für Unter- nehmensportale thematisiert.
2.1.1 Definition
Der Begriff „Portal“ leitet sich aus dem lateinischen Wort „porta“3 ab und impliziert so bereits die Bedeutung eines Zugangspunktes. In der Informatik bezeichnet ein Portal all- gemein ein Anwendungssystem, das sich durch Integration von Anwendungen, Prozessen und Diensten auszeichnet (Guba, 2007, S. 19).
Nach GROßMANN und KOSCHEK (2005, S. 32) ist ein Unternehmensportal bzw. Enterprise Portal „ein geschlossenes Portal, das den Anwendern einen individuellen, personalisierten Zugang zu allen relevanten Inhalten bietet, um alle Aufgaben bequem und schnell erledi- gen zu können.“
ZWERGER und SCHNEIDER (2002, S. 22) beschreiben ein Unternehmensportal als „zentraler Zugangspunkt für die Zielgruppe zu relevanten Informationen, Applikationen und Ge- schäftsprozessen in einer stark personalisierten Weise.“
Das Merkmal des personalisierten Zugangs auf Applikationen stellt gleichzeitig die Haupt- abgrenzung zu traditionellen Intranet-Plattformen dar, die in der Regel primär als eine Me- thode der unternehmensinternen Informationsverbreitung verwendet werden. „Portale sind eine direkte Weiterentwicklung der bestehenden Ansätze für Internet- bzw. Intranettechno- logien“ (Kirchhof, Gurzki, Hinderer & Vlachakis, 2004).
RIEMKE-GURZKI (2012) zählt zusätzlich zu diesen zentralen Eigenschaften eines Unter- nehmensportals folgende optionale Charakteristika auf, die auch im Rahmen der vorlie- genden Masterarbeit als Basis für den Portalbegriff dienen sollen:
- Verknüpfung und Datenaustausch innerhalb verschiedener Anwendungen über eine Plattform
- zentraler Zugriff auf unternehmensinterne Applikationen mit Single Sign On (SSO)
- Möglichkeit, die Prozesse und Zusammenarbeit innerhalb heterogener Gruppen zu un- terstützen
2.1.2 Klassifikation
Die Begriffsdefinition lässt grundsätzlich eine Vielzahl an unterschiedlichen Typen von Unternehmensportalen zu. Im Kontext der vorliegenden Ausarbeitung sind allerdings nicht alle Klassen von Portalen von Bedeutung, sodass im folgenden zwei in der Literatur häufig anzutreffenden Kategorisierungsmöglichkeiten vorgestellt und die hier relevanten Klassen bestimmt werden sollen.
Unternehmensportale können zunächst nach dem Kriterium des „Anwendungssschwer- punktes“ klassifiziert werden. Die Abbildung 3 skizziert diese Kategorisierung in Anleh- nung an GROßMANN und KOSCHEK (2005, S. 34).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Unternehmensportal nach Anwendungsschwerpunkt
Operational Portals bzw. Enterprise Application Portals sind primär auf die Unterstützung und Integration ausgewählter Unternehmensanwendungen ausgerichtet und sind im Rah- men dieser Arbeit von besonderer Bedeutung. Der zentrale und einheitliche Zugang wird in der Regel unterstützt durch Single Sign On-Technologien, sodass alle angebundenen Systeme für den Anwender ohne weitere Authentifizierung zugreifbar sind und keine Sys- temgrenzen mehr erkennbar sind.
Eine weitere Klassifikationsmöglichkeit, die ebenfalls eine Unterteilung in vier Kategorien vorsieht, stellt das Kriterium „Benutzerrolle“ dar und ist in Anlehnung an BAUER (2001, S. 36) in Abbildung 4 visualisiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Unternehmensportal nach Benutzerrolle
Als Synonym für Business-to-Employee-Portal gilt auch der Begriff Mitarbeiterportal. Diese Klasse steht im Mittelpunkt der weiteren Betrachtung, sodass die anderen Katego- rien mit ihren jeweiligen funktionalen Anforderungen nicht berücksichtigt werden müssen.
2.1.3 Referenzarchitektur
Die theoretischen Konzepte hinsichtlich der Architektur eines Unternehmensportals stim- men in der Literatur weitestgehend überein. Eine anerkannte Referenzarchitektur für Por- talsoftware nach GURZKI und HINDERER (2003, S. 2) ist im Anhang A beigefügt. Diese folgt der Client/Server-Architektur in Form von drei Schichten nach Präsentation, Anwen- dungslogik und Backend, wobei der Client-seitige Teil der Präsentationsschicht die Endge- räte der Portal-Anwender umfasst. Je nach Technologie und Schwerpunktsetzung des Her- stellers können die einzelnen Bestandteile der Anwendungslogik unterschiedlich stark aus- geprägt sein. Gemeinsam ist jedoch bei jedem Produkt ein Server, der die Anfragen der Anwender entgegennimmt und an die eigentliche Engine des Portals innerhalb der Anwen- dungslogik weiterleitet. „Die Portalsoftware ist bei vielen Herstellern auf einen Applicati- on Server angewiesen bzw. Bestandteil einer Plattformlösung, die einen Application Server umfasst“ (Kirchhof, Gurzki, Hinderer & Vlachakis, 2004, S. 8) und zu dem auch die Integ- rations- und Transaktionsdienste gehören. Die unterschiedlichen Portal-Basisdienste, die in der Referenzarchitektur dargestellt sind, decken die wichtigsten Portalfunktionen nach BAUER (20Ol, S. 38) ab. Für die visuelle Darstellung der Portalanwendungen werden so- genannte Portlets verwendet, dessen Konzept dem der Servlets entnommen ist und die we- sentlichen Strukturelemente eines Portals sind. Die einzelnen Portalanwendungen bzw. Portlets laufen unabhängig voneinander auf dem Portal-Server und werden Client-seitig einem virtuellen Fenster zugewiesen, das die Kommunikation mit dem Nutzer ermöglicht (Ferstl & Frank, 201O, S. 188). Die Portlets sind dabei nicht darauf beschränkt, sich aus einer Datenquelle zu bedienen, sondern können ihren Inhalt auch aus mehreren Datenquel- len zusammenstellen. Die Spezifikation von Portlets ist in der Portlet Specification (Java Specification Request) 1684 standardisiert. „Als dritter Bestandteil ist die Backend-Schicht der Ort, der die von Portalanwendungen verwendeten betrieblichen Informationssysteme enthält“ (Vlachakis, Kirchhof & Gurzki, 2005, S. 16).
2.2 SAP NetWeaver Portal
Nachdem nun eine Einführung des Portalbegriffs erfolgt ist, soll in diesem Abschnitt das SAP NetWeaver Portal als konkretes Produkt beschrieben werden. Die Lösung ist für den Zugriff auf die kaufmännische Systemlandschaft als zentrales Mitarbeiterportal vorgese- hen, sodass unterschiedliche Aspekte gewürdigt werden sollten. Zunächst soll die Portallö- sung als Einleitung in das Rahmenwerk SAP NetWeaver eingeordnet werden. Anschließend sollen die Software-Architektur mit den wichtigsten Funktionen und wesentliche Content- Elemente des SAP NetWeaver Portals erläutert werden.
2.2.1 Einordnung im SAP NetWeaver Rahmenwerk
Da das SAP NetWeaver Portal ein zentraler Baustein der SAP NetWeaver-Architektur ist, bietet es sich an, eine entsprechende Einordnung in das Rahmenwerk vorzunehmen. „SAP NetWeaver is the technological platform for all SAP business applications” (saptraininghouse, 2010) und stellt die Integrations- und Anwendungsplattform der SAP dar. „SAP NetWeaver integriert und verbindet Menschen, Informationen und Geschäfts- prozesse über Technologien und Unternehmen hinweg“ (SAP AG, 2007, S. 14). Die ent- sprechende Abbildung in Anhang B veranschaulicht die Integrations- und Anwen- dungsplattform und dessen Komponentensicht.
Application Platform
Die Applikationsplattform stellt die Basis von SAP-Produkten dar und besteht primär aus den beiden Polen Application Server ABAP (AS ABAP) und Application Server Java (AS Java), die jeweils grundlegende technische Funktionen für andere Komponenten von SAP NetWeaver bereitstellen.
Process Integration
Die Prozessintegration beinhaltet Werkzeuge wie SAP Exchange Infrastructure (SAP XI), die eine wichtige Rolle bei der Verbindung von SAP-Systemen und Non-SAP-Systemen spielt, sodass Geschäftsprozesse über Systemgrenzen hinweg in einer Landschaft funktio- nieren können.
Information Integration
Die Ebene der Integrationsschicht liefert einen einheitlichen Zugriff zu strukturierten und unstrukturierten Wissen und gewährleistet so Zugang auf verteiltes Wissen in einem Un- ternehmen. Die wesentlichen Schlüsselbereiche sind dabei Business Intelligence bzw. das SAP BW als Data-Warehouse-Lösung der SAP, das Master Data Management zur Verwal- tung von Stammdaten und das Knowledge Management.
People Integration
Die letzte Integrationsschicht kann als Schnittstelle zum Benutzer verstanden werden, die den Mitarbeitern eines Unternehmens Zugang zu Informationen und Funktionen bietet.
„Die Funktionen des SAP NetWeaver Portals haben in diesem Zusammenhang die ent- scheidendste Bedeutung“ (SAP AG, 2007, S. 18). Außerdem ist hier der Bereich Collabo- ration angesiedelt, zu dem alle Funktionen zusammengefasst werden, die zur synchronen oder asynchronen Kommunikation zwischen Teammitgliedern im Rahmen eines Projektes oder anderer Aufgaben beitragen können (Nicolescu, Klappert & Krcmar, 2012, S. 22).
Parallel zu diesen vier Schichten unterstützt das Life Cycle Management den gesamten Softwarelebenszyklus. „Das SAP Composite Application Framework umfasst Entwick- lungstools, Methoden, Services und Prozesse [...]“ (SAP AG, 2012), die es ermöglichen neue Anwendungen zu erstellen.
Das SAP NetWeaver Portal beinhaltet in Summe Komponenten der Bereiche People Integ- ration und Information Integration und besteht letztlich aus drei Bausteinen des SAP Net- Weaver Rahmenwerks (Portal, Collaboration und Knowledge Management), die in der Abbildung 5 in Anlehnung an SPALL (2003) als zusammenfassende Darstellung visualisiert sind. Technisch läuft das SAP NetWeaver Portal dabei auf dem NetWeaver Application Server Java.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Einordnung SAP NetWeaver Portal
2.2.2 Software-Architektur
Wie bereits ausgeführt, umfasst das SAP NetWeaver Portal drei große Bausteine: die Por- talplattform, das Knowledge Management und Collaboration. Die einzelnen Funktionen werden dabei durch eine enge Integration von mehreren Portal-Komponenten zur Verfü- gung gestellt - die folgende Abbildung 6 liefert in Anlehnung an SAP (2007, S. 75) einen Überblick mit den wichtigsten Komponenten. Aufbau und Inhalt des SAP NetWeaver Por- tals entsprechen dabei weitestgehend der bereits in Kapitel 2.l.3 vorgestellten Referenzar- chitektur von Unternehmensportalen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: SAP NetWeaver Portal Architektur
Um den Gesamtumfang des SAP NetWeaver Portals verstehen zu können, sollen nun die für das weitere Verständnis relevanten Komponenten einzeln vorgestellt werden.
Collaboration
Allgemein versteht man unter Kollaboration bzw. Collaboration eine Menge von Beteilig- ten und Beziehungen zwischen ihnen, die zum Erreichen eines bestimmten Ziels zusam- menwirken, wobei innerhalb einer Kollaboration Interaktionen stattfinden (Kahlbrandt, 20Ol, S. 185). Die Komponente Collaboration ist integrativer Bestandteil des SAP Net- Weaver Portals und unterstützt Teams bei der virtuellen Zusammenarbeit. Hierzu stehen unterschiedliche Dienste und Werkzeuge wie zum Beispiel virtuelle Räume, Application Sharing, Instant Messaging, Foren und Groupware-Integration zur Verfügung, um sowohl bei der synchronen als auch bei der asynchronen Kommunikation zu unterstützen.
Knowledge Management
Knowledge Management5 (KM) beinhaltet Werkzeuge zum Veröffentlichen, Verteilen und Auffinden von unstrukturierten Informationen (SAP AG, 2007, S. 231). KM lässt sich in die beiden Unterkomponenten „Content Management“ und „Search & Classification“ ein- teilen. Neben grundlegenden Funktionen wie das Anlegen und Ändern von Dokumenten bietet der Bereich Content Management weitergehende Dienste wie zum Beispiel Versio- nierungen zur transparenten Änderungsverfolgung oder Subskriptionen zur automatischen Information bei Änderungen an einem Dokument. Search & Classification bzw. dessen Verknüpfung mit der SAP-Suchmaschine TREX bietet, wie der Name bereits ausdrückt, Suchfunktionen und Möglichkeiten zur Klassifikation von Dokumenten.
User Management
User Management6 ist ein zentraler Portaldienst, in der sämtliche Benutzer, Rollen und Gruppen eines Portal-Systems verwaltet werden können. Die Benutzerverwaltung ist, wie die Abbildung 6 andeutet, eng verknüpft mit der User Management Engine (UME) ver- knüpft. „The UME supports a variety of data sources where user can be stored“ (SAP AG, 2009, S. 4). Für die persistente Datenhaltung der Benutzerinformationen können dabei Sys- temdatenbanken, Verzeichnisdienste (LDAP-Server) oder ABAP-basierte SAP-Systeme genutzt werden.
Universal Worklist
Die Universal Worklist7 (UWL) ist ein Bestandteil des SAP NetWeaver Portals und er- möglicht es, Aufgaben aus verschiedenen Workflow-Systemen zusammenzuführen, wobei sowohl unterschiedliche SAP-Systeme als auch Non-SAP-Systeme über entsprechende Schnittstellen angebunden werden können. “The UWL is a portal-based technology that brings all of a user’s work items from a number of systems into a central point of access” (Hague, 2008, S. 7). Für die Portalbenutzer steht so ein zentraler Einstiegspunkt für die Abwicklung von Aufgaben zur Verfügung. „Dazu sammelt die UWL Aufgaben und Mel- dungen der Business Workflows, des SAP Business Workplace, der Collaboration- Aufgaben, des Alert-Frameworks und der Knowledge-Management-Benachrichtigungen und zeigt sie übersichtlich an“ (Nicolescu, Klappert & Krcmar, 2012, S. 214).
Portal Content Directory
Das sogenannte Portal Content Directory (PCD) stellt ein Verwaltungswerkzeug dar, um Content-Objekte zu definieren und zu strukturieren. Dabei ist das PCD mit der entspre- chenden Datenbank des Portal-Systems verbunden, sodass die Content-Elemente in einer zentralen Datenbank persistent gehalten werden können. Welche Content-Elemente im Portal-Content Directory definiert werden können, soll im folgenden Kapitel 2.2.3 auf- grund der Wichtigkeit ausführlicher beschrieben werden.
2.2.3 Content-Elemente
Im folgenden sollen die vier wichtigsten Content-Elemente beschrieben und deren Bezie- hungen zueinander erläutert werden.
iView
„Ähnlich wie Portlets stellen iViews eine Schnittstellendefinition zur Einbindung von Ap- plikationen als Fenster im Portal dar“ (Horn, 2007). Ein iView ist insofern die kleinste lo- gische Objektart, die im PCD definiert werden kann und bezieht sich jeweils auf genau eine Systemquelle. Es gibt eine Vielzahl unterschiedlicher iView-Typen, wobei die wich- tigsten Arten in der folgenden Auflistung aufgeführt werden:
- Uniform Resource Locator (URL)-iView
- Business Server Pages (BSP)-iView
- Business Explorer (BEx) Web Application-iView
- SAP Transaktions-iView
- Web Dynpro Java-iView
- Web Dynpro ABAP-iView
Seite
Eine Seite besteht aus Layout und zugeordneten Content (SAP AG, 2007, S. 86). In der Regel können so unterschiedliche iView-Definitionen auf einer Seite eingebunden werden und ein entsprechendes Layout zur Anordnung definiert werden.
Workset
„A workset comprises all the tasks, services, and information for a specific activity area [...] “ (Hirao, 2008, S. 363). Dieses logische Strukturierungselement sammelt unterschied- liche Content-Inhalte und stellt diese in einer zu definierenden Navigationsstruktur dar. In einem Workset lassen sich dabei sowohl iViews als auch Seiten einbinden.
Rolle
Eine Rolle beinhaltet eine Sammlung von Worksets, Seiten oder iViews, die einem Benut- zer oder einer Gruppe von Benutzern zur Verfügung stehen sollen. Letztlich stellt eine Rol- le somit das Bindeglied zwischen Content-Inhalten und den Portalbenutzern dar.
In dem folgenden Schaubild in Abbildung 7 (SAP AG, 2007, S. 87) werden typische Zu- ordnungen zwischen den vorgestellten PCD-Objekten visualisiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Typische Beziehungen von Content-Elementen
Ergänzend zu den eigentlichen Content-Elementen sollte erwähnt werden, dass die einzel- nen Portalbenutzer, die in der Benutzerverwaltung administriert werden, zwar eine direkte Zuordnung zu einer Portalrolle besitzen können. Empfehlenswerter ist jedoch, dass Portal- rollen in Gruppen zusammengefasst werden, die wiederum den einzelnen Benutzern zuge- wiesen werden können, da hierbei eine größere Flexibilität gewährleistet ist.
2.3 Kontinuierlicher Verbesserungsprozess
Eines der zentralen Ziele der Masterarbeit ist es, einen Prozess zur methodischen und kon- tinuierlichen Weiterentwicklung von Portalen zu erarbeiten. Hinsichtlich stetiger Weiter- entwicklung existieren unterschiedliche Philosophien und Konzepte, die unter dem Begriff
„Kontinuierlicher Verbesserungsprozess (KVP)“ zusammengefasst werden können. Der Begriff wurde Ende der 80er-Jahre geprägt (Kostka & Kostka, 2008, S. 5) und stellt die Grundidee der stetigen kleinen Verbesserungsschritte in den Vordergrund, die dauerhaft eine große Veränderung hervorbringen und so eine nachhaltige Wirkung haben (Kostka & Kostka, 2008, S. 13). Dieser Grundsatz wird in unterschiedlichen theoretischen Konzepten aufgegriffen, die in Europa als „Continuous Improvement Process (CIP)“ bekannt sind (Allweyer, 2005, S. 41O-411). Im Folgenden soll eine Gegenüberstellung Process Reengi- neering vs. Process Improvement erfolgen sowie die verbreiteten Konzepte PDCA-Zyklus und Kaizen vorgestellt werden. Auch wenn sich die Philosophien primär auf Unterneh- mensleitbilder bezüglich Organisation und Qualitätsmanagement8 beziehen, sind die Er- kenntnisse der Modelltheorien letztlich Grundlage zur Ableitung des Vorgehensmodells zur Weiterentwicklung von Unternehmensportalen bzw. Mitarbeiterportalen.
2.3.1 Process Reengineering vs. Process Improvement
Zur Optimierung von Geschäftsprozessen gibt es zwei grundsätzlich unterschiedliche An- sätze: das Business Process Reengineering und das Business Process Improvement. Beides sind Ansätze zur Restrukturierung der Geschäftsprozesse eines Unternehmen, die sich hin- sichtlich Ausführung und Umfang unterscheiden (Hammer & Champy, 1995, S. 12). SCHMELZER und SESSELMANN (2006, S. 337) führen in diesem Zusammenhang die Begrif- fe Revolution und Evolution ein:
- Revolution steht für Prozesserneuerung, die im Business Process Reengineering (BPR) Anwendung findet
- Evolution steht für Prozessverbesserung, die im Business Process Improvement (BPI) Anwendung findet
Beide Ansätze können nicht nur auf Geschäftsprozesse bezogen werden, sondern auch auf allgemeine Weiterentwicklungsmöglichkeiten, zum Beispiel für Portale.
Die Erfinder des Process Reengineerings charakterisieren ihren Ansatz selbst als „funda- mental, radikal, dramatisch“ (Freund, 2004). HAMMER und CHAMPY (1995, S. Vorwort), die diesen Begriff prägten, bezeichnen es als „ein völlig neuartiges Leitbild für die Organi- sation und Führung von Unternehmen“.
Im Gegensatz dazu stellt das Process Improvement eine vorsichtigere Variante dar, die auf inkrementelle Veränderungen abzielt und in kleinen, überschaubaren und weniger riskan- ten Schritten realisiert werden (Gadatsch, 2003, S. 19). Die Verbesserung der Prozesse findet im laufenden Betrieb statt und hat kleine Veränderungen zur Folge (Schmelzer & Sesselmann, 2006, S. 337).
Während das Process Reengineering die Erneuerung der Prozesse, „losgelöst von der aktu- ellen Ist-Situation“ (Schmelzer & Sesselmann, 2006, S. 343) als einmaliges Projekt inner- halb einer begrenzten Zeitspanne durchführt, versucht das Process Improvement die Pro- zesse kontinuierlich zu verbessern.
Die wesentlichen Unterschiede der beiden Konzepte sollen in Anlehnung an SCHMELZER und SESSELMANN (2006, S. 338) in der folgenden Tabelle 2 gegenübergestellt werden.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Process Reengineering vs. Process Improvement
Für die Entwicklung eines Vorgehensmodells zur kontinuierlichen Weiterentwicklung ei- nes Unternehmensportals ist insbesondere die Ideologie des Process Improvements von Bedeutung, da hierbei von einer permanenten Aufgabe ausgegangen wird, die auf Grund- lage eines bestehenden Systems inkrementelle Verbesserungen vorsieht. Für die weitere Betrachtung wird daher der Fokus auf diese evolutionäre Form der Weiterentwicklung gerichtet.
2.3.2 PDCA-Zyklus
Der PDCA-Zyklus nach DEMING (1986, S. 88), der auch als Deming-Kreis oder Problem- lösungskreislauf bezeichnet wird, ist ein zentrales Element vom Kontinuierlichen Verbes- serungsprozess (Imai, 1992, S. 32). Der Zyklus „kann als Methode für alle Verbesserungen [...] verwendet werden“ (Weigert, 2004, S. 70), sodass die Methodik generisch für unter- schiedliche Weiterentwicklungsprozesse verwendet werden kann. Immer wiederkehrende Phasen spiegeln das Prinzip der ständigen Verbesserung wider und bilden eine methodi- sche Anleitung. Im Einzelnen setzt sich der Zyklus aus folgenden vier Phasen zusammen:
- Planen (Plan)
In dieser Phase wird die gegenwärtige Situation (Ist-Situation) geprüft und daraus notwen- dige Aktivitäten abgeleitet und geplant.
- Ausführen (Do)
In dieser Phase werden die zuvor geplanten Aktivitäten durchgeführt.
- Prüfen (Check)
In dieser Phase werden die Ergebnisse der zuvor durchgeführten Aktivitäten bezüglich ihrer Auswirkungen geprüft.
- Handeln (Act)
In dieser Phase werden Rückschlüsse aus den Erkenntnissen der zuvor abgeschlossenen Prüfung gezogen und entsprechende Maßnahmen eingeleitet, um die Pläne zu korrigieren. Durch die Visualisierung des PDCA-Zyklus in der folgenden Abbildung 8 (Deming, 1986,
S. 88) in Form eines geschlossenen und wiederkehrenden Kreislaufes wird insbesondere die Philosophie des Kontinuierlichen Verbesserungsprozesse veranschaulicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: PDCA-Zyklus nach DEMING
Nach WEIGERT (2004, S. 70) ist das wiederholte Durchlaufen des PDCA-Zyklus wichtig, „da bei jeder Wiederholung das bestehende Problem und die Schwachstellen immer mehr eingegrenzt und gemachte Erfahrungen aus vorherigen Zyklen berücksichtigt werden kön- nen“.
Ausgehend von der zyklischen Vorgehensweise des Deming-Kreises kann auch ein stetiger Verbesserungsprozess zur Weiterentwicklung eines bereits eingesetzten Portals erfolgen. Der Grundgedanke eines sich wiederholenden Kreislaufen sollte demnach auch in das zu entwickelnde Vorgehensmodell übertragen werden.
2.3.3 Kaizen
Wenn es um kontinuierliche Verbesserungsprozesse geht, sollte Kaizen zur Abrundung der Thematik nicht fehlen. Das japanische Wort „Kaizen“ besteht aus den zwei Bestandteilen
„Kai“9 und „Zen“lO. Zusammengesetzt bedeutet der Begriff also in etwa „Verändern zum Besseren“ und zählt in Japan nicht nur zu den gebräuchlichsten Wörtern, sondern ist auch Bestandteil des täglichen Lebens (Imai, 20Ol, S. 17). BRUNNER (2008, S. ll) fasst den Begriff folgendermaßen zusammen: „Im Prinzip ist Kaizen eine permanente Reise in PDCA-Zyklen.“ Häufig werden die Begriffe KVP und Kaizen als Synonym gesehen - KÜHNE (2012) stellt aber einen wesentlichen Unterschied fest:
„KVP ist der Prozess und Kaizen das Werkzeug.“
Kaizen als Werkzeug beinhaltet eine Reihe von bekannten Methoden und Techniken, die in Abbildung 9 (Imai, 1992, S. 25) in Form des sogenannten Kaizen-Schirms zusammen- fassend dargestellt sind.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9: Kaizen-Schirm
Auf eine detaillierte Erläuterung der einzelnen Methoden zur Qualitätsverbesserung soll an dieser Stelle verzichtet werden. Wichtig ist, dass die Philosophie von Kaizen einem konti- nuierlichen Prozess, also einer evolutionären Vorgehensweise in kleinen Schritten ent- spricht, die ständig erfolgt und nie als abgeschlossen betrachtet wird (Kamiske & Brauer, 2011, S. 89). Diese Eigenschaft ist die zentrale Erkenntnis, die auch bei der Erstellung des Vorgehensmodells zur ständigen Weiterentwicklung bzw. Verbesserung eines Portals ein- bezogen werden muss.
2.4 Allgemeine Vorgehensmodelle
Vorgehensmodelle finden insbesondere in der Informatik bei der Entwicklung von Soft- waresystemen Anwendung und werden daher häufig in der Spezialdisziplin des Software Engineerings betrachtet. Sie dienen dabei als Prozessmodelle, die das Vorgehen bei der Entwicklung von betrieblichen Anwendungen auf Basis von Beschreibungen und Anlei- tungen abbilden (Krause, 2003, S. 540). Es wird grundsätzlich, je nach Abstraktionsebene und Detaillierungsgrad, zwischen „Allgemeinen Vorgehensmodellen“ und „Konkreten Vorgehensmodellen“ unterschieden (Lohmann, 2005, S. 3). Allgemeine Modelle bilden somit Gruppen, denen sich konkrete Modelle zuordnen lassen.
Im Rahmen der vorliegenden Masterarbeit ist jedoch nur die Klasse der Allgemeinen Vor- gehensmodelle von Relevanz, da die entsprechenden unterschiedlichen Formen, die in die- sem Abschnitt vorgestellt werden sollen, Grundlage für die Konzeption des Vorgehensmo- dells in Kapitel 3 sind. Auf „Konkrete Prozessmodelle“, zu denen beispielsweise der Uni- fied Process oder das Extreme Programming gehören, wird daher an dieser Stelle nicht weiter eingegangen, sondern lediglich zur Vollständigkeit erwähnt.
2.4.1 Ad-hoc Vorgehen
Bei einem Ad-hoc Vorgehen handelt es sich nicht um einen richtigen Prozess, da die Ab- folge der Schritte ungezielt und ohne vorherige Planung erfolgt. Ein typisches Kennzei- chen bei diesem Vorgehen ist zudem, dass die Anforderungen im Vorfeld nur vage geklärt sind, sodass letztlich mehr oder weniger spontan entwickelt, getestet und anschließend korrigiert wird (Lohmann, 2005, S. 6).
Im Vergleich zu strukturierteren Vorgehensweisen gibt es hier bei großen Softwaresyste- men kaum Möglichkeiten zur Beherrschung der Komplexität, da die Softwarestruktur eher zufällig beim Entwickeln entsteht. Darüber hinaus sind die Möglichkeiten zur Weiterent- wicklung und Wartung sehr begrenzt. Trotz dieser Schwächen „verlassen sich viele Orga- nisationen auf Ad-hoc-Prozesse und benutzen bei der Entwicklung ihrer Software keinerlei Methoden aus dem Bereich des Software Engineering“ (Sommerville, 20Ol, S. 55).
Nach LOHMANN (2005, S. 14) ist ein Ad-hoc Vorgehen lediglich für die Entwicklung von Software mit geringem Umfang geeignet, die nur eine kurze Lebensdauer hat und in einem sehr kleinen Team von maximal zwei Personen entsteht. Aufgrund dieser Eigenschaften spielt das Ad-hoc Vorgehen für das Vorgehensmodell zur Weiterentwicklung von Unter- nehmensportalen keine Rolle.
[...]
1 http://www.f-i.de
2 http://www.sap.de
3 dt.: Tor, Pforte, Tür
4 http://developers.sun.com/portalserver/reference/techart/jsr168/
5 dt.: Wissensmanagement
6 dt.: Benutzerverwaltung
7 dt.: Zentraler Arbeitsvorrat (ZAV)
8 Vgl. ISO 9001:2008
- Citation du texte
- Christian Struck (Auteur), 2012, Konzeption eines Vorgehensmodells zur kontinuierlichen Weiterentwicklung von Mitarbeiterportalen, Munich, GRIN Verlag, https://www.grin.com/document/215443
