Unternehmensportale: Grundlagen, Architekturen, Technologien 3540222871, 9783540222873

Citation preview

---

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Martina Großmann Holger Koschek

Unternehmensportale Grundlagen, Architekturen, Technologien Mit 60 Abbildungen und 13 Tabellen

123

Martina Großmann [email protected]

Holger Koschek [email protected] www.pret-a-portal.info

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-22287-1 Springer Berlin Heidelberg New York ISBN-13 978-3-540-22287-3 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2005 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142 YL – 5 4 3 2 1 0

Für Uwe – M.G. Für Andrea, Nele, Marit und Lotta – H.K.

Vorwort

Vorbei sind die Zeiten, in denen Content-Management-Systeme als Allheilmittel im Kampf gegen die Informationsflut gepriesen und eingesetzt wurden. Sie hatten sich zum Ziel gesetzt, die komplexe Informationslandschaft der Unternehmen einheitlich und einfach zugreifbar zu gestalten. Dasselbe Ziel verfolgen die EnterpriseApplication-Integration-Systeme. Diese nähern sich dem genannten Ziel allerdings weniger vom Content, als vielmehr von den Informationssystemen an. Workflowsysteme weben die Informationen und Datenquellen schließlich in Geschäftsprozesse ein. Das Ergebnis ist ein integriertes System, das seinen Benutzern durchgängige Geschäftsprozesse zur Verfügung stellt und von der Komplexität der Informationslandschaft abstrahiert. Soweit die Theorie. Viele IT-Projekte, die sich mit den genannten Themen und Technologien beschäftigten, haben gezeigt, dass das hehre Ziel der Informations- und Prozessintegration gar nicht so einfach zu erreichen ist. Die Gründe für das Scheitern solcher Projekte sind vielgestaltig. Ihren Ursprung sucht man gern im technischen Bereich – wird dort aber seltener fündig, als man zunächst vermuten möchte. Oft sind es die fachlichen Probleme, die den negativen Ausschlag geben: Die Definition von Content, die Suche nach den Geschäftsprozessen, Abteilungsdenken, Datenhoheiten als Machtspiele, angeblich unveränderbare Anforderungen, Animositäten, Insellösungen. Erfolg aber ist Pflicht – gerade in Zeiten wirtschaftlicher Stagnation. Gefordert sind immer schnellere, immer günstigere, und vor allem messbare Lösungen. Messbar müssen sowohl die Kosten als auch der kurzund langfristige Erfolg sowie der Return on Investment derartiger Projekte sein. Es gilt, schlanke Geschäftsprozesse aufgabenbezogen mit den relevanten Informationen zu versorgen – einfach zu formulieren, aber schwierig umzusetzen. Betrachtet man die Entwicklung der Prozesse

Vorwort

■ ■ ■

VII

zur strategischen Entscheidungsfindung in den vergangenen Jahrzehnten, so wird man feststellen, dass Entscheidungen aus Gründen der Wettbewerbsfähigkeit immer schneller getroffen werden müssen. Kurze Reaktionszeiten und durchgängig hochwertige Dienstleistungen sind kritische Erfolgsfaktoren im internationalen Wettbewerb. Auf der anderen Seite werden immer mehr Informationsquellen und Daten als Entscheidungshilfe herangezogen, und die Kommunikationspfade werden immer länger – nicht zuletzt aufgrund der zunehmenden Globalisierung und Konzernbildung. Immer weniger Zeit, um immer mehr Informationen von einer zunehmenden Anzahl an Quellen zu verarbeiten, um dann rechtzeitig die richtige Entscheidung zu treffen oder die passende Auskunft zu geben – dieses Dilemma gilt es zu lösen. Unternehmensportale adressieren die genannten Herausforderungen, indem sie einen zentralen und einfachen Zugang zu allen relevanten Informationen, Anwendungen und Diensten bereitstellen. Neben der Integration unternehmensinterner wie auch externer Informationsquellen verwirklichen Unternehmensportale system- und unternehmensübergreifende Geschäftsprozesse, um jedem Benutzer für jede Situation alle für ihn wesentlichen Informationen sowie geeignete Vorgehensweisen an die Hand zu geben und ihn auf dem Weg zur Entscheidungsfindung zu begleiten. Unternehmensportale sind integrative Komponenten, die wesentliche Unternehmensanwendungen – auch die erwähnten ContentManagement-Systeme – fachlich sinnvoll zueinander in Beziehung setzen. Dieser integrative Charakter erlaubt die weitgehende Nutzung der bestehenden Infrastruktur und reduziert den Entwicklungsund Einarbeitungsaufwand. Ein Rollenkonzept, Personalisierung, Single Sign-On und Sicherheitskonzepte unterstützen eine zügige Integration. Damit eröffnen Unternehmensportale den Unternehmen vielfache Möglichkeiten zur Kosten- und Prozessoptimierung. Unternehmensportale stellen eine vergleichsweise junge Technologie dar, die aber auf erprobten Standardtechnologien basiert. Die Planung erfolgreicher Unternehmensportale orientiert sich an den individuellen Anforderungen und Möglichkeiten eines Unternehmens. Trotz der Vielfalt der zu beherrschenden Technologien sind Portalprojekte keine „klassischen“ IT-Projekte, da sie sich im Wesentlichen mit den Geschäftsprozessen eines Unternehmens befassen. Hinzu kommt, dass der Betrieb eines Unternehmensportals viele fachliche Fragen aufwirft: Wer liefert die Inhalte? Wie bringt man die Fachabteilungen dazu, die relevanten Informationen aus ihrem Bereich beizusteuern? Wie werden diese erfasst, strukturiert, abgeglichen und verwaltet? Wie sind die Verantwortlichkeiten definiert? Wie können weitere Prozesse und Systeme integriert werden? Wich-

VIII

■ ■ ■

Vorwort

tiger als diese Detailprobleme aber ist die Frage, welchen Nutzen der Einsatz eines Unternehmensportals bringt. Die von den Unternehmensportalen berührten Themengebiete sind so umfangreich wie vielfältig. Neben betriebswirtschaftlichen, fachlichen und organisatorischen Fragestellungen ist nicht zuletzt auch eine solide und zukunftsfähige Technologie für das Portalsystem zu wählen. Viele Portalprojekte scheitern schlicht daran, dass wesentliche der zuvor genannten Aspekte in der Planung und Realisierung unberücksichtigt bleiben. Hinzu kommt, dass der Begriff „Unternehmensportal“ mittlerweile von den Marketingabteilungen vieler Softwarehersteller entdeckt wurde – und auf alles Artverwandte „geklebt“ wird. Vom CMSSystem bis zum Web- und Applikationsserver: Alles ist angeblich ein Portal. Wer hätte da nicht gerne einen guten und umfassenden Leitfaden, der diesen Themenkomplex aus der Sicht von Praktikern umfassend vorstellt, die Begriffe definiert und gegeneinander abgrenzt sowie konkrete Hilfestellung bei der Bewertung und Auswahl von Portalsystemen bietet? Dieses Buch ist ein solcher Leitfaden.

Danke! Es gibt keine Drachen mehr. Als die Schriftstellerin Doris Lessing einem großen deutschen Nachrichtenmagazin die Frage beantworten sollte, woran es denn liege, dass die Qualitätsstandards bei der Produktion von Büchern stetig sinken, beklagte sie das Aussterben eines ganzen Berufsstandes: Sogenannte Copy Editors, sattelfeste wie streitbare Redakteure mit hoher Allgemeinbildung, die Manuskripte penibel auf sprachliche und stilistische Sauberkeit abklopften – und wegen ihrer resoluten Art in der Branche liebevoll-ehrfürchtig die „Drachen“ gerufen wurden. www.onlinejournalismus.de/webwatch/fehlerquote.php

Doch – es gibt sie noch, die „Drachen“ und unermüdlichen Helfer. Ohne sie wäre dieses Buch wohl nie entstanden. Wir bedanken uns bei Oliver Ihns für die Initialzündung und fortwährende Motivation sowie bei allen Kolleginnen und Kollegen der Resco GmbH für ihre Unterstützung. Vielen Dank an Herrn Engesser vom SpringerVerlag für das Vertrauen in unser Buchprojekt und die fachliche Betreuung. Herr Matrisch von der LE-TeX GbR hat uns bei allen produktionstechnischen Fragen mit Rat und Tat zur Seite gestanden. Unser besonderer Dank gilt unseren „Drachen“ Monika Großmann, Anke Koschek, Thomas „Samodrèthiël“ Lieder und Joachim Müller. Hamburg/Wedel, im April 2005

Martina Großmann Holger Koschek

Vorwort

■ ■ ■

IX

Die Autoren Martina Großmann Marketing-Kommunikationswirtin Mediengestalterin für Digital- und Printmedien (Medienberatung) Martina Großmann arbeitet derzeit als Consultant bei der Unternehmensberatung Resco in Hamburg. Als Expertin in den Domänen Marketing und Informationstechnologie liegt ihr Schwerpunkt im Bereich der Unternehmensportale und angrenzenden Themen wie Content Management oder Kommunikationsberatung. Als zertifizierte Projektmanagerin ist sie in internationalen Projekten tätig. [email protected]

Holger Koschek Diplom-Informatiker Holger Koschek studierte Informatik mit Schwerpunkt Softwaretechnik an den Universitäten Passau und Hamburg. Nach mehreren Engagements im Finanzdienstleistungsbereich in Frankfurt am Main und Zürich arbeitet er derzeit als Consultant bei der Unternehmensberatung Resco in Hamburg. Er beschäftigt sich hauptsächlich mit der J2EE-Softwareentwicklung sowie Unternehmensportalen und dem Portlet-Standard und ist Autor mehrerer Fachartikel zu diesen Themen. In verschiedenen internationalen Projekten hat er wiederholt die Rolle des Vermittlers zwischen den Fachabteilungen und der IT-Welt wahrgenommen. [email protected]

X

■ ■ ■

Vorwort

Prolog Wald in der Nähe von Wedel. Versammelt sind Squenz, Schnok, Zettel, Flaut, Schnauz und Schlucker. Holger tritt auf. Squenz Was blickst du nur so mürrisch drein, bist sonst doch immerzu so fröhlich. Zettel Und hast auch allen Grund zur Fröhlichkeit. Drei zauberhafte Töchter feengleich. Holger Hört auf mit dem Geschwätz. Ich habe keinen Grund zum Frohsinn. Ich muss ein Stück noch schreiben, das binnen dreier Monde aufgeführt werden soll, und bis jetzt habe ich noch nicht einmal den ersten Akt fertig. Squenz Da können wir dir helfen! Holger Das möchte ich sehen! Könnt ihr mir vielleicht beim Erstellen von Dateien mit Konstanten und Variablen helfen? Schnauz und Schlucker Nichts einfacher als das! Wir gehen morgen sowieso in den Wald, und da werden wir wohl so viele Variablen und Konstanten finden, wie du nur haben willst. Und Schnok der Schreiner wird dir eine Datei bauen. Schnok Ja, ich werde dir eine Datei bauen, die so schön und so stabil sein wird wie sie dir noch nie vorgekommen ist, und Flaut der Blasbalg-Flicker wird sie mit schönen Ornamenten versehen. Flaut Zwar bin ich nicht sehr gebildet, aber das werde ich wohl können. Holger Ich möchte weinen über euer Geschwätz. Ihr seid ja fast noch unbedarfter als mein Vater. Habt ihr auch nur eine blasse Ahnung über Laufwerke und Ordner? Schnauz und Schlucker Und ob wir das haben! Wir beide haben die besten Laufwerke im ganzen Norden, was man bei jedem Alsterlauf erleben kann. Und was den Ordner anbetrifft, so können wir nur auf Squenz verweisen. Er ist ein Genie, was das Ordnen anbetrifft. Holger Oh, dass doch gleich der Blitz einschlüge und alle Dummheit dieser Welt vernichte! Ich muss noch ein Portal erstellen. Stattdessen muss ich mir diesen Unsinn anhören. Zettel Da täuschst du dich. Sogleich wollen wir alle zupacken und dir ein Portal bauen, wie es so schön noch nie da gewesen ist. Mit prächtigen Stützen und einem wunderbaren Bogen wird es alle entzücken, die das Glück haben, dieses Wunderwerk zu bestaunen.

Heinz Koschek frei nach William Shakespeare

Vorwort

■ ■ ■

XI

Inhaltsverzeichnis

Einleitung ..........................................................................................1 Zielgruppe ...............................................................................1 Der Aufbau dieses Buchs........................................................2 Beispiele ..................................................................................5 Konventionen ..........................................................................5 Webseite ..................................................................................6 Kurz gefasst.............................................................................6 1

Begriffe ...................................................................................9 1.1 1.2 1.3

1.4 1.5 1.6 1.7 1.8

1.9

Ein gemeinsames Verständnis.....................................9 Unternehmen..............................................................10 Informationsmanagement ..........................................11 1.3.1 Daten ...............................................................12 1.3.2 Informationen .................................................15 1.3.3 Wissen.............................................................15 1.3.4 Content............................................................18 Prozessmanagement...................................................19 Applikationen und Dienste ........................................20 1.5.1 Applikationen .................................................21 1.5.2 Dienste ............................................................22 Integration ..................................................................23 1.6.1 Systemintegration und Prozessintegration.....24 1.6.2 Frontend- und Backend-Integration ...............25 Miteinanderarbeit (Collaboration).............................26 Portal ..........................................................................28 1.8.1 Horizontale und vertikale Portale...................29 1.8.2 Offene und geschlossene Portale ...................30 1.8.3 Kategorisierungsmatrix ..................................30 Unternehmensportale.................................................32 1.9.1 Zielgruppen.....................................................33 1.9.2 Anwendungsschwerpunkte.............................34

Inhaltsverzeichnis

■ ■ ■

XIII

1.9.3 Einsatzbereiche ...............................................37 2

Abgrenzung..........................................................................39 2.1

2.2

3

Motive und Grenzen ...........................................................51 3.1 3.2 3.3

3.4

4

■ ■ ■

Warum ein Portal einführen?.....................................51 Wem nützt ein Unternehmensportal? ........................52 Motive ........................................................................53 3.3.1 Miteinanderarbeit – auch über Unternehmensgrenzen hinweg .......................54 3.3.2 Verbesserung des Kundenservice...................57 3.3.3 Unterstützung strategischer Entscheidungen .60 3.3.4 Optimierung der Geschäftsprozesse...............61 3.3.5 Standardisierung .............................................63 3.3.6 Motivation der Mitarbeiter .............................64 3.3.7 Erfolgskontrolle ..............................................66 Grenzen ......................................................................68 3.4.1 Geringe Mitarbeitermotivation.......................69 3.4.2 Hierarchische Strukturen ................................71 3.4.3 Fehlende Verantwortlichkeiten ......................72 3.4.4 Fehlendes Bewusstsein für Geschäftsprozesse...........................................73 3.4.5 Fehlendes Wissen um verfügbare Informationen ...............................74 3.4.6 Unvollständige oder schlecht gepflegte Datenbestände.................................75 3.4.7 Ungenügende Integration ...............................76

Fachliche Anforderungen...................................................79 4.1 4.2 4.3 4.4

XIV

Content-Management-Systeme .................................39 2.1.1 Content-Management-Systeme und Portale im Vergleich ................................40 2.1.2 Content Management in Portalen ...................41 Enterprise Application Integration (EAI)..................44 2.2.1 Formen von EAI .............................................45 2.2.2 Der Aufbau eines message-basierten EAI-Systems ...................................................46 2.2.3 Web Services ..................................................47 2.2.4 EAI in Portalen ...............................................48

Abbildung und Steuerung von Geschäftsprozessen..79 Einheitliche integrierte Sicht auf Daten.....................87 Personalisierung .........................................................94 Single Sign-On ...........................................................98

Inhaltsverzeichnis

4.5 4.6 4.7 4.8 4.9 5

Sicherheit..................................................................102 Benutzer- und Rollenmanagement ..........................105 Ergonomie der Benutzungsschnittstelle ..................108 Multimodaler Zugriff...............................................110 Zukunftssicherheit ...................................................112

Technische Anforderungen..............................................115 5.1

Integration ................................................................115 5.1.1 Systemintegration .........................................116 5.1.2 Prozessintegration.........................................119 5.1.3 Frontend-Integration.....................................120 5.1.4 Backend-Integration .....................................122 5.1.5 Kombinierte Integration (Frontend + Backend)...................................122 5.2 Implizite Beziehungen zwischen Datenquellen ......125 5.2.1 Strukturierte Daten .......................................125 5.2.2 Unstrukturierte Daten ...................................127 5.3 Modelle für Metadaten ............................................129 5.3.1 Typen von Metadaten...................................130 5.3.2 Metadaten zum standardisierten Datenaustausch .............................................131 5.4 Datensicherheit ........................................................132 5.5 Verfügbarkeit ...........................................................132 5.5.1 Grundlegende Anforderungen......................133 5.5.2 Hochverfügbarkeit........................................134 5.5.3 Single Point of Failure..................................136 5.6 IT-Sicherheit ............................................................138 5.7 Skalierbarkeit ...........................................................139 5.8 Verteilbarkeit ...........................................................140 5.8.1 Gemeinsame Nutzung von Ressourcen .......141 5.8.2 Transparenz...................................................142 5.8.3 Performanz....................................................142 5.8.4 Adressierbarkeit (Naming) ...........................143 5.8.5 Konsistenz.....................................................143 5.8.6 Zeit ................................................................144 5.9 Modularer Entwurf: Entkoppelte Komponenten ....145 5.10 Standardtechnologien und offene Schnittstellen.....147 5.11 Trennung von Content und Design .........................149 5.12 Performanz ...............................................................151

6

Referenzarchitektur..........................................................155 6.1 6.2

Gebrauchsanleitung für eine Referenzarchitektur...155 Fachliches Architekturmodell .................................157

Inhaltsverzeichnis

■ ■ ■

XV

6.3

7

Standards........................................................................... 183 7.1 7.2

7.3

7.4 7.5 7.6 7.7 7.8

XVI

■ ■ ■

6.2.1 Integrationskomponente .............................. 159 6.2.2 Prozesskomponente ..................................... 160 6.2.3 Portalapplikationen ...................................... 162 6.2.4 Präsentationskomponente ............................ 163 6.2.5 Business Intelligence ................................... 165 6.2.6 Knowledge Management............................. 166 6.2.7 Benutzerverwaltung..................................... 167 6.2.8 Sicherheitsmechanismen ............................. 168 6.2.9 Programmierschnittstelle und -werkzeuge.. 169 Technische Referenzarchitektur ............................. 170 6.3.1 Middleware/EAI .......................................... 173 6.3.2 Transaktionsmanager................................... 174 6.3.3 Metadatenserver........................................... 175 6.3.4 Portalserver und Portlet-Container .............. 176 6.3.5 Web-Applikationsserver.............................. 176 6.3.6 Firewall ........................................................ 179 6.3.7 Web Services ............................................... 180 6.3.8 Portaladministration und -überwachung ..... 180

Der Nutzen von Standards ...................................... 183 Basistechnologie XML ........................................... 185 7.2.1 Document Type Definition (DTD).............. 189 7.2.2 XML-Schema............................................... 191 7.2.3 Definition eigener XML-Sprachen.............. 195 Standards für Präsentation und Layout von Portalinhalten....................................... 196 7.3.1 (X)HTML..................................................... 197 7.3.2 Cascading Stylesheets (CSS)....................... 199 7.3.3 XSL(T) ......................................................... 200 Standards für Integration......................................... 205 7.4.1 Web Services ............................................... 205 7.4.2 J2EE Connector Architecture (JCA) ........... 208 Standards für Portaltechnik..................................... 208 7.5.1 Portlets.......................................................... 210 7.5.2 Web Services for Remote Portlets (WSRP) 213 Standard für Portalinhalte: RSS.............................. 215 Standard für Prozesse: WfMC Workflow Reference Model ................................... 218 Standards für Content Management ....................... 220 7.8.1 WebDAV ..................................................... 220 7.8.2 Content Repository for Java Technology API................................... 220 7.8.3 Topic Maps .................................................. 221

Inhaltsverzeichnis

8

Das richtige System...........................................................223 8.1

8.2

8.3 8.4 9

Projektorganisation ..........................................................259 9.1 9.2

9.3 9.4 9.5 9.6 10

Portale für jede Unternehmensgröße.......................223 8.1.1 Kleine Unternehmen.....................................224 8.1.2 Mittlere Unternehmen ..................................226 8.1.3 Große Unternehmen .....................................227 8.1.4 Konzerne.......................................................228 Anforderungsanalyse ...............................................230 8.2.1 Die ersten Schritte bei der Anforderungsanalyse....................................232 8.2.2 Rahmenbedingungen ....................................237 8.2.3 Funktionale Anforderungen .........................240 8.2.4 Nicht-funktionale Anforderungen................240 8.2.5 Vorgehensweise............................................241 8.2.6 Die Analyse des Integrationspotenzials .......248 8.2.7 Bedeutung der Anforderungsanalyse ...........249 Softwareauswahl......................................................250 Marktübersicht .........................................................253

Spezielle Herausforderungen in Portalprojekten ....259 Die Schritte des Projektmanagement-Prozesses .....264 9.2.1 Der Prozess des Projektmanagements..........264 9.2.2 Der richtige Projektstart ...............................265 9.2.3 Prototyping....................................................271 9.2.4 Implementierung...........................................274 9.2.5 Projektcontrolling .........................................275 9.2.6 Test................................................................278 9.2.7 Rollout...........................................................280 Iteratives Vorgehen..................................................281 Inhalte vor- und aufbereiten ....................................282 Portalmarketing........................................................285 Den Projekterfolg messen – Nutzenbetrachtung.....287

Betrieb und Evolution.......................................................289 10.1 Portalmarketing........................................................290 10.2 Bereitstellung aktueller und relevanter Informationen .........................................294 10.3 Die Redaktion eines Unternehmensportals .............295 10.4 Erkennen von Integrationspotenzialen ....................299 10.5 Miteinanderarbeit in Portalen ..................................300 10.6 Das lernende Projekt................................................302 10.7 Release Management ...............................................305

Inhaltsverzeichnis

■ ■ ■

XVII

11

Nutzenanalyse und Erfolgskontrolle.............................. 311 11.1 11.2 11.3 11.4

12

Was nützt der Nutzen? ............................................ 311 Return on Investment (ROI) ................................... 313 Total Cost of Ownership (TCO) ............................. 318 Nutzensicherung...................................................... 320

Vorgehensmodell .............................................................. 323 12.1 Warum ein Vorgehensmodell? ............................... 323 12.2 Das Vorgehensmodell für Portalprojekte ............... 325 12.2.1 Zielfindung................................................... 327 12.2.2 Anforderungsanalyse ................................... 327 12.2.3 Analyse der Informations-, Prozess- und Systemlandschaft ......................................... 328 12.2.4 Portalkonzeption .......................................... 330 12.2.5 Implementierung.......................................... 332 12.2.6 Test ............................................................... 333 12.2.7 Einführung ................................................... 334

13

Ausblick ............................................................................. 335 13.1 Anforderungen der Unternehmen an die Portale von morgen ...................................... 335 13.2 Die Entwicklung des Portalmarkts ......................... 337 13.3 Technische Entwicklungen ..................................... 339 13.3.1 Komponentensysteme.................................. 339 13.3.2 Web Services ............................................... 341 13.3.3 Service-Oriented Architectures ................... 341 13.3.4 Semantic Web .............................................. 342 13.3.5 Intelligente Recherche ................................. 343 13.3.6 Mobilität und Multimodalität ...................... 344 13.3.7 Agilität.......................................................... 346 13.4 Fazit ......................................................................... 348

Literaturverzeichnis .................................................................... 349 Stichwortverzeichnis ................................................................... 355

XVIII

■ ■ ■

Inhaltsverzeichnis

Einleitung

Das vorliegende Buch behandelt die fachlichen, technischen und betriebswirtschaftlichen Aspekte von Unternehmensportalen. Diese ganzheitliche Sichtweise bietet Ihnen einen umfassenden Überblick und versetzt Sie grundsätzlich in die Lage, die Einführung eines Unternehmensportals für das eigene Unternehmen zu kalkulieren, zu planen und durchzuführen sowie den Betrieb des Unternehmensportals zu organisieren. Inhaltlich gehen wir dabei nicht bis ins letzte Detail. Das ist auch nicht unser Ziel. Wir wollen vielmehr den „roten Faden“ liefern, der Sie schnell und sicher durch die Welt der Unternehmensportale und die Projekte zum Aufbau dieser Portale führt. Wo immer möglich, haben wir Hinweise auf weiterführende Literatur oder Webseiten angegeben, anhand derer Sie sich in die Details einarbeiten können.

Zielgruppe Dieses Buch richtet sich an alle, die einen umfassenden Überblick über das umfangreiche Themengebiet der Unternehmensportale gewinnen möchten. Es soll insbesondere fachlich wie technisch orientierten Entscheidern und Projektleitern helfen, die Einführung eines Unternehmensportals fundiert nach Kosten und Nutzen zu bewerten sowie realistisch zu planen und durchzuführen. Auch wenn Sie in diesem Buch – abgesehen von etwas XMLCode – mit der Technik von Unternehmensportalen nicht in Berührung kommen, sei das Buch auch den Architekten und Softwareentwicklern in Portalprojekten ans Herz gelegt. Sie werden lernen, dass die Entwicklung eines Unternehmensportals in erster Linie eine fachliche Aufgabe ist, die natürlich technisch umgesetzt werden muss. Außerdem lernen Sie viele Standards kennen, die für Portale eine Rolle spielen.

Zielgruppe

■ ■ ■

1

Gut beraten?

Portalprojekte sind in vielerlei Hinsicht anspruchsvoll: ■

Sie erfordern die Zusammenarbeit verschiedener Fachabteilungen und der IT-Abteilung.

■

Sie tangieren die Geschäftsprozesse des Unternehmens und verändern diese gegebenenfalls.

■

Sie werfen einen kritischen Blick auf die Informationssysteme des Unternehmens – mit dem Ziel, diese nach fachlichen Anforderungen zu integrieren.

■

Sie erfordern ein Projektteam, das viele verschiedene fachliche und technische Themengebiete abdecken muss.

■

Sie sind oft für die Benutzung der Mitarbeiter des Unternehmens konzipiert – eine Benutzergruppe, die mit Kritik oftmals offener umgeht als Kunden, Lieferanten oder Partner.

■

Sie erregen eine bemerkenswerte Aufmerksamkeit bei der Führungsebene des Unternehmens; entsprechend hoch sind die Erwartungen.

Diese Liste ließe sich noch fortsetzen – aber bereits die genannten Aspekte machen deutlich, dass ein solches Projekt ohne den Einsatz von Portalexperten kaum zu bewältigen ist. Deshalb unser gut gemeinter Rat: Lassen Sie sich – zumindest bei Ihrem ersten Portalprojekt – von erfahrenen Experten unterstützen.

Der Aufbau dieses Buchs

Kurz gefasst

Checklisten

2

■ ■ ■

Wir haben das Buch als Nachschlagewerk konzipiert. Diese Funktion erschließt sich aber erst nach einem ersten, mehr oder weniger vollständigen linearen Lesen. Insbesondere das erste Kapitel möchten wir Ihnen nahe legen – wohl wissend, dass Begriffsdefinitionen nicht gerade zu den spannenden Inhalten zählen. Sie werden aber später feststellen, dass ein gemeinsames Begriffsverständnis die Lektüre der folgenden Kapitel vereinfacht. Jedes Kapitel beginnt mit einer Zusammenfassung, zu erkennen an der Marginalie „Kurz gefasst“. So wissen Sie, was Sie auf den folgenden Seiten erwartet. Auch später, wenn das Buch als Nachschlagewerk dient, kann diese Zusammenfassung in Kombination mit dem Index die Orientierung erleichtern. Aus vielen Inhalten dieses Buchs lassen sich Checklisten ableiten. Diese setzen die vermittelten Inhalte in Fragenkataloge oder Arbeitsanweisungen um. Wir haben bewusst darauf verzichtet, diese Checklisten im Buch abzudrucken. Schließlich sind diese für die

Einleitung

Praxis gedacht und sollen deshalb in elektronischer Form vorliegen. Dann können die Checklisten einfach als Grundlage für eigene, projektspezifische Anpassungen und Erweiterungen verwendet werden. Deshalb finden Sie die Checklisten auf der Webseite zum Buch (www.pret-a-portal.info). Wir werden die Checklisten dort pflegen, gegebenenfalls erweitern und verändern. Wir sind sehr interessiert an Ihren Kommentaren und Verbesserungsvorschlägen – so können Sie uns helfen, die Qualität der Checklisten kontinuierlich zu verbessern. Über die genannte Webseite können Sie mit uns in Kontakt treten. Zunächst wird mit der Definition grundlegender Begriffe ein gemeinsames Verständnis für die verschiedenen Aspekte des Themengebiets „Unternehmensportale“ geschaffen. Wir stellen die thematischen Schwerpunkte Informationsmanagement, Prozessmanagement, Applikationen und Dienste sowie Integration vor. Dann werden die Zielgruppen (Benutzer) und die verschiedenen Anwendungsschwerpunkte von Unternehmensportalen aufgezeigt.

Kapitel 1: Begriffe

Portale werden oft in einem Zug mit den Begriffen „Content Management“ und „Enterprise Application Integration“ (EAI) genannt. Auch wenn diese Themen eng miteinander verwandt sind, so können sie doch klar gegeneinander abgegrenzt werden, wie im zweiten Kapitel gezeigt wird.

Kapitel 2: Abgrenzung

Am Anfang eines Portalprojekts steht die Frage: „Warum ein Portal einführen?“. Das Wissen um die verschiedenen Motive für den Portaleinsatz hilft bei der Formulierung der eigenen Portalvision. Um realistische Ziele für das Unternehmensportal zu definieren, muss man auch um die Grenzen wissen, die Unternehmensportalen gesetzt sind. Die meisten Grenzen liegen übrigens in den organisatorischen Gegebenheiten begründet, und nicht etwa in den technischen Strukturen.

Kapitel 3: Motive und Grenzen

Basierend auf dem einheitlichen Begriffsverständnis und den Überlegungen zu Motiven und Grenzen werden die fachlichen und technischen Anforderungen an ein Unternehmensportal formuliert und erläutert. Diese Anforderungen werden deutlich gegeneinander abgegrenzt, um sie in der im Folgenden dargestellten Referenzarchitektur jeweils einer Komponente zuordnen zu können. Die Anforderungen werden ergänzt um praktische Lösungsansätze (sogenannte Best Practices) für typische, in der Praxis eines Unternehmensportalprojektes häufig anzutreffende Problemstellungen.

Kapitel 4: Fachliche Anforderungen

Der Aufbau dieses Buchs

Kapitel 5: Technische Anforderungen

■ ■ ■

3

Kapitel 6: Referenzarchitektur

Die Referenzarchitektur umfasst sowohl fachliche als auch technische Komponenten mit klaren Verantwortlichkeiten – eine wichtige Voraussetzung, um später ein konkretes Portalsystem aus verschiedenen Softwarekomponenten (unter Umständen von verschiedenen Herstellern) zusammenstellen zu können.

Kapitel 7: Standards

Der Erfolg der in der Referenzarchitektur vorgestellten Komponententechnologie basiert auf der Nutzung etablierter und praxiserprobter Standards. Die für Portale relevanten Standards, wie z.B. XML, Web Services und Portlets, werden vorgestellt und bewertet.

Kapitel 8: Das richtige System

Jetzt, da eine prototypische Architektur und die geeigneten Zutaten für ein erfolgreiches Unternehmensportal bekannt sind, kann man sich der Suche nach dem passenden Portalsystem widmen. Das Kapitel schließt mit einem Blick auf die aktuelle Entwicklung des Portalmarkts.

Kapitel 9: Projektorganisation

Anschließend werden die Prozesse betrachtet, die in Entwicklung und Betrieb von Unternehmensportalen eine Rolle spielen, und die damit verbundenen organisatorischen Herausforderungen skizziert.

Kapitel 10: Betrieb und Evolution

Da der Nutzen eines Unternehmensportals im Wesentlichen abhängig ist von der Qualität und der Relevanz der angebotenen Informationen, werden wir das Augenmerk auch auf die Betriebsorganisation lenken, die ein Unternehmensportal benötigt. Wir geben Hinweise zur Organisation einer Portal-Redaktion und beschreiben Techniken, mit denen man auch ungeübte Mitarbeiter zu Informationslieferanten für das Portal entwickeln kann. Wir schärfen den Blick für das Erkennen von Integrationspotenzialen, um das gesamte Unternehmen und seine Prozesse sukzessive abzubilden.

Kapitel 11: Nutzenanalyse und Erfolgskontrolle

Selbst technisch ausgereifte Portallösungen werden nur dann die Akzeptanz der Benutzer finden, wenn auch die Organisation des Portals zum Unternehmen passt. Zudem gilt es, den tatsächlichen Nutzen des Portaleinsatzes zu messen und mit dem eingangs geplanten Nutzen zu vergleichen. Aus diesem Vergleich leiten sich Maßnahmen zur Erhöhung des Nutzungsgrades ab. Wir stellen betriebswirtschaftliche Methoden und Vorgehensweisen vor, die bei einer solchen Nutzenanalyse helfen, und geben Hinweise auf Nutzen fördernde Maßnahmen.

Kapitel 12: Vorgehensmodell

Für die Projektorganisation geben wir Ihnen eine Vorgehensweise für die Entwicklung eines Unternehmensportals an die Hand. In Kombination mit der vorgestellten Referenzarchitektur bildet dieses

4

■ ■ ■

Einleitung

Vorgehensmodell das Rüstzeug, um sukzessive und strukturiert ein an den eigenen Anforderungen ausgerichtetes Unternehmensportal aufzubauen. Dem Vorgehensmodell kommt dabei die Aufgabe der Zerlegung des Entwicklungsprozesses in fachlich wie wirtschaftlich sinnvolle Teilschritte zu, ohne dabei das Ziel der umfassenden Gesamtlösung aus den Augen zu verlieren. Zum Abschluss wagen wir einen Blick in die Zukunft der Portale. Neue Managementkonzepte, der wirtschaftliche Wandel und technische Neuerungen verändern die Anforderungen der Unternehmen. Dementsprechend müssen die Portalsysteme von morgen andere Schwerpunkte setzen – in fachlicher wie technischer Hinsicht. Wir spüren die Trends auf und schreiben sie in die Zukunft fort.

Kapitel 13: Ausblick

Beispiele Wo immer es möglich ist, verwenden wir ein durchgängiges Beispiel. Es handelt sich dabei um das Unternehmen „Wein&Dein“, ein Versandhaus für Weine und alles rund um den Wein. Wein&Dein ist auch im Internet mit einem Online-Shop vertreten und unterhält zudem ein Mitarbeiterportal im Intranet. Für uns ist Wein&Dein ein geeignetes Mittel, um die in konkreten Kundenprojekten gemachten Erfahrungen zu abstrahieren und zusammenzufassen.

Konventionen Unsere Entscheidung, auf Schreibweisen wie „Benutzerinnen und Benutzer“ oder „SoftwareentwicklerInnen“ zu verzichten, ist ausschließlich der besseren Lesbarkeit geschuldet. Wenn wir von „dem Benutzer“ sprechen, dann meinen wir damit Rollennamen im Sinne funktioneller Rollen (vgl. Floyd 1997), die menschliche Aktivitäten und Aufgaben bezeichnen. Als Literatur bezeichnen wir neben Büchern und Zeitschriften auch elektronische Medien, wie z.B. Webseiten, PDF-Dateien etc. Die elektronischen Medien sind im Literaturverzeichnis durch Angabe einer URL gekennzeichnet. Eine Online-Version des Literaturverzeichnisses mit direkten Verweisen zu den elektronischen Medien finden Sie auf unserer Webseite www.pret-a-portal.info. Die Marginalien sollen Ihnen beim „Schnelldurchlauf“ durch das Buch die nötige Orientierung geben. Sie fassen die nebenstehenden Absätze zusammen. Des weiteren finden Sie in der Marginalienspalte die Beschriftung der Abbildungen und Tabellen. Außerdem sind dort die Beispiele und Definitionen sowie allgemeine Hinweise auf-

Beispiele

Schreibweisen

Literatur

Marginalien und Icons

■ ■ ■

5

geführt. Um diese besonders hervorzuheben, haben wir sie mit Icons gekennzeichnet: Beispiele, Definitionen, Praxistipps und allgemeine Hinweise.

Webseite Mit dem Siegeszug des Internet ist die Welt der Informationen dynamischer geworden. Dem wollen wir Rechnung tragen, indem wir aktuelle Informationen zu diesem Buch auf einer Webseite anbieten. Sie finden dort unter anderem ■

Errata,

■

die im Buch referenzierten Checklisten,

■

eine Online-Version des Literaturverzeichnisses mit Verweisen auf elektronische Quellen,

■

häufig gestellte Fragen zum Buch und zu Unternehmensportalen allgemein (natürlich mit Antworten),

■

die Möglichkeit, Kontakt zu den Autoren aufzunehmen

Die Webseite zum Buch und weiteren Themen rund um Unternehmensportale erreichen Sie unter der URL www.pret-a-portal.info

Kurz gefasst „Kurz gefasst“ steht, wie beschrieben, für eine Zusammenfassung der Kapitel, an dieser Stelle also als Zusammenfassung des Buchs. Ein Fazit gleich zu Beginn? Warum nicht – so wissen Sie sofort, was Sie auf den kommenden Buchseiten erwartet. Die zentrale Aussage dieses Buchs lautet: Unternehmensportale sind in erster Linie eine fachliche und organisatorische Herausforde-

6

■ ■ ■

Einleitung

rung. Die Wegbereiter des Unternehmensportals sind durchweg „klassische“ Disziplinen: Geschäftsprozessanalyse, fachliche Anforderungsanalyse, Systemanalyse, Softwareauswahl. Die wirtschaftliche Lage lässt die Bedeutung einer frühzeitigen und fundierten Nutzenanalyse weiter wachsen. Die Technik ist bereits heute flexibel genug, um die betriebswirtschaftlichen Prozesse und Funktionen in geeigneter Weise abzubilden – wenngleich es mitunter an qualifiziertem Personal fehlt, das den Umgang mit diesen Technologien beherrscht. Während dieses Expertenwissen für Portalprojekte über externe Ressourcen abgedeckt werden kann, müssen die fachlichen Anforderungen im Wesentlichen aus dem Unternehmen selbst kommen. Sonst droht die Realisierung eines Portals mit Funktionen, die sich nicht mit den Erwartungen der Benutzer decken. Aber die Erfüllung der Erwartungen allein genügt nicht. Nur ein Unternehmensportal, dessen Mehrwert allen (potenziellen) Nutzern anschaulich verdeutlicht wird, kann auf Dauer erfolgreich sein. Deshalb muss ein Portal beworben werden. Wir zeigen, dass dies auch ohne Hochglanzprospekt möglich ist. Die Technologien im Umfeld der Portale sind durchweg modern und folgen dem allgemeinen Trend zur Standardisierung. Je offener ein Standard ist, und je mehr er die von uns propagierte Architektur der entkoppelten Komponenten fördert, desto flexibler lässt sich ein Portalsystem aus vorgefertigten Modulen kombinieren. Diese Flexibilität ist auch nötig, um sich kontinuierlich den wechselnden Anforderungen zu stellen und auf diese reagieren zu können. Schließlich sind die Anforderungen der Benutzer sowie der betriebswirtschaftliche Nutzen die Richtschnur, an der sich das Unternehmensportal messen lassen muss – jederzeit.

Kurz gefasst

■ ■ ■

7

1 Begriffe

In diesem Kapitel werden grundlegende Begriffe aus dem Umfeld der Unternehmensportale definiert und gegeneinander abgegrenzt. Die Themengebiete, aus denen diese Begriffe stammen, umfassen das Informationsmanagement und das Prozessmanagement sowie Applikationen und Dienste, Integration und die Miteinanderarbeit. Das Kapitel schließt mit der Definition der Begriffe Portal und Unternehmensportal und einer Vorstellung der Zielgruppen, Anwendungsschwerpunkte und Einsatzbereiche von Unternehmensportalen. Ziel dieses Kapitels ist ein gemeinsames Verständnis der definierten Begriffe – idealerweise über den Kontext dieses Buchs hinaus.

Kurz gefasst

1.1 Ein gemeinsames Verständnis „Was ist ein Portal?“ Befragen Sie drei Kollegen, und Sie erhalten mindestens drei verschiedene Antworten. Der ohnehin große Interpretationsspielraum wird zu allem Überfluss von den MarketingAbteilungen der Softwarehersteller nach Belieben erweitert. Dokumenten-Management, Workflow-Management, Integrationssoftware oder Web-Applikationsserver: Software unterschiedlichster Couleur wird mit dem Attribut „(Unternehmens-)Portal“ belegt, um das Kundeninteresse zu wecken. Verständlich, wenn man das Marktpotenzial von Unternehmensportalen berücksichtigt – und bedauerlich zugleich. Jeder, der einmal an einem IT-Projekt mitgewirkt hat, kennt das Problem: Zentrale Begriffe haben für verschiedene Projektbeteiligte unterschiedliche Bedeutungen. Das liegt häufig am Blickwinkel – etwa dann, wenn Mitarbeiter der Fachabteilung einen Begriff aus ihrer Anwendungsdomäne heraus bewerten, während das Augenmerk der IT-Kollegen auf der informationstechnischen Modellierung des Begriffs liegt. Richtig problematisch wird es, wenn vermeintlich eindeutige Begriffe unterschiedlich ausgelegt werden.

1.1 Ein gemeinsames Verständnis

■ ■ ■

9

Wein&Dein bietet dem Kunden Proben ausgewählter Weine zum Kauf über ein Portal an. Es handelt sich um Erzeugerabfüllungen in 250 ml-Flaschen zu einem attraktiven Preis. Im Portal sollten diese Produkte zunächst als „Weinproben“ bezeichnet werden. Als die Wein&Dein beliefernden Winzer einen Prototyp des Portals präsentiert bekamen, gaben sie sofort zu bedenken, dass der Kunde mit dem Begriff „Weinprobe“ einen geselligen und informativen Abend mit Verkostung im Weinkeller verbindet. Und so dauerte es nicht lange, bis die Marketingabteilung eine neue Produktidee hatte: Ein Präsentkorb mit einer regionalen Auswahl dieser kleinen Flaschen sowie typischen Speisen der Region sollte ebenfalls „Weinprobe“ genannt werden. Man kam glücklicherweise dahingehend überein, dass die traditionelle Deutung des Begriffs – insbesondere aus Kundensicht – als unantastbar gilt. Die kleinen Flaschen wurden in „Probier/4“ (Probier-durch-vier; modern für: „Probier-Viertele“) umgetauft. Der Präsentkorb ist einem Karton gewichen und heißt jetzt „RegionalBox“. Definitionen – exakt, randscharf und thematisch gruppiert

In diesem Buch sind die folgenden Begriffe deshalb so exakt wie möglich definiert, gegeneinander abgegrenzt und thematisch gruppiert worden. Wir sind uns der Tatsache bewusst, dass diese Definitionen mitnichten den gesamten Interpretationsraum des Begriffs überdecken. Das ist weder möglich noch sinnvoll. Und doch sind wir der Meinung, dass die von uns gewählten Definitionen die gängigsten Deutungen einschließen. Vermeiden Sie von Beginn an Missverständnisse, indem Sie exakte Definitionen in Ihrem Portalprojekt verwenden. Sie können unsere Definitionen als Grundlage für Ihr projektspezifisches Glossar nutzen.

1.2 Unternehmen Wenn wir in diesem Buch von Unternehmen sprechen, dann fassen wir diesen Begriff weiter als die Betriebswirtschaftslehre. Letztere beschränkt den Begriff auf Einzelwirtschaften, die dem erwerbswirtschaftlichen Prinzip unterliegen. Aus Sicht der Unternehmensportale ist es sinnvoll, auch kleinere Einheiten, z.B. Abteilungen oder Projektteams, als „Unternehmen“ im weiteren Sinne zu bezeichnen. Ebenso fallen große, gemeinnützige Organisationen wie Unicef, Greenpeace oder die Vereinten Na-

10

■ ■ ■

1 Begriffe

tionen unter diesen erweiterten Unternehmensbegriff. Auch die zunehmend verfügbaren Bürgerinformationssysteme und webunterstützte Verwaltungsprozesse, die unter dem Begriff eGovernment zusammengefasst werden, weisen die Charakteristika von Unternehmensportalen auf.

1.3 Informationsmanagement Portale werden oft als zentraler Zugangspunkt zu Informationen aller Art gesehen. Diese Sichtweise, die insbesondere von den Vertretern der Content-Management-Fraktion gestützt wird, nennt einen wesentlichen, wenngleich nicht den einzig wichtigen Aspekt von (Unternehmens-)Portalen. Ohne Zweifel gewinnt das Informationsmanagement eine zunehmende Bedeutung in den Unternehmen. Der rasante Fortschritt auf dem Gebiet der Informationstechnologie und der Telekommunikation sind der Grund für diese Entwicklung. Noch vor vierzig Jahren wurde der größte Teil der Unternehmensdaten auf Papier gedruckt und geschrieben, in Aktenordner einsortiert und in Aktenschränken oder großen Archiven abgelegt. Solche Daten werden heute zunehmend elektronisch erfasst (oder zumindest in eine elektronische Form überführt, z.B. durch Scannen), verarbeitet und gespeichert. Die Papierarchive weichen zunehmend den großen Computernetzwerken. Das elektronisch vernetzte Unternehmen knüpft Kontakt zu seiner Umwelt – andere Unternehmen, aber auch das Internet werden zum Partner des Informationsaustauschs. Eine direkte Folge der weltweiten Vernetzung wird zunehmend zum zentralen Problem des Informationsmanagements: Das Informationsvolumen nimmt ständig zu – und auch die Frequenz, mit der die Informationen im Unternehmen eintreffen, wird zunehmend höher. Auf der anderen Seite bleibt immer weniger Zeit, um auf Grundlage dieser Informationen unternehmerische Entscheidungen zu treffen. In der Zeit der Papierarchive lag die Herausforderung darin, die gewünschte Information zu finden – man musste am richtigen Ort suchen. Heutzutage bedient man sich elektronischer Suchmaschinen. Diese suchen nicht nach dem richtigen Ort – sie suchen einfach an allen ihnen bekannten Orten. Mit deren Hilfe werden oft auch Informationen gefunden, von deren Existenz der Suchende gar nicht wusste. Dementsprechend umfangreich kann allerdings auch das Suchergebnis ausfallen.

1.3 Informationsmanagement

Zugang zu Informationen

Erfassung und Verwaltung von Daten

■ ■ ■

11

Von der Information zum Wissen

Filtern und Sortieren der Suchergebnismenge nach Relevanz – so lautet die neue Herausforderung der Informationsrecherche. Indem wir dies tun, extrahieren wir Wissen aus diesen Informationen, und dieses Wissen versetzt uns in die Lage, Entscheidungen zu treffen. Die drei wesentlichen Begriffe des Informationsmanagements wurden bereits genannt: Daten, Informationen und Wissen. Ein vierter Begriff, Content, wird in diesem Zusammenhang auch häufig genannt und soll deshalb ebenfalls genauer beschrieben werden.

1.3.1 Daten Daten sind Sammlungen von unteilbaren, individuellen Elementen. Man unterscheidet Daten nach ihrer Struktur und ihrem Bearbeitungsgrad. Abb. 1.1 Kategorisierung von Daten und Informationen (Quelle: SAP)

Originäre Daten

Applikationen

Internet

Unstrukturierte Daten

Strukturierte Daten

ERP-Systeme

Portal

Data Warehouse ManagementInformationssysteme

Extrahierte und aufbereitete Daten

12

■ ■ ■

1 Begriffe

Content Dokumente

Abbildung 1.1 zeigt verschiedene Ausprägungen von Daten, die sich bezüglich ihrer Struktur und ihres Bearbeitungsgrades voneinander abgrenzen. Unstrukturierte Daten sind Daten, die nicht nach einem festgelegten Schema strukturiert sind. Die automatische Bilderkennung durch Computer zählt z.B. immer noch zu den weitgehend ungelösten Problemen der Informationstechnologie. Man denke nur an die Probleme bei der biometrischen Identifikation von Personen: Bisher ist es noch nicht gelungen, eine Person eindeutig anhand eines Fotos von einem Computer identifizieren zu lassen – die Trefferquote ist zumindest noch nicht hoch genug, um diese Technologie in sicherheitskritischen Bereichen einzusetzen (vgl. Busch et al. 2003). Man kann ein Foto deshalb als eine Menge unstrukturierter Daten bezeichnen. Auch das Internet ist eine Quelle unstrukturierter Daten. Die HTML-Seiten des World Wide Web (WWW) weisen zwar eine standardisierte technische Struktur auf, die es verschiedenen Webbrowsern ermöglicht, die Seiten weitgehend einheitlich darzustellen. Semantisch aber sind die Inhalte nicht strukturiert – eine Maschine kann den Inhalt einer Webseite nicht automatisch bestimmen, da deren Semantik im Normalfall nicht gespeichert ist.

Unstrukturierte Daten

Strukturierte Daten folgen in ihrem Aufbau bestimmten Regeln. Sie können formal durch Datentypen beschrieben und von Computern interpretiert werden. Der Wertebereich der natürlichen Zahlen kann formal wie folgt beschrieben werden:

Strukturierte Daten

1. Das Zeichen „0“ ist eine natürliche Zahl. 2. Die Zeichen „1“, „2“, „3“, „4“, „5“, „6“, „7“, „8“ und „9“ sind natürliche Zahlen. 3. Jede Zeichenfolge, bestehend aus den in 2. definierten Zeichen, gefolgt von beliebig vielen Zeichen aus Regel 1 oder 2, ist eine natürliche Zahl. Die Ziffern werden in dieser Definition bewusst ganz neutral als „Zeichen“ bezeichnet. Damit soll angedeutet werden, dass ihnen keine Bedeutung (Semantik) innewohnen muss, um als Datentyp definiert werden zu können. Man hätte stattdessen auch zehn andere (unterscheidbare) Zeichen verwenden können. Tatsächlich reicht die

1.3 Informationsmanagement

■ ■ ■

13

obige Definition nicht aus, um die natürlichen Zahlen vollständig zu charakterisieren. Es fehlen z.B. die Operationen (Addition, Subtraktion, Multiplikation und Division). Solche Operationen sind in der Informatik Bestandteil eines Datentyps. Die Definition der Produkte von Wein&Dein ist eine Sammlung strukturierter Daten. Jedes Produkt hat eine Artikelnummer, eine Beschreibung und einen Preis in einer festgelegten Währung. Eine Bestellung erweitert diese Informationen um die Anzahl für jede einzelne Bestellposition. Aus den Bestellinformationen kann automatisch eine Rechnung erstellt werden. Informationssysteme dienen im Wesentlichen der Erfassung und Verarbeitung von Daten. Alle erfassten Daten, die über einen längeren Zeitraum genutzt werden sollen, werden dauerhaft in einem Datenspeicher abgelegt. Damit ist nicht unbedingt ein relationales Datenbank-Managementsystem (RDBMS) gemeint, sondern ganz allgemein eine Software, die das Speichern von Daten auf einem nichtflüchtigen Speichermedium, z.B. einer Festplatte, erlaubt. Bei den originären Daten unterscheidet sich das Format, in dem die Daten gespeichert werden, nicht (oder nur unwesentlich) vom Format, in dem sie in das Informationssystem gelangt sind. Originäre Daten

Originäre Daten haben oft den Nachteil, dass sie zu detailliert sind, um zu einer schnellen strategischen Entscheidungsfindung beitragen zu können. Zu groß ist der Aufwand, um diese Daten bei jeder Recherche erneut zu extrahieren, miteinander zu kombinieren und zu verdichten. Aus diesem Grund werden die Daten in separate Datenspeicher überführt, wo sie in einer aufbereiteten Form abgelegt werden. Aufbereitete Daten entstehen durch die Verarbeitung originärer Daten. Dazu werden Beziehungen zwischen den Daten erkannt und (technisch) geknüpft, arithmetische und finanzmathematische Operationen auf den Daten durchgeführt, oder die Daten werden nach bestimmten Kriterien sortiert, gruppiert und verdichtet.

Aufbereitete Daten

14

■ ■ ■

Die angesprochenen Beziehungen zwischen den Daten stellen beispielsweise den Zusammenhang her zwischen dem Umsatz eines Produktes und der regionalen Herkunft der Käufer oder der Jahreszeit. Die Umsatzentwicklung der vergangenen zehn Jahre oder der Quartalsumsatz je Verkaufsregion sind typische Kennzahlen, die aus aufbereiteten Daten gewonnen werden. Informationsrecherchen, die

1 Begriffe

auf der verdichteten Datenbasis durchgeführt werden, profitieren von dieser Vorbehandlung der Daten. Sie können auf deren Basis schnellere und oft auch genauere Ergebnisse erzielen.

1.3.2 Informationen Oft ist eine Zusammenstellung von Daten durch Beziehungen miteinander verknüpft, so dass den Daten eine Bedeutung zugeschrieben werden kann. In diesem Fall wird die Datenmenge als Information bezeichnet und durch einen Sammelbegriff beschrieben. Betrachtet man die Datenmenge [„Hamburg“, „1“, „20097“, „Rathausmarkt“], so erschließt sich durch „logisches Umsortieren“ der Daten die Bedeutung dieser Menge als postalische Adresse. Eine mögliche (sehr eingeschränkte) formale Definition der Information „Postalische Adresse“ ist eine Datenmenge, die aus jeweils einem Element des Datentyps „Straßenname“, „Hausnummer“, „Postleitzahl“ und „Ort“ besteht. Eine Datenmenge, der aufgrund ihrer Struktur und der Beziehungen zwischen den Datenelementen eine Bedeutung zugeschrieben werden kann, wird als Information bezeichnet. Daten repräsentieren Informationen in einer zur technikgestützten Darstellung und Verarbeitung geeigneten Form. Informationen, die in einer zur Weitergabe oder Übertragung geeigneten Form vorliegen, bezeichnet man als Nachrichten. Wir werden in diesem Buch den Begriff der „Information“ auch als Oberbegriff für Daten und Nachrichten verwenden – insbesondere dann, wenn sowohl die nichttechnischen als auch die technischen Aspekte von Informationen gemeint sind. Dies ist unser Zugeständnis an den Lesefluss, der durch Konstrukte wie „Informationen bzw. Daten oder Nachrichten“ unnötig leiden würde.

1.3.3 Wissen Wissen entsteht, wenn eine Person Informationen aufnimmt, verarbeitet und verwertet. Die verschiedenen Formen der Wissensverwertung schließen das Ausführen von Aktionen und das Treffen von Entscheidungen auf Grundlage des erworbenen Wissens mit ein.

1.3 Informationsmanagement

■ ■ ■

15

Vollständigkeit

Relevanz

Rechtzeitige Verfügbarkeit

Knowledge Management

16

■ ■ ■

Bezogen auf das obige Beispiel besitzt ein Postbote Wissen, wenn er eine Beziehung zwischen einem Haus und dessen Adresse herstellen kann. Der Transferprozess von der Information zum Wissen unterliegt verschiedenen Randbedingungen. Informationen müssen ein gewisses Maß an Vollständigkeit aufweisen, um sinnvoll verwendet werden zu können. Oftmals ist die Vollständigkeit sogar Voraussetzung für den Informationscharakter. Eine Kontonummer ist z.B. nutzlos, wenn weder die Bankleitzahl noch der Name der Bank bekannt ist – in diesem Fall wird sie zur bloßen Zahlenkolonne degradiert. Die Information, mit welchem DAX-Stand der gestrige Börsentag beendet wurde, hilft kaum bei der Beantwortung der allmorgendlichen Frage „Was ziehe ich heute an?“. Die Relevanz kann sich durch äußere Einflüsse ändern. So nützt nach einem Flug von Frankfurt nach Boston die Uhrzeit der eigenen Armbanduhr nichts mehr – es sei denn, man kennt den Zeitzonenunterschied unter Berücksichtigung der mitteleuropäischen Sommerzeit und der Daylight Saving Time. Zudem ist die Relevanz abhängig von der Person, die eine Information aufnimmt. Jeder kennt die kreativen Fehlermeldungen, die ein abstürzendes Computerprogramm mitunter produziert. Dem Anwender des Programms sagen die Zahlenkolonnen und Stack Traces üblicherweise nichts – er hat aber die Hoffnung, dass es Experten gibt, denen diese Informationen bei der Problemlösung weiterhelfen. Wer liest schon die Tageszeitung von gestern? Insbesondere der gestrige Wetterbericht ist für die heutige Tagesplanung irrelevant. Wissen ist demnach kein statisches Gut – es muss kontinuierlich an die aktuelle Situation angepasst und vor dem Hintergrund neu eintreffender Informationen neu bewertet werden. Ist der Erwerb von Wissen deshalb eine ausschließlich menschliche Fähigkeit? Forscher der Fachrichtung „Künstliche Intelligenz“ sind versucht, diese Frage mit „Nein“ zu beantworten. Tatsächlich ist es ihnen gelungen, Expertensysteme zu entwickeln, die in der Lage sind, Schlussfolgerungen aus Informationen auf Basis einer Wissenssammlung zu ziehen. Bezogen auf das Ziel, einen „intelligenten“ Computer zu entwickeln, dessen Prozessor ähnlich leistungsfähig ist wie das menschliche Gehirn, nehmen sich diese Erfolge aber eher bescheiden aus. Wie eingangs erwähnt, liegt die Herausforderung moderner Informationssysteme in der effizienten Verwaltung von Informationen und der „intelligenten“ Recherche in dem (heterogenen) Informationspool. Ziel dieser als „Knowledge Management“ bezeichneten Disziplin der Informationstechnologie ist die Unterstützung der Informationsbeschaffung für den aufgabenbezogenen Wissenserwerb.

1 Begriffe

Dazu stellen Knowledge-Management-Systeme unter anderem folgende Funktionen zur Verfügung: ■

Schnittstellen zu verschiedenen Informationssystemen: Datenliefernde Systeme unterscheiden sich in vielen technischen Eigenschaften, beginnend bei der Hardwarearchitektur (PC, Server, Mainframe), über das Betriebssystem, bis hin zur Struktur der Daten. Um dem Benutzer einen transparenten und konsistenten Zugriff auf den Informationspool zu bieten, versteckt ein Knowledge-Management-System die Komplexität der Informationssysteme hinter einer standardisierten Schnittstelle.

■

Umfangreiche und mächtige Suchfunktionen: Jeder, der einmal die „Erweiterte Suche“ einer Internet-Suchmaschine wie z.B. Google (www.google.de) benutzt hat, kennt die vielfältigen Konfigurationsmöglichkeiten, mit denen eine Informationsrecherche konkretisiert und verfeinert werden kann. Hinter solch aufwendig formulierten Suchanfragen steht immer die Hoffnung, die Ergebnismenge der Suche zu verkleinern und qualitativ zu verbessern, um letztendlich schneller in den Besitz der „richtigen“ Informationen zu kommen.

■

Relevanzfilter: Die Relevanz von Informationen ist nur schwer messbar, stellt aber das wichtigste Filterkriterium dar. Suchmaschinen versuchen, die Relevanz über Referenzanalysen, semantische Analyseverfahren oder andere Techniken zu ermitteln.

Wenn auch der Erwerb von Wissen primär ein individueller Prozess ist, so gibt es darüber hinaus in Unternehmen eine kollektive Wissensbasis. Diese setzt sich zusammen aus dem impliziten Wissen der Mitarbeiter, das in deren Köpfen gespeichert ist, und dem niedergeschriebenen oder elektronisch gespeicherten expliziten Wissen. Wenn das Wissen verschiedener Individuen in die Wissensbasis einfließt, kann durch Reflektion und Kombination neues Wissen entstehen. Zudem wird Wissen wiederverwendbar – in wiederkehrenden Situationen kann auf Grundlage dieses Wissens angemessen gehandelt werden. Daraus lassen sich Standards ableiten, die für die Qualitätssicherung eine wesentliche Rolle spielen.

Unternehmenswissen

Die Gesamtheit des kollektiven und des daraus abgeleiteten Wissens bezeichnet man als Unternehmenswissen. Für Unternehmen, die das kontinuierliche Lernen ihrer Mitarbeiter fördern, um diese Wissensbasis auszubauen, wurde der Begriff des lernenden Unternehmens geprägt.

1.3 Informationsmanagement

■ ■ ■

17

Richtig interpretiert und angewandt, hilft das Unternehmenswissen bei der Verbesserung der operationalen Prozesse. Unternehmenswissen ist keine wissenschaftliche Theorie. Ein gutes Beispiel für die praktische Umsetzung ist das betriebliche Vorschlagswesen. Mitarbeiter des Unternehmens können dieses Instrument nutzen, um Verbesserungsvorschläge für Arbeitsabläufe, den Einsatz von Werkzeugen, die Verarbeitung von Materialien oder andere Aspekte ihrer Arbeit einzubringen. Diese Vorschläge können ganz konkret dazu beitragen, dass ein Unternehmen seine (materiellen oder immateriellen) Produkte schneller, kostengünstiger oder qualitativ hochwertiger produziert oder veränderte bzw. neue Produkte auf den Markt bringt. Neben dem betriebswirtschaftlichen Erfolg steigert das betriebliche Vorschlagswesen auch die Zufriedenheit der Mitarbeiter, da sie sich aktiv an der Entwicklung des Unternehmens beteiligen können. Mehr zum Thema Wissensmanagement erfahren Sie z.B. bei Davenport und Prusak (2000) oder Probst et al. (2003). Einen umfassenden Überblick sowie Hinweise auf Veranstaltungen und eine Liste von Publikationen zu diesem Thema finden Sie auf der Webseite der Wissensmanagement-Gesellschaft (www.wissensmanagementgesellschaft.de).

1.3.4 Content Inhalte (engl. Content) sind informationstragende Bestandteile von Dokumenten. Ein Dokument kann ein beliebiger Informationsträger sein: Ein Schriftstück, aber auch eine WWW-Seite, ein Bild oder ein Tonträger. Bei der elektronischen Informationsverarbeitung und Informationsverwaltung werden Dokumente als Daten gespeichert. Die Tatsache, dass Dokumente unterschiedliche Formen und Formate haben können, erschwert deren softwaretechnische Verwaltung. Insbesondere die Recherche in Sammlungen heterogener Dokumente gestaltet sich oft als schwierig, da die Recherche-Software detailliertes Wissen über die Struktur der verschiedenen Dokumenttypen besitzen muss, um die Informationen aus den Dokumenten extrahieren zu können. Softwaresysteme zur Verwaltung von Informationen werden als Content-Management-Systeme bezeichnet. Die Abgrenzung dieser Systeme gegen Unternehmensportale ist Inhalt des Kapitels 2.1.

18

■ ■ ■

1 Begriffe

Abbildung 1.2 stellt die in diesem Abschnitt vorgestellten Begriffe des Informationsmanagements zueinander in Beziehung. repräsentieren

Informationen

Daten

Ausprägungen

Content

Wissen

Abb. 1.2 Begriffe des Informationsmanagements

werden verwertet zu

Nachrichten

1.4 Prozessmanagement Die Verarbeitung von Informationen zu Wissen ist ein individueller Prozess, dessen Dynamik sich auch in den Geschäftsprozessen des Unternehmens widerspiegelt. Diese Prozesse werden von denkenden und wissenden Menschen definiert, ausgestaltet und gelebt. Abhängig von der Art der Aufgaben eines Mitarbeiters sind die Geschäftsprozesse, an deren Ausführung er beteiligt ist, mehr oder weniger strukturiert und standardisiert. Zudem passen sich die meisten Geschäftsprozesse an veränderte Rahmenbedingungen an. Die Verwaltung und Optimierung dieser Prozesse, die das „Leben“ eines Unternehmens ausmachen, bezeichnet man mit dem Begriff „Prozessmanagement“. Insbesondere in wenig strukturierten und individuell ausgestalteten Geschäftsprozessen steckt oft ein beachtliches Optimierungspotenzial, weshalb dem Prozessmanagement ein hoher Stellenwert eingeräumt wird. Was aber genau sind Geschäftsprozesse? Ein Geschäftsprozess ist eine Verfahrensanweisung zur Bearbeitung eines Geschäftsvorfalls. Er setzt sich zusammen aus einer Folge von geordneten, fachlich zusammenhängenden Aktivitäten. Geschäftsprozesse haben einen definierten Anfang, ausgelöst durch ein Ereignis, sowie ein festgelegtes Ende. Zudem ist das Ergebnis des Geschäftsprozesses beschrieben.

1.4 Prozessmanagement

■ ■ ■

19

Der Geschäftsprozess „Immobilienkreditantrag“ z.B. beschreibt die Aktivitäten, die zur Bearbeitung eines Immobilienkredits nötig sind. Der Geschäftsprozess beginnt mit dem Kreditantrag und endet mit einem Darlehensvertrag oder einem ablehnenden Bescheid als Ergebnis. Der Geschäftsprozess ist das Muster, nach dem die Geschäftsvorfälle (d.h. konkrete Anträge) bearbeitet werden.

Medien- und Systembruch

Nicht alle Geschäftsprozesse können geeignet durch Software unterstützt werden, bei einigen gelingt dies nur zum Teil. Man unterscheidet deshalb zwischen vollständig softwaregestützten, teilweise softwaregestützten und nicht softwaregestützten Geschäftsprozessen. Obwohl die Aktivitäten der Geschäftsprozesse einen fachlichen Zusammenhang haben, müssen sie nicht zwingend durchgängig organisiert sein. Neben dem durchaus üblichen Wechsel des Bearbeiters im Verlauf eines Geschäftsprozesses kann es zudem zu Medienbrüchen und Systembrüchen kommen. Wenn ein per Post eingegangener Kreditantrag informationstechnisch erfasst wird, kommt es zu einem Medienbruch: Das Medium ändert sich von Papier zu Bits und Bytes. Der Geschäftsprozess sieht vor, dass der kreditvergabeberechtigte Sachbearbeiter eine SchufaAuskunft einholt. Wenn das System zur Antragserfassung keine direkte Schufa-Schnittstelle besitzt, dann muss der Sachbearbeiter die persönlichen Daten des Antragstellers in das Schufa-Anfragesystem eingeben. Die redundante manuelle Datenerfassung aufgrund des Systemwechsels verzögert die Abarbeitung des Geschäftsvorfalls unnötig. Zudem besteht die Gefahr von fehlerhaften Eingaben, die ebenfalls zu Lasten einer zügigen Bearbeitung des Vorgangs gehen. Ein erfolgreiches Prozessmanagement betrachtet und optimiert die Geschäftsprozesse aus fachlicher Sicht. Die technische Prozessunterstützung soll sich dieser Fachlichkeit unterordnen. Je durchgängiger ein Geschäftsprozess gestaltet ist, d.h. je weniger Medien- und Systembrüche er aufweist, desto sicherer und effektiver lässt sich der Geschäftsprozess ausführen.

1.5 Applikationen und Dienste Die Daten und Nachrichten, aus denen die Informationen gewonnen werden, werden von Computerprogrammen erfasst, verarbeitet, gespeichert und auf Anfrage ausgegeben. Solche Programme lassen sich unterteilen in Applikationen und Dienste.

20

■ ■ ■

1 Begriffe

1.5.1 Applikationen Die Kernprozesse moderner Unternehmen werden über Softwaresysteme abgewickelt. Diese Systeme sind vorwiegend unternehmensintern. Mit zunehmender Vernetzung der Informationssysteme werden aber auch externe Systeme in die Unternehmenskommunikation einbezogen. Zu den internen Systemen gehören z.B. ■

ERP-Systeme (Enterprise Resource Planning),

■

CRM-Systeme (Customer Relationship Management),

■

Dokumentenmanagement-Systeme Systems, DMS),

■

(Web-)Content-Management-Systeme,

■

Büroanwendungen (Office-Systeme), wie z.B. Textverarbeitung und Tabellenkalkulation,

■

Systeme für die Unternehmenskommunikation (z.B. E-Mail),

■

Intranet,

■

andere, oft unternehmensspezifische Systeme (Legacy Systems).

(Document

Management

Zu den externen Systemen gehören z.B. ■

das Internet mit seinen Informationsquellen (Datenbanken, Nachrichten- und Informationsfeeds, Audio- und VideoStreaming),

■

Systeme von Kunden, Lieferanten, Partnern oder anderen Unternehmen und Organisationen.

Applikationen sind alle in einem Unternehmen verwendeten Softwaresysteme (intern oder extern), die der Verwaltung von unternehmerisch genutzten Daten dienen. Sie stellen die technische Basis für alle softwaregestützten Geschäftsprozesse dar. Ein verbreitetes Problem dieser Applikationen ist die redundante Datenhaltung, insbesondere der Stammdaten. Die Folge sind oft Dateninkonsistenzen und Abstimmungsprobleme, wenn nicht explizit eines der Systeme als führendes System bei der Datenpflege deklariert und verwendet wird.

1.5 Applikationen und Dienste

■ ■ ■

21

Ein weiteres Problem ist die strikte Trennung zwischen den Systemen. So ist es oft nicht möglich, automatisch eine Kundennummer aus dem Bestellwesen mit den Daten im Kundeninformationssystem zu assoziieren – der Benutzer wird in der Regel die Kundennummer aus dem einen System auslesen und im zweiten System manuell eingeben müssen, um den zugehörigen Datensatz anzeigen zu lassen. Dieses Vorgehen ist aufwendig und fehlerträchtig. Fachlich durchgängig definierte Geschäftsprozesse werden durch den Systemwechsel technisch bedingt unterbrochen. Noch schwieriger wird es, wenn Daten mit externen Systemen ausgetauscht werden sollen. Wünschenswert ist die Definition von Geschäftsprozessen, die auf der gesamten Informationsbasis eines Unternehmens aufsetzen können.

1.5.2 Dienste Örtliche Unabhängigkeit

Die Grenzen zwischen Applikationen und Diensten (Services) sind fließend. Eine Möglichkeit der Differenzierung besteht in der Lokalisierbarkeit. Applikationen laufen auf einer identifizierbaren Hardware (PC, Server, Mainframe). Dienste hingegen sind im gesamten Netzwerk verfügbar. Die Frage, auf welchem Netzknoten sie laufen, ist nicht immer einfach zu beantworten, da sie in einem verteilten System von Rechnern (Distributed System) implementiert sind. Die Netzwerk-Basisdienste sorgen dafür, dass ein Dienst auf verschiedenen (geeigneten) Knoten im Netzwerk angeboten werden kann. Ausfallsicherungs- und Lastverteilungsstrategien sorgen dafür, dass Dienste immer verfügbar sind. Dabei ist es irrelevant, welcher konkrete Server den Dienst zu einem Zeitpunkt anbietet: Allein die Tatsache, dass der Dienst im Netzwerk verfügbar ist, ist ausschlaggebend. Dienste sind Softwarekomponenten, die ihre Geschäftsfunktionen in verteilten Systemen über eine standardisierte Schnittstelle und spezielle Agenten zur Verfügung stellen. Durch ihre örtliche Ungebundenheit abstrahieren sie von der konkreten technischen Infrastruktur und können eine hohe Verfügbarkeit erreichen. Die Common Object Request Broker Architecture (CORBA) und Web Services zählen zu den dienstorientierten Architekturen. Beide Architekturen definieren Mechanismen zum Beschreiben und zum Auffinden von Diensten sowie ein Standardprotokoll (IIOP für CORBA, SOAP für Web Services) zur Adressierung der Geschäftsfunktionen.

22

■ ■ ■

1 Begriffe

Die in der Definition angesprochene örtliche Ungebundenheit stellt einen wesentlichen Schritt hin zu einer applikationsneutralen Informationsrecherche dar. Wurde bisher eine konkrete Applikation adressiert, so stellt der Benutzer in Zukunft eine fachliche Anfrage an einen „Agenten“, der einen passenden Dienst identifiziert, diesen im Netzwerk lokalisiert, die Anfrage übermittelt und das Ergebnis zurückliefert. Die Agententechnologien sind vergleichsweise neu und befinden sich teilweise noch in der Entwicklungsphase. So muss der Benutzer heute – abhängig vom Anwendungsfall und der „Intelligenz“ des verwendeten Agenten – immer noch ein detailliertes Wissen über das Dienstangebot sowie die fachliche und eventuell auch die technische Schnittstelle der Dienste besitzen. Ähnlich wie bei den Applikationen ist auch bei den Diensten eine systemübergreifende Informationsrecherche und Prozessdefinition noch nicht durchgängig möglich, wenngleich das Agentenkonzept eine Integration verschiedener Dienste zumindest theoretisch ermöglicht. Der Beweis, dass diese Konzepte auch in der Praxis erfolgreich sind, muss jedoch erst noch erbracht werden.

Agenten

1.6 Integration „Enterprise Application Integration“ (EAI) zählt mit Sicherheit zu den Trendbegriffen des Jahrtausendwechsels. EAI fordert die Abkehr von der bedingungslosen Ablösung der Altsysteme, die immer mit einer kosten- und zeitintensiven Neuentwicklung einher ging. Stattdessen konzentriert man sich auf die funktions- und ergebnisorientierte Kombination der vorhandenen Systeme. Ein EAI-System als „Dolmetscher“ zwischen den unterschiedlichen System- und Datenwelten ermöglicht die Nutzung vermeintlicher veralteter Systeme in modernen Softwarearchitekturen. Da der Integrationsaspekt auch für Portale eine entscheidende Rolle spielt, sollen die verschiedenen Ausprägungen von Integration kurz vorgestellt werden. Der Begriff der Integration hat in der Softwaretechnik zwei Dimensionen: Man unterscheidet zum einen zwischen einer Integration von Systemen und einer Integration von (Geschäfts-)Prozessen. Zum anderen kann Integration auf der Benutzungsoberfläche (dem „Frontend“) einer Applikation stattfinden – oder sie geschieht im Verborgenen, im Backend des Systems. Während die Integration für klassische Internet-Portale eine eher untergeordnete Rolle spielt, ist sie für Unternehmensportale von großer Bedeutung (vgl. Abschnitt 5.1). Schließlich lautet eine der

1.6 Integration

Integrationsdimensionen

■ ■ ■

23

Kernforderungen an ein Unternehmensportal „einheitlicher, serviceorientierter Zugriff auf die (Alt-)Anwendungen des Unternehmens“. Deshalb werden die im Folgenden beschriebenen Integrationsarten aus dem Blickwinkel eines Unternehmensportals betrachtet.

1.6.1 Systemintegration und Prozessintegration Die Systemlandschaft eines Unternehmens besteht im Wesentlichen aus einer Ansammlung heterogener Systeme, die entweder hochgradig miteinander vernetzt sind (üblicherweise mit proprietären Schnittstellen) oder isoliert sind („Insellösungen“). Durch Schaffung einheitlicher, standardisierter Schnittstellen (z.B. unter Verwendung des XML-Formats) und Implementierung einer Integrationsschicht (z.B. durch Installation eines EAI-Servers) können Verbindungen zwischen zuvor isolierten Systemen hergestellt werden. Da diese Verbindungen über eine zentrale Vermittlungsschicht laufen, wird die Anzahl an Schnittstellen zwischen den Systemen weitgehend minimiert. Je weniger Schnittstellen ein System aufweist, desto einfacher kann es an veränderte Bedingungen und neue Anforderungen angepasst werden. Ein Unternehmensportal spannt ein Dach über diese Anwendungssysteme und stellt deren Funktionen und Daten in einer gemeinsamen Benutzungsoberfläche zur Verfügung. Damit verschwinden aus Sicht des Portalbenutzers die Systemgrenzen. Wie bereits im Abschnitt über Prozessmanagement erwähnt, kommt es in vielen technisch unterstützten Geschäftsprozessen zu Systembrüchen, weil die Summe der für den Geschäftsprozess benötigten fachlichen Funktionen nicht von einem einzigen Softwaresystem abgedeckt wird. Hier ist eine Integration gefordert, die eine durchgängige Bearbeitung des Geschäftsprozesses erlaubt. Diese Integration kann an der Benutzungsoberfläche (Frontend) oder in den datenliefernden Systemen (Backend) stattfinden – das ist das Thema des folgenden Abschnitts. Im Abschnitt 2.2 wird dann die hier vorgestellte Enterprise Application Integration ausführlicher betrachtet und gegen die Aufgaben eines Portalsystems abgegrenzt. Abbildung 1.3 stellt die über eine Integrationsschicht realisierte Prozess- und Systemintegration dar.

24

■ ■ ■

1 Begriffe

Abb. 1.3 Prozess- und Systemintegration

Personalwesen

Beschaffung Kundendienst

Integrationsschicht

ERP

CRM

Dateiserver

Content Mgmt.

E-Mail

Legacy

1.6.2 Frontend- und Backend-Integration Der offensichtlichste Integrationsaspekt eines Unternehmensportals ist die Integration an der Benutzungsoberfläche, dem Frontend: Verschiedene Informationssysteme werden gemeinsam in einer Portalseite, meistens in einem Webbrowser, dargestellt. Auch wenn diese technisch nach wie vor getrennt arbeiten, so gewinnt der Portalbenutzer doch den Eindruck, dass diese Systeme, für die er bisher mehrere Programme auf seinem PC starten musste und die alle in einem eigenen Fenster liefen, jetzt unter dem Dach des Portals vereint sind. Dieser Eindruck der Harmonisierung und Integration wird verstärkt durch die Beschränkung auf die Interaktionselemente einer Webanwendung, der alle Portalanwendungen unterliegen (wenn sie in einem Webbrowser ablaufen). Aufgrund der dadurch reduzierten Möglichkeiten in der Gestaltung der Benutzungsoberfläche nähern sich diese zwangsläufig einander an. Weniger sichtbar, dafür aber umso mächtiger, sind die Integrationsmöglichkeiten im Backend. Dies ist die Domäne der EAISysteme, die unterschiedlichen Anwendungen zum gegenseitigen Austausch von Informationen verhelfen. Der Portalbenutzer bekommt davon nicht unbedingt etwas mit – er profitiert aber von Portalanwendungen, deren Funktionsumfang und Informationshaushalt die Summe mehrerer Altanwendungen ist. Eine Besonderheit von Portalsystemen ist die Kombination von Frontend- und Backend-Integration. Bei dieser Art der Integration löst eine Benutzeraktion im Portal die Kommunikation und den Informationsaustausch zwischen verschiedenen Backend-Anwendungen aus. So können in einem Kundeninformationsportal z.B. nach der Eingabe der Kundennummer automatisch die Kunden-

1.6 Integration

■ ■ ■

25

stammdaten, die letzten Bestellungen sowie die Außenstände des Kunden aus den jeweiligen Systemen abgefragt und in verschiedenen Portalanwendungen dargestellt werden. Leider wurde dieser Integrationstyp bisher noch nicht standardisiert, weshalb jeder Portalhersteller seine eigene Implementierung anbietet (vgl. Abschnitt 5.1.5). Bei SAP heißt diese Technologie „Drag&Relate“, bei IBM wird sie „Click2Action“ genannt. Abbildung 1.4 stellt die drei Ebenen der Integration (F = Frontend, B = Backend, F+B = kombinierte Integration) aus der Sicht eines Portals dar. Abb. 1.4 Ebenen der Integration

Portal

F F +B

B

1.7 Miteinanderarbeit (Collaboration) Dimensionen von Beziehungen

26

■ ■ ■

In seinem privaten wie auch im beruflichen Dasein ist kaum ein Individuum auf sich allein gestellt; hier wie dort ergeben sich Beziehungen zu anderen Individuen. Diese Beziehungen können von kurzer Dauer (der Smalltalk auf einer Party, ein kurzes Gespräch am Kaffeeautomaten) oder langfristig angelegt sein (Lebensgemeinschaft, geschäftliche Partnerschaft bzw. Kundenbeziehung) und die beteiligten Individuen einmalig oder wiederholt binden. Die Beziehungen unterscheiden sich zudem nach dem Grad ihrer Formalität. Dienen die Beziehungen der gemeinsamen Erbringung einer Leistung, so sprechen wir von Miteinanderarbeit (engl. Collaboration). Zu den formalen Formen der Miteinanderarbeit zählen Besprechungen (neudeutsch: Meetings), Telefongespräche, E-Mail-

1 Begriffe

Verkehr und der Austausch von (gedruckten oder elektronischen) Dokumenten. Doch gerade der nicht-formale Informationsaustausch hat einen enormen Einfluss auf den Aufbau des Unternehmenswissens: Das kurze Gespräch zwischen Kollegen auf dem Flur oder in der Kantine, die spontane Diskussion als Reaktion auf eine in den Raum hinein gestellte Frage – hier werden Informationen ausgetauscht und in der Folge Wissen aufgebaut, das sich nur schwer fassen und in explizites Unternehmenswissen umwandeln lässt. Dieses Wissen hat zudem den Vorteil, dass es redundant in den Köpfen mehrerer Individuen gespeichert ist. Dieser vielbeschworene „Know-how-Transfer“ ist z.B. nötig, um auch in der Urlaubszeit den Geschäftbetrieb dank funktionierender Vertreterregelungen aufrecht erhalten zu können. Wenn Wissen in mehreren Köpfen vorhanden ist, dann führt die Personalfluktuation nicht zwangsläufig zu einer Abwanderung eines Teils des Unternehmenswissens. Miteinanderarbeit funktioniert bekanntlich nicht nur zwischen einzelnen Individuen. Projektteams, Abteilungen, Gremien oder Interessengruppen bilden Gemeinschaften, die sich zum Zweck einer aufgabenbezogenen Miteinanderarbeit zusammengefunden haben. Diese Gemeinschaften weisen in der Regel eine innere Struktur auf, die sich in den verschiedenen Rollen der Mitglieder ausdrückt. Nicht alle Gemeinschaften sind so formal – auch beim gemeinsamen Mittagessen in der Kantine bilden sich (kurzlebige) Gemeinschaften. Sie sind meistens dynamisch: Mitglieder verlassen die Gemeinschaft, neue Mitglieder kommen dazu – die Gemeinschaft mit ihren Aufgaben und Zielen aber bleibt. Miteinanderarbeit wird um so schwieriger, je größer die räumliche und zeitliche Distanz zwischen den Mitgliedern einer Gemeinschaft ist. Weltweit operierende Unternehmen haben nicht selten Projektteams, die an verschiedenen Orten in unterschiedlichen Zeitzonen arbeiten. Die Miteinanderarbeit beschränkt sich in solchen Fällen auf einige der formalen Formen. Telefongespräche stellen dabei die einfachste Form der direkten Kommunikation dar. Meetings lassen sich mit einigem Aufwand als Videokonferenz realisieren, gegebenenfalls auch als Chat, eine synchrone, schriftliche Form der elektronischen Kommunikation. Die zeitliche Distanz führt aber häufig dazu, dass eine asynchrone Kommunikation, z.B. per E-Mail, bevorzugt genutzt wird. Was fehlt, sind die Gelegenheiten zum informellen und spontanen Austausch – es gibt keinen gemeinsamen Kaffeeautomaten, und man kann dem tausend Kilometer entfernt arbeitenden Kollegen nicht bei der Lösung eines Problems helfen, indem man ihm über die Schulter schaut. Hier können Portale helfen, indem sie die verbliebenen Kommunikationsformen möglichst optimal zugänglich und nutzbar machen. Außerdem helfen Portale bei

1.7 Miteinanderarbeit (Collaboration)

■ ■ ■

27

der Erschließung des Wissens, das im informellen Informationsaustausch entsteht, und machen dieses Wissen für alle zugänglich.

1.8 Portal Die Historie der Portale

Der Begriff „Portal“ taucht in seiner informationstechnologischen Bedeutung erstmals Ende der 90er Jahre des vergangenen Jahrhunderts auf. Zu dieser Zeit wuchs das World Wide Web (WWW) unkontrolliert und mit enormer Geschwindigkeit. Dessen Nutzer suchten Hilfe bei der Navigation durch das Netz und bei der Suche nach den gewünschten Informationen. Aus dem Wunsch, die unstrukturierte Informationsflut des Internet zu filtern und in geordnete Bahnen zu lenken, entstand Yahoo! (www.yahoo.com). Vor zehn Jahren, am 2. März 1995, wurde aus dem Studentenprojekt eine Firma, deren Börsengang (1996) den Dotcom-Hype weiter beschleunigte (vgl. Borchers 2005). Zunächst war Yahoo! ein Link-Katalog, in dem die Inhalte des WWW strukturiert und nach Themen sortiert präsentiert wurden – eine Art „Gelbe Seiten“ des WWW. Später lieferte eine Suchfunktion eine Liste von Web-Links zu beliebigen Suchbegriffen. Weitere Suchdienste, wie z.B. Altavista, folgten diesem Beispiel. Zugleich erkannten die Hersteller von Webbrowsern (allen voran Microsoft und Netscape) sowie die Anbieter von Online-Diensten (z.B. AOL oder CompuServe), dass die WWW-Nutzer die Webseiten dieser Firmen als Ausgangspunkt ihrer Reise durch das Web nutzten. Dementsprechend wurden diese Webseiten zu Informations- und Kommunikationsportalen ausgebaut, indem das Angebot um Funktionen wie z.B. E-Mail, Shopping, Diskussionen und Chat erweitert wurde. Eine weitere bahnbrechende Funktionalität war (und ist) die Personalisierung der Portale: Der Benutzer kann aus dem Angebot an Informationen und Diensten seine persönliche Auswahl treffen und diese speichern, so dass beim nächsten Aufruf des Portals diese persönliche Konfiguration voreingestellt ist. Ein Portal ist ein zentraler und persönlicher Einstieg (Single Point of Access) in die Informationswelt des Internet oder Intranet, von dem aus Verbindungen zu den relevanten Informationen und Diensten hergestellt werden können. Die Relevanz von Informationen und Diensten ist schwer messbar, stellt aber das wichtigste Filterkriterium für die Informationsrecherche in Portalen dar. Portalsysteme versuchen, diese Relevanz über

28

■ ■ ■

1 Begriffe

Link-Referenzanalysen, semantische Analyseverfahren oder andere Techniken zu ermitteln. Es gibt unterschiedliche wissenschaftliche Ansätze, um Portale nach verschiedenen Kriterien zu typisieren und zu kategorisieren. Beispiele für solche Kriterien sind: ■

Fokus (horizontal – vertikal),

■

Nutzerkreis (offen – geschlossen),

■

Rollen der Benutzer (Business-to-Consumer – Business-toBusiness – Business-to-Employee),

■

Netzwerktechnische Erreichbarkeit (Internet – Intranet – Extranet).

Kategorisierung von Portalen

Unserer Meinung nach sind die beiden erstgenannten Kriterien (Nutzerkreis und Fokus) für Unternehmensportale am wichtigsten, weshalb wir uns in der Portalkategorisierung auf diese beiden Kriterien beschränken möchten. Wir werden später die Unternehmensportale noch einmal nach ihrem Anwendungsbereich unterscheiden. Nun aber zunächst zur allgemeinen Kategorisierung von Portalen.

1.8.1 Horizontale und vertikale Portale Ein horizontales Portal fungiert als Plattform, die diverse Applikationen zur Verfügung stellt und so ein breit gefächertes Informationsangebot präsentiert. Ein horizontales Portal adressiert in der Regel keine bestimmte Zielgruppe. Es ist also eine Art „Gemischtwarenladen“, in dem eine breite Informationspalette, aber in den einzelnen Kategorien nur ein grober Überblick angeboten werden. Beispiele für horizontale Portale sind Yahoo!, web.de oder T-Online.de. Ein vertikales Portal (oft als „Vortal“ bezeichnet) bietet eine Auswahl von Funktionen, die bestimmte fachliche und technische Anforderungen adressieren. Der Funktionsumfang eines vertikalen Portals orientiert sich an speziellen Wertschöpfungsprozessen oder Anwendungsfällen und ist auf bestimmte Interessengruppen, Branchen oder Themen spezialisiert. Ein vertikales Portal kann z.B. der Abwicklung von Projekten in einem Unternehmen dienen, die auf verschiedene Niederlassungen

1.8 Portal

■ ■ ■

29

verteilt sind. Die Projektmitarbeiter finden in einem solchen Portal eine räumlich und zeitlich unabhängige Kommunikationsplattform für die Miteinanderarbeit vor. Ist die Struktur eines Portals zu sehr vertikal ausgerichtet, dann besteht die Gefahr, einen zu engen Blickwinkel einzunehmen. Das Portal läuft Gefahr, zu einer Insellösung zu werden, die sich nicht gut mit anderen Informationssystemen integrieren lässt. Ist die Struktur wiederum zu horizontal angelegt, dann ist ein erheblicher Implementierungsaufwand notwendig, um von Beginn an Portalanwendungen für das breit gefächerte Informations- und Dienstangebot zu entwickeln. Ein schneller Return on Investment (ROI) ist dann kaum zu erreichen.

1.8.2 Offene und geschlossene Portale Offene Portale sind grundsätzlich für jeden Benutzer über das Internet oder das Intranet zugänglich. Das schließt nicht aus, dass sich der Benutzer bei einem solchen Portal registrieren und in der Folge diesem gegenüber authentifizieren muss. Oft wird erst dadurch eine dauerhafte und browserunabhängige Personalisierung des Portalangebots möglich. „Offen“ bedeutet lediglich, dass die Nutzung eines solchen Portals nicht auf bestimmte Gruppen von Benutzern beschränkt ist. Ein geschlossenes Portal steht nur einer definierten Benutzergruppe im Internet oder Intranet zur Verfügung. Dieser Benutzergruppe können die Mitarbeiter, aber auch Kunden, Lieferanten oder Partner eines Unternehmens angehören. Um Zugang zu einem geschlossenen Portal zu erlangen, müssen sich die Benutzer immer authentifizieren.

1.8.3 Kategorisierungsmatrix In Anlehnung an die „magischen Quadranten“ von Gartner (vgl. Abschnitt 8.4), mit denen Softwareprodukte kategorisiert werden, haben wir eine Kategorisierungsmatrix für Portale entwickelt, die in Abb. 1.5 dargestellt ist. Die Matrix verwendet die aus unserer Sicht

30

■ ■ ■

1 Begriffe

horizontal

Abb. 1.5 Kategorisierung von Portalen Prozessorientiertes Unternehmensportal

Konsumentenportal

vertikal

Fokus

relevanten Kriterien (Fokus und Nutzerkreis, vgl. Abschnitt 1.8). Jeder Kriterienkombination ist ein Portaltyp zugeordnet.

Anwendungsorientiertes Unternehmensportal

Themenportal

geschlossen

offen Nutzerkreis

Prozessorientierte Unternehmensportale stellen einer geschlossenen Benutzergruppe die (automatisierbaren) Geschäftsprozesse des Unternehmens in einer einheitlichen Ablaufumgebung zur Verfügung. Prozessorientierte Unternehmensportale sind das erklärte Ziel vieler Portalprojekte. Je komplexer allerdings die Geschäftsprozesse eines Unternehmens sind, desto schwieriger ist die Integration. Oft sind die Anwendungen, die von dem Geschäftsprozess genutzt werden, sehr komplex. Das erschwert die Analyse und Implementierung der Integration. Manchmal müssen viele verschiedene Anwendungen integriert werden, um die gewünschte Durchgängigkeit der Prozesse ohne Medien- und Systembrüche zu erreichen. Demgegenüber steht die Forderung nach der Wirtschaftlichkeit der Portalimplementierung – die Kosten sollen so schnell wie möglich durch einen Nutzenzuwachs kompensiert werden. Die Erkenntnis, dass ein schneller ROI für Portale nur dann erreicht werden kann, wenn der Funktionsumfang zunächst beschränkt wird und später sukzessive erweitert werden kann, hat sich mittlerweile durchgesetzt. Und so startet manch ein prozessorientiertes Unternehmensportal zunächst als anwendungsorientiertes Unternehmensportal.

1.8 Portal

Prozessorientierte Unternehmensportale

■ ■ ■

31

Ein anwendungsorientiertes Unternehmensportal fasst ausgewählte Unternehmensanwendungen und deren Datenbestände in der Benutzungsoberfläche des Portals zusammen. Der Grad der Integration reicht von der Zusammenführung der Präsentation bis hin zur kombinierten Frontend- und Backend-Integration. Anwendungsorientierte Unternehmensportale Konsumentenportale und Themenportale

Natürlich werden auch in einem anwendungsorientierten Unternehmensportal Geschäftsprozesse unterstützt. Da diese aber nicht notwendigerweise vollständig und durchgängig abgebildet sind, liegt der Schwerpunkt eindeutig auf den integrierten Anwendungen. Zu den Konsumentenportalen werden die bereits bei der Portalkategorisierung erwähnten „Gemischtwarenläden“ des Internets gezählt. AOL zählt zu den prominenten Vertretern dieser Gattung von Portalen. Daneben gibt es aber auch themenbezogene, offene Portale. Diese bieten viele der Funktionen ihrer horizontalen Verwandten, darunter Suchdienste, Nachrichtenticker und Foren, beschränken sich aber auf ein Thema. The Motley Fool (www.fool.com; Geldanlage) oder Swinging Hamburg (www.hamburg-jazz.de) sind Beispiele für solche Vortale.

1.9 Unternehmensportale Wie aus der Kategorisierungsmatrix ersichtlich ist, sind Unternehmensportale zunächst einmal geschlossene Portale. Für sie stellt das Internet nur eine von vielen Informationsquellen dar, die es für den Anwender zu erschließen gilt. Ein Unternehmensportal ist ein geschlossenes Portal, das den Anwendern einen individuellen, personalisierbaren Zugang zu allen relevanten Inhalten bietet, um alle Aufgaben bequem und schnell erledigen zu können. Dieser Zugang muss jederzeit und überall auf sicherem Weg erreichbar sein. Zu den Anwendern eines Unternehmensportals zählen die Mitarbeiter des Unternehmens, aber auch die Kunden, Lieferanten oder Partner. Den Benutzern werden in einem Unternehmensportal rollenspezifisch ausgewählte Inhalte individuell präsentiert. Diese kontextbezogene Vorauswahl der relevanten Informationen beugt dem Problem der Informationsüberflutung vor. Als browserbasiertes System lässt sich ein Unternehmensportal leicht unternehmensweit einführen. Die Browserumgebung ist den meisten Anwendern vertraut und trägt

32

■ ■ ■

1 Begriffe

somit ihren Teil zur Akzeptanz des Systems bei. Außerdem erlaubt die Verwendung der standardisierten Internet-Technologien die unkomplizierte Anbindung anderer, mobiler Endgeräte. Ein umfangreiches, zentrales Sicherheits- und Berechtigungskonzept muss dabei die sensiblen Unternehmensdaten vor dem unberechtigten Zugriff durch Dritte schützen und den berechtigten Benutzern den Zugriff auf genau die Daten erlauben, die sie sondieren und modifizieren dürfen. Schließlich erlaubt das Prinzip des Single Sign-On ein angenehmes Arbeiten, da sich die Benutzer nicht mehr die Passwörter für alle genutzten Systeme merken müssen: Eine Anmeldung am Portal genügt, um alle angeschlossenen Systeme im Zugriff zu haben. All diese Systeme sind in das Portal integriert und bringen ihre Daten in das Informationsangebot des Portals ein. Diese Befreiung vom notwendigen Wissen über die Datenquelle ermöglicht den Übergang vom systembezogenen Denken hin zum prozess- und lösungsorientierten Denken und trägt somit wesentlich zur Qualität und Vorhersagbarkeit der aus den Informationen abgeleiteten Entscheidungen bei.

1.9.1 Zielgruppen Mit dem soeben erweiterten Unternehmensbegriff ist die Bandbreite der Zielgruppen von Unternehmensportalen recht groß. Sie reicht vom erwähnten Projektteam bis hin zur Gesamtheit der Bürger eines Staates. Jedoch haben diese Gruppen gemeinsame Interessen, die von vielen Unternehmensportalen adressiert werden. Zu diesen Interessen gehören ■

der Wunsch nach einem zentralen und einheitlich strukturierten Zugangspunkt zur Informationslandschaft und den Geschäftsprozessen eines Unternehmens,

■

die Möglichkeit, die Sicht auf diese Informationen und Prozesse nach den persönlichen Anforderungen zu gestalten,

■

die schnelle, effiziente und sichere Miteinanderarbeit von Mitarbeitern des Unternehmens über räumliche und zeitliche Grenzen (und mitunter auch über Unternehmensgrenzen) hinweg,

■

der Aufbau eines Wissensspeichers, in dem aus individuellem Wissen Unternehmenswissen entsteht (lernendes Unternehmen).

1.9 Unternehmensportale

■ ■ ■

33

Die genannten Interessen finden sich in Unternehmensportalen in Form verschiedener Anwendungsschwerpunkte wieder. Diese sollen im Folgenden vorgestellt werden.

1.9.2 Anwendungsschwerpunkte Ähnlich wie bereits bei den Portalen, so können auch bei Unternehmensportalen verschiedene Ausprägungen unterschieden werden. Abbildung 1.6 zeigt die vier wesentlichen Anwendungsschwerpunkte. Es wird kaum ein Portalprodukt geben, das nur einen dieser Schwerpunkte abdeckt, also z.B. ein reinrassiges Decision Portal ist. Allerdings haben die meisten Produkte einen Schwerpunkt, der sich mit einem (oder mehreren) der dargestellten Anwendungsschwerpunkte deckt. Bei der Planung eines Portalprojekts kann diese Kategorisierung bei der Softwareauswahl helfen (vgl. Abschnitt 8.3). Informationen publizieren

Operational Portal

Anwendungen bereitstellen

34

■ ■ ■

1 Begriffe

Miteinanderarbeit ermöglichen

Unternehmensportal

Collaborative Portal

Decision Portal

Publishing Portal Wissen extrahieren / Informationen aufbereiten

Abb. 1.6 Anwendungsschwerpunkte von Unternehmensportalen

Die Publishing Portals, eine auch als (Enterprise) Information Portals bezeichnete Gattung der Unternehmensportale, dienen in erster Linie der zielgerichteten Erschließung der Informationslandschaft eines Unternehmens und der einheitlichen Präsentation der Informationen. Auf die Heterogenität dieser Informationslandschaft und die damit verbundenen Herausforderungen für die Informationsrecherche wurde in diesem Kapitel bereits eingegangen. Es geht im Wesentlichen darum, die richtigen, d.h. die für die gegebene Situation oder Aufgabe relevanten Informationen zu beschaffen. Dabei müssen etwaige Zugriffsbeschränkungen auf Daten gewahrt bleiben. Das Portal abstrahiert aus Sicht des Benutzers von der Komplexität der Informationssysteme, in denen die Daten gespeichert sind sowie vom Format, in dem die Daten vorliegen. Neben den unternehmensinternen Daten können auch externe Quellen in die Informationsrecherche mit einbezogen werden.

Publishing Portal

Die der Miteinanderarbeit dienenden Unternehmensportale (Enterprise Collaboration Portals) legen den Schwerpunkt auf Funktionen, wie sie in Workgroup-Systemen (Groupware) zu finden sind. Wie schon im Abschnitt 1.7 beschrieben, versuchen diese Portale, die Probleme der Miteinanderarbeit über räumliche und zeitliche Distanzen hinweg zu adressieren, um auch den verteilt agierenden Gemeinschaften ein effektives Arbeiten zu ermöglichen. Zu den typischen Funktionen dieser Systeme gehören

Collaborative Portal

■

Asynchrone Kommunikationsmittel (E-Mail, Newsgroups, Foren),

■

Synchrone Chat),

■

Virtuelle (Projekt-)Räume mit Möglichkeiten der Dateiablage, projektbezogener Rollen- und Rechtevergabe und Projektplanungs-Funktionen,

■

Terminverwaltung mit Besprechungsplanung,

■

Adressverwaltung,

■

Datensynchronisierung in verteilten Systemen.

Kommunikationsmittel

(Telefonie-Funktionen,

Operational Portals werden auch (Enterprise) Application Portals genannt. Sie sind auf die Unterstützung und Integration ausgewählter Unternehmensanwendungen ausgerichtet und somit vertikaler Natur. Der Vorteil für die Benutzer eines solchen Portals besteht im zentralen, einheitlichen Zugang zu den benötigten Systemen. Die Schlüsseltechnologie dieser Portale ist das Single Sign-On. Damit

1.9 Unternehmensportale

Operational Portal

■ ■ ■

35

sind alle über das Unternehmensportal verfügbaren Systeme und Applikationen (in den durch die Rechte des Benutzers gegebenen Grenzen) ohne weitere Authentifizierungen zugreifbar, sobald sich der Benutzer am Unternehmensportal angemeldet hat. Dabei ist für den Benutzer nicht (notwendigerweise) ersichtlich, ob die ihm präsentierten Daten aus einem ERP-System, einem Content-Management-System oder gar von externen Dienstleistern kommen: Für ihn bildet das Portal die zentrale Schnittstelle zu allen relevanten Unternehmensdaten, die im Idealfall unter einer einheitlichen Benutzungsoberfläche zusammengefasst sind. Decision Portal

Die Domäne der Business-Intelligence-Systeme stand Pate bei der Entwicklung der Decision Portals. In der Literatur findet sich daher auch der Begriff (Enterprise) Knowledge Portals als Bezeichnung für diese Portalgattung. Sie nimmt die Charakteristika der besprochenen Anwendungsschwerpunkte auf und kombiniert sie zu einem Werkzeug der Verarbeitung und Verwaltung von Wissen. Damit dienen diese Portale der strategischen Entscheidungsfindung. Sie ermöglichen die Analyse der Unternehmensdaten und unterstützen bei der Prognose der Unternehmensentwicklung, basierend auf den erwähnten Analysen. Zu diesem Zweck bedienen sich Decision Portals der strategischen Systeme des Unternehmens (Data Warehouses, Statistikprogramme, Spezialanwendungen für Controlling). Diese entfalten ihr Potenzial in Kombination mit Konzepten zur Informationsrecherche sowie dem Zugriff auf die Systeme zur Unternehmenskommunikation. Zusammengefasst, gefiltert und verdichtet werden die Informationen dann einheitlich im Portal präsentiert. Bereits diese kurze Beschreibung lässt erahnen, dass der Aufbau eines Decision Portal-Systems einige Herausforderungen bietet. Neben der notwendigen Kombination komplexer Softwaresysteme wirft die fachliche Konzeption eines solchen Portals viele Fragen auf: Welche Systeme sollen die Datenbasis darstellen? Sind die Daten dieser Systeme miteinander verträglich? Haben sie ein vergleichbares Abstraktionsniveau? Gibt es Beziehungen zwischen den verschiedenen Datenmodellen? Wie flexibel soll der Zugriff auf die Datenbasis gestaltet werden (offenes, „intelligentes“ Abfragesystem oder vorgefertigte Reports)? Wie bei allen Unternehmensportalen, so gilt auch hier der Grundsatz: Think big – start small. Mit anderen Worten: Mit der Vision des allumfassenden Wissens-Systems im Kopf beginnt man mit der Implementierung grundlegender Funktionalitäten, die dann sukzessive in überschaubaren Schritten weiter ausgebaut werden.

36

■ ■ ■

1 Begriffe

1.9.3 Einsatzbereiche Die Gründe für den Einsatz eines (Unternehmens-)Portals wurden an verschiedenen Stellen in diesem Kapitel erwähnt und sollen hier noch einmal zusammengefasst werden. Portale ■

bringen Ordnung in die Informationslandschaft, indem sie einen zentralen, einheitlichen und systemunabhängigen Zugang zu den Informationen und Diensten des Unternehmens schaffen,

■

sorgen für Orientierung in der stetig wachsenden Flut an Informationen, indem sie eine kontextabhängige Informationsrecherche anbieten und die Informationen nach ihrer Relevanz filtern, sortieren und gruppieren,

■

abstrahieren von der Vielgestaltigkeit der Unternehmensdaten; sie lenken den Blick des Benutzers weg von der Technik der Systeme und hin zu der Nutzen stiftenden Fachlichkeit,

■

sorgen für eine Durchgängigkeit der Geschäftsprozesse durch Integration der am Prozess beteiligten Informationssysteme,

■

erlauben die Miteinanderarbeit von räumlich verteilten und zeitlich versetzt arbeitenden Gemeinschaften.

Hinter all diesen Möglichkeiten stehen aber höhere Unternehmensziele. Im Wesentlichen gilt das Interesse der Produktivitätssteigerung, der Automatisierung, Optimierung und damit der Beschleunigung von Geschäftsprozessen, der Qualitätsverbesserung sowie der Steigerung der Mitarbeitermotivation. Doch auch diese Ziele sind nur Mittel zum Zweck – letztendlich geht es darum, die Rentabilität des Unternehmens zu steigern. Das haben viele Unternehmen erkannt, nicht zuletzt vor dem Hintergrund einer schwierigen wirtschaftlichen Lage und dem aufgrund der Globalisierung zunehmenden Konkurrenzdruck, und sie setzten ihre Hoffnung in Unternehmensportale. Diese müssen aber möglichst schnell einen ROI erreichen, um diesem Ziel dienen zu können. Auch Unternehmensportale sind keine Allheilmittel, sondern komplexe Systeme, bestehend aus einer Kombination von erprobten Technologien. Und wie bei jeder Technologie bestimmt der richtige oder falsche Einsatz über den Erfolg oder Misserfolg des Systems.

1.9 Unternehmensportale

■ ■ ■

37

2 Abgrenzung

Dieses Kapitel grenzt die Fähigkeiten und Aufgaben von Portalsystemen gegen Content-Management- und Enterprise-ApplicationIntegration (EAI)-Systeme ab. Es werden Szenarien entwickelt und Möglichkeiten aufgezeigt, wie Inhalte aus Content-ManagementSystemen sinnvoll in ein Portal integriert werden können. Ein kurzer Überblick über die verschiedenen Integrationsszenarien mit Hilfe von EAI-Systemen schließt das Kapitel ab.

Kurz gefasst

2.1 Content-Management-Systeme Die spezialisierten Hersteller für Dokumenten- und Web-ContentManagement-Systeme haben sich in den letzten Jahren zu Allroundern entwickelt, die Enterprise-Content-Management-Systeme anbieten. Diese können mit strukturierten und halbstrukturierten Dokumenten wie Berichten, Listen und Formularen optimal umgehen, um sie unter anderem in Archivierungssystemen vorzuhalten und ihre Verwendung über ein Workflow-Management zu steuern. Die Indizierung von Daten und leistungsfähige Suchmechanismen gehören darüber hinaus zu den Kernkompetenzen der Enterprise-ContentManagement-Systeme. Portale ergänzen diese ContentManagement-Aspekte um die Fähigkeiten, Geschäftsprozesse durchgängig abzubilden und zu steuern sowie Inhalte anwendungsübergreifend zu integrieren. Aus dieser evolutionären Entwicklung heraus stellt sich für viele Anwender die Frage nach der weiteren Daseinsberechtigung von spezialisierten Content-Management-Systemen. Gerade Unternehmen, die bereits mit hohem Aufwand Systeme zur Verwaltung ihrer Webseiteninhalte und Unternehmensdaten eingeführt haben, sehen diese Investitionen durch die Einführung eines Portals gefährdet und befürchten hohe Migrationskosten.

2.1 Content-Management-Systeme

■ ■ ■

39

2.1.1 Content-Management-Systeme und Portale im Vergleich

Schwerpunkte von Portalsystemen

Schwerpunkte von ContentManagementSystemen

40

■ ■ ■

Eine scharfe Abgrenzung der Aufgaben eines Portals und eines Content-Management-Systems kann nicht allgemeingültig getroffen werden. Welche Aufgaben von welchem System übernommen werden, lässt sich nur bei der Betrachtung konkreter Systeme exakt feststellen. Portale bieten umfangreiche Funktionen an, um Inhalte (Daten und Informationen) effektiv erstellen und verwalten zu können. Inhalte lassen sich über intuitive Redaktionsoberflächen erfassen und werden getrennt von Layoutinformationen verwaltet. Diese Trennung zwischen Inhalt und Design ist die Voraussetzung für den Aufbau eines multimodalen, über verschiedene Kommunikationskanäle zugreifbaren Portals (vgl. Abschnitt 4.8). Viele Portalsysteme bieten außerdem grafische Editoren zum Generieren von Portlets an. Als Portlets werden die Applikationen eines Portals bezeichnet (vgl. Abschnitt 7.5.1). Über diese kann der Zugriff auf externe Anwendungen realisiert und Inhalte personalisiert auf der Oberfläche präsentiert werden. Für ein Portal als zentrale personalisierte Oberfläche, unter der verschiedene Anwendungen integriert werden, ist die ContentManagement-Komponente nur ein potenzieller Inhaltslieferant. Der Fokus liegt auf der Integration von Content-Quellen zur Unterstützung durchgängiger Geschäftsprozesse. Dazu werden Daten aus verschiedenen Quellen miteinander verwoben und personalisiert präsentiert. Anders als Portale, die Content im Sinne der Unterstützung von Geschäftsprozessen betrachten, liegt der Fokus bei ContentManagement-Systemen auf den redaktionellen Ansprüchen an die Erstellung und Verwaltung strukturierter Daten. ContentManagement-Systeme verfügen in der Regel über ausgereifte WYSIWYG-Editoren (What You See Is What You Get – grafische Editoren) mit denen auch Autoren ohne technisches Vorwissen einfach Inhalte erfassen, verwalten und archivieren können. Rechteund Rollenkonzepte in Content-Management-Systemen beziehen sich zumeist auf die Benutzer- und die Dokumentenebene. Über Workflow-Mechanismen lassen sich unterschiedliche Rollen im Redaktionsprozess und somit mehrere Bearbeitungs- und Freigabestufen abbilden. Content Management Systeme unterstützen außerdem den redaktionellen Prozess durch Versionskontrollen, Sperren, Benachrichtigungen und die Definition von Genehmigungsinstanzen.

2 Abgrenzung

Content-Management-Systeme bieten außerdem Mechanismen zur automatischen zeitgesteuerten Publikation von Inhalten, zur Historisierung auf Dokumentenebene sowie zur Archivierung an. Auch Content-Management-Systeme verwalten Daten unabhängig von ihrem Präsentationsdesign. Darüber hinaus verfügen ContentManagement-Systeme über zahlreiche Funktionen zur Personalisierung von Online-Inhalten, zur Indizierung und Suche von Content und zum Austausch von Inhalten zwischen Webseiten (Content Syndication).

eb

nt Management Sy nte o st C e Workflowkomponente

m

W

Content Syndication bezeichnet den Austausch und Handel von Inhalten für das Publizieren im Web. Werden beim Content Sharing Inhalte getauscht, tritt beim Content Syndication ein Content Provider als Händler von Content auf.

eShop

Syndication

Staging Benutzerverwaltung

Zugriffsverwaltung

Contentverwaltung

Templateverwaltung

Abb. 2.1 Aufgaben und Funktionen eines Web-ContentManagementSystems

Import-Schnittstelle

Versionierung

Personalisierung

Export-Schnittstelle

Abbildung 2.1 illustriert die Komplexität von ContentManagement-Systemen. Diese orientieren sich an den Prozessen einer klassischen Redaktion und übernehmen bzw. unterstützen diese zum Teil automatisiert.

2.1.2 Content Management in Portalen Wie dargestellt, haben Portale und Content-Management-Systeme im Hinblick auf die Verwaltung von Inhalten unterschiedliche Schwerpunkte. Dies beantwortet auch die Frage nach der weiteren Daseinsberechtigung von Content-Management-Systemen: Portale

2.1 Content-Management-Systeme

■ ■ ■

41

Integrationsszenarien

ContentManagementSysteme als Contentprovider

42

■ ■ ■

und Content-Management-Systeme dienen einem unterschiedlichen Zweck. Die grundsätzliche Entscheidung für das eine oder andere Werkzeug muss sich an dem Ziel orientieren, das durch die Einführung des jeweiligen Systems erreicht werden soll. In diesem Zusammenhang muss beachtet werden, dass die Einführung eines Content-Management-Systems im Vergleich zu einem Portalprojekt wesentlich weniger komplex und mit weniger organisatorischen Herausforderungen behaftet ist. In den meisten Portalprojekten sind die Content-ManagementFunktionen eines Portalsystems ausreichend für die Anforderungen, die an den Prozess der Content-Verwaltung gestellt werden. Eine konkrete Entscheidung über den zusätzlichen Einsatz eines ContentManagement-Systems lässt sich aber nur im Vergleich der Zielsetzungen eines Unternehmens mit den Content-ManagementFunktionalitäten der verschiedenen Portalsysteme treffen. Verfügt ein Unternehmen bereits über ein etabliertes System zur Content-Verwaltung, so gibt es verschiedene Szenarien, dieses System bzw. dessen Inhalte in ein Portal zu integrieren. Die Hersteller der führenden Content-Management-Lösungen haben bereits die Herausforderungen der Zeit erkannt und ihre Anwendungen um Schnittstellen zu den verschiedenen Portalsystemen erweitert. Darüber hinaus bieten zahlreiche Drittanbieter Portlets für die Integration von Content-Management-Systemen in ein Portal an. Über die Portlets wird auf das externe Content-Management-System zugegriffen und dessen Inhalte, in ihrer Präsentation abhängig von der Rolle und den persönlichen Präferenzen des Benutzers, im Portal dargestellt. Die Portlets und somit auch die Inhalte lassen sich beliebig im Portal positionieren. Portlets können außerdem genutzt werden, um Anwendern abhängig von ihren Rechten und den ihnen zugewiesenen Rollen, Redaktionsmasken zur Erstellung von Inhalten im Portal anzubieten. Über Portlets lassen sich verschiedene Integrationsszenarien realisieren. So kann das Content-Management-System z.B. als reiner Content-Lieferant fungieren, während die Auswahl der Inhalte, ihre Zusammenstellung und die Präsentation vom Portal übernommen wird. Das Portal sorgt in diesem Szenario für eine personalisierte oder multimodale Darstellung der Inhalte aus dem Content Management System. Demzufolge übernimmt das Portal oftmals auch das Caching, um die Inhalte performant ausliefern zu können. Die Synchronisation zwischen Portal und Content-Management-System findet einerseits über den Austausch von Meta-Informationen statt, andererseits über ein gemeinsam zugängliches Content Repository – im Regelfall die Datenbank der Content-Management-Anwendung.

2 Abgrenzung

Ausgabekanäle

Portal

CMS

Abb. 2.2 Exemplarische Aufgabenverteilung zwischen CMS und Portal

HTML

Formular

Portlet XML

Template

...

Template

Abbildung 2.2 stellt die Integration eines Content-ManagementSystems in ein Portal über Portlets dar. In einem anderen Integrationsszenario können die Aufgaben zwischen Portal und Content-Management-System über das Frontend integriert werden. Das Content-Management-System dient hier nicht nur der Speicherung von Content, sondern auch der gesamten Zusammenstellung, Personalisierung und Formatierung der auszuliefernden Inhalte. Das Portal bildet hier nur den Rahmen, innerhalb dessen die Inhalte direkt aus dem Content-Management-System angezeigt werden. Außerdem übernimmt das Portal grundlegende administrative Aufgaben wie beispielsweise Benutzer- und Sessionverwaltung oder Authentifikation und übergibt die für den Abruf der Daten erforderlichen Informationen an das Content-ManagementSystem. Die Suchmechanismen von Portalen lassen sich in den meisten Fällen auf externen Content und beinahe beliebige Formate ausdehnen. So lassen sich die Daten aus einem Content-ManagementSystem komplett in die Portalinfrastruktur integrieren und sind flexibel auffindbar. Lässt sich das bestehende Content-Management-System über Schnittstellen oder Portlets nicht adäquat in ein Portal integrieren, dann ist die Migration der Daten in das Content Repository des Portals der geeignete Weg, ein effektives Content Management innerhalb des Portals aufzubauen. Da sich sowohl Content-Management-Systeme als auch Portale in ihrem Leistungsumfang und ihren technischen Strukturen zum Teil untereinander stark unterscheiden, lässt sich kein generelles Kochrezept für optimales Content Management in Portalen angeben. Die Entscheidung für oder gegen ein System bzw. für oder gegen ein

2.1 Content-Management-Systeme

FrontendIntegration eines ContentManagementSystems

Suche

Migration

Das optimale Integrationsszenario

■ ■ ■

43

Integrationsszenario kann nur entsprechend den individuellen Voraussetzungen des Unternehmens getroffen werden. Dazu müssen die beteiligten Systeme und die bestehende IT-Infrastruktur betrachtet werden. Es muss genau bewertet werden, welche ContentManagement-Funktionalitäten ein Portal mitbringt und inwieweit es diese Anforderungen des Unternehmens erfüllt. Bestehende Content-Management-Systeme müssen hinsichtlich ihrer Technologie und des daraus resultierenden Integrationspotenzials bewertet werden.

2.2 Enterprise Application Integration (EAI) Das Thema Enterprise Application Integration (EAI) ist im Zusammenhang mit Portalen vielfältig definiert und zugeordnet. Zum einen werben die Hersteller von Portalsystemen mit dem Integrationspotenzial ihrer Lösungen, zum anderen vermarkten Anbieter von EAISystemen diese als Grundlage für prozessorientierte Portale. Dieser Abschnitt soll etwas Klarheit in den Dschungel der MarketingBuzzwords bringen und einen kurzen Überblick über verschiedene Integrationsszenarien geben sowie deren Bedeutung für Unternehmensportale bewerten. Durch die Prozessorientierung von Portalen rückt das Thema Integration als Basis durchgängiger Prozesse ins Blickfeld. Auch bei spezialisierten EAI-Lösungen steht die Integration vorhandener Applikationen und Daten und das Einbinden zukünftiger Applikationen im Vordergrund. Eines ist Portalen und EAI-Systemen auf jeden Fall gemein: Es existieren keine klaren Definitionen und Abgrenzungen beider Begriffe. In diesem Buch wird die folgende Definition des Begriffs EAI (vgl. Müller 2004) zugrunde gelegt: Ein EAI-System ist eine Software, mit deren Unterstützung bestehende und neue Anwendungen innerhalb eines Unternehmens miteinander verknüpft werden können, um auf Basis gemeinsamer Daten und Funktionen Geschäftsprozesse abzuwickeln. Der Einsatz eines EAI-Systems ermöglicht es, die in einem Geschäftsprozess eingebundenen Anwendungen in einer heterogenen IT-Landschaft miteinander zu verweben und somit einen Datenaustausch zwischen den Anwendungen ohne Medienbruch zu realisieren.

44

■ ■ ■

2 Abgrenzung

Ein Blick auf den Gartner-Quadranten für Portalsysteme (vgl. Abschnitt 8.4) zeigt, dass sich EAI- und Portallösungen nicht scharf voneinander abgrenzen lassen. Etablierte Hersteller von EAISystemen haben ihre Produkte um Portalkomponenten ergänzt, während Hersteller von Portallösungen, die eher aus dem ContentManagement-Bereich kommen, mittlerweile ebenfalls Integrationsfunktionen in ihrem Portfolio haben. Generell lässt sich sagen, dass eine Integration der Unternehmensanwendungen und -daten die Grundlage für Portale darstellt. EAI integriert die heterogene Applikationslandschaft von Unternehmen. Portale bilden Geschäftsprozesse durchgängig ab, EAI realisiert die dazu notwendige Integration verschiedener Anwendungssysteme.

2.2.1 Formen von EAI EAI-Lösungen stellen eine IT-Infrastruktur in Form einer Middleware zur Kopplung von Systemen zur Verfügung. Grundsätzlich lassen sich nach Horn (2004) verschiedene Integrationsszenarien unterscheiden: ■

Datenintegration: Direkter Austausch von Daten, meist auf Datenbankebene z.B. über ODBC (Open Database Connectivity) oder JDBC (Java Database Connectivity).

■

Funktionsaufruf: Funktionsaufrufe (vornehmlich synchron) zwischen Anwendungen, z.B. über RMI (Remote Method Invocation, Java), RPC (Remote Procedure Call, Java), RFC (Remote Function Call, SAP) oder BAPI (Business Application Programming Interface, SAP).

■

Objektorientierte Middleware und komponentenorientierte Middleware: Alternative Konzepte zum Aufruf externer Funktionen mit Diensten, unter anderem für Transaktionen, Bekanntmachung, Sicherheit, z.B. CORBA (Common Object Request Broker) als objektorientierte Middleware und EJB/J2EE und DCOM/.NET als komponentenorientierte Middleware.

■

Message-oriented Middleware (MOM): Basiert auf dem Austausch von Nachrichten und ermöglicht sowohl eine synchrone als auch eine asynchrone Kommunikation über Message Queues. Message-oriented Middleware implementiert ein Transaktionsmanagement, das auch im Fehlerfall die Ausführung der Nachrichten sicherstellt. Darüber hinaus werden Funk-

2.2 Enterprise Application Integration (EAI)

Integrationsszenarien

■ ■ ■

45

tionen zur Nachrichtentransformation, Routing, Anwendung von Regeln, zum Vorhalten von Nachrichten und zur Implementierung von Publish-and-Subscribe-Mechanismen zur Verfügung gestellt. ■

Prozessintegration: Integration auf Geschäftsprozessebene mit Funktionen zur Steuerung von Geschäftsprozessen und Automatisierung von Workflows.

■

Web Services: Web Services sind Dienste, die Funktionen über Web-Technologien anbieten. Damit ermöglichen Web Services die plattformunabhängige Verteilung von Diensten und die Verbindung heterogener Systeme. Web Services werden ausführlich im Abschnitt 2.2.3 und im Kapitel 7 beschrieben.

Der Funktionsumfang moderne EAI-Lösungen beschränkt sich nicht nur auf die Herstellung von Verbindungen zwischen Anwendungen. EAI-Systeme sind auch Übersetzer zwischen den Systemwelten. Zum einen übernehmen sie die syntaktische Umformung, die z.B. durch verschiedene Zeichensätze notwendig wird und übersetzen die Sprache des Quellsystems in die des Zielsystems. Zum anderen unterstützen EAI-Systeme das Prozessmanagement, indem sie Funktionen für die Definition, Abarbeitung, Überwachung und Analyse applikationsübergreifender Geschäftsprozesse bieten.

2.2.2 Der Aufbau eines message-basierten EAISystems Bei den professionellen EAI-Lösungen hat sich insbesondere die nachrichtenbasierte Integration (MOM) etabliert. Die Vorteile liegen vor allem in einer Entkopplung der integrierten Systeme und in der weitgehenden Verwendung eines systemunabhängigen Austauschformates wie XML. Eine derartige EAI-Lösung setzt sich in der Regel aus den folgenden Komponenten zusammen: Komponenten einer EAILösung

46

■ ■ ■

■

Adapter: Softwaremodule zur Anbindung verschiedener Anwendungssysteme.

■

Datenmapping-Werkzeuge: Transformationswerkzeuge, welche die verschiedenen Datenformate der Quell- und Zielsysteme übersetzen.

■

Metadaten-Repository: Hier werden Informationen für die verschiedenen Datenquellen, Übersetzungsregeln und Steuerungshinweise für den Datenfluss verwaltet.

2 Abgrenzung

■

Messaging Server: Koordiniert und steuert den Austausch von Daten in Form von Nachrichten.

■

Operational Data Store (ODS): Datenspeicher, in dem aus Performanzgründen bestimmte zu integrierende Daten redundant gehalten werden.

■

Workflow: Zum Teil sind Workflow- und Prozesssteuerungskomponenten in die EAI-Lösung integriert oder bilden deren Basis.

2.2.3 Web Services Eine weitere grundlegende Veränderung, die sich im Bereich von EAI derzeit abzeichnet, ist der Einsatz von Web Services. Ähnlich wie Portlets stellen Web Services die Kommunikation und den Austausch mit beliebigen Anwendungen her. Web Services sind plattformunabhängig und basieren auf einer Kombination von Standards. Web-Service-Schnittstellen lassen sich durch die breite Unterstützung durch Entwicklungsumgebungen, insbesondere für J2EE- (Java Enterprise 2 Edition) und Microsoft .NET-Entwicklung, einfach erstellen. Der große Vorteil von Web Services liegt neben der Standardisierung der Technologie durch unabhängige Gremien insbesondere in ihrer Flexibilität. Denn mit dieser neuen XML-Technik steht ein Protokoll zur Verfügung, das nicht nur von EAIWerkzeugen mit proprietären Adaptern, sondern auch von Anwendungen direkt genutzt werden kann. Die breite Unterstützung dieser Technologie verringert die Vielfalt an Informationstechnologien und somit den Betriebsaufwand und die Anforderungen an das ITKnow-how. Durch die offenen Standards und die Hersteller- und Plattformunabhängigkeit von Web Services bieten sich diese insbesondere für die Anbindung externer Systeme an. Web Service

Anbieter

verbinden

eintragen

Web-ServiceUmgebung

Benutzer

Abb. 2.3 Die Funktionsweise von Web Services

suchen Register Web-ServiceModell

2.2 Enterprise Application Integration (EAI)

■ ■ ■

47

Abbildung 2.3 stellt die Funktionsweise von Web Services schematisch dar. Die Anbieter publizieren Web Services in Registern oder stellen sie den Benutzern direkt zur Verfügung. Die Benutzer fordern Web Services direkt vom Anbieter ab oder führen Suchoperationen aus, um gewünschte Web Services im Register zu finden und dort abzurufen. Das Web-Service-Register dient als zentrales Verzeichnis und Bibliothek von Web Services, die von Anbietern definiert und publiziert wurden. Mit der zunehmenden Standardisierung der Prozessschichten bei der Integration durch Web Services wie beispielsweise die Business Process Execution Language for Web Services (BPEL4WS, vgl. Andrews et al. 2003) sowie der Sicherheitsmechanismen wird die Bedeutung von Web Services weiter steigen. Dieser Entwicklung folgend haben viele Anbieter von Integrations- und Portallösungen ihre Software Web-Service-fähig gemacht und treiben die weitere Entwicklung dieser Standards voran.

2.2.4 EAI in Portalen Portalsysteme im Allgemeinen unterstützen den EAI-Gedanken, indem sie in der Lage sind, durch Portlets auf verschiedene BackendSysteme zuzugreifen und deren Informationen über die Ausgabemedien des Portals darzustellen. Portale stellen meist eine große Auswahl fertiger Portlets zur Verfügung, mit denen auf gängige Anwendungssysteme zugegriffen werden kann und bieten darüber hinaus Entwicklungsumgebungen für die individuelle Entwicklung von Portlets an. Im Sinne einer effektiven und entkoppelten Anwendungsintegration ist dies aber nicht ausreichend. Viele Portale unterstützen wie bereits dargestellt den EAIGedanken zudem durch ihre Web-Service-Fähigkeit. Die meisten der führenden Portalsysteme setzen außerdem auf einem Applikationsserver auf und nutzen dessen Integrationsdienste. Andere Systeme wiederum sind aus spezialisierten EAI-Lösungen hervorgegangen. Diese beiden Arten von Portalsystemen bringen ein hohes und ausgereiftes Integrationspotenzial mit. Welche Art der Integration für ein Unternehmen aber sinnvoll ist, oder ob sich gar die Investition in einen zentralen Integrationsbus lohnt, lässt sich wiederum nur im Einzelfall entscheiden. Nur in Abhängigkeit von der IT-Infrastruktur, der bestehenden Datenhaltung, den zu realisierenden Anforderungen und den abzubildenden Geschäftsprozessen lässt sich die richtige Form der Integration und ein dafür geeignetes Portalsystem wählen. Neben diesen Kriterien spie-

48

■ ■ ■

2 Abgrenzung

len außerdem Performanzgesichtspunkte, das interne IT-Know-how und die Plattform- und Betriebssystemunterstützung der verschiedenen Hersteller eine wichtige Rolle. Im Gegensatz zur Einführung einer zentralen Integrationsarchitektur (EAI-Bus) ist eine punktuelle und direkte Verknüpfung des Portals mit datenliefernden Unternehmensanwendungen nur dann sinnvoll, wenn heute und zukünftig nur eine geringe Zahl von Systemen integriert werden soll und keine weitere Anwendung auf die integrierte Sicht zugreifen muss. Punkt-zu-Punkt-Verbindungen

Zentraler EAI-Bus

n • (n-1) Schnittstellen

n Schnittstellen

Abb. 2.4 Reduktion der Schnittstellen durch den Einsatz eines zentralen EAIBusses

EAI Bus

Abbildung 2.4 veranschaulicht die Reduzierung der Schnittstellen bei einer unternehmensweiten Anwendungsintegration durch den Einsatz eines zentralen EAI-Busses. Zusammenfassend lässt sich sagen, dass durch ein optimales Integrationsszenario die Komplexität des Gesamtsystems insbesondere im Hinblick auf die Schnittstellen verringert und damit die Wartbarkeit verbessert werden kann. Applikationsbruchstellen in Prozessen werden aufgelöst und damit komplette Geschäftsprozesse abbildbar. Für die Integration über einen einheitlichen EAI-Bus spricht die Verringerung der Schnittstellen und des damit verbundenen Pflegeaufwands.

2.2 Enterprise Application Integration (EAI)

■ ■ ■

49

3 Motive und Grenzen

Dieses Kapitel gibt Antworten auf die Frage, welche Beweggründe hinter der Einführung eines Unternehmensportals zu finden sind. So unterschiedlich wie die im Abschnitt 1.9.2 genannten Anwendungsschwerpunkte und Einsatzbereiche sind auch die Motive für den Portaleinsatz. Zu diesen Motiven werden Lösungsansätze vorgestellt, die mit Portalen realisiert werden können, ohne jedoch die Lösungen tiefgreifend zu behandeln. Ziel ist es vielmehr, einen Ausblick auf die folgenden Kapitel zu geben, in denen die fachlichen und technischen Lösungen ausführlich besprochen werden. Neben den Möglichkeiten, die Portale bieten, müssen aber auch deren Grenzen betrachtet werden. Das Wissen um diese Grenzen ist eine wichtige Voraussetzung für die erfolgreiche Planung und Durchführung eines Portalprojekts.

Kurz gefasst

3.1 Warum ein Portal einführen? In der jüngeren Vergangenheit stand bei der Entscheidung für die Einführung eines Unternehmensportals nicht selten das technische Interesse im Vordergrund. Genährt durch die Versprechungen der Systemhersteller obsiegte der Wunsch nach dem Schritthalten mit der neuesten Technologie über das rationale Nutzendenken. Die Hoffnung, die Informationsflut in kürzester Zeit in geordnete Bahnen lenken zu können, wurde meistens abgelöst von der Erkenntnis, dass die Portaltechnik allein nicht ausreicht, um die Herausforderungen im Informationsmanagement zu meistern. Die darauf folgende Phase der Ernüchterung, in Kombination mit dem mahnenden Hinweis des hausinternen Controllings, bei all den Kosten den Nutzen nicht aus den Augen zu verlieren, führte schließlich zu einer neuen Bewertung der Portalthematik. Anstatt sofort mit der technischen Umsetzung zu beginnen, steht jetzt die Suche nach dem Nutzen ganz oben auf der Aufgabenliste. Gleichzeitig hat sich auch die Erwartungshaltung gegenüber einem Portal gewandelt: Zu Beginn des Por-

3.1 Warum ein Portal einführen?

■ ■ ■

51

tal-Hypes haben die Auftraggeber nicht selten überzogene Erwartungen gehegt, die in Anbetracht der Projektlaufzeiten, des Wissens um Portale sowie des gegebenen Standes der Technik nicht erfüllt werden konnten. Heute betrachtet man das Potenzial eines Unternehmensportals weitaus realistischer – auch deshalb, weil die Grenzen der Portaltechnik mittlerweile allgemein bekannt sind. Diese Grenzen werden am Ende dieses Kapitels näher betrachtet.

3.2 Wem nützt ein Unternehmensportal? Jeder, der schon einmal eine Nutzenanalyse anfertigen sollte, kennt das Problem: Je „weicher“ die Anforderungen sind, desto schwieriger ist es, den Nutzen zu definieren. Was bei technischen Fragestellungen (Erweiterung einer IT-Infrastruktur mit dem Ziel der Steigerung des Transaktionsvolumens pro Zeiteinheit) oder streng strukturierten Arbeitsabläufen (Erweiterung der Call Center-Software mit dem Ziel der Reduzierung der Vorgangsdauer) noch gut zu bewerkstelligen ist, wird mit zunehmender Variabilität und Autonomie der Arbeitsabläufe immer schwieriger. Autonome Arbeitsabläufe werden an Arbeitsplätzen ausgeführt, die nach Züllighoven (1998) dem Leitbild des Arbeitsplatzes für eigenverantwortliche Expertentätigkeit zugeordnet werden können. Dieses Leitbild ist durch folgende Eigenschaften gekennzeichnet: Leitbild „Arbeitsplatz für eigenverantwortliche Expertentätigkeit“

■

Gestaltungsziel ist die Unterstützung qualifizierter Arbeit durch einen geeigneten (elektronischen) Arbeitsplatz.

■

Die Anwender sind eigenverantwortlich handelnde Experten, die eine Fachsprache sprechen.

■

Die Entwickler eines solchen Arbeitsplatzes gestalten diesen durch die Implementierung und aufgabenbezogene Gestellung von (Software-)Werkzeugen.

Aus unserer beruflichen Praxis kennen wir viele Unternehmensportale, die diesem Leitbild folgen. Die Benutzungsoberfläche des Portals stellt das elektronische Abbild des Experten-Arbeitsplatzes dar. Wie Sie in den Kapiteln 4 und 6 sehen werden, bieten Portale dank ihrer Standardfunktionen wie Personalisierung und rollenbasierter Benutzerverwaltung und -konfiguration ausreichende Möglichkeiten, um den Arbeitsplatz an die Bedürfnisse und Tätigkeiten des Benutzers anzupassen. Der Tatsache, dass die Experten eine Fachsprache sprechen, entspricht man durch Modellierung der do-

52

■ ■ ■

3 Motive und Grenzen

mänenspezifischen Artefakte im Portal. Das ist auch dann möglich, wenn die zugrunde liegenden Informationssysteme diese Artefakte nicht explizit abbilden: Durch die Integration der Informationen aus verschiedenen Systemen und die Anreicherung mit Metadaten kann es mit Hilfe des Portals gelingen, eine im Vergleich zu den datenliefernden Systemen und Applikationen größere fachliche Nähe zu erreichen. Die Mitarbeiter der Vertriebsabteilung von Wein&Dein sind es gewohnt, mit den wichtigsten Presseinformationen rund um den Wein(handel) versorgt zu werden. Deshalb gehört es zu den wöchentlichen Aufgaben der Vertriebsassistenz, in der Tages- und Fachpresse nach relevanten Artikeln zu recherchieren und diese zu einer Umlaufmappe zusammenzustellen. Zunehmend dient auch hier das World Wide Web als Informationsquelle. So war es konsequent, die Umlaufmappe durch einen elektronischen Clipping Service abzulösen. Dieser ist in das Portal integriert und lässt sich – im Gegensatz zur Umlaufmappe – benutzerspezifisch konfigurieren. So können die Clippings z.B. nach bestimmten Schlagworten durchsucht und entsprechend bewertet werden. Artikel, die nicht in elektronischer Form vorliegen, werden eingescannt und manuell verschlagwortet. Diesem erhöhten Aufwand steht der Nutzen einer schnelleren und gleichzeitigen Verfügbarkeit für alle Interessierten sowie die Möglichkeit der Archivierung der Clippings gegenüber. Die Möglichkeiten der fachlichen Modellierung werden in den Kapiteln 8 und 9 genauer betrachtet.

3.3 Motive Im Folgenden sollen typische Motive für den Portaleinsatz aufgezeigt und bewertet werden. Diese Aufzählung (vgl. Abb. 3.1) kann nicht vollständig sein – dafür gibt es, abhängig vom Unternehmen, zu viele verschiedene (gute) Gründe, um die Nutzung eines Unternehmensportals in Erwägung zu ziehen. Die genannten Punkte sollen vielmehr als Anregung dienen, um für das eigene Unternehmen Potenziale für den Portaleinsatz zu erkennen und zu erschließen.

3.3 Motive

■ ■ ■

53

nd ard isie

run

g

Prozessoptimierung

Sta

er nd tio iter a e tiv Mo itarb M

+

Unternehmensportalprojekt

+

Miteinande rarbeit

+ +

+

Ve rb Ku esse nd en rung se rvi des ce

+ +

e ch n gis ge ate un Str cheid ts En

Abb. 3.1 Motive für den Einsatz von Unternehmensportalen

Erfolgskontrolle

3.3.1 Miteinanderarbeit – auch über Unternehmensgrenzen hinweg Organisatorische Herausforderungen

Die Koordination umfangreicher innerbetrieblicher Projekte stellt oft eine große organisatorische Herausforderung dar. Die Interessen und die zeitliche Verfügbarkeit der Projektbeteiligten sind aufeinander abzustimmen. Informationen und Dokumente müssen gemeinsam erstellt und untereinander ausgetauscht werden. Die projektrelevanten Informationen müssen für alle Beteiligten in der jeweils aktuellen Fassung jederzeit verfügbar sein. Eventuell muss der Zugriff auf gewisse Informationen rollenabhängig beschränkt werden. Dabei bewegen sich die für die Projektorganisation Verantwortlichen meistens auf bekanntem Terrain – die Abläufe und Strukturen ihres Unternehmens sind ihnen bekannt, und sie kennen die wichtigen Ansprechpartner. Auch wenn wir nachfolgend nur von (innerbetrieblichen) Projekten sprechen, so treffen viele der genannten Aspekte auch für die Abteilungen eines Unternehmens zu. Letztere werden im Folgenden nicht gesondert erwähnt.

Fachliche und technische Integration

54

■ ■ ■

Sollen nun andere Unternehmen – seien es Kunden, Lieferanten, Partner oder neu übernommene Firmen bzw. Geschäftsbereiche – in dieses Kommunikationsgefüge integriert werden, so ist die Ausgangslage ungleich schwieriger. Zu den Hauptproblemen, der Suche nach den richtigen Ansprechpartnern und der Einigung auf die Kommunikationsformen, gesellt sich das Problem der technischen

3 Motive und Grenzen

Integration. In der Regel werden die Kooperationspartner unterschiedliche technische Systeme für die Bürokommunikation und Dokumentenablage verwenden. So ist es oft nicht möglich, Verteilerlisten übergreifend und einheitlich zu definieren, wenn die Beteiligten unterschiedliche E-Mail-Systeme einsetzen. Die Folge: Jeder Partner (eventuell sogar jedes Projektmitglied) pflegt seine persönliche Liste. Änderungen müssen nicht nur kommuniziert, sondern auch in allen Kopien der Liste nachgepflegt werden – ansonsten drohen Informationsverluste oder die Fehlleitung von Informationen. Ähnlich problematisch ist die Verwendung unterschiedlicher Bürosoftware (Textverarbeitung, Tabellenkalkulation, Präsentation). Der IT-Systemarchitekt von Wein&Dein hat ein schriftliches Angebot über die Hardwareausstattung für einen neuen Webserver bekommen. Um das im Angebot enthaltene Architekturdiagramm in die eigene Ausschreibungsauswertung übernehmen zu können, hat er eine elektronische Version des Diagramms angefordert. Dieses kommt auch prompt – allerdings in Form einer OpenOffice-Datei (www.openoffice.org). Dokumente im OpenOffice-Format lassen sich allerdings nicht ohne weiteres mit der bei Wein&Dein eingesetzten Office-Software bearbeiten. Nun werden aber nicht immer nur Texte und Tabellen ausgetauscht. So ist es heute durchaus üblich, dass Rechnungen von Lieferanten den Kunden auf elektronischem Wege erreichen. Zugegeben: Diese Form der Miteinanderarbeit ist weniger auf zwischenmenschliche Kontakte ausgelegt, als vielmehr auf den Datenverkehr zwischen zwei (Buchhaltungs-)Systemen. Die Probleme sind jedoch ähnlich gelagert. Auch hier muss man sich auf ein Format für die Kommunikation einigen, das vom Lieferanten produziert und vom Kunden gelesen und verarbeitet werden kann. Neben älteren, etablierten Formaten wie EDIFACT setzt sich in letzter Zeit verstärkt XML als Metaformat für die Definition solcher elektronischer Geschäftsdokumente durch (vgl. das XML-Rechnungsbeispiel im Abschnitt 7.2). Ein weiteres Problem entsteht, wenn Dokumente gespeichert werden sollen, so dass sie für alle Partnerunternehmen im direkten Zugriff sind. Die Dateiserver der Unternehmen sind aus Datenschutzgründen gegen den Zugriff von außen geschützt. Selbst wenn der Zugriff für einen gesonderten Bereich gelockert werden sollte, so muss üblicherweise die Administration der berechtigten Benutzer beim Eigner des betreffenden Dateisystems erfolgen. Das bedeutet aber auch, dass alle Projektmitglieder ein Benutzerkonto auf dem Dateiserver bekommen müssen. Ein Gruppenkonto kommt als Lösung des Problems nicht in Frage, da dann die durchaus wichtige In-

3.3 Motive

Datenaustausch

Datenzugriff

■ ■ ■

55

Datenspeicherung

Die Herausforderungen der Miteinanderarbeit

formation, welches Projektmitglied wann welche Datei zuletzt bearbeitet hat, nicht ermittelt werden kann. Die üblichen Dateisysteme bieten ohnehin nur unzureichende Möglichkeiten zum Dokumentenmanagement. So ist es normalerweise nicht möglich, verschiedene Versionen eines Dokuments im selben Verzeichnis unter demselben Namen zu speichern. Die Versionsnummer „wandert“ daher meistens in den Dateinamen, und es ist dann die Aufgabe des Recherchierenden, die „richtige“ Version des Dokuments ausfindig zu machen. Aus verschiedenen Gründen (technische oder organisatorische Zwänge, Gewohnheit, Bequemlichkeit) werden oft mehrere unterschiedliche Möglichkeiten der Dokumentablage verwendet. Einige E-Mail- und Kommunikationssysteme bieten eine eigene Dateiablage an (z.B. Lotus Notes). Hinzu kommen Spezialanwendungen, z.B. Content-Management-Systeme, Web Logs (Blogs) und dergleichen mehr. Diese Diversifizierung der Ablage erschwert die Verwaltung und Versionierung der Dokumentation. Systeme und Werkzeuge für das Dokumentenmanagement adressieren die oben genannten Probleme – allerdings nur dann, wenn sie konsequent eingesetzt werden. Bei der Organisation der Miteinanderarbeit hat man demnach die folgenden Probleme zu lösen: ■

Informationsaustausch zwischen den Projektbeteiligten.

■

Möglichkeit des Zugriffs auf alle relevanten Informationen und Dokumente für alle Projektbeteiligten – möglichst unabhängig von deren Ablageort und der für den Zugriff benötigten Software.

■

Versionierung und Änderungsverfolgung der Dokumente.

■

Personen- oder rollenbasierter Zugriffsschutz.

■

Gruppierung der Projektbeteiligten nach Aufgaben und Interessen (z.B. durch Definition von E-Mail-Verteilerlisten).

■

Verwendung von Dokumenttypen und -formaten, die für alle Beteiligten lesbar bzw. modifizierbar sind.

Viele der in diesem Abschnitt genannten Probleme treten nicht nur bei der Miteinanderarbeit über Unternehmensgrenzen hinweg auf, sondern auch bei der Organisation einer Kommunikationsstruktur innerhalb des Unternehmens. Bei der übergreifenden Kommunikation werden sie aber oft deutlicher wahrgenommen. Das bedeutet im Umkehrschluss, dass gerade bei der innerbetrieblichen Kommu-

56

■ ■ ■

3 Motive und Grenzen

nikation genauer auf die möglichen Probleme geschaut werden muss, da diese nicht immer offensichtlich sind. Unternehmensportale mit Schwerpunkt Miteinanderarbeit (sogenannte Collaborative Portals) bieten hierbei Unterstützung, indem sie für alle Projektbeteiligten eine einheitliche Plattform zur Verfügung stellen, die dank standardisierter (Web-)Technologien in die IT-Infrastruktur nahezu jedes Unternehmens integriert werden kann. In virtuellen Räumen können alle projektbezogenen Informationen und Dokumente abgelegt und ausgetauscht werden. Zutritt zu diesen Bereichen haben nur ausgewählte Benutzer(gruppen). Abgerundet wird das Angebot oft durch die Integration von E-Mail-, Kalenderund Projektmanagement-Funktionalität.

Collaborative Portals

3.3.2 Verbesserung des Kundenservice Viele der im vorangegangenen Abschnitt erwähnten Probleme haben Einfluss auf die Außenwirkung des Unternehmens. Wenn nämlich zur Klärung von Kundenanfragen im (virtuellen) Informationspool des Unternehmens recherchiert werden muss, dann wird die Anfrage umso schneller und besser beantwortet werden können, je einfacher und schneller die benötigten Informationen gefunden und auf ihre Relevanz hin beurteilt werden. Dieser Informationspool umfasst nicht nur die EDV-Informationssysteme, sondern auch alle Mitarbeiter des Unternehmens. Im Rahmen einer Kundenanfrage werden oft auch Experten konsultiert, da deren Wissen schnell im Zugriff ist (telefonische Rückfrage) und flexibel abgerufen werden kann, und da auch „unscharfe“ Anfragen durch Rückfragen oder Umformulierung zu richtigen und guten Antworten führen. Leider stellen diese Experten in der Regel einen Engpass dar. Sie können zu jedem Zeitpunkt normalerweise nur eine Anfrage bearbeiten, sind nicht immer sofort verfügbar (weil sie andere Aufgaben wahrnehmen) und können auch für längere Zeit oder dauerhaft ausfallen (Urlaub, Krankheit oder Fluktuation). Um das Expertenwissen allgemein, schnell, parallel und dauerhaft verfügbar zu machen, muss es in einem Informationssystem gespeichert werden. Die Speicherung der Fakten allein genügt jedoch nicht, um ein schnelles Auffinden und vor allem ein sicheres Bewerten ihrer Relevanz gewährleisten zu können. Dabei müssen Konzepte und Verfahren des Wissensmanagement (Knowledge Management) zum Einsatz kommen, damit das Expertenwissen später nicht nur elektronisch verfügbar, sondern auch recherchierbar ist.

3.3 Motive

Schneller und sicherer Zugriff auf Expertenwissen

■ ■ ■

57

Wein&Dein unterhält eine Informations-Hotline für alle Fragen rund um das Thema Wein. Die Hotline wird von einem externen Call Center betrieben, dessen Mitarbeiter allerdings keine ausgebildeten Önologen sind. Sie wurden in einer Grundausbildung mit der Thematik vertraut gemacht, sind aber auf elektronisch oder telefonisch verfügbares Expertenwissen angewiesen. Da Wein&Dein keine zentrale Informationsdatenbank besitzt, greifen die Call CenterMitarbeiter bei der Beantwortung der Anfragen hauptsächlich auf die Weinexperten im Dienste von Wein&Dein zurück. Deren Hauptaufgabe ist jedoch nicht das Beantworten von Kundenanfragen. Deshalb müssen Kunden am Telefon oft sehr lange auf die Beantwortung ihrer Frage warten. Viele dieser Kunden beenden daher das Gespräch vorzeitig, ohne die Antwort abzuwarten. Das Verhältnis der abgebrochenen Anrufe zu der Gesamtanzahl der telefonischen Kundenanfragen ist ein wichtiges Indiz für die Servicequalität des Call Centers. Portale als Informationskanal

Von einem Portal kann man in dieser Hinsicht Besserung erwarten – hauptsächlich aufgrund seiner Eigenschaft, einen zentralen Zugang zu den verschiedenen Informationssystemen und -quellen des Unternehmens zu schaffen. Diese Kapselung der InfrastrukturKomplexität erleichtert den Zugang zu den Informationen. In Kombination mit Werkzeugen zur Informationsaufbereitung (Klassifikation der Informationen und Anreicherung mit Metadaten) sowie der intelligenten Informationsrecherche (z.B. natürlichsprachige Suchanfragen, Relevanzfilter und automatische Textzusammenfassung) kann die Qualität der Rechercheergebnisse häufig deutlich verbessert werden. Zugleich wird in der Regel die Anzahl der gelieferten Ergebnisse reduziert, indem nicht relevante Treffer ausgefiltert werden. Das Finden der tatsächlich benötigten Informationen wird dadurch weiter beschleunigt. Hier kann die Technik nur bedingt unterstützen – der Benutzer muss den Umgang mit den Recherchewerkzeugen erlernen und Erfahrungen sammeln, um erfolgreich und schnell recherchieren zu können. Dies kann leicht an einer Suchmaschine wie Google (www.google.de) nachvollzogen werden. Gibt man bei der Anfrage nur den gesuchten Begriff ein, so ist die Ergebnismenge unter Umständen zu groß, um sie komplett zu verarbeiten. Die Hinzunahme weiterer einschränkender Begriffe und die Gruppierung von Begriffen, die aus mehr als einem Wort bestehen (durch Einfassen in doppelte Anführungszeichen), kann die Ergebnismenge erheblich reduzieren. Sucht man z.B. nach Suchmaschinen, die eine unscharfe Suche (engl. „fuzzy search“) erlauben, dann

58

■ ■ ■

3 Motive und Grenzen

kann man die Größe der Ergebnismenge durch die Wahl und Markierung der Suchbegriffe erheblich beeinflussen: Suchbegriff fuzzy search “fuzzy search” “fuzzy search” engine “fuzzy search” linguistic engine

Anzahl gefundener Einträge (ca.) 1.670.000 29.600 2.670 175

Außerdem darf nicht verschwiegen werden, dass die Qualität der Rechercheergebnisse immer abhängig ist von der Qualität der zugrunde liegenden Informationen. Diese müssen zum einen gut gepflegt sein, d.h. die Informationen müssen regelmäßig aktualisiert werden, neue Informationen müssen aufgenommen werden, und nicht mehr gültige Informationen müssen als solche gekennzeichnet oder gelöscht werden. Zum anderen muss der Informationsbestand gezielt erschlossen sein. Darunter versteht man eine inhaltliche Analyse mit dem Ziel, die Informationen um Metadaten zum Inhalt und zu Beziehungen zwischen Informationseinheiten zu ergänzen. Diese Erschließung kann teilweise automatisch erfolgen. Ein anderer Ansatzpunkt zur Verbesserung des Kundenservice betrifft die Geschäftsprozesse des Unternehmens, die auf den Kunden eine direkte oder indirekte Auswirkung haben. Ist z.B. der Bestellvorgang zu kompliziert oder ein Genehmigungsverfahren bei der Kreditvergabe zu lang, so werden sich Kunden bei den Mitbewerbern umsehen. Ist die Warenlieferung schlecht organisiert, so dass nicht alle bestellten Waren ausgeliefert werden oder die Auslieferung unerklärbar lange dauert, dann leidet die Kundenzufriedenheit ebenfalls. Unternehmensportale können in diesem Fall nur indirekt zu einer Verbesserung der Prozesse beitragen, indem sie die reorganisierten Geschäftsprozesse technisch optimal unterstützen. Gelingt es zudem, über das Portal eine größere Transparenz und Nachvollziehbarkeit der Prozesse zu erreichen, dann kann in Fällen, wo Fehler oder Unzulänglichkeiten den Kunden verärgern, das Kundenvertrauen unter Umständen wieder gewonnen werden, indem man den Kunden über den Grund der Panne informiert. Ein Fehler, dessen Ursache man kennt, wiegt nicht so schwer wie ein Fehler, über dessen Grund man nur spekulieren kann.

3.3 Motive

Tabelle 3.1 Der Einfluss des Suchbegriffs auf die Größe der Ergebnismenge Informationsqualität

Optimale Geschäftsprozesse

■ ■ ■

59

3.3.3 Unterstützung strategischer Entscheidungen Kennzahlen – die Essenz der Unternehmensinformationen

Präsentation der Informationen

Die Reduzierung auf das (im gegebenen Kontext) Wesentliche ist eines der Hauptmerkmale von Unternehmensportalen. Abhängig von fachlichem Kontext und Geschäftsprozess werden die relevanten Informationen aus allen beteiligten technischen Systemen gewonnen, gefiltert, miteinander in Beziehung gesetzt, aufbereitet und verdichtet. Die Essenz dieser Informationen wird dem Benutzer in übersichtlicher, fachspezifischer und personalisierter Form präsentiert. Damit entspricht ein Unternehmensportal dem Wunsch vieler Führungskräfte nach Unternehmensinformationen, die zeitnah, problembezogen und vollständig zur Verfügung stehen. Außerdem liefert das Portal einen wichtigen Beitrag zur strategischen Entscheidungsfindung. Die automatische Informationssammlung erspart die zeitaufwendige manuelle Informationsrecherche, die zudem aufgrund der Fülle an Informationen in den meisten Fällen unvollständig ist. Hinzu kommt, dass mit zunehmender Anzahl an Informationen die manuelle Verdichtung und Analyse immer aufwendiger wird. Im schlimmsten Fall werden die Entscheidungen auf der Basis unvollständiger und teilausgewerteter Informationen sowie der persönlichen Erfahrung und Risikobereitschaft getroffen. Unternehmensportale hingegen ermöglichen eine Beschleunigung unternehmerischer Entscheidungen bei gleichzeitiger Risikominimierung. Neben der Verdichtung der Informationen kommt auch der übersichtlichen Präsentation eine entscheidende Rolle zu. Ein Blick in die Geschäftsberichte zeigt, wie konzentriert die Kennzahlen eines Unternehmens in Form weniger Zahlen und einfacher Diagramme dargestellt werden können. Unternehmensportale bieten hier eine geeignete technische Basis, um die Kennzahlen übersichtlich und benutzerdefiniert zu präsentieren. Damit hilft ein Portal bei der Erfüllung der Informationspflichten, die insbesondere größere Unternehmen etwa gegenüber ihren Anteilseignern, Banken oder dem Staat haben. Über das Portal stehen die geforderten Kennzahlen ad hoc zur Verfügung, was eine unmittelbare Auskunftsfähigkeit ermöglicht. Werden komplexe Zusammenhänge zu sehr vereinfacht, dann kann dies in der Folge zu Fehlentscheidungen führen, weil im Zuge der Verdichtung wesentliche Informationen verloren gegangen sind. Daher gilt: „Make everything as simple as possible, but not simpler“ (Albert Einstein).

60

■ ■ ■

3 Motive und Grenzen

Abb. 3.2 Management Dashboard: Instrument zur Anzeige des Monatsumsatzes

635.000 € 387.420 €

200.000 €

1.000.000 €

0€

Umsatz

November 2004

Eine PKW-Instrumententafel (engl. dashboard) kann als Metapher für die Präsentation dienen. Genau wie im PKW müssen die wesentlichen Informationen zum Zustand des Unternehmens mit nur einem Blick erfasst werden können. Abbildung 3.2 zeigt ein „Instrument“ zur Anzeige des Monatsumsatzes. Die Skala ist durch einen Mindestumsatz (200.000 €) und einen angestrebten Umsatz (635.000 €) in drei Bereiche eingeteilt. Bewegt sich der Zeiger im mittleren Bereich, so befindet sich der Umsatz im Soll. Mehrere solcher Instrumente für verschiedene Kennzahlen können eine „ManagementInstrumententafel“ (engl. management dashboard) bilden.

Management Dashboard

3.3.4 Optimierung der Geschäftsprozesse Wie am Beispiel des Kundenservice bereits gezeigt wurde, hat die Qualität der Geschäftsprozesse einen großen Einfluss auf den Erfolg eines Unternehmens. Schließlich handelt es sich dabei um jene Prozesse, mit denen (bzw. mit deren Ergebnissen) der Leistungsanteil des Ertrages eines Unternehmens erwirtschaftet wird. Je geringer die Kosten für diese Prozesse sind, desto größer ist folglich die Leistung. Deshalb ist die Kostenreduzierung das primäre Ziel der Geschäftsprozessoptimierung. Daneben gibt es sekundäre Ziele, wie z.B. die Beschleunigung der Prozesse (was wiederum dem primären Ziel der Kostensenkung dient) oder die Steigerung der Mitarbeitermotivation (z.B. durch die Automatisierung von Routinetätigkeiten und die damit verbundene Aufwertung der verbleibenden Tätigkeiten). Lassen sich die Geschäftsprozesse auf einem hohen Abstraktionsniveau noch recht gut beschreiben, so wird es mit zunehmendem Detaillierungsgrad immer schwieriger, eine genaue Beschreibung der Prozesse zu erstellen. Die abstrakte Darstellung ist notwendig,

3.3 Motive

Ziele der Optimierung von Geschäftsprozessen

Je detaillierter, desto schwieriger

■ ■ ■

61

Fehlende Durchgängigkeit der Geschäftsprozesse

Die Portallösung: Kombinierte Integration

62

■ ■ ■

um sich einen Überblick über die Struktur, die Gruppierung sowie die Abhängigkeiten der verschiedenen Geschäftsprozesse und deren Aufgaben und Tätigkeiten zu verschaffen. Ausgehend von diesem Plan können Prozessketten herausgearbeitet bzw. gebildet werden, die den Wertschöpfungsprozess über Funktions- und Abteilungsgrenzen hinweg beschreiben. Die klassische Prozesskette eines produzierenden Betriebes beginnt beim Kundenauftrag und führt über die Auslieferung der Ware und das Stellen der Rechnung bis hin zum Eingang und der Verbuchung des Rechnungsbetrages. Unglücklicherweise steht die Optimierung und die Reorganisation einer solchen Prozesskette häufig in Konkurrenz zur Verbesserung und Bündelung einzelner Funktionen (Fertigung, Vertrieb, Verkauf etc.). Die Organisation vieler Betriebe ist immer noch nach den Abteilungen ausgerichtet, welche die genannten Funktionen ausüben. Zunehmend setzt sich jedoch die ganzheitliche Sichtweise eines Geschäftsprozessmanagements durch. Hier wird die Ablauforganisation des Unternehmens als Bündel solcher Prozessketten begriffen, die es abteilungsübergreifend zu modellieren gilt. Das ist oft einfacher gesagt als getan. Denn mit zunehmendem Detaillierungsgrad bei der Beschreibung von Geschäftsprozessen und den darin eingebetteten Aufgaben wird es immer schwieriger, die Genauigkeit und Einheitlichkeit zu erreichen, aus der heraus eine Optimierung erst möglich wird. Vermeintliche Routinetätigkeiten entpuppen sich beim genaueren Hinsehen als Bündel von Aktivitäten mit vielen Ausnahmefällen. Abhängig vom Bearbeiter werden Aufgaben unterschiedlich ausgeführt, was mitunter sogar zu unterschiedlichen, höchstens ähnlichen Ergebnissen führt. Je individueller die Produkte oder Dienstleistungen des Unternehmens auf den Kunden zugeschnitten sind, desto schwerer fällt die standardisierte Beschreibung der wertschöpfenden Prozesse. Ein weiteres Problem der genannten Prozessketten ist die oft fehlende Durchgängigkeit. Den Kompetenzen und Möglichkeiten der Prozessbeteiligten, aber auch den technischen Systemen, die den Prozess (teilweise) unterstützen, sind in der Regel klare Grenzen gesetzt. Solche technischen Grenzen lassen sich oft nur mit großem Aufwand überwinden – es sei denn, man führt eine Integrationsebene ein, die alle aus fachlicher Sicht benötigten Verknüpfungen zwischen den beteiligten Systemen (genauer: den in diesen verwalteten Daten) herstellt. Auf die Grenzen der Prozessunterstützung wird am Ende dieses Kapitels noch ausführlich eingegangen. Ein Portal stellt eine ideale Plattform für die prozessorientierte Systemintegration dar – insbesondere deshalb, weil es eine kombinierte Integration in Frontend und Backend erlaubt (vgl. Abschnitt 1.6). So können beispielsweise Informationen aus dem CRM-

3 Motive und Grenzen

System mit denen aus der Buchhaltungssoftware verknüpft und in einer gemeinsamen Portalseite angezeigt werden. Diese visuelle Integration macht die Durchgängigkeit der Prozesskette für den Portalnutzer direkt erfahrbar.

3.3.5 Standardisierung Wie im Kapitel 7 beschrieben wird, dienen Standards in allen Bereichen des Unternehmens als verlässliche Schaffensbasis. Sie fördern die Wiederverwendung erprobter Muster und Vorgehensweisen und vereinfachen das Zusammenspiel von Mensch und Technik innerhalb und außerhalb des Unternehmens. Dabei ist der Gültigkeitsbereich von Standards sehr verschieden: Während einige Standards weltweit oder zumindest national etabliert sind (ISO, DIN), besitzen andere nur eine Gültigkeit innerhalb des Unternehmens oder für bestimmte Geschäftsbeziehungen. Der Wunsch nach Standards entsteht meistens aus einem ganz einfachen Grund: Man möchte dem „Wildwuchs“ von Vorgehensweisen im Schaffensprozess oder der Ausgestaltung von Arbeitsergebnissen Einhalt gebieten – oder diesen vermeiden. Bedingt durch den schnellen technologischen Wandel und ständig steigende Anforderungen leiden die technischen Systeme zunehmend unter diesem wuchernden Prozess der Veränderung und Erweiterung, wie das folgende Beispiel zeigt.

Standards geben Sicherheit

Standards beschneiden den Wildwuchs

Das in Eigenentwicklung entstandene Informationsportal eines großen Internet-Dienstleisters wächst und verändert sich kontinuierlich – sowohl hinsichtlich des Umfangs als auch in der Art des Informationsangebotes. Beschränkte man sich ursprünglich auf Nachrichten, so kamen mit der Zeit unter anderem Wetter- und Finanzinformationen sowie Spiele hinzu. Viele dieser interaktiven Informationsangebote und Dienste wurden zugekauft oder durch Firmenübernahmen erworben. Deren Integration war aufgrund fehlender Standards sehr schwierig. Mit der Zeit wuchs daher die Zahl an Schablonen (Templates) und Adaptern für die verschiedenen Informationstypen und datenliefernden Systeme. Um die Zukunft des Portalsystems zu sichern, war eine Konsolidierung der Portalarchitektur nötig. Ein Standard, der einige der im Beispiel genannten Probleme zu lösen vermag, ist die Portlet-Spezifikation, die den Aufbau und das Verhalten von Portalapplikationen und deren Integration in ein Portalsystem beschreibt (vgl. Abschnitt 7.5.1).

3.3 Motive

Portlet-Standard

■ ■ ■

63

Anpassung der Software an das Unternehmen – nicht umgekehrt

Bei prozessorientierten Portalen steht die Standardisierung der durch das Portal unterstützten Prozesse im Vordergrund. Bei der bisher üblichen Vorgehensweise mussten sich die Unternehmen an den im ERP-System implementierten Organisationsstrukturen und Prozessen ausrichten. Diese konnten nur bedingt an die unternehmenseigenen Strukturen und Prozesse angepasst werden. Portale verfolgen den umgekehrten Ansatz. Sie bieten die nötige Infrastruktur, um die vorhandenen oder zukünftigen Geschäftsprozesse flexibel technisch zu unterstützen. Es hängt ganz vom Anwendungsschwerpunkt des Portals ab, wie gewichtig das Motiv der Standardisierung von Geschäftsprozessen bei der Entscheidung für ein Unternehmensportal ist. So steht bei Informationsportalen, die dem Management als Werkzeug zur strategischen Entscheidungsfindung dienen sollen, ein hoher Freiheitsgrad der Portalnutzung im Vordergrund, und weniger die Standardisierung von Abläufen.

3.3.6 Motivation der Mitarbeiter Mitarbeiter erwarten von der Einführung eines Unternehmensportals vor allem eines: Sie wollen in ihrer täglichen Arbeit optimal unterstützt werden. Dies bedeutet insbesondere, dass ihnen wiederkehrende Routineaufgaben weitestgehend von dem Portal abgenommen und automatisch ausgeführt werden. Dies stellt für den einzelnen Mitarbeiter eine qualitative Aufwertung seiner Aufgaben durch Fokussierung auf die eingangs beschriebenen Expertentätigkeiten dar. Bei der Suche nach den Gründen für eine sinkende Mitarbeitermotivation wird man früher oder später aber auch die gelebte Informationspolitik des Unternehmens als eine wesentliche Ursache ausmachen. Aus Informationen entsteht Wissen. Wissen wiederum bedeutet Macht – und Macht teilen nur die wenigsten gern. Aus diesem Grund werden Informationen vielfach nicht sachbezogen ausgetauscht, sondern als machtpolitisches Mittel gebraucht. Durch gezieltes Weitergeben – oder Zurückhalten – von Informationen können Unternehmensprozesse manipuliert und (um-)gelenkt werden. Das wirkt sich letztendlich negativ auf die Motivation jener Mitarbeiter aus, die zu den Verlierern des Ringens um die Information zählen, und schadet schließlich auch der Produktivität des Unternehmens. Deshalb setzen viele Maßnahmen zur Motivationsförderung an diesem Punkt an – so auch die im Folgenden genannten.

64

■ ■ ■

3 Motive und Grenzen

Die Transparenz von Geschäftsprozessen ist eng verbunden mit dem freien Zugang zu Unternehmensinformationen. Sicherlich wird nicht jeder Mitarbeiter alle Unternehmensdaten sehen dürfen. In der Regel haben die Mitarbeiter aber Zugriff auf weitaus weniger Informationen, als man ihnen aufgrund ihrer Erfahrung und Position gewähren kann. Neben den oben genannten machtpolitischen Beweggründen kann auch eine unzureichende Organisation der Unternehmensinformationen (und dem Zugriff auf diese) der Grund für das Informationsdefizit sein. Hat der Mitarbeiter Zugriff auf die für ihn relevanten Informationen, und ist dieser Zugriff „intelligent“ genug, um die Informationen schnell und zuverlässig filtern und bewerten zu können, dann erwächst aus diesen Informationen Wissen – zunächst persönlich beim betreffenden Mitarbeiter. Später, wenn dieses Wissen über Rückkopplungsprozesse (z.B. Wissensspeicher) den Kollegen zur Verfügung gestellt wird, entsteht das Wissen, das wir eingangs als Unternehmenswissen bezeichnet haben (vgl. Abschnitt 1.3.3). Portale dienen zum einen als Schlüssel zu den Unternehmensinformationen, zum anderen können sie auch die genannten Rückkopplungsprozesse implementieren und auf diese Weise als Katalysator für den Wissenszuwachs im Unternehmen dienen. In einigen Fällen kann das Mehr an Wissen des einen Mitarbeiters auch die Produktivität eines anderen Mitarbeiters steigern: Sobald das Expertenwissen des letztgenannten Mitarbeiters im Portal zur Verfügung steht, muss er nicht mehr persönlich als Wissensspeicher für seine Kollegen dienen. Er kann sich deshalb auf seine eigentlichen Aufgaben konzentrieren. Wir wollen nicht verschweigen, dass es auch Mitarbeiter gibt, die ihre Motivation aus dem Expertentum beziehen. Solche Mitarbeiter tun sich in der Regel schwer damit, ihr Wissen zu externalisieren, da dies aus ihrer Sicht einen Verlust von Ansehen und Macht bedeutet. Unzählige Beispiele aus allen Bereichen der freien Wirtschaft und des öffentlichen Dienstes belegen: Mitarbeiter, denen ein Mindestmaß an Eigenständigkeit bei der Verrichtung ihrer beruflichen Tätigkeiten abgesprochen wird, entwickeln kein Verantwortungsgefühl für ihre Arbeit, bzw. verlieren dieses. Die Folge ist eine Einstellung, die gemeinhin als „bürokratisch“ empfunden und bewertet wird: Die Tätigkeiten werden streng nach Vorgabe ausgeführt, auch wenn eine kreative Ausnutzung des Spielraums, den die meisten Regelwerke bieten, zu besseren Ergebnissen führen würde. „Besser“ kann in diesem Zusammenhang vieles bedeuten: Zufriedenere Kunden, qualitativ hochwertigere Produkte, die den Kundenanforderungen besser entsprechen, oder Kostenersparnisse – um nur einige Verbesserungspotenziale zu nennen. Je besser die Arbeitsergebnisse,

3.3 Motive

Mehr Transparenz

Mehr Wissen

Mehr Eigenständigkeit und Verantwortung

■ ■ ■

65

Employee Self-Service Portal

Etablieren von Standards

desto besser ist in der Regel auch die Einstellung des Mitarbeiters zu seinem Tätigkeitsbereich. Es gibt sicherlich auch Menschen, für die das Übernehmen von Verantwortung in erster Linie eine Last bedeutet. Die meisten Mitarbeiter werden jedoch die Übertragung einer ihren Fähigkeiten angemessenen Verantwortung als Bereicherung empfinden. Portale unterstützen diese Übertragung der Verantwortung, indem sie dem Mitarbeiter die Informationen, Applikationen und Prozesse zur Verfügung stellen, die er für die eigenverantwortliche Ausführung seiner Tätigkeiten benötigt. Den positiven Effekt der selbständig entscheidenden Mitarbeiter machen sich auch die sogenannten Selbstbedienungsportale für Mitarbeiter (Employee Self-Service Portals) zunutze. Dieser Portaltyp ist in der Praxis recht häufig anzutreffen. Er stellt in vielen Unternehmen das Intranet-Portal in der ersten Ausbaustufe dar und gestattet es den Mitarbeitern, neben dem Zugang zu den Unternehmensinformationen auch Zugriff auf die wesentlichen Prozesse des Personalwesens zu haben. Dazu zählen in der Regel die Planung des persönlichen Jahresurlaubs, das Aktualisieren personenbezogener Daten, das Informieren über Schulungen und Weiterbildungsangebote (und das Buchen selbiger), aber auch der interne Stellenmarkt. Damit räumt ein solches Portal jedem Mitarbeiter ein gewisses Maß an Kontrolle und Selbstbestimmung über dessen persönliche Daten ein. Das schafft Vertrauen und vermittelt eine Wertschätzung der Arbeitsleistung und des persönlichen Engagements eines jeden Mitarbeiters. Die beschriebene Förderung von eigenverantwortlichem Handeln dient der Aktivierung des individuellen kreativen Potenzials. Standards hingegen bieten dem Mitarbeiter ein organisatorisches, fachliches oder technisches Rahmenwerk. Dieses dient der Orientierung und Absicherung der eigenverantwortlich gefällten Entscheidungen und schafft Vertrauen. Eigenverantwortliches Handeln und Standards sind einander ergänzende Konzepte und nicht etwa alternativ zu betrachten. Im Kapitel 7 werden einige für Unternehmensportale relevante Standards vorgestellt.

3.3.7 Erfolgskontrolle Die Zeiten, in denen IT-Projekte technischer Selbstzweck waren, getrieben aus einer „e“-Euphorie heraus, sind vorbei. Wie bereits in der Einleitung erwähnt, werden heute umfangreiche Projekte wie die Einführung eines Unternehmensportals erst nach genauer Analyse der Kosten und einer Abschätzung des erwarteten Nutzens, sprich:

66

■ ■ ■

3 Motive und Grenzen

seinem Beitrag zur Wertschöpfung des Unternehmens, genehmigt und gegebenenfalls gestartet. Um beide Aspekte – Kosten und Nutzen – einander vergleichend gegenüberstellen zu können, muss der Nutzen messbar sein. Der Return on Investment (ROI) ist eine Kennzahl, die einen wirtschaftlich messbaren Nutzen beschreibt. Über das Verhältnis der zur Einführung eines Unternehmensportals benötigten Investitionen in Relation zu den daraus erwarteten höheren Umsätzen oder gesenkten Kosten kann der Wert eines Unternehmensportals für das Unternehmen abgeschätzt werden. Allerdings sind die zur Berechnung des ROI benötigten Eingangsparameter nicht fix, sondern müssen in Abhängigkeit von den gewünschten Zielen und strategischen Schwerpunkten des Unternehmens definiert und ständig auf ihre Gültigkeit hin validiert werden. Abschnitt 11.2 beschreibt die portalspezifischen Aspekte bei der ROI-Betrachtung.

Messbarer Nutzen, ROI

Das im Abschnitt 3.3.2 beschriebene Beispiel formuliert ein Problem des Call Centers von Wein&Dein: Kunden müssen am Telefon oft sehr lange auf die Beantwortung ihrer Frage warten. Viele dieser Kunden beenden das Gespräch vorzeitig, ohne eine Antwort erhalten zu haben. Diese Zahl der vom Kunden abgebrochenen Kontaktaufnahmen lässt sich bestimmen und daraus ein messbares Ziel formulieren, z.B. „Wir möchten 30% dieser Abbrüche vermeiden, indem wir die Fragen schneller beantworten“. Ist das Ziel bekannt, kann nach den Ursachen geforscht werden – in diesem Fall die häufige Konsultation der Experten sowie die langwierige Suche in heterogenen Systemen. Ein Unternehmensportal kann diese Systeme integrieren und die Informationen so aufbereiten, dass die Call Center-Mitarbeiter in die Lage versetzt werden, auch komplizierte Sachverhalte eigenständig zu bearbeiten. Die schnellere Beantwortung von Kundenanfragen löst mehrere positive Entwicklungen aus: Die Kunden sind zufrieden, da ihre Fragen schnell und kompetent beantwortet werden. Das Call Center wird somit zum Kundenbindungsinstrument. Dessen Mitarbeiter können mehr Gespräche abwickeln als zuvor, da sich die mittlere Gesprächsdauer verkürzt hat. Und auch die Experten arbeiten produktiver, da sie sich ohne störende Unterbrechungen besser auf ihre eigentliche Arbeit konzentrieren können. Neben den messbaren Eingangsgrößen und Zielen gibt es noch andere, die sich nicht oder nur schwer in Zahlen fassen lassen. Dazu zählen vor allem emotionale Aspekte wie Motivation und Kundenzufriedenheit. Bezugnehmend auf das obige Beispiel dürfte sich die schnellere Beantwortung der Kundenfragen positiv auf die Zufrie-

3.3 Motive

Nicht messbarer Nutzen

■ ■ ■

67

Die Möglichkeit zum Wandel

denheit auswirken. Zugleich wird die Rolle der Call CenterMitarbeiter aufgewertet: Waren sie bisher bei schwierigen Fragen lediglich eine Vermittlung zwischen Anrufer und Experten, so sind sie jetzt selber Experten. Mit dem Rückgang der Anfragen aus dem Call Center dürften schließlich auch die Experten einverstanden sein, können sie sich doch intensiver um ihre eigentliche Arbeit kümmern und werden seltener aus ihrem Gedankengang herausgerissen. Oft werden einige nützliche Aspekte erst während des Betriebs eines Unternehmensportals offenbar. So eröffnet die integrierte Sichtweise, die ein Portal auf die Unternehmensdaten bietet, neue Betrachtungsmöglichkeiten für die betriebswirtschaftlichen Abläufe und lässt Zusammenhänge deutlich werden, die zuvor nicht oder kaum bekannt waren. Aus diesen lassen sich strategische Entscheidungen ableiten, die wiederum in messbarem Nutzen resultieren. Ein kontinuierlicher Vergleich der beobachteten Ergebnisse zur Laufzeit des Unternehmensportals mit den eingangs definierten betriebswirtschaftlichen Zielgrößen erlaubt einerseits die Anpassung der strategischen Ausrichtung des Portals, andererseits können auch die Zielgrößen an veränderte Bedingungen angepasst werden. Zudem werden durch den praktischen Einsatz der im Unternehmensportal definierten Prozesse deren Schwachstellen aufgedeckt und können korrigiert werden. Eine der wahrscheinlich wichtigsten Eigenschaften eines Unternehmensportals ist dessen Fähigkeit, sich seinen Benutzern, aber auch den Rahmenbedingungen flexibel und schnell anpassen zu können. Die Entwicklung eines guten, sprich: akzeptierten und intensiv genutzten Unternehmensportals endet nicht mit seiner Einführung, sondern wird weitergetrieben. Die treibende Kraft ist nun nicht mehr das Entwicklerteam, sondern die Benutzergemeinde des Portals. Die Benutzer können im Rahmen der Personalisierungsmöglichkeiten, aber auch durch Ideen zur Erweiterung des Portals dieses Softwaresystem zu einem zentralen und mächtigen Werkzeug für die strategische Informationsgewinnung, -verarbeitung und -nutzung machen.

3.4 Grenzen Sie haben den Nutzen eines Portals für Ihr Unternehmen erkannt, definiert und schlüssig argumentiert. Damit haben Sie den eigentlichen Zweck der Einführung eines Unternehmensportals gefunden. Herzlichen Glückwunsch!

68

■ ■ ■

3 Motive und Grenzen

Die Euphorie, die sich angesichts des Potenzials bei Ihnen und allen, die Sie für diese Idee gewinnen konnten, einstellen mag, darf aber nicht den Blick auf die Grenzen eines Portaleinsatzes verstellen. Ein Portalsystem ist letztendlich nur ein technisches Hilfsmittel, das seine Möglichkeiten nur dann entfalten kann, wenn es organisatorisch wie auch technisch optimal in ausgewählte Prozesse des Unternehmens integriert ist. Gemeint sind jene Prozesse, über die sich der definierte Nutzen realisieren lässt. Portale sind kein technischer Selbstzweck – sie müssen organisatorische Probleme lösen und betriebswirtschaftlichen Nutzen erbringen. Aus den soeben genannten Voraussetzungen für den Erfolg eines Unternehmensportals lassen sich auch dessen Grenzen ableiten (vgl. Abb. 3.3). So sind Portale z.B. machtlos, wenn die Organisation des Unternehmens bestimmte strukturelle oder kulturelle Schwächen aufweist.

+

+

+

Ve ran Fehl tw end ort lich e ke ite n

+

Sc qu hlec alit h ät t e D un d - aten pfl eg e

um en en ss Wi ation in Ke form In

+

he isc rch ren a r u Hie trukt S

Ungenügende Integration

+

+

Kein Bewusstsein für Geschäftsprozesse

Unternehmensportalprojekt

Geringe Motivation der Mitarbeiter

Abb. 3.3 Grenzen von Unternehmensportalen

3.4.1 Geringe Mitarbeitermotivation Fehlen Leitbilder, Visionen und (Projekt-)Ziele, so fällt es schwer, den Mitarbeitern des Unternehmens, also den späteren „Kunden“ des Unternehmensportals dessen Vorzüge zu vermitteln. Je weniger bzw. je später die betroffenen Mitarbeiter in den Entstehungsprozess des Portals eingebunden werden, desto weniger werden sie sich später mit dem Portal und dessen Zielen identifizieren können. Zudem werden durch ein solches Informationsdefizit – oftmals unbewusst – Ängste und Vorurteile geschürt: Das Unternehmensportal wird von vornherein als „Manager-Spielzeug“ abgetan, ohne dass die Mitar-

3.4 Grenzen

■ ■ ■

69

Portalmarketing schafft Transparenz

beiter die Vorteile erkennen, die ihnen persönlich das Portal zu bringen vermag. Oft sitzt die Angst noch tiefer: Ein gängiges Vorurteil über Unternehmensportale ist, dass diese nur zum Zwecke der Rationalisierung als Jobkiller eingesetzt werden. Daneben steht die Angst, insbesondere von älteren Mitarbeitern, mit den neuen Technologien nicht umgehen zu können. Deshalb ist es wichtig, die Mitarbeiter intensiv und frühzeitig in die Anforderungsanalyse mit einzubeziehen. Dann kann ihnen auch glaubhaft vermittelt werden, dass das Unternehmensportal ihre tägliche Arbeit erleichtern, nicht aber übernehmen soll. Auch eine ergonomisch gestaltete Benutzungsoberfläche kann dazu beitragen, die Angst vor der neuen Technologie zu nehmen. Unter Ergonomie verstehen wir in diesem Zusammenhang nicht nur ein „gesundes“ Oberflächendesign. Auch die Umgewöhnung von den Altsystemen zum Portalsystem sollte für die Benutzer so einfach wie möglich sein. Die Logik der Benutzungsoberfläche des Portals sollte sich an der etablierten Dialogführung der vom Portal gekapselten Altsysteme orientieren. Hinzu kommen rechtliche Bestimmungen zur Gestaltung von Arbeitsplätzen, z.B. die „Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten“ (BildschArbV). Um das Interesse am Portal, das Verständnis für dessen Strukturen und den Glauben an seinen Erfolg aufrechtzuerhalten, ist ein kontinuierliches Portalmarketing nach „oben“ (d.h. in Richtung der Projektinitiatoren, Sponsoren und der Geschäftsführung) wie nach „unten“ (alle von der Einführung des Unternehmensportals betroffenen Personen innerhalb und außerhalb des Unternehmens) notwendig. Mitarbeitermotivation kann nicht befohlen werden – sie entsteht, wenn sich die Mitarbeiter als aktive Mitgestalter des Portalsystems fühlen können. Die genannten Faktoren sind wesentliche Voraussetzungen, um die organisatorischen Herausforderungen bei der Einführung des Unternehmensportals zu meistern. Die Mitarbeiter der telefonischen Bestellannahme von Wein&Dein sollen mit einer Portalapplikation in ihrer Tätigkeit unterstützt werden. Einerseits sollen sie auskunftsfähiger werden, indem die Kundendaten des Anrufenden (soweit vorhanden) automatisch über die Telefonanlage ermittelt und im Portal präsentiert werden. Andererseits sollen die über eine zentrale Eingabemaske des Portals erfassten Informationen (Bestelldaten, Sonderwünsche, Kritik, Kundendaten, Lieferadressen) auf direktem Weg in die verschiedenen angeschlossenen Applikationen (ERP-System, CRM-System, etc.) gelangen. Dieser Nutzen wird den Mitarbeitern der Bestellannahme leider nicht vermittelt – mit der Folge, dass das Gerücht kursiert, die neue Software diene in erster Linie dazu, Personal abzubauen. Dies

70

■ ■ ■

3 Motive und Grenzen

führt dazu, dass nach der Einführung des Portalsystems die Bereitschaft der Mitarbeiter zur Arbeit mit dem neuen System ausgesprochen gering ist. Die Situation verschärft sich weiter, als die Mitarbeiter feststellen, dass das Portal ihre gewohnte Arbeitsweise nur ungenügend unterstützt. Da der Einarbeitungsaufwand zu hoch erscheint, arbeitet man weiter mit dem Altsystem, das aus verschiedenen Gründen noch nicht abgeschaltet worden ist. Wenn das Portalsystem von vornherein an den Bedürfnissen des Unternehmens und der Benutzer ausgerichtet worden wäre, dann gäbe es keine Diskrepanz zwischen vorhandener und geforderter Funktionalität. Außerdem hat das Projektteam die Vision und den Nutzen des Portals ungenügend kommuniziert. Das lässt sich nachholen, wenngleich es eine große Herausforderung sein dürfte, das Vertrauen der Benutzer zurückzugewinnen.

3.4.2 Hierarchische Strukturen Die Mitarbeiter, die später mit dem Portal arbeiten sollen, sind oftmals diejenigen, die in der Phase der Planung und Anforderungsanalyse kaum oder gar nicht gehört werden. Dabei sind es gerade sie, die Anforderungen an ein Portal benennen können, durch deren Berücksichtigung sie wirklich in ihrer täglichen Arbeit unterstützt würden. Selbst wenn ihre Meinung gefragt ist, können stark ausgeprägte Hierarchien die Aufnahme der Anforderungen behindern. In diesem Fall sind die Meinungen der Vorgesetzten dermaßen prägend, dass Mitarbeiter nicht in der Lage sind oder sich schlichtweg nicht trauen, ihre eigene Sichtweise zu vertreten. Solchen hierarchischen Aufbauorganisationen ist meistens ein starkes Verantwortungs- und Informationsgefälle zueigen. Das aber widerspricht den grundlegenden Zielen eines Unternehmensportals, das allen Mitarbeitern die für sie wesentlichen Informationen auf breiter Basis zur Verfügung stellen soll. Die Folge: Das Unternehmensportal kann seine Möglichkeiten nicht entfalten, weil der Informationszugriff stark reglementiert wird und auch bei der Pflege der Inhalte informationspolitische Erwägungen eine Rolle spielen. Um diesen negativen Auswirkungen der Informationspolitik entgegenzuwirken, können „Moderatoren“ für die verschiedenen Themenbereiche des Portals ernannt werden. Diese sind für die Qualität der Informationen in ihrem Verantwortungsbereich verantwortlich. Die gemeinsame Verantwortung aller Moderatoren umfasst die Integrität des gesamten Informationsbestands sowie das Erkennen von Synergieeffekten, z.B. bei überlappenden Themenbereichen.

3.4 Grenzen

■ ■ ■

71

Die Idee, ein Wein&Dein-Portal einzuführen, stammt vom neu ernannten Chief Information Officer (CIO) des Unternehmens. Dieser betrachtet das Portal im Wesentlichen als persönliches Profilierungsinstrument. Zudem sieht er zunächst die technischen Vorteile, ohne jedoch den fachlichen Nutzen ausreichend zu erörtern. Die Leiter der Fachabteilungen reagieren bei der Präsentation des Projektvorhabens zurückhaltend. Sie sind in der Zwickmühle: Einerseits sehen sie, dass die Strategie zu sehr technisch orientiert ist. Andererseits wollen sie – aus Sorge um ihre Position oder ihren Arbeitsplatz – das Verhältnis zum Technik-Vorstand so wenig wie möglich belasten. Diese taktische Zurückhaltung der Abteilungsleiter macht es letztendlich auch deren Mitarbeitern unmöglich, die eigenen Vorstellungen in die Gestaltung des Portals einzubringen.

3.4.3 Fehlende Verantwortlichkeiten Die verantwortlichen Personen müssen während der gesamten (Projekt-)Laufzeit eines Portals definiert und bekannt sein. Während der Projektphase kann so sichergestellt werden, dass keine wichtigen Informationen mangels Zuständigkeit verloren gehen und Entscheidungen schnell herbeigeführt werden können. Nach der Einführung des Portals sorgt eine klare Zuordnung der Aufgaben und Verantwortlichkeiten für eine kontinuierliche Pflege und Weiterentwicklung des Portals und seiner Inhalte. Wein&Dein ist ein ISO 9001-zertifiziertes Unternehmen. Entsprechend muss das neue Portalprojekt die Anforderungen dieser Norm erfüllen. Ein Qualitätsmanager kümmert sich normalerweise um diese Aufgabe. Der Projektmanager ist überzeugt von seinem Team und der Qualität seines Projektplans. Das Qualitätsmanagement – dessen ist er sich sicher – wird implizit stattfinden, denn die Mitglieder des Teams haben umfangreiche Erfahrungen in vielen unternehmensinternen Projekten sammeln können. Eine explizite Berücksichtigung des Themas „Qualität“ kostet zudem Zeit und Geld. Die Mitglieder des Projektteams bringen alle ihre eigenen Erfahrungen und Vorgehensweisen in das Projekt ein, ohne sich Gedanken über eine Vereinheitlichung zu machen. Das gehört, wie sie meinen, nicht zu ihrem Aufgabenbereich – und ist zudem aufwendig, da es eine Abkehr vom Gewohnten bedeutet. Diese unterschiedliche Wahrnehmung führt letztendlich zu einer verweigerten Abnahme des Projekts seitens des IT-Systembetriebs. Da sich während der Projektlaufzeit

72

■ ■ ■

3 Motive und Grenzen

niemand um die Einhaltung der Qualitätsstandards gekümmert hat, wurden die von der für den Systembetrieb verantwortlichen ITAbteilung geforderten Dokumente, wie z.B. eine Installationsdokumentation und ein Leitfaden für die Systemüberwachung, nicht erstellt. Die verantwortliche IT-Abteilung besteht jedoch auf der Einhaltung der Qualitätsstandards, weshalb das Portal zunächst nicht in Betrieb genommen werden kann. Dieser Abteilung fehlen offensichtlich die für einen reibungslosen Betrieb notwendigen Standards für die Dokumentation, Installation und Systemüberwachung.

3.4.4 Fehlendes Bewusstsein für Geschäftsprozesse Jedes Unternehmen hat Geschäftsprozesse. Das Wissen um diese Prozesse – sofern überhaupt vorhanden – genügt leider nicht, um diese in einem Unternehmensportal sinnvoll und zielgerichtet abbilden zu können. Entscheidend ist, ob sich die identifizierten Geschäftsprozesse für die Abbildung im Portal eignen. Das hängt unter anderem von folgenden Faktoren ab, die durch die aufgeführten Fragestellungen ermittelt werden können: ■

Strukturierungsgrad: Ist der Geschäftsprozess klar gegliedert? Wie homogen sind die enthaltenen Abläufe, auch über einen längeren Zeitraum und mehrere Wiederholungen hinweg? Wie viele Ausnahmen gibt es?

■

Formalisierungsgrad: Sind die Prozesse nur mündlich überliefert oder schriftlich ausformuliert? Erlaubt die Art der Formulierung eine Vergleichbarkeit mit anderen Geschäftsprozessen des Unternehmens?

■

Relevanz: Wie groß ist der Beitrag des Geschäftsprozesses zum unternehmerischen Erfolg? Wie viele Personen sind wie häufig in den Geschäftsprozess eingebunden?

■

Optimierungspotenzial: Welche Verbesserungen bringt eine technische Unterstützung des Geschäftsprozesses? Rechtfertigt diese – gemessen an der Relevanz des Prozesses – die Investition in eine technische Lösung?

■

Durchgängigkeit: Weist der Geschäftsprozess fachliche oder technische Brüche auf, die auch von einem Unternehmensportal nicht überwunden werden können? Beispiele hierfür sind Prozesse, die Medienbrüche aufweisen (Papier und Software) oder

3.4 Grenzen

■ ■ ■

73

sich über Unternehmensgrenzen hinaus erstrecken (Einbindung der Lieferanten). ■

Technische Modellierbarkeit: Basiert der Geschäftsprozess auf einem oder mehreren Softwaresystemen, und lassen sich diese integrieren? Lohnt der Aufwand, einen bisher nicht softwaretechnisch gestützten Prozess technisch zu modellieren? Ist dies überhaupt möglich?

Die Geschäftsprozesse dürfen nicht isoliert betrachtet werden. Eine unternehmensweite Sicht auf die Prozesse ist nötig, um die oben aufgeführten Fragen für jeden Geschäftsprozess im Kontext der Prozesslandschaft des Unternehmens zu beantworten. Die Modellierung des Bestellprozesses für das Wein&Dein-Portal wird einem erfahrenen Mitarbeiter der IT-Abteilung übertragen. Dieser arbeitet bereits lange im Unternehmen und hat in zahlreichen Projekten als Mittler zwischen den Fachabteilungen und den Entwicklern fungiert. Dementsprechend einfach lassen sich die Sachbearbeiter für Interviews gewinnen, in denen ihre Arbeitsabläufe aufgenommen werden – mit dem Ziel, die daraus resultierenden Anforderungen an den zu modellierenden Geschäftsprozess formal zu beschreiben. Die Sachbearbeiter beschreiben eher die Ausnahmen ihrer Arbeit als den Regelfall, der – wie sie meinen – ohnehin jedem bekannt ist und deshalb nicht mehr beschrieben werden muss. Der Erfahrung und Sensibilität des Prozessmodellierers ist es zu verdanken, dass durch gezieltes Nachfragen auch die „Normalfälle“ ermittelt werden. Diese bilden später die wesentliche Grundlage für die Spezifikation des Systems.

3.4.5 Fehlendes Wissen um verfügbare Informationen Unternehmensportale sollen aus Sicht des Benutzers von der Komplexität der Informationslandschaft des Unternehmens abstrahieren. Das setzt voraus, dass die Projektverantwortlichen diese Komplexität durchdringen. Diese müssen zunächst ermitteln, aus welchen Systemen die für das Portal relevanten Informationen bezogen werden können. Die Informationsbasis muss nach originären und abgeleiteten Daten geordnet werden. Daraus ergibt sich auch, welche Systeme als führend im Sinne der von ihnen gehaltenen Informationen angesehen werden. Nun können alle Systeme, welche die Informationsbasis bilden, gemäß der vom Unternehmensportal zu unterstützenden Prozesse integriert werden. Probleme ergeben sich in

74

■ ■ ■

3 Motive und Grenzen

der Praxis häufig dann, wenn Daten redundant in verschiedenen Systemen gehalten werden. In diesem Fall müssen Lösungen gefunden werden, um eine Datenkonsistenz zu gewährleisten. Das Wissen um die Informationen und Daten ist zudem nicht statisch: Der Informationspool wird sich im Laufe der Zeit verändern. Die Portalverantwortlichen müssen dem Rechnung tragen, indem sie die Integrationsbeziehungen an die veränderte Realität anpassen. Bei der Analyse der Informationslandschaft von Wein&Dein wurde das Stammdatensystem als zentrale Informationsquelle für Kundeninformationen ausgemacht. Die Systemschnittstellen und Teile der Portal-Applikationslogik wurden auf dieses System ausgerichtet. Ein Jahr nach Einführung des Portals fällt die Entscheidung für die Einführung eines neuen CRM-Systems als Ersatz für das alte Stammdatensystem. Man erkennt die Notwendigkeit, die Schnittstellen des Portals entsprechend anzupassen. Die neuen Möglichkeiten, die das CRM-System gegenüber seinem Vorgänger auszeichnete, sind den Portalverantwortlichen nicht bewusst gemacht worden. Dementsprechend belässt man es bei einem Austausch der technischen Schnittstelle. Die Unterstützung der neuen CRM-Funktionen durch das Portal wird nicht in Betracht gezogen, obwohl diese einen Mehrwert für einige der vom Portal unterstützten Geschäftsprozesse bedeuteten.

3.4.6 Unvollständige oder schlecht gepflegte Datenbestände Auch wenn die oben beschriebene, aus integrierten Systemen gebildete Informationsbasis mehr ist als die Summe ihrer Daten, kann sie dennoch keine unvollständigen oder fehlenden Daten ergänzen bzw. ersetzen. In diesem Fall wird sich die schlechte Datenqualität direkt auf die Informationsqualität des Unternehmensportals auswirken. Auch ursprünglich „gute“ Datenbestände können im Laufe der Zeit aufgrund von ungenügender Pflege oder unkontrollierter Bearbeitung an Qualität verlieren. Das Portal kann jedoch als Organ zur Qualitätskontrolle und -sicherung eingesetzt werden. Schlecht gepflegt ist ein Datenbestand auch dann, wenn sich ein Teil der Informationen nur in den Köpfen einzelner Mitarbeiter befindet. Diese Informationen stehen einem Portal nicht zur Verfügung. Gleichwohl kann ein Portal die Mitarbeiter dazu motivieren, diese Informationen elektronisch zu erfassen und damit allgemein zugänglich zu machen.

3.4 Grenzen

■ ■ ■

75

Wein&Dein möchte zum Zwecke der Kundenbindung einen regelmäßigen E-Mail-Newsletter versenden. Unglücklicherweise stellt sich heraus, dass nur für die Hälfte der Kunden eine E-Mail-Adresse verfügbar ist und diese nicht auf ihre Gültigkeit hin untersucht wurde. Dieser Umstand führt dazu, dass sowohl bei der Kontaktaufnahme über das Kundenportal als auch in der Portalapplikation für die Mitarbeiter der telefonischen Bestellannahme die E-Mail-Adresse als Pflichtfeld definiert wird. Das System überprüft zudem ähnliche Datensätze, in denen z.B. Name, Vorname und Postleitzahl übereinstimmen, der Straßenname aber unterschiedlich geschrieben ist. Auf diese Weise werden Dubletten vermieden.

3.4.7 Ungenügende Integration Die Integration der informationstragenden und -verwaltenden Systeme ist kein technischer Selbstzweck, sondern dient dem fachlich motivierten Verweben von Daten. Integration muss sich demnach an dem jeweiligen Anwendungszweck orientieren. Die allumfassende Integration der gesamten Informationslandschaft und die Migration von Insellösungen hin zum zentralen Datenbestand ist ein Wunschtraum – und wird es wohl auch bleiben. Ohne fachliche Anforderungen ist eine Integration ohnehin nicht sinnvoll – wohl aber die Konsolidierung der datenliefernden Systeme. Es gibt mit Sicherheit Anwendungsfälle, in denen eine Systemintegration für die portalgestützte Informationsversorgung nicht notwendig ist. In vielen Fällen wird es das Projektteam eines Portalprojektes jedoch mit Geschäftsprozessen zu tun haben, deren durchgängige technische Abbildung nur über die Systemintegration zu erreichen ist. Die Herausforderung liegt in der genauen Definition des Informationsbedarfs eines Anwendungsfalls sowie in der Bestimmung des daraus abzuleitenden Integrationsbedarfs. Stellt man fest, dass der Integrationsbedarf für einen konkreten Anwendungsfall unerwartet hoch ist, so ist man schnell versucht, diesen dennoch – auf der Basis unvollständig integrierter Systeme – zu realisieren. Ein solches Vorgehen ist selten zielführend. Zum einen investiert man in eine halbfertige Lösung. Zum anderen bedingt die nur begrenzt nutzbare Version des Anwendungsfalls, dass dessen unerfüllt gebliebene Aspekte anderweitig (und in der Regel nicht-technisch) realisiert werden müssen. Es ist in diesem Fall besser, die Realisierung auf einen Zeitpunkt zu verschieben, zu dem eine vollständige Integration möglich ist.

76

■ ■ ■

3 Motive und Grenzen

Im Call Center von Wein&Dein geht ein erboster Anruf eines Kunden ein. Dieser beschwert sich darüber, dass Wein&Dein ihm einen Werbeprospekt zugesendet hat, obwohl er dies ausdrücklich bei seiner per Postkarte aufgegebenen Bestellung untersagt hat. Der Mitarbeiter des Call Centers kann zwar über seine Portalapplikation die Bestellungshistorie des Kunden einsehen. Auch die mit den Kundenstammdaten gespeicherte Zustimmung zum Empfang von Werbemailings ist einsehbar. Für den betreffenden Kunden liegt laut System die Zustimmung vor. Dabei handelt es sich aber um einen Fehler bei der Datenübernahme. Die Bestellpostkarte wird bei Eingang eingescannt und archiviert. Die Bestelldaten werden normalerweise automatisch ausgelesen und in das Bestellsystem übertragen. In einigen Fällen widersetzt sich die Handschrift des Bestellers einer automatischen Schrifterkennung – dann werden die Bestelldaten manuell erfasst. Der Mitarbeiter des Call Centers hat in seiner Portalapplikation keinen Zugriff auf die im elektronischen Archiv abgelegte Postkarte. Deshalb kann er Fehler, die ihre Ursache in der manuellen Datenerfassung haben, nicht so einfach nachvollziehen. Die genannten Grenzen stellen für ein Portalprojekt nur dann eine unüberwindbare Hürde dar, wenn die Risiken nicht rechtzeitig erkannt oder zu lange ignoriert werden. Wir hoffen deshalb, mit diesem Kapitel bei Ihnen das nötige Problembewusstsein geschaffen zu haben. Die genannten Motive mögen Ihnen als Anhaltspunkt dienen, um Ihr Portalprojekt erfolgreich und überzeugend zu präsentieren und zu realisieren. Für eine transparente Innen- und Außendarstellung des Portalprojekts ist eine offene Kommunikation von Chancen und Risiken unabdingbar. Sie schafft bei allen Beteiligten ein Gefühl für die Zusammenhänge und das Bewusstsein für die positiven und negativen Einflussfaktoren.

3.4 Grenzen

Grenzen sind Herausforderungen – keine Hürden

■ ■ ■

77

4 Fachliche Anforderungen

In diesem Kapitel werden die primären Anforderungen beleuchtet, die üblicherweise von den Fachabteilungen an ein Unternehmensportal gestellt werden. Anhand dieses Überblicks über die fachlichen Zielsetzungen und Anforderungen werden die vielfältigen Einsatzgebiete eines Portalsystems aufgezeigt. Im Folgenden sind die am häufigsten in der Praxis anzutreffenden Aspekte dargestellt. Je nach Größe und Branche des Unternehmens sowie dem Anwendungszweck eines Unternehmensportals lässt sich diese Aufstellung um beliebige weitere Anforderungen ergänzen.

Kurz gefasst

4.1 Abbildung und Steuerung von Geschäftsprozessen Betrachtet man die betriebswirtschaftlichen Prozesse eines Unternehmens, so stellen sich diese als ein komplexes Netzwerk aus Personen und Informationen dar. Zu den Personen zählen neben den Mitarbeitern in ihren unterschiedlichen Rollen (z.B. Manager, Angestellte, Arbeiter) mit den jeweiligen Verantwortungsbereichen (z.B. Controlling, Human Resources, Marketing) auch Personen aus dem wirtschaftlichen Umfeld, wie z.B. Partner, Kunden oder Lieferanten. Diese Personen interagieren über verschiedene Kommunikationsmittel und –wege und tauschen Informationen aus. Dabei werden wiederkehrende und bewährte Interaktionsformen und Aktivitätsketten implizit oder explizit standardisiert und wiederverwendet. Diese Geschäftsprozesse bilden die Grundlage des wirtschaftlichen Handelns eines Unternehmens. Ihre Qualität und Effektivität hat große Auswirkungen auf die Wirtschaftlichkeit des Unternehmens und trägt entscheidend zum Geschäftserfolg bei. Unternehmen müssen ihre Produktivität und Profitabilität steigern, dem Kunden ein hohes Dienstleistungsniveau bieten und seine Wünsche frühzeitig erkennen. Zugleich müssen sie die Kosten der laufenden Geschäftsprozes-

4.1 Abbildung und Steuerung von Geschäftsprozessen

■ ■ ■

79

Prozessevolution

Optimierung betrieblicher Abläufe

Mehr Transparenz, weniger Kosten

Fachlich motivierte Prozessdefinition

80

■ ■ ■

se senken. Eine durchgängige, an den Arbeitsabläufen des Unternehmens orientierte, technische Abbildung der Geschäftsprozesse unterstützt die Flexibilität und Effizienz dieser Prozesse. Geschäftsprozesse sind im Prinzip unabhängig von technischen Systemen, wenngleich sich viele (Teil-)Prozesse technischer Systeme bedienen bzw. auf diesen aufsetzen. Die meisten nichttechnischen Prozesse sind Ausdruck der Erfahrungen aller an ihnen beteiligten Personen, die ihre Tätigkeit weniger als Prozess denn als natürliche Form des Handelns oder Routine verstehen. Diese Handlungsformen verändern sich über die Zeit und mit zunehmender Erfahrung und passen sich an veränderte Bedingungen an. Bei dieser Prozessevolution setzt sich nicht notwendigerweise der objektiv beste Prozess durch, da viele (mitunter irrationale) Einflussfaktoren die Richtung verändern können. An diesem Punkt setzt die Geschäftsprozessanalyse an. Ausgehend von der Analyse der bestehenden Prozesse wird die Ablauforganisation des Unternehmens methodisch reorganisiert. Ziel ist eine Optimierung und Beschleunigung der betrieblichen Abläufe sowie eine erhöhte Transparenz. Die Möglichkeiten der Optimierung betrieblicher Abläufe sind vielfältig. Sie reichen von der Straffung und Beschleunigung durch Reduktion der Prozessschritte oder der Anzahl der am Prozess beteiligten Personen über die Automatisierung von (Teil-)Prozessen bis hin zur Schaffung eines ergonomischeren Arbeitsumfelds. Die technische Unterstützung strukturierter Geschäftsprozesse ermöglicht bzw. erleichtert die Etablierung von Vorgehensstandards in diesen Prozessen. So vielfältig wie die Maßnahmen sind auch die Ziele, die mit einer Prozessoptimierung verfolgt werden: Kostenreduzierung (meist durch Beschleunigung und Automatisierung) ist das primäre wirtschaftliche Ziel. Ein weiteres Ziel stellt die Steigerung der Prozesstransparenz dar. Mit zunehmender Transparenz werden Prozesse verständlicher und nachvollziehbarer, was wiederum zu einer weiteren Verbesserung der Prozesse führen kann. Durch die automatische Steuerung gesamter Prozessketten kann die Verarbeitung eines Geschäftsvorfalls transparenter gemacht werden, da der gesamte Ablauf protokolliert wird und jederzeit der Status einzelner Arbeitsschritte abgerufen werden kann. Diese Transparenz erhöht die Auskunftsfähigkeit des Unternehmens nach innen (z.B. gegenüber der Geschäftsleitung) und nach außen (z.B. gegenüber den Kunden). Geschäftsprozesse, die von technischen Systemen unterstützt werden, sind durch diese Systeme oft in ihrer Ausgestaltung eingeschränkt. Die Systemgrenzen sind üblicherweise identisch mit den Grenzen des Geschäftsprozesses. Anstatt die Prozesse nach fachlichen Anforderungen zu gestalten, werden sie von technischen

4 Fachliche Anforderungen

Randbedingungen diktiert. Das Resultat ist eine Vielzahl partieller Prozesse, die an den für sie unüberwindbaren Systemgrenzen miteinander in Verbindung gebracht werden müssen – ein aufwendiges und fehlerträchtiges Vorgehen. Das Ziel muss daher sein, die Geschäftsprozesse fachlich orientiert zu gestalten. Dazu müssen zunächst die technischen Voraussetzungen geschaffen werden. Als Datenbasis einer fachlich orientierten Prozesssteuerung muss die gesamte Informationslandschaft des Unternehmens mit allen explizit implementierten und implizit definierten Beziehungen zwischen den Informationseinheiten zur Verfügung stehen. Um Geschäftsprozesse ganzheitlich fachlich zu unterstützen, muss das Unternehmensportal einerseits die Geschäftsprozesse durchgängig abbilden und gegebenenfalls verbessern (Prozessunterstützung) und andererseits die Durchführung der einzelnen Arbeitsschritte in einer Prozesskette optimieren (Funktionsunterstützung).

Prozessunterstützung und Funktionsunterstützung

Die Prozessunterstützung beinhaltet unter anderem Mechanismen zur Steuerung und Kontrolle von Vorgängen, Aktivitäten im Rahmen der Vorgänge, Abfolgen von Aktivitäten, Zuständigkeiten und Verantwortlichkeiten. Die Funktionsunterstützung umfasst die Bereitstellung der Informationen und Anwendungen, die für eine Bearbeitung eines bestimmten Prozessschritts – einer Prozessfunktion – notwendig sind und dem Bearbeiter zur Verfügung gestellt werden müssen. Eine Prozessunterstützung beschreibt somit auf Basis einer integrierten Informationslandschaft komplette Prozessketten über Systemgrenzen hinweg. Sie ist der zentrale Steuermechanismus der technischen Unterstützung von Geschäftsprozessaktivitäten (Workflow). Diese Workflowsteuerung des Portals beschreibt den Ablauf des Geschäftsprozesses bzw. seiner möglichen Geschäftsvorfälle. Sie weist Mitarbeitern Aufgaben entsprechend ihrer Rolle in der Prozesskette zu und wacht über deren planmäßige Erledigung. Für den Fall einer nicht fristgerechten oder nicht korrekten Erledigung eines Prozessschrittes können in der Workflowsteuerung Eskalationsstufen eingerichtet werden. Eskalationsstufen beschreiben verschiedene Fehlerfälle bzw. Fehlerintensitäten. Diese Fehlerfälle werden mit dem Ziel einer möglichst schnellen Fehlerbehebung an Aktionen (beispielsweise die Benachrichtigung des Vorgesetzten) geknüpft. Die Funktionsunterstützung hingegen betrachtet nicht die gesamte Prozesskette, sondern nur einzelne Prozessschritte und die damit verknüpften Aufgaben. Entsprechend seiner Rolle stellt sie dem Bearbeiter die für die Erledigung seiner Aufgaben notwendigen Infor-

4.1 Abbildung und Steuerung von Geschäftsprozessen

Workflowsteuerung in Portalen

■ ■ ■

81

Qualitätssicherung

Motivation durch Automatisierung von Routinetätigkeiten

Verbesserter Wissensaustausch in und zwischen Geschäftsprozessen

82

■ ■ ■

mationen und Anwendungen personalisiert zur Verfügung. Voraussetzung für die lückenlose Funktionsunterstützung über die ganze Prozesskette hinweg ist eine vollständige Integration aller für den Prozess relevanten Informationen und Systeme. Mit der Modellierung von Geschäftsprozessen und deren (teil-) automatisierter Steuerung geht die Standardisierung dieser Prozesse einher. Die Soll-Beschreibung eines Geschäftsprozesses bzw. seiner möglichen praktischen Ausprägungen (Geschäftsvorfälle) wird in der Workflowsteuerung des Unternehmensportals hinterlegt. Da das Unternehmensportal die zentrale Steuerung und Kontrolle der Geschäftsprozesse übernimmt, wird über Abteilungs- und Anwendungsgrenzen hinweg sichergestellt, dass sich die Abarbeitung der Prozesse an dem gewünschten Soll-Ablauf orientiert. Neben einer einheitlichen Qualität der Prozessabläufe wird durch die Standardisierung der Geschäftsprozesse eine erhöhte Prozesstransparenz und daraus resultierend eine verbesserte Planbarkeit realisiert. Daneben verringert eine eindeutige Workflowdefinition den Einarbeitungsaufwand für neue Mitarbeiter und standardisiert unternehmensweit die Ergebnisse der verschiedenen Prozessketten. Die Motivation der Mitarbeiter ist ein weiteres Ziel, das durch die Veränderung von Prozessen erreicht werden kann. Insbesondere die technische Unterstützung aller automatisierbaren routinemäßigen Tätigkeiten bedeutet für viele Mitarbeiter – vom Manager bis zum Sachbearbeiter – eine qualitative Aufwertung ihrer Arbeit, da sie sich nun auf die kreativeren und strategischen Aspekte ihrer Tätigkeit konzentrieren können. Damit einhergehend wird – wiederum durch die Erhöhung der Transparenz – für jeden Mitarbeiter das Verständnis für innerbetriebliche Strukturen und Abläufe vertieft, so dass dieser die Prozesse zielgerichtet verwenden kann. Die Befreiung von lästigen manuellen Routinetätigkeiten führt zudem oft zu einer erheblichen Effizienzsteigerung. Ein weiteres Ziel, das im Zusammenhang mit der Prozessoptimierung durch ein Unternehmensportal steht, ist die Verbesserung des Wissensaustauschs innerhalb eines Geschäftsprozesses und zwischen den Geschäftsprozessen. Durch ein gezieltes Management des Prozesswissens lässt sich ein kontinuierlicher Lern- und Verbesserungsprozess im Unternehmen etablieren.

4 Fachliche Anforderungen

Abb. 4.1 Wissensflüsse in Geschäftsprozessen

a

Prozess A Fall 1

b

Prozess A Fall 2

c

Prozess B Fall 1

Wie in Abbildung 4.1 dargestellt, können hauptsächlich drei wichtige Arten von Wissensflüssen in und zwischen Geschäftsprozessen unterschieden werden. Im Fall (a) wird Wissen zwischen den einzelnen Schritten eines Prozesses ausgetauscht, d.h. das in einem Schritt gewonnene Wissen wird an den nächsten Schritt weitergegeben. Fall (b) beschreibt den Austausch von Erfahrungen zwischen zwei verschiedenen Geschäftsvorfällen desselben Geschäftsprozesses. Hier wird das in einem zeitlich früheren Prozessdurchlauf gewonnene Wissen späteren Geschäftsvorfällen zur Verfügung gestellt. Im Fall (c) werden die Grenzen des Geschäftsprozesses überwunden und Wissen zwischen zwei verschiedenen Geschäftsprozessen ausgetauscht. So profitieren die Geschäftsprozesse auch von den in anderen Geschäftsprozessen gewonnenen Erfahrungen. Das Unternehmensportal muss diese Wissensprozesse mit den Geschäftsprozessen verknüpfen. Dazu müssen die Wissensflüsse bei der Prozessmodellierung berücksichtigt werden. Das Portal stellt dazu einen Datenspeicher zur Verfügung, in dem das gewonnene Wissen abgelegt werden kann. Auf diesen Speicher greifen wahlweise andere Geschäftsvorfälle direkt zu und rufen das für sie relevante Wissen ab, oder sie werden durch den Datenspeicher benachrichtigt. Durch das Management des Prozesswissens kann ein Lernprozess im Unternehmen etabliert werden, durch den die Geschäftsprozesse

4.1 Abbildung und Steuerung von Geschäftsprozessen

■ ■ ■

83

Reduktion auf prozessrelevante Daten und Anwendungen

Push- und PullMechanismen

Flexible Anpassung an veränderte Bedingungen

84

■ ■ ■

kontinuierlicher verbessert und stets den sich verändernden Gegebenheiten angepasst werden können. Ein Unternehmensportal soll neben der Quantität der verfügbaren Informationen auch deren Qualität steigern. Dies bedeutet auf der einen Seite, dass sich durch das Verweben von Daten und Informationen über die Integrationsmechanismen des Portals die Aussagekraft und Tiefe der für den einzelnen Mitarbeiter verfügbaren Informationen erhöht. Auf der anderen Seite bedeutet dies aber auch, dass dem einzelnen Mitarbeiter in erster Linie nur die für seinen Arbeitskontext relevanten Informationen präsentiert werden. Die beschriebene Funktionsunterstützung selektiert die für den jeweiligen Prozessschritt relevanten Informationen und stellt sie dem Benutzer dann zur Verfügung, wenn er sie benötigt. Bei „herkömmlichen“ Prozessen, die nicht auf einer integrierten Systemlandschaft basieren, sind die Bearbeiter der einzelnen Prozessschritte gezwungen, sich die notwendigen Informationen aus einer Vielzahl verschiedener Informationsquellen selbst zu beschaffen. Dies erfordert Kenntnisse über Bedienung, Aufbau und Navigation einer Vielzahl verschiedener Anwendungen. Außerdem setzt dieses Vorgehen voraus, dass der Bearbeiter weiß, in welchen Datenquellen des Unternehmens die für ihn relevanten Informationen zu dem jeweiligen Zeitpunkt zu finden sind. Die automatische Selektion und Filterung der kontextrelevanten Informationen in Unternehmensportalen hilft, Streuverluste bei der Informationsrecherche zu vermeiden und verringert dadurch die Bearbeitungszeit der einzelnen Prozessschritte erheblich. Die kontextbezogenen Informationen, die dem Benutzer des Unternehmensportals zur Verfügung gestellt werden, können als Pushoder Pull-Dienste realisiert werden. Bei einem Push-Vorgang werden dem Benutzer die für ihn relevanten Daten vom Portal direkt präsentiert. Dies ist in Anwendungsfällen sinnvoll, in denen Benutzer über wichtige Nachrichten und Neuigkeiten informiert werden sollen. Bei einem Pull-Dienst holt sich der Bearbeiter die von ihm gewünschten Informationen selber ab. Prozesse sind einem stetigen Wandel unterworfen – um so wichtiger ist es, dass technikgestützte Prozesse bzw. die den Prozess implementierende Technik flexibel genug sind, um diesen Wandel zu ermöglichen und zu unterstützen. Ein Portal wird nur dann dauerhaft zum Geschäftserfolg des Unternehmens beitragen, wenn es sich an veränderte Rahmenbedingungen des Unternehmens anpassen kann. Aus diesem Grund sollen Prozesse nicht „hart im Programmcode verdrahtet“ werden, sondern in einem anwendungsneutralen, offenen und leicht modifizierbaren Format vorliegen. Ein Beispiel für eine

4 Fachliche Anforderungen

solche Prozessbeschreibung liefert das WfMC Workflow Reference Model (vgl. Abschnitt 7.7). Die Prozessbeschreibung muss sich über eine möglichst intuitive Benutzungsoberfläche einfach adaptieren lassen. Neben der Anpassung bestehender Prozesse spielt das möglichst einfache Aufsetzen neuer Prozessketten eine entscheidende Rolle, um ein Portal langfristig erfolgreich einsetzen zu können. Mangelt es einem Unternehmensportal an dieser Flexibilität, so wird sich schnell eine sinkende Benutzerakzeptanz einstellen. Außerdem wird ein Unternehmensportal dann seinem Anspruch, das zentrale Werkzeug zu allen Informationen und Anwendungen im Unternehmen zu sein, nicht mehr gerecht werden können. Die mangelnde Fähigkeit des Portals, sich mit dem Unternehmen zu entwickeln, wird durch Insellösungen außerhalb des Portals aufgefangen werden müssen. Damit ist das Unternehmensportal zum Scheitern verurteilt, da es dem Ziel, den zentralen Zugang zu allen Anwendungen und Informationen des Unternehmens darzustellen, nicht mehr gerecht werden kann. Durch die Identifikation und Beschreibung der Kernprozesse des Unternehmens können Soll-Vorgaben für die einzelnen Schritte dieser Prozessketten definiert werden. Aus diesen lassen sich Indikatoren und Messkriterien für Erfolgsfaktoren ableiten. Messkriterien können beispielsweise Kennzahlen für die Durchlaufzeiten einzelner Prozessschritte oder quantitative Vorgaben für die Ergebnisse eines Prozesses pro Zeiteinheit sein. Die technische Steuerung der Geschäftsprozesse macht durch Überwachungsmechanismen die Ergebnisse und Durchlaufzeiten des Prozesses messbar. Die aktuellen Informationen aus den Prozessen werden gegen die hinterlegten Messkriterien geprüft und machen so Abweichungen zwischen den Vorgaben und dem Ablauf der Prozesse sichtbar. Durch die Messbarkeit der Geschäftsprozesse lassen sich Optimierungspotenziale bei der Gestaltung der Prozessabläufe aufzeigen. Auch Veränderungen im Nutzerverhalten können über die Kontrollmechanismen des Portals erkannt werden. Durch die Messbarkeit der Geschäftsprozesse lassen sich wertvolle Erfahrungen in Bezug auf das Prozessmanagement gewinnen, die auch die Modellierung späterer Prozesse positiv beeinflussen.

4.1 Abbildung und Steuerung von Geschäftsprozessen

Messbarkeit

■ ■ ■

85

Die fachlichen Anforderungen an die Abbildung und Steuerung von Geschäftsprozessen lassen sich wie folgt zusammenfassen: Anforderungskatalog: Abbildung und Steuerung von Geschäftsprozessen

86

■ ■ ■

■

Durchgängige Prozesse: Die Modellierung von Geschäftsprozessen soll sich an fachlichen Gesichtspunkten orientieren und nicht durch technische Rahmenbedingungen diktiert werden.

■

Gesteigerte Prozessqualität: Die Etablierung von Vorgehensstandards und Qualitätssicherungsmechanismen wird durch die technische Unterstützung strukturierter Geschäftsprozesse erleichtert.

■

Steigerung der Produktivität: Ein Unternehmensportal kann die Produktivität der Mitarbeiter und somit auch der Geschäftsprozesse erhöhen, z.B. durch die Vermeidung von Streuverlusten bei der Suche und eine intuitive, ergonomische Benutzungsoberfläche.

■

Reduzierung der Prozesskosten: Die technische Prozesssteuerung reduziert die direkten Prozesskosten, z.B. durch die Beschleunigung und Automatisierung von Prozessen oder die Verringerung von Kommunikationsaufwänden.

■

Erhöhte Transparenz: Durch die technische Steuerung werden Prozessabläufe nachvollziehbar. Dies erhöht einerseits die Auskunftsfähigkeit des Unternehmens nach innen und nach außen und gibt andererseits wichtige Hinweise für eine weitere (kontinuierliche) Verbesserung der Prozesse.

■

Flexible Definition: Geschäftsprozesse sollen so modelliert werden, dass sie sich flexibel an die sich ständig verändernden Rahmenbedingungen des Unternehmens anpassen können.

■

Erhöhte Mitarbeitermotivation: Durch die technische Unterstützung aller automatisierbaren routinemäßigen Tätigkeiten wird die Arbeit der Mitarbeiter qualitativ aufgewertet.

■

Kontinuierlicher Lern- und Verbesserungsprozess: Durch ein gezieltes Management des Prozesswissens lernt das Unternehmen aus den eigenen Erfahrungen, und es etabliert sich ein kontinuierlicher Lernprozess im Unternehmen.

4 Fachliche Anforderungen

4.2 Einheitliche integrierte Sicht auf Daten Die Heterogenität der Unternehmensinformationen stellt seit jeher die größte Herausforderung für das softwaregestützte Informationsmanagement dar. Informationen unterscheiden sich hinsichtlich ihres Gehalts, ihrer Relevanz im Kontext verschiedener Geschäftsprozesse, ihres Strukturierungsgrades und nicht zuletzt ihrer Quelle, d.h. dem technischen Ort der Datenspeicherung. Das Ziel des Informationsmanagements ist es, die im gegebenen Kontext relevanten Informationen zu ermitteln und dem Benutzer gefiltert zur Verfügung zu stellen, so dass dieser auf die manuelle Datenselektion verzichten und sich auf die strategische Analyse der Daten konzentrieren kann. Die Informationen müssen aus fachlichen Bedürfnissen heraus miteinander in Beziehung gesetzt werden können, ohne dass technische Systemgrenzen im Weg stehen. In der Praxis behindern aber genau diese Systemgrenzen ein ganzheitliches Informationsmanagement und eine durchgängige Prozessmodellierung. In der IT-Infrastruktur der meisten Unternehmen findet sich eine Vielfalt von Plattformen, Datenbankmanagementsystemen und Technologien: ERP-Systeme, Legacy-Datenbanken, Cobol-Programme, selbst entwickelte Datenbankanwendungen und Groupware-Applikationen – um nur einen Ausschnitt der möglichen Bandbreite zu nennen. Dabei orientiert sich die Art der Datenhaltung nicht an den fachlichen Geschäftsprozessen, sondern am technischen Anwendungszweck der datenhaltenden Applikation. Erschwerend kommt hinzu, dass viele Informationen genau aus diesem Grund redundant in verschiedenen Systemen gehalten werden. Die Forderung nach einer durchgängigen IT-gestützten Prozesssteuerung impliziert somit auch die Forderung nach einer Zugriffsschicht, welche die heterogenen Systeme der IT-Landschaft kapselt und die Kommunikation zwischen Clients und den datenhaltenden Systemen regelt. Aus Sicht der Anwendungssysteme abstrahiert die Zugriffsschicht von der Vielfalt der Datenquellen und stellt nach außen eine virtuelle, zentrale Informationsquelle dar. Dazu greift die Zugriffsschicht über Adapter – für das jeweilige System maßgeschneiderte Schnittstellen – auf die datenhaltenden Systeme zu und vermittelt bei der Kommunikation zwischen Backend und ClientAnwendungen. Abbildung 4.2 visualisiert die Zugriffsschicht als zentrale Informationsquelle für das Portal. Die Funktionen dieser Informationsquelle werden im Folgenden genauer beschrieben.

4.2 Einheitliche integrierte Sicht auf Daten

Kapselung der Informationszugriffe

■ ■ ■

87

Abb. 4.2 Zugriffskapselung datenhaltender Systeme

Virtuelle zentrale Informationsquelle Übersetzen und Abbilden Datentransformation Kommunikation

Metadaten

Adapter

Backend-Systeme

Virtuelle, zentrale Informationsquelle

Metadaten

Eine derartige virtuelle, zentrale Informationsquelle erschließt das relevante Informationsspektrum eines Unternehmens für ein Unternehmensportal: Strukturierte Daten, wie sie in ERP-Systemen und Legacy-Applikationen verwaltet werden, extrahierte, aufbereitete Daten aus Data-Warehouse-Systemen sowie die großen Mengen unstrukturierter Informationen, die in DokumentenmanagementSystemen, Dateisystemen, Mailservern oder Intranets zu finden sind. Doch mit dem reinen Erschließen der Informations- und Anwendungsvielfalt des Unternehmens ist noch nicht die Frage nach der Kontextrelevanz der Information beantwortet. Dazu muss das Informationsspektrum analysiert, strukturiert und um Taxonomien (Wortschätze) für verschiedene Geschäftsfelder und -prozesse angereichert werden. Es muss möglich werden, die Informationen nach ihrer Relevanz für einen gegebenen Kontext zu bewerten. Taxonomien stellen die Auffindbarkeit von Dokumenten sicher, auch wenn der Portalbenutzer deren genauen Inhalt nicht kennt. Ferner muss der Schutz vor unbefugter Kenntnisnahme der Daten gewährleistet werden, wobei der rechtmäßige Datenzugriff für verschiedene Benutzergruppen und Informationsbereiche unterschiedlich sein kann. Um Informationen unterschiedlicher Struktur und Herkunft über eine zentrale Schnittstelle auffindbar zu machen, müssen umfassende Metadaten über diese Informationen zur Verfügung stehen. Metadaten (Daten über Daten) sind strukturierte Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser auffindbar gemacht wird.

Terminologiebasierte Integration

88

■ ■ ■

Um Daten zwischen verschiedenen technischen Systemen, aber auch zwischen Unternehmen flexibel austauschen zu können, muss eine gemeinsame Begriffswelt geschaffen werden. Bei dieser sogenannten terminologiebasierten Integration wird die fachspezifische Ter-

4 Fachliche Anforderungen

minologie (Taxonomie) der Anwendungsbereiche global rekonstruiert, normiert und in einem gemeinsamen Lexikon oder Glossar festgehalten. Taxonomien stellen somit auch Metadaten dar. Die zentrale Definition des Domänenwissens eines Unternehmens, separat von den konkreten Anwendungen, erleichtert zudem dessen Administration und die Integration neuen Wissens. Die Kommunikation zwischen Systemen, die unterschiedliche, jedoch synonyme Terminologien verwenden, kann über diese global rekonstruierte Normsprache stattfinden, ohne dass die Normsprache von den Kommunikationspartnern selbst beherrscht werden muss. Die Normsprache ist ein fachliches Wörterbuch, das der Übersetzung zwischen fachlichen Terminologien dient. Wie in Abb. 4.2 dargestellt, übernimmt die virtuelle Informationsquelle mehrere Aufgaben. Zum einen stellt sie die Kommunikation zwischen den Backend-Systemen und dem Portal über Adapter her. Zum anderen bedient sie sich des hinterlegten fachlichen Wörterbuchs in Form von Metadaten, um die Begriffswelten der einzelnen Unternehmensanwendungen in eine einheitliche und eindeutige Sprache zu übersetzen. Auf diese Weise können die Informationen aufeinander abgebildet werden und beispielsweise durch Zusammenfassung, Vergleich oder Hinzufügen zu höherwertigen Informationsobjekten weiterverarbeitet werden. Eine weitere Aufgabe der virtuellen Informationsquelle ist die Transformation der Quelldaten, um sie z.B. durch eine Formatkonvertierung dem Zielsystem entsprechend aufzubereiten. Durch die Kapselung der Komplexität der Datenhaltung ergeben sich neue Möglichkeiten für die Modellierung von Informationsobjekten. Während sich Quantität und Qualität der verfügbaren Informationen bislang an den Kapazitäten der einzelnen datenhaltenden Systeme orientieren mussten, ermöglicht eine integrierte Informationsquelle, Informationen nach fachlichen Gesichtspunkten und geschäftsprozessbedingten Notwendigkeiten zu definieren. Die Informationen aus den einzelnen Systemen können zueinander in Beziehung gesetzt und fachlich miteinander verwoben werden. Dies ermöglicht die Modellierung von neuen Informationsobjekten, beispielsweise für eine ganzheitliche Sicht auf den Kunden oder zur Unterstützung eines speziellen Prozessschrittes innerhalb einer Prozesskette. Dadurch lassen sich Prozessdurchlaufzeiten verringern, Dienstleistungen verbessern und die Auskunftsfähigkeit des Unternehmens erhöhen. Darüber hinaus ist, wie bereits dargestellt, eine integrierte Sicht auf die Unternehmensdaten die kritische Voraussetzung für die Abbildung und Steuerung durchgängiger Geschäftsprozesse. Durchgängige Geschäftsprozesse müssen sich damit nicht an

4.2 Einheitliche integrierte Sicht auf Daten

Aufgaben einer zentralen Zugriffsschicht

Verringerte Komplexität

■ ■ ■

89

Informationsqualität

Systemgrenzen und der Verfügbarkeit von Daten orientieren, sondern lassen sich fachlich orientiert modellieren. Doch auch in technischer Hinsicht verringert eine zentrale Zugriffsschicht die Gesamtkomplexität eines Portalsystems. Die Zugriffsschicht stellt für das Portal einen virtuellen Informationsspeicher dar, mit dem es über eine definierte Schnittstelle kommuniziert. Verfügt das Portal nicht über diesen gekapselten Informationszugriff, dann muss es einzeln auf die verschiedenen Schnittstellen der datenhaltenden Systeme zugreifen. Dies stellt die Implementierung eines Portals vor eine große Herausforderung. Das Portal muss die Komplexität der IT-Landschaft abbilden und in jeder einzelnen Portalapplikation die Sprache der datenliefernden Systeme implementieren. Dadurch entsteht eine große Anzahl im Portal fest kodierter Kommunikationsschnittstellen. Sollen weitere Systeme ergänzt oder bestehende ausgetauscht werden, kann dies durch erhebliche Anpassungen der vorhandenen Portallogik realisiert werden. Aus Sicht des Portalbetriebs führt eine zentrale Zugriffskapsel zu einer Reduktion der zu pflegenden Schnittstellen. Kommunikationsschnittstellen, die durch Neueinführung oder Austausch eines datenliefernden Systems oder durch Modifikation und Ergänzung der Portalapplikationen notwendig werden, lassen sich an einer zentralen Stelle verwalten (vgl. Abschnitte 2.2 und 5.1.4). Je größer die in einem Unternehmen zu verwaltende Informationsmenge ist, desto mehr Bedeutung kommt der Bewertung und Kontrolle der Informationsqualität zu. Die Abstraktion von den datenhaltenden Systemen ist der erste Schritt eines durchgängigen Managements der Informationsqualität. Bevor die Möglichkeiten eines Portals als Instrument zur Etablierung und Sicherung von Qualitätsstandards eruiert werden, wird im Folgenden der Begriff Informationsqualität genauer betrachtet. Ein Qualitätsmerkmal ist nach Schwarze (1998) eine an einem Qualitätsobjekt feststellbare qualitative oder quantitative Eigenschaft, durch die gleichartige Qualitätsobjekte unterschieden werden und die für die Messung, die Beurteilung und die Bewertung von Qualität herangezogen werden können. Qualitätsrichtlinien müssen, um als Bewertungsmaßstab dienen zu können, objektiv formuliert sein. Für das Informationsmanagement haben Königer und Reithmayer (1998) folgende Kategorien für eine Qualitätsbewertung definiert:

90

■ ■ ■

4 Fachliche Anforderungen

Kategorie

Dimension

Innere Qualität

Genauigkeit, Objektivität, Vertrauenswürdigkeit Zugänglichkeit, Sicherheit Bedeutung, Mehrwert, Zeitgerechtheit, Vollständigkeit, Informationsgehalt Interpretierbarkeit, Verständlichkeit, Knappheit, Durchgängigkeit Existenz, Angemessenheit, Interpretierbarkeit Existenz, Angemessenheit, Nachvollziehbarkeit

Zugangsqualität Kontextuelle Qualität Darstellungsqualität Qualität der Metainformationen Qualität der Strukturierung

Stellt man nun diesen Qualitätskategorien die bereits beleuchteten Potenziale einer virtuellen zentralen Informationsquelle gegenüber, lässt sich schnell erkennen, dass die Qualität der Informationen durch die Kapselung des Datenzugriffs in vielen Kategorien praktisch automatisch steigt. Dabei wird die Bedeutung einer konsequenten Pflege der Metadaten deutlich. Aufbauend auf einer integrierten und einheitlichen Sicht auf die Daten und Informationsobjekte des Unternehmens, müssen Standards zur Etablierung und Sicherung der Informationsqualität im Unternehmen verankert werden. Neben der Erhöhung der Qualität der verfügbaren Informationen ist auch eine verstärkte Wiederverwendung und Wiederverwertung von Informationsobjekten das Ziel eines stringenten Informationsmanagements. Dazu muss unternehmensweit definiert werden, welche Eigenschaften Informationen haben müssen. Ein Portal stellt hier nur die technische Basis zur Pflege dieser Standards. Das Management der Informationsqualität ist aber eine gesamtbetriebliche Aufgabe. Im Unternehmen müssen Standards für das Management von Informationen eingeführt werden. Diese geben Anweisungen für die Erstellung von Daten und schreiben Metadaten vor, die zu einem bestimmten Datentyp erfasst werden müssen. Dem Portal kommen dabei zwei Aufgaben zu. Zum einen repräsentiert es in seiner virtuellen Informationsquelle sämtliche relevanten Daten des Unternehmens. Auf diese Weise wird sichergestellt, dass alle Daten in die Betrachtung der Informationsqualität einbezogen werden und diese Sicht nicht auf einige wenige Systeme beschränkt bleibt. Zum anderen kann das Portal, z.B. durch Eingabeaufforderungen in den Datenpflegemasken bei der Etablierung der Qualitätsstandards unterstützen.

4.2 Einheitliche integrierte Sicht auf Daten

Tabelle 4.1 Kategorien für eine Qualitätsbewertung des Informationsmanagements (nach Königer u. Reithmayer 1998)

Qualitätsstandards

■ ■ ■

91

Die Kapselung des Informationszugriffs erhöht im Sinne eines technischen Datenzugriffs durch eine einheitliche Beschreibung der Informationsobjekte deren Auffindbarkeit und Wiederverwertbarkeit. Business Intelligence

Knowledge Management

Die Steuerung eines Unternehmens erfordert aussagekräftige Kennzahlen über die Kostenstruktur und die Leistungsfähigkeit der Geschäftsprozesse. Business-Intelligence-Werkzeuge stellen dem Management des Unternehmens umfassende Auswertungen und Informationen zur Entscheidungsfindung sowie zur Steuerung und Kontrolle des Unternehmens zur Verfügung. Bislang waren BusinessIntelligence-Anwendungen oft Stand-Alone-Lösungen, denen die für ihre Auswertung relevanten Daten explizit zur Verfügung gestellt werden mussten. In vielen Fällen verhindert das langwierige Beschaffen von Daten aus verschiedenen Quellen aber die Ad-hocVerfügbarkeit wichtiger Informationen und macht damit schnelle Entscheidungen entweder unmöglich oder zu einer Frage der Intuition. Durch die Repräsentation der Unternehmensdaten in einer virtuellen zentralen Informationsquelle wird dagegen prinzipiell das gesamte Datenspektrum des Unternehmens zu Auswertungszwecken herangezogen. Daneben erlaubt die technische Steuerung der Kerngeschäftsprozesse, kennzahlrelevante Daten für die Auswertung direkt aus den Geschäftsvorfällen dieser Prozesse zu extrahieren. Auf dieser Basis setzen die Business-Intelligence-Werkzeuge des Portals auf. Sie konsolidieren und homogenisieren die vorhanden Daten. Durch hinterlegte Auswertungs- und Analysealgorithmen werden die Daten zu Kennzahlen aufbereitet. Über das Portal können die Anwender diese Kennzahlen abrufen, auswerten und zueinander in Verbindung setzen. Somit werden Mitarbeiter von zeitintensiver manueller Selektion und Aufbereitung von Informationen entlastet. Auf diese Weise lassen sich Entscheidungen auf Basis aktueller Informationen treffen und Fehlentwicklungen frühzeitig erkennen und vermeiden. Der Erfolg der getroffenen Entscheidungen lässt sich wiederum mit den Techniken des Business Intelligence überprüfen. Neben der Ermittlung von Kennzahlen dient die einheitliche Sicht auf die Unternehmensdaten aber auch der Generierung von Wissen aus den vorhandenen Informationen. Dies geschieht mit Hilfe der Werkzeuge und Methoden des Knowledge Managements. Knowledge Management ist nach Klaus (2004) der Prozess zielorientierter Gestaltung der Wissensgenerierung, des Wissenstransfers, der Wissensspeicherung und der Wissensnutzung.

92

■ ■ ■

4 Fachliche Anforderungen

Insbesondere Wissenstransfer und Wissensnutzung sind in heterogenen Systemlandschaften mit einer Vielzahl datenhaltender Systeme kaum oder nur schwer möglich. Auch die Generierung von Wissen stellt bereits eine Herausforderung dar. Wissen entsteht, indem Informationen miteinander in Beziehung gesetzt und in einen prozessorientierten Kontext eingebunden werden. In der Praxis scheitern die Bemühungen um die Generierung von Wissen nicht selten an nicht überwindbaren Systemgrenzen. Die Kapselung des Informationszugriffs ist die Voraussetzung für ein interaktives und dynamisches Wissensmanagement. Die Werkzeuge des Knowledge Management vernetzen, aggregieren und analysieren die vorhandenen Informationen und transformieren sie so in handlungs- und entscheidungsrelevantes Wissen. Dazu werden den einzelnen Informationsobjekten Kategorien zugeordnet. Für die Strukturierung der Informationen hat sich der Topic-Map-Standard bewährt (vgl. Abschnitt 7.8.3). Dieser ermöglicht eine semantische Beschreibung der Informationsobjekte und ihrer Beziehungen zueinander. Ergänzend stellt die Prozesssteuerung des Portals mittels Knowledge Management erzeugte Wissen kontextsensitiv in den einzelnen Prozessschritten zur Verfügung. Damit lassen sich für die integrierte Sicht auf die Unternehmensdaten folgende fachliche Forderungen definieren: ■

Fachliches Verweben von Daten: Daten sollen fachlich motiviert zueinander in Beziehung gesetzt und miteinander verwoben werden. Dazu muss vom tatsächlichen Ort der Datenspeicherung abstrahiert werden können.

■

Kontextrelevanz: Informationen stellen nur in Zusammenhang zu einem fachlichen Kontext einen Wert dar. Über Taxonomien müssen Informationsobjekte eindeutig beschrieben werden, so dass diese gezielt wieder aufgefunden und zu anderen Informationsobjekten in Beziehung gesetzt werden können.

■

Höhere Informationsqualität – Über die Etablierung von Standards für das Informationsmanagement lässt sich die Qualität der verfügbaren Informationen steigern. Eine gesteigerte Qualität der Informationen erhöht nicht nur den fachlichen Gehalt der Informationen, sondern auch die Wiederverwendbarkeit und Wiederverwertbarkeit der Informationen.

■

Aktualität der Kennzahlen: Kennzahlen für die strategische Entscheidungsfindung und Informationen für externe Anteilseigner müssen jederzeit ad hoc abgerufen werden können.

4.2 Einheitliche integrierte Sicht auf Daten

Anforderungskatalog: Einheitliche integrierte Sicht auf Daten

■ ■ ■

93

■

Wissensmanagement: Über ein gezieltes Wissensmanagement wird für das Unternehmen transparent, was es tatsächlich weiß. Die Mechanismen des Wissensmanagements unterstützen den Wissenstransfer und die Wissensnutzung im Unternehmen.

4.3 Personalisierung Der Begriff der Personalisierung gehört zu den Schlagworten, die in jeder Diskussion zu den Themen Portale und Content Management auftauchen. Personalisierung wird gerne als Wunderwaffe zur Kundenbindung und Absatzsteigerung dargestellt. Aber was bedeutet Personalisierung wirklich? Grundsätzlich bedeutet Personalisierung, dass sich das Portal nicht für alle Benutzer mit demselben Funktions- und Informationsangebot und nicht mit derselben Gestaltung der Benutzungsoberfläche präsentiert. Diese werden vielmehr speziell auf die unterschiedlichen Belange der Benutzer zugeschnitten. Es lassen sich folgende Arten der Personalisierung unterscheiden:

Personalisierung nach Rollen

94

■ ■ ■

■

Personalisierung nach Rollen,

■

Personalisierung nach persönlichen Einstellungen,

■

implizite Personalisierung.

Unter einer Personalisierung nach Rollen als Form der expliziten Personalisierung versteht man das aufgabenbezogene Selektieren und Filtern von Informationen und Anwendungen. Jedem Benutzer des Portals ist mindestens eine Rolle zugeordnet. Mit diesen Rollen sind Zugriffsrechte auf Informationen und Anwendungen verknüpft. Dem Benutzer werden kontextbezogen nur die Informationen angezeigt und Anwendungen bereitgestellt, die seiner Rolle entsprechen und zur Erledigung der jeweiligen Aufgabe dienen. Durch die Informationsfilter der Personalisierung wird der Aufwand für das Finden und Bewerten der relevanten Informationen reduziert. Darüber hinaus verhindert ein stringentes Management der Zugriffsrechte einer Rolle, dass für den Benutzer Informationen zugänglich sind, die nicht für ihn bestimmt sind. Abbildung 4.3 illustriert die Zusammenstellung und Auswahl von Applikationen und Informationen entsprechend der Rolle des Bearbeiters und seines jeweiligen Arbeitskontextes bei der rollenbasierten Personalisierung.

4 Fachliche Anforderungen

Abb. 4.3 Rollenbasierte Personalisierung

Applikationen

A1 A2 A3

I1 I2 I3 I4

A2

Personalisierungsfilter

Informationsquellen

I1

I4

Portal

Prozessschritt 1 I2

I4

Prozessschritt 2

A1

A3

I3

Prozessschritt 3 Rollen

R1 R2

Die Personalisierung nach persönlichen Einstellungen ist eine weitere Form der expliziten Personalisierung. Darunter versteht man das benutzerspezifische Aufbereiten und Darstellen von Informationen und Anwendungen entsprechend den Angaben, die der Benutzer selbst gemacht hat. Der Benutzer hat so die Möglichkeit, sich eine für seine persönlichen Vorlieben und Arbeitsweisen optimale Portaloberfläche zu konfigurieren. Der Gestaltungsspielraum reicht dabei von der Anordnung der Applikationen auf der Portaloberfläche, über Layoutangaben (wie z.B. Typographie, Farbgebung) bis zum Abonnement bestimmter optionaler Dienste und Anwendungen. Die Möglichkeit des Benutzers, sich sein Portal nach individuellen Vorstellungen und Interessen gestalten zu können, erhöht die Benutzerfreundlichkeit und trägt zur Benutzerakzeptanz des Portals bei. Im Unterschied zu der expliziten Personalisierung werden bei der impliziten Personalisierung Informationen über eine Person (Benutzer) gesammelt, analysiert und so passende Inhalte und Kategorien für diese Person identifiziert. Die Herausforderung besteht darin, aus den vorhandenen Informationen über das Verhalten des Portalnutzers zusätzliches Wissen zu generieren und in die eigene Wertschöpfung einzubringen. Dazu werden im Rahmen der jeweils gültigen Datenschutzgesetze und -bestimmungen verschiedene Verfahren innerhalb des Web Mining angewandt.

4.3 Personalisierung

Personalisierung nach persönlichen Einstellungen

Implizite Personalisierung

■ ■ ■

95

Als Web Mining wird das Sammeln von Informationen über Webseitenbesucher bezeichnet. Dazu wird das Verhalten (z.B. Kauf- und Navigationsverhalten) des Webseitenbesuchers aufgezeichnet (User Tracking). Ziel des Web Mining ist es, die gewonnenen Informationen zu Benutzerprofilen zu verdichten, um eine differenzierte Segmentierung, Klassifizierung und Bewertung von Kundengruppen vorzunehmen. Anhand der Profile können Angebote zielgruppenorientiert aufbereitet und Werbung sinnvoll platziert werden. Die implizite Personalisierung ist hauptsächlich für externe Kundenportale von Bedeutung. Informationen, die auf diese Weise gewonnen werden können, sind z.B. das Browse- und Kaufverhalten von Benutzern in einem Online-Shop. Basierend auf diesen Informationen werden die Inhalte des Shops benutzerspezifisch aufbereitet. Doch auch in Unternehmensportalen kann die implizite Personalisierung für bestimmte Anwendungsfälle sinnvoll eingesetzt werden. So kann es beispielsweise für den Benutzer hilfreich sein, wenn er die Dokumente oder Kundendatensätze angezeigt bekommt, die er in seiner vorherigen Portalsitzung als letztes bearbeitet hat. Personalisierung bietet somit die Möglichkeit, den Benutzer zumindest vor einem Teil der Informationsflut zu bewahren und ihm nur die Informationen und Anwendungen zu präsentieren, die für seine Aufgaben und Interessengebiete relevant sind. Abb. 4.4 Der Regelkreis der Personalisierung

Portal

Personalisierung

Benutzerprofile

Informationsgewinnung Informationsanalyse

Informationsspeicher

Abbildung 4.4 visualisiert, wie sich die verschiedenen Arten der Personalisierung zu einem Regelkreis kombinieren lassen. Auf Basis

96

■ ■ ■

4 Fachliche Anforderungen

der in den Benutzerprofilen hinterlegten Rollen werden Informationen gefiltert und im Portal dargestellt. Informationen über das Verhalten des Benutzers werden ermittelt, analysiert und für eine implizite Personalisierung gespeichert. Die vom Benutzer eingegebene Konfiguration seiner persönlichen Portaloberfläche wird im Benutzerprofil gespeichert und zur personalisierten Darstellung der Portaloberfläche genutzt. Bei ihren Überlegungen, wie man Kunden auch online einen optimalen Service anbieten kann, stieß die Marketingabteilung von Wein&Dein schnell auf das Thema Personalisierung. Ein Benchmarking mit anderen Portalen und Online-Shops aus ähnlichen Branchen ergab, dass ein Mix aus expliziten und impliziten Personalisierungsmethoden den größten Kundenmehrwert bietet. Die Marketingabteilung erstellte daraufhin ein Konzept, dass die Erweiterung des persönlichen Bereichs der Kunden im Portal vorsah. Zusätzlich zu den Adressinformationen sollten Kunden hier nun auch das Wein&Dein-Portal nach ihren eigenen Vorlieben und Interessen konfigurieren können. Neben der Festlegung von Startseiten für die einzelnen Menübereiche des Portals und der Filterung des Informationsangebots nach Interessensschwerpunkten (z.B. Rotweine aus Frankreich, Sonderangebote), sollten Kunden auch die grafische Präsentation des Portals individuell beeinflussen können. Neben diesen expliziten Personalisierungsmechanismen wollte Wein&Dein nun auch ein konsequentes User Tracking durchführen. Durch die Analyse des Benutzerverhaltens sollte es möglich werden, dem Kunden kontextrelevante Informationen automatisch anzeigen zu können. Über einen virtuellen Zwischenspeicher sollten Kunden direkt auf die zuletzt besuchten Produkte zugreifen können. Die Auswertung des Kaufverhaltens sollte es ermöglichen, Kunden aktiv die von ihnen bevorzugten Produkte zu präsentieren. Eine „Kunden, die X gekauft haben, haben auch Y gekauft“-Funktion wiederum sollte Kunden zum Kauf von Produkten animieren, die bislang noch nicht von ihnen erworben wurden. Nach der Einführung der geplanten Maßnahmen war die Marketingabteilung selbst über den schnellen Erfolg ihrer Ideen verwundert. Eine stichprobenartige Befragung der Kunden ergab eine gesteigerte Benutzerzufriedenheit mit dem Portalangebot von Wein&Dein. Bereits nach wenigen Monaten machten sich die Investitionen in die Personalisierungsfunktion des Portals bezahlt. Der Umsatz über das Portal hatte sich um über zwölf Prozent erhöht.

4.3 Personalisierung

■ ■ ■

97

Anforderungskatalog: Personalisierung

Zu den fachlichen Anforderungen an ein personalisiertes Unternehmensportal gehören: ■

Hohe Benutzerfreundlichkeit: Benutzer können sich die Portaloberfläche entsprechend ihren persönlichen Vorlieben und ihrer individuellen Arbeitsweise gestalten. Funktionen der impliziten Personalisierung können die Benutzerfreundlichkeit des Portals steigern.

■

Zugriffskontrolle: Benutzer sollen nur auf die Daten und Anwendungen zugreifen können, für die sie explizit berechtigt worden sind.

■

Beschränkung auf relevante Informationen: Dem Benutzer sollen vorrangig jene Informationen präsentiert werden, die für seine Aufgaben und seinen aktuellen Arbeitskontext relevant sind. Dadurch lässt sich der Aufwand für Informationsrecherchen reduzieren.

■

Zielgruppengerechte Ansprache: Das Unternehmensportal soll dem Benutzer gezielt jene Inhalte präsentieren, die für ihn interessant sind.

4.4 Single Sign-On

Der Schlüssel zu den Unternehmensdaten

98

■ ■ ■

Mit zunehmender Komplexität der Systemlandschaft eines Unternehmens werden auch die verwendeten Authentifizierungsmechanismen vielfältiger und unübersichtlicher. Dies stellt nicht nur eine Herausforderung für den IT-Betrieb dar, sondern auch für den einzelnen Mitarbeiter, der sich eine Vielzahl von Passwörtern merken muss. Single Sign-On gehört deshalb zu den ersten Anforderungen, die an ein Unternehmensportal als zentralen Zugriffspunkt zu unterschiedlichen Informationsquellen gestellt werden – zum einen wegen der einfacheren Bedienbarkeit des Systems und der damit einhergehenden Zeitersparnis, zum anderen aber auch aus Sicherheitsund Administrationsgründen. Single Sign-On macht alle über das Unternehmensportal verfügbaren Systeme und Applikationen (in den durch die Rechte des Benutzers gegebenen Grenzen) ohne weitere Authentifizierungen zugreifbar, sobald sich der Benutzer am Unternehmensportal angemeldet hat. Dabei ist für den Benutzer nicht (notwendigerweise) ersichtlich, ob die ihm präsentierten Daten aus einem ERP-System, einer Content-Management-Anwendung oder gar von externen

4 Fachliche Anforderungen

Dienstleistern kommen: Für ihn bildet das Portal die zentrale Schnittstelle zu allen relevanten Unternehmensdaten. Abbildung 4.5 stellt den schematisierten Ablauf einer SingleSing-On-Authentifizierung dar. Der Benutzer meldet sich über ein sicheres Kommunikationsprotokoll am Portal an. Dieses ermittelt über die zentrale Benutzerverwaltung die Zugangsinformationen des Benutzers für die Unternehmensanwendungen, für die dieser berechtigt ist. Das Portal authentifiziert dann den Benutzer automatisch an den verschiedenen Unternehmensanwendungen. Applikationen A1

Portal

Abb. 4.5 Single Sign-On

Single Sign-On

Benutzer- und Rollenverwaltung

sichere Kommunikation

Authentifizierung

A2

A3

A4

A5

A6

Benutzerdaten

Je weniger Passwörter sich ein Nutzer merken muss, desto geringer ist die Gefahr, dass einfache Passwörter genutzt werden, die leicht zu ermitteln sind. Die Gefahr, dass Passwörter aufgeschrieben und für andere leicht zugänglich aufbewahrt werden, wie z.B. als Notiz unter der Tastatur, wird ebenfalls geringer. Damit erhöhen Single-Sign-On-Komponenten die Sicherheit in Unternehmensnetzwerken. Beim Zugriff auf eine bestimmte Ressource werden zunächst die Zugriffsrechte zentral überprüft. Der Nutzer erhält dann die mit dem Benutzerkonto verbundene Berechtigung, die Services und Ressourcen nutzen zu können, ohne dass er beim Aufruf der Programme ein Passwort angeben muss.

Komfortabel und sicher

Daneben steigert die automatische Authentifizierung an beliebig vielen Anwendungen den Komfort für die Benutzer erheblich und trägt so zur Benutzerakzeptanz des Portals bei. Bei hohen Sicherheitsanforderungen an das zentrale Portal-Login können anstelle einer Benutzername/Passwort-Kombination auch andere Techniken zur Benutzerauthentifizierung eingesetzt werden.

4.4 Single Sign-On

■ ■ ■

99

Digitale Zertifikate

Abb. 4.6 Verfahren zur digitalen Zertifizierung (Quelle: Microsoft)

Eine Variante einer sicheren Authentifizierungstechnik sind digitale X.509-Zertifikate. Dies sind von einem vertrauenswürdigen Aussteller – einer Zertifizierungsinstanz – geprüfte und beglaubigte digitale Dokumente – das digitale Äquivalent eines Ausweises. Digitale Zertifikate beinhalten Angaben über Inhaber, Zweck und Gültigkeit des Zertifikats und einen oder mehrere öffentliche Schlüssel. Digitale Zertifikate nutzen eine asymmetrische Verschlüsselung mit einem Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem zugehörigen privaten Schlüssel wieder entschlüsselt werden. Um Zertifikate für sein Portal-Login nutzen zu können, muss der Benutzer sich erst bei einer vertrauenswürdigen Registrierungsstelle registrieren. Diese ist im Idealfall direkt in die Benutzerverwaltung des Portals integriert und leitet die Benutzerdaten direkt an eine Zertifizierungsstelle (Trust Center) weiter. Zertifizierungsanforderung (inkl. Name

1 und öffentlichem Schlüssel)

Zertifizierungsstelle

Nachricht (mit privatem Schlüssel

2 der Zertifizierungsstelle signiert)

Portal überprüft

Benutzer sendet Zertifikat an das

Portal

4 Signatur der Zertifizierungsstelle

3 Portal (bietet Zugriff auf den öffentlichen Schlüssel des Benutzers)

Bei der Anmeldung am Portal präsentiert der Webbrowser des Portalbenutzers dem Portal das für den Benutzer vom Trust Center ausgestellte Zertifikat. Das Zertifikat enthält, mit einer digitalen Signatur verschlüsselt, die Login-Daten des Benutzers. Das Portal prüft nun, ob das übermittelte Zertifikat von einem vertrauenswürdigen Server ausgestellt wurde. Ist die Prüfung erfolgreich, extrahiert das Portal den öffentlichen Schlüssel aus dem Zertifikat. Diesen nutzt es, um die digitale Signatur zu verifizieren und so sicherzustellen, dass der Benutzer tatsächlich über den richtigen Schlüssel verfügt, der zu dem öffentlichen Schlüssel im Zertifikat passt. Wurde die digitale Signatur verifiziert, können die Benutzerinformationen aus dem Zertifikat extrahiert und mit den in der Benutzerverwaltung des Portals hinterlegten Daten verglichen werden. Nach dem erfolgreichen Abgleich der Login-Daten wird der Zugriff auf das Unternehmensportal

100

■ ■ ■

4 Fachliche Anforderungen

gewährt. Abbildung 4.6. stellt diesen Prozess einer Authentifizierung mittels digitaler Zertifikate dar. Vorteil dieser Technik ist die hohe Sicherheit, die mittels digitaler Zertifikate bei der Authentifizierung von Benutzern erreicht werden kann. Außerdem sind Zertifikate die geeignete Lösung, um sie für ein Portal mit hohen Nutzerzahlen einzusetzen, da sie keine zusätzliche Hardware auf Benutzerseite erfordern. Dagegen stehen aber der relativ hohe Aufwand, der mit der Implementierung und dem Betrieb einer Public-Key-Infrastruktur zum Aufbau einer Vertrauensbeziehung über eine Zertifizierungsstelle verbunden ist. Als Public-Key-Infrastruktur (PKI) wird eine technische (und organisatorische) Infrastruktur bezeichnet, die z.B. das Ausstellen, Verteilen und Verwalten von Public Keys und allenfalls den zugehörigen Zertifikaten und Private Keys in einem Public-Key-basierten System ermöglicht. Die Public-Key-Infrastruktur stellt eine offene Plattform für die Implementierung weiterer Sicherheitsdienste (z.B. digitale Signatur von Dokumenten für sichere Geschäftsprozesse) im Unternehmen dar. Eine weitere Möglichkeit einer sicheren Authentifizierung stellt die Authentifizierung mittels Einmalpasswörtern dar. Diese Passwörter können nur einmal genutzt werden und verlieren nach ihrer Nutzung sofort ihre Gültigkeit. Diese Passwörter werden von sogenannten Authentifizierungstoken (Einmalpasswortgeneratoren) in regelmäßigen kurzen Abständen erzeugt. Die Gültigkeit des vom Benutzer eingegebenen Passworts wird über eine entsprechende ServerKomponente verifiziert. Das Wissen um das derzeitig einmalig gültige Passwort beweist, dass der Benutzer momentan im Besitz des Authentifizierungstokens ist. Meist wird die Nutzung von Einmalpasswörtern als zweifacher Authentifizierungsmechanismus implementiert: Neben dem durch den Token generierten Code muss auch noch eine statische PIN bei der Anmeldung am Portal eingegeben werden. Ansonsten wäre bei Verlust des Tokens das Portal vor einem unautorisierten Zugriff nicht mehr geschützt. Auch die Technik der Einmalpasswörter stellt eine sehr sichere Authentifizierungslösung dar. Allerdings bietet sich dieses Verfahren nur in Unternehmensportalen mit einer geringen Anzahl von Benutzern an, da alle Benutzer im Besitz eines Tokens sein müssen. Auch die Einführung von Tokens im Unternehmen und der Aufbau der entsprechenden Serverinfrastruktur zur Validierung der Passwörter ist relativ aufwendig.

4.4 Single Sign-On

Einmalpasswörter

■ ■ ■

101

Weitere Möglichkeiten einer sicheren Authentifizierung

Sicherheit beim Single Sign-On

Anforderungskatalog: Single Sign-On

Schließlich kann auch spezielle Hardware (Chipkarten, biometrische Scanner) für die Authentifizierung zum Einsatz kommen. Auch bei diesen Techniken müssen die Benutzer im Besitz einer Hardware für die Authentifizierung sein, was sie bei großen Benutzerzahlen sehr kostenintensiv macht. Diese verschiedenen Authentifizierungsmechanismen lassen sich wahlweise in einem Portal einsetzen. Für die Realisierung eines zentralen Logins an beliebigen externen Applikationen setzen die unterschiedlichen Portalsysteme verschiedene Techniken ein und sind außerdem in der Lage, externe Single-Sign-On-Dienste zu nutzen. Obwohl der Einsatz einer Single-Sign-On-Lösung die Sicherheit von Passwörtern grundsätzlich erhöht, muss bedacht werden, dass die Schadensauswirkung steigt, wenn sich doch ein Unberechtigter anmeldet, da mit einem Passwort die Daten aller integrierten Anwendungsprogramme einsehbar werden. Auf Systemseite müssen Benutzerkennwörter und Zugriffsrechte nur noch an einer zentralen Stelle administriert und vor unerlaubtem Zugriff geschützt werden, was die Verwaltung dieser sensiblen Daten sowie deren Schutz vereinfacht. Mit dem Thema Single Sign-On sind drei zentrale fachliche Forderungen verknüpft: ■

Zentrale Schnittstelle zu den Unternehmensdaten: Das Unternehmensportal stellt für den Benutzer den zentralen Zugang zu allen Anwendungen und Daten des Unternehmens dar. Für den Benutzer ist es irrelevant aus welchen Backend-Systemen die präsentierten Daten stammen.

■

Verringerung von Sicherheitsrisiken: Durch die Reduktion von Passwörtern, die sich ein Benutzer merken muss, und die zentrale Verwaltung der Login-Daten verringert sich das Risiko eines unbefugten Zugriffs auf die Unternehmensdaten.

■

Einfache Administration: Login-Daten müssen nur noch an einer zentralen Stelle administriert werden.

4.5 Sicherheit Portale bündeln die Daten und Applikationen eines Unternehmens, bilden Geschäftsprozesse ab und sind interner wie externer Kommunikationskanal zum Austausch von Dokumenten. Die Menge und

102

■ ■ ■

4 Fachliche Anforderungen

Qualität der Daten innerhalb eines Portals macht dieses schützenswert. Demnach liegt für Unternehmen, die ein Portal betreiben, ein wesentlicher Fokus auf dem Punkt Sicherheit. Um diesen Sicherheitsanforderungen gerecht zu werden, sind vielfältige Maßnahmen denkbar und notwendig. Dabei ist zu beachten, dass die Gesamtsicherheit nur so stark ist wie die schwächste Maßnahme. Nur mit einer durchdachten und ganzheitlichen Sicherheitsstrategie lässt sich den Sicherheitsanforderungen von Unternehmensportalen Rechnung tragen. Schutzziele definieren die Sicherheitsinteressen der beteiligten Kommunikationspartner in allgemeiner Form. Nach SAGA (2003) lassen sich vier Schutzziele unterscheiden: Vertraulichkeit ist der Schutz vor unbefugter Kenntnisnahme. Daten werden Individuen, Entitäten oder Prozessen nicht unautorisiert zur Verfügung gestellt oder offenbart. Die Präsentation aller Daten und Applikationen im Portal wird zentral über den Personalisierungsmechanismus entsprechend der Zugriffsrechte des Benutzers gesteuert. Integrität ist der Schutz vor Manipulation. Daten können nicht unautorisiert verändert oder zerstört werden. Nicht autorisierte Personen oder Systeme können nicht unberechtigt auf Daten innerhalb des Portals oder auf die datenhaltenden Systeme zugreifen. Bei der Übertragung von Dokumenten wird sichergestellt, dass diese nicht modifiziert oder gelöscht werden. Authentizität ist der Schutz vor einer gefälschten Identität oder Herkunft einer Ressource. Es wird sichergestellt, dass die Einheit bzw. Ressource (z.B. Mensch, Prozess, System, Dokument, Information) die ist, die sie zu sein vorgibt. Diese kann, wie bereits im Abschnitt 4.4 in Bezug auf das Single Sign-On beschrieben z.B. mittels digitaler Zertifikate sichergestellt werden. Verfügbarkeit ist der Schutz vor Ausfällen von IT-Systemen. Die Eigenschaft einer Entität bzw. Ressource ist zugänglich bzw. nutzbar, wenn es durch eine autorisierte Entität gewünscht wird. Ein Portal wird je nach Anwendungszweck unterschiedlichen Anforderungen an seine Verfügbarkeit genügen müssen. Durch Hard- und Softwarekomponenten lässt sich die Verfügbarkeit des Portals und der darunter liegenden Systeme garantieren. Ein weiterer Aspekt soll an dieser Stelle noch ergänzt werden: Die Nachvollziehbarkeit im Sinne einer Protokollierung der Datenmodifikation und -sondierung. In vielen Umgebungen ist es (rechtlich) relevant, die Historie des Zugriffs auf Daten und der Veränderung derselben zu kennen. Neben der Nachvollziehbarkeit erlauben solche Historisierungskonzepte die Wiederherstellung oder zumindest die Sicht auf den Datenbestand zu einem Zeitpunkt in der Ver-

4.5 Sicherheit

Schutzziele

Vertraulichkeit

Integrität

Authentizität

Verfügbarkeit

Nachvollziehbarkeit

■ ■ ■

103

Rechtlicher Rahmen

Sicherheit als Investition

gangenheit. Diese Informationen können bei der strategischen Analyse helfen, erfüllen aber auch eine Nachweispflicht. Neben den oben genannten Schutzzielen haben sowohl die Betreiber eines Unternehmensportals als auch dessen Benutzer das Bedürfnis nach Rechtssicherheit. Während der vergangenen Jahre wurden mehrere Rechtsvorschriften erlassen, aus denen sich zu Fragen der IT-Sicherheit unmittelbare Handlungs- und Haftungsverpflichtungen für Unternehmen ergeben. In diesem Zusammenhang wollen wir auf das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) hinweisen. Das Gesetz schreibt unter anderem für Entwicklungen, die zukünftig ein Risiko für das Unternehmen darstellen könnten, die Überwachung durch ein Risikomanagement für Kapitalgesellschaften vor. Für einen kompakten Überblick über die wichtigsten organisatorischen, infrastrukturellen und technischen IT-Sicherheitsmechanismen sei an dieser Stelle auf den Leitfaden des Bundesamtes für Sicherheit in der Informationstechnik (www.bsi.de) verwiesen. Sicherheit ist eine der wichtigsten Voraussetzungen für den Betrieb eines Unternehmensportals. Erst wenn auf Ebene der Basistechnologien und der Middleware ein Mindestmaß an Sicherheit und Vertrauenswürdigkeit erfüllt ist, kann eine Gesamtarchitektur aufgebaut werden, die den hohen Sicherheitsanforderungen eines Unternehmens entspricht. Investitionen in die Sicherheit ihres Unternehmensportals sind für Unternehmen Investitionen in ■

den Schutz vor finanziellem Schaden,

■

den Schutz vor Imageverlust,

■

den Schutz vor Rechtsverletzung (z.B. beim Umgang mit personenbezogenen Daten),

■

die bessere Bewertung des Unternehmens (z.B. Basel II),

■

das Risikomanagement

und somit in den langfristigen wirtschaftlichen Betrieb des Unternehmensportals.

104

■ ■ ■

4 Fachliche Anforderungen

Mit dem Begriff Sicherheit ist ein ganzes Bündel fachlicher Anforderungen verknüpft, die bei der Konzeption und dem Betrieb eines Portals berücksichtigt werden müssen: ■

Sicherheit sensibler Daten,

■

starke Benutzerauthentifizierung,

■

sichere Kommunikation,

■

Zugriffsschutz,

■

Datenschutz,

■

Rechtssicherheit.

Anforderungskatalog: Sicherheit

4.6 Benutzer- und Rollenmanagement Aussagekräftige Benutzerinformationen und eine differenzierte Rechteverwaltung tragen wesentlich zur Benutzerakzeptanz und zur Zielerreichung eines Portals bei, sorgen sie doch für einen Zuschnitt der präsentierten Informationen auf die fachlichen Rollen oder die persönlichen Einstellungen einzelner Benutzer. Je nach Zielsetzung eines Portals fallen der Benutzer- und Rechteverwaltung ein entsprechendes Gewicht und verschiedene Aufgaben zu. Dabei werden die Informationen zu den Benutzern und ihren Zugriffsrechten meist zentral in hierarchischen Verzeichnisdiensten vorgehalten und administriert. In einem Unternehmensportal, das als Zielgruppe die Mitarbeiter eines Unternehmens fokussiert und Arbeitsprozesse vereinfachen und effizienter gestalten soll, kommt gerade der Rechteverwaltung eine große Bedeutung zu. Benutzer sollen entsprechend ihrer Rolle im Unternehmen die für sie relevanten Informationen angezeigt bekommen. Sensible Daten, z.B. aus dem Controlling oder der Personalverwaltung, sollen nur für speziell berechtigte Personen bzw. Rollen zugreifbar sein. Prozesse lassen sich nur effektiv gestalten, wenn jeder Beteiligte einen klar definierten Aufgabenbereich und entsprechende Kompetenzen hat. In einem über das Internet zugänglichen Unternehmensportal, das hauptsächlich auf Kundenbindung abzielt und als Vertriebskanal benutzt wird, spielt eine effektive Benutzerverwaltung eine große Rolle. Anhand der gesammelten Benutzerinformationen lassen sich die angezeigten Inhalte personalisieren und zu kundenspezifisch abgestimmten Informationsangeboten zusammenstellen. Der Rechteverwaltung fällt hier kein so großes Gewicht zu wie in einem unter-

4.6 Benutzer- und Rollenmanagement

Relevanz abhängig vom Nutzungsszenario

■ ■ ■

105

Voraussetzung für Single Sign-On

Einfache Administration

106

■ ■ ■

nehmensinternen Portal, da über die öffentlichen Kommunikationskanäle ohnehin nur Inhalte publiziert werden, die keine sensiblen Unternehmensdaten sind. In diesem Fall tragen sich Anwender selbst bei ihrer ersten Registrierung in die Benutzerverwaltung ein und werden regelbasiert mit Rechten ausgestattet. Natürlich müssen aber auch in öffentlichen Kundenportalen sensible Daten wie z.B. Kundenprofile und Bestellvorgänge gegen einen unautorisiertenZugriff geschützt werden. Ist das Unternehmensportal über das Internet für einen geschlossenen Benutzerkreis zugänglich, so spielt wiederum die Rechteverwaltung eine Rolle. Zudem wachsen die Anforderungen an die Datensicherheit, wenn sensible Daten über das Internet transportiert werden. In der Benutzerverwaltung des Portals werden sämtliche Authentifizierungsinformationen für alle über das Portal zugänglichen Systeme in einem Verzeichnisdienst hinterlegt. Dies ist die Voraussetzung für ein portalweites Single Sign-On. Bei der zentralen Authentifizierung meldet sich das Portal bei erfolgreicher Verifizierung des Portal-Logins an den einzelnen datenliefernden Systemen an. Dazu bedient es sich der im Benutzerprofil hinterlegten Zugriffsrechte und Passwörter. Für den Benutzer ist dieser Anmeldeprozess nicht sichtbar. Er muss sich nur das Passwort für das Portal-Login merken oder gegebenenfalls über die richtige Hardware oder Zertifikate verfügen, um sich am Portal anzumelden. Danach stehen ihm entsprechend seiner Rolle die relevanten Informationen und Applikationen zur Verfügung. Der einfachen und flexiblen Administration der Benutzer kommt im Unternehmensportal eine besondere Bedeutung zu. Gerade bei großen Nutzerzahlen ist eine effiziente Verwaltung von Benutzerkonten wichtig, um diese schnell an Veränderungen im Unternehmen anpassen zu können. Ein schnelles Deaktivieren von einzelnen Benutzerkonten schützt das Unternehmen vor ungewollten Portalzugriffen. Andererseits kann neuen Mitarbeitern durch eine einfache Anlage eines neuen Benutzerkontos schnell ihr eigener Portalzugang eingerichtet werden. Um die verschiedenen Verantwortlichkeiten und Aufgabengebiete im Unternehmen abbilden zu können, erfordert die Rollenzuweisung ein hohes Maß an Flexibilität. Den Benutzern müssen beliebig viele Rollen und damit verbundene Rechte zugewiesen werden können. Hat ein Benutzer mehrere Rollen zugewiesen bekommen, so muss er sich je nach Struktur des Unternehmens entweder bei der Anmeldung am Unternehmensportal für eine Rolle entscheiden, die er für diese Sitzung bekleiden möchte, oder das Portal kombiniert die mit den Rollen verbundenen Rechte.

4 Fachliche Anforderungen

Aus Gründen einer effizienten Administration bietet sich bei großen Portalen eine Rollenverteilung auf Gruppenebene an. Die in der Benutzerverwaltung hinterlegten Benutzergruppen orientieren sich meistens an den organisatorischen Einheiten des Unternehmens.

Rollenzuweisung auf Gruppenebene

Für eine einfache und flexible Benutzeradministration hat sich der hierarchische Aufbau von Benutzergruppen bewährt. Dies bedeutet, dass Gruppen Untergruppen enthalten können, an die sie implizit ihre Eigenschaften vererben. So kann beispielsweise eine Gruppe „Vertrieb“ die Gruppen „Vertrieb Nord“ und „Vertrieb Süd“ enthalten. Eine Berechtigung für die Gruppe „Vertrieb“ gilt dann automatisch für alle Mitglieder aller enthaltenen Gruppen, eine Berechtigung für „Vertrieb Nord“ aber nur für die Mitglieder dieser Gruppe. Das Single Sign-On des Portals erfordert einen sicheren und skalierbaren Verzeichnisdienst für die Verwaltung der Zugriffsinformationen auf Backend-Systeme. Die Veränderungen in der Applikationsinfrastruktur eines Unternehmens müssen schnell für eine große Anzahl von Benutzerkonten nachgezogen werden können. Der Verzeichnisdienst zur Speicherung der Benutzerkonten muss sich flexibel um weitere Anmeldeinformationen ergänzen lassen. Da der Verzeichnisdienst sämtliche Zugangsinformationen zu den Systemen des Unternehmens speichert, werden an seinen Zugriffsschutz und seine Ausfallsicherheit besondere Anforderungen gestellt.

Skalierbarkeit des Single Sign-On

Damit lassen sich die Anforderungen an das Benutzer- und Rollenmanagement in Unternehmensportalen wie folgt zusammenfassen:

Anforderungskatalog: Benutzerund Rollenmanagement

■

Zielgruppengenaue Angebote: Aussagekräftige Benutzerinformationen sind die Basis für die Personalisierung von Inhalten und Anwendungen.

■

Rechtebasierter Portalzugriff: Benutzern werden die Inhalte präsentiert, die ihrer Rolle entsprechen. Sensible Daten sind nur für speziell berechtigte Benutzergruppen zugreifbar.

■

Einfache Administration: Das Benutzer- und Rollenmanagement muss sich flexibel an Veränderungen im Unternehmen anpassen. Diese Flexibilität bezieht sich zum einen auf das einfache Anlegen und Löschen von Benutzerkonten und zum anderen auf die Skalierbarkeit des Single Sign-On.

4.6 Benutzer- und Rollenmanagement

■ ■ ■

107

4.7 Ergonomie der Benutzungsschnittstelle Usability und Bedienungskomfort sind die entscheidenden Kriterien für die Benutzerakzeptanz eines technischen Systems. Die Usability eines Softwaresystems bezeichnet das Ausmaß, in dem es von einem bestimmten Benutzer verwendet werden kann, um Ziele in einem bestimmten Kontext effektiv, effizient und zufriedenstellend zu erreichen.

Gestaltung der Benutzungsoberfläche

108

■ ■ ■

Gerade bei Portalen als zentrale Schnittstelle zu Informationen jeglicher Art sollte höchstes Augenmerk auf die Qualität der Benutzerführung eines Informationssystems gelegt werden. Nicht der Benutzer sollte sich an ein interaktives System anpassen müssen, sondern das Systemdesign muss so beschaffen sein, dass es für den Benutzer intuitiv und natürlich erscheint und gegebenenfalls an dessen Arbeitsweise angepasst werden kann. Um den Benutzern eine optimale Schnittstelle zur Verfügung zu stellen, sollten bei der Konzeption der Benutzungsoberfläche (Graphical User Interface, GUI) folgende Aspekte berücksichtigt werden: ■

intuitive und durchgängige Navigationsstrukturen,

■

ausschließliche Präsentation von Inhalten, die für den Benutzer wichtig und sinnvoll sind,

■

durchgängige und einheitliche Gestaltung (Corporate Identity),

■

so viel Information wie nötig, so wenig wie möglich,

■

einfach verständliche Bild- und Farbwelten,

■

Möglichkeit für den Benutzer, sich seine persönliche Portaloberfläche zusammenzustellen (Personalisierung),

■

Mehrsprachigkeit,

■

intuitive Suchformulare (natürlichsprachliche Suche, ähnliche Begriffe, Und-/Oder-Verknüpfungen, Freitextsuche),

■

Hilfe-Funktionen,

■

für den Druck optimierte Ansicht von Inhalten,

■

komfortabel zu bedienende interaktive Menüs,

■

direktes und aussagekräftiges Feedback auf Benutzereingaben,

■

behindertengerechte (barrierefreie) Darstellung (Rechtsverordnung zu §11 des Behindertengleichstellungsgesetzes).

4 Fachliche Anforderungen

Bei öffentlichen Portalen spielen außerdem folgende Faktoren eine wichtige Rolle: ■

geringe Ladezeiten der Weboberfläche,

■

browsertyp- und -versionsunabhängige Gestaltung des Portals,

■

gute Auffindbarkeit durch Suchmaschinen.

Bei der Konzeption der Benutzungsoberfläche sollte die tägliche Arbeitsweise der Benutzer im Fokus stehen. Dies ermöglicht ein Design, das die intuitive Bedienung der Benutzungsschnittstelle begünstigt und so den Einarbeitungsaufwand bei der Einführung des Portals verringert. Ähnelt das Portal dem Benutzer vertrauten Oberflächen und Arbeitsweisen, wird er schnell den Nutzen erkennen können, den das Portal für seine tägliche Arbeit bringt. Muss er sich hingegen mit technischen Unzulänglichkeiten befassen oder ist er nicht in der Lage, das Portal korrekt zu bedienen, wird dies zu einer schwindenden Benutzerakzeptanz führen. Usabilitytests in einer frühen Phase des Portalprojektes können hier helfen, die Konzeption zu verifizieren und konsequent an den Bedürfnissen der Benutzer auszurichten. Die Gestaltung der Benutzungsoberfläche sollte sich außerdem an dem Corporate Brand des Unternehmens orientieren. Wenn das Portal als ein Mittel zur internen Unternehmenskommunikation genutzt werden soll, muss es auch den Gestaltungsrichtlinien des Unternehmens entsprechen. Ein stringentes medienübergreifendes Umsetzen des Corporate Brands erfüllt nicht nur den Zweck einer hohen Wiedererkennbarkeit nach außen, sondern prägt auch intern das Gesicht des Unternehmens und trägt so zur Identifikation der Mitarbeiter mit ihrem Unternehmen bei.

Intuitives Design

Die Notwendigkeit einer ergonomischen Benutzungsschnittstelle resultiert aus den folgenden fachlichen Anforderungen:

Anforderungskatalog: Ergonomie der Benutzungsschnittstelle

■

Unterstützung der Arbeitsprozesse: Die Gestaltung der Benutzungsoberfläche soll ein effizientes Arbeiten ermöglichen und so zur Produktivitätssteigerung der Mitarbeiter beitragen.

■

Geringer Einarbeitungsaufwand: Die Arbeitsabläufe und die Benutzerführung im Portal sollen sich an etablierten Arbeitsweisen orientieren und intuitiv gestaltet sein, um mit geringerem Einarbeitungsaufwand produktiv mit dem Portal arbeiten zu können.

4.7 Ergonomie der Benutzungsschnittstelle

Orientierung am Corporate Brand

■ ■ ■

109

■

Kommunikationskanal des Unternehmens: Das Unternehmensportal ist ein wichtiger Kommunikationskanal des Unternehmens, der nach innen und außen das Unternehmen im Sinne des Corporate Brand repräsentieren soll.

4.8 Multimodaler Zugriff

Trennung von Content und Design

Medienoptimierte Präsentation

110

■ ■ ■

Durch die Möglichkeit der Nutzung unterschiedlicher Ausgabemedien und Kommunikationsprotokolle (Multi Channel) erweitertet sich das mögliche Einsatzspektrum eines Unternehmensportals. Neben dem Zugriff auf das Portal über einen Webbrowser spielen mobile Endgeräte wie Mobiltelefone und Handhelds (PDA, Personal Digital Assistant) bei der Konzeption von Portalen eine immer wichtigere Rolle. Durch die aktuellen technischen Entwicklungen werden weitere Ausgabeformate und Protokolle wie i-mode, UMTS oder das digitale Fernsehen (iTV) in Zukunft zudem an Bedeutung gewinnen. Die Forderung nach einem multimodalen Zugriff auf das Unternehmensportal stellt die Konzeption des Portals vor weitere Herausforderungen. Durch die eingeschränkten Darstellungsmöglichkeiten der mobilen Endgeräte ist die Präsentationsschicht des Portals, die für den Zugriff über einen Browser bestimmt ist, nicht geeignet, um sie beispielsweise auf dem Display eines Mobiltelefons anzuzeigen. Das Portal muss deshalb in der Lage sein, Informationen entsprechend dem jeweiligen Ausgabemedium aufzubereiten. Um diese flexible Aufbereitung zu ermöglichen, müssen Daten getrennt von ihren Layoutinformationen verwaltet werden. Das bedeutet, dass die Daten in einem medienneutralen Format gehalten werden, das unabhängig ist von der späteren Präsentationsform und dem Ausgabemedium. Dem Portal kommt nun die Aufgabe zu, diese Daten automatisch zu strukturieren, zu formatieren und geeignete Navigationsmechanismen zu erzeugen, um die Benutzungsoberfläche auf die einzelnen Ausgabemedien anzupassen. Die Präsentation der Informationen muss sich dabei an den technischen Darstellungsmöglichkeiten des zugreifenden Mediums orientieren. Außerdem muss die Portaloberfläche in einem Format ausgeliefert werden, das von dem jeweiligen Medium auch verstanden werden kann. Um bei einem Zugriff auf das Portal die richtige Präsentationsschicht auszuliefern, muss das Portal in der Lage sein, automatisch die Art des zugreifenden Mediums zu erkennen.

4 Fachliche Anforderungen

Neben der medienoptimierten Präsentation der Portalinformationen und -applikationen muss bei der Konzeption eines multimodalen Portals auch berücksichtigt werden, welche Applikationen für bestimmte Ausgabemedien geeignet sind. Nicht alle Portalapplikationen müssen zwingend für alle Ausgabemedien zur Verfügung stehen. So ist beispielsweise die Möglichkeit, den Kantinenplan der Unternehmenszentrale per Mobiltelefon abzurufen, für Außendienstarbeiter nicht unbedingt notwendig. Gerade bei Medien mit eingeschränkten Darstellungsmöglichkeiten wird auch die Bedeutung einer personalisierten Präsentation und Informationsauswahl deutlich. Wenn es schon nicht möglich ist, dem Benutzer alle Informationen zu präsentieren, ist es umso wichtiger, ihn mit genau den für ihn relevanten Informationen zu versorgen.

Geeignete Portalapplikationen

Personalisierung

In der Praxis haben sich XSL (Extensible Stylesheet Language) und XSLT (XSL Transformation) als geeignete Techniken erwiesen, um XML-basierte Daten für unterschiedliche Zwecke in geeignete Formate zu überführen. Genauere Informationen über XSLT finden Sie im Abschnitt 7.3.3. Für die Redaktionsmechanismen des Portals bedeutet die Trennung von Inhalten und Design, dass die Pflege der Daten zunächst unabhängig von einer späteren Präsentationsform und einem Ausgabemedium erfolgen muss. Das Portal sollte allerdings Vorschaufunktionen für die verschiedenen Präsentationsschichten anbieten, damit Benutzer das Aussehen ihrer Eingaben in deren späteren Ausgabeformat überprüfen können. Eine konsequente Trennung des Designs (Präsentationsschicht) von den darunter liegenden Portalschichten ermöglicht außerdem die schnelle Anpassung des Oberflächendesigns. Werden die Designinformationen separat gehalten, müssen weder die präsentierten Informationen noch die Logik der Portalapplikationen angepasst werden, wenn sich das Design der Portaloberfläche ändert. In diesem Fall muss nur die zentrale Designinformation (Stylesheet) geändert werden, um alle Portalapplikationen und Informationen in einem neuen Layout zu präsentieren.

ContentRedaktion

Designänderungen

Die Einkäufer von Wein&Dein verbringen den größten Teil ihrer Arbeitszeit in den verschiedenen weltweiten Weinanbaugebieten. Nur zu wichtigen Terminen halten sie sich in der Hauptniederlassung von Wein&Dein auf. Dennoch sind die Einkäufer in ihren Verhandlungen mit Winzern und Lieferanten auf die Geschäftszahlen aus den Niederlassungen angewiesen. Um ihre Einkäufe optimal an

4.8 Multimodaler Zugriff

■ ■ ■

111

den Entwicklungen des Absatzes auszurichten, benötigen sie Informationen über den aktuellen Lagerstand einzelner Produkte, Absatzprognosen sowie Einkaufskonditionen bei den einzelnen Lieferanten. Deshalb verfügt das Wein&Dein-Portal nicht nur über eine Präsentationsschicht für Webbrowser, sondern auch über eine Oberfläche, die für den Zugriff durch ein Mobiltelefon optimiert wurde. Über die Oberfläche des Mobiltelefons stehen nur ausgewählte Portalapplikationen zur Verfügung, nämlich genau die, die für die Einkäufer relevant sind. Selbst diese Portalapplikationen sind in ihrem Funktionsumfang reduziert und dienen hauptsächlich dazu, die Einkäufer kurz und übersichtlich mit Kennzahlen zu versorgen. Daneben haben die Einkäufer selbst die Möglichkeit, das Portal nach ihren persönlichen Interessen zu gestalten. So interessiert sich beispielsweise der für Südafrika zuständige Einkäufer nicht für die Kennzahlen französischer Rotweine. Durch die Möglichkeit, per Mobiltelefon auf das Unternehmensportal zuzugreifen, können die Einkäufer sich nun jederzeit mit aktuellen Kennzahlen versorgen. Durch dieses Vorgehen konnte Wein&Dein seine Einkaufsmargen wesentlich erhöhen und seine Lagerkosten um sieben Prozent reduzieren. Anforderungskatalog: Multimodaler Zugriff

Die Bedeutung des Themas Multimodalität ergibt sich aus den folgenden drei Aspekten: ■

Mehrere Zugriffskanäle: Durch die Möglichkeit des Zugriffs über verschiedene Kommunikationskanäle sind Informationen des Portals jederzeit und überall verfügbar.

■

Präsentation nach Anwendungszweck: Für die verschiedenen Kommunikationskanäle werden genau die Informationen und Anwendungen angeboten, die in Abhängigkeit von den technischen Möglichkeiten und dem Einsatzzweck des Mediums sinnvoll sind.

■

Zentrale Inhaltspflege: Portalinhalte werden für alle Ausgabemedien einmal zentral im Unternehmensportal erfasst.

4.9 Zukunftssicherheit Der Portalmarkt ist ein Markt mit Zukunft. Analysten gehen von einer wachsenden Bedeutung dieses Mediums aus, und existierende Portalprojekte und -systeme geben einen Eindruck von dessen Potenzial. Unternehmen müssen aber sicherstellen, dass ihre heutigen

112

■ ■ ■

4 Fachliche Anforderungen

Investitionen in ein Portalsystem auch in Zukunft noch rentabel sein werden, auch unter dem Einfluss immer enger werdender Märkte, sich immer schneller verändernder Prozesse und einer dynamisch wachsenden IT-Landschaft. Die Forderung nach einer tragfähigen, flexiblen Architektur ist damit nicht nur eine technische, sondern vor allem eine betriebswirtschaftliche Forderung an ein langfristig effizientes Portal, das sich mit dem Unternehmen entwickelt. Die Portalarchitektur muss so beschaffen sein, dass sie auch in Zukunft noch tragfähig ist, mit den steigenden Anforderungen an das Portal wächst und offen für die Anbindung neuer Systeme ist. Um den Herausforderungen der Zukunft gerecht werden zu können, muss sich die Flexibilität eines Unternehmensportals auf folgende Bereiche beziehen: ■

die Benutzerverwaltung,

■

die Integrationsfähigkeit (Verweben von Daten),

■

die Neu- und Weiterentwicklung von Applikationen,

■

das Design,

■

die Integration externer Partner,

■

die Modellierung von Geschäftsprozessen,

■

das Annotieren von Metainformationen,

■

das Anlegen neuer Ausgabekanäle,

■

die Integration anderer Webanwendungen, die in das Portal eingeklinkt werden und sich mit dem Portal z.B. die Benutzerverwaltung und das Session-Management teilen.

Wie ein guter Systementwurf tatsächlich aussieht, lässt sich konkret nur unter Berücksichtigung des eingesetzten Portalsystems und seines Anwendungszwecks bewerten. Die wichtigsten allgemeingültigen Forderungen, die an eine offene und zukunftsfähige Architektur gestellt werden, sind im Folgenden kurz beschrieben. Die Verwendung offener, herstellerunabhängiger Standards und Formate sichert die technische wie fachliche Zukunftsfähigkeit eines Portals. Organisationen und Konsortien wie OMG (UML, CORBA), W3C (HTML, HTTP, XML), OASIS (ebXML, DocBook) oder die Apache Software Foundation (Jakarta, Xerces, Xalan) schaffen Standards bzw. Referenzimplementierungen, die weltweit eingesetzt werden. Hinzu kommen branchenspezifische Standardisierungsgremien wie z.B. das International Press Telecommunications Council (NewsML).

4.9 Zukunftssicherheit

Tragfähige Architektur

Offene Standards

■ ■ ■

113

Modulares Konzept

Standardisierte Kommunikationsplattform Herstellerkriterien

Fachliche Skalierbarkeit

Anforderungskatalog: Zukunftssicherheit

114

■ ■ ■

Ein komponentenbasiertes Konzept erlaubt die Kapselung von Teilfunktionalitäten in abgeschlossenen Komponenten, die mit den anderen Komponenten des Systems kommunizieren. In einem solchen modularen System ist es möglich, Softwarekomponenten verschiedener Hersteller miteinander zu kombinieren sowie einzelne Komponenten auszutauschen, zu entfernen oder hinzuzufügen, ohne die anderen Komponenten anpassen zu müssen. Das modulare Konzept verlangt Kommunikationsstandards, die von allen beteiligten Komponenten unterstützt werden. Existierende Konzepte/Architekturen sind z.B. HTTP, SOAP oder MOM. Bei der Auswahl eines Portalsystems sollte auch der Aspekt der Zukunftssicherheit der Investitionen berücksichtigt werden. Ein teures Update- und Lizenzmodell kann die Betriebskosten eines Portals langfristig in die Höhe treiben. Informationen über den Hersteller sollten in den Entscheidungsprozess einfließen. Kann der Hersteller auf eine langjährige starke Marktposition verweisen, kann davon ausgegangen werden, dass dieser den Support des Portalsystems für die nächsten Jahre garantieren kann. Neben diesen technischen Aspekten ist aber auch die Flexibilität des Portals hinsichtlich seiner fachlichen Skalierbarkeit entscheidend für die Zukunftssicherheit der Portalinvestition. Geschäftsprozesse sind in den sich schnell verändernden Märkten einem ständigen Wandel unterworfen, die Innovationszyklen bei der Entwicklung neuer Produkte werden immer kürzer und Fusionen stehen auf der Tagesordnung. Diesen Entwicklungen muss die Architektur des Unternehmensportals Rechnung tragen. Die fachliche Skalierbarkeit eines Portalsystems beginnt bei der schnellen Umsetzung eines neuen Corporate Brands und hört bei der Integration weiterer datenhaltender Systeme auf. Eine besondere Bedeutung kommt der Flexibilität der Geschäftsprozesse zu. Nur wenn es einem Portal gelingt, seine Prozesse stets an den Bedingungen des Unternehmens auszurichten, wird es langfristig den erwarteten Nutzen bringen. Die Zukunftssicherheit eines Unternehmensportals wird in fachlicher Hinsicht durch die folgenden Forderungen garantiert: ■

Fachliche Skalierbarkeit: Das Portal muss sich mit den wirtschaftlichen und organisatorischen Veränderungen im Unternehmen entwickeln können.

■

Technischer Investitionsschutz: Die Investition in die Technik eines Unternehmensportals lässt sich langfristig durch die Nutzung etablierter Standards und durch einen flexiblen modularen Entwurf sicherstellen.

4 Fachliche Anforderungen

5 Technische Anforderungen

Es wurde immer wieder betont, dass ein Unternehmensportal in erster Linie durch dessen fachliche Ausrichtung geprägt ist und einen betriebswirtschaftlichen und fachlichen Nutzen verfolgt. Nichtsdestotrotz gibt es eine Reihe von technischen Anforderungen, denen ein Unternehmensportal genügen sollte, um die fachlichen Anforderungen optimal abbilden zu können. Wie auch schon bei der Beschreibung dieser fachlichen Anforderungen bemerkt, sind nicht alle der folgenden technischen Aspekte für jedes Unternehmensportal von Bedeutung. So spielen z.B. Datensicherheit und Archivierung in einem Nachrichtenportal, das lediglich zu Informationszwecken dient, eine untergeordnete Rolle. Trotzdem sollten Sie bei der Planung Ihres Portals auch diese Anforderungen betrachten und gegebenenfalls explizit ausschließen – ignorieren sie diese von vornherein, so besteht die Gefahr, dass ihnen ein wesentlicher Aspekt bereits in der Planungsphase fehlt. Nicht selten stellt sich heraus, dass zumindest ein Teilaspekt entgegen der ursprünglichen Annahme bedeutend ist und berücksichtigt werden muss. Die in diesem Kapitel vorgestellten technischen Anforderungen betreffen nicht das Unternehmensportal allein. Sie beziehen sich auch auf die IT-Landschaft des Unternehmens, deren Systeme, Anwendungen, Dienste und Prozesse sich das Unternehmensportal bedienen soll.

Kurz gefasst

5.1 Integration Die Integration technischer Systeme spielt für nahezu alle Portale eine wichtige Rolle. So unterschiedlich deren Anwendungsschwerpunkte auch sind (vgl. Abschnitt 1.9.2) – letztendlich gilt es, mit dem Portal eine Abstraktionsebene oberhalb der technischen Systeme zu errichten, um deren Komplexität zugunsten durchgängiger, fachlich motivierter Geschäftsprozesse zu überdecken. Die Komple-

5.1 Integration

■ ■ ■

115

xität der zu bewältigenden Integration ist weitgehend unabhängig vom Anwendungsschwerpunkt eines Portals – lediglich der Charakter der zu choreographierenden Systeme ist verschieden. Bei den der Miteinanderarbeit dienenden Unternehmensportalen (Collaborative Portals) handelt es sich hauptsächlich um Systeme zur Unternehmenskommunikation sowie zur Dateiablage. Letztere werden auch von Informationsportalen (Publishing Portals) zugegriffen, die zudem die Unternehmensdaten aus den verschiedenen Datenquellen, ERP-Systemen und anderen Unternehmensapplikationen beziehen. Teilfunktionen der letztgenannten Systeme werden von den Operational Portals unterstützt. Portale zur strategischen Entscheidungsfindung (Decision Portals) bedienen sich schließlich vornehmlich der extrahierten und aufbereiteten Informationen. Diese werden vom Portal unter Umständen gefiltert oder weiter verdichtet, bevor sie dem Benutzer präsentiert werden. Wie kann nun ein Portal eine Integration der genannten Systeme ermöglichen bzw. unterstützen? Diese Frage muss für die im Abschnitt 1.6 definierten Arten der Integration (System- und Prozessintegration, Frontend- und Backend-Integration, kombinierte Integration) einzeln beantwortet werden.

5.1.1 Systemintegration

Katalogisierung der Informationsquellen und Dienste

Die Einbindung technischer Systeme in ein Unternehmensportal dient in erster Linie dem vereinheitlichten Zugriff auf Unternehmensanwendungen über die Benutzungsoberfläche des Portals. Neben den bereits genannten fachlichen Beweggründen für eine solche Integration lassen sich auch technische Vorteile identifizieren. So bedingt die funktionale Erschließung des zu integrierenden Systems eine Offenlegung der von ihm angebotenen fachlichen Dienste, zu denen dann die technischen Schnittstellen beschrieben werden. Mit zunehmender Zahl der integrierten Systeme entsteht aus den Schnittstellenbeschreibungen nach und nach ein Servicekatalog der unternehmenseigenen IT-Landschaft. An diesem Katalog können neue fachliche Anforderungen für das Portal, aber auch für andere Projekte gemessen werden. Das erleichtert (und verkürzt) die Analysephase von IT-Projekten, denn ein wesentlicher Bestandteil dieser Projektphase ist die Systemanalyse. Wir haben in vielen Projekten bei Großunternehmen die Erfahrung gemacht, dass die Unternehmen nicht wissen, was sie alles wissen, sprich: Das Informations- und Dienstangebot ist in seinem vollen

116

■ ■ ■

5 Technische Anforderungen

Umfang niemandem bekannt. Deshalb nimmt gerade bei Unternehmen dieser Größenordnung die Katalogisierung der Systeme einen hohen Stellenwert ein. Sie ist aber nur ein erster Schritt, hin zu einer Standardisierung der Datenmodelle, gegebenenfalls sogar zu einer Konsolidierung und Zentralisierung der Datenquellen. Auch in kleineren und mittleren Unternehmen wächst der Informationshaushalt im Laufe der Jahre oft unkontrolliert an, weshalb von Zeit zu Zeit eine Bestandsaufnahme notwendig wird. Der Wunsch nach einer Systemintegration ist dann oft der Auslöser dafür. Abb. 5.1 Punkt-zu-PunktVernetzung von Systemen

Die Bündelung der Systemschnittstellen in einem Punkt ist ein weiterer wichtiger Grund, um die Integration von Unternehmensanwendungen (bzw. den technischen Systemen, auf denen diese Anwendungen laufen) voranzutreiben. Bei der Enterprise Application Integration (EAI) wird die Systemkommunikation über eine zentrale Integrationsplattform, den sogenannten EAI-Bus, gesteuert. Damit fallen die direkten Punkt-zu-Punkt-Verbindungen zwischen zwei Systemen weg. Dies reduziert die Anzahl der existierenden (und technisch wie fachlich zu wartenden) Schnittstellen und damit die Komplexität des Gesamtsystems, wie die Abbildungen 5.1 und 5.2 anschaulich zeigen.

5.1 Integration

■ ■ ■

117

Abb. 5.2 Systemintegration mittels EAIKomponente (Sternarchitektur)

EAI Bus

In der in Abb. 5.2 dargestellten Sternarchitektur besitzt jedes System genau einen Kommunikationskanal, der von der EAIKomponente genutzt wird. EAI-Systeme bieten heute eine Vielzahl von Adaptern an, um Verbindungen zu den unterschiedlichsten technischen Systemen herstellen zu können – vom Mainframe über Spezialanwendungen bis hin zu J2EE- und .NET-Applikationen. Die zu kontaktierenden Systeme müssen nur in Ausnahmefällen zum Zwecke der Integration angepasst oder erweitert werden. Wein&Dein verwendet Lotus Notes als System für die Bürokommunikation. Bei der Auswahl eines Portalsystems spielt für das Unternehmen die Integrationsmöglichkeit von Notes eine wichtige Rolle. Die Anforderungen gehen über eine Abbildung der NotesClientsoftware in die Benutzungsoberfläche des Portals hinaus. So möchte man die Notes-Grundfunktionen (z.B. das Lesen und Schreiben von E-Mails und der Zugriff auf das UnternehmensAdressbuch) auch von anderen Portalapplikationen aus nutzen können. Im Verlauf der Softwareauswahl stellt sich heraus, dass mehrere der untersuchten Portalsysteme die Nutzung der verschiedenen Notes-Funktionen über einen EAI-Bus ermöglichen. Zu Evaluierungszwecken wird eine prototypische Portalapplikation entwickelt, die den Zugriff auf den Notes-Terminkalender sowie das Versenden einer E-Mail über Notes ermöglicht. Dieser Prototyp wird den am Portalprojekt beteiligten Benutzern präsentiert. Diese sind von der gezeigten Integration begeistert. Sie haben jetzt eine genauere Vorstellung von den Möglichkeiten, die die Integration ihnen bietet. Dem-

118

■ ■ ■

5 Technische Anforderungen

entsprechend können sie die Anforderungen an das Portal genauer formulieren. Außerdem beginnen sie, neue Nutzungskonzepte zu entwickeln, bei denen die Geschäftsprozesse im Mittelpunkt der Betrachtung stehen. Systemgrenzen, die sie bisher als Barrieren bewertet haben, treten in diesen Konzepten in den Hintergrund.

5.1.2 Prozessintegration Das obige Beispiel der Integration einer Kommunikationssoftware zeigt, dass es mit der technischen Integration des Softwaresystems allein meist nicht getan ist. Das Versenden einer E-Mail, z.B. zur Bestätigung einer Aktion, ist heute Bestandteil vieler Geschäftsprozesse. Damit der Portalbenutzer, der sich der technischen Unterstützung eines Geschäftsprozesses (z.B. über das Unternehmensportal) bedient, nicht jedes Mal die (Portal-)Anwendung wechseln muss, um die E-Mail zu schreiben und zu versenden, bietet sich die Integration der Kommunikationssoftware in den Geschäftsprozess an. Technisch setzt das eine Ansteuerung des E-Mail-Systems von der Workflowkomponente voraus. Fachlich gesehen kann die Bestätigungsmail automatisch vorformuliert und dem Bearbeiter zur Veränderung oder Ergänzung vorgelegt werden, bevor er diese direkt aus seiner Fachanwendung heraus versenden kann. Die Forderung nach einer Prozessintegration hebt die technische Systemintegration auf eine höhere Anforderungsstufe: Die oben aufgestellte Forderung nach einer definierten Kommunikationsschnittstelle nach außen wird dahingehend konkretisiert, dass die Ausgestaltung dieser Schnittstelle den Erfordernissen einer Workflowsteuerung genügen muss. Diese Steuerkomponente betrachtet den Aufruf eines externen Systems als eigenständige Aktivität innerhalb des aktuell bearbeiteten Geschäftsprozesses. Dazu muss das externe System in seiner Schnittstelle Funktionen zur Abarbeitung der zugewiesenen Workflow-Aktivität definieren. Müller (2004) weist noch auf eine andere Möglichkeit der Integration von Fachanwendungen in Workflowsystemen hin: Hier wird die lokal auf dem Personal Computer des Benutzers installierte Fachanwendung direkt von der Workflow-Clientsoftware angesprochen. Letztere ist ebenfalls lokal auf dem PC installiert. Müller nennt auch einen Nachteil dieser clientseitigen Kopplung: Der Workflowserver bekommt von alledem nichts mit und kann folglich keine Prozessdaten zu diesen Aktivitäten speichern. Damit ist eine spätere Analyse des Workflows nicht ohne weiteres möglich.

5.1 Integration

Workflowsteuerung

■ ■ ■

119

BPEL

Web Services

ServiceOriented Architectures (SOA)

Die genannten workflowspezifischen Anforderungen lassen sich in den Systemschnittstellen am elegantesten und flexibelsten implementieren, wenn diese einem gemeinsamen Standard folgen. Mit der Business Process Execution Language for Web Services BPEL(4WS) existiert ein solcher Standard (vgl. Andrews et al. 2003). Diese XML-basierte Metasprache versteht die zu integrierenden Systeme als Dienste (Services) und beschreibt die Abläufe zum Aufruf dieser Dienste. Eine BPEL-basierte Kommunikation ermöglicht einen hohen Grad an loser Systemkopplung (siehe auch Abschnitt 5.9). Dadurch ist das Gesamtsystem weniger anfällig für Änderungen in den Systemen oder Prozessen – die Stabilität und Wartbarkeit steigt, das Risiko sinkt. Der BPEL-Standard ist von namhaften Softwareherstellern ins Leben gerufen worden, so dass es bereits heute Produkte gibt, die eine Laufzeit- und Entwicklungsumgebung für die Ebene der Geschäftsprozesse realisieren (vgl. Raepple 2004). Die Idee, die zu integrierenden Systeme als Dienste zu betrachten, liegt auch dem Konzept der Web Services zugrunde. Das Prinzip der losen Kopplung, das auch bei Technologien wie Enterprise JavaBeans (EJB) oder der Common Object Request Broker Architecture (CORBA) Anwendung findet, ermöglicht die Realisierung ortsunabhängiger und völlig autarker Dienste: Die Kenntnis der Dienstbeschreibung vorausgesetzt, kann ein Web Service von überall aus dem Internet aufgerufen werden. Die Beschreibung des Dienstes ist standardisiert und soll ausreichen, um den Dienst nutzen zu können, ohne dass zusätzliches Wissen über den Dienst erforderlich ist. Die genannte Flexibilität der Dienste ermöglicht den Entwurf von Softwarearchitekturen, die einem Baukasten von Diensten gleichen, aus dem sich der Softwarearchitekt bedienen kann, um die fachliche Anwendung zusammenzusetzen. Solche diensteorientierten Architekturen (Service-Oriented Architectures, SOA) werden zurzeit viel diskutiert – allerdings ohne nennenswerte Implementierungen vorweisen zu können. Es bleibt zu beobachten, ob und wie sich die Diskussion um die Dienste in verlässlichen und standardisierten Architekturen und technischen Rahmenwerken (Frameworks) niederschlagen wird.

5.1.3 Frontend-Integration Die Einbindung verschiedener Anwendungen, Dienste und Prozesse in ein Unternehmensportal soll dem Portalnutzer einen zentralen Zugang zu den genannten Komponenten der IT-Landschaft des Un-

120

■ ■ ■

5 Technische Anforderungen

ternehmens schaffen. Um die beabsichtigte integrierte Sichtweise für den Benutzer erlebbar zu machen, muss die Benutzungsoberfläche des Portals durchgängig gestaltet sein. Der Benutzer wird im Idealfall nicht merken, mit welchen Informationssystemen die von ihm genutzte Portalapplikation im Hintergrund kommuniziert. So leicht sich dieser Anspruch formulieren lässt, so schwierig ist es, ihn in der Praxis umzusetzen. Um die Benutzungsoberfläche einheitlich über alle angeschlossenen Systeme und deren Portal-Repräsentation gestalten zu können, muss das Layout aller Portalapplikationen selbst entwickelt werden. Die Forderung nach einer Durchgängigkeit in der Gestaltung der Benutzungsoberfläche bezieht sich nicht allein auf die grafischgestalterischen Richtlinien, die in der Regel von der unternehmenseigenen Corporate Identity vorgegeben werden. Auch die Applikationslogik sollte abgestimmt sein – beginnend bei einer einheitlichen Benennung der Interaktionselemente, wie Schaltflächen (Buttons) und Eingabefelder, über eine einheitliche oder zumindest ähnliche Anordnung dieser Elemente, bis hin zu einer Vereinheitlichung der Arbeitsschritte zwischen den verschiedenen Teilprozessen. Natürlich muss die Benutzungsoberfläche auch den ergonomischen Gestaltungsrichtlinien von Bildschirmarbeitsplätzen genügen. Nicht selten steht der „reinen Lehre“ der Softwareergonomie die althergebrachte Arbeitsweise mit der zu integrierenden Anwendung gegenüber. Insbesondere bei älteren Anwendungen wurden ergonomische Gesichtspunkte nicht berücksichtigt. Der geübte Benutzer kennt jedoch die Kommandofolgen und Bildschirmmasken – eine Abkehr von dieser gewohnten Umgebung bedeutet für ihn, sich neu einzuarbeiten. Neue Benutzer, denen die Altanwendung nicht vertraut ist, werden moderne, grafische Benutzungsoberflächen (Graphical User Interface, GUI) bevorzugen. Um beide Typen von Benutzern zufrieden zu stellen, sollte die Benutzungsoberfläche alternative Interaktionsformen unterstützen – z.B. Tastenkürzel oder Transaktionskommandos neben Schaltflächen und Menüs. Für das von Wein&Dein ausgewählte Portalsystem bietet IBM eine Lotus Notes-Portalapplikation an. Als diese mit voreingestellten Funktionen und Layout im Portal zur Verfügung gestellt wird, beschweren sich die Benutzer. Man hatte ihnen ein „integriertes Arbeiten“ versprochen – tatsächlich aber erspart ihnen das Portal lediglich das Starten einer zusätzlichen Applikation (nämlich die NotesClientsoftware). Da die Notes-Portalapplikation an nur einer Stelle in der Portalnavigation verankert ist, muss der Benutzer jedes Mal diesen Menüpunkt auswählen, um eine E-Mail schreiben zu können.

5.1 Integration

■ ■ ■

121

Vorher konnte er einfach den Browser verlassen und zum NotesClient wechseln. Ausgehend von dieser Kritik wurde Lotus Notes in einer Folgeversion des Portals tatsächlich integriert. So ist jetzt auf jeder Portalseite ersichtlich, ob neue E-Mails eingegangen sind, und auch das Schreiben von Mails kann von jeder Portalseite aus erfolgen. Zudem wird in ausgewählten Geschäftsprozessen das automatische Erstellen von E-Mails unterstützt. Bietet der Hersteller eines zu integrierenden Systems für ein gegebenes Portalsystem eine passende Portalapplikation, so wird deren Benutzungsoberfläche nicht in allen Aspekten den eigenen Anforderungen genügen. Deshalb lautet eine wesentliche Forderung an solche Portalapplikationen, dass deren Benutzungsoberfläche anpassbar sein muss. Gelingt dies nicht, oder gibt es gar keine Portalapplikation für ein System (oder einen Dienst), dann muss diese selbst entwickelt werden. Im Kapitel 7 wird die Portlet-API vorgestellt – ein Standard für die Programmierung solcher Portalapplikationen, der flexibel genug ist, um Layout-Anpassungen einfach vornehmen zu können.

5.1.4 Backend-Integration Für die Backend-Integration gelten im Wesentlichen dieselben Anforderungen wie für die Systemintegration. Einziger Unterschied ist, dass hier nicht die Systeme und Dienste in das Portal integriert werden, sondern fachlich motiviert miteinander verknüpft werden. Es hat sich gezeigt, dass das Knüpfen von Beziehungen zwischen den Datenmodellen der Systeme und Anwendungen sowie die Festlegung des führenden (primären) Systems die zentralen Herausforderungen der Backend-Integration darstellen.

5.1.5 Kombinierte Integration (Frontend + Backend) Bei der Kombination aus Frontend- und Backend-Integration löst eine Benutzeraktion im Portal die Kommunikation und den Informationsaustausch zwischen verschiedenen Backend-Anwendungen aus. Auf diese Weise lassen sich Anwendungen sichtbar miteinander verbinden. Damit stellt die kombinierte Integration die flexibelste Form der Prozessintegration dar, weil die Informationsverknüpfung

122

■ ■ ■

5 Technische Anforderungen

auch unmittelbar ohne fest vorgegebenen Geschäftsprozess möglich ist. Einen solch hohen Flexibilitätsgrad erreichen die Systeme nicht von allein – der Preis ist eine intensive Analyse der Datenmodelle und die Definition der möglichen Verbindungsstellen. Diese werden in Form von Schlüsselfeldern beschrieben, die einen Datensatz des einen Systems mit den passenden Daten eines anderen Systems in Verbindung bringen können. Die Definition dieser Datenbeziehungen wird üblicherweise in einem eigenen System gespeichert, dem sogenannten Metadatenserver. Dieser sorgt in einem kombinierten Integrationsszenario für die Lieferung der benötigten Metainformationen über die von den kombinierten Systemen bezogenen Daten. Er ist ferner für die Protokollierung von erfolgreichen wie fehlerhaften Datenzugriffen verantwortlich. Die Auswertung dieser Protokollinformationen erlaubt später eine Auswertung des Nutzungsgrades der einzelnen Szenarios. Die Fehlerfälle lassen Rückschlüsse auf Änderungen in den Datendefinitionen der angeschlossenen Systeme zu.

Metadatenserver

Die von einem Metadatenserver geforderte Funktionalität kann in kleineren Projekten mit vergleichsweise einfachen Mitteln realisiert werden. Oft genügen Views und wenige zusätzliche Tabellen in den Datenbanken der Anwendungssysteme, um die systemübergreifenden Beziehungen formal zu definieren. Die Benutzungsoberfläche muss visuelle Hinweise auf das Vorhandensein von verknüpfbaren Inhalten anbieten. So kann beispielsweise ein entsprechendes Datenfeld anders formatiert sein oder beim Überfahren mit der Maus seine Darstellungsform ändern. Selbiges gilt für alle Bereiche der Portalseite, die als mögliches Verknüpfungsziel in Frage kommen. Als Interaktionsform für die kombinierte Integration hat sich „Drag and Drop“ etabliert: Das zu verknüpfende Datenfeld wird mit der Maus angeklickt und bei gedrückter Maustaste auf ein Verknüpfungsziel gezogen. Wird die Maustaste losgelassen, solange sich das Datenfeld-Objekt über dem Verknüpfungsziel befindet, dann wird die entsprechende kombinierte Integration gestartet: Die benötigten Metadaten werden vom Metadatenserver angefordert. Die entsprechenden Systeme werden kontaktiert, und Datenabfragen werden abgesetzt. Die Ergebnisse der Abfragen werden gegebenenfalls kombiniert, abgeleitet, verdichtet und schließlich im Portal zur Anzeige gebracht. Neben sondierenden Verknüpfungen sind auch Szenarien denkbar, in denen die kombinierte Integration zu Datenänderungen im Verknüpfungs-Zielsystem führt.

5.1 Integration

■ ■ ■

123

Leider ist dieser Integrationstyp derzeit noch nicht standardisiert, weshalb jeder Portalhersteller seine eigene Implementierung anbietet. Die Portlet-API (vgl. Abschnitt 7.5.1) kann zukünftig Abhilfe schaffen – eine Inter-Portlet-Kommunikation steht auf der Aufgabenliste für die nächste Version des Portlet-Standards. Der Metadatenserver wird bei der Beschreibung der impliziten Beziehungen zwischen Datenquellen im Abschnitt 5.2.1 noch einmal thematisiert. Die aus der Integration abgeleiteten technischen Anforderungen lassen sich wie folgt zusammenfassen: Anforderungskatalog: Integration

124

■ ■ ■

■

Anwendungen und Systeme müssen offene, dokumentierte Schnittstellen nach außen anbieten. Idealerweise sind diese Schnittstellen standardisiert – z.B. in Form von Web Services – definiert.

■

Die Schnittstellen sollten in einem unternehmensweiten Katalog verzeichnet und gepflegt werden.

■

Zur zahlenmäßigen Minimierung der Schnittstellen sollte eine zentrale Integrationskomponente (Enterprise Application Integration, EAI) zum Einsatz kommen.

■

Die Schnittstellen sollten den Anforderungen einer WorkflowSystemintegration genügen, um die Modellierung und Ausführung integrierter und durchgängiger Geschäftsprozesse zu ermöglichen. So sollen die zu integrierenden Systeme in ihrer Schnittstelle Funktionen zur Abarbeitung der zugewiesenen Workflow-Aktivität definieren.

■

Die Benutzungsoberflächen der Portalapplikationen aller integrierten Systeme und Anwendungen müssen sich bezüglich des grafischen wie auch des funktionalen Layouts an dem für das Unternehmensportal definierten Standard orientieren.

■

Die Umgewöhnung der Benutzer von den Altanwendungen auf die Portalapplikationen sollte erleichtert werden, indem zusätzlich zu den „modernen“ auch die gewohnten Interaktionsformen angeboten werden.

■

Für die kombinierte Integration muss ein Metadatenserver die Datenbeziehungen für alle gewünschten Verknüpfungen definieren. Dieser kann in kleineren Projekten einfach über Datenbanktabellen und Views realisiert werden.

■

Quelle und Ziel der möglichen Verknüpfungen im Rahmen einer kombinierten Integration müssen für den Benutzer aus der Benutzungsoberfläche ersichtlich sein.

5 Technische Anforderungen

5.2 Implizite Beziehungen zwischen Datenquellen Unternehmensportale bieten den Benutzern einen einheitlichen Blick auf die Informationsressourcen eines Unternehmens und realisieren durchgängige Geschäftsprozesse unabhängig von technischen Systemgrenzen. Dazu müssen heterogene Systeme mit unterschiedlichen Daten und Datenstrukturen integriert und in eine einheitliche Infrastruktur eingebunden werden. Die Integrationsmöglichkeiten hängen davon ab, ob die Daten strukturiert oder unstrukturiert sind.

5.2.1 Strukturierte Daten Bei strukturiert vorliegenden Daten können die Beziehungen zwischen Daten formal abgebildet und oft direkt in einer Datenstruktur hinterlegt werden. Innerhalb einer Datenquelle sind die Beziehungen zwischen einzelnen Datenelementen in der Regel explizit definiert. In einem relationalen Datenbanksystem sind dies beispielsweise die Relationen zwischen Datenbanktabellen, die über Primär- und Fremdschlüssel sowie SQL-Abfragen (in den darüber liegenden Anwendungssystemen) dargestellt sind. In objektorientierten Systemen sind es die Assoziationen zwischen Objekten. Sobald die Daten über technische oder fachliche Systemgrenzen hinweg miteinander in Beziehung gesetzt werden sollen, ist eine explizite Definition dieser Beziehungen nicht mehr sinnvoll und oft nicht einmal möglich. Eine bidirektionale Beziehung zwischen zwei Datenquellen müsste – die technische Machbarkeit vorausgesetzt – in beiden Quellen implementiert werden. Dies kann die Integrität beider Datenquellen verletzen, da diese abhängig von Veränderungen der referenzierten Datenquelle sind. Hinzu kommt, dass beide Datenquellen in der Regel unterschiedliche Datenmodelle aufweisen. Um eine (fachliche) Beziehung herzustellen, muss die Semantik beider Modelle bekannt sein – eine Abbildung der Terminologien beider Datenquellen ermöglicht dann die Definition der Beziehung. Das Wissen über den semantischen Gehalt der Daten(quellen) ist dann in dieser Beziehung „versteckt“, was die Nachvollziehbarkeit und Qualitätssicherung erschwert. Hinzu kommt, dass eine Datenquelle üblicherweise zu mehr als einer anderen Datenquelle in Beziehung gebracht wird – es entsteht ein schwer wartbares und fehleranfälliges Relationsgeflecht, das den

5.2 Implizite Beziehungen zwischen Datenquellen

Datenintegrität

Semantik der Datenbeziehungen

■ ■ ■

125

Metadatenserver

Abb. 5.3 Der Metadatenserver verbindet Datenquellen

Änderungsaufwand mit jeder neuen Beziehungsdefinition vergrößert. Aus diesen Gründen ist es empfehlenswert, die Metamodelle aus den Datenquellen zu extrahieren und in einer eigenständigen Datenintegrationskomponente, dem Metadatenserver, zu definieren. Diese Komponente fungiert als „Wörterbuch“, in dem die mit unterschiedlichen Terminologien belegten, semantisch aber äquivalenten Inhalte verschiedener Datenquellen miteinander in Beziehung gesetzt werden. Dabei abstrahiert der Metadatenserver von der Struktur der verknüpften Datenquellen. Die Komponente ist auch für die technische Kommunikation zwischen den beteiligten Datenquellen zuständig. Sie legt außerdem für die verschiedenen fachlichen Datenstrukturen das jeweils führende System fest. Bei der Erweiterung bzw. der Modifikation der Systemarchitektur ist es nicht nötig, für jede neue oder geänderte Datenquelle direkte, punktuelle Schnittstellen zu entwickeln – es genügt, jeweils eine Anbindung an den Metadatenserver zu realisieren. Metadatenserver Führendes System (Master) Kundendaten

Auftragsdaten

...

= Beziehungen

ID KDNR NAME 1 9712 Möller

CRM-System

ID AUFTR KUNDE 42 201147 9712

Auftragsverwaltung

Abbildung 5.3 zeigt an einem einfachen Beispiel, wie der Metadatenserver eine fachliche Verbindung zwischen den Datensätzen zweier Unternehmensanwendungen herstellt und das führende System (Master) für verschiedene fachliche Informationsbereiche (Kundendaten und Auftragsdaten) definiert. Im Customer Relationship Management (CRM)-System sind die wesentlichen Informationen zu allen Kunden von Wein&Dein abgelegt. In der Datenbank des CRM-Systems hat jeder Datensatz einen internen Identifikator (ID). Die Kundennummer dient zugleich als

126

■ ■ ■

5 Technische Anforderungen

nach außen sichtbarer Identifikator, der z.B. in der Korrespondenz mit dem Kunden verwendet wird. Zudem sind der Name des Kunden und viele weitere Attribute gespeichert. In der Auftragsverwaltung sind alle auftragsbezogenen Daten gespeichert. Auch hier hat jeder Datensatz eine interne und eine externe ID (Auftragsnummer). Außerdem ist zu jeder Bestellung die Kundennummer des Bestellers gespeichert. Im Metadatenserver wird definiert, dass das Datenbankfeld KDNR des CRM-Systems und das Datenbankfeld KUNDE des Auftragsverwaltungssystems dieselbe Kundennummer bezeichnen. Über diesen eindeutigen Schlüssel können nun in beiden Systemen fachlich zueinander passende Daten ermittelt werden. Damit ist es z.B. möglich, alle offenen Aufträge eines Kunden zu recherchieren, von dem nur der Name, nicht aber die Kundennummer bekannt ist – und das, obwohl im Auftragsverwaltungssystem nur die Kundennummer gespeichert ist. Das Auftragsverwaltungssystem speichert allerdings auch Rechnungs- und Lieferadressen. Diese müssen nicht identisch mit der im CRM-System gespeicherten Adresse sein. Der Metadatenserver definiert für fachliche Datenstrukturen das führende System (den „Master“). Der in Abb. 5.3 dargestellte Metadatenserver legt fest, dass das CRM-System führend bei der Verwaltung der Kundendaten ist.

5.2.2 Unstrukturierte Daten Im Gegensatz zu den strukturierten Daten fehlen bei unstrukturierten Daten die beschreibenden Mittel, um Beziehungen zwischen Daten auszudrücken. Aufgrund der fehlenden Struktur können diese Daten nur auf der Basis der ihnen innewohnenden Informationen miteinander in Beziehung gesetzt werden. Dazu müssen die Daten indiziert und die Informationen extrahiert und kategorisiert werden. Die Indizierung der Daten erlaubt die strukturierte Recherche in der Datenbasis. Durch die Zuordnung der Daten zu verschiedenen Kategorien lassen sich kontextabhängig inhaltliche Zusammenhänge erkennen und darstellen. Diese Aufbereitung der Daten gehört zu den Aufgaben einer Knowledge Management-Komponente. Diese wird später, bei der Vorstellung des fachlichen Architekturmodells, noch ausführlicher beschrieben.

5.2 Implizite Beziehungen zwischen Datenquellen

■ ■ ■

127

Abb. 5.4 GATE – General Architecture for Text Engineering

GATE (gate.ac.uk) ist ein Rahmenwerk für die automatische Informationsextraktion aus natürlichsprachlichen Texten. Es stellt verschiedene Softwarekomponenten zur Verfügung. Diese dienen der Zerlegung des Textes in seine Bestandteile, der Textanalyse sowie der Annotation (vgl. Abschnitt 5.3). Darüber hinaus bietet es eine grafische Oberfläche, in der diese Komponenten miteinander verbunden, konfiguriert und auf Texte angewendet werden können. Abb. 5.4 zeigt das Ergebnis einer solchen Textanalyse. Im rechten Fenster sind die Annotationsklassen zu sehen, die über modifizierbare Regelwerke definiert werden. Schaltet eine solche Regel für einen Textbestandteil, so wird dieser entsprechend annotiert (grau hinterlegte Wörter im linken Fenster). GATE kann außerdem Identitätsbeziehungen (Koreferenzen) zwischen Annotationen feststellen, so z.B. das mehrfache Vorkommen der „Organization“ Yahoo im Beispieltext.

128

■ ■ ■

5 Technische Anforderungen

Damit lassen sich für die impliziten Beziehungen zwischen Datenquellen zwei zentrale Forderungen definieren: ■

Beziehungen zwischen strukturierten Daten aus verschiedenen Systemen sollen in einem zentralen Metadatenserver beschrieben werden.

■

Um Beziehungen zwischen unstrukturierten Daten automatisch knüpfen zu können, sind Werkzeuge zur „intelligenten“ Erschließung und semantischen Anreicherung nötig.

Anforderungskatalog: Implizite Beziehungen zwischen Datenquellen

5.3 Modelle für Metadaten Um eine Menge von Daten unterschiedlicher Struktur und Herkunft einer fachlichen Recherche zugänglich zu machen, müssen Metadaten mit diesen Daten verknüpft werden. Unter Metadaten („Daten über Daten“) versteht man strukturierte Daten, mit deren Hilfe eine Informationseinheit beschrieben und dadurch besser auffindbar gemacht wird. Abb. 5.5 MP3-Datei mit Metadaten

Abbildung 5.5 zeigt eine MP3-Datei namens „AmericanPie.mp3“. Allein aus dem Dateinamen lässt sich nicht erkennen, ob es sich dabei um das Original von Don McLean, die Version von Madonna oder den Soundtrack zum gleichnamigen Kinofilm handelt. Eine MP3-Wiedergabesoftware könnte keine Wiedergabelisten (Playlists) zusammenstellen, die nur ausgewählte Musikstile oder Interpreten enthalten. In einer MP3-Datei können aber Metainformationen über das Musikstück gespeichert werden. Die Attribute „Interpret“, „Albumtitel“, „Jahr“ und „Titelnummer“ sind Bestandteil dieses ID3v1Metadatenformats.

5.3 Modelle für Metadaten

■ ■ ■

129

5.3.1 Typen von Metadaten Bearman und Sochats (1995) unterscheiden folgende Metadatentypen:

Context

Content

■

Metadaten zur Identifikation und zu Nachweiszwecken („resource discovery“),

■

Metadaten für Zugangsbedingungen sowie Nutzungs- und Beschaffungskonditionen („terms and conditions“),

■

Metadaten zu strukturellen Aspekten („structure“),

■

Metadaten zum Kontext („context“),

■

Metadaten zum Inhalt („content“),

■

Metadaten zur Nutzungs- und Wirkungshistorie („use history“).

Dieses Buch ist ein strukturierter Text, bestehend aus einer Titelei, einem Inhaltsverzeichnis, Kapiteln mit Überschriften 1. bis 3. Ordnung und einem Index. Einige dieser Strukturinformationen finden sich in den Formatvorlagen der Textverarbeitung wieder. Der Kontext von unstrukturierten Daten ist unter anderem für Informationsportale wichtig. Immer öfter werden die dargestellten Informationen automatisch um passende Inhalte ergänzt. Dabei hängt es vom Kontext ab, ob ein Bericht über Madonna um die aktuelle CD der Sängerin (Kontext „Musik“) oder um religiöse Inhalte (Kontext „Religion“) ergänzt werden muss. Das im vorigen Beispiel vorgestellte ID3v1-Metadatenformat enthält Metadaten zum Inhalt einer MP3-Datei. Abhängig von den Anforderungen an die Informationsrecherche müssen die Unternehmensdaten mit Metadaten einer oder mehrerer der oben genannten Kategorien angereichert werden. Neben dieser sehr allgemeingültigen Kategorisierung gibt es auch spezielle Gründe, die für die Einführung von Metadaten sprechen. Es ist sinnvoll, die verschiedenen Typen von Metadaten bei der Ergänzung der Daten deutlich zu unterscheiden. Das bedeutet, dass jedes Metadatum seinerseits mit einem Metadatum – seinem Typ – versehen wird.

130

■ ■ ■

5 Technische Anforderungen

5.3.2 Metadaten zum standardisierten Datenaustausch Hinter dem Begriff der Metadaten steht heute auch die Suche nach neuen Ansätzen in der unternehmensübergreifenden Ressourcenbeschreibung und nach den entsprechenden Verfahren der Informationsvermittlung, die auf einen effizienten und kostengünstigen Einsatz in elektronischen Netzen hin optimiert sind. Solche Beschreibungen können den Austausch von Geschäftsinformationen zwischen Unternehmen, oft sogar schon zwischen verschiedenen Abteilungen eines Unternehmens, vereinfachen, beschleunigen und die Grundlage für die Automatisierung des Datenaustauschs schaffen. Die Metadaten werden mithin zum „Dolmetscher der Integration“ – aber nur dann, wenn sie günstige Rahmenbedingungen vorfinden. So stellen fehlende Standards bei der Definition von Metamodellen weiterhin das größte Problem bei der technischen Umsetzung der Informationsintegration dar. Beim Austausch von Informationen und Dokumenten werden Unternehmen immer wieder durch „inkompatible“ Metadaten vor Hindernisse gestellt. Der Einsatz eines Metadatenservers ermöglicht es immerhin, die Übersetzung der verschiedenen Metadaten-Domänen zentral zu verwalten – besser ist es jedoch, wenn eine solche Übersetzung gar nicht erst notwendig wird. Metadaten sollten immer zielbezogen für die derzeit gültigen Anforderungen definiert werden. Eine vorsorgliche Definition zusätzlicher Metadaten, die eventuell für zukünftige Anwendungsfelder relevant sein könnten, generiert nur zusätzlichen Aufwand, ohne jedoch zeitnah einen Nutzen zu bringen. Der Aufwand für das Ergänzen der Nutzdaten um Metadaten darf nicht unterschätzt werden. Immerhin muss in vielen Fällen dieser als Annotation bezeichnete Prozess manuell durchgeführt werden. Allein deshalb empfiehlt es sich, mit einer kleinen Metadatenmenge zu beginnen und sich auf die tatsächlich benötigten Metadaten zu beschränken. Das setzt allerdings voraus, dass die Informationssysteme flexibel genug sind, um später zusätzliche Metadaten zu ergänzen. Um die Verwertung von Unternehmenswissen über Systemgrenzen hinweg zu gewährleisten, wird ein umfassendes und effizientes Knowledge Management benötigt. Es muss die zielgerichtete Verwaltung und eine einfache und unkomplizierte Indizierung der unterschiedlichen Informationen und Dokumente unterstützen, um effiziente Suchverfahren zu ermöglichen. Gesucht ist also ein flexibel erweiterbares Metamodell, das auf die Anforderungen des Knowledge Management zugeschnitten ist.

5.3 Modelle für Metadaten

■ ■ ■

131

Anforderungskatalog: Modelle für Metadaten

Zu den Anforderungen an ein solches Metamodell gehören ■

einfache Ergänzung (Annotation) der Nutzdaten um Metadaten, möglichst direkt im datenliefernden System,

■

Kategorisierung der annotierten Metadaten als Grundlage für die Gruppierung und Indizierung der Daten,

■

Erweiterbarkeit der annotierten Metadaten (Think big – start small).

5.4 Datensicherheit Das Thema „Sicherheit“ wurde bereits bei den fachlichen Anforderungen adressiert. Auch für die technische Realisierung eines Unternehmensportals wird ein angemessenes Maß an Sicherheit gefordert. Die Schutzziele sind identisch mit den bei den fachlichen Anforderungen genannten und werden hier noch einmal kurz aufgelistet. Die Forderung nach Verfügbarkeit wird im folgenden Abschnitt weiter detailliert. Anforderungskatalog: Datensicherheit

■

Vertraulichkeit: Schutz vor unbefugter Kenntnisnahme

■

Integrität: Schutz vor Manipulation

■

Authentizität: Schutz vor gefälschter Identität/Herkunft

■

Verfügbarkeit: Schutz vor Ausfall der IT-Systeme

■

Nachvollziehbarkeit: Protokollierung der Datenmodifikation und -sondierung

5.5 Verfügbarkeit Unternehmenskritische Daten und Anwendungen müssen möglichst unterbrechungsfrei zur Verfügung stehen. Die Forderung nach einer 100%–Verfügbarkeit (24/7 – 24 Stunden am Tag, 7 Tage in der Woche) wird in der Praxis für viele Systeme weder erreicht noch gefordert. Meistens genügt es, die Verfügbarkeit während der üblichen Bürozeiten zu garantieren. Eine bekannte und verbreitete Ausnahme sind Web Shop-Systeme. Hier kann der Kunde rund um die Uhr einkaufen – entsprechend müssen die Systeme immer funktionieren. Eine abgeschwächte Form der Forderung nach Verfügbarkeit lautet deshalb: Systemausfälle sind weitestgehend, mindestens aber für

132

■ ■ ■

5 Technische Anforderungen

definierte Zeiträume, zu begrenzen bzw. zu verhindern. Das betrifft sowohl unvorhergesehene Ausfälle wie Fehler in der Hard- oder Software, Bedienungsfehler, Stromausfall oder Netzwerkfehler, als auch vorhersehbare Ausfälle aufgrund von Wartung oder Veränderungen an der Hardware- und Softwarekonfiguration. Nur eine sorgfältige Technologieauswahl bei der Implementierung eines hochverfügbaren Systems, in Kombination mit einem Konzept für sichere und schnelle Backups, verhindert lange und kostspielige Ausfallzeiten. Im Folgenden werden einige Grundanforderungen für verfügbare Systeme näher betrachtet. Anschließend wenden wir uns den hochverfügbaren Systemen zu.

5.5.1 Grundlegende Anforderungen Sobald es zu einem Störungsfall kommt, muss der Datenzugriff weiterhin gewährleistet sein. Insbesondere ist dafür zu sorgen, dass das System in einen konsistenten Zustand überführt wird. Dazu werden in allen noch nicht abgeschlossenen System- und Datenbanktransaktionen die bereits erfolgten Änderungen rückgängig gemacht. Oder ein zweites, identisches System übernimmt die Aufgaben des ausgefallenen Systems – in diesem Fall muss das Notfallsystem denselben Datenzustand widerspiegeln. Dabei ist zu beachten, dass nicht jede Anwendungssoftware einen solchen Standby-Betrieb unterstützt. Zeitgemäße Systemarchitekturen trennen die Anwendungssoftware von der Datenspeicherung. Erstere liegt auf einem Anwendungsserver (Application Server), während die Datenbanken, in denen die Nutz- und Konfigurationsdaten der Anwendung lagern, auf einem getrennten Datenbankserver installiert sind. Neben dieser fachlichen Trennung greifen die Serversysteme zunehmend auf eigenständige Datenspeichereinheiten (Storage Systems) zu. Auch dort sollen die Anwendungen und Datenbanken physisch voneinander getrennt gespeichert werden. Da Festplatten aufgrund der enormen Beanspruchung zu den ausfallgefährdeten Komponenten gehören, werden die Daten redundant auf mehreren Festplatten gespeichert. Für diese redundante Datenspeicherung (RAID – Redundant Array of Independent/Inexpensive Disks) gibt es verschiedene Konzepte (RAID-Level), die neben der Datensicherheit auch eine möglichst optimale Zugriffsgeschwindigkeit berücksichtigen.

5.5 Verfügbarkeit

Datenkonsistenz und unterbrechungsfreier Datenzugriff im Störungsfall

Redundante Datenspeicherung

RAID

■ ■ ■

133

Horizontal skalierbare Sicherungssysteme

Zentrale Konfiguration, Administration und Überwachung der IT-Infrastruktur

Eine regelmäßige Datensicherung bildet die Grundlage für die Rekonstruierbarkeit des Systemzustands. Mit zunehmendem Datenvolumen muss aber auch die Kapazität des Sicherungssystems ansteigen. Die Wahl eines skalierbaren Sicherungssystems bietet die nötige Flexibilität. Eine Erhöhung der Speicherkapazität des Sicherungssystems darf aber nicht zu Lasten des Wiederherstellungsaufwands gehen. Was nützt es, wenn die Unmengen gesicherter Daten im Störungsfall nur mit großem Zeitaufwand wiederhergestellt werden können? Dieser Aufwand ist bei der Definition der maximal zulässigen Ausfallzeiten zu berücksichtigen. Bei einer Störung bzw. dem Ausfall eines Systems muss schnell gehandelt werden, um die Ausfall- bzw. Störungszeit so kurz wie möglich zu halten. Deshalb ist es wichtig, dass die Fehlerursache möglichst schnell identifiziert wird und der Fehler mit möglichst geringem Zeit- und Personalaufwand behoben werden kann. Je komplexer ein System aufgebaut ist, desto mehr potenzielle Fehlerquellen birgt es. Laufen die Informationen über den Zustand dieser Fehlerquellen an einer Stelle zusammen, so kann der Fehler in der Regel schneller gefunden werden. Kann von dieser zentralen Stelle aus die Fehlerbehebung eingeleitet oder gar komplett durchgeführt werden, dann minimiert auch dies den Zeitaufwand. Aus diesem Grund setzen Rechenzentren zentrale Überwachungssysteme ein. Ein Überwachungssystem ist aber nur so gut wie die Statusinformationen und die Schnittstellen zur Fehleranalyse und -behebung der zu überwachenden Software. Deshalb muss bei jeder einzelnen Systemkomponente – insbesondere bei eigenentwickelter Software – auf die Eignung für die genannten Überwachungssysteme geachtet werden.

5.5.2 Hochverfügbarkeit In der Literatur finden sich viele Definitionen des Begriffs „Hochverfügbarkeit“. Allen gemein ist die Forderung, dass ein System auch im Fehlerfall für alle (oder zumindest den überwiegenden Teil) der Anwender benutzbar bleibt und diese keine oder nur eine kurze Unterbrechung wahrnehmen. Zur Erfüllung dieser Forderung werden Systeme redundant ausgelegt. Resnick (1996) hat diesen Lösungsansatz in seine Definition der Hochverfügbarkeit (High Availability, HA) aufgenommen: “A system which is designed, implemented and deployed with sufficient components to satisfy the system's functional requirements but which also has sufficient redundancy in components (hardware, software and procedures) to mask certain defined faults, has High Availability (HA).”

134

■ ■ ■

5 Technische Anforderungen

Unter “Masking” versteht Resnick die Nichtwahrnehmbarkeit eines Ereignisses, in diesem Fall eines Fehlers. Die wichtigste Kenngröße für die Hochverfügbarkeit ist neben der maximalen Dauer eines einzelnen Systemausfalls die Verfügbarkeit, meist als prozentual bezogen auf ein Jahr angegeben. Eine Verfügbarkeit von 99% entspricht einer Ausfallzeit von insgesamt 3,6 Tagen pro Jahr. Bei einer Verfügbarkeit von 99,99999% darf das System nur 3 Sekunden pro Jahr ausfallen (Abb. 5.6). Abb. 5.6 Prozentuale Verfügbarkeit in Abhängigkeit von der Ausfallzeit pro Jahr

Ausfallzeit pro Jahr (sec.)

300.000 250.000 200.000 150.000 100.000 50.000

99

99,9

99,99

99,999

99,9999

99,99999

Verfügbarkeit (%)

Zu den weiteren Kenngrößen für Hochverfügbarkeit zählen: ■

Zuverlässigkeit,

■

Reaktionszeit: Zeitspanne zwischen dem Auslösen einer Aktion des Systems und der Ausführung dieser Aktion,

■

Mean Time between Failure (MTBF): Die mittlere ausfallfreie Zeit eines Systems,

■

Mean Time to Repair (MTTR): Die mittlere Dauer für die Wiederherstellung nach einem Ausfall,

■

Mean Time between Crash (MTBC): Die mittlere ausfallfreie Zeit eines Betriebssystems.

Auf der projekt- und systemspezifischen Ausgestaltung dieser Kenngrößen basieren die Vereinbarungen bzw. Verträge, in denen die Systemverfügbarkeit geregelt wird (Service Level Agreements, SLA). Hochverfügbarkeit ist eine Anforderung, die oft aufgestellt wird, ohne vorher die Eignung des Hardware- bzw. Softwaresystems für einen hochverfügbaren Einsatz untersucht zu haben.

5.5 Verfügbarkeit

■ ■ ■

135

Während für Betriebssysteme oder Datenbanken Mechanismen für den Betrieb in einem Server-Cluster weitgehend vorhanden sind, ist dies bei Spezialanwendungen und eigenentwickelter Software nicht immer der Fall. So fehlen meistens Mechanismen, die für die Systemüberwachung und den Wechsel auf ein Parallelsystem (das z.B. im selben Server-Cluster läuft) notwendig sind. Beim Ausfall eines Cluster-Knotens vollziehen Betriebssystem und Datenbank den Wechsel auf das Ersatzsystem automatisch und ohne Informationsverlust. Die Fachanwendung hingegen muss auf dem anderen Cluster-Knoten manuell gestartet werden. Der Systemzustand und die Daten sind unter Umständen inkonsistent.

5.5.3 Single Point of Failure Ein Single Point of Failure ist eine Systemkomponente, deren Ausfall oder Fehlfunktion einen Ausfall des Gesamtsystems nach sich zieht. Eine wesentliche Anforderung der Systemverfügbarkeit ist deshalb die weitgehende Reduzierung der Single Points of Failure. Tabelle 5.1 listet einige bekannte Fehlerquellen auf und beschreibt mögliche präventive Maßnahmen.

Tabelle 5.1 Single Points of Failure

Single Point of Failure

Mögliche präventive Maßnahmen

Stromversorgung

Installation einer unterbrechungsfreien Stromversorgung (USV), Alarmierung bei Stromausfall Ständige Temperaturüberwachung, Alarmierung bei Überschreiten eines festgelegten Temperatur-Schwellwertes Redundante Auslegung der ausfallgefährdeten Hardwarekomponenten Rechtzeitige und regelmäßige Aktualisierung des Betriebssystems (Updates, Patches) Rechtzeitige und regelmäßige Aktualisierung der Software (Updates, Patches) Aufbau einer verfügbaren und sicheren Netzwerkinfrastruktur Weitgehende Automatisierung der Notfallmaßnahmen; Unterstützung des Personals durch Handlungsanweisungen/Checklisten

Klimaautomatik

Hardware (z.B. Festplatten) Betriebssystem Anwendungssoftware Netzwerk Systemüberwachung

136

■ ■ ■

5 Technische Anforderungen

Neben den genannten Fehlerquellen ist der Mensch ein wesentlicher Unsicherheitsfaktor und damit eine häufige Ursache für einen Systemausfall. Allerdings wird man Menschen nicht als Single Points of Failure bezeichnen – dieser Begriff wird nur im Zusammenhang mit (technischen) Systemen verwendet. Dennoch ist es an dieser Stelle angebracht, auch die „Fehlerquelle Mensch“ zu betrachten. Die Gegenmaßnahmen sind so vielfältig wie die Situationen, in denen menschliches Versagen zum Systemausfall führt. Bei der Entwicklung eines (Portal-)Softwaresystems muss der Faktor Mensch bei vielen Entwurfsentscheidungen berücksichtigt werden. Das beginnt bei der Definition des Entwicklungsprozesses. Reviews der Spezifikationen und des Programmcodes leisten einen wesentlichen Beitrag zur Qualitätssicherung der eigenentwickelten Softwarekomponenten. Ein wohldefiniertes, mehrstufiges Release Management sorgt dafür, dass neue Versionen der Software in einer eigenen, dem Produktivsystem möglichst ähnlichen Umgebung hinsichtlich der Installierbarkeit und Funktionsfähigkeit getestet werden, bevor sie im Produktivsystem installiert und zur Benutzung freigegeben werden. Die Fehler, die bei der Benutzung des Softwaresystems infolge falscher Benutzereingaben auftreten, lassen sich ebenfalls vermeiden oder zumindest abmildern, z.B. durch einen logischen Aufbau der Benutzungsoberfläche, Plausibilitätsprüfungen oder die Möglichkeit, Aktivitäten rückgängig zu machen (Undo-Funktionalität).

Fehlerquelle Mensch

Damit lassen sich die Anforderungen an (hoch-)verfügbare Systeme wie folgt zusammenfassen:

Anforderungskatalog: Verfügbarkeit

■

Sicherstellung eines unterbrechungsfreien Datenzugriffs im Störungsfall,

■

redundante Datenspeicherung,

■

horizontal skalierbare Sicherungssysteme,

■

zentrale Konfiguration, Administration und Überwachung der IT-Infrastruktur,

■

Identifikation der Single Points of Failure und das Ergreifen präventiver Maßnahmen.

5.5 Verfügbarkeit

■ ■ ■

137

5.6 IT-Sicherheit Aufgrund der zunehmenden Vernetzung der Computersysteme sind immer mehr Anwendungen per Internet erreichbar. Dies, sowie die Tatsache, dass viele dieser Anwendungen mit einer browserbasierten Benutzungsoberfläche ausgestattet sind, macht sie zum potenziellen Ziel von Angriffen über das Internet. Abhängig von der gewählten Programmierumgebung (z.B. CGI, PHP oder JavaServer Pages, JSP) und vom verwendeten Webbrowser (allen voran der Microsoft Internet Explorer) kommen bei einem Angriff auf eine Webanwendung verschiedene Techniken zum Einsatz. Huseby (2004) behandelt unter anderem die folgenden Techniken:

Buffer Overflow

138

■ ■ ■

■

SQL Injection: Duch geschickte Formulierung von Eingaben in einer Webanwendung können Datenbankabfragen manipuliert werden.

■

Shell Command Injection: Durch geschickte Formulierung von Eingaben in einer Webanwendung können Betriebssystemkommandos an den Server transportiert und zur Ausführung gebracht werden.

■

Cross Site Scripting (XSS): Ein Webserver wird dazu benutzt, böswilligen HTML-Text – üblicherweise Skriptcode – an die Benutzer auszuliefern. Mit XSS können Session-Informationen erspäht (Session Hijacking) und damit Zugang zu gesicherten Webanwendungen erlangt werden.

■

Web-Trojaner / Phishing (Password Fishing): Der Angreifer versucht, Andere durch eine E-Mail oder einen Link dazu zu bringen, eine Webseite anzuwählen, die sie nie im Sinn hatten. Damit kann der Angreifer z.B. Zugang zum gesicherten Kundenbereich einer Online-Bank bekommen.

Neben den genannten Techniken werden auch Fehler in Softwaresystemen (z.B. Web- oder Mailserver) ausgenutzt, um unberechtigten Zugriff zu dem System zu erlangen. So kann z.B. der Versand präparierter Datenpakete beim empfangenden System einen Pufferüberlauf (Buffer Overflow) bewirken. Dadurch gelangt der in den Datenpaketen enthaltene böswillige Code zur Ausführung auf dem Serversystem. Dieser verschafft dem Angreifer uneingeschränkten Systemzugriff.

5 Technische Anforderungen

Portalsysteme verwenden in den meisten Fällen einen Webbrowser für die Benutzerschnittstelle. Somit fallen sie in die Kategorie der Webanwendungen und müssen sich vor den oben genannten Angriffstechniken schützen. Dazu muss die vom Internet aus zugreifbare IT-Infrastruktur regelmäßig überwacht und gesichert werden. Solche Sicherheits-Audits sollten nur von Experten durchgeführt werden, die über eine entsprechende Ausbildung und die nötige Erfahrung verfügen. Durch gute Programmierung lassen sich viele der oben genannten Angriffstechniken verhindern. Insbesondere bei der Entwicklung von Webanwendungen müssen die Programmierer für diese Angriffstechniken sensibilisiert werden, damit sie ihren Code entsprechend robust gestalten. Es gehört zu den Aufgaben des Projektleiters, das Thema Sicherheit als Projektziel zu verankern und konsequent zu verfolgen. Das Aufgabengebiet der IT-Sicherheit umfasst aber weit mehr als die genannten Webanwendungen. Auch Systeme, die nicht mit dem Internet verbunden sind, können lohnende Ziele eines Angriffs sein. Die Beschäftigung mit diesem Thema gehört zum Pflichtprogramm für jeden IT-Verantwortlichen und Projektleiter.

Sicherheitsaudits

Sicherheit in der Programmierung

5.7 Skalierbarkeit „Think big – start small“ – diese Regel zur erfolgreichen Einführung von Softwaresystemen empfiehlt, das System zunächst mit einem überschaubaren Leistungsumfang zu implementieren („start small“) und anschließend zu erweitern. Um sich die späteren Erweiterungsmöglichkeiten nicht von vornherein zu verbauen, sollten aber bereits in der ersten Ausbaustufe entsprechende Schnittstellen und flexible Strukturen vorgesehen werden („think big“). Die obige Regel kann aber auch für einen anderen Aspekt der Skalierbarkeit gelten: Die Eignung der Portalinfrastruktur für eine zunehmende Anzahl von parallel arbeitenden Benutzern. Bis zu einem gewissen Grad kann diese Skalierbarkeit über den Einsatz von größerer und leistungsfähigerer Hardware erreicht werden („Skalierbarkeit in Blech“). Irgendwann ist jedoch der Punkt erreicht, an dem auch eine noch bessere Hardware-Ausstattung nicht mehr helfen kann. Spätestens dann zeigt sich, ob die Softwarearchitektur flexibel genug ist, um mit einer höheren Systemlast umgehen zu können. Insbesondere der Kommunikationsaufwand zwischen den Komponenten verdient Beachtung, da dieser in der Regel überproportional

5.7 Skalierbarkeit

■ ■ ■

139

ansteigt. Die geplante Anzahl der Systembenutzer und eine Abschätzung des jährlichen Wachstums der Benutzerzahlen sind wichtige Kenngrößen für die Berücksichtigung der Skalierbarkeit in der Systemarchitektur. Da nicht jeder im Portal registrierte Benutzer auch tatsächlich regelmäßig damit arbeitet, muss außerdem eine mittlere und eine maximale Systemauslastung geschätzt werden. Zusammengefasst bedeutet das: Anforderungskatalog: Skalierbarkeit

■

Think big – start small,

■

Auslegung aller kritischen Systemkomponenten auf steigende Belastung,

■

besondere Berücksichtigung der Kommunikation zwischen Komponenten,

■

Planung und Abschätzung der aktuellen und zukünftigen Anzahl an Benutzern sowie der mittleren und der maximalen Systemauslastung.

5.8 Verteilbarkeit Unternehmensportale sind komplexe Systeme, bestehend aus unterschiedlichen fachlichen und technischen Komponenten. Die einzelnen Komponenten werden später ausführlich vorgestellt. In diesem Abschnitt geht es um die Frage, wie diese Komponenten innerhalb der IT-Landschaft des Unternehmens angeordnet werden können, und welche Vor- und Nachteile eine Verteilung der Komponenten auf mehrere technische Systeme (Server) mit sich bringt. Eine verteilte Anwendung besteht aus einer Menge kooperierender Prozesse, die auf mehrere Rechner verteilt sind und gemeinsam eine Anwendung oder einen Dienst zur Verfügung stellen. Das Netzwerk – egal, ob LAN (Local Area Network) oder Internet – spielt dabei eine zentrale Rolle, da es als Transportmedium für den Austausch von Nachrichten zwischen den Prozessen dient. Da diese nicht über einen gemeinsamen Speicher verfügen, müssen alle Zustandsänderungen eines Prozesses als Nachricht versendet werden, um den Zustand aller Prozesse konsistent zu halten. Verteilte Systeme zeichnen sich durch eine inkrementelle Erweiterbarkeit aus, die neben der Skalierbarkeit bei zunehmenden Leistungsanforderungen (z.B. durch eine steigende Zahl an Benutzern) auch eine Ausfallsicherheit gewährleisten kann, sofern die kooperierenden Prozesse gleichartig und damit redundant ausgelegt sind. In

140

■ ■ ■

5 Technische Anforderungen

diesem Fall erscheint das verteilte System wie eine einzige virtuelle Komponente. Tanenbaum und van Steen (2002) definieren ein verteiltes System (Distributed System) als „collection of independent computers that appears to its users as a single coherent system“. Der Benutzer kann nicht erkennen, welcher konkrete Prozess dieser virtuellen Komponente für die Ausführung seiner Anwendung verantwortlich zeichnet. Leslie Lamport hat eine vielzitierte Definition für verteilte Systeme geprägt, die auf diesem Charakteristikum beruht: “[A distributed system is] one on which I cannot get any work done because some machine I have never heard of has crashed.”

Der Entwurf verteilter Anwendungen sollte einigen grundlegenden Prinzipien folgen, die im Folgenden kurz vorgestellt werden. Wir haben unsere Darstellung auf die für Unternehmensportale besonders relevanten Prinzipien beschränkt. Viele der in diesem Kapitel genannten technischen Anforderungen (z.B. Skalierbarkeit) gelten auch für verteilte Systeme – sie werden deshalb an dieser Stelle nicht aufgeführt. Eine vollständige Übersicht über verteilte Systeme findet man z.B. bei Tanenbaum und van Steen (2002).

Entwurfsprinzipien

5.8.1 Gemeinsame Nutzung von Ressourcen Unternehmensportale sind grundsätzlich für den Mehrbenutzerbetrieb ausgelegt und müssen deshalb sorgsam mit den verfügbaren Ressourcen umgehen können. Zu diesen Ressourcen zählen Hauptspeicher, Massenspeicher und Peripheriegeräte, aber auch die Daten. Ressourcen, auf die zu jedem Zeitpunkt nur exklusiv von einem Prozess bzw. Benutzer zugegriffen werden darf, müssen nach erfolgter Nutzung wieder freigegeben werden. Das ist insbesondere im Portalumfeld wichtig, da dort Ressourcen aus den verschiedenen Unternehmensanwendungen genutzt werden. Das Portal konkurriert mit den „klassischen“ Unternehmensanwendungen um diese Ressourcen. Es ist zu gewährleisten, dass die Ressourcenverteilung fair und nutzungsorientiert ist. Mit anderen Worten: Eine Ressource sollte nur dann blockiert werden, wenn sie tatsächlich benötigt wird, und dann auch nur für die tatsächliche Nutzungsdauer.

5.8 Verteilbarkeit

■ ■ ■

141

Ressourcen, die nur exklusiv genutzt werden können, werden schnell zu einem Flaschenhals des Systems. Es muss ferner gewährleistet werden, dass keine Verklemmungen (Deadlocks) auftreten. Diese entstehen, wenn zwei Prozesse gegenseitig auf die Freigabe einer Ressource warten.

5.8.2 Transparenz Das oben wiedergegebene Zitat von Leslie Lamport beschreibt gut, wie ein verteiltes System als transparentes Gebilde verstanden werden kann, dessen konkrete Zusammensetzung der Benutzer nicht kennen muss. Transparenz hat viele Aspekte – einige wesentliche wollen wir an dieser Stelle aufführen. ■

Räumliche Transparenz: Dienste können genutzt werden, ohne den Ort der Dienstausführung kennen zu müssen. Die Dienste können zudem ihren Ort wechseln, ohne ihren Namen zu ändern.

■

Zugriffstransparenz: Das verteilte System bietet eine einheitliche Zugriffsmöglichkeit für lokale (d.h. auf demselben Rechner ablaufende) und entfernte Dienste.

■

Transparenz der Redundanz: Systeme und Komponenten können beliebig viele Kopien haben. Der Daten- und Zustandsabgleich zwischen den Kopien geschieht automatisch.

■

Transparenz der Nebenläufigkeit: Gemeinsam genutzte Ressourcen werden vor konkurrierenden Zugriffen geschützt.

Die Transparenz wird im Fall der Unternehmensportale auch hinsichtlich der Datenbasis gefordert. Dem Benutzer eines Unternehmensportals sollen die Informationen unabhängig von der konkreten Datenquelle präsentiert werden, um eine umfassende Recherche sowie die Modellierung systemübergreifender Geschäftsprozesse ohne technische Grenzen zu ermöglichen.

5.8.3 Performanz Dem Thema Performanz widmen wir einen eigenen Abschnitt (5.12).

142

■ ■ ■

5 Technische Anforderungen

5.8.4 Adressierbarkeit (Naming) Die von einem verteilten System angebotenen Dienste müssen über einen eindeutigen Namen angesprochen werden. Oftmals existieren zwei Namensräume: Ein technischer Namensraum (z.B. IP-Adresse „81.209.184.90“) und ein fachlicher Namensraum (z.B. Domainname „www.pret-a-portal.info“), die miteinander in Beziehung stehen. Namensdienste strukturieren diese Informationen und bilden unterschiedliche Namensräume aufeinander ab. In Unternehmensportalen müssen auch die angebotenen Informationen, Applikationen, Dienste und Prozesse eindeutig identifiziert werden können. Dabei sollen die fachlichen Namen von den technischen Strukturen (Name des Servers bzw. der Datenquelle) abstrahieren und möglichst sprechend sein.

5.8.5 Konsistenz Die Forderung nach Konsistenz bezieht sich auf die drei Bereiche Datenkonsistenz, Replikation und Cache. Insbesondere bei der gleichzeitigen Manipulation derselben Daten durch mehrere Dienste oder Benutzer muss die Konsistenz der Daten vor und nach jeder Aktion gewährleistet sein. Diese Anforderung wird durch Transaktionsmechanismen gelöst: Jede Aktion wird als Folge von atomaren Befehlen implementiert. Jede Teilfolge von Befehlen, die gesamthaft ablaufen muss, um die Datenkonsistenz zu gewährleisten, wird als Transaktion modelliert. Ist die Ausführung einer Transaktion erfolgreich, so wird die Befehlsausführung fortgesetzt. Trat ein Fehler auf, so werden alle innerhalb der Transaktion manipulierten Daten (und Systemzustände) auf ihren Ausgangswert zurückgesetzt, den sie vor der Transaktionsausführung innehatten. Für Unternehmensportale stellt der Transaktionsmechanismus eine wesentliche Voraussetzung dar – insbesondere für die kombinierte Integration. Da hier unter Umständen Daten in verschiedenen Systemen zeitgleich verändert werden, muss deren Konsistenz gewährleistet sein. Die Modellierung und Implementierung solcher verteilten (systemübergreifenden) Transaktionen ist nicht trivial. Replizierte Kopien der Daten, z.B. auf mobilen Endgeräten, müssen konsistent zum Originaldatenbestand gehalten werden. Erschwert wird diese Forderung durch die Tatsache, dass Änderungen sowohl auf dem Original als auch auf der Replik der Daten stattfinden können. Synchronisationsmechanismen sorgen für den notwen-

5.8 Verteilbarkeit

Datenkonsistenz

Replikation

■ ■ ■

143

Cache

digen Datenabgleich und warnen, falls dasselbe Datum im Original und in der Replik manipuliert wurde. Mit zunehmender Mobilität von Unternehmensportalen wächst der Stellenwert von Replikationsmechanismen. Außendienstmitarbeiter (z.B. im Vertrieb oder im Service) müssen mit aktuellen Unternehmensinformationen versorgt werden, um vor Ort beim Kunden eine zuverlässige und erfolgreiche Dienstleistung erbringen zu können. Zugleich müssen die von ihnen erfassten Informationen in die zentralen Informationssysteme des Unternehmens eingespeist werden, um z.B. strategische Entscheidungen auf der Basis aktueller Daten fällen zu können. Gleiches gilt für Unternehmen mit mehreren Standorten, wenn Kopien bestimmter Daten in jedem Standort lokal vorgehalten werden. Die Aktualität der Daten kann nur gewährleistet werden, wenn der Datenabgleich schnell, sicher und konsistenzerhaltend durchgeführt wird. Daten, die aus Gründen der Systemperformanz in Zwischenspeichern (Caches) gehalten werden, müssen stets mit dem Originaldatenbestand konsistent sein. Deshalb ist sicherzustellen, dass der verändernde Datenzugriff immer über den Cache erfolgt.

5.8.6 Zeit Eine globale (Uhr-)Zeit erlaubt die Vergleichbarkeit und Ordnung von Ereignissen und ist die Voraussetzung für eine „Gleichzeitigkeit“ von Ereignissen. Insbesondere in Portalen zur Miteinanderarbeit spielt die Zeit eine wichtige fachliche Rolle. Dieser Portaltyp besitzt in der Regel eine Terminverwaltungskomponente. Die elektronische Einladung zu einem Meeting mit automatischer Prüfung der Teilnehmerverfügbarkeit, das Bestätigen des Termins oder die Verschiebung auf einen anderen Zeitpunkt und schließlich die Erinnerung an den Termin zu einem festgelegten Zeitpunkt – all das kann nur gelingen, wenn alle Benutzer des Systems dieselbe Zeit haben – oder automatisch zwischen einer einheitlichen Systemzeit und den lokalen Zeiten „übersetzt“ wird. Die Zeit spielt zudem eine wesentliche Rolle bei der Nachvollziehbarkeit von protokollierten Ereignissen. Soll – z.B. im Fehlerfall – ein Ereignis rekonstruiert werden, so kann die Analyse der verschiedenen Protokolle (Log-Dateien) wichtige Anhaltspunkte liefern. Kennt man das Datum und die Uhrzeit, zu der ein Fehler aufgetreten ist, dann ist man in der Lage, die Suche auf einen entsprechenden Bereich der Log-Dateien zu beschränken – vorausgesetzt, die Uhrzeit ist Bestandteil des Protokolls, und der Server verwendet

144

■ ■ ■

5 Technische Anforderungen

dieselbe Zeit. Letzteres lässt sich über die Nutzung eines zentralen Zeitdienstes sicherstellen. Damit ergibt sich für die verteilten Systeme der folgende Anforderungskatalog: ■

Gemeinsame Nutzung von Ressourcen,

■

Transparenz,

■

Performanz,

■

Adressierbarkeit (Naming),

■

Konsistenz,

■

einheitliche Zeit.

Anforderungskatalog: Verteilbarkeit

5.9 Modularer Entwurf: Entkoppelte Komponenten Die bisher formulierten fachlichen und technischen Anforderungen legen den Schluss nahe, dass Unternehmensportale durch eine modulare Architektur den an sie gestellten (und stetig wachsenden) Anforderungen am besten gerecht werden können. Diese Architektur aus lose gekoppelten, miteinander kommunizierenden und verteilten Komponenten, in Kombination mit der Verwendung offener Schnittstellen und Standards, garantiert ein hohes Maß an Flexibilität und Skalierbarkeit. Üblicherweise folgen modulare Architekturen dem objektorientierten Paradigma. Bei der engen Kopplung können Komponenten auf alle Attribute und Funktionen der anderen Komponenten zugreifen (Abb. 5.7). Ändert sich der Name oder die Semantik eines Attributes bzw. einer Funktion, so müssen alle darauf zugreifenden Komponenten angepasst werden.

5.9 Modularer Entwurf: Entkoppelte Komponenten

■ ■ ■

145

Abb. 5.7 Enge Kopplung von Komponenten

Komponente A Attribute A

A

Attribute A

A

Funktionen F

F

Komponente B

A

A

A

Funktionen F

F

F

F

F

Lose gekoppelte Komponenten kommunizieren nur über Funktionsschnittstellen (Abb. 5.8). Der direkte Zugriff auf Attribute ist nicht möglich – er muss über eine Schnittstellenfunktion gekapselt werden. Komponente A

F

Definierte Minimalfunktionalität

Standardverhalten

146

■ ■ ■

Attribute

A

F

F

F

F

F

F

F

A

Schnittstelle

A

Funktionen

Stabile Schnittstellen

Komponente B

Attribute

Schnittstelle

Abb. 5.8 Lose Kopplung von Komponenten

A

Funktionen

F

F

Die Stabilität dieser Schnittstellen vorausgesetzt, sind lose gekoppelte Komponenten immun gegen Änderungen der inneren Struktur der von ihnen referenzierten Komponenten. Das garantiert die weitgehende Unabhängigkeit der Komponenten – vorausgesetzt, diese Komponenten erfüllen noch zwei weitere Anforderungen: Die Komponenten müssen einen minimalen fachlichen Funktionsumfang garantieren. Dieses Mindestmaß an Funktionalität steht anderen Komponenten über die genannten stabilen Schnittstellen zur Verfügung. Damit lässt sich eine Komponente durch eine andere, gleichwertige austauschen, die über denselben minimalen Funktionsumfang verfügt. Die über die Schnittstelle verfügbaren Funktionen müssen zudem ein verlässliches und definiertes Verhalten im Rahmen von technisch unterstützten Geschäftsprozessen anbieten. Dieses definierte und dokumentierte Standardverhalten vereinfacht die Integration der Komponenten in einen Workflow.

5 Technische Anforderungen

Diese objektorientierte „Architektur der entkoppelten Komponenten“ ist keine revolutionäre Idee. Tatsächlich gibt sie den aktuellen Stand der Technik in der modernen Softwareentwicklung wieder. Neben den bereits vorgestellten Anforderungen an ein Unternehmensportal gibt es Konzepte, Metamodelle, Frameworks und Technologien, welche die Verwendung der Architektur entkoppelter Komponenten vereinfachen und damit deren Verbreitung begünstigen. Die Konzepte standardisieren die technischen Strukturen und Prozesse, die in verteilten objektorientierten Architekturen zum Einsatz kommen, wie z.B. Interprozesskommunikation, den Lebenszyklus von Objekten, die plattformunabhängige Repräsentation von Objektzuständen oder Mechanismen zur Persistenz von Objekten. Die Metamodelle und Frameworks wiederum bieten eine Implementierung dieser standardisierten Strukturen und Prozesse an, so dass sich der Entwickler auf die Implementierung der fachlichen Funktionalität konzentrieren kann. Die Enterprise JavaBeans-Technologie (vgl. Ihns et al. 2004) ist ein aktuelles Beispiel für ein solches Konzept bzw. Framework.

Protagonisten der Idee entkoppelter Komponenten

Damit lässt sich für den modularen Entwurf die folgende Anforderung formulieren:

Anforderungskatalog: Modularer Entwurf

■

Definition einer Architektur der entkoppelten Komponenten und Unterstützung dieser Architektur durch ■

standardisierte Konzepte,

■

Metamodelle und Frameworks,

■

Standard-Basistechnologien,

■

Komponenten, die über einheitliche Schnittstellen, eine definierte Minimalfunktionalität und ein Standardverhalten verfügen.

5.10 Standardtechnologien und offene Schnittstellen Da wir dem Thema „Standards“ ein eigenes Kapitel widmen (vgl. Kapitel 7), wollen wir an dieser Stelle nur kurz auf die Vorteile von Standardtechnologien eingehen. Wenn wir an dieser Stelle von Standards reden, dann meinen wir offene, frei zugängliche Standards, deren Nutzung in der Regel nicht mit Lizenzkosten verbunden ist.

5.10 Standardtechnologien und offene Schnittstellen

■ ■ ■

147

Anforderungskatalog: Standardtechnologien und offene Schnittstellen

148

■ ■ ■

Viele Standards der Informationstechnologie entstehen aus der Praxis heraus – mit dem Ziel, eine einheitliche Lösung für ein allgegenwärtiges Problem zu etablieren. Dieser Praxisbezug bedingt die tatsächliche Einsetzbarkeit der Standards – im Gegensatz zu manch einer Richtlinie, die am Schreibtisch ersonnen wurde und in der Praxis kaum Nutzen bringt. Sicherlich muss man sich im Laufe des Standardisierungsprozesses auf einen (oft kleinen) gemeinsamen Nenner einigen, der nicht alle Facetten des behandelten Problems abdeckt. Dennoch hat die Einigung auf einen Standard und die Softwareentwicklung nach Standards wichtige Vorteile. So können Programme, die bestimmte Systemkomponenten (z.B. Datenbanksysteme) über einen Standard ansprechen (beispielsweise JDBC – Java Database Connectivity), die entsprechende Systemkomponente ohne Programmieraufwand gegen eine ebenfalls standardkonforme Komponente auswechseln. Das steigert die Systemunabhängigkeit und Portabilität des Softwaresystems. Ein weiterer, nicht zu unterschätzender Vorteil betrifft die Qualifizierung von Softwareentwicklern. Anstatt für jedes Softwareprojekt neue, proprietäre Schnittstellen lernen zu müssen, können die Entwickler ihr erworbenes Wissen über die Standards in vielen Projekten wiederverwenden. Das schafft Sicherheit, steigert die Produktivität und schließlich auch die Qualität der entwickelten Software. Viele – wenn nicht gar die meisten – Standards in der Informationstechnologie betreffen die Schnittstellen von technischen Systemen und Softwaresystemen. Sind die Standards offen, so sind es in der Folge auch die standardkonformen Schnittstellen. Offene Schnittstellen wiederum erlauben den sicheren und gezielten externen Zugriff auf ein technisches System bzw. Softwaresystem. Das erleichtert die Integration (oder macht diese unter Umständen erst möglich) und schafft somit die Grundlage für Unternehmensportale, die ihren Nutzen aus der Integration der Unternehmensanwendungen ziehen. Zusammenfassend kann man fordern: ■

Nutzung offener, frei verfügbarer Standards,

■

Definition offener Schnittstellen.

5 Technische Anforderungen

5.11 Trennung von Content und Design Als das World Wide Web (WWW) noch in den Kinderschuhen steckte, waren die Gestaltungsmöglichkeiten damaliger Webseiten beschränkt. Die Auszeichnungssprache HTML (Hypertext Markup Language) war erst rudimentär ausgebildet und bot wenig mehr als die Darstellung von strukturierten und leidlich formatierten Texten und Grafiken. Die Webseiten waren statische HTML-Seiten. War deren Inhalt anzupassen, so musste die entsprechende HTML-Seite editiert werden. Dieser manuelle Anpassungsaufwand war in vielen Fällen ein Hindernis – insbesondere bei Webseiten, die sich regelmäßig änderten. Webseiten mit interaktiven Elementen, z.B. einer Suchfunktion, waren überhaupt nicht realisierbar. Das änderte sich mit der Einführung der Common Gateway Interface (CGI). Diese Spezifikation beschreibt, wie Informationen von einem Webbrowser an ein Serverprogramm übermittelt werden. Dieses Serverprogramm, oft als CGI-Programm bezeichnet, verarbeitet die Informationen und sendet eine dynamisch erzeugte Webseite über den Webserver zurück an den Browser. Die CGITechnologie bedeutete einen Durchbruch in zweierlei Hinsicht: Zum einen konnten Webseiten dynamisch erzeugt werden und ihre Inhalte z.B. aus einer Datenbank beziehen. Zum anderen war (nach der Einführung entsprechender HTML-Sprachelemente) die Programmierung von Webformularen möglich, ohne die der Internet-Boom mit Sicherheit nicht stattgefunden hätte. Das World Wide Web hatte sich vom Informationskanal zum interaktiven Medium gewandelt. Die Zahl der Online-Angebote stieg sprunghaft an, und immer neue Nutzungsmöglichkeiten erschlossen sich. Aus Webseiten wurden Webanwendungen. Zu dieser Zeit entstand auch die Portalidee. Ein Problem gab es aber noch: CGIProgramme waren sowohl für das Sammeln und Aufbereiten der Informationen als auch für das Erzeugen der Webseiten zuständig. Während der technische Aspekt der Informationsverarbeitung sinnvollerweise von Programmierern bearbeitet wird, kümmern sich Designer und Grafiker um den gestalterischen Aspekt des Weblayouts. Wie aber sollten sie ihr Schaffen zu einem CGI-Programm verweben? Es fehlte eine Trennung der informations- bzw. contentbezogenen Tätigkeiten von den gestalterischen Tätigkeiten, die auch im Programmcode der Webanwendungen sichtbar ist. Für dieses Problem wurde eine Vielzahl von Lösungen entwickelt, angefangen bei speziellen Web-Programmiersystemen (z.B. WebObjects, ColdFusion oder Vignette) bis hin zu Programmiersprachen für die Programmie-

5.11 Trennung von Content und Design

Die Historie des Web Design

CGI

Programmierumgebungen für dynamische Webseiten

■ ■ ■

149

rung von Webanwendungen (z.B. PHP oder JavaServer Pages). Gemeinsames Merkmal dieser Lösungen ist die Möglichkeit, Webseiten in HTML zu entwerfen und in den HTML-Code die dynamischen Anteile in Form von Programmieranweisungen einzuflechten. Um das Layout aller Webseiten eines Webauftritts (z.B. eines Unternehmens) einheitlich zu halten, besteht ferner die Möglichkeit, das Grundgerüst der Seiten als HTML-Schablone (Template) zu speichern und in die Webseiten einzubinden (Abb. 5.9). Aus diesen Technologien entwickelten sich schließlich die ContentManagement-Systeme. Abb. 5.9 Dynamisches Generieren einer Webseite

Daten Schablone

HTML

Code

D

Datenquelle

Webseitengenerator

HTML

Webbrowser

ModelViewController

Auch in der Softwareentwicklung hat sich die strikte Trennung der Daten von der Präsentation als vorteilhaft erwiesen. Ein wichtiges Erbe der objektorientierten Programmierung in Smalltalk ist das Model-View-Controller-Paradigma (MVC). Es sieht für die Konstruktion interaktiver Softwaresysteme drei Komponententypen mit genau definierten Verantwortungsbereichen vor: ■

150

■ ■ ■

Model: Ein Modell eines strukturierten Datentyps, bestehend aus Eigenschaften und Operationen. Eine Teilmenge der Eigenschaften und Operationen bildet die externe Schnittstelle des Modells.

5 Technische Anforderungen

■

View: Eine Sicht auf das Modell. Diese Komponente beschränkt sich auf die Präsentation des Modells. Zu einem Modell kann es mehrere verschiedene Views geben.

■

Controller: Das Verbindungsglied zwischen Model und View sorgt für die Darstellung des View. Werden (über entsprechende Interaktionselemente des View) Aktionen angestoßen, die zu Änderungen des Modells führen, so validiert der Controller diese Aktionen und modifiziert gegebenenfalls das Modell.

Auch bei den Entwurfsmustern (Design Patterns), die in der Konstruktion objektorientierter Softwaresysteme heute eine wesentliche strukturelle Rolle spielen, finden sich Entsprechungen zum ModelView-Controller-Paradigma. Die grundlegenden Beziehungen des Paradigmas werden von den Entwurfsmustern Observer, Composite und Strategy beschrieben (vgl. Gamma et al. 1995). Wir fassen die Forderungen an das Web Design wie folgt zusammen: ■

Dynamische Generierung von Portalseiten mit wechselnden Inhalten anstelle von statischer HTML-Programmierung,

■

Trennung der Daten und Inhalte (Content) von deren Präsentation in der Portalseite,

■

zentrale Verwaltung des Layouts in Form von Schablonen (Templates),

■

im Falle interaktiver Webanwendungen: Modularisierung der Anwendung nach dem Model-View-Controller-Paradigma (MVC).

Anforderungskatalog: Trennung von Content und Design

5.12 Performanz Mit dem Begriff Performanz bezeichnen wir die gemittelte Reaktionszeit einer Interaktion mit dem Portal. Die Interaktion beginnt, wenn der Portalbenutzer eine Aktion auslöst (z.B. durch das Drücken einer Schaltfläche). Sie endet, wenn die als Reaktion auf die Aktion ermittelten Inhalte auf der Portalseite zur Anzeige gebracht werden (vgl. Abb. 5.10).

5.12 Performanz

■ ■ ■

151

Abb. 5.10 Prozesskette nach Auslösen einer Benutzeraktion

Webbrowser

Portal

Die Performanz eines Unternehmensportals ist eine für den Portalbenutzer erlebbare Größe und deshalb entsprechend hoch zu gewichten. Oft ist es jedoch schwierig, die Zeit zu messen, die ein Informationselement für den Weg durch die Komponenten des Unternehmensportalsystems benötigt. Zu komplex sind diese Systeme, und zu viele unterschiedliche Komponenten müssen berücksichtigt werden. Zudem bieten nicht alle Komponenten die Möglichkeit, ihre Performanz zu messen. Eine Messung der Performanz wird aber genau dann wichtig, wenn die Performanz des Unternehmensportals nicht den Erwartungen entspricht. Eine erste Version des Intranets bei Wein&Dein basierte auf einem Content-Management-System. Das Projekt wurde unter hohem Zeitdruck fertiggestellt – zu hoch wäre der interne Prestigeverlust der Verantwortlichen im Falle einer Verzögerung gewesen. Nach der Einführung des Intranet stellte man fest, dass viele Benutzer die Zeit bis zum vollständigen Aufbau der Webseite als zu lange empfanden. Viel größere Kritik gab es jedoch für die Suchfunktion, die oft erst nach Minuten ein Ergebnis zurücklieferte. Je mehr Dokumente über das Intranet zugreifbar wurden, desto länger dauerte die Suche. Eine groß angelegte softwaretechnische Analyse begann, bis schließlich – nach mehreren Tagen – ein Fehler in der Konfiguration der Lastverteilungskomponente (Load Balancer) als Ursache für den langsamen Seitenaufbau erkannt wurde. Es dauerte hingegen Wochen, bis man in einer Enterprise JavaBeans (EJB)-Komponente eine SQLDatenbankanfrage entdeckte, die so formuliert war, dass sie vom Datenbanksystem nicht optimiert werden konnte. Dies, in Kombina-

152

■ ■ ■

5 Technische Anforderungen

tion mit einem unglücklich definierten Datenbank-Index, führte zu den beobachteten langen Suchzeiten. Wie das Beispiel zeigt, ist die Nachvollziehbarkeit der gesamten informationstechnischen Prozesskette, von der Anfrage (Request) bis hin zur Antwort vom System in Form einer Präsentation des Ergebnisses (Response), eine notwendige Voraussetzung für das Beherrschen des Faktors Performanz. Neben der Nachvollziehbarkeit sollte auch die Möglichkeit der Messung von Durchlaufzeiten für einzelne Prozesse gegeben sein. Diese Notwendigkeit haben auch einige Anbieter von Portalsystemen und Drittanbieter entdeckt. Sie bieten Lösungen für die Überwachung (Monitoring) der Portalsysteme an, die teilweise sogar einen Blick bis hinein in die Backend-Systeme gestatten. Je sauberer die Softwarearchitektur der selbsterstellten und zugekauften Komponenten eines Unternehmensportals ist, desto einfacher lässt sich das Portalsystem hinsichtlich seiner Performanz optimieren. Auch eine Erweiterung um Mess- und Überwachungskonzepte ist realisierbar – sofern noch nicht vorhanden. Das Systemverhalten sollte so früh wie möglich unter realistischen Bedingungen getestet werden. Die Erfahrung zeigt aber, dass den Entwicklern nur selten die Zeit und die technischen Möglichkeiten gegeben werden, um entsprechende Tests zu planen und durchzuführen. Nicht selten begnügt man sich mit einem einfachen Funktionstest. Hier testet der Entwickler das spezifikationsgemäße Verhalten des Systems, indem er – strukturiert und wiederholbar oder zufällig – die geforderten Funktionen ausführt und deren Ergebnisse überprüft. Tut er dies allein oder in einer kleinen Gruppe von Entwicklern, so bleiben zwei wesentliche Aspekte ungetestet: Das Verhalten unter Last, wenn einer oder mehrere Benutzer sehr schnell sehr viele Anfragen an das Portalsystem stellen. Und das Verhalten im Mehrbenutzerbetrieb, wenn Benutzer parallel mit dem Portalsystem arbeiten. Diese Tests müssen unter realistischen Bedingungen stattfinden, d.h. der Inhalt der Tests muss sich an den fachlichen Anforderungen der Portalbenutzer orientieren, und die Hardware- und Softwarekonstellation muss dem Produktivsystem so ähnlich wie möglich sein. Ein System, das plötzlich mit einer großen Anzahl an Benutzeranfragen konfrontiert wird, kann unter Umständen in seiner Funktionsfähigkeit eingeschränkt werden oder gar komplett ausfallen. Ein bekanntes Beispiel sind die Denial-of-Service-Attacken. Hier werden in schneller Folge sehr viele HTTP-Anfragen an einen Webserver gesandt – so lange, bis dieser unter der Last der Anfragen förmlich zusammenbricht. Es muss aber nicht immer ein böser Wille hin-

5.12 Performanz

Informationstechnische Prozesskette

Softwarequalität

Lasttest und Mehrbenutzertest

Verhalten unter Last

■ ■ ■

153

Verhalten im Mehrbenutzerbetrieb

Anforderungskatalog: Performanz

154

■ ■ ■

ter einem solchen Datenaufkommen stecken. So müssen z.B. die Webserver von Nachrichtenagenturen oder Großereignissen (z.B. die Olympischen Spiele) eine Unmenge gewollter Anfragen bearbeiten. Nun wird ein Unternehmensportal in der Regel deutlich geringere Zugriffsraten haben als z.B. die Online-Enzyklopädie Wikipedia (www.wikipedia.org). Nichtsdestotrotz muss die zu erwartende Last für das Portal geschätzt und bei der Planung der Hardware- und Softwareinfrastruktur berücksichtigt werden. Es kommt häufig vor, dass ein technisches System beim Test eines einzelnen Entwicklers einwandfrei funktioniert, das parallele Arbeiten mehrerer Benutzer jedoch mit Fehlern quittiert. Der Grund liegt in den meisten Fällen in jenen Teilen der Software, die den Zugriff auf gemeinsam genutzte Ressourcen regeln sollen, dies aber nicht zuverlässig tun. So haben mehrere Benutzer oder Prozesse gleichzeitig Zugriff auf eine Ressource, oder sie warten beide auf den exklusiven Zugriff und blockieren sich gegenseitig. Ein Mehrbenutzertest kann solche Fehler rechtzeitig aufdecken. Um den Faktor Performanz beherrschbar zu machen, müssen die folgenden Gegebenheiten erfüllt sein: ■

Nachvollziehbarkeit der gesamten informationstechnischen Prozesskette (Request + Response),

■

Messbarkeit der Durchlaufzeiten einzelner Prozesse,

■

eine Softwarearchitektur, die mit steigenden Anforderungen skaliert und die Messung und Überwachung der Performanz ermöglicht,

■

eine skalierbare technische Infrastruktur,

■

Durchführung von Lasttests,

■

Durchführung von Mehrbenutzertests.

5 Technische Anforderungen

6 Referenzarchitektur

Basierend auf den in den vorigen Kapiteln ermittelten fachlichen und technischen Anforderungen wollen wir in diesem Kapitel eine Referenzarchitektur für Unternehmensportale vorstellen. Der Name deutet es bereits an: Eine solche Architektur kann als Orientierung dienen, wird aber so gut wie nie ohne Anpassungen auf die konkreten Anforderungen übertragen werden können. Deshalb geben wir zu Beginn des Kapitels Hinweise zum Umgang mit einer Referenzarchitektur, bevor wir die fachliche und die technische Sicht auf eine solche idealisierte Portalarchitektur entwickeln.

Kurz gefasst

6.1 Gebrauchsanleitung für eine Referenzarchitektur Eine Softwarearchitektur beschreibt nach Balzert (1996) die Struktur des Softwaresystems durch Systemkomponenten und ihre Beziehungen untereinander. Eine Beziehung beschreibt jede mögliche Verbindung zwischen zwei Komponenten, dynamisch oder statisch. Entsprechend ist eine Referenzarchitektur die idealisierte Darstellung der Komponenten eines Softwaresystems sowie der Beziehungen und der Aufgabenteilung zwischen diesen Komponenten. Abhängig von der jeweiligen Betrachtungsweise lassen sich technische und fachliche Darstellungen finden. Auch wenn beide Modelle im Folgenden getrennt voneinander beschrieben werden, ergibt sich doch erst aus der Kombination der beiden Sichtweisen eine ganzheitliche Betrachtung des Portals. Erst dieser Blick auf das Ganze schafft das Bewusstsein für die Komponentenvielfalt und das Beziehungsgeflecht eines Portalsystems. Die Betrachtung der Architektur eines Unternehmensportals aus der Vogelperspektive ermöglicht den Überblick und die notwendige Orientierung in diesem komplexen Thema.

6.1 Gebrauchsanleitung für eine Referenzarchitektur

Fachliche und technische Darstellung

■ ■ ■

155

Idealtypisches Modell

156

■ ■ ■

Die beiden Betrachtungsweisen der Portalarchitektur leiten sich aus den in den Kapiteln 4 und 5 beschriebenen fachlichen und technischen Anforderungen ab. Dabei abstrahiert das Architekturmodell von den konkreten Anforderungen und gruppiert gewünschte Funktionen und Services zu Architekturkomponenten. Folglich wirken sich einige technische Anforderungen auch auf das fachliche Architekturmodell aus und umgekehrt. So haben z.B. die technischen Möglichkeiten der Datenaufbereitung in Abhängigkeit von den Ausgabemedien (z.B. Webbrowser) Auswirkungen auf die fachliche Gestaltung der Benutzungsoberfläche. Die Betrachtung der jeweils anderen Architektursicht und der entsprechenden Anforderungen hilft, die Vollständigkeit der identifizierten Komponenten zu überprüfen. So setzt beispielsweise die fachliche Anforderung durchgängiger Geschäftsprozesse das Vorhandensein und die Integration eines EAI-Servers sowie eines Workflowsystems voraus. Nur in seltenen Fällen wird ein Architekturmodell in seiner Gesamtheit den tatsächlichen Gegebenheiten eines Portalprojekts bzw. Portalprodukts entsprechen. In der Regel muss das Modell an die unternehmensspezifischen Anforderungen und Rahmenbedingungen des Portalprojekts angepasst werden. Das idealtypische Architekturmodell dient hier als Leitfaden und Instrument der Qualitätssicherung bei der Konzeption und der Implementierung des Portals. Die Abbildung des Modells auf die tatsächlichen Gegebenheiten ist nicht trivial. Dies liegt zum einen an der Tatsache, dass Portalprodukte in der Regel nicht alle Komponenten des Architekturmodells vollständig beinhalten. Zum anderen werden von verschiedenen Produktherstellern unterschiedliche Begrifflichkeiten verwendet. Erschwerend kommt hinzu, dass das Produktmarketing durch eine freie absatzorientierte Interpretation der fachlichen und technischen Begriffe Erwartungen weckt, die das Produkt schlussendlich nicht erfüllt. Folglich ist es erst durch eine tiefgehende Analyse der Produktfunktionalitäten einerseits und der Anforderungen des Unternehmens andererseits möglich festzustellen, welche Produkte die Anforderungen des Unternehmens tatsächlich abdecken. Die Themen Anforderungsanalyse und Softwareauswahl werden im Kapitel 8 ausführlich dargestellt. Kapitel 9 und 10 beleuchten die wichtigsten Aspekte der Einführung, des Betriebs und der Weiterentwicklung eines Unternehmensportals.

6 Referenzarchitektur

6.2 Fachliches Architekturmodell Ausgehend von den im Kapitel 4 formulierten fachlichen Anforderungen wird in diesem Kapitel ein fachliches Referenzmodell für Unternehmensportale vorgestellt. Nach einer kurzen Beschreibung der einzelnen Komponenten und deren Beziehungen als Erläuterung der Abbildung 6.1 werden die Komponenten in den folgenden Abschnitten ausführlich beschrieben. Abb. 6.1 Fachliches Architekturmodell

Frontends

F

F

F

Präsentation Sicherheit

Portlet

Portlet

Portalapplikationen

Prozessunterstützung Prozessautomatisierung

Integration

Programmierwerkzeuge

Portlet

Knowledge Management

Portlet

Personalisierung

Business Intelligence

Templates

PORTAL

Programmierschnittstelle

F

Benutzerverwaltung

F

Metadaten

Datenquellen, Anwendungssysteme, Diensteanbieter

Ein Unternehmensportal ist funktional angesiedelt zwischen den Unternehmensdaten, Anwendungen und Diensten (Backend) und der Präsentationsebene (Frontend). Es abstrahiert von den konkreten Datenquellen und stellt über die Integrationskomponente eine virtuelle zentrale Informationsquelle dar. Die Beziehungen zwischen Informationen können direkt in den Datenmodellen der Backend-Systeme implementiert sein. Sollen jedoch mehrere technische Datenquellen miteinander in Verbindung gebracht werden, so werden die Informationen zur Beschreibung dieser Beziehungen in einem zentralen Metadatenserver abgelegt.

6.2 Fachliches Architekturmodell

Integration

Metadaten

■ ■ ■

157

Prozessunterstützung und Prozessautomatisierung

Präsentation Portalapplikationen

Business Intelligence Knowledge Management

Benutzerverwaltung

Sicherheit

158

■ ■ ■

Die Kombination einer virtuellen zentralen Informationsquelle mit der Möglichkeit eines externen Zugriffs auf BackendFunktionen erlaubt, Geschäftsprozesse technisch durchgängig zu unterstützen. In der Komponente zur Prozessunterstützung und Prozessautomatisierung (Prozesskomponente) werden Geschäftsprozesse allein nach fachlichen und rollenbezogenen Anforderungen definiert, ohne Rücksicht auf Systemgrenzen nehmen zu müssen. Die Präsentation ist gemäß dem Model-View-Controller (MVC)Paradigma strikt von der Funktionalität und den Daten getrennt. Portalapplikationen (Portlets) stellen die Funktionalität des Portals zur Verfügung. Portlets sind modular aufgebaut und lassen sich zu kontext- und rollenbezogenen Benutzerschnittstellen komponieren. Sowohl die Inhalte als auch die Darstellungsform der Portlets lassen sich personalisieren. Über die Portlets stellt das Portal dem Benutzer neben fachlichen Anwendungen auch grundlegende Funktionen, wie z.B. einen systemübergreifenden Suchmechanismus, zur Verfügung. In der darüberliegenden Präsentationsschicht wird die Portalseite in Abhängigkeit vom Ausgabemedium formatiert. Das Grundgerüst einer Portalseite wird über Formatvorlagen (Templates) definiert. Diese legen das grafische Layout sowie die Anordnung der Navigation, der Portlets und anderer Gestaltungs- und Interaktionselemente fest. Business Intelligence unterstützt den Benutzer bei der strategischen Analyse und Aufbereitung der Informationen. Die Knowledge-Management-Komponente ordnet die vielen unstrukturiert vorliegenden Unternehmensdaten. Diese machen ca. 85% des Gesamtdatenbestands aus. Durch Klassifikation der Daten und intelligente Suchfunktionen kann die Informationsrecherche beschleunigt und die Qualität der Rechercheergebnisse erhöht werden. In der Benutzerverwaltung werden jedem Portalbenutzer entsprechend seiner funktionalen Einordnung im Unternehmen eine oder mehrere Rollen zugewiesen. Über diese Rollen wird der Zugriff auf die Informationen und Portalapplikationen gesteuert. Zur Realisierung eines Single Sign-On sind die Authentifizierungsdaten (Benutzernamen und Passwörter) für den Benutzerzugriff auf das Portal und die Backend-Systeme zentral in der Benutzerverwaltung abgelegt. Hat sich der Benutzer einmal am Portal angemeldet, so muss er sich dank der Single-Sign-On-Funktionalität nicht mehr einzeln bei den ERP- und Legacy-Systemen sowie den anderen Unternehmensapplikationen und Datenbanken anmelden. Als Klammer um die Portalkomponenten sorgt die Sicherheitskomponente für den beim Umgang mit sensiblen Unternehmensdaten notwendigen Schutz. Sie ist verantwortlich für die sicherheitstechnische Infrastruktur eines Single Sign-On. Daneben übernimmt

6 Referenzarchitektur

sie die Aufgabe der Übertragung und Verschlüsselung von Daten und regelt und kontrolliert den Zugriff von außen. Eine Programmierschnittstelle (Application Programming Interface, API) ermöglicht die Erweiterung des Portalsystems um eigene Portlets, Funktionen oder Komponenten. Viele Portalprodukte bringen Programmierwerkzeuge mit, die den Entwickler bei der Arbeit mit der Portal-API unterstützen.

Programmierschnittstelle Programmierwerkzeuge

Die in diesem Abschnitt kurz vorgestellten fachlichen Komponenten werden in den folgenden Abschnitten ausführlich betrachtet.

6.2.1 Integrationskomponente Die Heterogenität der Unternehmensinformationen stellt seit jeher die größte Herausforderung für das softwaregestützte Informationsmanagement dar. Informationen unterscheiden sich hinsichtlich ihres Gehalts, ihrer Relevanz im Kontext verschiedener Geschäftsprozesse, ihres Strukturierungsgrades und nicht zuletzt ihrer Quelle, d.h. dem technischen Ort der Datenspeicherung. Das Ziel des Informationsmanagements ist es, die im gegebenen Kontext relevanten Informationen zu ermitteln und dem Benutzer zur Verfügung zu stellen, so dass dieser auf die manuelle Datenselektion verzichten und sich auf die Analyse der Daten konzentrieren kann. Die Informationen müssen aus fachlichen Bedürfnissen heraus miteinander in Beziehung gesetzt werden können, ohne dass technische Systemgrenzen im Weg stehen. Die Integrationskomponente übernimmt in diesem Kontext folgende Aufgaben: ■

Integration von Daten durch die Schaffung einer virtuellen, integrierten Informationsquelle zur Erschließung des gesamten Informationsspektrums des Unternehmens.

■

Integration von Anwendungen und Diensten mittels eines zentralen Zugriffs auf die Backend-Systeme.

■

Implementierung eines zentralen Datenkatalogs für alle angeschlossenen Backend-Systeme. Wesentlicher Bestandteil dieses Katalogs ist eine Art „fachliches Wörterbuch“, das der Übersetzung zwischen den fachlichen Terminologien der verschiedenen Systeme dient und eine Daten- und Prozessintegration über Systemgrenzen hinweg erst möglich macht.

6.2 Fachliches Architekturmodell

Aufgaben der Integrationskomponente

■ ■ ■

159

Alle Komponenten des Portalsystems verwenden die Integrationskomponente als einheitliche Zugriffsschicht, die fachlich definierte Schnittstellen zu den technischen Backend-Systemen anbietet. Wie eine solche Integrationskomponente im Detail aussehen kann, wurde bereits in den Abschnitten 2.2 und 5.1 ausführlich beschrieben.

6.2.2 Prozesskomponente Die Prozesskomponente einer Portalarchitektur dient der Automatisierung und dem Management von Geschäftsprozessen über Abteilungs- und Funktionsgrenzen hinweg. Dabei liegt der Fokus neben der Automatisierung von Einzelfunktionen auf der elektronischen Steuerung gesamter Prozessketten und der Integration von Daten, Dokumenten und Applikationen zur Ausführung der Arbeitsschritte. Über die Prozesskomponente lässt sich festlegen, wie der Arbeitsund Datenfluss für einen bestimmten Geschäftsprozess sein soll, welche Rollen bzw. Funktionsträger an den einzelnen Arbeitsschritten beteiligt sind und wie weitere Arbeitsschritte in Abhängigkeit von den Ergebnissen vorhergehender Schritte aussehen sollen. Die Prozesskomponente koordiniert Benutzer und Anwendungen, um definierte Ziele zu festgelegten Schlussterminen zu erreichen, und stellt die erforderlichen Daten bereit. Die technisch unterstützten Aktivitäten eines Geschäftsprozesses werden als Workflow bezeichnet. Dementsprechend wird die Prozesskomponente auch als Workflow-Management-System (WfMS) bezeichnet. Durch Workflows lassen sich vor allem Prozesse effektiv steuern, ■

die nach fest definierten Regeln ablaufen.

■

die aus mehreren Arbeitsschritten bestehen.

■

die sich häufig wiederholen.

■

an denen mehrere Personen beteiligt sind.

■

die vordefinierte Ziele besitzen.

Geschäftsprozesse, die keinem dieser Kriterien entsprechen, lassen sich in den meisten Fällen kaum durch eine technische Workflowsteuerung sinnvoll unterstützen. Diese Prozesse sind entweder in ihren Abläufen zu wenig strukturiert, als dass eine techni-

160

■ ■ ■

6 Referenzarchitektur

sche Modellierung und regelbasierte Steuerung des Prozesses möglich wäre, oder es ergeben sich aus einer technischen Unterstützung keine (betriebs-)wirtschaftlichen Verbesserungspotenziale für diese Prozesse. Die Modellierung der zugrundeliegenden Geschäftsprozesse geschieht in den meisten Workflowsystemen grafisch mit einem speziellen Workfloweditor. Aus den grafischen Prozessdiagrammen erstellt das System dann entsprechende Steuerungsbeschreibungen für die einzelnen Arbeitsschritte. Zur Steuerung der Geschäftsprozesse werden Informationen über den Zustand und die Historie des aktuell ablaufenden Workflows herangezogen. Daneben bedient sich die Prozesskomponente der Benutzer- und Rechteverwaltung des Portals, um für bestimmte Arbeitsschritte die verantwortlichen Benutzer entsprechend ihrer Rolle zu finden und diesen die richtigen Dokumente entsprechend ihrer Berechtigungen anzuzeigen. Durch die automatische Steuerung gesamter Prozessketten wird die Verarbeitung eines Geschäftsvorfalls transparent, da jederzeit der Status einzelner Arbeitsschritte abgerufen werden kann und der gesamte Ablauf protokolliert wird. Müller (2004) unterscheidet hier zwischen den Prozesskontrolldaten und den prozessrelevanten Daten. Während erstere als Grundlage für die oben dargestellte Steuerung des Workflows dienen, handelt es sich bei den prozessrelevanten Daten um die für den Geschäftsprozess notwendigen fachlichen Daten. Um Schwachstellen und Verbesserungsmöglichkeiten frühzeitig aufzeigen zu können, bringen die meisten Workflowsysteme eine Simulationskomponente mit. Unter Berücksichtigung der für den einzelnen Workflow angenommenen Daten, wie z.B. Bearbeitungszeiten einzelner Aktivitäten, wird dieser in der Simulationskomponente durchgespielt. Dabei lässt sich das Verhalten des modellierten Prozesses unter verschiedenen Bedingungen überprüfen. Anhand eines grafischen Ablaufprotokolls lassen sich die Schwachstellen des Workflows identifizieren. Außerdem lässt sich die Simulationskomponente als Instrument zur Qualitätskontrolle der produktiven Workflows einsetzen. Dazu werden die Laufzeitdaten der Workflows in die Simulationskomponente importiert, um sie dort auswerten zu lassen. Dies ermöglicht Rückschlüsse auf Engpässe und Abweichungen vom Soll-Ablauf des Workflows. Mit der Business Process Execution Language (BPEL) liegt eine Metasprache für die Beschreibung von Geschäftsprozessen bzw. Workflows vor, die als anwendungsneutrale Beschreibungsform und zum Austausch zwischen verschiedenen GeschäftsprozessModellierungssystemen verwendet werden kann (vgl. Andrews et al. 2003, Raepple 2004).

6.2 Fachliches Architekturmodell

Modellierung von Geschäftsprozessen

Steuerung von Geschäftsprozessen

Simulation von Geschäftsprozessen

Standardisierte Beschreibung von Prozessen und Workflows

■ ■ ■

161

Im Rahmen eines Unternehmensportals nimmt die Workflowkomponente die Rolle eines Regisseurs ein, der die im Folgenden beschriebenen Portalapplikationen und eventuell externe Systeme und Dienste zum Zusammenspiel innerhalb eines Geschäftsprozesses bewegt. In Kooperation mit der Knowledge-ManagementKomponente sorgt sie zudem dafür, dass aktuelles Wissen kontextrelevant in den Geschäftsvorfällen zur Verfügung gestellt wird. Wein&Dein bietet einen batteriebetriebenen Korkenzieher an. Dieser wird ohne Batterien geliefert – eine Information, die über die Knowledge Management-Komponente mit der Artikelbeschreibung verknüpft worden ist. Bestellt ein Kunde telefonisch diesen Korkenzieher, so wird die Workflowkomponente bei der Anforderung der Produktdaten auch diese Zusatzinformation beziehen und der Bestellapplikation mitteilen. Der Sachbearbeiter ist nun in der Lage, dem Kunden das Bestellen eines Batteriesatzes zu empfehlen. Die Workflowkomponente stellt im Zusammenspiel mit dem Knowledge Management solche Zusatzinformationen allen betroffenen Geschäftsprozessen zur Verfügung, so auch der OnlineBestellung und dem Beschwerdemanagement.

6.2.3 Portalapplikationen Die Trennung der Verantwortlichkeiten von Applikations- und Präsentationsschicht in unserer Referenzarchitektur orientiert sich an der Portlet-Spezifikation (vgl. Abdelnur u. Hepper 2003, Koschek 2004). Der Vorteil dieses Standards liegt in der weitgehenden Herstellerunabhängigkeit, die es einem Unternehmen erlaubt, das Portalsystem zu wechseln, ohne alle eigenentwickelten Portalapplikationen neu entwickeln zu müssen. Dazu sollten jedoch neben den Portalapplikationen auch alle anderen Module und deren Schnittstellen bestimmten Standards folgen. Einige der für Unternehmensportale relevanten Standards werden im Kapitel 7 ausführlich beschrieben. Die unternehmensspezifischen Fachfunktionen werden als Portalapplikationen modelliert. Daneben stellen weitere Portalapplikationen die Basisfunktionen des Portals zur Verfügung, wie beispielsweise eine Such- oder Hilfefunktion und das Portal-Login. Es gibt verschiedene Wege, um zur „richtigen“ Portalapplikation zu gelangen:

162

■ ■ ■

6 Referenzarchitektur

■

Die Portalapplikation gehört zum Lieferumfang des Portalsystems.

■

Die Portalapplikation wird vom Hersteller des Portalsystems bezogen.

■

Die Portalapplikation wird von einem Drittanbieter bezogen. Hier ist darauf zu achten, dass die Applikation kompatibel zum Portalsystem ist. Idealerweise unterstützen beide – Portalsystem und -applikation – den Portlet-Standard (vgl. Abschnitt 7.5.1).

■

Die Portalapplikation wird selber entwickelt oder bei einem ITDienstleister in Auftrag gegeben. Dafür stehen entsprechende Entwicklungsumgebungen zur Verfügung (vgl. Abschnitt 6.2.9).

Als „Portlets“ werden die Applikationen eines Portals bezeichnet. Es handelt sich dabei um webbasierte Präsentationskomponenten für den Zugriff auf Informationssysteme. Portlets verarbeiten die vom Portalbenutzer gestellten Anfragen, indem sie die benötigten Portalkomponenten (beispielsweise Knowledge Management oder Business Intelligence) sowie die Daten und Anwendungen der BackendSysteme (indirekt über die Integrationskomponente) bemühen. Als Ergebnis liefern sie dynamisch generierte Inhalte, genannt „Fragmente“. Diese Fragmente werden vom Portalserver zur Portalseite aggregiert. Der Portalserver bettet das vom Portlet gelieferte Fragment in ein Portlet-Fenster ein. Dieses hat üblicherweise einen Rahmen und eine Titelleiste mit Schaltflächen für die Portlet-Modi, den Fensterzustand und zum Schließen des Portlets. Die Fenster werden von der Präsentationskomponente auf der Portalseite positioniert.

Bezug von Portalapplikationen

Portlets

6.2.4 Präsentationskomponente Ein Unternehmensportal ist nur so gut wie die Qualität seiner Daten und die vorhandenen Möglichkeiten der selektiven Präsentation dieser Daten: kontext- und rollenbezogen, personalisiert sowie nach Relevanzkriterien gefiltert. Dies setzt ein hohes Maß an Flexibilität bei der Präsentation der Informationen voraus. Die grafische Benutzungsoberfläche besteht üblicherweise aus einer Navigations- und einer Inhaltskomponente. Letztere setzt sich aus den Fragmenten der Portalapplikationen zusammen. Die Anordnung dieser Fragmente auf der Portalseite und die Verwaltung der Grundstruktur der Portalseiten (Templates) wird entweder vom Por-

6.2 Fachliches Architekturmodell

■ ■ ■

163

Rollenbasierte und personalisierte Darstellung

Interaktion zwischen Portalapplikationen

talserver selbst oder einem integrierten Content-ManagementSystem erstellt. Die Rollen der Portalbenutzer legen deren Zugriffsrechte für die über das Portal verfügbaren Informationen und Geschäftsprozesse fest. Sie bestimmen auch, welche Portalapplikationen auf der Portalseite verwendet werden können bzw. müssen. Der Benutzer des Unternehmensportals kann nun aus der über seine Rolle definierten Teilmenge an Portalapplikationen jene auswählen, mit denen er persönlich seine Arbeit am effektivsten gestalten kann. Ebenso kann er für Portalapplikationen, die unterschiedliche Formen der Darstellung unterstützen, eine Darstellung wählen, die seinen persönlichen Vorlieben entspricht. Die Präsentationskomponente selektiert die Portalapplikationen entsprechend der Rolle und den individuellen Einstellungen des Benutzers und ordnet diese auf der Portalseite an. Sie formatiert die Oberfläche der Portalapplikation nach den Benutzervorgaben für das jeweilige Ausgabemedium. Die Präsentationskomponente speichert außerdem alle vom Benutzer getätigten persönlichen Einstellungen. Dadurch kann dem Benutzer beim nächsten Anmelden seine persönliche Portalsicht präsentiert werden. Die Präsentationskomponente verwaltet darüber hinaus die Informationen, welche Portalapplikationen sich für Zustandsänderungen anderer Portalapplikationen interessieren, und benachrichtigt diese gegebenenfalls. Ein Unternehmensportal bietet eine Portalapplikation zur Anzeige der Wetterverhältnisse in allen Großstädten und Regionen weltweit. Eine andere Portalapplikation erlaubt die Darstellung der Uhrzeit für ausgewählte Zeitzonen. Die beiden Applikationen sind miteinander verbunden, so dass ein Wechsel der Stadt in der Wetter-Applikation automatisch die Zeitzone in der Weltzeit-Applikation anpasst.

Standards für die Entwicklung von Präsentationskomponenten

164

■ ■ ■

Die Entwicklung von Präsentationskomponenten sollte bestimmten Standards genügen. Diese legen die grafische Darstellung, die Anbindung an die Datenquellen, die Interaktion mit dem Benutzer sowie die Trennung von Darstellung, Steuerung und Datenhaltung (Model-View-Controller-Paradigma) fest. Der Vorteil solcher Standards ist eine weitgehende Herstellerunabhängigkeit, die es einem Unternehmen erlaubt, das Portalsystem zu wechseln, ohne alle eigenentwickelten Komponenten neu entwickeln zu müssen. Dazu müssen aber neben den Präsentationskomponenten auch alle anderen Module und deren Schnittstellen bestimmten Standards folgen. Solche Standards werden später bei den technischen Lösungsansätzen für eine komponentenbasierte Architektur beschrieben.

6 Referenzarchitektur

Für die Standardisierung von Präsentationskomponenten haben sich führende Hersteller von Portalsystemen zu einer Expertengruppe zusammengefunden, die im Rahmen des Java Community Process eine Java Portlet Specification erarbeitet (vgl. Abdelnur u. Hepper 2003, Koschek 2004). Der Portlet-Standard wird im Abschnitt 7.5.1 genauer beschrieben.

6.2.5 Business Intelligence Unter dem Begriff Business Intelligence (BI) werden Systeme verstanden, die dem Controlling und der strategischen Entscheidungsfindung sowie zur Überwachung und Optimierung der Geschäftsprozesse im Unternehmen dienen. Dazu verdichten sie die Unternehmensdaten zu definierten Kennzahlen. Diese werden entweder in Echtzeit berechnet (Online Analytical Processing, OLAP) oder in Form von Reports zur Verfügung gestellt (Query & Reporting). Oft gehören Standard-Analysen, Reportings und Kennzahlen zum Lieferumfang von Business-Intelligence-Komponenten, die als Grundlage für die Definition eigener strategischer Analysen dienen können. Im allgemeinen Sprachgebrauch werden die Begriffe „Business Intelligence“ und „Data Warehouse“ oft synonym verwendet. Data Warehouses stellen als Datencontainer die technische Basis. Sie werden aus den datenliefernden Systemen über den sogenannten ETL-Prozess (Extract, Transform and Load) befüllt. Die BusinessIntelligence-Systeme hingegen beinhalten die analytische Funktionalität. Diese setzt auf den im Data Warehouse definierten Strukturen auf und bedient sich dessen Datenbestands. Damit trägt auch Business Intelligence zu einer einheitlichen und fokussierten Sicht auf die Unternehmensdaten bei. In diesem Bereich findet derzeit ein Wandel der Sichtweise statt. Früher standen die Daten im Vordergrund, die in zeitaufwendigen Prozessen aus den Geschäftsanwendungen in ein Data Warehouse extrahiert und dort ausgewertet wurden. Diese Daten waren aber zum Zeitpunkt der Nutzung unter Umständen bereits veraltet. Aus diesem Grund entwickelte sich die Forderung nach einem OnlineZugriff auf die operativen Daten, verbunden mit Analyse- und Reporting-Funktionen. Dank besserer Integrationsmöglichkeiten können Business-Intelligence-Systeme heute in Echtzeit auf die operativen Daten zugreifen und aus diesen aktuelle, systemübergreifende Kennzahlen aufbereiten. Dazu nutzen diese die von der Integrations-

6.2 Fachliches Architekturmodell

Data Warehouses

■ ■ ■

165

komponente gebildete einheitliche und systemübergreifende Zugriffsschicht. In Portalen werden die Funktionen der Business-IntelligenceKomponente von den Portalapplikationen im Rahmen strategischer Geschäftsprozesse genutzt.

6.2.6 Knowledge Management

Erschließung von Wissen

Informationsgewinnung und Informationsklassifizierung

166

■ ■ ■

Systeme im Bereich des Knowledge Management stellen sich der Herausforderung, den mit ca. 85% Anteil am Gesamtbestand der Unternehmensinformationen sehr großen Bereich der unstrukturierten Informationen zu organisieren und strukturiert verfügbar zu machen. Unstrukturierte Daten sind, wie im Abschnitt 1.3.1 beschrieben, Daten, die nicht nach einem festgelegten Schema strukturiert sind. Sie sind z.B. in Dokumentenmanagement-Systemen, Dateisystemen, Mailservern oder Intranets zu finden. Knowledge Management umfasst viele Aspekte des Umgangs mit Informationen, von denen die wesentlichen im Folgenden kurz beschrieben werden. Die Verwaltung und der Zugriff auf Dokumente der gesamten Informationsbasis eines Unternehmens ist sicherlich eine wesentliche Aufgabe des Knowledge Managements. Dies bildet aber lediglich die Grundlage für das eigentliche Ziel, die Erschließung des impliziten und expliziten Unternehmenswissens. Der Wissensumfang ist auch bei kleineren und mittleren Unternehmen immens groß. Im Rahmen der Geschäftsprozesse eines Unternehmens finden immer nur definierte Ausschnitte aus diesem Wissensspeicher Verwendung. Das Knowledge Management hilft mittels kontextabhängiger Informationsrecherche und -präsentation bei der geforderten Konzentration auf das Wesentliche. Dazu bietet es den Portalapplikationen „intelligente“ Relevanzfilter und Recherchewerkzeuge an, die benutzer- und kontextspezifisch angepasst werden können. Das gefilterte Ergebnis einer solchen unternehmensweiten Suche liefert nicht selten Informationen, von deren Existenz der Suchende gar nicht wusste. Ein Benutzer des Portals, der auf diese Weise aus dem Umgang mit diesem System einen Nutzen für sich und seine tägliche Arbeit zieht, wird auch gewillt sein, das in seinem Kopf gespeicherte (implizite) Wissen in explizites, allgemein zugängliches und konservierbares Wissen zu überführen. Viele Datenbestände eines Unternehmens sind als natürlichsprachliche Texte gespeichert. Im Rahmen des Knowledge Managements dient die Informationsextraktion dazu, bestimmte ge-

6 Referenzarchitektur

wünschte Informationen in diesen unstrukturierten Texten zu identifizieren und in eine strukturierte Form zu überführen. Diese Anreicherung um strukturierte (Meta-)Informationen erlaubt formale Anfragen und eine weitere maschinelle Verarbeitung des Textdatenbestands. Die angereicherten natürlichsprachlichen Texte können nun miteinander in Beziehung gesetzt werden. Da eine Vielzahl an Beziehungen denkbar ist, muss man sich hier auf die tatsächlich benötigten bzw. relevanten Klassen von Relationen beschränken. Topic Maps sind eine Möglichkeit, um solche Beziehungsgeflechte zu notieren (vgl. Abschnitt 7.8.3). Bei allen Strukturierungsbemühungen darf nicht vergessen werden, dass nur ein unternehmensweites Vokabular, definiert in einem Schlagwortkatalog und vorgegebenen Taxonomien, eine einheitliche Qualität der Rechercheergebnisse gewährleistet. Bei der Qualitätssicherung der Recherche spielen weitere Eigenschaften der Informationsobjekte, wie z.B. Versionsnummer oder Gültigkeitsdauer, eine Rolle. Die Knowledge-Management-Komponente beschleunigt die Informationsrecherche der Portalbenutzer und erhöht die Qualität der Suchresultate. Darüber hinaus ermöglicht sie aber auch ein kontinuierliches Lernen und Weiterentwickeln des Unternehmens aus den eigenen Erfahrungen. Über das Knowledge Management werden in Zusammenarbeit mit der Workflowkomponente Informationen aus früheren Geschäftsvorfällen den Bearbeitern eines Geschäftsprozesses zur Verfügung gestellt und können zwischen Geschäftsprozessen ausgetauscht werden. Neben dem Erschließen, der Verwaltung und der Recherche des Unternehmenswissens kann auch der Aspekt der Miteinanderarbeit vom Knowledge Management profitieren, indem es den aktiven Wissensaustausch in Diskussionsforen oder virtuellen Räumen unterstützt.

Lern- und Weiterentwicklungsprozess

Teamarbeitsumgebungen

6.2.7 Benutzerverwaltung Die Benutzer des Unternehmensportals nehmen bei ihrer Arbeit mit dem Portal bestimmte Rollen ein. Diese Rollen werden mit den dazugehörigen Benutzerkonten in der Benutzerverwaltung gepflegt. Jedem Benutzerkonto können dabei eine oder mehrere der definierten Rollen zugewiesen werden.

6.2 Fachliches Architekturmodell

■ ■ ■

167

Authentifizierung

Zugriffssteuerung

Die geschützten Bereiche eines Portals sind in der Regel nur jenen Benutzern zugänglich, die über ein autorisiertes Benutzerkonto verfügen und sich am Portal angemeldet haben. Für die Authentifizierung werden die Kontoinformationen herangezogen. Die Rollen beschreiben in der Regel fachliche Aufgaben. Sie legen Zugriffsrechte für die über das Portal verfügbaren Informationen und Geschäftsprozesse fest. Dadurch wird die gesamte Informationsund Prozesslandschaft auf eine definierte (rollenbezogene bzw. personalisierte) Teilmenge eingeschränkt. Innerhalb der einzelnen Portalapplikationen legen die mit den Rollen verknüpften Rechte fest, welche Aufgaben (z.B. Löschen, Modifizieren, Lesen) der Benutzer übernehmen darf (vgl. Abschnitte 4.3 und 4.6). In der Praxis hat sich das LDAP-Protokoll (Lightweight Directory Access Protocol) als Standard für die Verwaltung verzeichnisartiger Daten, wie es Benutzerinformationen sind, etabliert (vgl. Wahl et al. 1997; eine anschauliche Einführung bietet Haberer 2003). Auch wenn das LDAP-Protokoll weder die Inhalte des Verzeichnisses noch die Art und Weise der Diensterbringung definiert, so werden die meisten LDAP-Server für die Benutzerverwaltung eingesetzt. Der Vorteil von LDAP in dieser Hinsicht ist dessen Flexibilität bei der Strukturdefinition. So können z.B. für jeden Benutzer die Authentifizierungsinformationen für verschiedene Systeme gespeichert werden, was die Implementierung einer Single-Sign-On-Lösung deutlich vereinfacht.

6.2.8 Sicherheitsmechanismen

Sichere Kommunikation

168

■ ■ ■

Unternehmensportale arbeiten mit sensiblen und schützenswerten Daten. Sie müssen deshalb mit entsprechenden Sicherheitsmechanismen ausgestattet werden, um den unberechtigten Zugang zu den Daten zu verhindern. Dies ist umso schwieriger (aber auch umso wichtiger), je öffentlicher der Zugang zum Portal ist. Die höchsten Sicherheitsanforderungen stellt demnach ein über das Internet erreichbares Unternehmensportal. Nicht nur der Zugang zu den Anwendungssystemen ist zu sichern, sondern auch die Datenübertragungswege, um das unbefugte Ausspähen und Manipulieren der Daten zu verhindern. Das Thema Sicherheit umschließt wie eine Klammer alle Komponenten unserer Referenzarchitektur. Die konkreten Sicherheitsanforderungen wurden bereits im Abschnitt 4.5 ausführlich behandelt und sollen an dieser Stelle lediglich kurz wiederholt werden:

6 Referenzarchitektur

■

Authentifizierung: Überprüfung der Identität eines Benutzers, üblicherweise durch Angabe eines Benutzernamens und eines Passworts.

■

Autorisierung: Überprüfung, ob ein Benutzer die Berechtigung für eine bestimmte Aufgabe hat.

■

Single Sign-On: Erlaubt nach der Authentifizierung gegenüber dem Portal den Zugriff auf alle über das Portal zugreifbaren Systeme, ohne sich bei diesen erneut authentifizieren zu müssen.

■

Sichere Kommunikation: Verschlüsselung, Authentifizierung oder Firewall-Infrastrukturen zum Schutz des Datentransfers vor dem Zugriff Unbefugter.

Sicherheitsanforderungen

6.2.9 Programmierschnittstelle und -werkzeuge Wie im Abschnitt 6.2.3 beschrieben, gibt es verschiedene Wege, um zur „richtigen“ Portalapplikation zu gelangen. Einer dieser Wege ist die Eigenentwicklung. Dies schließt die Auftragsentwicklung bei einem IT-Dienstleister mit ein. Für den Fall der Eigenentwicklung muss das Portalsystem eine Programmierschnittstelle anbieten. Je nach Funktionsumfang der Schnittstelle lassen sich folgende Erweiterungen des Portalsystems realisieren: ■

Entwicklung eigener Portalapplikationen. Diese können in das Portal integriert werden und nutzen die Standardfunktionen des Portals.

■

Erweiterung der Komponenten des Portalsystems entsprechend den eigenen Anforderungen. Beispiel: Erweiterung der Datenbasis für die Suchfunktion des Portals um eigene, unternehmensspezifische Datenquellen.

■

Erweiterung der Standardprozesse des Portalsystems um eigene Algorithmen, die an definierten Eingriffspunkten (Hooks) vom Portalsystem aufgerufen werden. Beispiel: Die Ergänzung des Single-Sign-On-Mechanismus um ein unternehmenseigenes Authentifizierungssystem.

■

(Lesender) Zugriff auf die internen Prozesse des Portalsystems, um Fehler in eigenen Portalapplikationen zu analysieren oder die Performanz durch gezielte Engpasssuche zu optimieren.

6.2 Fachliches Architekturmodell

Erweiterung eines Portalsystems

■ ■ ■

169

■

Entwicklung eigener Portalkomponenten, die zum Portalsystem kompatibel sind und eng mit diesem zusammenarbeiten. Beispiel: Eine Komponente zur Erstellung eines Performanzprofils. Sie bedient sich der oben genannten Zugriffsfunktionen auf die portalinternen Prozesse und wertet diese aus.

Um den Softwareentwicklern den Umgang mit der Programmierschnittstelle zu erleichtern, sollte diese nicht nur ausreichend dokumentiert und mit Beispielprogrammen illustriert sein, sondern sich auch flexibel mit unterschiedlichen Programmierwerkzeugen kombinieren lassen. Da die Softwareentwicklung heute überwiegend durch integrierte Softwareentwicklungsumgebungen (Integrated Development Environment, IDE) unterstützt wird, sollten die Werkzeuge zur Portalentwicklung (z.B. zur Workflowdefinition) in die gängigen IDEs integrierbar sein. Dazu zählen aus heutiger Sicht neben dem frei verfügbaren Eclipse (www.eclipse.org) auch kommerzielle Lösungen wie z.B. Borland JBuilder oder – für die Windows/.NET-Welt – Microsoft Visual Studio. Solche integrierbaren Komponenten werden als Plugins bezeichnet. Der Integrationsgrad in solche IDEs reicht von einfachen Validierungswerkzeugen für die portalspezifischen Konfigurationsdateien über automatische Helfer (Wizards) für die Erstellung von Beschreibungen oder Programmcode bis hin zu portalzentrierten Sichten innerhalb der IDE, bei Eclipse „Perspektiven“ genannt. Idealerweise werden aber auch Softwareentwickler unterstützt, die ohne IDE programmieren, z.B. durch eine Schnittstelle zu Apache Ant (ant.apache.org), einem Werkzeug zur Automatisierung des Build-Prozesses.

6.3 Technische Referenzarchitektur Der folgende Abschnitt vermittelt die grundlegenden Aufgaben jener technischen Systemkomponenten, die üblicherweise in der Architektur von Portalsystemen zum Einsatz kommen. Da die fachliche und die technische Architektur einander bedingen, kann nicht das eine ohne das andere dargestellt werden. Die Komponenten der technischen Referenzarchitektur werden zunächst kurz vorgestellt. Da dieses Buch kein Kompendium der ITSystemtechnik ist, fällt auch die anschließende Beschreibung der einzelnen Komponenten vergleichsweise knapp aus. An gegebener Stelle wird auf entsprechende Fachliteratur verwiesen.

170

■ ■ ■

6 Referenzarchitektur

Firewall

Administration / Monitoring

Web-Applikationsserver

Portalserver

Web Services

Abb. 6.2 Technisches Architekturmodell

Webserver Lastverteilung Proxy Cache Portlet

Portlet

Portlet

Portlet-Container

Metadatenserver

Transaktionsmanager

Middleware / EAI

Datenquellen, Anwendungssysteme, Diensteanbieter

Technisch ist das Unternehmensportal zwischen den Datenquellen, Anwendungssystemen und Diensteanbietern (Backend) und der Firewall-Infrastruktur als Sicherheitsbarriere vor der Benutzungsoberfläche (Frontend) angesiedelt. Die Middleware bzw. Enterprise Application Integration (EAI) trennt die Funktionalität von der Datenhaltung. Sie abstrahiert von den konkreten Backend-Systemen, indem sie funktionsbezogene Dienste definiert und zur Verfügung stellt. Die technische Ausgestaltung der Schnittstellen zwischen den beteiligten Systemen wird vor den anderen Komponenten verborgen. Das Portal stellt nicht nur sondierende Anfragen an die BackendSysteme, sondern verändert auch Daten, z.B. im Rahmen von Workflow-Prozessen. Dabei muss die Integrität der Daten sichergestellt werden – insbesondere dann, wenn Veränderungen in mehreren Backend-Systemen vorgenommen werden oder parallele Zugriffe auf eine Datenquelle erfolgen. Zu diesem Zweck laufen solche Aktivitäten im Rahmen einer Transaktion ab. Bei den in Portalen häufig vorkommenden verteilten Transaktionen ist es nicht sinnvoll, die Transaktion aus einer der beteiligten Applikationen heraus zu starten. Deshalb wird diese Aufgabe an den Transaktionsmanager delegiert.

6.3 Technische Referenzarchitektur

Middleware EAI

Transaktionsmanager

■ ■ ■

171

Metadatenserver

Portalserver und PortletContainer

WebApplikationsserver

Firewall

Web Services

Administration und Monitoring

172

■ ■ ■

Die Definition der fachlichen Beziehungen zwischen Daten verschiedener Systeme wird üblicherweise in einer eigenen Komponente gespeichert, dem sogenannten Metadatenserver. Dieser sorgt z.B. bei jeder Ausführung einer kombinierten Integration (vgl. Abschnitt 1.6.2) für die Lieferung der benötigten Metainformationen über die von den kombinierten Systemen bezogenen Daten. Er ist ferner für die Protokollierung von erfolgreichen wie fehlerhaften Datenzugriffen verantwortlich. Der Portalserver bildet die Kernkomponente des Unternehmensportals. Seine Aufgabe ist die Aggregation von Inhalten verschiedener Datenquellen in einer Webseite. Ein Portal bietet üblicherweise eine Personalisierung der Inhaltsauswahl und -präsentation sowie die automatische Authentifizierung bei den angeschlossenen Informationssystemen (Single Sign-On). Der Portlet-Container stellt die Ablaufumgebung für die Portalapplikationen (Portlets) dar. Der Portalserver und meistens auch der Portlet-Container sind ihrerseits Komponenten eines Web-Applikationsservers. Dieser stellt die Ablaufumgebung für Webapplikationen dar, von denen eine das Portal selbst ist. Daneben übernimmt der Web-Applikationsserver technische Aufgaben. Um das Portalsystem hochverfügbar und performant auch unter Hochlastbedingungen zu machen, nimmt er eine lastabhängige Verteilung der Client-Anfragen auf die verschiedenen zur Verfügung stehenden Server vor (Load Balancing). Daneben fungiert er als Proxy Cache, um die Zugriffe auf Inhalte zu beschleunigen. Um das Unternehmensportal und die darin transportierten sensiblen Unternehmensdaten vor dem Zugriff Unbefugter zu schützen, müssen alle Komponenten hohe Sicherheitsanforderungen erfüllen. Eine Firewall-Infrastruktur stellt den Schutz vor Angriffen aus dem Internet sicher. Web Services stellen die standardisierte Schnittstelle zu ortsunabhängig und plattformübergreifend verfügbaren Diensten dar. Basierend auf dem Web-Service-Standard sind weitere Standards für spezialisierte Dienste entstanden, z.B. für verteilte Geschäftsprozesse oder Portalapplikationen (Portlets). Schließlich müssen all diese technischen Systeme verwaltet und überwacht werden. Dazu stehen verschiedene Administrationswerkzeuge zur Verfügung – im ungünstigsten Fall eines je Komponente. Für einen sicheren Betrieb des Portals ist eine Überwachungskomponente (Monitor) unabdingbar.

6 Referenzarchitektur

6.3.1 Middleware/EAI Middleware-Komponenten sind in der Regel Standardlösungen, die über Adapter in der Lage sind, beliebige Systeme in einer heterogenen IT-Landschaft miteinander zu verbinden. Sie sind das technische Pendant zu der im Abschnitt 6.2.1 vorgestellten Integrationskomponente. Durch die zentrale Steuerung der Kommunikation zwischen diesen Systemen entfällt die Notwendigkeit der Realisierung aufwendiger und schwer wartbarer Punkt-zu-Punkt-Verbindungen. Die Kommunikationspfade bilden stattdessen eine um die Middleware angeordnete Sternarchitektur (vgl. Abschnitt 5.1.1). Mit Enterprise Application Integration (EAI)-Systemen werden die Middleware-Konzepte fortentwickelt und eine Integrationsarchitektur für die Applikationslandschaft in Unternehmen aufgebaut. Dabei stellt eine solche Integrationsarchitektur eine ideale Ausgangsbasis zum Aufbau von Unternehmensportalen dar (vgl. Abschnitt 2.2). Andere Portalkomponenten nutzen die Middleware/ EAI-Komponente als zentrale Schnittstelle für den Zugriff auf die Backend-Systeme. Die Möglichkeiten von EAI-Systemen und deren Abgrenzung zu Portalsystemen ist Inhalt des Kapitels 2. Der Zugriff auf Backend-Systeme erfolgt über spezielle Adapter. Diese sind spezifisch für jedes angeschlossene System, implementieren aber gegenüber der Integrationskomponente eine einheitliche Schnittstelle. Dank dieser Standardisierung lassen sich zusätzliche Systeme einfacher anbinden – die Möglichkeit eines externen Zugriffs auf das System vorausgesetzt. In der Praxis bringen Portal- und EAI-Systeme Adapter für gängige Unternehmensanwendungen wie z.B. ERP-Systeme mit. Viele dieser Adapter sind konfigurierbar oder erweiterbar und können somit an die Bedürfnisse des Unternehmens angepasst werden. Reichen die Anpassungsmöglichkeiten für den Informations- und Funktionsbedarf des Unternehmensportals nicht aus, so können weitere Adapter selbst entwickelt bzw. von Drittanbietern erworben werden.

6.3 Technische Referenzarchitektur

Integrationsarchitektur

Adapter

■ ■ ■

173

6.3.2 Transaktionsmanager Die Aufgabe eines Transaktionsmanagers beschreibt Gray (1993) wie folgt: “The idea of distributed systems without transaction management is like a society without contract law. One does not necessarily want the laws, but one does need a way to resolve matters when disputes occur.”

Transaktionsmanager bündeln einzelne Aktionen innerhalb einer gemeinsamen Transaktionsklammer. Nur wenn alle Transaktionen in allen beteiligten Systemen abgeschlossen werden können, wird die übergreifende Transaktion endgültig gemacht (Commit). Schlägt auch nur in einem System die Transaktion fehl, dann werden alle Transaktionen rückgängig gemacht (Rollback). Der Transaktionsmanager erreicht damit einen konsistenten Datenzustand auch über Systemgrenzen hinweg. An den in einem Portalsystem ablaufenden Prozessen sind in der Regel mehrere Komponenten des Portals beteiligt: Die Workflowkomponente orchestriert die Portalapplikationen und die fachlichen Portalkomponenten (Business Intelligence und Knowledge Management) im Rahmen von Geschäftsprozessen. Um Aktivitäten mit mehreren beteiligten Komponenten koordinieren zu können, werden verteilte Transaktionen verwendet. Der Transaktionsmanager garantiert bei der Ausführung einer verteilten Transaktion die vier Haupteigenschaften Ununterbrechbarkeit, Konsistenz, Isolation und Dauerhaftigkeit, die unter dem Akronym ACID bekannt sind.

174

■ ■ ■

■

Atomicity (Ununterbrechbarkeit): Die Garantie, dass eine Transaktion immer als Ganzes ausgeführt wird.

■

Consistency (Konsistenzerhaltung): Die Garantie, dass sich ein System, welches sich vor Ausführung der Transaktion in einem konsistenten Zustand befunden hat, auch nach deren Ausführung einen konsistenten Zustand besitzt. Während der Transaktionsausführung kann der Zustand durchaus inkonsistent sein.

■

Isolation (Isolierter Ablauf): Die Garantie, dass eine Transaktion nicht durch parallel ablaufende Transaktionen beeinträchtigt wird, die konkurrierend auf die von der Transaktion genutzten Daten und Systeme zugreifen. Von den konkurrierenden Transaktionen gleichzeitig bewirkte Daten- und Zustandsänderungen

6 Referenzarchitektur

bleiben den jeweils anderen Transaktionen bis zum Transaktionsabschluss verborgen. ■

Durability (Dauerhaftigkeit der Ergebnisse): Die Garantie, dass die Ergebnisse einer erfolgreich abgeschlossenen Transaktion permanent sind.

Transaktionsmanager – auch als Transaction Processing Monitor (TP-Monitor) bezeichnet – sind in jeder Softwarearchitektur für verteilte Systeme anzutreffen. So gehört z.B. bei J2EE (Java 2 Enterprise Edition)-kompatiblen Applikationsservern ein TP-Monitor zum Standardumfang (vgl. z.B. Ihns et al. 2004). Bei Monson-Haefel (2001) finden Sie eine allgemeine Einführung in verteilte Objektarchitekturen, Komponentenmodelle und Transaktionsmonitore.

TP-Monitor

6.3.3 Metadatenserver Der Metadatenserver dient der Integrationskomponente als zentraler Datenspeicher zur Ablage und Administration von Metadaten. Auf Basis eines relationalen oder XML-basierten DatenbankManagementsystems werden all jene Informationen gespeichert, die für die Definition von Beziehungen zwischen Informationseinheiten verschiedener Datenquellen und für die terminologiebasierte Integration benötigt werden (vgl. Abschnitt 4.2). Damit bildet der Metadatenserver die Informationsbasis für die Datenintegration und ermöglicht die Definition datenquellenübergreifender Prozesse, sowohl für fachliche Geschäftsprozesse als auch für technische Funktionen wie z.B. die Informationsrecherche. Außer der Verwaltung von Metadaten zu einzelnen Informationselementen kommt dem Metadatenserver die Aufgabe zu, die verschiedenen systemspezifischen Begriffswelten aufeinander abzubilden. Er dient quasi als „Wörterbuch“ für die Kommunikation zwischen den beteiligten System- und Domänenwelten. Diese Taxonomien werden auch von der Knowledge-Management- und der Business-Intelligence-Komponente genutzt. Durch die Protokollierung der Zugriffe auf den Metadatenserver lassen sich Rückschlüsse auf die Informationsbedürfnisse der Portalbenutzer ziehen. Solche Informationen sind wichtig, um das Portal kontinuierlich am Bedarf seiner Benutzer auszurichten.

6.3 Technische Referenzarchitektur

■ ■ ■

175

6.3.4 Portalserver und Portlet-Container Technisch gesehen ist ein Portal eine Anwendung, die auf einem Web-Applikationsserver läuft. Der Portalserver ist meistens das zentrale Servlet dieser Applikation. Der Portlet-Container stellt die Ablaufumgebung für Portlets dar. Er bestimmt deren Lebenszyklus und wickelt die Kommunikation mit dem Portal ab. Die Portalapplikationen (Portlets) implementieren die fachliche Funktionalität des Portals. Sie sind eingebunden in Prozessketten, welche die Geschäftsprozesse des Unternehmens komplett oder in Teilen abbilden. Diese Definition der wesentlichen Komponenten eines Portals und deren Zusammenspiel lehnt sich an die Portlet-Spezifikation an, die im Abschnitt 7.5.1 ausführlich vorgestellt wird.

6.3.5 Web-Applikationsserver Der Begriff des (Web-)Applikationsservers wird von verschiedenen Herstellern solcher Systeme unterschiedlich belegt. Es gibt jedoch einige Merkmale, die typisch, wenn auch nicht zwingend notwendig sind:

176

■ ■ ■

■

Definition und Ausführung von Geschäftslogik und Geschäftsprozessen.

■

Unterstützung der gängigen Komponentenmodelle, wie z.B. CORBA oder J2EE. Zunehmend setzt sich das J2EE-Modell durch. Entsprechende Applikationsserver sind demnach auch Container für Enterprise JavaBeans (EJB, vgl. Ihns et al. 2004).

■

Integration von Backend-Systemen (Datenbanken, ERP- und Legacy-Systeme).

■

Integration eines Transaktionsmonitors für verteilte DatenbankTransaktionen.

■

Bereitstellung einer Modulschnittstelle für den Webserver, um dynamische Inhalte zu generieren und zu liefern.

■

Spezielle Anwendungsfunktionen (Shop-Funktionalität, Content Management, Katalogsystem).

6 Referenzarchitektur

Zudem beinhalten Web-Applikationsserver einen eigenen Webserver und übernehmen technische Funktionen wie Lastverteilung und Proxy Cache-Funktionalität. Einige der genannten Eigenschaften von Web-Applikationsservern haben wir zuvor als technische Portalkomponente definiert, z.B. Transaktionsmonitore und EAI-Systeme. Da aber nicht alle Web-Applikationsserver diese Funktionen anbieten, beschränken wir unsere Definition dieser Komponente auf drei wesentliche Aufgaben: Webserver, Lastverteilung und Caching. Tatsächlich gibt es Web-Applikationsserver, die zusätzlich Funktionen zum Transaktionsmanagement und zur Integration zur Verfügung stellen. Damit decken diese die entsprechenden Komponenten unserer Referenzarchitektur (in diesem Fall „Transaktionsmanager“ und „Middleware / EAI“) ab. Der Webserver stellt die direkte Schnittstelle zu den Webbrowsern dar. Webserver und Browser kommunizieren über das Standardprotokoll HTTP (Hypertext Transfer Protocol). Es regelt die Anfragen an den Webserver und dessen Antwortmöglichkeiten sowie das Verhalten im Fehlerfall. Der bekannteste Webserver mit dem größten Verbreitungsgrad ist der Apache HTTP Server. Dessen Konfiguration und Administration ist bei Aulds (2002) beschrieben. Dort finden Sie auch eine ausführliche Beschreibung der Funktionsweise von Webservern. Webbrowser sind die mit Abstand am häufigsten genutzte ClientKomponente der Portalarchitektur. Auch andere (mobile) Endgeräte, wie z.B. Mobiltelefone oder Personal Digital Assistants (PDA), bedienen sich Technologien zur Informationspräsentation, die denen der Webbrowser ähneln (z.B. WAP) oder mit diesen identisch sind. Oft werden auch Inhalte, die für solche Endgeräte bestimmt sind, von einem Webserver ausgeliefert. Die auf einem Webserver abgelegten Dokumente sind in einer Verzeichnisstruktur organisiert, ähnlich den Dateisystemen gängiger Betriebssysteme. Die Clients (d.h. die Browser) können jedes Dokument in dieser Verzeichnisstruktur über eine Pfadangabe (URL – Uniform Resource Locator) adressieren und vom Webserver anfordern. Die über den Webserver verfügbaren Dokumente verwenden hauptsächlich das HTML-Format (Hypertext Markup Language). Der Inhalt dieser Dokumente ist statisch, d.h. sie werden genau so ausgeliefert, wie sie auf dem Webserver gespeichert sind. Komplexe webbasierte Anwendungen wie z.B. Unternehmensportale benötigen dynamisch generierbare Dokumente. Fordert ein Benutzer Informationen an, so werden diese vom Portalsystem aus den entsprechenden Datenquellen bezogen und an die verantwortliche Portalapplikation übergeben, die diese Daten unter Berücksich-

6.3 Technische Referenzarchitektur

Webserver

■ ■ ■

177

Lastverteilung

Proxy Cache

178

■ ■ ■

tigung benutzerspezifischer Einstellungen zur Anzeige bringt. Diese Anforderung kann ein Webserver nicht erfüllen. Allerdings lassen sich in die gängigen Webserver Zusatzmodule für solche speziellen Aufgaben integrieren. Ein Modul zum Generieren dynamischer Dokumente analysiert beispielsweise die Anfrage des Webbrowsers und sammelt die entsprechenden Informationen. Portalapplikationen erzeugen aus diesen Informationen Teildokumente (Fragmente). Die Fragmente werden anschließend vom Portalserver zu einem Dokument zusammengefügt, welches dann dem Webserver übergeben wird. Dieser liefert es an den Client aus (vgl. Abschnitt 5.11). Neben den eben beschriebenen Modulen werden für gängige Webserver weitere Zusatzmodule angeboten, die ein breites Spektrum an Funktionen abdecken. Zu den wichtigsten Funktionen gehören Authentifizierung, benutzerbezogene Zugriffsbeschränkungen, sichere Übertragungsprotokolle (z.B. HTTPS), URL-Mapping und Protokollierung (Logging). Die Komponente zur Lastverteilung (Load Balancer) ermöglicht eine horizontale Skalierbarkeit des Systems, indem sie HTTPAnfragen auf mehrere identisch konfigurierte und zu einem Cluster zusammengefasste Webserver verteilt. Für den Benutzer ist diese Lastverteilung transparent – ihm erscheint das System wie ein einziger Webserver. Zur Verteilung werden Regeln eingesetzt, die sich dynamisch an die konkrete Systemlast anpassen können. Neben der Skalierbarkeit auf beliebig viele nachgelagerte Webserver bietet die Lastverteilung dank der Redundanz der Server auch den Vorteil einer höheren Systemverfügbarkeit, da bei Ausfall eines Webservers dessen Aufgaben von einem anderen Server übernommen werden können. Voraussetzung ist eine hohe Verfügbarkeit der Lastverteilungskomponente. Ein Proxy Cache nimmt, vergleichbar einem Makler, die Anfragen von einem Webbrowser entgegen und leitet diese an den zuständigen (Web-)Server weiter. Eine Kopie der Antwort vom Server speichert er in einem eigenen Cache-Bereich. Wird dasselbe Objekt mehrfach angefordert, so können die Clients direkt aus dem Cache bedient werden, ohne den Server bemühen zu müssen. Das beschleunigt vor allem den Zugriff auf dynamisch generierte Inhalte. Die zeitaufwendige Generierung der Inhalte muss der Server nur noch dann durchführen, wenn diese sich geändert haben. Allerdings ist das Caching dynamischer Inhalte mitunter sehr komplex, da für jeden generierten Teilinhalt geprüft werden muss, ob er sich gegenüber der vorherigen Anfrage verändert hat.

6 Referenzarchitektur

6.3.6 Firewall Der Begriff „Firewall“ stammt aus dem Ingenieurbau und bezeichnet dort eine Wand, die das Übergreifen eines Feuers auf andere Gebäudeteile verhindern soll. Auf Computernetzwerke übertragen, schützt eine Firewall ein privates Netzwerk (LAN, Intranet) vor den Gefahren, die von einem ungeschützten Netzwerk (in der Regel dem Internet) ausgehen. Ist ein privates Netzwerk mit dem Internet verbunden, so ist es automatisch auch von allen Rechnern im Internet aus erreichbar. Eine Hauptaufgabe der Firewall ist es daher, das private Netzwerk vor jedem unautorisierten Zugriff von außen zu schützen. In der Firewall werden Sicherheits- und auch Netzwerkverkehrsregeln definiert. Jedes Datenpaket muss die Firewall passieren und wird auf seine Art, Herkunft und Zielort überprüft. Die Firewall entscheidet dann anhand der Regeln, ob das Paket die Firewall passieren darf oder ob es abgewiesen wird. Die Firewall kontrolliert jedoch nicht nur die eingehenden Datenpakete. Auch für die Gegenrichtung lassen sich Regeln definieren, die den Datenverkehr auf bestimmte Dienste bzw. Netzwerkprotokolle (z.B. HTTP, E-Mail, FTP) einschränken. Leider bieten Firewalls keinen lückenlosen Schutz vor unberechtigten Zugriffen. Das liegt zum einen an Sicherheitslücken im Firewall-System selbst bzw. in den Softwarekomponenten, auf denen es aufbaut. Hier werden immer wieder Fehler aufgedeckt, die einem Experten eine „Hintertür“ öffnen, mit der die Schutzmechanismen umgangen werden können. Zum anderen können Firewalls nur vor Zugriffen von außen schützen, sind aber machtlos, wenn sich der Angreifer im privaten Netzwerk befindet. Auch Fehler bei der Konfiguration von Firewall-Systemen, bedingt durch die komplexe Materie der Netzwerktechnik, führen häufig dazu, dass der Schutz entscheidend geschwächt wird. Die Bandbreite an Topologien für geschützte private Netzwerke reicht von der Firewall-Software auf dem PC, über einen dedizierten Firewall-PC mit direktem Zugang zum Internet einerseits und dem privaten Netzwerk andererseits, bis hin zu komplexen Netzwerkarchitekturen mit sogenannten demilitarisierten Zonen (DMZ). Firewalls sind entweder Softwarepakete, die üblicherweise auf einem speziell für diese Zwecke eingerichteten Server installiert werden, oder sie sind als spezialisierte Hardwarekomponente realisiert. Einen umfassenden Überblick über das Thema Firewalls finden Sie bei Zwicky und Chapman (2000).

6.3 Technische Referenzarchitektur

Aufgaben

Grenzen

Technologien

■ ■ ■

179

6.3.7 Web Services Web Services werden in diesem Buch an verschiedenen Stellen thematisiert (vgl. Abschnitte 1.4.2, 2.2.3 und 7.4.1). Wir verzichten hier auf eine wiederholte Beschreibung der Technologie und verweisen auf die genannten Kapitel. Im Rahmen der Referenzarchitektur stehen Web Services für die im Abschnitt 5.9 vorgestellte Architektur entkoppelter Komponenten. Mit Hilfe dieser Technologie können sowohl fachliche Dienstleistungen als auch Portalkomponenten (z.B. Portlets) über das Internet bezogen und in das Portal integriert werden.

6.3.8 Portaladministration und -überwachung Für die administrativen Aufgaben der Konfiguration und Überwachung bieten technische Systeme entsprechende Werkzeuge. Die Bandbreite reicht von einfachen Skripten und Protokolldateien (Logfiles) bis hin zu umfangreichen, nicht selten webbasierten Anwendungen. Der Funktionsumfang variiert, abhängig vom Umfang der konfigurierbaren Eigenschaften des Systems. Einige Funktionen finden sich aber in den meisten Administrationswerkzeugen: ■

Statusbericht des Systems bzw. seiner Komponenten,

■

Überblick über die aktuelle Konfiguration des Systems bzw. seiner Komponenten,

■

Starten und Stoppen des Systems bzw. seiner Komponenten,

■

Modifizieren der Systemparameter,

■

Einblick in die Protokolldateien (Logfiles, Ereignisprotokolle),

■

Statistik zum Systemverhalten (z.B. Speicherverbrauch, CPUZeit oder Durchsatz).

Aus der Sichtweise eines Systemadministrators handelt es sich bei einem Portalsystem um eine komplexe IT-Architektur. Sie besteht aus mehreren umfangreichen Komponenten, die für sich genommen schon komplex sind und deren Zusammenspiel organisiert und sichergestellt werden muss. Da die Komponenten nur in seltenen Fällen vom selben Hersteller stammen, muss man davon ausgehen, dass die Werkzeuge für deren Administration nicht integriert sind. Doch selbst verschiedene Werkzeuge desselben Herstellers

180

■ ■ ■

6 Referenzarchitektur

können sich voneinander unterscheiden, wie das Beispiel des Oracle Application Servers zeigt, dessen Enterprise Manager nicht in die Administrationswerkzeuge des Oracle-Datenbanksystems integriert ist (vgl. Heldt u. Koschek 2005). Je größer ein Unternehmensportal ist, gemessen an der Zahl seiner Benutzer und der Nutzungsfrequenz, desto wichtiger ist es, den Zeitaufwand bei der Identifizierung und Behebung von Problemen in der Verwaltung von Ressourcen, Transaktionen oder Systemereignissen zu reduzieren. Moderne Überwachungssysteme unterstützen ein proaktives Überwachen und Handeln, indem sie mögliche Engpässe oder Fehler frühzeitig erkennen und bereits Gegenmaßnahmen ergreifen (bzw. dem menschlichen Administrator vorschlagen), bevor es zu einem Fehlerfall oder gar einem Systemausfall kommt. Damit halten sie den einwandfreien Betriebszustand der ITUmgebung aufrecht. IT-Systemmanagement ist ein vielfältiges Fachgebiet, für das viele verschiedene Lösungen erhältlich sind. Allein IBM bietet unter dem Markennamen „Tivoli“ mehr als dreißig verschiedene Softwarelösungen an, die verschiedene Bereiche des Systemmanagements abdecken.

6.3 Technische Referenzarchitektur

■ ■ ■

181

7 Standards

Die Verwendung ausgereifter, allgemein akzeptierter und weit verbreiteter Standards bietet viele Vorteile bei der Softwareentwicklung – und das nicht nur für Unternehmensportale. Sie dienen als verlässliche Basis, fördern die Wiederverwendung erprobter Muster und Rahmenwerke und erleichtern die Interoperabilität. Damit verbessern sie insgesamt die Zukunftsfähigkeit der Portale sowohl im technischen Bereich als auch bei der Beschreibung der Inhalte. In diesem Kapitel werden Standards vorgestellt, die für die verschiedenen fachlichen und technischen Aspekte von Unternehmensportalen eine Rolle spielen.

Kurz gefasst

7.1 Der Nutzen von Standards Standards und Normen – da denkt man an Aktenordner, in denen im besten Beamtendeutsch Dinge und Prozesse (über)spezifiziert werden. Fluch oder Segen? Wir meinen: In der Regel eher Letzteres. „Normung beschleunigt Innovation, wenn man sich frühzeitig auf gemeinsame technische Plattformen einigt“, sagt Bernd Hartlieb, der beim Deutschen Institut für Normung e.V., kurz DIN, für entwicklungsbegleitende Normung zuständig ist (vgl. Ramge 2004). Was passiert, wenn man sich nicht einigt, das mussten die Anwender von Portalsystemen erfahren. Weil die Hersteller versäumten, die Technologie zur Erstellung von Portalanwendungen frühzeitig zu vereinheitlichen, waren die Anwendungen verschiedener Portalsysteme nicht kompatibel. Schließlich einigten sich die Hersteller auf einen gemeinsamen Portlet-Standard, der im Folgenden näher beschrieben werden soll. Aber auch ganz allgemeine Standards, deren Verwendung nicht auf Portale beschränkt ist, finden hier Verwendung – allen voran die Extensible Markup Language, kurz XML. Dieses universelle Metaformat bildet unter anderem die Basis für RSS, einen offenen Standard für die Formatierung von Nachrichten und Informationen.

7.1 Der Nutzen von Standards

■ ■ ■

183

Als offene Standards bezeichnen wir all jene Standards, die frei zugänglich sind und deren Nutzung in der Regel nicht mit Lizenzkosten verbunden ist. Standards sind mehr als Normen

Entwurfsmuster

Standards für Portale

184

■ ■ ■

Ein Standard muss nicht unbedingt normiert sein – viele Standards der Informationstechnologie existieren aufgrund stiller Übereinkunft, teilweise ratifiziert durch globale Konsortien, Stiftungen oder Softwarekonzerne, oder werden dank ihrer weiten Verbreitung faktisch zum Standard erhoben. Nichtsdestotrotz sind sie meistens formal beschrieben und umfassend dokumentiert. Das vereinfacht die Verwendung der Standards und regt zur aktiven Weiterentwicklung an – denn schließlich leben diese offenen Standards vom Zuspruch und der Mitarbeit der weltweiten Entwickler-Gemeinde. Die Weiterentwicklung darf allerdings nicht dazu führen, dass der Standard verwässert wird. Auch Entwurfsmuster (Design Patterns, vgl. Gamma et al. 1995) können im weitesten Sinne den Standards zugeordnet werden. Schließlich handelt es sich um strukturierte Beschreibungen erprobter Handlungsanweisungen bzw. Software-Mikroarchitekturen. Sie werden in diesem Kapitel jedoch nicht weiter behandelt. Die im Folgenden vorgestellten Standards sind für verschiedene Aspekte von Unternehmensportalen relevant. XML ist – wie erwähnt – ein Metastandard, der als Basistechnologie in nahezu allen modernen IT-Systemen Verwendung findet. Auch bei den Standards für die Präsentation und das Layout von Portalinhalten wird XML eingesetzt. Die Integration von Softwaresystemen kann mit Web Services und der Java Connector Architecture (JCA) standardisiert werden. Anschließend werden mit den Portlets und den Web Services for Remote Portlets (WSRP) zwei Schwester-Standards vorgestellt, die der Kompatibilität von Portalanwendungen über die Grenzen einzelner Portalsysteme hinaus dienen. Mit RSS wird stellvertretend ein Format für die einheitliche Beschreibung von Inhalten vorgestellt. Schließlich zeigt ein Überblick über die Aktivitäten der Workflow Management Coalition (WfMC) den Status Quo der Standardisierung im Bereich der Geschäftsprozesse.

7 Standards

7.2 Basistechnologie XML Die Extensible Markup Language, kurz XML, ist eine vereinfachte Form der Standard Generalized Markup Language (SGML). XML entstand aus dem Bedürfnis, den Austausch von Daten zwischen verschiedenen Anwendungen zu vereinfachen. In der Vergangenheit wurden proprietäre, anwendungsspezifische Formate zur Speicherung von Daten verwendet. Das Dokumentformat von Microsoft Word war lange Zeit ein gut gehütetes Geheimnis. Für die Konkurrenz auf dem Markt der Textverarbeitungsprogramme war es schwierig, Dokumente vollständig und fehlerfrei aus dem Format des Marktführers in die eigene Software zu importieren bzw. in Word zu exportieren. Bei einfachen Texten gelang dies einwandfrei. Kamen aber komplexere Formatierungselemente wie Tabellen oder Abbildungen oder umfangreiche Absatzformate ins Spiel, so ähnelte das konvertierte Dokument nur annähernd dem Original. Mittlerweile hat Microsoft die Dokumentformate seiner OfficeAnwendungen auf XML umgestellt. Die Definition des XMLFormats für Word-Dokumente ist zwar sehr umfangreich, aber für Fremdprogramme ist es damit deutlich einfacher geworden, eine Word-Datei zu „verstehen“ und weiterzuverarbeiten. Das liegt an der Struktur, die allen XML-Dokumenten gemein ist. Der entscheidende Vorteil von XML gegenüber den ursprünglichen individuellen Formaten besteht in der Vereinheitlichung der Strukturierungselemente. Diese sind bei allen XML-Formaten in Form und Verhalten identisch, unterscheiden sich aber im semantischen Gehalt. Ein XML-Format kann beliebig viele solcher Elemente definieren und Regeln für den Aufbau von Dokumenten als Kombination solcher Elemente festlegen. Diese Elemente können durch Attribute genauer beschrieben werden. Da sowohl die Elemente selbst als auch ihre Attribute einen Namen tragen, erschließt sich die Bedeutung eines XML-Dokuments – die Verwendung „sprechender“ Namen vorausgesetzt – allein aus ihrer Notation. Auch die formale Beschreibung des XML-Formats, als Dokumenttyp-Definition (DTD) oder XML-Schema, dient der Dokumentation des Formats und trägt zu dessen Verständnis bei. XML ist eine sogenannte Auszeichnungssprache (engl. Markup Language). Die logischen Bestandteile eines XML-Dokuments werden durch die oben beschriebenen Elemente ausgezeichnet, die darüber hinaus hierarchisch geschachtelt werden können. Da sowohl

7.2 Basistechnologie XML

Einheitliche Struktur und formale Beschreibung

Auszeichnungssprache

■ ■ ■

185

der Anfang als auch das Ende eines jeden XML-Elements ausgezeichnet sind, ist der Umfang jedes logischen Dokumentbestandteils eindeutig definiert. Die beschriebenen Charakteristika von XML-Dokumenten lassen sich gut an einem einfachen Beispiel darstellen.

Rechnung Nr.

Datum

Kundennr.

Bruttopreis

MwSt-Betrag

4711081517089974371538····97.6016····15.62 Nettopreis

Versand- Rechnungskosten betrag

Pos. Nr.

Anz.

Abb. 7.1 Struktur eines Rechnungsdatensatzes mit festen Feldlängen

MwSt

Die Weinhandelsgesellschaft, aus der Wein&Dein hervorgegangen ist, verwendete eine spezielle Software für die Verwaltung von Bestellungen und Rechnungen. Dieses auf einem Mainframe laufende System basierte auf einer hierarchischen IMS-Datenbank, in der unter anderem alle Rechnungen elektronisch gespeichert wurden. Der folgende Ausschnitt aus einem exportierten Datensatz für eine einzelne Rechnung zeigt die Grenzen des Formats auf:

Artikelnr.

····81.98··5.20···102.80··1·600024651 Artikel

Einzelpreis

Gesamtpreis

Pos. Nr.

Anz.

1994ER·SCHRIESH.·WUENSCHELR.·SPAETBURGUN Artikelnr.

····12.95····77.70··2·200043920 Artikel

1998ER·LADENBURGER·HULDIGER·RIESLING···· Einzelpreis

Gesamtpreis

·····9.95····19.90

Alle Felder haben eine feste Länge, z.B. 40 Zeichen für die Artikelbezeichnung. Kürzere Werte werden mit Leerzeichen „·“ aufgefüllt, längere Artikelbezeichnungen müssen abgekürzt werden. Umlaute und Sonderzeichen sind nicht erlaubt. Sind die Nummernkreise für Rechnungs- und Kundennummer zu knapp definiert, dann kann es passieren, dass irgendwann keine neuen Kunden bzw. Rechnungen vom System verwaltet werden können – ein Problem, das in der Praxis häufig zu beobachten ist. Ebenso klassisch ist das Jahr-2000Problem von Altanwendungen, die zur Speicherung der Jahreszahl

186

■ ■ ■

7 Standards

lediglich zwei Ziffern vorsehen. Problematisch wird es auch, wenn der Mehrwertsteuersatz in Zukunft nicht mehr ganzzahlig sein sollte – dann reichen die vorgesehenen zwei Stellen nicht mehr aus. Oft wird in solchen Fällen das Datenformat durch das Hinzufügen neuer Felder erweitert – in diesem Fall könnte ein weiteres Feld zur Aufnahme der MwSt-Nachkommastellen Abhilfe schaffen. Dadurch wird das ohnehin schwer lesbare Datenformat weiter verkompliziert. Zudem ist das System nicht in der Lage, mit verschiedenen Währungen umzugehen – es wird immer die Deutsche Mark als Währung angenommen. Die Artikelnummer wird vorn mit Nullen anstelle von Leerzeichen aufgefüllt. Ein verarbeitendes Programm muss diese Sonderregel kennen. Durch Darstellung der obigen Informationen im XML-Format lassen sich alle angesprochenen Probleme lösen. Das folgende Listing zeigt ein XML-Dokument, das obige Rechnungsinformationen für eine aktuelle, in Euro ausgestellte Rechnung verwendet. Als Service für jene Kunden, die immer noch mit der D-Mark rechnen, wird der umgerechnete Kurs angegeben.

2004-08-17 74371538

6

1994er Schriesheimer Wünschelrütchen Spätburgunder

8.50

51.00

2

1998er Ladenburger Huldiger Riesling

5.95

11.90

7.2 Basistechnologie XML

Listing 7.1 Rechnung im XML-Format

■ ■ ■

187



16

10.06

5.20

68.10

133.19

XML-Struktur

XML-Bezeichner

188

■ ■ ■

Zunächst fällt die besondere Art der Feldkennzeichnung auf. Diese macht den Datensatz deutlich umfangreicher – dafür kann offensichtlich auf Abkürzungen verzichtet werden. Die Feldkennzeichnungen sind hierarchisch strukturiert, hier durch entsprechende Einrückungen verdeutlicht. Diese Einrückungen, wie auch die Zeilenumbrüche, sind übrigens optional und dienen nur der Lesbarkeit. Jedes XML-Dokument besitzt genau ein Wurzelelement – im obigen Beispiel ist dies das Element . Elemente können Unterelemente (Kinder, children) haben. So ist ein Unterelement von . Es kann mehrere Elemente auf derselben Ebene (Geschwister, siblings) geben, z.B. und . Auch kann ein Element(typ) mehrfach vorkommen, wie z.B. . Jedes Element beginnt mit dem in spitze Klammern eingefassten Elementnamen. Der Ende-Bezeichner sieht ganz ähnlich aus – dem Elementnamen ist zusätzlich ein Schrägstrich „/“ vorangestellt. Zwischen den beiden Bezeichnern kann im Fall eines Blattelements (ein Element ohne Kinder, z.B. ) beliebiger Text stehen. Da XML-Dokumente verschiedene Zeichensätze verwenden können (neben dem universellen Unicode z.B. auch den Zeichensatz ISO 8859-1, der die wichtigsten in Westeuropa verwendeten Zeichen enthält), gibt es keine Beschränkung bei der Wahl von Sonderzeichen. Lediglich jene Zeichen, die zum XML-Sprachumfang gehören (z.B. die spitzen Klammern), müssen besonders kodiert werden. Für alle anderen Zeichen genügt die Deklaration des gewünschten Zeichensatzes im Attribut „encoding“.

7 Standards

Elemente können Attribute besitzen. So wurde die Rechnungsnummer als Attribut „Nr“ des Elements modelliert. Genauso gut hätte man diese auch als Kindelement von definieren können. Es gibt keine vorgeschriebenen Regeln, wann man eine Eigenschaft als Attribut bzw. als Element definieren muss. Einige Datenmodellierer verwenden Attribute immer dann, wenn die Eigenschaft für das Element genau ein einziges Mal vergeben werden kann. Entsprechend dieser Regel wurde im obigen Beispiel die Währung als Attribut modelliert. Hat ein Element mehrere Eigenschaften desselben Typs, so müssen diese als Elemente ausgestaltet sein, da ein Attributname in einem Element nur einmal verwendet werden darf. Auch im Falle komplexer Eigenschaften bietet sich die Modellierung als Element an. Das mehrfach vorkommende Element innerhalb von zeigt dies auf anschauliche Weise: Eine Rechnung kann mehrere Positionen enthalten, und eine Position ist ein komplexes Element mit verschiedenen Eigenschaften, wobei die Eigenschaft „Einzelpreis“ mehrfach vorkommt. Deshalb wurde die Position als Element modelliert. Ein großer Vorteil des XML-Formats wird bei der elektronischen Verarbeitung von XML-Dokumenten deutlich. Da die Attribute und Elemente über ihren Namen adressiert werden, spielt deren Position innerhalb des Dokuments keine Rolle. Selbst die Reihenfolge der Elemente kann in vielen Fällen beliebig vertauscht werden, ohne dass die verarbeitenden Programme angepasst werden müssen. Selbst wenn zu einem späteren Zeitpunkt neue Elemente oder Attribute zu einem XML-Format hinzugefügt werden, bleiben diese Programme funktionsfähig – sie lesen nur die ihnen bekannten Eigenschaften und ignorieren den Rest. Außerdem stehen für die Verarbeitung von XML-Dokumenten Standardwerkzeuge und Funktionsbibliotheken zur Verfügung. Deshalb sind die XMLdatenverarbeitenden Programme in der Regel robuster und weniger anfällig gegenüber Änderungen im (XML-)Datenformat als Programme, die Daten mit feldbasierten Formaten verarbeiten.

Elemente oder Attribute?

Adressierung über Attributund Elementnamen

7.2.1 Document Type Definition (DTD) Eine XML-Version der Rechnung bietet also Vorteile bezüglich der Lesbarkeit und der Weiterverarbeitung. Wie aber wird beschrieben, welche Elemente eine enthalten darf und welche Attribute für diese Elemente definiert sind? Diese und weitere Festlegungen werden in der Dokumenttypdefinition (DTD) oder in einem

7.2 Basistechnologie XML

■ ■ ■

189

XML-Schema (siehe Abschnitt 7.2.2) getroffen. Die DTD für unser Beispieldokument sieht wie folgt aus: Listing 7.2 Document Type Definition (DTD) für die XMLRechnung















(#PCDATA)> CDATA

#REQUIRED>

Die DTD legt für jedes Element die erlaubten Kindelemente sowie die Attribute fest. Die Kindelemente sind in Klammern aufgeführt. Ein „+“ hinter einem Elementnamen bedeutet, dass das entsprechende Element mehrfach, mindestens aber einmal vorkommt (1..n). Ein -Element kann demnach mehrere Elemente vom Typ beinhalten. Mit einem Stern „*“ werden Elemente bezeichnet, die beliebig oft (0..n) vorkommen können. Ein optionales Element (0..1) wird mit einem Fragezeichen „?“ markiert.

190

■ ■ ■

7 Standards

„#PCDATA“ steht als Platzhalter für beliebigen Text, ebenso das „CDATA“ in der Attributdefinition. Attribute können zwingend erforderlich (#REQUIRED) oder optional (#IMPLIED) sein. Neben den beschriebenen Definitionsmöglichkeiten gibt es noch weitere, die aber den Rahmen dieser XML-Einführung sprengen. Um ein XML-Dokument mit einer DTD zu verknüpfen, muss im XML-Dokument bekanntgegeben werden, welcher DTD dieses Dokument gehorcht. Diesem Zweck dient das DOCTYPE-Element, dessen einfachster Verwendungsfall (direkte Referenz der DTDDatei rechnung.dtd) wie folgt aussieht:



...

Listing 7.3 DTD-Referenz mittels DOCTYPE

Eine DTD ist übrigens nicht zwingend notwendig. XMLDokumente, die den XML-Spezifikationen genügen sowie den in einer DTD festgelegten Regeln folgen, werden als valide oder gültige Dokumente bezeichnet. Erfüllt ein Dokument lediglich die XMLSpezifikationen, ohne jedoch eine DTD zu verwenden, so spricht man von einem wohlgeformten Dokument. Dementsprechend ist jedes valide Dokument immer auch wohlgeformt, aber nicht jedes wohlgeformte Dokument ist valide.

7.2.2 XML-Schema Neben der DTD gibt es eine weitere Sprache zur Definition von XML-Formaten: XML-Schemata erweitern die Definitionsmöglichkeiten der DTD, um nicht nur die Struktur, sondern auch den Inhalt (z.B. Gültigkeiten) von Daten festlegen zu können. Das folgende Listing zeigt das XML-Schema zum Rechnungsbeispiel.

Listing 7.4 XML-Schema für die Rechnung





7.2 Basistechnologie XML

■ ■ ■

191

























192

■ ■ ■

7 Standards













Es fällt auf, dass die Schema-Definition deutlich umfangreicher ist als das DTD-Pendant. Das hat mehrere Gründe: So ist ein XMLSchema selbst eine XML-Datei. Das XML-Format ist – gemessen an der Länge der Dokumente – ein umfangreiches Format. Dafür ist es flexibel genug, um nahezu alle Anforderungen der Datenmodellierung standardisiert zu erfüllen. Das DTD-Format hingegen ist proprietär – und deshalb aus den eingangs genannten Gründen problematisch. Deshalb wurde dem ursprünglich von SGML übernommenen DTD-Konzept das standardisierte XML-Schema als Alternative zur Seite gestellt. Für jedes XML-Element der Rechnung wird ein Elementtyp angegeben. Im Falle einfacher Elemente, die lediglich aus einem Wert bestehen (z.B. das Rechnungsdatum), wird dem Elementnamen einer der XML-Schema-Standardtypen oder ein selbstdefinierter Typ („Betrag“ im obigen Beispiel) zugewiesen. Daneben gibt es komplexe Typen, die aus mehreren Kindelementen bestehen oder Attribute besitzen. Diese werden in -Elementen beschrieben. Das Präfix „xsd:“ bezeichnet einen Namensraum (namespace), der die XML-Schema-Definition umspannt. In der ersten Zeile der Schema-Definition wird dieser Namensraum definiert und durch Zuweisung zur gewählten XML-Schema-Definition eindeutig identifiziert (xmlns:xsd="http://www.w3.org/2001/XMLSchema"). Wie bereits erwähnt, erlaubt XML-Schema die Definition komplexer Typen. In einem -Element werden alle Kindelemente in der geforderten Reihenfolge angegeben. Möglich ist auch

7.2 Basistechnologie XML

Typisierte Elemente

Namensraum

Komplexe Elementtypen

■ ■ ■

193

die Definition einer Auswahl () aus Elementen. Die Attribute „minOccurs“ und „maxOccurs“ bestimmen die Häufigkeit, mit der das entsprechende Element in einem XML-Dokument auftauchen darf. Der voreingestellte Wert für beide Attribute ist 1. Demnach müssen die Elemente und im Beispiel mindestens einmal vorkommen. Bei der Attributdefinition für einen komplexen Typ ist die Voreinstellung eine andere: Ein Attribut ist grundsätzlich optional. Mit „use="required"“ wird festgelegt, dass ein Attribut zwingend erforderlich ist. Interessant ist die Definition von Elementen, die einen einfachen Typ haben, aber eines oder mehrere Attribute besitzen. Wie das Beispiel des Elements zeigt, müssen diese als komplexe Typen definiert werden, in denen ein einfacher Typ (hier „xsd:string“) um eines oder mehrere Attribute (hier „Nr“) erweitert wird. Das Attribut „Waehrung“ des Elements verwendet einen benutzerdefinierten einfachen Typ „Waehrungscode“. Sie finden die Definition am Ende der XML-Schema-Datei. Hier wird ein Standardtyp („xsd:string“) eingeschränkt – in diesem Fall auf Zeichenketten, die aus mindestens zwei, aber höchstens drei Großbuchstaben bestehen. Um ein XML-Dokument einem Schema zuzuordnen, das in der Datei rechnung.xsd gespeichert ist, muss das Schema als Attribut des Wurzelelements (hier: ) angegeben werden: Listing 7.5 XML-SchemaReferenz



… Dies soll genügen, um die Eigenschaften und Vorzüge von XML aufzuzeigen. Es konnten natürlich nicht alle Möglichkeiten von XML demonstriert werden – dazu sei auf die entsprechende Fachliteratur (z.B. Behme u. Mintert 2000; Harold u. Means 2004) und verschiedene Internetseiten zum Thema (www.xml.org, www.linkwerk.com) verwiesen. Einen Überblick über die Möglichkeiten von XML-Schema vermittelt Fallside (2001).

194

■ ■ ■

7 Standards

7.2.3 Definition eigener XML-Sprachen Aus dem Beispiel sollte deutlich geworden sein, dass XML keine (Programmier-)Sprache ist, sondern ein Standardformat nebst Regelwerk (DTD bzw. XML-Schema) zur Definition eigener Sprachen. Dank ihrer gemeinsamen Grundstruktur und Eigenschaften sowie einer klaren Trennung von Struktur und Inhalt sind XMLSprachen zueinander kompatibel. In diesem Sinne kann man XML als Metasprache bezeichnen, die zur Beschreibung anwendungsfallbezogener Datenaustauschformate und Business-Sprachen dient. Für einige Fachdomänen gibt es bereits standardisierte XML-basierte Sprachen, z.B. ebXML für Electronic Business, vXML (Voice XML) für Sprachdienste oder NewsML für Nachrichtenagenturen. Daneben existieren viele aufgaben- und unternehmensspezifische XML-Sprachen. Die Definition eines XML-Formats (und damit einer Sprache) ist im Wesentlichen ein Abstimmungsprozess zwischen den Experten aus dem IT- und dem Fachbereich. Dieser Prozess darf nicht unterschätzt werden, denn es muss ein Kompromiss zwischen den Interessen aller beteiligten Parteien gefunden werden. Auch wenn XML sehr strukturiert ist, so bietet es doch noch genügend Gestaltungsspielraum, der ausreichend Stoff für lange Diskussionen hergibt. Glücklicherweise lässt sich eine XML-Formatdefinition beliebig erweitern und gegebenenfalls auch verändern. So kann man mit einer überschaubaren Lösung beginnen, die nur die Kerninformationen definiert. Diese lässt sich dann sukzessive um weitere Informationen (sprich: Elemente und Attribute) erweitern. Solange es sich um Erweiterungen handelt, können Programme, die nur für die Basisversion des XML-„Dialekts“ ausgelegt sind, auch mit Dokumenten umgehen, die auf dem erweiterten Sprachumfang basieren – ein weiterer Vorteil von XML, da kosten- und zeitintensive Anpassungen der Software entfallen bzw. verlagert werden können. Das Beispiel zeigt die Einfachheit von XML und wiederlegt damit ein gängiges Vorurteil. XML basiert auf nur wenigen Konstrukten und Regeln. Die mit XML definierten Sprachen sind mitunter komplex, was aber nicht der XML angelastet werden kann. Ein weiteres Vorurteil betrifft die informationstechnische Verarbeitung von XML-Dokumenten. XML-basierte Anwendungen gelten als speicherhungrig und langsam. Zugegeben, XML-Dateien sind in der Regel größer als optimierte proprietäre Datenformate. Allerdings ist Plattenspeicher heutzutage billig und nur noch selten ein limitierender Faktor. Zudem sind XML-Dokumente reine Textdokumente, die sich für den Transport (z.B. im Netzwerk) stark komprimieren las-

7.2 Basistechnologie XML

Standardformat und Regelwerk zur Definition eigener Sprachen

Definition eines XML-Formats

Erweiterbar und abwärtskompatibel

XML ist weder kompliziert noch langsam

■ ■ ■

195

sen. Die Verarbeitung von XML-Daten ist nur so langsam wie die Systeme, auf denen die Verarbeitung stattfindet, sowie die zum Einsatz kommenden Programmiersprachen. Der Vorteil ist aber, dass XML standardisiert ist. Für eine Vielzahl von Programmiersprachen stehen – wiederum standardisierte – Schnittstellen (Application Programming Interfaces, APIs) für die XML-Verarbeitung zur Verfügung. Zu den bekanntesten XML-APIs gehören das Document Object Model (DOM) und das Simple API for XML Parsing (SAX). DOM ist insbesondere für komplexe Transformationen geeignet, benötigt aber mehr Speicherplatz. SAX hingegen kommt mit wenig Speicher aus und ist schnell. Die datenstromorientierte Verarbeitung von SAX ist allerdings nicht für alle Anwendungsfälle geeignet. Formal betrachtet ist der XML-Standard eine Empfehlung des World Wide Web Consortium (W3C; www.w3.org/XML/). Dieses unabhängige Gremium sichert die Offenheit von XML und bietet somit den nötigen Investitionsschutz für die Nutzer von XML. Damit werden die Vorzüge von XML – einfacher Aufbau, flexible Erweiterbarkeit, Integrationspotenzial, Verfügbarkeit vieler Werkzeuge und Programmierbibliotheken – auch in Zukunft für dessen zunehmende Verbreitung sorgen.

7.3 Standards für Präsentation und Layout von Portalinhalten Die Trennung von Content und Design ist als technische Anforderung im Abschnitt 5.11 beschrieben worden. Dahinter steht der Wunsch, das Layout einer Portalseite nachträglich ändern zu können, ohne dass diese Änderung Auswirkungen auf die Inhalte hat. Erreicht wird dies, indem Inhalte und Layout getrennt voneinander beschrieben und erst bei der Konstruktion der Portalseite miteinander verwoben werden. Ein XML-basiertes Standardformat für Nachrichten wird später noch vorgestellt (vgl. Abschnitt 7.6 über das RSS-Format). Zunächst sollen die gängigen (und standardisierten) Präsentations- und Layouttechniken vorgestellt werden. Den Anfang macht das wohl prominenteste Format des World Wide Web: HTML und sein an XML angepasster Schwesterstandard XHTML.

196

■ ■ ■

7 Standards

7.3.1 (X)HTML HTML, die „HyperText Markup Language“, wurde vom Erfinder des World Wide Web, Tim Berners-Lee, als Mittel zur Strukturierung von Texten erdacht. Von Beginn an konnten auch Grafiken in den Text integriert werden. Weitere Gestaltungselemente wie z.B. Tabellen oder Formulare kamen später hinzu. Heute bietet HTML mit Schnittstellen zu Cascading Stylesheets (CSS) oder JavaScript ein mächtiges Instrumentarium für die professionelle Gestaltung von Webseiten. Das wichtigste Konzept von HTML ist jedoch der Verweis (engl. Link), mit dem weitere HTML-Seiten oder andere Elemente im World Wide Web referenziert werden können. Diese Idee der Verknüpfung von Webseiten hat das World Wide Web zu dem gemacht, was es heute ist: Ein gigantisches Netzwerk von Informationen. HTML ist – genau wie XML – eine Auszeichnungssprache im Klartextformat. HTML-Seiten sind reine Textdateien, die mit nahezu jedem Texteditor erstellt werden können. Dieses Format hat zwei Vorteile: Es ist zum einen ohne Spezialsoftware lesbar und bearbeitbar. Zum anderen kann HTML einfach automatisch erzeugt werden. Es gibt viele Skriptsprachen wie z.B. PHP, die hauptsächlich der automatischen Generierung von HTML-Seiten dienen.

Auszeichnungssprache

Wein&Dein

Willkommen!

Willkommen bei Wein&Dein!

Listing 7.6 Eine einfache HTML-Datei

Wie das vorstehende Listing zeigt, ist die Grundstruktur einer HTML-Datei sehr einfach. Sie besteht aus

Grundstruktur

■

einer Dokumenttyp-Angabe, mit der die verwendete HTMLVersion festgelegt wird,

■

Kopfinformationen („Header“), wie z.B. dem Titel der Webseite,

■

dem eigentlichen Seiteninhalt („Body“).

7.3 Standards für Präsentation und Layout von Portalinhalten

■ ■ ■

197

Die HTMLHistorie

XHTML

198

■ ■ ■

Header und Body werden vom Wurzelelement eingefasst. Im Body verwendet man Textstrukturelemente (z.B. für Überschriften und

für Absätze) oder spezielle Elemente, z.B. für das Einbinden von Grafiken. Da das Zeichen „&“ in HTML eine besondere Bedeutung hat, muss es codiert werden. Der entsprechende Zeichencode lautet & (für engl. „Ampersand“). Diese Notation (&code;) kann auch für Sonderzeichen verwendet werden – so z.B. für die deutschen Umlaute (ä anstatt „ä“). Alternativ können im Header Angaben zu dem für diese HTML-Seite zu verwendenden Zeichensatz gemacht werden. HTML hat sich im Laufe der Zeit erheblich weiterentwickelt – teilweise aber auch zurückentwickelt, um sich auf seine Kernaufgabe zu beschränken. So spielt die Version 1.0 heute praktisch keine Rolle mehr – ist aber gleichwohl die Wurzel aller folgenden Formatversionen. Sie bietet im Wesentlichen Auszeichnungen für Standard-Elemente wie Überschriften, Textabsätze, für Grafikreferenzen und für Verweise. Version 2.0 stand immer im Schatten der HTMLErweiterungen, die von Netscape für den Webbrowser „Navigator“ entwickelt worden waren und allgemein großen Anklang fanden. Insbesondere die Frame-Technologie (Mehrfenster-Darstellung) gehört zu den bahnbrechenden Ideen des Netscape-Teams. Mit der Version 3.2 schoss das W3-Konsortium weit über das ursprüngliche Ziel hinaus. Euphorisiert durch die Netscape-Erfolgsgeschichte, wurden viele neue Gestaltungselemente in die Spezifikation aufgenommen – unter anderem auch die Tabellen. Leider fanden auch einige Elemente zur physischen Textauszeichnung (z.B. Schriftgrößen) den Weg in den Standard. Die Trennung von Content und Design begann zu schwinden. So ist es nicht verwunderlich, dass heute viele der Neuerungen von HTML 3.2 als „deprecated“ eingestuft sind und in naher Zukunft aus dem Standard verschwinden dürften. So ist der Nachfolger HTML 4.x deutlich schlanker. Um das Layout kümmern sich Cascading Stylesheets (CSS), deren Integration in HTML ebenso definiert ist wie die Einbindung von JavaScript. Die Version 4 basiert auf dem Unicode-Standard und erlaubt somit die Verarbeitung von Texten in verschiedenen Sprachen und Schriftsystemen. Einen kleinen Makel hat HTML: Es weist zwar eine XMLähnliche Struktur auf, ist aber nicht XML-kompatibel und kann deshalb nicht mit XML-Werkzeugen verarbeitet werden. Aus diesem Grund wurde die Sprache dahingehend modifiziert und im XHTMLStandard definiert. Mittlerweile existiert XHTML mit der Version 1.1 bereits in der zweiten Generation.

7 Standards

7.3.2 Cascading Stylesheets (CSS) Die Entscheidung, wie eine Überschrift vom Typ im Webbrowser dargestellt wird, trifft der Browser selbst. Das ist einerseits unbefriedigend, da das Layout der HTML-Seite oft bestimmten Vorgaben genügen muss, z.B. dem Corporate Design des Unternehmens. Andererseits möchte man den Inhalt und die Struktur der Dokumente von deren Design trennen. Die Angabe, dass es sich um eine Überschrift handelt, ist grundsätzlich noch unabhängig vom Design. Sie bezeichnet lediglich den semantischen Gehalt eines bestimmten Textabschnitts. Sobald aber Textauszeichnungen wie „kursiv“ oder Zeichensätze (Fonts) oder Schriftgrößen ins Spiel kommen, ist die Grenze zum Design überschritten. Diese Formatangaben sollten in einem getrennten Dokument gemacht werden können. Genau diesen Zweck erfüllen die Cascading Stylesheets (CSS). In einem solchen Stylesheet kann z.B. festgelegt werden, dass Überschriften vom Typ immer in Arial fett mit einer Schriftgröße von 16 Punkt erscheinen (vgl. Listing 7.7). Darüber hinaus können Randabstände, Hintergrundfarben, Tabellen, Listenformatierungen und ähnliche Layout-Angaben definiert werden. Elemente können sogar punktgenau platziert und für verschiedene Ausgabemedien (Bildschirm, Papier) unterschiedlich formatiert werden. Diese Formatangaben können benannt und über ihren Namen in der HTML-Datei referenziert werden.

Trennung von Struktur und Layout

h1 { font-family: Arial, sans-serif; font-size: 16pt; font-weight: bold; }

Listing 7.7 CSS-Definition (HTML-Überschrift erster Ordnung)

Die CSS-Informationen können auch direkt in der HTML-Datei angegeben werden. Das verstößt allerdings wieder gegen den Grundsatz der Trennung von Content und Design. Der größte Vorteil einer Auslagerung in eine separate Datei ist aber die universelle Verwendung dieser CSS-Datei für verschiedene HTML-Dateien. So kann z.B. eine zentrale CSS-Datei das Corporate Design eines Unternehmens umsetzen, was die Einheitlichkeit des Designs aller Webseiten eines Portals vereinfacht. Bei einer Änderung des Layouts muss nur die CSS-Datei angepasst werden. Alle HTMLDateien, die dieses Cascading Stylesheet verwenden, erscheinen fortan im neuen Layout, ohne dass die HTML-Seite geändert werden muss.

7.3 Standards für Präsentation und Layout von Portalinhalten

■ ■ ■

199

Eine planlose Verwendung von Stylesheets führt in vielen Fällen zu Problemen. Angenommen, in allen HTML-Seiten sei eine Stilklasse für alle Überschriften zweiten Grades definiert worden. Trifft nun jemand die Entscheidung, dass für einen bestimmten Typ von Inhalten diese Überschrift anders gestaltet werden soll, dann kann auch das Stylesheet nicht helfen: Für die betreffenden Seiten muss eine neue Stilklasse definiert werden. Diese muss in jede betroffene HTML-Seite eingetragen werden. Vor der Verwendung von Stylesheets müssen die benötigten Inhalts- und Strukturtypen definiert werden. Auch wenn diese im Aussehen identisch sind, sollten verschiedene Stilklassen verwendet werden, um spätere Änderungen zu ermöglichen. Die StylesheetDefinition sollte sich also an fachlichen Gesichtspunkten und nicht am Layout orientieren.

7.3.3 XSL(T) Am Beispiel von CSS haben wir bereits gesehen, wie eine Auszeichnungssprache wie HTML um Formatierungsinformationen ergänzt werden kann. Damit erhält der Ersteller von HTML-Seiten die Kontrolle über das Aussehen seiner Seite. Ohne CSS-Informationen entscheidet der Webbrowser, wie die verschiedenen HTMLElemente dargestellt werden sollen. Diese Voreinstellungen sind den üblichen Formatierungen von Texten entlehnt. So ist eine Überschrift üblicherweise in einer größeren Schrift als der Fließtext gesetzt und weist einen größeren Absatzabstand auf. Will man eine XML-Datei in einem Webbrowser anzeigen, so kennt dieser die anwendungsspezifischen Elementtypen nicht – folglich kann er keine voreingestellten Darstellungsformen anbieten. Hat man bei HTMLDokumenten noch die Wahl, eine eigene CSS-Datei zu verwenden, so müssen für die Darstellung von XML-Dateien immer benutzerdefinierte Formatierungsanweisungen verwendet werden. Die entsprechende Stylesheet-Sprache heißt XSL (Extensible Stylesheet Language). Der Funktionsumfang geht mit Sortierung und automatischer Nummerierung sogar über die Möglichkeiten von CSS hinaus. Allerdings kann XSL die Formatierung von XML-Dokumenten nicht direkt durchführen. Es erwartet als Quellformat einen speziellen Dokumenttyp namens XSL-FO, der sogenannte Formatierungsobjekte (FO) enthält. Um beliebige XML-Dokumente in Formatierungsobjekte zu überführen, verwendet man eine weitere StylesheetSprache: XSLT (XSL Transformation). Mit XSLT können XML-

200

■ ■ ■

7 Standards

Dokumente nicht nur in XSL-FO, sondern in beliebige andere Formate übersetzt (transformiert) werden. Es ist sogar möglich, XML mittels XSLT direkt in HTML umzuwandeln, ohne den Umweg via XSL-FO gehen zu müssen. Letzteres dient derzeit vor allem der seitenorientierten Formatierung, z.B. in PDF. Abbildung 7.2 verdeutlicht das Zusammenspiel von XSL und XSLT. Abb. 7.2 Transformation und Formatierung von XML mittels XSL(T)

XML

XSLTProzessor

XML

XHTML

...

FO

XSLFormatierer

PDF

Postscript

...

Der folgende Ausschnitt aus einem XSLT-Stylesheet wandelt die im Abschnitt 7.2 eingeführte XML-Rechnung in ein (einfaches) (X)HTML-Format um.

Wein&Dein

Rechnung
Nr.
Kundennr.

7.3 Standards für Präsentation und Layout von Portalinhalten

Listing 7.8 XSLTStylesheet zur Umwandlung einer Rechnung von XML nach HTML

■ ■ ■

201

Nr.	Artikelnr.	Bezeichnung	Anzahl	Einzelpreis	Gesamtpreis
Artikelsumme:
Enthaltene MwSt 202 ■ ■ ■ 7 Standards (%):   ; Nettobetrag:
Versandkosten:
Rechnungsbetrag:

definiert eine Bearbeitungsanweisung für das im „match“-Attribut angegebene Element. Die in der Abbildung dargestellten Anweisungen werden demnach ausgeführt, sobald der XSLT-Prozessor bei der Analyse der XML-Datei auf ein -Element trifft. Das Element selektiert Text aus dem Inhalt von XML-Elementen oder deren Attributen. So wird mittels der

7.3 Standards für Präsentation und Layout von Portalinhalten

■ ■ ■

203

Wert des Attributs „Nr“ vom -Kindelement in die Ausgabe eingefügt. iteriert über alle -Elemente der Rechnung und erzeugt je Position eine Tabellenzeile.   bezeichnet das Leerzeichen. Dieses muss explizit als dezimale Zeichenreferenz angegeben werden. Das soll als Einführung in die Navigations- und Formatierungsmöglichkeiten von XSLT genügen. Details findet man in der Fachliteratur, z.B. in dem bereits erwähnten Buch von Behme und Mintert (2000). Einige Webbrowser, wie z.B. der Microsoft Internet Explorer, sind übrigens in der Lage, XML-Dateien mit einem angegebenen XSLT-Stylesheet zu transformieren und das Ergebnis – so es denn (X)HTML ist – formatiert anzuzeigen. Abbildung 7.3 zeigt das Ergebnis der Formatierung unserer XML-Beispielrechnung mit dem obigen Stylesheet. Abb. 7.3 Formatierung einer XML-Datei mittels XSL im Microsoft Internet Explorer

Die (X)HTML-Spezifikationen sind beim W3-Konsortium (www.w3.org) zu finden. Weiterführende Informationen zu (X)HTML und allen damit verbundenen Standards (CSS, JavaScript, XSL & Co.) bietet SELFHTML, das deutschsprachige HTMLKompendium von Stefan Münz (selfhtml.teamone.de). Behme und Mintert (2000) beschreiben verschiedene Möglichkeiten der XMLTransformation für ein professionelles Web-Publishing mit XML.

204

■ ■ ■

7 Standards

Die XML-Dateien sowie die DTD, das XML-Schema und das XSLT-Stylesheet für das Beispiel können von der Webseite www.pret-a-portal.info bezogen werden.

7.4 Standards für Integration Integration ist die Einbindung von beliebigen Informationssystemen in ein gegebenes System. Die beliebige Beschaffenheit und Komplexität der Daten macht die Integration oftmals zu einer zeit- und kostenintensiven (und nicht selten deutlich unterschätzten) Aufgabe. Wie kann eine so individuelle Aufgabe von Standards profitieren? Schließlich möchte man das zu integrierende System in der Regel unberührt lassen, weil es oft zu aufwendig oder gar unmöglich ist, Änderungen an dem alten oder geschlossenen Code vorzunehmen. Anstatt also das System selbst zu standardisieren, vereinheitlicht man die Kommunikationsprotokolle zwischen Integrator und zu integrierendem System. Wohlgemerkt: Nur das Protokoll soll standardisiert werden, nicht aber der Kommunikationsweg. Letzterer ist oft zu individuell oder historisch bedingt. Aus diesem Grund rückten Kommunikationsmechanismen für verteilte Systeme in den Mittelpunkt des Interesses der Integrationskonzepte. Zwei wichtige Konzepte, die zu Standards avanciert sind, möchten wir vorstellen. Zum einen die Web Services, quasi der „Über-Standard“ der verteilten Kommunikation. Zum anderen einen Standard, der im Rahmen der J2EE-Spezifikationssammlung die Integrationsaufgabe übernimmt.

7.4.1 Web Services Ein Web Service ist, fachlich betrachtet, ein Dienst, der Funktionen anbietet, die von den Dienstnehmern über Web-Technologien genutzt werden können. Web Services eignen sich als Basistechnologie für durchgängig implementierte fachliche Geschäftsprozesse. Abschnitt 2.2.3 betrachtet Web Services aus einer solchen fachlichen Sichtweise. Aus technischer Sicht handelt es sich bei einem Web Service um ein Programm, welches über das Internet oder Intranet mittels SOAP-gekapselter Funktionsaufrufe angesprochen werden kann. Dazu werden XML-Nachrichten über ein Internetprotokoll ausgetauscht. Diese Nutzung von standardisierten und allgemein verfügbaren Kommunikationskanälen ermöglicht die sichere Kommunikation von lose miteinander verbundenen Komponenten. Da Firewalls

7.4 Standards für Integration

■ ■ ■

205

das HTTP(S)-Protokoll üblicherweise zulassen, müssen sie für die Nutzung von Web Services in der Regel nicht angepasst werden. Das wiederum erleichtert die Integration bestehender (Alt-)Systeme. Die Wahl von XML für die Kommunikation und die Schnittstellenbeschreibung bringt schließlich die ersehnte Unabhängigkeit von der Systemplattform und der Programmiersprache. Ein in COBOL auf einem Mainframe programmierter Web Service kann z.B. von einem in Java programmierten Programm auf einem PC genutzt werden. Booth et al. (2004) definieren Web Services wie folgt: “A Web Service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”

Abbildung 7.4 zeigt die Architektur der Web Services und die zur Schnittstellenbeschreibung und dem Nachrichtenaustausch verwendeten Technologien. Diese basieren auf den in diesem Kapitel vorgestellten XML-Basistechnologien (XML, DTD und XMLSchema). Abb. 7.4 Web-ServicesArchitektur (nach Booth et al. 2004)

Dienstebeschreibungen WSDL Nachrichten SOAP, SOAP-Erweiterungen

Verwaltung

Sicherheit

Prozesse Auffinden, Aggregieren, Koordinieren

Basistechnologien XML, DTD, XML-Schema

Kommunikation HTTP, SMTP, FTP, JMS, IIOP

Kommunikation

206

■ ■ ■

Ein Web Service kommuniziert mit anderen Softwarekomponenten mittels XML-Nachrichten. Diese Nachrichten können über alle gängigen Internetprotokolle (z.B. HTTP und SMTP) ausgetauscht werden.

7 Standards

Der Aufruf der von einem Web Service angebotenen Dienste wird durch das Versenden einer SOAP-Nachricht initiiert. Das Simple Object Access Protocol (SOAP; auch als Service Oriented Architecture Protocol bezeichnet) ermöglicht die Ausführung entfernter Methodenaufrufe (Remote Procedure Calls, RPC) sowie den asynchronen Austausch von Nachrichten. Auch Fehlermeldungen können als SOAP-Nachricht versandt werden. Darüber hinaus definiert SOAP ein Verarbeitungsmodell, das für den Kommunikationspfad zwischen Sender und Empfänger noch Zwischenstationen (Intermediaries) zulässt. Eine Nachricht kann auf ihrem Weg zum Empfänger bei allen besuchten Intermediaries Aktionen auslösen. Das Diensteangebot sowie die technischen Voraussetzungen für die Nutzung eines Web Services werden mit Hilfe der Web Services Description Language (WSDL) beschrieben. Diese definiert den sogenannten Port des Web Service, d.h. dessen Schnittstelle mit den angebotenen Operationen bzw. Methoden. Eine WSDLBeschreibung beantwortet drei Fragen (vgl. Kossmann u. Leymann 2004): ■

Was: Was bietet der Web Service?

■

Wie: Welche Protokolle werden zum Nachrichtenaustausch verwendet, und wie werden die Nachrichten kodiert?

■

Wo: Wie heißt der Web Service, und unter welcher Internetadresse kann man Nachrichten an den Web Service schicken?

Zum Auffinden eines Web Service werden spezielle Dienste bemüht. So dient beispielsweise UDDI (Universal Description, Discovery and Integration) der Katalogisierung von Web Services. Bei der Suche nach dem gewünschten Web Service müssen unter Umständen mehrere dieser Kataloge befragt werden. Ein Koordinationsdienst übernimmt diese Aufgabe. Er dient dem Nachfrager eines Dienstes als Makler für die verschiedenen Dienstanbieter. Da Web Services über das Internet abgewickelt werden, muss die Sicherheit bei der Nachrichtenübertragung gewährleistet sein. SOAP-Nachrichten können verschlüsselt und signiert werden. Auch der Einsatz von Zertifikaten ist möglich. Die Sicherheitsinfrastruktur der Web Services gründet auf etablierten Standards, z.B. XML Signature und XML Encryption. Web Services sind mehr als ein Standard für lose gekoppelte Dienste. Mit der Web-Services-Architektur hat das World Wide Web Consortium (W3C) eine ganze Reihe von Standards definiert, die in ihrer Gesamtheit eine verteilte und sichere Infrastruktur zur Verfügung stellen. Dieser umfassende Ansatz hat dafür gesorgt, dass

7.4 Standards für Integration

Nachrichten

Dienstebeschreibungen

Prozesse

Sicherheit

Web Services in der Praxis

■ ■ ■

207

Web Services auch in der Praxis eine Rolle spielen. So bietet z.B. Amazon einen Web Service für die Recherche im Katalog und die Bestellung von Artikeln an (www.amazon.com/webservices).

7.4.2 J2EE Connector Architecture (JCA) Die J2EE Connector Architecture (JCA) ist Bestandteil der Java 2 Enterprise Edition (J2EE), einer Plattform aufeinander abgestimmter Spezifikationen zur Implementierung serverseitiger Dienste. Innerhalb dieses Konzerts von Java-Standards übernimmt JCA die Rolle der Integration mit Unternehmens-Informationssystemen (Enterprise Information Systems, EIS). Die Bandbreite solcher Systeme reicht vom Legacy-System (dem klassischen „Host“) über die Riege der Enterprise Resource Planning-Systeme (z.B. SAP, PeopleSoft) und beliebige (auch nicht-relationale) Datenbanken bis hin zu speziellen Backend-Systemen. Die technische Schnittstelle zwischen dem J2EE-Applikationsserver und dem zu integrierenden System bildet der Resource Adapter. Diese Softwarekomponente wird für jedes System spezifisch entwickelt und implementiert die von der JCA vorgegebene Schnittstelle. Damit können J2EE-Applikationsserver oder beliebige andere JCA-Clients (so z.B. auch Portalsysteme) die Funktionalität beliebiger Drittsysteme ohne Kenntnis der proprietären Schnittstellen ansprechen – sie kommunizieren lediglich über die JCA-Standardschnittstelle. Die aktuelle Version 1.5 der JCA ist Bestandteil der J2EE 1.4Spezifikation. Sie bietet die benötigte Funktionalität für die performante, skalierbare und nachrichtenbasierte Integration von Unternehmens-Informationssystemen. Die Kommunikation kann wahlweise synchron oder asynchron erfolgen. Zudem können die Funktionen der via JCA integrierten Systeme den Klienten als Web Services zur Verfügung gestellt werden.

7.5 Standards für Portaltechnik Der Trend zur offenen Standardisierung technischer Schnittstellen begann in der Informationstechnologie erst vor wenigen Jahren und ist seitdem ungebrochen. Kein Wunder, denn die Vorteile (Austauschbarkeit von Komponenten, Anbindung von Fremdsystemen, Entwicklung von Bausteinen und Werkzeugen für Konkurrenzprodukte) überwiegen gegenüber dem vermeintlichen Nachteil, die produkteigenen Alleinstellungsmerkmale aufzugeben

208

■ ■ ■

7 Standards

dukteigenen Alleinstellungsmerkmale aufzugeben und damit an Marktmacht einzubüßen. Nicht selten geht die Initiative für die Standardisierung technischer Konzepte sogar von den Herstellern selbst aus: Für seine Programmiersprache Java hat Sun Microsystems einen formalen Standardisierungsprozess ins Leben gerufen. Im Rahmen dieses Java Community Process (JCP; www.jcp.org) entstehen Erweiterungen für Java, die zum Teil sogar in den Standard-Sprachumfang aufgenommen werden. Auch die Definition des Sprachkerns und der Basis-Editionen findet im Rahmen dieses Prozesses statt und steht somit grundsätzlich allen Interessierten offen. Dass diese Standards vom Markt akzeptiert werden, zeigt der Markt der Webapplikationsserver. Die entsprechenden Produkte der führenden Hersteller folgen dem J2EE-Standard (Java 2 Enterprise Edition). Softwarehersteller, deren Programme gemäß diesem Standard entwickelt wurden, werden in die Lage versetzt, ihre Softwareprodukte ohne Anpassungen für alle J2EE-kompatiblen Applikationsserver anzubieten. Und Softwareentwickler und Administratoren, die diesen Standard beherrschen, können (zumindest theoretisch) mit den Applikationsservern dieser Hersteller arbeiten, ohne sich jedes Mal einarbeiten zu müssen. Tatsächlich unterscheiden sich die Applikationsserver in den Details der Umsetzung verschiedener Aspekte des Enterprise JavaBeans (EJB)-Standards sowie in den Administrationswerkzeugen. Deshalb ist immer eine gewisse Einarbeitungszeit notwendig. Eine ähnliche Entwicklung erhofft man sich auch für den PortletStandard, der die Portalanwendungen verschiedener Portalserver zueinander kompatibel machen soll. Neben dem JCP gibt es weitere Standardisierungsprozesse und Gremien, die sich um die Harmonisierung der Informationstechnologie im Allgemeinen und der Portale im Speziellen verdient machen. Zu diesen gehört auch das Herstellerkonsortium OASIS (Organization for the Advancement of Structured Information Standards). Mit den Web Services for Remote Portlets (WSRP) hat dieses Konsortium einen weiteren Standard vorgestellt, der eine Integration von Portlets ermöglichen soll, die auf entfernten Servern von Portlet-Diensteanbietern implementiert sind (vgl. Abschnitt 7.5.2). Beide Standards – Portlet Specification und WSRP – sind erst im Jahr 2003 verabschiedet worden. Trotzdem haben die namhaften Portalsystemhersteller die Standards bereits heute in ihre Produkte integriert.

7.5 Standards für Portaltechnik

Java Community Process (JCP)

OASIS

■ ■ ■

209

7.5.1 Portlets Portalanwendungen dienen dazu, in einem zugewiesenen Bereich innerhalb der Portalseite Inhalte aus unterschiedlichen Systemen und Datenquellen eines Unternehmens benutzergerecht, personalisiert und prozesszentriert darzustellen (vgl. Koschek 2003). Je nach Portalsystemhersteller werden diese Komponenten als „iViews“, „Gadgets“, „Connectors“ oder „Portlets“ bezeichnet. So verschieden die Namen, so unterschiedlich sind auch die Programmierschnittstellen, die sich dahinter verbergen. Die Folge: Portalanwendungen, die für das Portalsystem eines Herstellers entwickelt wurden, können in der Regel nicht in dem Portalsystem eines anderen Herstellers ablaufen. Sowohl den Betreibern von Unternehmensportalen als auch den Herstellern von Portalsystemen und Portalanwendungen entstehen daraus schwerwiegende Nachteile. So kann sich ein Unternehmen bei der Softwareauswahl eines Portalsystems nicht allein auf die Charakteristika der Portalsoftware sowie deren Eignung für die Integration in die IT-Systemlandschaft des Unternehmens konzentrieren. Vielmehr müssen die für das fragliche System verfügbaren Portalanwendungen analysiert und am Katalog der fachlichen Anforderungen für das Unternehmensportal gemessen werden. Was nützt schließlich das beste Portalsystem, wenn die benötigte fachliche Funktionalität nicht gegeben ist und erst zeit- und kostenaufwendig implementiert werden muss? Die Hersteller von fachlichen Portalanwendungen haben auf der anderen Seite das Problem, dass sie ihre Anwendung für jedes Portalsystem spezifisch implementieren müssen, um möglichst viele Abnehmer für ihre Anwendung finden zu können. Viele Hersteller scheuen aber die Entwicklung paralleler Versionen für verschiedene Portalsysteme, da der Entwicklungsund vor allem der Wartungsaufwand zu hoch ist. Wein&Dein hatte in seinen ersten Webauftritt einen WeinInformationsdienst integriert. Zwei Mitarbeiter publizierten dort aktuelle Informationen und Kurznachrichten aus der Welt des Weines. Dieser Dienst wurde von den Kunden gut angenommen, wie die hohe Anzahl an Registrierungen für den begleitenden E-Mail-Dienst bewies. Von diesem Erfolg beflügelt, wollte man den Nachrichtendienst anderen Online-Anbietern von Wein und Lifestyle-Produkten als Produkt anbieten. Dazu ließ man eine entsprechende Portalanwendung (ein „iView“) für das SAP Enterprise Portal entwickeln. Als man schließlich mit dem Vertrieb dieses iViews begann, musste man leider feststellen, dass nur wenige potenzielle Kunden ein SAPPortal besaßen. Alle Kunden mit anderen Portalsystemen konnten

210

■ ■ ■

7 Standards

das iView nicht einsetzen – selbst wenn sie wollten. Aus diesem Grund wurde diese Idee nicht weiterentwickelt. Die Hersteller von Portalsystemen, die häufig selber eine große Anzahl an Portalanwendungen für ihr eigenes System anbieten, hatten zunächst schlichtweg kein Interesse, ihre Anwendungen für die Konkurrenzprodukte verfügbar zu machen. Die Kunden forderten aber zunehmend eine Kompatibilität dieser Anwendungen, und nicht wenige warteten mit der Kaufentscheidung für ein Portalsystem, bis die Frage nach der Harmonisierung der Anwendungen beantwortet war. Diese Zurückhaltung der Kunden mag einer der Gründe gewesen sein, warum sich im März 2002 achtzehn namhafte Softwarehersteller zusammenschlossen, um unter der Führung von Sun und IBM im Rahmen des Java Community Process eine Spezifikation für Java-Portlets zu schaffen, genannt Java Specification Request (JSR) 168: Portlet Specification (vgl. Abdelnur u. Hepper 2003). Dieser Standard, im Oktober 2003 verabschiedet, wurde schnell in die meisten Portalsysteme integriert, wobei die neue, standardisierte Programmierschnittstelle der alten zunächst zur Seite gestellt wurde. Nur so kann sichergestellt werden, dass die alten, proprietären Portalanwendungen weiterhin lauffähig sind. Es gibt aber noch einen anderen Grund für die Dualität der APIs: Dem Standard fehlen noch einige marktrelevante Konzepte, die allerdings zum Teil in späteren Versionen der Spezifikation Einzug halten sollen. So ist z.B. die Inter-Portlet-Kommunikation noch nicht standardisiert, weshalb Portlets derzeit noch nicht miteinander in Verbindung treten können. Deshalb setzt z.B. SAP weiterhin auf die hauseigene iViewTechnologie, unterstützt aber parallel den Portlet-Standard. Es bleibt abzuwarten, ob der Standard den Anforderungen aus der Praxis möglichst schnell gerecht werden kann. Die erste Version legt aber auf jeden Fall eine solide und umfassende Grundlage und erlaubt die Implementierung umfangreicher, kompatibler Portalanwendungen. Die technischen Details der Portlet-Spezifikation sprengen den Rahmen dieses Buchs – der interessierte Leser findet bei Koschek (2004) eine Abhandlung der wesentlichen Konzepte und Techniken dieses Standards. Wir wollen uns hier auf die Beschreibung der konzeptuellen Komponenten beschränken, wie sie in Abb. 7.5 dargestellt sind.

7.5 Standards für Portaltechnik

Die Historie des PortletStandards

■ ■ ■

211

Abb. 7.5 Portalarchitektur im Sinne der Portlet-API (JSR 168)

Portalseite

Portlet-Fenster

Portlet-Fenster

Fragment

Fragment

Servlet-Container

Servlet-API

(Web-Applikationsserver)

PORTAL Portalinfrastruktur

Portal-Webapplikation

Benutzerverwaltung

Portalserver (Servlet)

Persistenter und transienter Portlet-Zustand

Portlet-Applikation Portlet

Portlet

Portlet

Portlet-API (Kontext)

Portlet-API (Aufruf)

Portlet-Container

Vorteile des PortletStandards

212

■ ■ ■

Portlets sind in einem Container angesiedelt, der ihnen eine Ablaufumgebung bietet und für die Kommunikation mit dem Portalsystem, d.h. dem Portalserver, verantwortlich ist. Der Portalserver wiederum koordiniert den Aufbau der Portalseite im Browser des Portalbenutzers. Zudem leitet er die Anfragen des Benutzers an den Portlet-Container weiter, der diese wiederum dem betroffenen Portlet zustellt. Innerhalb der Portalseite erhält jedes Portlet einen bestimmten Bereich zugewiesen, innerhalb dessen es seine Inhalte darstellen kann. Dazu schickt es die Inhalte auf Anforderung als sogenanntes Fragment an den Portlet-Container. Diese Fragmente werden im Portalserver gegebenenfalls mit Fensterrahmen und ähnlichen Darstellungselementen dekoriert und in die Portalseite eingebaut. Diese klare Trennung der Verantwortlichkeiten zwischen Portalserver und Portlet-Container ist eine der wesentlichen Errungenschaften des Portlet-Standards, trägt sie doch wesentlich zur Modularisierung von Portalsystemen bei. Das wiederum vereinfacht den Austausch einzelner Komponenten. Mit Hilfe des Portlet-Standards können Portalanwendungen in allen kompatiblen Portalsystemen ablaufen. Die Kunden solcher Anwendungen finden ein größeres Portlet-Angebot vor, und die Anbieter derartiger Portlets sehen sich vom Problem der Parallelentwick-

7 Standards

lung und Pflege für proprietäre Portalsysteme befreit. In unserem Beispiel könnte Wein&Dein ein Portlet für einen WeinNachrichtendienst entwickeln, das sich einfach in ein Portal integrieren lässt. Allerdings müsste ein solches Portlet regelmäßig mit den Nachrichten versorgt werden. Auch ist die Aktualisierung (Update) der Portletanwendung aufwendig, da alle Kunden mit der neuen Version versorgt werden müssen. Genau betrachtet, ist es nicht das Portlet, an dem der Kunde interessiert ist, sondern die WeinInformationen, die über dieses Portlet zur Anzeige gebracht werden. Dienstleistungen dieser Art werden heute über Web Services angeboten (vgl. Abschnitt 7.4.1). Basierend auf diesen Web Services wurde ein weiterer Standard definiert, der die „Fernbedienung“ von Portlets erlaubt. Dieser Standard soll im folgenden Abschnitt näher betrachtet werden.

7.5.2 Web Services for Remote Portlets (WSRP) Während die „klassischen“ Web Services eine standardisierte funktionsorientierte Schnittstelle für verteilte Dienste im Netzwerk definieren, liegt der Schwerpunkt der Web Services for Remote Portlets bei den interaktiven, präsentationsorientierten Diensten. Der WSRPStandard besteht im Wesentlichen aus drei Komponenten: ■

Einer Aufrufschnittstelle für WSRP-Dienste. Diese bedient sich der Web Services Description Language (WSDL).

■

Regeln für die Interaktion mit WSRP-Diensten, die sich nicht über die WSDL ausdrücken lassen.

■

Regeln für die Struktur der Daten, die von WSRP-Diensten erzeugt und an deren Klienten gesandt werden. Diese Datenstrukturen werden als „Fragmente“ bezeichnet, da sie i.d.R. eine Teilmenge der im Klienten (z.B. ein Portal) aggregierten Informationen darstellen.

Bei der WSRP-Kommunikation spielen drei verschiedene Akteure eine Rolle. Da ist zunächst das Portlet selbst, das gewisse (präsentationsorientierte) Dienste anbietet. Die Charakteristika der WSRPPortlets entsprechen nicht von ungefähr dem im vorigen Abschnitt beschriebenen Portlet-Standard – hier zeigt sich, dass die Standardisierungsgremien beider Standards eng zusammengearbeitet haben. Ein Portlet bietet selber keine Web Service-Schnittstelle. Deshalb wird es im WSRP-Szenario in einen Produzenten (Producer) einge-

7.5 Standards für Portaltechnik

WSRPKomponenten

WSRP-Akteure

■ ■ ■

213

bettet, der einen Web Service-kompatiblen Dienst darstellt. Ein Produzent kann mehrere Portlets anbieten. Die Nutzer eines solchen Dienstes werden als Konsumenten (Consumer) bezeichnet. Ein typischer Konsument ist ein Portal, das die von den Portlets eines Produzenten angebotenen Fragmente in die Portalseite aggregiert. Die Fragmente können natürlich auch von anderen Applikationen verarbeitet werden – dafür wird der Standard in der kommenden Version 1.1 neben (X)HTML weitere Formate für die Fragmente anbieten, z.B. WML oder Voice XML. Abb. 7.6 Konstruktion einer Portalseite aus WSRPgenerierten Fragmenten

Portalseite

Portlet-Fenster

Portlet-Fenster

Fragment

Fragment

Portal

Vorteile von WSRP

214

■ ■ ■

Fragment

Fragment

Fragment

WSRPDienst

WSRPDienst

WSRPDienst

Abbildung 7.6 zeigt, wie die Fragmente eines WSRPkompatiblen Portlets zur Portalseite eines Benutzers gelangen. Der große Vorteil des WSRP-Standards gegenüber der Javabasierten Portlet-API ist dessen Sprach- und Plattformunabhängigkeit. Er vermag verschiedene, unter Umständen plattformspezifische Portlet-Schnittstellen zu kapseln und den Konsumenten gegenüber als standardisierte, plattformunabhängige Dienste anzubieten. Zudem ist die Integration von Sicherheitsmechanismen und -standards Bestandteil der Spezifikation. Ähnlich wie bei der PortletSpezifikation hat das WSRP-Standardisierungsgremium einige wichtige Konzepte für die Folgeversionen des Standards aufgehoben – so auch die bereits erwähnte Inter-Portlet-Kommunikation. Diese könnte sich als „Killer-Kriterium“ für die Akzeptanz der beiden

7 Standards

Standards erweisen und für die endgültige Ablösung der alten, proprietären Schnittstellen sorgen.

7.6 Standard für Portalinhalte: RSS Bei der Beschreibung von XML haben wir bereits darauf hingewiesen, dass für einige Fachdomänen bereits standardisierte XMLbasierte Sprachen existieren. Einer dieser Standards, der insbesondere in Informationsportalen zunehmend Verwendung findet, soll hier stellvertretend vorgestellt werden: RSS. Betrachtet man die Internetseiten (bzw. Portale) von Nachrichtendiensten, Fernsehsendern, Tageszeitungen und Zeitschriften, so wird man dort immer häufiger das Kürzel „RSS“ finden. Ursprünglich von Netscape entwickelt, um Nachrichten im (hauseigenen) Portal zu publizieren, hat es sich mittlerweile als Standard etabliert. Eigentlich handelt es sich um eine Sammlung von Standards, denn es gibt verschiedene RSS-Versionen, die alle noch im Einsatz sind (vgl. Tabelle 7.1). Version

Eigner

Beschreibung

0.90

Netscape

0.91

UserLand

0.92 0.93 0.94 1.0

UserLand

Ausgangsformat auf Basis des Resource Description Framework www.w3.org/RDF/ Sehr einfaches Format Spiegel, Computerwoche Basiert auf RSS 0.91; Presseportal umfangreichere Metadaten Basiert auf RSS 0.90; N24 modulares Konzept auf RDF-Basis Basiert auf RSS 0.91; NETZEITUNG modulares, flexibles Konzept

2.0

RSS-DEV Working Group UserLand

Verwendung im World Wide Web Tagesschau, Heise Newsticker

Man kann dennoch von einem Standard sprechen, da sich die Formate inhaltlich sehr ähneln. Sie sind allesamt XML-Formate und definieren Nachrichtenkanäle (Channels) mit Informationsobjekten (Items). Diese Objekte haben mindestens einen Titel, einen Verweis (URL) auf die eigentliche Nachricht (Link) und einen beschreiben-

7.6 Standard für Portalinhalte: RSS

Tabelle 7.1 RSS-Versionen

Sieben Formate – ein Standard

■ ■ ■

215

den Text (Description). Neuere RSS-Versionen erlauben die Angabe weiterer Informationen, z.B. Autor oder Datum. Da die grundlegenden Attribute allen Versionen des RSS-Formats gemein sind, lassen sie sich ineinander überführen. Bei der Übersetzung von einer neueren in eine ältere Version können allerdings Informationen verloren gehen. Listing 7.9 Ausschnitt aus einem RSS 0.91-Feed

COMPUTERWOCHE ONLINE http://www.computerwoche.de

de-de 2004 Computerwoche

http://www.computerwoche.de/img/logo.gif

Logo Computerwoche Online http://www.computerwoche.de

Itellium-Deal ist 1,2 Milliarden Euro wert Atos Origin und KarstadtQuelle haben Einzelheiten ihres Outsourcing-Abkommens genannt. Danach beläuft sich der Wert der Vereinbarung auf mehr als 1,2 Milliarden Euro. Bei einer Laufzeit von acht Jahren [...]

http://www.computerwoche.de/index.cfm? pageid=254&type=detail&artid=65071& linktype=rss

[...]

[...] Listing 7.10 Ausschnitt aus einem RSS 2.0Feed

216

■ ■ ■

NETZEITUNG.DE http://www.netzeitung.de

Aus Prinzip schneller

de

7 Standards

NETZEITUNG.DE

http://www.netzeitung.de/image/nzprint.gif

http://www.netzeitung.de

New Yorker gedenken am Ground Zero der Opfer der Anschläge vom 11. September 2004-09-11T18:32:51+02:00

New York gedenkt mit einer Trauerfeier der Opfer der Anschläge auf das World Trade Center. Präsident Bush nahm an einer Schweigeminute im Weißen Haus teil.

http://www.netzeitung.de/ausland/ 304592.html

[...]

[...] Listing 7.9 zeigt einen Ausschnitt aus einem RSS-Datenstrom (www.computerwoche.de/rss/news.xml), wie ihn die OnlineVersion der Computerwoche liefert. Listing 7.10 zeigt zum Vergleich den RSS 2.0-Datenstrom der NETZEITUNG (www.netzeitung.de/export/news/rss/titelseite.xml). Diese Datenströme können ohne großen Aufwand in das eigene Portal integriert werden – entsprechende Nutzungsbestimmungen vorausgesetzt. Weiterer Vorteil: Dank des geringen Datenumfangs und des Verzichts auf Grafiken eignet sich das RSS-Format auch für die Darstellung auf mobilen Endgeräten (WAP-Mobiltelefon, PDA). Der Erfolg gibt dem RSS-Format Recht: Nach Angaben von syndic8 (www.syndic8.com) werden derzeit (Stand: April 2005) rund 370.000 RSS-Datenströme über das Internet angeboten – Tendenz stark steigend. Zum Vergleich: Im September 2004 zählte syndic8 ca. 150.000 RSS-Datenströme. Wenngleich die meisten dieser Datenströme aus Online-Tagebüchern (Weblogs) stammen, so entdecken doch immer mehr Verlage und Nachrichtenagenturen das Marketingpotenzial von RSS. Der Datenstrom transportiert den Titel und eventuell einen Anreißer der Nachricht zu den Lesern. Zum Lesen des kompletten Artikels muss aber die Webseite des Anbieters ange-

7.6 Standard für Portalinhalte: RSS

■ ■ ■

217

steuert werden – und das ist schließlich das Ziel der Betreiber von Webseiten.

7.7 Standard für Prozesse: WfMC Workflow Reference Model Geschäftsprozesse werden technisch durch einen Workflow unterstützt. Workflow-Management-Systeme (WfMS) dienen der Modellierung, Implementierung, Simulation, Ausführung, Steuerung und Analyse dieser Workflows. Ähnlich wie die Portalsysteme krankt der Markt der Workflow-Management-Systeme an deren Inkompatibilität. Aus diesem Grund wurde 1993 die Workflow Management Coalition (WfMC) gegründet. Deren primäres Ziel war (und ist) die Schaffung eines Referenzmodells für ein WfMS. Dieses Modell ist nur einer in einer Reihe von Workflowstandards der WfMC, die derzeit aber nur in Teilen verabschiedet sind. Im Workflow Reference Model wird der Aufbau eines WfMS definiert. Dieses ist in drei funktionale Bereiche aufgeteilt, die dem Erstellen, Betreiben und Kontrollieren eines Prozesses dienen. Die Kommunikation mit dem WfMS läuft über eine der im Workflow Reference Model beschriebenen und in Abbildung 7.7 dargestellten Schnittstellen (Interfaces). Von diesen ist allerdings nur das Interface 4 bisher verabschiedet. Für Interface 2 existiert immerhin ein Vorschlag, die anderen Schnittstellen befinden sich noch in der Entwicklung. Abb. 7.7 Die Schnittstellen des Workflow Reference Model (Quelle: Hollingsworth 1995)

218

■ ■ ■

7 Standards

Das Process Definition Interface (1) dient der Anbindung des Modellierungswerkzeugs an die Workflow Engine. Es definiert das Datenformat für den Austausch der Prozessdefinition und die Funktionsaufrufe der Workflow API. Das Workflow Client Applications Interface (2) definiert die Schnittstelle zwischen der Workflow Engine und den Clients. Damit ist es möglich, workflowunterstützte Applikationen zu entwickeln, die mit beliebigen (standardkompatiblen) WfMS zusammenarbeiten können. Das Invoked Applications Interface (3) regelt die Integration externer Applikationen, die aufgrund bestimmter Workflowereignisse aufgerufen werden sollen. So kann z.B. ein Workflow das Versenden einer E-Mail beinhalten. Die E-Mail-Clientsoftware wäre eine solche externe Applikation. Das Other Workflow Enactment Services Interface (4) standardisiert die Kommunikation zwischen WfMS, damit diese z.B. Prozessdefinitionen untereinander austauschen können. Schließlich kümmert sich das Administration & Monitoring Tools Interface (5) um die Einbindung des WfMS in die IT-Administrations- und Überwachungswerkzeuge. Derzeit gibt es kein kommerzielles WfMS-Produkt, das alle Aspekte des Standards unterstützt. Es werden nur einige der definierten Schnittstellen gemäß den Empfehlungen des Standards umgesetzt. Es werden jedoch zunehmend Verbindungen geknüpft von etablierten Modellierungssystemen wie ARIS zu den Workflowsystemen, z.B. von Staffware oder SAP. Bei den Open Source-Projekten sieht es anders aus. Diese konzentrieren sich vornehmlich auf die Implementierung eines Moduls (z.B. Workflow Engine, Modellierungswerkzeug oder Administrationswerkzeug) und die entsprechende Standard-Schnittstelle. Es besteht also die berechtigte Hoffnung, dass in Zukunft eine Kombination von Open Source-Modulen einen wesentlichen Teil des WfMCReferenzmodells umsetzen wird. Dazu müssen die Schnittstellen dieses Modells allerdings noch exakter spezifiziert werden – derzeit besteht noch zu viel Freiraum für Interpretationen, was eine erfolgreiche Kommunikation der Komponenten in der Praxis erschwert. Berücksichtigt man ferner, dass nach zehn Jahren Arbeit der WfMC gerade einmal eine der fünf Schnittstellen verabschiedet ist, so ist es nicht verwunderlich, dass sich die Hersteller mit der Umsetzung dieser Standards noch Zeit lassen. Das ist wenig förderlich für die Weiterentwicklung des Standards. Die Integration eines WfMS in ein Unternehmensportal wird also auch zukünftig über proprietäre Schnittstellen erfolgen müssen. Weiterführende Informationen zur Standardisierung von WfMS im Rahmen der prozessbasierten Integration von Anwendungen sind bei Müller (2004) zu finden.

7.7 Standard für Prozesse: WfMC Workflow Reference Model

■ ■ ■

219

7.8 Standards für Content Management Auch für die Verwaltung der Inhalte von Unternehmensportalen (Content Management) gibt es Standards. Ein kurzer Überblick über derartige Standards schließt dieses Kapitel ab.

7.8.1 WebDAV Mit WebDAV (Web-based Distributed Authoring and Versioning) wird eine bereits 1991 von Tim Berners-Lee formulierte Vision Wirklichkeit, die den Austausch von Daten unabhängig von deren Aufenthaltsort beschreibt. Der WebDAV-Standard ermöglicht die kooperative Dokumentenpflege über das World Wide Web. Sowohl Menschen als auch Softwaresysteme können via WebDAV verändernd auf die Struktur oder den Inhalt von Dokumenten einwirken (vgl. Goland et al. 1999).

7.8.2 Content Repository for Java Technology API Mit dem Java Specification Request (JSR) 170 – Content Repository for Java Technology API – steht ein Java-Standard für den Zugriff von Softwareanwendungen auf Inhalte aller Art zur Verfügung (vgl. Nuescheler 2005). JSR 170 hat für Content-Management-Systeme eine ähnliche Bedeutung wie die Portlet-API (JSR 168) für Portalsysteme. So können in Zukunft alle standardkompatiblen Content Repositories über eine einheitliche Schnittstelle angesprochen werden – unabhängig davon, ob es sich um hierarchische oder nicht hierarchische Repositories handelt. Zwei Standardisierungsebenen garantieren die Verfügbarkeit der Grundfunktionen (Level 1), standardisieren darüber hinaus aber auch weitergehende Funktionen wie z.B. Transaktionen und Versionierung (Level 2). Allerdings muss sich noch zeigen, ob der Standard von den Herstellern der ContentManagement-Systeme akzeptiert und implementiert wird.

220

■ ■ ■

7 Standards

7.8.3 Topic Maps Charles Goldfarb, Mitglied der Arbeitsgruppe „XML Topic Maps“, bezeichnet Topic Maps als „GPS des Web“. Der Vergleich mit dem globalen Positionierungssystem ist treffend, denn Topic Maps dienen der Orientierung und Navigation in großen Informationsmengen. Neben der großen Menge an Daten ist es vor allem die Vielfalt der Formate, in denen die Informationen vorliegen. Dementsprechend sind die durch Topic Maps definierten Strukturierungskonzepte umfangreicher als z.B. der zweistufige Index dieses Buchs. Drei Elementtypen bilden die Grundlage der Topic Maps. Sie werden auch als TAO des Standards bezeichnet (vgl. Rath 2002): ■

Topics (Themen) spiegeln die Konzepte, Ideen, Objekte oder Dinge wider, über die eine Topic Map etwas aussagen soll. Ein Thema trägt einen oder mehrere Namen (Names).

■

Associations (Assoziationen) beschreiben die semantischen Beziehungen zwischen Themen.

■

Occurrences (Vorkommensangaben) verbinden die Themen mit Ressourcen (z.B. Dokumente, Bilder, Audio oder Video), die relevante Informationen zu dem Thema enthalten.

Wein&Dein setzt eine Topic Map zur Klassifizierung und Beschreibung der angebotenen Weine und zur Definition der hauseigenen Produkte ein. Ein Ausschnitt aus dieser Topic Map ist in Abb. 7.8 dargestellt. Die Produktzusammensetzung wird über „enthält“-Assoziationen abgebildet. Die Weine, Instanzen der Themenklasse „Wein“, werden z.B. durch die Angabe der Region klassifiziert. Die Region hat wiederum eine Beziehung zum Land. Mit diesen Informationen ließe sich z.B. eine hierarchische Navigation für das Wein&Dein-Portal, beginnend beim Land, automatisch generieren. Unter Nutzung der Vorkommensangaben können zu einigen Navigationselementen (z.B. der Region Gaillac) automatisch Inhalte präsentiert werden (in diesem Fall Informationen über die genannte Region und das Weinland Frankreich). Durch Kombination der Assoziationen mit den Vorkommensangaben lässt sich die Region Mosel-Saar-Ruwer mit einem Dokument über den Riesling verknüpfen. Dieses abgeleitete Wissen, das explizit nicht gespeichert ist, verdeutlicht das Potenzial der Topic Maps.

7.8 Standards für Content Management

■ ■ ■

221

Abb. 7.8 Topic Map zur Beschreibung der Wein&DeinProdukte

Produkt

Wein

Region

Herkunftsland

T

T

T

T

Probier/4 Mosel

2003 Zeltinger Sonnenuhr Riesling

Mosel-SaarRuwer

T

T

enthält

stammt aus

RegionalBox Südwestfrankreich

2000 Domaine des Terrisses

T

T enthält

Aktion »Moselwein«

Thema (Topic)

T

T

Instanz

Deutschland liegt in

T

Die Region Gaillac

Assoziation (Association)

T

Frankreich

Gaillac stammt aus

Der Riesling

Themenklasse

T

liegt in

T

Weine aus Frankreich

Vorkommensangabe (Occurrence)

Ressource

Die Anwendungsgebiete für Topic Maps sind vielfältig. Sie reichen von Wissensmodellierung für Knowledge-ManagementSysteme über Klassifikation von Textinhalten im Verlagsumfeld und Navigationshilfen für komplexe Webseiten bis hin zu Ontologien für intelligente Suchmaschinen (vgl. Rath 2002). Neben dem Resource Description Framework (RDF) sind Topic Maps zudem ein Kandidat für die Ontologiedefinition im Rahmen des Semantic Web. In diesem Internet der nächsten Generation sollen Programme und Applikationen intelligent miteinander kommunizieren können (siehe auch Abschnitt 13.3.4). Detaillierte Informationen zu Topic Maps finden Sie z.B. bei Widhalm und Mück (2002).

222

■ ■ ■

7 Standards

8 Das richtige System

Wie Sie im Kapitel 3 sehen konnten, haben verschiedene Unternehmen unterschiedliche Motive, sich mit dem Thema Unternehmensportale zu befassen. Die Strategie für die Einführung eines Unternehmensportals hängt wesentlich von der Größe des Unternehmens ab. Diese Abhängigkeit wird im Folgenden näher untersucht. Um das richtige System für das eigene Unternehmen definieren zu können, müssen die Anforderungen an ein solches Portalsystem bekannt sein. Aus diesem Grund macht der Prozess der Anforderungsanalyse einen wesentlichen Anteil eines Portalprojektes (und dieses Kapitels) aus. Abschließend beschäftigen wir uns mit den Kriterien zur Auswahl eines Portalprodukts und geben eine kurze und neutrale Übersicht über den Markt der Portalsoftware.

Kurz gefasst

8.1 Portale für jede Unternehmensgröße Wir unterscheiden im Folgenden vier Unternehmenskategorien anhand der Anzahl der (potenziellen) Nutzer eines Unternehmensportals. Unternehmenskategorie

Portalbenutzer

Kleines Unternehmen Mittleres Unternehmen Großes Unternehmen Konzern

1–50 50–500 500–5000 > 5000

Tabelle 8.1 Unternehmenskategorien

Die verschiedenen Anwendungsbereiche lassen sich natürlich nicht exakt einer bestimmten Unternehmensgröße zuordnen. Trotzdem wollen wir versuchen, einige typische Anwendungsszenarien für die unterschiedlichen Unternehmenskategorien zu entwerfen und so den spezifischen Nutzen eines Portals sichtbar zu machen.

8.1 Portale für jede Unternehmensgröße

■ ■ ■

223

8.1.1 Kleine Unternehmen

Projektkosten und erforderliches Know-how

Geringe Komplexität der Geschäftsprozesse

Geringer Integrationsbedarf

224

■ ■ ■

In der Praxis sind es noch eher selten die kleineren Unternehmen, die ein Portal nutzen oder von den Herstellern entsprechender Systeme als potenzielle Kunden beworben werden. Dies liegt natürlich zum einen an den prognostizierten Infrastruktur- und Projektkosten. Gerade kleine Unternehmen haben außerdem meist nicht das für die Durchführung eines Portalprojektes erforderliche interne IT-Know-how. Andererseits scheuen kleine Unternehmen die Investitionen in externe Berater- und Entwicklerstunden sowie Betriebskosten. Zum anderen liegt die geringe Relevanz des Portalthemas in kleineren Unternehmen daran, dass in Unternehmen dieser Größenordnung originäre Portalaufgaben und -funktionen von einfacheren Werkzeugen übernommen werden. Dies ist möglich, da in kleinen Unternehmen Geschäftsprozesse meist nicht so komplex sind wie in größeren Unternehmen. Es gilt nicht, eine Vielzahl von Abteilungsgrenzen zu überwinden, viele Mitarbeiter in die Prozesse einzubinden oder gar die Miteinanderarbeit über mehrere Standorte sicherzustellen. Die interne Unternehmenskommunikation lässt sich so z.B. durch ein klassisches Intranet oder einfach durch persönlichen Kontakt sicherstellen. E-Mail und sogenannte Personal Information Manager (PIM) können die Miteinanderarbeit im Unternehmen unterstützen, und Desktop-Anwendungen wie Textverarbeitungs- und Tabellenkalkulationsprogramme reichen aus, um Inhalte zu erstellen und zu verbreiten. Außerdem ist im Regelfall in kleinen Unternehmen der Integrationsbedarf nicht so hoch wie dies bei größeren Unternehmen der Fall ist. Kleine Unternehmen verfügen meist über eine überschaubare Anzahl von Anwendungen und Informationsquellen. Bedingt durch die geringe Anzahl von Anwendungen kann der Integrationsbedarf, um beispielsweise vollständige Kundenprofile zu erstellen oder Produktinformationen wie Verkaufszahlen und Einkaufskosten zusammenzustellen, ohne die Unterstützung spezialisierter EAI-Tools effizient über Punkt-zu-Punkt-Verbindungen umgesetzt werden. Dennoch gibt es auch bei den kleinen Unternehmen Beispiele von erfolgreichen Portaleinführungen, insbesondere im Dienstleistungsbereich. Wenn ein Portal hinreichend Mehrwerte für die Kernprozesse eines Unternehmens schafft, wird der Return on Investment (ROI) den Aufwand der Investitionen wert sein. Beispiele für derartige Anwendungsszenarien von Portaltechnologien sind:

8 Das richtige System

■

Der Bedarf, interne und externe Informationsquellen in einen Geschäftsprozess zu integrieren, wie dies z.B. bei PR-Agenturen der Fall ist.

■

Kleine Unternehmen, bei denen Informationen im Mittelpunkt stehen, wie z.B. Presseagenturen.

■

Die Nutzung einer großen Wissensbasis, die auf standardisierten Taxonomien basiert, wie z.B. im medizinischen oder rechtlichen Bereich.

Anwendungsszenarien in kleinen Unternehmen

Für dienstleistungsorientierte Unternehmen kann ein Portal ein einfacher Weg sein, um die Kunden in die eigenen Arbeitsabläufe zu integrieren. Als Beispiel mag hier eine Designagentur dienen, die mit ihren Kunden projektbezogen zusammenarbeitet. Für diese Zusammenarbeit werden Daten und Informationen aus verschiedenen Quellen benötigt und zwischen Kunden und einer weiterverarbeitenden Stufe ausgetauscht. Ein Unternehmensportal kann diese Aufgaben durch eine automatisierte Workflowsteuerung und einen OnlineDatenzugriff effektiv unterstützen und verbinden. An diesem Beispiel lässt sich bereits erkennen, dass ein Portal, das auch externe Nutzer adressiert, gerade für kleinere Unternehmen erhebliche Vorteile bringen kann. Ein Portal bietet die Möglichkeit, nach außen hin wie ein viel größeres Unternehmen aufzutreten und einer großen Zahl von Kunden personalisierte Dienstleistungen anzubieten. So lassen sich die Beschränkungen eines Unternehmens geringer Größe, wie z.B. keine kundennahen Niederlassungen, nur wenige Support-Mitarbeiter und kein eigenes Call Center, überwinden. Die Investition in ein Portal muss für Unternehmen jeder Größe einen klaren und berechenbaren Nutzen erbringen, der ohne dieses technische Hilfsmittel so nicht zu erreichen gewesen wäre. Dieser Nutzen rechtfertigt die Investition in ein Portal und wird die verursachten Kosten über die Laufzeit des Portals direkt oder indirekt amortisieren. Mit dem Wachstum des Portalmarkts wird sich auch das Angebot an Hosting-Lösungen für Portale vergrößern. So wird es auch für kleinere Unternehmen leichter, ein Portal zu betreiben und damit einen schnellen ROI zu erzielen.

8.1 Portale für jede Unternehmensgröße

Instrument zur Kundenansprache

Nutzen rechtfertigt Investition

■ ■ ■

225

8.1.2 Mittlere Unternehmen Miteinanderarbeit

Verstreute Unternehmensinformationen

Unterstützung durchgängiger Geschäftsprozesse

Kundenmehrwert

Integration von Geschäftspartnern

226

■ ■ ■

Für mittlere Unternehmen stellt die Miteinanderarbeit einen wichtigen Aspekt dar. Oftmals sind in Unternehmen dieser Größe Prozesse und Mechanismen für die Kernkompetenzen des Unternehmens nicht definiert und unterstützt. Die Standardisierung und Überwachung der Geschäftsprozesse spielt aber insbesondere in Organisationen, die über mehrere Standorte verteilt sind, eine immer entscheidendere Rolle – gerade wenn im täglichen Geschäft verschiedene Abteilungen innerhalb des Unternehmens zusammenarbeiten müssen. Bereits in Unternehmen mittlerer Größe ist oftmals eine kritische Menge an verschiedenen Informationstypen und Datenformaten erreicht. Unternehmensportale können in diesem Fall den Single Point of Access zu den verstreuten Unternehmensinformationen darstellen und die Informationen für den Benutzer strukturiert und recherchierbar darstellen. Der Mehrwert des Portals wird noch erhöht, indem andere informationsverarbeitende Applikationen in das Portal integriert werden und zusätzliche Funktionen, wie das Publizieren von Geschäftsberichten oder das Ermitteln von Kennzahlen zur Entscheidungsfindung, ergänzt werden. Viele dieser Unternehmen haben eine Vielzahl von Systemen, die ihre Geschäftsprozesse unterstützen. Selbst wenn diese von einem einzigen Hersteller stammen, ist es doch selten der Fall, dass all diese Systeme vollständig integriert sind. Prozessmanagement- und Workflow-Lösungen können auf der Prozessebene eine Integration ermöglichen, indem sie die Applikationen miteinander verketten. Werden über das Portal auch Mehrwerte für die Kunden des Unternehmens geschaffen, kann ein Portal das ideale Werkzeug für mittlere Unternehmen sein, um sich über Servicequalität, einen hohen Grad der Auskunftsfähigkeit und kurze Reaktionszeiten einen Vorsprung vor der (größeren) Konkurrenz zu sichern. Unternehmen mittlerer Größe nutzen außerdem oftmals Portaltechnologien, um Lieferanten und Geschäftspartner über einen kontrollierten Zugang an ihre internen Systeme anzubinden. Dies funktioniert überall dort, wo enge Beziehungen zu Geschäftspartnern bestehen und wo regelmäßig geschäftliche Informationen ausgetauscht werden. Auch wenn zum heutigen Zeitpunkt große Portallösungen für mittelständische Unternehmen noch nicht geeignet erscheinen, werden mit der Entwicklung der Werkzeuge und Standards in den nächsten Jahren derartige Funktionen auch für Unternehmen dieser Größe praktikabel und sinnvoll einsetzbar sein.

8 Das richtige System

8.1.3 Große Unternehmen Große Unternehmen haben typischerweise eine Vielzahl von Informationen in unterschiedlichen Formaten, die zum Teil auch noch physikalisch über mehrere verschiedene Systeme verteilt sind. Diese Informationen, das gesammelte Wissen der Organisation, ist wohl die wertvollste Ressource, die das Unternehmen besitzt. Umso mehr ist ein Unternehmensportal ein unverzichtbares Werkzeug, um Informationen zu verwalten, zu verteilen und bekannt zu machen. Ein Unternehmensportal verbessert dadurch die Miteinanderarbeit innerhalb des Unternehmens. Es spielt eine entscheidende Rolle, wenn es darum geht, die Ressource Wissen gewinnbringend zu erschließen. Ein Portal sollte deshalb als Wissensnetzwerk benutzt werden. Es ist die Basis eines strukturierten Wissens- und Informationsaustauschs in komplexen Organisationen. Eine Gruppe von Individuen sammelt Wissen und Informationen, die wiederum von anderen Individuen genutzt und für ihre eigene Arbeit adaptiert werden können. Dieses Netzwerk sollte die Möglichkeit bieten, das Wissen des Unternehmens transparent und auffindbar zu machen, und eine Plattform für die Erzeugung von Wissen, Kommunikation und Miteinanderarbeit sein. In unserem heutigen Informationszeitalter sind die Funktionen eines Knowledge Managements entscheidend für die erfolgreiche Arbeit eines Unternehmens. Über Such-, Navigations- und Kategorisierungswerkzeuge wird dieses Wissen für den Benutzer auffindbar. Ein Portal unterstützt die Ablage und Verteilung von Informationen, so dass neue interne oder externe Quellen in den bestehenden Wissensspeicher integriert werden können und diesen aktuell halten. Ein Portal unterstützt außerdem Manager dabei, sicherzustellen, dass wichtige Informationen, wie z.B. ein Geschäftsbericht, ein Produktionshinweis oder eine wichtige Neuigkeit schnell dann vorhanden sind, wenn sie benötigt werden. Neben seiner Aufgabe als Basis des Wissensaustauschs in einem großen und lokal weit verzweigten Unternehmen, stellt ein Portal in Organisationen dieser Größenordnung ein wichtiges ManagementInformationssystem dar. Informationen über Geschäftsprozesse, die sich über Anwendungs- und unter Umständen sogar Unternehmensgrenzen hinweg erstrecken, und andere geschäftskritische Daten lassen sich einfach und zeitnah ermitteln. Diese Daten spielen gerade bei großen Unternehmen, bedingt durch ihre juristische Geschäftsform, eine besondere Rolle. Sie ermöglichen außerdem, das Unternehmen gegenüber Anteilseignern gegen die Mitbewerber abzugrenzen oder unternehmerische Entscheidungen (z.B. über Outsourcing

8.1 Portale für jede Unternehmensgröße

Erschließen des Wissens

ManagementInformationssystem

■ ■ ■

227

Mobiler Informationszugriff

Integration

bestimmter Unternehmensteile) zu treffen. Ein Portal wird so zu einem wichtigen Managementwerkzeug, das bei strategischen Entscheidungen unterstützt und eine stete Berichtsfähigkeit über die Kennzahlen des Unternehmens ermöglicht. Gerade bei weit verzweigten Organisationen mit einem überregionalen Einsatz von Beratern oder Außendienstmitarbeitern spielt der mobile und plattformunabhängige Zugriff auf die Unternehmensdaten eine besondere Rolle. Über einen Browser werden Anwendungen und interne IT-Ressourcen für die Mitarbeiter von prinzipiell jedem Standort der Welt aus zugreifbar. Ein mobiler Zugang (z.B. per Mobiltelefon oder PDA) auf die für die jeweilige Tätigkeit erforderlichen Daten kann darüber hinaus für den Außendienst neue Potenziale eröffnen und helfen, Zeit und Kosten zu sparen. Abschnitt 4.8 beschreibt ein Beispiel für einen solchen Anwendungszweck. Die Einkäufer von Wein&Dein greifen über ihre Mobiltelefone auf das Portal zu und rufen dort die für ihre Vertragsverhandlungen relevanten Informationen ab. Für die beschriebenen Aufgaben ist eine an den Geschäftsprozessen und konkreten Aufgaben der Nutzer orientierte Integration der unterschiedlichen Unternehmensanwendungen nötig. Die Fähigkeit, die verschiedenen Systeme und Anwendungen innerhalb eines Unternehmens unterstützen zu können, ist somit das entscheidende Kriterium bei der Auswahl einer Portallösung. Große Unternehmen sollten die Einführung eines Portals für Kunden, Lieferanten und Partner sowohl als Fundament für EBusiness-Applikationen sowie als Kollaborationswerkzeug betrachten. Um diese Anforderungen zu erfüllen, muss zum einen das Portal auf einer stabilen und skalierbaren Plattform aufsetzen, zum anderen müssen Portalarchitektur und -anwendungen sorgfältig konzipiert sein. Um ein Portal erfolgreich einzuführen und einen schnellen ROI zu erwirtschaften, muss es dem Unternehmen außerdem gelingen, die Veränderungen in der Kultur und den Geschäftsprozessen innerhalb des Unternehmens zu kommunizieren und zu etablieren.

8.1.4 Konzerne Etablierung von Unternehmensstandards

228

■ ■ ■

Viele der Anwendungen eines Unternehmensportals, die für einen Einsatz in großen Unternehmen sinnvoll sind, lassen sich natürlich auch auf Konzerne adaptieren. Darüber hinaus bieten Unternehmensportale Konzernen eine exzellente Möglichkeit, gemeinsame Standards auch über geographische und kulturell unterschiedliche Unternehmensteile hinweg einzuführen. Dies spielt gerade im Hin-

8 Das richtige System

blick auf globale Übernahmen und Fusionen eine nicht zu unterschätzende Rolle. Die Fähigkeit eines Portals, Informationen aus unterschiedlichen Quellen zu kombinieren und Unternehmensstandards über alle Bereiche des Unternehmens zu verbreiten, stellt in diesem Zusammenhang einen besonderen Wert dar. Ohne die Vereinheitlichungen und Vereinfachungen, die ein Portal bietet, ist dieses Unterfangen fast unmöglich. Konzerne haben oftmals eigene Abteilungen, die sich mit dem Corporate Branding, der internen Unternehmenskommunikation sowie der Pflege und Entwicklung der Unternehmenskultur befassen. Der Einsatz eines Portals kann diese Abteilungen effektiv in ihrer täglichen Arbeit unterstützen und ist ein Weg, um Mitarbeiter, Kunden, Partner und Zulieferer zu erreichen und zu integrieren. Tritt das Unternehmen nach innen und außen über ein zentrales Frontend auf, kann das Branding des Unternehmens stringent eingehalten und entwickelt werden. Ein inkonsistentes Bild des Unternehmens durch eine Vielzahl einzeln entwickelter und gestalteter E-BusinessSysteme kann so vermieden werden. Für ein Unternehmen in Konzerngröße ist die Integration der Applikationen durch ein Portal komplexer als bei kleineren Unternehmen. Es ist unwahrscheinlich, dass der heterogene Mix von Systemen, der typischerweise bei derartigen Unternehmen existiert, auf unternehmensweiter Basis integriert werden kann. Unternehmen dieser Größe werden eher Portale aufbauen, die spezifische Anforderungen adressieren und gegebenenfalls eine lokale Integration umfassen. Es ist ebenso denkbar, ein Portal einem bestimmten Unternehmenszweig zuzuweisen. Auf Basis eines gemeinsamen Fundaments können dann Lösungen maßgeschneidert werden, die genau zu einem bestimmten Bereich des Unternehmens passen. Durch seine Flexibilität kann das Portal diese Funktionen mit Elementen kombinieren, die Unternehmensstandards verbreiten. So können die jeweiligen Vorteile der verschiedenen Ansätze genutzt werden. Allerdings darf nicht außer Acht gelassen werden, dass auch die Entwicklung und Einführung kleinerer, lokaler Portallösungen in Konzernen eine komplexe Herausforderung darstellen. Auch wenn sich der fachliche Fokus bei kleineren Portallösungen verengt, so müssen sich diese dennoch in die komplexe technische und organisatorische Infrastruktur eines Konzerns integrieren. So wie die Komplexität im Hinblick auf die infrastrukturellen und kulturellen Veränderungen bei der Einführung eines Unternehmensportals mit der Größe des Unternehmens steigt, wächst der positive Nutzen, der mit dem Einsatz eines Portals realisiert werden kann. Für große Unternehmen wird die Fähigkeit, die richtige Information zur richtigen Zeit an den richtigen Ort bzw. Adressaten zu liefern,

8.1 Portale für jede Unternehmensgröße

Konsistenter Unternehmensauftritt

Lokale Portallösungen

■ ■ ■

229

zur entscheidenden Schlüsselqualifikation im globalen Informationszeitalter.

8.2 Anforderungsanalyse Gerade in Portalprojekten, die sich meist durch eine hohe Komplexität und eine Vielzahl beteiligter Personen bzw. Interessen auszeichnen, ist eine intensive und detaillierte Analyse der von den beteiligten Parteien an das System gestellten Anforderungen ein entscheidender Faktor für den Erfolg. So erbrachte eine Umfrage der Standish Group (www.standishgroup.com) unter 352 Unternehmen mit insgesamt mehr als 80.000 IT-Projekten folgendes Ergebnis:

Vollständige und detaillierte Analyse

230

■ ■ ■

■

31% aller Softwareprojekte scheitern, bevor sie beendet werden (eine Verschwendung von 81 Milliarden US-Dollar).

■

53% aller Projekte kosten 189% ihres ursprünglich veranschlagten Budgets.

■

In großen Unternehmen sind 9% aller Softwareprojekte im Zeitund Budgetplan.

■

In kleinen Unternehmen sind 16% aller Softwareprojekte im Zeit- und Budgetplan.

Als hauptsächliche Gründe für diese Fehlentwicklungen von Projekten werden mangelnde Informationen von Anwenderseite sowie unvollständige und sich ständig verändernde Anforderungen genannt. Diese Probleme verschärfen sich mit der Komplexität der Projekte bzw. der Aufgaben, die von einem Softwaresystem erfüllt werden sollen. Aus diesem Grund muss in Portalprojekten ein besonderes Augenmerk auf eine vollständige und detaillierte Analyse der Anforderungen gelegt werden. Auch wenn sich Anforderungen im Laufe der Zeit ändern, ist es ein wesentlicher Erfolgsfaktor für das Projekt, möglichst früh weitestgehend Vollständigkeit und Klarheit über die Anforderungen zu erlangen. Nur dann gründen alle weiteren Projektaktivitäten auf einer verlässlichen Basis. Der Grad der Zufriedenheit der Anwender hängt von der Erfüllung der Anforderungen ab. Nur wenn diese hinreichend bekannt und eindeutig sind, kann dieses zentrale Projektziel erreicht werden. Konnten sich die von der Einführung eines Portalsystems betroffenen Personen aktiv in die Gestaltung des zukünftigen Systems einbringen, dann steigt die Bereitschaft, sich positiv auf das System einzulassen. Darüber hinaus

8 Das richtige System

ist es in einem fortgeschrittenen Projektstadium kaum und nur mit sehr hohem Aufwand möglich, Fehler, die bei der Analyse der Anforderungen gemacht wurden, wieder zu korrigieren. Wie die Umfrage der Standish Group zeigt, können diese Fehler sogar das gesamte Projekt in Frage stellen. Fehler sind in diesem Zusammenhang zumeist nicht Fehler im engeren Sinne, sondern vielmehr Missverständnisse und Unklarheiten. Wie diese vermieden werden können, wird in den folgenden Abschnitten beschrieben. Was aber ist überhaupt eine Anforderung? Volere, ein Muster zur Gliederung von Anforderungsspezifikationen, definiert den Begriff wie folgt (vgl. www.volere.co.uk): Eine Anforderung ist ■

ein bewertbarer Wunsch,

■

oder eine Forderung an etwas, was das System oder Produkt tun muss oder können muss,

■

oder eine Eigenschaft, die das System/Produkt haben muss,

■

oder eine Randbedingung für das System/Produkt oder das Projekt, die beachtet werden muss.

Die Phase der Anforderungsanalyse (Requirements Engineering) umfasst das Ermitteln, das Beschreiben, das Prüfen und das Verwalten von Anforderungen und hat entscheidende Auswirkungen auf die Qualität des entstehenden Systems. Eine definierte Vorgehensweise zur Anforderungsanalyse ermöglicht es, die meist unüberschaubare Anzahl an Anforderungen in komplexen Projekten zu beherrschen. Abbildung 8.1 veranschaulicht die Bedeutung der Anforderungsanalyse als Basis für die erfolgreiche Durchführung eines Projektes. Die Zusammenhänge werden im Folgenden genauer beleuchtet. Abb. 8.1 Anforderungsanalyse als Basis erfolgreicher Portalprojekte

Anforderungen als Grundlage für

Kommunikation

Benutzerakzeptanz

Abnahme- und Testkriterien

Projektdurchführung / -planung

Dokumentation

Systemauswahl

Systemarchitektur

8.2 Anforderungsanalyse

■ ■ ■

231

8.2.1 Die ersten Schritte bei der Anforderungsanalyse Motive für ein Portalprojekt

Allgemeingültige Kriterien für handlungsweisende Ziele

Abb. 8.2 Die Zieldefinition – der erste Schritt der Anforderungsanalyse

Zunächst muss mit den Initiatoren des Projektes die Frage nach der Motivation für ein Portalprojekt, folglich nach dem Zweck, den ein Portal erfüllen soll, geklärt werden. Diese Motivation ist die Basis, um die ersten Schritte des Portalprojektes zu planen. Dabei ist es wichtig, die Motive für ein Portalprojekt als operationalisierbare Ziele zu definieren. Die Aussage „Wir wollen unsere Auftragsabwicklung beschleunigen“ reicht als Zielaussage nicht aus. Es fehlen hier die quantifizierbaren Größen. Die Bearbeitung welcher Aufträge soll in welcher Zeit mit welchen Mitteln um welchen Faktor beschleunigt werden? Wie lässt sich die Zielerreichung messen? Um als handlungsweisende Vorgaben und Messgrößen für den Projekterfolg dienen zu können, müssen Ziele folgende Kriterien erfüllen: ■

Das Ziel muss positiv formuliert sein und den Zielzustand genau beschreiben.

■

Das Ziel soll realistisch sein und im Rahmen der Möglichkeiten liegen.

■

Das Ziel muss zeitlich begrenzt sein.

■

Das Ziel muss messbar sein. Beteiligte Parteien

Rahmenbedingungen

Projektteam

zeitlich, monetär, personell

Zieldefinition

Betroffene Geschäftsprozesse

Motive

Annahmen

232

■ ■ ■

8 Das richtige System

Abbildung 8.2 veranschaulicht die Aspekte, die aus fundierten Zieldefinitionen für ein Projekt abzuleiten sind. Abgeleitet aus den Zielen eines Portalprojektes werden die Geschäftsprozesse des Unternehmens betrachtet und die für den Einsatzzweck des Portals relevanten Prozesse identifiziert. Diese Aufgabe stellt oftmals eine besondere Herausforderung dar, da viele Geschäftsprozesse zwar selbstverständlich, aber nicht bewusst oder sogar explizit definiert im Unternehmen existieren. Die klare Benennung der für das Portalprojekt relevanten Prozesse ist aber die Voraussetzung, um die an dem Projekt direkt oder indirekt beteiligten Parteien, die prozessunterstützenden IT-Systeme sowie die Abhängigkeiten und kritischen Erfolgsfaktoren eines Portalprojektes zu erkennen. Eine besondere Bedeutung erlangt die Benennung der relevanten Prozesse in jenen Portalprojekten, bei denen externe Organisationen, wie z.B. Lieferanten, in die Unternehmensprozesse integriert werden sollen. In diesem Fall erstrecken sich die zu betrachtenden Prozesse auch über die Grenzen des Unternehmens hinweg. Dabei sind aber nicht alle mittelbar oder unmittelbar durch die Einführung eines Portalprojektes betroffenen Geschäftsprozesse geeignet, um durch ein technisches System abgebildet und automatisiert zu werden. Die Voraussetzungen für eine sinnvolle technische Unterstützung von Prozessen sind im Abschnitt 6.2.2 aufgeführt. Prozesse, die sich durch ihre Struktur nicht für eine technische Unterstützung eignen, müssen, sofern die Einführung eines Portals indirekte Auswirkungen auf sie hat, ebenfalls im Rahmen der Anforderungsanalyse betrachtet werden. Nur so entsteht ein ganzheitliches Bild aller betroffenen Parteien und Prozesse und der damit einhergehenden organisatorischen Herausforderung durch die Einführung eines Portals für ein Unternehmen. An dieser Stelle soll das Thema Geschäftsprozessanalyse nicht weiter vertieft werden, da dies den Rahmen dieses Buchs sprengen würde. Es sei stattdessen auf die entsprechende Fachliteratur (z.B. Gadatsch 2002, Schnetzer 1999) verwiesen. Ist der Zweck des Portalprojektes bekannt und sind die betroffenen Geschäftsprozesse identifiziert, lassen sich die Beteiligten des Portalprojektes benennen. Dies sind zum einen die direkt involvierten Personen, die einen aktiven Part bei der Umsetzung des Portalprojektes übernehmen. Zum anderen sind dies aber auch alle durch die Einführung eines Portals und die Veränderung der Geschäftsprozesse betroffenen Personen und Abteilungen innerhalb und außerhalb des Unternehmens. Sie werden in einer klassifizierten Liste potenzieller Nutzer des Portals erfasst. Ergänzt wird diese um eine Quantifizierung, wann wie viele Benutzer das System voraussichtlich nutzen werden. Die Benutzer(gruppen) werden

8.2 Anforderungsanalyse

Geschäftsprozessanalyse

Zielgruppen der Anforderungsanalyse

■ ■ ■

233

Externe Zielgruppen

234

■ ■ ■

lich nutzen werden. Die Benutzer(gruppen) werden zudem mit einer Priorisierung versehen, die ihren Stellenwert im Projekt und im Portalsystem festlegt. Die identifizierten Personen und Abteilungen sind die Zielgruppe der Anforderungsanalyse. Ihre verschiedenen Sichtweisen, Bedürfnisse, Kriterien und Ideen werden im Rahmen der Anforderungsanalyse systematisch gesammelt, ausgewertet und in technische Anforderungen an ein Portalsystem übersetzt. Die von der Einführung eines Portals betroffenen Personen bzw. Abteilungen sind all jene, auf die das Portal in ihrer täglichen Arbeit Auswirkungen hat. Dies können, abhängig vom Anwendungszweck, die Fachabteilungen, die das Portal als zentrales Werkzeug ihrer Arbeit nutzen sollen, Redakteure und Autoren, die mit der Erstellung der Inhalte befasst sind, sowie Abteilungen, die für Marketing und interne Unternehmenskommunikation zuständig sind, sein. Zu der Zielgruppe der Anforderungsanalyse zählen auch die ITAbteilungen des Unternehmens. Diese werden wesentlich mit der Umsetzung des Projektes betraut sein und nach dessen Fertigstellung Wartung und Betrieb des Portals übernehmen. Das Controlling wiederum wird ebenfalls eigene Ansprüche an die Einführung eines Portalprojektes stellen. Darüber hinaus kann es innerhalb eines Unternehmens zahlreiche weitere Interessenvertreter geben, deren Wünsche in den Anforderungskatalog für ein Portalsystem einfließen müssen. Je nach Art und Verwendungszweck des Portals müssen Kunden und Lieferanten aktiv in den Prozess der Anforderungsanalyse eingebunden werden. Adressiert das Portal eine große Anzahl an Kunden, so empfehlen sich Marktforschungsmaßnahmen. Durch diese lässt sich ermitteln, welche angebotenen Dienste für die Kunden einen echten Mehrwert darstellen und wie sich ein Vorsprung vor Konkurrenzangeboten realisieren lässt. Diese verschiedenen Interessengruppen sehen das Portal aus unterschiedlichen Perspektiven. Sie betrachten im Regelfall nicht das Unternehmensportal als Ganzes, sondern sind Spezialisten ihrer Domäne und können für diese beschreiben, welche Anforderungen sie an ein Portal haben und wie das Portal sie in ihrer täglichen Arbeit unterstützen kann. Entscheidend für eine aussagekräftige Anforderungsanalyse ist es, all diese verschiedenen Sichtweisen auf ein Portal und die damit einhergehenden Interessen und Kriterien vollständig aufzunehmen. Nur wenn man die verschiedenen Bedürfnisse aller Betroffenen verstanden hat, wird man ein ganzheitliches Bild der Problemstellung gewinnen.

8 Das richtige System

Daneben ist es wichtig, von Anfang des Projektes an die mit der Durchführung des Portalprojektes und insbesondere mit der Anforderungsanalyse betrauten Personen, und deren Funktionen und Verantwortlichkeiten klar zu definieren und zu kommunizieren. Dadurch lassen sich Unklarheiten in der Kompetenzverteilung verhindern, und es lässt sich vermeiden, dass wertvolle Ideen von Mitarbeitern verloren gehen, nur weil diese nicht wissen, wer der richtige Adressat für ihren Beitrag ist. Im Vorfeld der Befragung der einzelnen Interessengruppen ist es ratsam, projektweit geltende Namenskonventionen und Definitionen festzulegen. Durch diese kann man Missverständnisse, die im Sprachgebrauch der einzelnen Kompetenzfelder liegen, vermeiden (vgl. Abschnitt 1.1). In der Praxis ist es oft so, dass z.B. Marketingund IT-Abteilungen zwar dieselben Begriffe verwenden, damit aber Verschiedenes bezeichnen. Konventionen verringern die Gefahr, aneinander vorbei zu reden und schaffen ein einheitliches Verständnis des Diskussionsgegenstandes. Zu diesem Zweck werden die Begriffe, Abkürzungen und Synonyme, die für das Projekt von Bedeutung sind, gesammelt und festgehalten. Dabei wird jeder Begriff in seiner Bedeutung für das Projekt beschrieben. Aus dieser Liste entsteht im Laufe der Analyse ein komplettes Glossar des Anforderungskataloges mit genauen Definitionen aller fachlichen Objekte. Dieses Projektwörterbuch stellt zudem die Eindeutigkeit der Anforderungen gegenüber Dritten, z.B. Systemherstellern, sicher.

Klare Verantwortlichkeiten

Die Sprache des Projektes

Die Praxis hat allerdings gezeigt, dass sich ein zu strikter Umgang mit Konventionen auch kontraproduktiv auswirken kann. Wenn Konventionen dazu führen, dass die Befragten sich mehr Gedanken über die Form als über den Inhalt ihrer Aussagen machen, sind Konventionen ein Korsett, das die Entwicklung kreativer Ansätze unterdrückt. Konventionen sollten eher als ein Mittel verstanden werden, mit dem das mit der Anforderungsanalyse betraute Team die verschiedenen Anforderungen in eine standardisierte und allgemein unmissverständliche Sprache übersetzt. Ebenfalls im Vorfeld der eigentlichen Anforderungsanalyse sollte ein Katalog mit Annahmen erstellt werden, die dem Analyseprozess zugrunde gelegt werden. Diese Annahmen beeinflussen zum einen die konkrete Umsetzung des Analyseprozesses, zum anderen aber auch die Projektorganisation und den späteren Systementwurf. In dem Katalog werden beispielsweise Annahmen über verfügbare Ressourcen, parallele Entwicklungen anderer Systeme oder Abhängigkeiten von Dritten aufgeführt.

8.2 Anforderungsanalyse

Annahmen

■ ■ ■

235

Der Annahmenkatalog dient der Nachvollziehbarkeit des Analyseprozesses und der initialen Projektplanung. Außerdem stellt er für das Projektmanagement ein wichtiges Werkzeug dar, um schon zu einer frühen Projektphase die Auswirkungen sich verändernder Rahmenbedingungen zu erkennen. Abb. 8.3 Die Hauptprobleme der Anforderungsanalyse (nach Rupp 2002)

Hauptprobleme der Anforderungsanalyse

Unklare Zielvorstellungen

Sprachbarrieren

Hohe Komplexität

Arten von Anforderungen

Schlechte Qualität

Veränderte Anforderungen

Ungenaue Planung

Unnötige Merkmale

Abbildung 8.3 stellt die besonderen Herausforderungen einer Anforderungsanalyse in komplexen Projekten dar. Die Abbildung macht deutlich, wie wichtig eine strukturierte Vorgehensweise bei der Analyse der Anforderungen und eine Qualitätssicherung ihrer Ergebnisse ist. Wie die Probleme bei der Anforderungsanalyse vermieden werden können, wird im Folgenden noch erläutert werden. Sind alle Randbedingungen des Portalprojektes identifiziert und festgelegt, dann ist die Basis geschaffen, um mit den einzelnen Beteiligten die Anforderungen an das Portalsystem aufzunehmen und schlussendlich zu einem Anforderungskatalog zusammenzuführen. Je nach ihrer Rolle und ihrer Aufgabe im Unternehmen werden die Beteiligten der Anforderungsanalyse zu folgenden Kriterien befragt (vgl. www.volere.co.uk): ■

Rahmenbedingungen des Projektes,

■

funktionale Anforderungen,

■

nicht-funktionale Anforderungen.

Die einzelnen Aspekte der Anforderungsanalyse werden im Folgenden genauer betrachtet und zueinander in Beziehung gesetzt.

236

■ ■ ■

8 Das richtige System

8.2.2 Rahmenbedingungen Zu den globalen Rahmenbedingungen gehört zuforderst der Zweck, den ein Portal für die verschiedenen Interessengruppen erfüllen muss. Dieser Zweck, also das Ziel, das durch die Einführung eines Portalsystems erreicht werden soll, wird im Regelfall von den verschiedenen Interessengruppen, die von einem Portalprojekt betroffen sind, sehr unterschiedlich verstanden. Die individuellen Zielsetzungen sind von der Rolle und den Verantwortlichkeiten sowie von den persönlichen Einstellungen und Interessen der Beteiligten abhängig. Die einzelnen Beteiligten haben eher ihre jeweilige Domäne und die Auswirkungen eines Portals auf ihre tägliche Arbeit im Blick, als die gesamtorganisatorische Wirkung. So kann es durchaus vorkommen, dass die Zielsetzungen der Beteiligten mehr oder minder stark von der Zieldefinition der Initiatoren des Portalprojektes abweichen. Umso wichtiger ist es, diese unterschiedlichen Motive zu kennen, um zu einem ganzheitlichen Verständnis der Projektanforderungen zu kommen. Sind verschiedene Motive frühzeitig bekannt, können gegebenenfalls entstehende Zielkonflikte frühzeitig bewusst gemacht und gelöst werden. Passiert dies nicht, ist unter Umständen schon in dieser frühen Projektphase der Grundstein für das Scheitern des Portalprojektes gelegt. Weichen die Motive verschiedener Beteiligter zu stark von der Zielsetzung des Projektes ab, kommt es bei der Einführung des Portals zu Frustrationen und somit zu einer geringeren Benutzerakzeptanz. Abgeleitet aus den definierten Zielen, werden in diesem Zuge auch die für das Projekt kritischen Erfolgsfaktoren benannt. Diese bezeichnen die Messpunkte, mit denen der Erfolg oder Misserfolg des Projektes gemessen werden kann, und die Funktionen, die zwingend für die Einführung des Portals implementiert sein müssen. Darüber hinaus wird in der Anforderungsanalyse die Ressourcensituation in zeitlicher, personeller und monetärer Hinsicht betrachtet. Die zeitliche Ressourcenplanung gibt Auskunft über die geplante Laufzeit des Projektes. Wann soll das System eingeführt werden? Gibt es Maßnahmen oder Bedingungen (wie z.B. eine Werbekampagne, die den Launch des Portals ankündigt), welche die Einhaltung dieses Termins zwingend erforderlich machen? Gibt es außerdem bereits festgelegte Meilensteine, zu denen bestimmte Teilergebnisse realisiert sein müssen? In personeller Hinsicht muss analysiert werden, mit welcher Kapazität die am Projekt beteiligten Personen dem Projekt zur Verfügung stehen. Wie viele Entwickler sind beispielsweise für die Entwicklung der einzelnen Portalapplikationen eingeplant, inwieweit

8.2 Anforderungsanalyse

Motive der beteiligten Parteien

Kritische Erfolgsfaktoren

Ressourcen

■ ■ ■

237

soll das interne Projektteam durch externe Spezialisten unterstützt werden? Wie viel Zeit steht den Mitarbeitern der Fachabteilungen für den Test und das Abnahmeverfahren zur Verfügung? Stehen Mitarbeiter dem Projekt nur Teilzeit zur Verfügung, dann muss beachtet werden, dass die Projektzeiten dieser Mitarbeiter nicht zu 100 Prozent verplant werden können. Wenn jemand zwei Aufgaben zu je 50 Prozent seiner Arbeitszeit wahrnehmen soll, wird häufig ignoriert, dass dies organisatorischen Mehraufwand erzeugt. Dieser zusätzliche, durch den Aufgabenwechsel bedingte Aufwand führt dazu, dass der Mitarbeiter beide Aufgaben nur zu je 45 Prozent ausführen kann. Sind mehr als zwei Aufgaben wahrzunehmen, steigt der Anteil des organisatorischen Aufwands entsprechend, so dass die tatsächlich erbringbare Leistung deutlich abnimmt. Nicht zuletzt muss natürlich die Frage nach dem verfügbaren Budget gestellt werden. Welche Kosten sind für das Gesamtprojekt eingeplant? Gibt es ein Budget für Change Requests (Planänderungen), und ist bereits ein Budget für weitere Releases geplant? Gerade bei Portalprojekten ist aufgrund ihrer Komplexität ein Risikomanagement unerlässlich. Es muss daher auch ein entsprechendes Budget für die Risikovermeidung bzw. die Schadensbegrenzung in der Budgetplanung berücksichtigt werden. Rahmenbedingungen der IT-Infrastruktur

Weitere für die Systemauswahl entscheidende Rahmenbedingungen lassen sich aus der Analyse der bestehenden IT-Infrastruktur ableiten. Im Rahmen dieser Analyse müssen Informationen zu mindestens den folgenden Punkten erhoben werden: ■

Server-Hardware,

■

Client-Hardware,

■

Netzwerk,

■

verwendete Netzwerkprotokolle,

■

Betriebssysteme,

■

Leistungsdaten von Servern und Netzwerk,

■

Datensicherungskonzept,

■

Datenschutzkonzept.

Sollen externe Partner wie z.B. Lieferanten technisch in das Portal integriert werden, so müssen auch deren IT-Systeme betrachtet

238

■ ■ ■

8 Das richtige System

werden. Um zu vermeiden, dass bei der Einführung des Portals bereits angenommene technische Rahmenbedingungen nicht mehr aktuell sind, sollten neben der reinen Analyse der Ist-Situation auch alle zukünftigen Entwicklungen, die bereits abzusehen sind, betrachtet werden. Aus der Analyse der IT-Infrastruktur aller am Projekt beteiligten Organisationen leiten sich technische Anforderungen und Einschränkungen ab. Diese liegen zum einen in den bereits verwendeten Technologien, Plattformen und Protokollen selbst begründet. Zum anderen entstehen sie durch das intern vorhandene IT-Know-how. Setzte das Unternehmen bislang auf den Einsatz bestimmter Technologien und Standards und hat in diesen Bereichen entsprechendes Expertenwissen aufgebaut, sollte sich dieses Wissen und die damit verbundene Erfahrung natürlich auch in dem Portalprojekt einsetzen lassen. Neben den Einschränkungen und Anforderungen, die sich aus der Ressourcensituation und der IT-Infrastruktur ergeben, müssen auch die Auswirkungen anderer Aktivitäten auf das Portalprojekt analysiert werden. Diese Aktivitäten können organisatorischer, politischer oder systemtechnischer Natur sein. Portalprojekte sind technisch komplex. Portale haben viele Verknüpfungen und Abhängigkeiten zu anderen IT-Systemen. Sind neben der Einführung des Portals weitere IT-Projekte geplant, so kann es hier zu unvorhergesehenen Überschneidungen kommen, die den Verlauf des Portalprojektes beeinflussen. Andererseits kann die Einführung eines Portals andere IT-Projekte für einen längeren Zeitraum blockieren. Auch organisatorische Veränderungen, die z.B. Geschäftsprozesse beeinflussen, die durch das Portal unterstützt werden sollen, können ungeplante Auswirkungen auf das Portalprojekt haben.

Auswirkungen anderer Projekte

In der Praxis kommt es leider immer wieder vor, dass erst bei der Einführung von Systemen bemerkt wird, dass sich unterstellte Rahmenbedingungen zwischenzeitlich verändert haben. Aus diesem Grund müssen die Aktivitäten in der Umwelt des Portalprojektes bekannt sein, um sie in der Planung des Projektes berücksichtigen zu können, so dass sie den Erfolg des Portalprojektes nicht gefährden können.

8.2 Anforderungsanalyse

■ ■ ■

239

8.2.3 Funktionale Anforderungen Funktionale Anforderungen umfassen alle gewünschten funktionalen Leistungen, alle gewünschten Abläufe und Algorithmen, sowie alle gewünschten Informationen, die das System zur Verfügung stellen bzw. verarbeiten können muss. Der Katalog aller funktionalen Anforderungen ist die vollständige Beschreibung der Funktionsweise des Portals aus der Nutzerperspektive. Diese Phase der Anforderungsanalyse ist im Regelfall die längste des gesamten Analyseprozesses. Hierbei werden alle Anforderungen der Beteiligten an die Funktionalität des Systems aufgelistet. Die gewünschten Funktionen hängen wiederum meist stark von der Domäne des Befragten und seiner Rolle, die er im Portal übernimmt, ab. Sie reichen beispielsweise von redaktionellen Freigabemechanismen bis zur automatischen Ermittlung betriebswirtschaftlicher Kennzahlen. Hier finden Sie die bereits im Kapitel 4 dargestellten fachlichen Anforderungen an Portalsysteme wieder. Soll das Portal auch als Kommunikationskanal nach außen dienen, so müssen nicht nur die Anforderungen der intern an dem Portalprojekt Beteiligten analysiert werden. Ein besonderes Augenmerk gilt hier den funktionalen Wünschen der Kunden. Nur wenn das Portal den Anforderungen der Kunden entspricht, wird es sich als effektives Kundenbindungsinstrument etablieren.

8.2.4 Nicht-funktionale Anforderungen Nicht-funktionale Anforderungen sind Verhaltenseigenschaften, die von dem zu implementierenden System zusätzlich zu den funktionalen Anforderungen außerdem gewährleistet werden müssen. Alle nicht-funktionalen Anforderungen müssen messbar und auf ihre Erfüllung hin überprüfbar sein. Systemkriterien

240

■ ■ ■

Zu den nicht-funktionalen Anforderungen zählen die bereits im Kapitel 5 vorgestellten technischen Kriterien. Dazu gehören neben den Technologien zur Entwicklung von Portalapplikationen oder zur Integration externer Anwendungen auch die durch das Portalsystem unterstützten Clients. Für den späteren Betrieb des Systems sind die Anforderungen an Performanz, Verfügbarkeit und Sicherheit sowie der prognostizierte Wartungsaufwand entscheidend.

8 Das richtige System

Ebenfalls zu den nicht-funktionalen Kriterien gehören die Anforderungen an die Gestaltung und Ergonomie der Benutzungsoberfläche des Portals. Zu den Kriterien für eine intuitive Benutzbarkeit des Systems zählen der Lernaufwand, die Komplexität der Dateneingabe, die Auffindbarkeit von Informationen und Hilfefunktionen. Auch die Anforderungen an den Hersteller des Portalsystems zählen zu dieser Kategorie. Hier spielen Kriterien wie Umsatz, Herkunft, Anzahl der Portalinstallationen und insbesondere das Dienstleistungsangebot des Herstellers eine Rolle. Neben den Anforderungen, die direkt an den Hersteller gestellt werden, ist das Serviceangebot, das rund um das Portalsystem von Dritten angeboten wird, oftmals von entscheidender Bedeutung. Insbesondere für Unternehmen, die intern nicht die für ein Portalprojekt notwendigen Ressourcen oder das entsprechende Know-how haben, ist dies ein entscheidender Faktor. Die angebotenen Dienstleistungen reichen dabei vom Hosting, das von Service Providern angeboten wird, über Angebote von Unternehmensberatungen bis hin zur Übernahme von Entwicklung und Betrieb des Portalsystems durch IT-Systemhäuser. Zu guter Letzt gehören neben weiteren organisatorischen oder politischen Anforderungen auch alle Vorschriften und Gesetze, die Auswirkungen auf das Portalsystem haben, zu den nichtfunktionalen Anforderungen. Dazu zählen unter anderem die Grundsätze des Datenzugriffs und der Prüfbarkeit digitaler Unterlagen (GDPdU) sowie die Vorschriften aus dem Teledienstegesetz. Die vorgestellte Liste der Anforderungskriterien erhebt keinen Anspruch auf Vollständigkeit. Sie ist eine Richtschnur und muss auf das jeweilige Unternehmen und den Anwendungszweck eines Portals adaptiert werden. Auf unserer Webseite www.pret-a-portal.info finden Sie eine beispielhafte Checkliste zur Anforderungsanalyse.

Intuitive Benutzungsoberfläche

Herstellerkriterien

Vorschriften und Gesetze

8.2.5 Vorgehensweise Wie bereits in den vorangegangenen Abschnitten dargelegt, werden nicht alle Beteiligten zu allen Anforderungskriterien befragt. Die Auswahl der Fragen richtet sich nach der Aufgabe des Beteiligten im Unternehmen und seiner Rolle im Portal(projekt). Die globalen Rahmenbedingungen des Projektes wie Zeit, Budget und verfügbare Ressourcen werden von den Auftraggebern des Projektes festgelegt. Die funktionalen Anforderungen können am besten von den Beteiligten spezifiziert werden, die später täglich mit dem Portal arbeiten sollen. Angaben über die IT-Infrastruktur, Anforderungen an unter-

8.2 Anforderungsanalyse

■ ■ ■

241

Repräsentanten der Interessengruppen

Methoden zur Anforderungsanalyse Fragebögen

Einzelinterviews

Gruppeninterviews

242

■ ■ ■

stützte Technologien und an die Wartbarkeit des Systems kommen von der IT-Abteilung. Für eine effiziente Analyse der Anforderungen ist es nicht sinnvoll, jede einzelne Person, die von der Einführung eines Portals betroffen ist, direkt in den Prozess der Anforderungsanalyse einzubinden. Dieses Vorgehen würde in komplexen Portalprojekten mit einer großen Anzahl von Portalbenutzern eine sinnvolle und effiziente Anforderungsanalyse unmöglich machen. Es ist ausreichend, wenn jede Interessengruppe mindestens einen Repräsentanten benennt, der alle Gruppenmitglieder im Anforderungsanalyseprozess vertritt. Dieser Repräsentant muss so frühzeitig benannt werden, dass er die Möglichkeit hat, sich mit seinen Kollegen auseinander zu setzen und deren Anforderungen aufzunehmen. Die funktionalen Anforderungen haben das meiste Gewicht im Prozess der Anforderungsanalyse. Um sämtliche Anforderungen an die Funktionen des Systems bei den Beteiligten abzufragen, können verschiedene Methoden eingesetzt werden. Schriftlich auszufüllende Fragebögen haben den Vorteil, dass sie von einer großen Anzahl von Personen mit relativ geringem Aufwand beantwortet werden können. Fragebögen sind zwar eine sehr demokratische Methode der Befragung, doch haben sie den Nachteil, statisch zu sein und keine Möglichkeit für Rückfragen zu geben. Einzelinterviews sind dagegen vergleichsweise aufwendig, bieten aber Raum, um direkt auf die Aussagen des Befragten einzugehen und unklare Punkte im Gespräch zu lösen. Schwierig sind Einzelinterviews auch in Situationen, in denen es zwischenmenschliche Spannungen zwischen Interviewer und Befragtem gibt oder in denen sich der Befragte aufgrund von Hierarchieunterschieden nicht traut, kritische Antworten zu geben. Das Gruppeninterview hat die gleichen Vor- und Nachteile wie das Einzelinterview, ist aber mit einem geringeren zeitlichen und organisatorischen Aufwand verbunden. Außerdem ist der gemeinsame Austausch oftmals sehr hilfreich, um auftretende Zielkonflikte direkt in einer Gruppenentscheidung zu lösen. Darüber hinaus verändert eine Diskussion der geäußerten Anforderungen den Blickwinkel der Beteiligten und führt so manchmal zu neuen Ansätzen, die in einer Einzelbefragung nicht gefunden worden wären. Neben den genannten Methoden gibt es zahlreiche weitere, wie z.B. Kreativitätstechniken, die bei der Aufnahme und dem Verständnis von Anforderungen sinnvoll unterstützen können. In Portalprojekten mit einer Vielzahl beteiligter Parteien lassen sich diese aber oft nicht effektiv einsetzen. Generell gibt es keine „richtige“ Methodik der Anforderungsaufnahme. Die gewählte Form der Befragung hängt von der Anzahl der

8 Das richtige System

zu befragenden Personen, deren örtlicher Verfügbarkeit und dem Befragungsgegenstand ab. Gegebenenfalls sind auch Mischformen der vorgestellten Methoden die richtige Wahl für eine effiziente Anforderungsaufnahme. So können z.B. Zielkonflikte, die sich durch eine Fragebogenanalyse ergeben haben, in einer Gruppendiskussion mit den betroffenen Parteien gelöst werden. In der Praxis haben sich Checklisten und Fragebögen für die Aufnahme reiner Fakten, wie z.B. der Struktur der IT-Landschaft, als am effektivsten bewährt. Die Checklisten werden von den für ITBetrieb, Entwicklung, Datensicherheit, technische Wartung zuständigen Mitarbeitern oder Dienstleistern ausgefüllt. So lässt sich sicherstellen, dass in großen und komplexen Portalprojekten keine Informationen vergessen werden und die Informationen in strukturierter Form gesammelt werden. Eine beispielhafte Checkliste, die als Grundlage für eine an den individuellen Gegebenheiten des Unternehmens ausgerichtete Checkliste dienen kann, finden Sie auf unserer Webseite www.pret-a-portal.info. Für die Analyse der funktionalen Anforderungen haben sich Gruppeninterviews bewährt. Neben den genannten Vorteilen führen diese dazu, dass sich alle Diskussionspartner am Ende des Interviews auf den Katalog der Anforderungen und deren Prioritäten verständigt und somit einen einheitlichen Informationsstand erhalten haben. Menschliche Einflussfaktoren

Motivation

Kommunikative Fähigkeiten

Abstraktionsvermögen

Art des Wissens

Machtsituation, Gruppendynamik

Checklisten und Fragebögen

Abb. 8.4 Die größte „Gefahr“: Der Einflussfaktor Mensch (nach Rupp 2002)

Homogenität der Interessen

Abbildung 8.4 illustriert die menschlichen Einflussgrößen, die auf den Prozess der Anforderungsanalyse einwirken. Die Tatsache, dass die Anforderungsanalyse kein rein rationaler und an ausschließlich fachlichen Gesichtspunkten orientierter Prozess ist, macht diese zu einer Kunst für sich, wie das folgende Zitat der Sophist Group unterstreicht (vgl. Rupp 2002).

8.2 Anforderungsanalyse

■ ■ ■

243

Das Ermitteln von Anforderungen ist die Kunst, eine vollständige und widerspruchsfreie Menge von Anforderungen zu sammeln und zwar durch den gezielten Einsatz bestimmter Methoden, wie Interviews, Fragebogen, Apprenticing und Systemarchäologie. Das Formulieren von Anforderungen ist die Kunst, eine Anforderung so zu beschreiben, dass sie eindeutig, testbar und verständlich ist. Hierfür stehen dem Analytiker eine Reihe von Methoden zur Verfügung, etwa die natürliche Sprache oder halbformale Sprachen. Das Validieren von Anforderungen ist schließlich die Kunst, dabei zu Anforderungen zu gelangen, über die sich die Stakeholder einig sind.

Kriterien für Anforderungen

Prototypen

Use Case

244

■ ■ ■

Losgelöst von der gewählten Methodik gilt für den Analyseprozess, dass Anforderungen erst dann als solche beschrieben werden können, sobald sie detailliert definiert und niedergeschrieben sind. Anforderungen sollten nach Volere (www.volere.co.uk) mit den folgenden Informationen beschrieben werden: ■

eindeutige Anforderungsnummer,

■

Beschreibung,

■

Begründung (optional),

■

Prüfkriterien (Kriterien, anhand derer die Erfüllung der Anforderung geprüft werden kann),

■

Quelle,

■

Abhängigkeiten zu anderen Anforderungen oder Rahmenbedingungen des Projektes,

■

gegebenenfalls Verweise auf Dokumente und Informationen, welche die Anforderung weiter verdeutlichen.

Um zu verifizieren, dass die aufgenommenen Anforderungen richtig verstanden wurden, helfen oftmals anschauliche Prototypen. Anhand einer konkreten Umsetzung lassen sich unklare Anforderungen oftmals direkter klären und fachsprachliche Barrieren überwinden. Gerade bei Portalsystemen, die für die späteren Benutzer zu einem zentralen Werkzeug ihrer täglichen Arbeit werden sollen, haben sich Prototypen als sehr hilfreich erwiesen, um frühzeitig die Benutzer an das System heranzuführen oder Fehlentwicklungen zeitnah zu erkennen. Eine ausführliche Betrachtung der Bedeutung von Prototypen in Portalprojekten finden Sie im Abschnitt 9.2.3. Eine weitere Methode, um sich über Anforderungen zu verständigen, sind sogenannte Use Cases, im Deutschen oft als Anwendungsfälle bezeichnet. Diese beschreiben ausgehend von den aufge-

8 Das richtige System

nommenen Anforderungen detailliert die gewünschte Ablauflogik bestimmter Geschäftsprozesse. Der Vorteil von Use Cases ist, dass sie einfach zu erstellen und zu verstehen sind. Sie veranschaulichen, wie das zukünftige System aus der Benutzerperspektive funktionieren wird. Die Erstellung von Use Cases erzwingt eine detaillierte Betrachtung des Aufbaus und der Bedienlogik des Systems. Die Use Cases sind damit ein guter Gradmesser, um zu ermitteln, ob alle erforderlichen Informationen bekannt und verstanden sind. Use Cases verwenden eine allgemein verständliche Sprache, die nicht nur von den an der Anforderungsanalyse Beteiligten, sondern auch von Programmierern, Systemarchitekten und Testern verstanden wird. Da sich aus Use Cases auch automatisch eine Reihe von Testfällen ergeben, sind sie aber nicht nur in der Anforderungsanalyse, sondern über den gesamten Projektverlauf hinweg ein wertvolles Werkzeug. Werden Use Cases zur Verständigung über Anforderungen eingesetzt, dann kann das konkrete Verhalten des Systems schon in dieser frühen Phase sehr genau beschrieben werden. Durch dieses Vorgehen wird vermieden, dass Entscheidungen über die Funktionsweise der Portalsoftware erst während der Implementierung ad hoc getroffen werden. Use Cases nutzen standardisierte Vorlagen. Diese umfassen ein Use-Case-Diagramm, eine Liste der beteiligten Personen, Ereignisse, Beschreibungen, Vor- und Nachbedingungen, alternative Abläufe, Fehler- und Ausnahmebedingungen, Risiken und Ergebnisse sowie Funktionen und Regeln. Ein detaillierter Einblick in die Methodik der Use CaseModellierung würde den Rahmen dieses Buchs sprengen. Es sei an dieser Stelle auf die entsprechende Fachliteratur (z.B. Oestereich 2001) verwiesen. Sind alle Anforderungen aufgenommen worden, dann müssen sie konsolidiert, priorisiert und hinsichtlich gegenseitiger Konflikte untersucht werden. Der nun entstandene Katalog der Anforderungen muss den folgenden Kriterien genügen: ■

Vollständigkeit: Fällt die Entscheidung für ein Portalsystem aufgrund unvollständiger Anforderungen, dann kann das unter Umständen das gesamte Projekt in Frage stellen.

■

Eindeutigkeit: Anforderungen dürfen nicht redundant und insbesondere nicht mehrdeutig beschrieben sein. Bietet die Formulierung der Kriterien Raum für Interpretationen, so stellt dies eine potenzielle Fehlerquelle dar. Prioritäten müssen die Bedeutung der Anforderung für die Projektrealisierung eindeutig festlegen.

8.2 Anforderungsanalyse

Kriterien des Anforderungskatalogs

■ ■ ■

245

Technischer Anforderungskatalog

246

■ ■ ■

■

Konsistenz: Ein Anforderungskatalog darf keine Widersprüche enthalten. Zielkonflikte, die aus den verschiedenen Sichtweisen der Beteiligten resultieren, müssen frühzeitig gelöst werden. Die getroffenen Entscheidungen müssen dabei an die beteiligten Parteien kommuniziert und begründet werden, um für diese den weiteren Projektverlauf nachvollziehbar zu machen. Des weiteren muss der Anforderungskatalog iterativ weiterentwickelt werden. Änderungen, die sich z.B. durch einen Prototypen ergeben, müssen in den Katalog einfließen.

■

Nachvollziehbarkeit: Um späteren Missverständnissen vorzubeugen, Änderungen zielgerichtet kommunizieren zu können und technische Anforderungen fachlichen Bedürfnissen zuordnen zu können, muss die Herkunft der einzelnen Kriterien nachvollziehbar sein.

■

Keine Design-Informationen oder Umsetzungshinweise: Sobald eine Anforderungen beginnt, einzelne Teilkomponenten und ihre Algorithmen zu beschreiben, ist sie keine Anforderung mehr, sondern eine Design-Information und somit nicht geeignet für einen Anforderungskatalog.

Sind die funktionalen und nicht-funktionalen Anforderungen aufgenommen und analysiert, beginnt der nächste Schritt des Analyseprozesses. Die fachlichen Anforderungen müssen in eine technische Sprache als konkrete Anforderungen an ein Softwaresystem (System Requirements) übersetzt werden. Die Aussage „Das System soll Kunden den Status ihrer Bestellung anzeigen“ ist eine funktionale Anforderung an die zukünftige Portalinstallation. Sie reicht aber als technische Anforderung zur Auswahl eines Softwaresystems nicht aus. Während die funktionalen und nicht-funktionalen Anforderungen die Bedürfnisse der an einem Portalprojekt beteiligten Personen beschreiben, stellt der technische Anforderungskatalog die Lösungen für diese Bedürfnisse dar. Der technische Anforderungskatalog ist die Basis für die spätere Systemevaluation. Deshalb müssen die technischen Systemanforderungen so detailliert wie möglich formuliert werden. Die Kriterien, die an den Katalog der funktionalen und nicht-funktionalen Anforderungen gestellt werden (vgl. Abschnitt 8.2.1), gelten auch für die Liste der technischen Anforderungen.

8 Das richtige System

Das folgende Beispiel zeigt exemplarisch die Übersetzung der fachlichen Welt in eine technische Sprache: Nr.

Anforderungsbeschreibung

1

2

Über das System sollen Stammdaten, Bestell- Geschäftsführung daten und eine Kommunikationshistorie zu den Kunden dargestellt werden. Marketing Inhalte, die für das Portal erfasst werden, müssen erst von dem für Marketing zuständigen Mitarbeiter freigegeben werden, bevor sie publiziert werden.

Nr.

Anforderungsbeschreibung

3

Systeme sollen nur lose gekoppelt sein. IT-Betrieb Punkt-zu-Punkt-Verbindungen sind wegen der Anbindung externer Lieferanten nicht wünschenswert.

Nr.

Anforderungsbeschreibung

1

Das System muss die über einen zentralen In- Geschäftsführung, tegrationsmechanismus (Integrationsbus) zur IT Verfügung zu stellenden Daten aus dem SAPSystem, der CRM-Anwendung und der Produktdatenbank integrieren und zueinander in Beziehung setzen. Die Redaktionsfunktion des Portals soll über Marketing einen Workflowmechanismus mit Freigabestufen gesteuert werden.

2

Quelle

Quelle

Quelle

Tabelle 8.2 Funktionale Anforderungen

Tabelle 8.3 Nicht-funktionale Anforderungen

Tabelle 8.4 Technische Anforderungen

Die Trennung der Benutzerbedürfnisse (im weitesten Sinne) von den technischen Kriterien hat den Vorteil, dass Bedürfnisse und Lösungen sauber voneinander getrennt werden. Die Kontrolle und Freigabe der jeweiligen Kataloge kann von Spezialisten der jeweiligen Domäne vorgenommen werden. Um Nachvollziehbarkeit zu gewährleisten, müssen sich die einzelnen Punkte im Katalog der Systemanforderungen den funktionalen Anforderungen zuordnen lassen und umgekehrt. Änderungen in einem der Kataloge müssen während der gesamten Projektlaufzeit entsprechend in dem anderen Katalog nachgezogen werden.

8.2 Anforderungsanalyse

■ ■ ■

247

8.2.6 Die Analyse des Integrationspotenzials

Redundante Datenhaltung

Orientierung am Anwendungszweck

248

■ ■ ■

An dieser Stelle soll noch ein Punkt besonders hervorgehoben werden, dem im Rahmen der Anforderungsanalyse für Portalsysteme ein besonderes Gewicht zukommt. Gemeint ist das Erkennen des für das Portalprojekt relevanten Integrationspotenzials von Geschäftsprozessen und der darunter liegenden IT-Infrastruktur. Sind die Ziele, die mit der Einführung eines Portals verbunden sind, sauber definiert, so lassen sich die Geschäftsprozesse ableiten, die potenziell für eine Portalunterstützung in Frage kommen. Wie bereits beschrieben, ist die Struktur der Prozesse und der Standardisierungsgrad ihrer Abläufe ausschlaggebend für eine sinnvolle ITtechnische Unterstützung. Daneben werden im Rahmen der Anforderungsanalyse Informationen über die IT-Infrastruktur und die verschiedenen Datenquellen des Unternehmens ermittelt. Anwender definieren ihre funktionalen Anforderungen an eine integrierte Sicht auf die Unternehmensdaten. Dies alles sind wichtige Schritte, um die Funktionsweise des zukünftigen Portals zu beschreiben und daraus technische Anforderungen an ein IT-System abzuleiten. Sie alleine reichen aber noch nicht aus. Viele Daten liegen im Unternehmen redundant vor. So werden beispielsweise Kundenstammdaten im CRM-System, dem ERPSystem oder auch in der Datenbank des Online-Shops verwaltet. Die Herausforderung liegt nun darin, zu erkennen, welches die „richtigen“ Daten zur Unterstützung eines Geschäftsprozesses sind und wie deren Aktualität und Konsistenz über mehrere Systeme sichergestellt werden kann. Daneben steht die Frage, wie Daten aus verschiedenen Systemen eindeutig miteinander in Beziehung gesetzt werden können. Diese grundsätzlichen Punkte müssen geklärt sein, um beschreiben zu können, welche Integrationsmechanismen für die Unterstützung der Geschäftsprozesse sinnvoll sind. Daraus lassen sich dann technische Anforderungen an die Integrationsfunktion eines Portalsystems ableiten. Ein weiterer wichtiger Aspekt in diesem Zusammenhang ist die Zweckgebundenheit der Integration. Integrierte Daten an sich stellen noch keinen Wert dar. Sie entwickeln diesen erst im Zusammenhang mit einem konkreten Anwendungsfall. Aus diesem Grund darf Integration niemals ein technischer Selbstzweck sein. Für den Mitarbeiter im Call Center stellt eine integrierte Sicht auf alle Kunden-, Bestell- und Kontaktdaten eine hilfreiche Unterstützung seiner Arbeit dar. Für den Außendienst-Mitarbeiter, der ein technisches System warten soll, sind nur Informationen aus der Produktdatenbank für die Ausübung seiner Aufgabe relevant.

8 Das richtige System

Diese Beispiele zeigen, dass Sie, wenn Sie sich Gedanken über das Integrationspotenzials ihres Portals machen, nicht vom technisch Möglichen ausgehen sollten, auch wenn das zum Teil verführerisch sein mag. Schlussendlich soll das Portal dazu dienen, die Mitarbeiter in ihren Aufgabenbereichen optimal zu unterstützen. Deshalb muss sich auch die Konzeption an realen Anwendungsfällen orientieren.

8.2.7 Bedeutung der Anforderungsanalyse Zusammenfassend lässt sich sagen, dass die Anforderungsanalyse in einem Portalprojekt, das im Regelfall eine hohe Komplexität besitzt und eine Vielzahl beteiligter Parteien und somit Interessen berücksichtigt, sehr sorgfältig durchgeführt werden sollte. Fehler, die in der Analysephase gemacht werden, lassen sich zu einem fortgeschrittenen Projektzeitpunkt kaum oder nur mit sehr hohem Aufwand korrigieren. In vielen Projekten neigen die Beteiligten dazu, die Analysephase zu vernachlässigen und mit dem minimal möglichen Ressourceneinsatz zu betreiben. Wird viel Wert darauf gelegt, alle Anforderungen an ein System eindeutig, widerspruchsfrei, vollständig und testbar zu beschreiben, so wird eine solche Analyse die Kosten in den frühen Phasen des Projektes zwar erhöhen. Allerdings können durch eine gute Anforderungsanalyse viele Fehler im Projektablauf frühzeitig vermieden werden, wodurch sich langfristig gesehen die GesamtProjektlaufzeit wesentlich reduzieren lässt. Darüber hinaus gewährleisten sorgfältig gepflegte Anforderungskataloge die Planungssicherheit des Projektes. So lassen sich z.B. organisatorische Herausforderungen in der Einführungsphase des Portals bereits in einem frühen Projektstadium erkennen. Die Investitionen in die Analyse der Anforderungen amortisieren sich über die Projektlaufzeit. Auf Basis der Anforderungskataloge lassen sich Release-Planungen, Testszenarien, Abnahmekriterien und Meilensteine entwickeln. Der technische Anforderungskatalog ist die Basis einer Bewertungsmatrix für die Softwareauswahl. Die Ergebnisse der Analysephase sind somit ein wichtiges Planungsinstrument für das Projektmanagement. Die Anforderungsanalyse darf nicht als einmaliger Prozess in einer frühen Phase des Projektes verstanden werden. Durch die sich im Laufe der Konzeption und Entwicklung des Portalsystems verändernden Sichtweisen und Erkenntnisse müssen die Anforderungskataloge permanent weiterentwickelt werden. Für eine vorausschauende Projektplanung ist außerdem das Erfassen (potenzieller) zukünf-

8.2 Anforderungsanalyse

Kontinuierlicher Prozess

■ ■ ■

249

tiger Anforderungen sinnvoll. Um Inkonsistenzen zu vermeiden und Nachvollziehbarkeit zu gewährleisten, müssen Änderungen stets in beiden Anforderungskatalogen nachgezogen werden. Ebenso muss auch die Liste der zugrundegelegten Annahmen über das Projekt permanent fortgeschrieben werden. Die Praxis hat gezeigt, dass es oftmals sinnvoll ist, sich bei der Anforderungsanalyse von externen Dienstleistern unterstützen zu lassen. Diese bringen neben weitreichender Erfahrung in ähnlichen Projekten und IT-Kompetenz einen unvoreingenommenen Blick und die nötige Neutralität gegenüber den geäußerten Anforderungen mit.

8.3 Softwareauswahl Make or Buy?

Zunehmende Standardisierung

250

■ ■ ■

Der Prozess der Implementierung eines Unternehmensportals ist in seinen Inhalten stark abhängig von der fachlichen und technischen Portalstrategie sowie von der Entscheidung in der Frage „Make or Buy?“. Wird das Unternehmensportal mehr oder weniger selbst entwickelt („Make“), so wird die Implementierung ein zeitlich aufwendiger Prozess sein – im Falle des „Buy“ hofft man hingegen auf eine deutlich geringeren Implementierungsaufwand, der sich im Wesentlichen auf die Komposition vorhandener (zugekaufter) Komponenten beschränken sollte. Abhängig von der Anzahl der zu integrierenden Komponenten und Datenquellen kann in der Praxis auch ein Portalprojekt, das aus zugekauften Komponenten besteht, schnell umfangreich werden. Wie immer stecken die Probleme im Detail. Hinzu kommt, dass die verschiedenen marktreifen Komponententechnologien für verteilte Systeme (J2EE, CORBA, .NET) zwar miteinander kommunizieren können, dies aber zu Lasten der Performanz und der Einfachheit des Systementwurfs geht. Bei der Auswahl der Kaufkomponenten sollte also nicht nur die Funktionalität im Vordergrund stehen, sondern auch die Möglichkeiten der Integration über Middleware- und Komponententechnologien berücksichtigt werden. Mit zunehmender Standardisierung der Portalapplikationen können die fachlichen Anforderungen bei der Systemauswahl immer stärker in den Vordergrund rücken. Während man sich bei der ersten Generation der Portalsysteme mit der Entscheidung für einen Hersteller automatisch auf dessen proprietäre Schnittstellen festgelegt hat, versprechen die Portlet-Spezifikation und der WSRP-Standard eine größere Unabhängigkeit von einzelnen Herstellern sowie die Kombinierbarkeit von Lösungen verschiedener Hersteller (vgl. Ka-

8 Das richtige System

pitel 7). Diese Entwicklung ist zu begrüßen, da sie den Unternehmen mehr Freiheiten einräumt und fachliche Kriterien einen größeren Stellenwert bekommen. Damit berücksichtigt das Softwareprojekt „Unternehmensportal“ von Beginn an die fachlichen Anforderungen im angemessenen Umfang. Wir können es nur immer wieder betonen: Unternehmensportale haben einen fachlichen Fokus, der von der Technik lediglich bestmöglich unterstützt wird. Auf der anderen Seite stehen am Ende des Produktauswahlprozesses ein oder mehrere Softwarepakete, welche die Grundlage für das Unternehmensportal bilden sollen. Diese Software muss sich zwingend in die IT-Systemlandschaft des Unternehmens integrieren lassen. Im Gegensatz zu anderen Softwaresystemen kann ein Unternehmensportal aufgrund seiner zentralen, steuernden Natur nie als Insellösung implementiert werden. Es ist angewiesen auf die datenverarbeitenden und prozesssteuernden Systeme des Unternehmens. Ohne Zugriff auf diese Systeme kann es seine Aufgabe in der Regel nicht erfüllen. Hinter dieser Forderung nach einem umfassenden Informationszugriff stehen aber verschiedene technische Fragen, so z.B. nach den kommunikativen Fähigkeiten der Systeme, der Möglichkeit eines Online-Zugriffs oder den Zugriffsberechtigungen. Klare technische Anforderungen also, die von immer stärker werdenden fachlichen Kriterien flankiert werden. Die wesentliche Herausforderung bei der Vorbereitung der Softwareauswahl ist es demnach, Technik und Fachlichkeit nicht in Konkurrenz zueinander zu sehen oder zu stellen, sondern stattdessen die beiden Aspekte als einander ergänzend zu begreifen: Ein technisch perfektes Unternehmensportal nützt nichts, wenn die vom Portal angebotenen Inhalte und unterstützten Prozesse keinen Nutzen stiften. Selbst wenn die Portalsoftware in der Lage ist, auch die letzte kleine Datenquelle anzuzapfen, so muss der im Zugriff des Portals befindliche virtuelle Datenpool gezielt aufbereitet und die enthaltenen Daten sinnbringend miteinander verknüpft werden. Erst dann hat das Portal eine Chance auf Erfolg. Sind auf der anderen Seite alle Geschäftsprozesse so weit definiert, dass eine Entscheidung über deren technische Unterstützung durch ein Portal qualifiziert gefällt werden kann, und ist der Informationshaushalt des Unternehmens so beschaffen, dass die sinnvolle Kombination der qualitativ hochwertigen, gut strukturierten und miteinander vergleichbaren Daten einen Mehrwert erbringen kann, so wird dies nur gelingen, wenn die Portalsoftware alle technischen Grundlagen für ein intelligentes Informations- und Prozessmanagement mitbringt.

8.3 Softwareauswahl

Zusammenspiel von Technik und Fachlichkeit

■ ■ ■

251

Checkliste „Softwareauswahl Unternehmensportale“

Diese Dualität von fachlichen und technischen Gesichtspunkten spiegelt sich auch in der Checkliste „Softwareauswahl Unternehmensportale“ wieder, die Sie auf der Webseite www.pret-aportal.info finden. Der Prozess der Softwareauswahl geht weit über die Auswahl eines passenden Portalsystems hinaus. Je nach Funktionsumfang des Portalsystems müssen weitere Komponenten ausgewählt, integriert bzw. beschafft werden, um alle an das Unternehmensportal gestellten Anforderungen erfüllen zu können. Hier unterscheidet sich die Portal-Softwareauswahl von anderen Softwareauswahl-Prozessen, z.B. für ein CRM-System, wo es im Wesentlichen auf die alleinige Entscheidung für eine CRM-Software ankommt. Und eben dieser Unterschied stellt an die Portal-Softwareauswahl höhere Anforderungen und macht sie komplexer. Zu der Checkliste möchten wir noch anmerken, dass nicht alle der genannten Kriterien für jedes Unternehmensportalprojekt relevant sind. Zu unterschiedlich sind die Anwendungsschwerpunkte von Portalen. Die Kriterienliste stellt vielmehr die nach unserem Wissen vollständige Überdeckung aller Anwendungsfälle von Unternehmensportalen dar. Wir möchten damit gewährleisten, dass die Checkliste für die Mehrzahl der Leser anwendbar ist – wohl wissend, dass es Anwendungsfälle gibt, die so speziell sind, dass sie hier keine Berücksichtigung gefunden haben. Diejenigen, die mit dem Aufbau eines solch speziellen Portals befasst sind, profitieren aber zumindest von den für alle Portale anwendbaren, allgemeingültigen Kriterien. Auch die für den konkreten Anwendungsfall nicht relevanten Kriterien tragen zum Projekterfolg bei. Sie erlauben nämlich den argumentierten Ausschluss eines Kriteriums. Zu wissen, dass ein Kriterium im gegebenen Kontext keine Rolle spielt, minimiert das Projektrisiko. Wird das Kriterium aber von vornherein gedanklich ausgeblendet, so besteht die Gefahr, etwas Wesentliches zu übersehen. Wir empfehlen deshalb, alle Kriterien kritisch zu betrachten und auf ihre Relevanz hin zu untersuchen.

Tabelle 8.5 Kategorien der Checkliste „Softwareauswahl Unternehmensportale“

Kategorie

Beschreibung

Hersteller

Neben der Marktbedeutung, der Solidität und den Unterstützungsleistungen (Support) des Herstellers werden hier auch die Produktkosten aufgeschlüsselt. Einordnung nach den im Kapitel 3 definierten Anwendungsbereichen und den im Abschnitt 8.1 genannten Unternehmensgrößen. Alle Dienste rund um das Portalprodukt.

Anwendungsbereich

Dienstleistungen

252

■ ■ ■

8 Das richtige System

Kategorie

Beschreibung

Integration

Verfügbare Schnittstellen zu Standardsoftware und Komponenten von Drittanbietern. Vom Portalsystem unterstützte Portal- und Webstandards. Anforderungen des Portalsystems bzgl. Hardware, Systemsoftware und Middleware. Werkzeuge zur Portal-Softwareentwicklung und für den Systembetrieb. Unterstützte Authentifizierungs-, Autorisierungs- und Verschlüsselungsmechanismen. Mechanismen zur Lastverteilung. Hier können zudem Anforderungen an das Systemverhalten formuliert werden. Verteilbarkeit und Clustering. Unternehmens- bzw. projektspezifische Anforderungen, z.B. die Verfügbarkeit vertikaler Portalapplikationen.

Standards Technische Infrastruktur Entwicklung und Administration Sicherheit Performanz

Skalierbarkeit Besonderheiten

Die Checkliste ist in mehrere Kategorien unterteilt, die in Tabelle 8.5 kurz beschrieben sind. In der Spalte „Gewichtung“ kann jedes einzelne Kriterium nach seiner Relevanz gewichtet werden. Erst der Vergleich der gewichteten Ergebnisse verschiedener Portalprodukte ist wirklich aussagekräftig, da die Gewichtung die Ergebnisse der Anforderungsanalyse wiederspiegelt. Zu jedem evaluierten Portalprodukt sollte eine eigene Checkliste angefertigt werden. Um für alle Portalprodukte die gleiche Gewichtung zu verwenden, empfiehlt es sich bei Verwendung der ExcelTabelle, zunächst in der leeren Tabelle die Gewichtung einzutragen und diese dann als Grundlage für die Softwareauswahl zu verwenden. Es ist übrigens nicht ratsam, für jedes Portalprodukt eine eigene Excel-Datei anzulegen. Stattdessen sollte jedes Portalprodukt auf einem gesonderten Blatt abgehandelt werden. Der Vorteil dieser Lösung: Auf einem weiteren Blatt können die Ergebnisse der Evaluierung jedes Portalprodukts sehr einfach zusammengestellt werden.

8.4 Marktübersicht Wenn wir Ihnen im folgenden Abschnitt den Markt der Unternehmensportal-Software und dessen Protagonisten vorstellen, dann bleiben wir dabei neutral. Dieses Buch kann und will keine Kauf-

8.4 Marktübersicht

■ ■ ■

253

Dynamischer Markt

Markteinteilung nach Gartner

254

■ ■ ■

empfehlungen abgeben. Im vorigen Abschnitt haben Sie gesehen, wie differenziert das Anforderungsprofil betrachtet werden muss, um eine passende Software zu finden. Wie sollen wir ohne Kenntnis eines solchen Anforderungsprofils eine Empfehlung aussprechen? Ohne eine fundierte Kenntnis des Anforderungskatalogs eine Produktempfehlung aussprechen zu wollen, wäre ein schlicht unseriöses Vorhaben. Hinzu kommt, dass der Portalsoftware-Markt vergleichsweise jung und entsprechend dynamisch ist. So haben von den Portalsystemherstellern der ersten Stunde nur wenige das erste halbe Jahrzehnt überlebt. Betrachtet man den magischen Quadranten zum Portalmarkt der Analysten von Gartner, so wird man feststellen, dass viele Produkte im Laufe der Zeit den Quadranten gewechselt haben. Abbildung 8.5 zeigt einen Vergleich der „Gartner Magic Quadrants“ aus den Jahren 2002 und 2004 (vgl. Phifer et al. 2002, Phifer et al. 2004). Die Bögen deuten die Entwicklung der Portalprodukte einzelner Hersteller im Verlauf dieser zwei Jahre an. Die Krümmung der Bögen dient nur einem übersichtlichen Layout und ist ohne inhaltliche Bedeutung. Gartner bewertet die Hersteller nach deren Fähigkeit, sich am Markt zu beweisen („Ability to Execute“) sowie nach dem Abdeckungsgrad ihrer Portalvision („Completeness of Vision“). Dazu wird der Markt in vier Quadranten eingeteilt: ■

„Leader“ sind jene Hersteller, denen es gelingt, die Bedürfnisse des Marktes heute und auch zukünftig zu befriedigen. Ihre Sichtbarkeit am Markt ist hoch, sie sind multinational aufgestellt. Die Produkte sind hochgradig integriert und skalierbar.

■

„Challengers“ besitzen zwar eine hohe Marktpräsenz, haben allerdings (noch) kein ganzheitliches Produktangebot.

■

„Niche Players“ konzentrieren sich auf kleinere Märkte (beschränkt auf bestimmte Regionen, Branchen oder Anwendungsfelder) oder decken bestimmte Portalaspekte nur unzureichend ab.

■

„Visionaries“ sind jene Hersteller, die nicht zu den Großen im Markt gehören oder die sich (bisher) nicht auf den Portalmarkt konzentrieren.

8 Das richtige System

Ability to Execute

Challengers

Leaders IBM SAP Oracle BEA

Microsoft

Abb. 8.5 Vergleich der „Gartner Magic Quadrants“ aus den Jahren 2002 und 2004

Plumtree Sun PeopleSoft Novell Vignette Fujitsu Netegrity Sybase Citrix CA BroadVision TIBCO webMethods Hummingbird Epicentric Sybase SeeBeyond Technology ATG Open Text Compuware abaXX

Bowstreet Corechange

InfoImage

Day

Abilizer Solutions Enfish

Niche Players 2002 2004

Visionaries Completeness of Vision

Zunächst fällt auf, dass die meiste Bewegung in den Quadranten der Challengers und Leaders stattgefunden hat. Dort sind – abgesehen von Citrix, Netegrity und Sybase – alle Hersteller auch 2004 noch in der Analyse berücksichtigt worden. Anders sieht es bei den Niche Players und Visionaries aus: Hier sind viele Hersteller aus der Betrachtung der Analysten (und zum Teil sogar vom Markt) verschwunden, aber dafür fast genauso viele neu hinzugekommen. Das Verschwinden hat aber nicht immer damit zu tun, dass die betreffenden Hersteller die Aufnahmekriterien (Fokus auf horizontale Portale, Portalsystem, geographisch signifikante Präsenz, Unternehmensgröße, Marktmomentum) nicht erfüllten. So wurde Epicentric von Vignette übernommen und wird deshalb 2004 nicht mehr gesondert aufgeführt. Die Marktführer (IBM, SAP, BEA, Oracle und Plumtree) haben sich in den vergangenen zwei Jahren in punkto Marktmacht und Abdeckungsgrad weiterentwickelt und sich deutlich von den Mitbewerbern absetzen können. Nur wenige Produkte haben sich zurückentwickelt – darunter Computer Associates (CA), TIBCO und ATG. Kaum bewegt hat sich Sun mit seinem Java System Portal Server.

8.4 Marktübersicht

■ ■ ■

255

Weitere Ordnungskriterien

Gartner weist ausdrücklich darauf hin, dass die Analyse nicht dazu verleiten soll, sich bei der Softwareauswahl auf die Hersteller aus dem „Leader“-Quadranten zu konzentrieren. Auch nach Lektüre der Analyse kommt man also um eine unternehmensspezifische Bewertung der Kriterien nicht herum. Man kennt allerdings den Markt und die strategische Ausrichtung einzelner Hersteller ein wenig besser. In der Regel ist eine der beiden folgenden unternehmerischen Strategien für einen Quadrantenwechsel oder eine deutliche Positionsveränderung im Quadranten verantwortlich: Entweder ergänzt der Portalsystemhersteller sein Produkt durch Eigenentwicklung um die fehlende Funktionalität, oder er schließt die Lücke durch Firmenzukäufe. So hat z.B. die Firma Open Text ihr Produktportfolio in Richtung Portale durch den Zukauf von Corechange ergänzt. Die fehlende Funktionalität in den Bereichen Content Management und Workflow holte man sich durch die Übernahme von Gauss und Ixos ins Haus. Auf ähnliche Art und Weise wandelt sich Vignette durch die Übernahme von Epicentric vom Hersteller von ContentManagement-Systemen zum Portalsystemanbieter. Neben dem Gartner-Quadranten gibt es andere Marktsegmentierungen, die sich z.B. an der Herkunft der Hersteller bzw. deren Lösung orientieren. So zitieren Born u. Diercks (2004) die Beratungsgesellschaft Wolfgang Martin Team, die den Portalmarkt wie folgt unterteilt: ■

Stand-Alone-Portalentwicklungsumgebungen: Plumtree, Hummingbird, abaXX und Computer Associates,

■

Integrationsplattformen mit Portalplattform IONA, SeeBeyond, TIBCO, WebMethods,

■

Applikations-Infrastruktursoftware (Application Server + Portalentwicklungsumgebung): BEA, IBM, Microsoft, Oracle, Sun, Sybase,

■

ERP-Portale: Peoplesoft, SAP, Siebel,

■

Business-Intelligence-Portale: Arcplan, Business Objects, Cognos, SAS.

als

Zusatz:

Die enorme Dynamik des Portalmarkts macht solche Klassifizierungen zu Momentaufnahmen mit geringer Halbwertszeit. Der Qua(dra)ntensprung von Vignette – vom Nischenprodukt in die Führungsriege innerhalb von zwei Jahren – zeigt, wie stark sich die Portalprodukte noch ändern. Gartner rechnet übrigens mit einem weiteren Wachstum des Portalmarkts bis zum Jahr 2006.

256

■ ■ ■

8 Das richtige System

Ein Wort noch zu den Beweggründen der ERP-Systemhersteller, in den Portalmarkt einzusteigen. SAP hat das hauseigene Enterprise Portal zur universellen Benutzungsoberfläche der Zukunft erklärt (vgl. Niemann 2003). Ein Grund dürfte der Wunsch nach Vereinheitlichung der Benutzungsoberflächen sein. Damit verbunden sind Kosteneinsparungen durch Standardisierung und die Umsetzung des „Thin Client“-Konzepts. Wenn nämlich auf den Klienten-Systemen (damit sind in der Regel die PCs der ERP-Systembenutzer gemeint) keine umfangreiche Software mehr installiert werden muss (wie es bisher bei der SAP GUI notwendig war), dann verringert sich insbesondere in großen und mittleren Unternehmen der Installations- und Verwaltungsaufwand für die ERP-Systeme erheblich. Eine dritte Möglichkeit zur Komplettierung des Portfolios ist die Bildung strategischer Partnerschaften. Diese waren insbesondere in den Anfängen der Portalentwicklung notwendig, da aufgrund der proprietären Programmierschnittstellen die Entwicklung von Portalprogrammen eng an einzelne Portalsysteme gekoppelt war. Diese Abhängigkeit von einem bestimmten Portalsystem beschränkte die Absatzmöglichkeiten der Portalprogramme. Dies ist auch der Grund, warum sich Drittanbieter nur zögerlich auf diesen Markt wagten und ihre Applikationen nur für die wenigen führenden Portalsysteme anboten. Mit der Integration der standardisierten Portlet-API sowie der Web Services for Remote Portlets (WSRP) ergeben sich hier völlig neue Möglichkeiten (siehe auch Kapitel 7). Den Anbietern von Portalapplikationen bieten die Standards den Vorteil, dass sie ihre Bausteine für alle standardkonformen Produkte im Markt anbieten und ihren bisherigen Entwicklungs- und Wartungsaufwand vermindern können (vgl. Koschek 2003). Neben den in der Gartner-Studie untersuchten kommerziellen Portalsystemen gibt es einige Open-Source-Projekte, die eine Portalinfrastruktur komplett oder in Teilen zur Verfügung stellen. Stellvertretend soll das Jetspeed-Projekt der Apache Software Foundation vorgestellt werden. Jetspeed ist ein Java- und XML-basierendes Portalsystem. Es hat eine lange und erfolgreiche Entwicklungsgeschichte hinter sich. Einige Jetspeed-Komponenten findet man auch in kommerziellen Portalsystemen. Mit der aktuellen Version 2 (portals.apache.org/jetspeed-2/) unterstützt Jetspeed die standardisierte Portlet-API (vgl. Abschnitt 7.5.1). Außerdem nutzt es ein standardisiertes Verfahren für das Deployment von Portlets. Die Komponentenarchitektur ist flexibel und skalierbar. Für die Präsentation der Daten stehen verschiedene Layout-Sprachen und Rahmenwerke zur Verfügung, z.B. Velocity (jakarta.apache.org/velocity/) oder JSP (JavaServer Pages).

8.4 Marktübersicht

ERP-Portale

Strategische Partnerschaften

Open-SourceProjekte

■ ■ ■

257

Diese für Open-Source-Projekte typische Vorgehensweise, sich der Ergebnisse anderer Open-Source-Projekte zu bedienen, ist zugleich das größte Marketing-Problem des freien Softwaremarktes. Potenzielle „Kunden“ eines Open-Source-Portalsystems befürchten oft, dass durch diese Kombination mehrerer Projekte der Einarbeitungsaufwand in die verschiedenen Technologien zu hoch ist – zumindest höher als bei einem System, in dem alle Komponenten „aus einem Guss“ sind. Zudem könnte es passieren, dass eines der benötigten Projekte irgendwann nicht mehr weiterentwickelt wird. Beiden Argumenten kann entgegnet werden. Die Tatsache, dass Open-Source-Projekte einander verwenden, bedeutet auch, dass deren Schnittstellen sauber definiert und dokumentiert sein müssen. Sonst könnte die Integration nicht gelingen. Wie am Beispiel der Layout-Technologien für Jetspeed 2 gezeigt wurde, bieten viele Open-Source-Projekte alternative Implementierungen für bestimmte Funktionen an. Diese Wahlmöglichkeit fehlt bei vielen kommerziellen Systemen. Hier verlässt man sich nicht selten auf wenige hauseigene oder standardisierte Lösungen. Oft sind die Komponenten solcher Systeme wesentlich enger gekoppelt, die Schnittstellen aber nur unzureichend oder überhaupt nicht offengelegt. Abhängig von den eigenen Anforderungen an ein Portalsystem müssen solche Faktoren in die Softwareauswahl mit einbezogen werden. Sollte ein Open-Source-Projekt nicht mehr weiterentwickelt werden, so besteht kein Grund zur Sorge. Hier verhält es sich wie mit jeder anderen Software auch: Neue Versionen sollte man nur dann verwenden, wenn diese einen Mehrwert gegenüber der aktuell eingesetzten Version bieten. Gibt es keine neue Version, dann bleibt man bei der alten. Sobald eine nicht implementierte Funktionalität dringend benötigt wird, kann diese auch selbst implementiert werden. Der Quellcode ist bei allen Open-Source-Projekten für jedermann frei zugänglich (daher der Name). Oft stehen die ursprünglichen Entwickler auch nach erfolgter Abkündigung ihres Projektes für Fragen und Hilfestellungen zur Verfügung. Wer eine detaillierte Übersicht über den Markt der Portalsysteme sucht, der wird z.B. bei Born und Diercks (2004) oder Hoffmann (2004) fündig. In beiden Untersuchungen werden neben den kommerziellen Produkten auch Open-Source-Projekte berücksichtigt. Bei Drucklegung dieses Buchs sind mit Sicherheit aktuellere Artikel verfügbar. Aus diesem Grund haben wir hier auf eine Hersteller- und Produktliste verzichtet. Eine Liste aktueller Publikationen zu diesem Thema finden Sie auf unserer Webseite www.pret-a-portal.info.

258

■ ■ ■

8 Das richtige System

9 Projektorganisation

Unternehmen schätzen die Herausforderungen, die die Einführung eines Unternehmensportals mit sich bringt, oftmals als rein technische Problemstellung ein. In der Praxis zeigt sich aber, dass es vor allem die organisatorischen Aspekte sind, die über Erfolg und Misserfolg eines Unternehmensportals entscheiden. Welche Bedeutung in diesem Zusammenhang der Organisation und dem Management eines Portalprojektes zukommt, wollen wir in diesem Kapitel näher beleuchten. Dabei verzichten wir auf eine Beschreibung allgemeingültiger Methoden und Vorgehensweisen und beschränken uns auf die speziell für Portalprojekte relevanten Aspekte des Projektmanagements.

Kurz gefasst

9.1 Spezielle Herausforderungen in Portalprojekten Schon die Zielsetzungen, die mit einem Portalprojekt verknüpft sind, zeigen, dass ein Portal nie als ein rein technisches Vorhaben verstanden werden kann. In unserer täglichen Praxis stellen wir aber immer wieder fest, dass Projektleiter glauben, „Packung aufreißen – installieren – fertig“ sei alles, was bei Portalen zu beachten ist. Dass es so einfach nicht gehen kann, zeigt Abbildung 9.1. Neben der Integration technischer Komponenten müssen auch Menschen und Abteilungen in den Projektprozess eingebunden werden. Darüber hinaus müssen Arbeitsschritte und Ergebnisse überwacht und aktiv gestaltet werden. Nur durch die Berücksichtigung der verschiedenartigen Einflussfaktoren können Architektur, Prozess und Organisationsform des Portals optimal gestaltet und das Portalprojekt zum Erfolg geführt werden.

9.1 Spezielle Herausforderungen in Portalprojekten

■ ■ ■

259

Integration in Anwendungsarchitektur (EAI)

Sauberes Software Engineering

Integration technischer Komponenten

n tio

Unternehmensportal

Sponsoring von höchster Stelle Frühes Einbeziehen der Anwender – Change Management

Sensibilität für Benutzerwünsche

260

■ ■ ■

ektur hit rc

Orga nis a

Ergonomie

Integration von Arbeitsschritten und Ergebnissen Stringentes Änderungsmanagement

Prozes s

Komponenten (kommerziell, Open Source, individuell)

Unterstützung durch die Unternehmensführung

"Bebauungsplan"

Erprobte Integrationsmuster

A

Abb. 9.1 Einflussfaktoren auf das Management eines Portalprojektes

Langlaufende, vielstufige Projekte Refactoring Partnermanagement

Eindeutige Eigner der Anforderungslage Integration von Menschen und Abteilungen

Die Einführung eines Portals tangiert meist weite Teile des Unternehmens, wenn nicht sogar das gesamte Unternehmen. Die Ziele, die mit der Einführung eines Portals verfolgt werden, sind außerdem in vielen Fällen direkt aus der Unternehmensstrategie abgeleitet. Deshalb ist im Regelfall die Entscheidung für den Aufbau eines Portals eine Unternehmens- und keine alleinige Abteilungsentscheidung. Aus diesem Grund ist für die Durchführung und Vermarktung des Projektes auch die direkte Unterstützung durch die Unternehmensführung notwendig. Nur dann kann sichergestellt werden, dass das Projekt die nötige Aufmerksamkeit und Mitarbeit erlangt und die Ergebnisse schlussendlich der Strategie des Unternehmens entsprechen. Es ist die Aufgabe des Projektmanagements, die Unternehmensführung in das Projekt einzubeziehen, kontinuierlich Zwischenergebnisse und den aktuellen Projektstatus zu kommunizieren sowie die notwendige Unterstützung zu fordern. Durch die Einführung eines Unternehmensportals sind eine Vielzahl von Mitarbeitern in ihrer täglichen Arbeit direkter betroffen, als dies bei der Einführung der meisten anderen IT-Projekte der Fall ist. Durch die mit der Portaleinführung einhergehenden Veränderungen etablierter Arbeitsabläufe entstehen oftmals Verunsicherungen und Ängste. Hier ist das Projektmanagement gefordert, um die Ziele, die mit dem Unternehmensportal verfolgt werden, so zu vermarkten, dass für den einzelnen Mitarbeiter ein Nutzen erkennbar wird und so

9 Projektorganisation

die Bereitschaft, sich auf Neues einzulassen, steigt. Das Projektmanagement muss ein Gespür für die Kultur des Unternehmens entwickeln. Oftmals sind es ja gerade die leisen Zwischentöne in den Äußerungen der Mitarbeiter, die ihre tatsächlichen Einstellungen und Ängste verraten. Diese Tendenzen muss das Projektmanagement wahrnehmen, um frühzeitig auf Ängste und Ablehnung reagieren zu können und auch die eigene Planung auf Fehleinschätzungen hin zu überprüfen. Immerhin soll das Portal die von allen Mitarbeitern genutzte Basis der Kommunikation und Informationsversorgung innerhalb des Unternehmens sein. Bei der Einführung eines Portals können Unternehmen in der Regel kaum auf Erfahrungswerte zurückgreifen. Vielleicht wurden bereits einige Erfahrungen in Integrationsprojekten oder beim Aufbau eines Intranets gesammelt. Die Herausforderungen, die mit der Einführung eines Unternehmensportals verbunden sind, sind aber zumeist neu. Dies führt dazu, dass viele Anforderungen und Zielsetzungen zu Beginn eines Portalprojektes noch nicht oder nicht ausreichend konkret bekannt sind und sich in der Folge über die Projektlaufzeit häufig verändern. Die Planung des Projektes muss diesem Umstand Rechnung tragen. Sie muss den Spagat zwischen einer durchgängigen und konsequenten Projektstrategie und einer größtmöglichen Flexibilität in der Planung bewältigen. Portalprojekte sind durch die Einbeziehung heterogener Applikationen technisch anspruchsvoll und komplex. Das Projektmanagement muss nicht nur ein Verständnis für die Kultur und die Prozesse des Unternehmens mitbringen, sondern muss außerdem in der Lage sein, das Projekt technisch zu überblicken und zu verstehen. So ist es nicht ausreichend, die geschäftskritischen Prozesse des Unternehmens zu kennen und beschreiben zu können. Es muss auch die Fähigkeit vorhanden sein, zu analysieren, welche dieser Prozesse sich sinnvoll durch ein Portalsystem unterstützen lassen. Außerdem lässt sich nicht allein mit dem reinen Verständnis für die fachlichen Anforderungen an ein Portal das fachlich wie technisch optimale System auf dem Portalmarkt auswählen.

Fehlende Erfahrungswerte

Technisches Verständnis

Je nach Größe und Komplexität des Projektes sollte das Projektmanagement nicht nur von einer einzelnen Person übernommen werden. Es hat sich bewährt, die Planungs-, Steuerungs- und Kontrollaufgaben des Projektes arbeitsteilig von verschiedenen Spezialisten übernehmen zu lassen. Ein erster Schritt ist beispielsweise die Unterscheidung zwischen Chefarchitekt und Projektkoordinator. Die Entscheidung, welche Geschäftsprozesse sich technisch gut unterstützen lassen, muss der Chefarchitekt verantworten. Den daraus re-

9.1 Spezielle Herausforderungen in Portalprojekten

■ ■ ■

261

sultierenden Zeitplan muss der Projektkoordinator aufbauen und kontinuierlich überwachen.

Kommunikation im Projekt

Die Besetzung des Projektteams

262

■ ■ ■

Die Vielfältigkeit der technischen Komponenten eines Portals (vgl. Abschnitt 6.3) zeigt, wie wichtig es ist, dass das Projektmanagement die technischen Aspekte bei der Einführung eines Unternehmensportals überblicken und verstehen kann. Nur ein sauberes SoftwareEngineering verhindert, dass das Projekt in technischen Problemen stecken bleibt, und sichert die langfristige technische und fachliche Skalierbarkeit des Portals. Neben dem Wahrnehmen der Überwachungs- und Kontrollfunktionen muss das Projektmanagement außerdem die Kommunikation innerhalb des Projektes fördern. Dieser kommt gerade in Portalprojekten mit einer Vielzahl involvierter Interessengruppen eine große Bedeutung zu. Um sicherzustellen, dass alle Projektbeteiligten stets von den gleichen Voraussetzungen und Zielen ausgehen, muss das Projektmanagement auf allen Hierarchieebenen der Organisation für die Transparenz des Projektstatus sorgen. Daneben müssen die Ziele des Projektes klar an alle Beteiligten kommuniziert werden. Dass diese Ziele den Projektmitarbeitern bekannt sind und von ihnen geteilt werden, ist die Voraussetzung für ein motiviertes und eigenverantwortliches Arbeiten und Erkennen von Zusammenhängen. Je eigenverantwortlicher die Projektmitarbeiter arbeiten, desto weniger Kontroll- und Koordinationsaufgaben muss das Projektmanagement wahrnehmen. Die Besetzung des Projektteams muss auf die besonderen Herausforderungen in Portalprojekten ausgerichtet werden. Neben der Entwicklung der Portalapplikationen und der Etablierung der Portalinfrastruktur müssen stets die fachlichen Aspekte des Portals, die Geschäftsprozesse sowie die organisatorischen und kulturellen Einflussfaktoren des Portalprojektes im Auge behalten werden. Um die Komplexität eines Portalprojektes beherrschen zu können, müssen sich diese erforderlichen Teildisziplinen in der Besetzung des Projektteams wiederfinden. Neben technischen Spezialisten bedarf es erfahrener Mitarbeiter, die die Abläufe und Zusammenhänge innerhalb des Unternehmens kennen, sowie Spezialisten der jeweiligen fachlichen Bereiche. Um trotz dieser Vielzahl beteiligter Personen und Kompetenzen einen effektiven Projektablauf sicherzustellen, ist es wichtig, dass die unterschiedlichen Spezialisten möglichst eng zusammenarbeiten und ein intensiver Austausch innerhalb des Projektteams stattfindet. Die enge Zusammenarbeit von Mitarbeitern der Fachabteilungen und IT-Spezialisten unterstützt, dass auch zwischen den Domänen dieselbe Sprache gesprochen wird. Das Verständnis für die anderen Sichtweisen des Projektes wächst, Missverständnisse

9 Projektorganisation

und Fehlentwicklungen können frühzeitig erkannt werden oder treten erst gar nicht auf. Um im Projekt einen einheitlichen Sprachgebrauch zu etablieren, bietet sich die Einführung eines Projektglossars an (vgl. Abschnitt 8.2.1). In diesem Zusammenhang ist es auch entscheidend, dass das Projektmanagement die Verantwortlichkeiten und Rechte innerhalb des Projektes klärt und an alle Beteiligten kommuniziert. Während dies für die Entwicklungsphase des Projektes noch relativ selbstverständlich erscheint, wird gerne vergessen, dass es auch nach der Einführung des Portals klare Zuständigkeiten geben muss. Der Betrieb des Portals kann nur reibungslos funktionieren, wenn klar ist, wem das Portal „gehört“, wer was entscheiden darf, und wie Rechte und Pflichten bei der Pflege und Weiterentwicklung des Portals und seiner Inhalte verteilt sind. Die Grenzen des eigenen Unternehmens sind oftmals nicht die Grenzen des Portalprojektes. In diesem Fall stellt die Einbeziehung externer Partner eine weitere Herausforderung für das Projektmanagement dar. Wo sich bei einem internen Portalprojekt das Management bereits mit einer Vielzahl unterschiedlicher Interessengruppen und fachlicher sowie technischer Anforderungen auseinandersetzen muss, dort potenzieren sich diese Projektschnittstellen durch die Einbindung externer Partner. Wie wir bereits dargestellt haben, sind Portalprojekte sowohl in technischer als auch in organisatorischer Hinsicht komplexe Projekte. Ein Portal setzt Veränderungsvorgänge in Gang und stellt etablierte Strukturen und Prozesse in Frage. Deshalb stellen Portalprojekte insbesondere an die soziale Kompetenz der Projektleitung besondere Ansprüche. Diesen Herausforderungen muss sich das Projektmanagement stellen und dafür Sorge tragen, dass das Projekt im zeitlichen und budgetären Plan verläuft. Wie Abb. 9.2 zeigt, hilft Projektmanagement mit seinen in diesem Kapitel beschriebenen Aufgaben, Zeit, Kosten und Risiko des Projektes zu minimieren und im Gegenzug die Produktivität der Projektarbeit durch koordinierende Maßnahmen zu erhöhen. Seinen vollen Wirkungsspielraum kann das Projektmanagement aber nur dann entfalten, wenn es durchgängig und umfassend im Projekt betrieben wird. Das bedeutet einerseits, dass das Projektmanagement bereits in der Planungsphase des Portals beginnt und bis zum Betrieb des Portals reicht. Andererseits fokussiert durchgängiges Projektmanagement alle Hierarchieebenen der (Projekt-)Organisation und bindet sie in den Verlauf des Projektes ein.

9.1 Spezielle Herausforderungen in Portalprojekten

Einbindung externer Partner

■ ■ ■

263

Abb. 9.2 Der Nutzen von Projektmanagement

Entwicklungskosten

100 80 60

punktueller

89

Ansatz

umfassender

62

40 20 Risiko

33

100

0

40

100

Termine

70

100

100 118 Produktivität

Qualitätskosten

9.2 Die Schritte des ProjektmanagementProzesses Nachdem das Warum des Projektmanagements nun klar ist, soll im Folgenden das Wie genauer betrachtet werden. Ausgehend von einem Standardprozess, wie er bei vielen IT-Projekten Verwendung findet, werden die portalspezifischen Aspekte herausgearbeitet und in diesen Prozess integriert.

9.2.1 Der Prozess des Projektmanagements Abbildung 9.3 stellt einen Standardprozess des Projektmanagements dar, wie man ihn in vielerlei Projekten unterschiedlichster Art und damit auch in Portalprojekten wiederfinden kann. Da eine vollständige Betrachtung des Projektmanagementprozesses nicht Ziel dieses Buches ist und dessen Rahmen sprengen würde, werden im Folgenden nur diejenigen Aspekte näher beleuchtet, die bei Portalprojekten eine besondere Rolle spielen. Der abgebildete Standardprozess bietet einen Überblick über den Gesamtprozess, in den die für Portale relevanten Aspekte einsortiert und bewertet werden.

264

■ ■ ■

9 Projektorganisation

Unternehmen / Auftraggeber Projektakte

Initialisierung

Auftrag Umfeld Ziele

Planung

Risiken Organisation

Abb. 9.3 Der ProjektmanagementStandardprozess (nach GPM Deutsche Gesellschaft für Projektmanagement)

Projektprozess

Phasen

Durchführung

Struktur Termine Ressourcen

Überwachung und Steuerung

Finanzen Kontrolle Prognosen

Abschluss

Verträge Ergebnisse

Lernende Organisation

9.2.2 Der richtige Projektstart Bevor die Frage nach dem Wie des Portalprojektes (Vorgehensweise und Projektplanung) gestellt werden kann, müssen die Verantwortlichen des Projektes erst die Frage nach dem Warum beantworten. Gemäß dem im Abschnitt 8.2 dargestellten Prozess der Anforderungsanalyse hat das Projektmanagement einen Überblick über die Ziele, die durch die Einführung eines Portals erreicht werden sollen. Im Anforderungskatalog sind die Funktionen und Dienste beschrieben, die das Portal zur Verfügung stellen muss. Ist aber ein Portal wirklich das geeignete Werkzeug, um diese Ziele zu erreichen? Oder übersteigt gar der Aufwand einer Portaleinführung den zu erwartenden Nutzen? Diese Fragen müssen sich die Verantwortlichen des Portalprojektes stellen, bevor sie mit der konkreten Planung des Projektes beginnen. Eine Gegenüberstellung von Nutzen und Kosten muss die Entscheidung für die Einführung eines Portals verifizieren.

9.2 Die Schritte des Projektmanagement-Prozesses

Ziele des Portalprojektes

■ ■ ■

265

Ressourcenbedarf

Kosten und Nutzen

Die initiale Projektplanung

266

■ ■ ■

Zu diesem Zweck werden die zu implementierenden Portalfunktionen mit ihrem geschätzten Ressourcenbedarf – Zeit, Geld, Personen – bewertet. Der konkrete Implementierungsaufwand einzelner Funktionen hängt stark von dem gewählten Portalsystem ab. Bringt das Portal z.B. bereits standardisierte Adapter zur Integration der wichtigsten Applikationen mit, und sind einige der gewünschten Funktionen bereits als fertige Portlets im Lieferumfang enthalten, so verringert dies den Entwicklungsaufwand des Portals erheblich. Um die Schätzungen der Aufwände vornehmen zu können, muss daher bereits das gewählte Portalsystem bekannt sein. Den Aufwänden wird der Nutzen der einzelnen Portalfunktionen (d.h. deren Beitrag zum ROI) gegenübergestellt. Wie im Kapitel 11 noch ausführlich dargestellt wird, lässt sich dieser Nutzen oftmals nicht ohne weiteres ermitteln und in konkreten Zahlen ausdrücken. Während beispielsweise der Nutzen einer Portalapplikation zur Reduzierung der Antwortzeiten im Call Center noch relativ gut messbar ist, wird dies bei der Feststellung einer gestiegenen Zufriedenheit der Kunden oder Mitarbeiter ungleich schwieriger sein. Das Projektmanagement muss hier ein Bewertungssystem entwickeln, das auch den „weichen“, nicht konkret messbaren Nutzen in die Gesamtbetrachtung für eine Portalfunktion einfließen lässt. Außerdem wird es natürlich auch Portalfunktionen geben, die keinen direkten Beitrag zum Nutzen eines Portals haben. Dies sind beispielsweise Basisdienste wie die Sessionverwaltung. Sie erbringen zwar keinen fachlichen Nutzen, ohne sie kann ein Portal aber nicht sinnvoll betrieben werden. Neben den Aufwänden für die Implementierung einzelner Funktionen müssen natürlich auch die Aufwände für Softwarelizenzen, die Projektinfrastruktur, das Projektteam und spätere Betriebskosten in die Nutzenbetrachtung einfließen. Die Analyse des Nutzenpotenzials ist einer der ersten Schritte bei der Planung einer erfolgreichen Portaleinführung – und unter Umständen auch der letzte. Dies ist dann der Fall, wenn die KostenNutzen-Bilanz des geplanten Portals ergibt, dass die Zielvorstellungen unrealistisch und nicht (oder nicht mit vertretbarem Aufwand) zu erreichen sind. Gerade die Geschäftsführung und das Controlling werden ein großes Interesse daran haben, die Wirtschaftlichkeit ihrer Investition sicherzustellen, bevor die Umsetzungsphase des Projektes startet. In diesem Sinne dient eine positive Kosten-Nutzen-Bilanz nicht nur der Argumentation für die Einführung eines Portals, sondern ist auch ein wichtiges Marketinginstrument, um die Geschäftsführung für das Projekt zu gewinnen.

9 Projektorganisation

A9

Nutzen

A1

A3

+

A6

A7

A5

Abb. 9.4 Bewertung der gewünschten Portalfunktionen

A2

A4

A8

Einfache Implementierung

Daneben beeinflusst die wirtschaftliche Einschätzung der einzelnen Funktionen die Planung des konkreten Projektvorgehens. Reicht die Projektlaufzeit oder das veranschlagte Budget nicht aus, um alle gewünschten Funktionen in der ersten Stufe der Portalentwicklung zu realisieren, dann sollten vorrangig diejenigen Funktionen implementiert werden, die eine signifikante Wertschöpfung versprechen. Um die Entscheidung für die Einführungsprioritäten einzelner Portalfunktionen zu treffen, kann ein Quadrant genutzt werden, wie er in Abb. 9.4 dargestellt ist. Die einzelnen Funktionen werden nach geschätztem Implementierungsaufwand und erwartetem Nutzen in ein Koordinatensystem eingeordnet. Auf diese Weise können die geforderten Funktionen übersichtlich dargestellt und deren Chancen und Risiken einfach bewertet werden. Je nach Gegenstand und Ziel der Betrachtung können an den Koordinaten auch andere Kriterien gegenübergestellt werden, z.B. Messbarkeit und Realisierbarkeit. Der Einsatz einer Quadrantenanalyse ist dann hilfreich, wenn für die Geschäftsführung bereits mit dem Prototyp ein messbarer ROI nachgewiesen werden soll. Durch seine einfache Darstellung hilft ein Portfolio, sich einen schnellen Überblick über die Anforderungssituation des Projektes zu verschaffen und getroffene Entscheidungen gegenüber den Portalbenutzern und der Geschäftsführung zu begründen. Bei der Chancen- und Risikenbewertung eines Portals darf nicht vernachlässigt werden, dass der Erfolg eines Portals mindestens so sehr von der Akzeptanz der Benutzer wie von der betriebswirtschaft-

9.2 Die Schritte des Projektmanagement-Prozesses

Einführungsprioritäten von Portalfunktionen

■ ■ ■

267

Einführungsstrategie

Big Bang Step by step

Grobkonzept

268

■ ■ ■

lichen Zielerreichung abhängt, zumal diese beiden Faktoren einander bedingen. So hat z.B. das Abrufen des Kantinenplans über das Portal an sich noch keine wertschöpfende Wirkung, wird aber zur Nutzung des Portals durch die Mitarbeiter beitragen. Sind die in der ersten Iteration des Projektes zu implementierenden Funktionen festgelegt worden, dann wird die Projektplanung weiter konkretisiert. Eine Einführungsstrategie muss mit den Initiatoren des Projektes und der Geschäftsführung abgestimmt und festgelegt werden. Dabei gilt es, sich zwischen zwei klassischen Einführungsszenarien zu entscheiden: der Big-Bang-Methode und der Step-by-Step-Methode. Mit der Big-Bang-Methode wird das Projekt zu einem definierten Zeitpunkt in seinem gesamten Funktionsumfang auf einen Schlag im Unternehmen eingeführt. Die Step-byStep-Methode dagegen geht davon aus, dass einzelne fertiggestellte Funktionen bereits während der Implementierungsphase produktiv gesetzt und den Nutzern zugänglich gemacht werden. Die Big-BangMethode hat den Vorteil, dass das fertige Portal unmittelbar zur Verfügung steht und so bei den Mitarbeitern keine Verunsicherung entsteht, ob die von ihnen gewünschten Funktionen in der Umsetzung vergessen worden sind. Unter Umständen ist auch die Aufmerksamkeit, die man mit der einmaligen vollständigen Einführung des Portals bei dessen Zielgruppe erreicht, größer. Allerdings erhöht dieses Vorgehen die Komplexität der Einführung und die Gefahr, dass Fehlentwicklungen erst zu spät erkannt werden. Die Step-by-StepMethode reduziert die technische Komplexität der Einführung erheblich, da einzelne Komponenten des Portals sukzessive eingeführt werden. Im Gegenzug verlängert sich durch dieses Vorgehen im Regelfall aber die Gesamtprojektlaufzeit. Die Step-by-StepMethode bietet allerdings den Vorteil, dass die Entwicklung eng mit den Nutzern des Systems abgestimmt werden kann und das Benutzerfeedback direkt in die weitere Projektplanung einfließen kann. Aus diesem Grund hat sich die Step-by-Step-Methode in Portalprojekten bewährt. In Kombination mit Prototypen, auf die wir in diesem Kapitel noch näher eingehen werden, verringert die Stepby-Step-Methode das Risiko von Fehlentwicklungen und hilft, eine hohe Benutzerakzeptanz sicherzustellen. Die Entscheidung für eines der vorgestellten Einführungsszenarien ist entscheidend für die Ablaufplanung des Projektes. Parallel zur Festlegung der Vorgehensweise wird das Grobkonzept für das Portalprojekt entwickelt. In diesem werden die fachlichen und technischen Funktionen des Portals aufgeführt, Lösungsansätze entwickelt und die Logik der Benutzungsoberfläche beschrieben. Das Grobkonzept umfasst außerdem die Beschreibung der technischen Infrastruktur (Hard- und Software) und die Festle-

9 Projektorganisation

gung der relevanten organisatorischen und technischen Standards. Das Grobkonzept stellt somit den ersten Projektrahmenplan dar. Abgeleitet aus dem Grobkonzept kann der Projektplan erstellt werden. Dazu werden die im Grobkonzept beschriebenen Funktionen in Arbeitspakete übersetzt und auf dem Zeitstrahl der Projektlaufzeit verteilt. Um Portalprojekte sinnvoll planen und kontrollieren zu können, bietet sich der Einsatz eines speziellen Projektmanagement-Werkzeugs an. Mit diesem lassen sich unter anderem Abhängigkeiten zwischen den einzelnen Arbeitspaketen definieren und Auswirkungen veränderter Rahmenbedingungen schnell ermitteln. Außerdem unterstützt es bei der Verwaltung der Projektressourcen. Gerade in Portalprojekten, bei denen in der Regel Erfahrungswerte fehlen und die komplex und damit besonders risikoanfällig sind, ist eine Schönwetter-Planung die falsche Herangehensweise. Das Projektmanagement muss sich der zahlreichen Einflussfaktoren eines Portalprojektes bewusst sein und diesen mit einem entsprechenden Risikomanagement Rechnung tragen. Dazu gehört neben einer Identifikation aller Risiken und der Einschätzung ihrer Eintrittswahrscheinlichkeit auch die Planung von Maßnahmen zur Risikominderung und Fallback-Szenarien. Über die gesamte Projektlaufzeit hinweg müssen die identifizierten Risiken verfolgt und nach neuen Risiken gesucht werden. Das Ziel eines effektiven Risikomanagements muss es sein, Risiken offensiv anzugehen, anstatt darauf zu vertrauen, dass diese nicht eintreten werden. Die zahlreichen Schnittstellen zu den IT-Systemen und anderen Projekten machen Portalprojekte anfällig für unvorhersehbare Änderungen der Rahmenbedingungen. Darum ist es ratsam, in der ersten Iteration eines Portalprojektes nicht den Anspruch zu verfolgen, möglichst viele Funktionen zu implementieren. Schlussendlich wird sich der Erfolg des Projektes an der Einhaltung der Zeit-, Leistungsund Kostenvorgaben messen müssen und nicht an der Anzahl unvollständig implementierter Funktionen. Funktionen, auf die in der ersten Stufe einer Portaleinführung verzichtet werden kann, können für ein späteres Release geplant werden, in dem sie mit den gewonnenen Erfahrungen sicherer zu planen und schneller umzusetzen sind. Den einzelnen Arbeitspaketen werden die Mitglieder des Projektteams verantwortlich zugeordnet. Für das Projekt ist es entscheidend, dass die einzelnen Teammitglieder ihre jeweiligen Zuständigkeiten genau kennen und in diesem Rahmen eigenverantwortlich arbeiten können. Durch die klare Aufteilung der Verantwortlichkeiten können die Domänenspezialisten optimal eingesetzt werden, und durch eine klare Kompetenzverteilung werden Streuverluste in der Projektkommunikation vermieden.

9.2 Die Schritte des Projektmanagement-Prozesses

Projektplanung

Risikomanagement

Festlegung der Verantwortlichkeiten

■ ■ ■

269

Frühzeitiges Etablieren eines ChangeManagementProzesses

270

■ ■ ■

Auch wenn eine detaillierte Aufnahme und Analyse der Anforderungen und Zielsetzungen eine entscheidende Voraussetzung für den erfolgreichen Projektverlauf ist, darf man sich nicht der Illusion hingeben, dass mit der ersten Analyse die Anforderungen vollständig und endgültig erfasst worden sind. Jeder, der einmal an der Durchführung eines fachlich initiierten IT-Projektes beteiligt gewesen ist, kennt das Problem der sich über die Projektlaufzeit hinweg ständig verändernden Anforderungen. Während der Konzeption und Umsetzung eines Projektes wird der Blick auf mögliche Lösungsszenarien immer detaillierter und Unschärfen in den Anforderungen somit offensichtlicher. Daneben zeigt die Praxis oftmals, dass doch nicht alles so einfach ist, wie es in der Theorie aussah. Je greifbarer die im Projekt entwickelten Lösungen werden, umso mehr Anhaltspunkte gibt es, um über deren Richtigkeit zu diskutieren. Von diesem Effekt kann in Portalprojekten mit einer Vielzahl fachlicher Interessengruppen mit Sicherheit ausgegangen werden. Das Projektmanagement ist hier gefordert, einen stabilen Anforderungs- und Annahmenkatalog zusammenzustellen, der eine verlässliche Projektplanung möglich macht. Andererseits muss das Projektmanagement dem Lerneffekt, der sich während des Projektes einstellt und zu sich verändernden Anforderungen führt, durch eine größtmögliche Flexibilität in der Planung Rechnung tragen. Zu diesem Zweck wird frühzeitig ein Change Management im Projekt etabliert. Das Change Management stellt sicher, dass Anforderungen und Ideen, die nach der Anforderungsanalyse in das Projekt eingebracht werden, nicht untergehen. Im Gegenzug verhindert ein Change Management aber auch ein Ad-hoc-Vorgehen (im Sinne eines „Kannst du noch mal eben kurz...“) bei der Implementierung des Portals. Die Anforderungen werden im Rahmen des Change Managements hinsichtlich ihres Aufwands und ihrer Priorität bewertet und fließen in die ReleasePlanung des Projektes ein. Anforderungen, die aufwandsneutral und ohne eine Verschiebung der Ressourcensituation umgesetzt werden können, werden direkt in die Planung des laufenden Projektes einfließen. Anforderungen, bei denen dies nicht der Fall ist, die aber eine hohe Priorität haben, müssen hinsichtlich ihres Aufwands eingeschätzt werden. Dieser Aufwand umfasst nicht nur den reinen Implementierungsaufwand für die Umsetzung der Anforderungen, sondern bezieht auch den durch die Änderung des Projektplans resultierenden Aufwand mit ein. Sprengt der prognostizierte Aufwand den Zeit- und Kostenrahmen des Projektes, muss mit den Sponsoren des Projektes bzw. mit der anfordernden Fachabteilung ein entsprechendes Budget für Change Requests ausgehandelt werden. Ein konsequentes Change Management stellt einen planbaren Projektverlauf einerseits und eine hohe Benutzerakzeptanz anderer-

9 Projektorganisation

seits sicher. Change Management als wichtiges Instrument der Release-Planung muss sowohl während der Konzeptions- und Implementierungsphase als auch nach der Einführung des Portals konsequent durchgeführt werden.

9.2.3 Prototyping Durch die bereits vorgestellten besonderen Herausforderungen bei der Umsetzung eines Portalprojektes hat es sich in der Praxis bewährt, anhand von Prototypen die Machbarkeit der Konzeption nachzuweisen. Der größte Vorteil dieser Herangehensweise ist, dass der Prototyp ein Proof-of-Concept und somit die argumentative Grundlage für die vollständige Umsetzung ist. Mit dem Prototyp wird das konzipierte Portal außerdem zum ersten Mal sichtbar und benutzbar. Der Prototyp ist somit geeignet, um sich in einer frühen Phase der Implementierung anhand konkreter Portalfunktionen mit den Benutzern über die Struktur und Logik der Benutzungsschnittstellen abzustimmen. Dieser Vorteil einer frühen Verständnisüberprüfung der Anforderungen wiegt in den meisten Fällen den zusätzlichen Aufwand auf, der mit einem Prototyp verbunden ist. Durch die Erfahrungen, die in der Prototypphase gesammelt werden, kann ein reales System effizienter aufgesetzt und in Betrieb genommen werden – mit einer wesentlich verringerten Gefahr von unvorhergesehenen Risiken überrascht zu werden. Auch wenn es verlockend ist, alle Möglichkeiten einmal durchgespielt zu haben, sollte man nicht versuchen, alle Portalfunktionalitäten in einem Prototyp umzusetzen. Dies würde den Intentionen eines Prototyps nicht gerecht werden und den Aufwand für diesen in die Höhe treiben, ohne einen angemessenen Vorteil zu bringen. Es ist ratsamer, sich auf eine paar wenige ausgewählte Schlüsselfunktionen zu konzentrieren, die einfach abgeschätzt und bewertet werden können, und für die bereits eine hohe Einführungspriorität festgelegt wurde. Diese Schlüsselfunktionen sollten außerdem einen konkreten Mehrwert für die Benutzer darstellen. Auf diese Weise kann der Prototyp dem aktiven Marketing des Portals bereits in der Implementierungsphase dienen. Im Hinblick auf Produktivität, Effizienz und Planungssicherheit ist es wichtig, die Benutzer in alle Phasen des Portalprojektes einzubinden. Im Sinne des Rapid-Application-Development-Ansatzes geben die Benutzer direktes Feedback zu der Entwicklung des Prototyps. Dieses Vorgehen verkürzt den Abstimmungsaufwand im Entwicklungsprozess und stellt die Qualität der Ergebnisse sicher.

9.2 Die Schritte des Projektmanagement-Prozesses

Ausgewählte Funktionen

Einbindung der Benutzer

■ ■ ■

271

Da der Erfolg direkt von der Benutzerakzeptanz des Portals abhängt, sollten Usability-Tests ein fester Bestandteil der Projektplanung sein. Anhand ausgewählter repräsentativer Funktionen wird die Benutzerfreundlichkeit des Systems getestet. Die Ergebnisse des Usability-Tests können dann wieder direkt in die Umsetzung einfließen. Der Prototyp hilft dadurch, die Benutzerschnittstelle optimal zu gestalten und den Einarbeitungsaufwand zu minimieren. Im Sinne eines Step-by-Step-Vorgehens kann der Prototyp mehr als ein reiner Proof-of-Concept sein. Oft stellt er bereits den Grundstein für die weitere Portalentwicklung dar. In einem iterativen Vorgehen wird der Prototyp dann sukzessive um einzelne Portalfunktionen erweitert, die den Benutzern direkt zur Verfügung gestellt werden. Das Portal wird so in enger Abstimmung mit den Benutzern entwickelt. In späteren Iterationen profitiert das Entwicklungsteam so nicht nur von den beim Rollout des Portals frühzeitig gewonnenen Erfahrungen, sondern auch von den direkten Benutzerreaktionen, die in die Planung einfließen. Beim Einsatz von Prototypen entsteht häufig ein typisches Missverständnis. Der Prototyp vermittelt den Eindruck, dass das zu implementierende Portalsystem bereits fertig ist. Dabei ist in der Regel nur die Benutzungsoberfläche in weiten Teilen vollständig implementiert. Die komplexe Integrationslogik und andere ähnlich technisch anspruchsvolle Portalfunktionen fehlen noch oder sind nur rudimentär entwickelt. Diese Tatsache muss durch das Projektmanagement kommuniziert werden, um spätere Rechtfertigungen für die benötigte Projektlaufzeit zu vermeiden. Performanz

272

■ ■ ■

Ein einfach zu bedienendes Portal mit großem Funktionsumfang stellt für den Benutzer erst dann ein hilfreiches Werkzeug dar, wenn die Antwortzeiten des Portals bei der Informationsverarbeitung und Informationsrecherche akzeptabel sind. Neben einem intuitiven Design der Benutzungsoberfläche ist folglich die Performanz eines der ausschlaggebenden Kriterien für die Benutzerakzeptanz eines Portalsystems. Mit Hilfe von Testwerkzeugen, wie sie auch für andere E-Business-Lösungen eingesetzt werden, kann das Verhalten des Portals unter hoher Last simuliert werden. Eine derartige Teststrategie sollte Teil des Prozesses zum Ausbau des Prototyps in das produktive Portal sein. Ebenfalls durch den Einsatz der entsprechenden Werkzeuge kann durch Regressionstests das korrekte Systemverhalten kontinuierlich geprüft werden.

9 Projektorganisation

Fertiges Portalsystem

Umsetzung des Portals

Abb. 9.5 Prototyping

Beginn der Entwicklung

Anforderungsanalyse

Überarbeitung Prototyp

Konzeption und Entwurf

Benutzertest Prototyp

Entwicklung Prototyp

Abbildung 9.5 stellt den Prozess der Entwicklung eines Portals mittels Prototypen dar. Dabei wird der Prototyp so lange überarbeitet, bis man sich mit den Benutzern über die Umsetzung der Anforderungen geeinigt hat und die erforderliche Benutzerakzeptanz erreicht ist. Danach beginnt der Aufbau des produktiven Portals. Versuchen Sie, in allen Bereichen und Disziplinen des Projektes stets auf Einfachheit, Einheitlichkeit und eine angemessene Informationsversorgung aller Beteiligten zu achten. Die Erfahrung hat gezeigt, dass einige Prototypentwicklungen länger dauerten als geplant, und dass es erhebliche Hürden auf dem Weg vom Prototyp zum produktiven Portal gibt. Die häufigsten Gründe für diese Verzögerungen sind Probleme mit der Skalierbarkeit, gefolgt von Problemen bei der Implementierung. Ein Fallstrick bei der Herangehensweise mittels Prototypen ist beispielsweise, dass zwar Erfahrungen mit dem Portalprodukt gesammelt werden, aber die Anforderungen an eine voll ausgebaute Lösung nicht ausreichend evaluiert wurden. Aus diesem Grund ist es wichtig, dass der initiale Projektplan und auch die Prototypphase selbst einer durchdachten und definierten

9.2 Die Schritte des Projektmanagement-Prozesses

■ ■ ■

273

Vorgehensweise für die Realisierung des voll ausgebauten Portals folgen.

9.2.4 Implementierung Eine Besonderheit von Portalprojekten ist die Vielfältigkeit der technischen Kompetenzen, die beim Aufbau eines Portals notwendig ist. Neben Know-how für das Portalsystem und PortletTechnologien bedarf es Spezialisten für Geschäftsprozessmodellierung, Integration sowie weiterer technischer wie fachlicher Teildisziplinen entsprechend des Anwendungszweckes des Portals. Der Systementwurf für ein Unternehmensportal muss neben Performanzund Verfügbarkeitsaspekten auch die an das Portal gestellten Sicherheitsanforderungen frühzeitig berücksichtigen. Die Architektur des Portals muss einen stufenweisen evolutionären Entwicklungsprozess unterstützen. Ein sauberer und durchdachter Systementwurf ist somit die Voraussetzung für eine erfolgreiche Einführung und Weiterentwicklung des Portals. Die Implementierung des Unternehmensportals stellt hohe Anforderungen an das technische Verständnis des Projektmanagements. Das Projektmanagement muss die Erstellung des Systementwurfs koordinieren, das Ergebnis schließlich abnehmen und in die Projektplanung einfließen lassen. Außerdem muss der Projektplan entsprechend den technischen Anforderungen einzelner Arbeitspakete erstellt werden. Dazu muss das Projektmanagement die technische Komplexität einzelner Arbeitsschritte und ihrer Abhängigkeiten beurteilen können. Im Hinblick auf die vielfältigen technischen Aspekte eines Unternehmensportals ist dies keine einfache Aufgabe. Die Phasen des Entwicklungsprozesses eines Unternehmensportals unterscheiden sich aber prinzipiell nicht stark von denen klassischer IT-Projekte. Abbildung 9.6 stellt einen Ausschnitt unseres Vorgehensmodells für Portalprojekte dar. Abhängig von der für das Portal gewählten Einführungsstrategie werden die einzelnen Phasen des Projektes einmal oder im Sinne des Step-by-Step-Ansatzes für einzelne Portalfunktionen iterativ durchlaufen.

274

■ ■ ■

9 Projektorganisation

Abb. 9.6 Implementierungsphase eines Portalprojektes

Portalkonzeption - Grobkonzeption - Sicherheits- / Berechtigungskonzept - Technologie- und Produktauswahl - Feinkonzeption - Wirtschaftlichkeitsbetrachtung

Portalkonzept Implementierung - Umsetzung - Qualitätssicherung - Einführungskonzeption - Schulungskonzeption

Test

Einführung - Schulungen - Deployment - Wirtschaftlichkeitsanalyse

9.2.5 Projektcontrolling Das Projektcontrolling unterstützt mit systematisch erhobenen und ausgewerteten Informationen zum Projektverlauf die Projektsteuerung und -überwachung. Hauptaufgabe des Projektcontrollings ist es, den Projektplan (Soll) mit dem tatsächlichen Projektverlauf (Ist) zu vergleichen. Portalprojekte haben typischerweise eine Vielzahl einzelner Arbeitsschritte, die durch zahlreiche Teammitarbeiter konzipiert und durchgeführt werden. Deshalb hat es sich bewährt, ein Teammitglied allein für das Thema Controlling abzustellen. Dieser Projektcontroller ist dafür verantwortlich, kontinuierlich Ist- und Soll-Zustände des Projektes abzugleichen, um Abweichungen frühzeitig zu entdecken und deren Ursachen zu erforschen. Gegebenenfalls kann das Projektmanagement dann entsprechende Korrekturmaßnahmen einleiten. Das Projektcontrolling lässt sich in drei Arten unterteilen: ■

Termin- und Ablaufcontrolling,

■

Kostencontrolling,

■

Ergebniscontrolling (Qualitätssicherung).

9.2 Die Schritte des Projektmanagement-Prozesses

Arten des Projektcontrollings

■ ■ ■

275

Termin- und Ablaufcontrolling

Kostencontrolling

Ergebniscontrolling

276

■ ■ ■

Das Termin- und Ablaufcontrolling prüft über die gesamte Projektlaufzeit hinweg die Einhaltung des Projektplans. Analysiert werden vor allem Arbeitspakete und Meilensteine hinsichtlich der Übereinstimmung mit geplanten Vorgaben. Hierbei werden insbesondere die Einhaltung von Terminen überprüft und die Folgen von zeitlichen Verschiebungen in einzelnen Arbeitspaketen untersucht. Sind die Ursachen für eine Terminverschiebung ermittelt, müssen diese dem Projektmanagement mitgeteilt werden, sodass neue Erkenntnisse oder veränderte Rahmenbedingungen in die Projektplanung und gegebenenfalls den Annahmenkatalog des Projektes einfließen können. Ein kontinuierliches Controlling des Projektablaufs ist wichtig, um Fehlentwicklungen sofort zu erkennen und frühzeitig gegensteuern zu können. Außerdem wird dadurch von Anfang des Projektes an bei den Projektmitarbeitern ein Bewusstsein für die Zeitplanung des Projektes, die Zieltermine und ihre daraus resultierenden Verantwortlichkeiten geschaffen. Im Kostencontrolling wird die tatsächliche Kostensituation des Projektes den geplanten Kosten gegenübergestellt. Grundlage der Bemessung sind hier die Kosten pro Arbeitspaket, die im Kostenplan der Gesamtprojektplanung veranschlagt worden sind. Die Nichtbeachtung der Kostenseite eines Portalprojektes kann fatale Folgen haben. Wird zu spät erkannt, dass das Projekt den prognostizierten Kostenrahmen sprengt, so können kaum mehr Gegenmaßnahmen ergriffen werden. Findet sich kein Sponsor, der bereit ist, das entstandene Budgetloch zu stopfen, und reichen die für Änderungen veranschlagten finanziellen Mittel (Change-Request-Budget) nicht aus, um die Kostenerhöhung aufzufangen, dann kann dies das vorzeitige Ende des Portalprojektes bedeuten. Das Kostencontrolling endet nicht mit der Produktivsetzung des Portalsystems. Die Betriebs- und Wartungskosten sowie die Einführungskosten (z.B. Schulungsaufwände) für das Portal werden mit den für diese Punkte im Gesamtkostenplan veranschlagten Kosten verglichen. Diese Betrachtungen können Grundlage für ein verändertes Rollout-Konzept späterer Releases oder für alternative Betriebsszenarien sein. Die Einhaltung des geplanten Zeit- und Kostenaufwands alleine macht ein Portalprojekt nicht erfolgreich. Schließlich müssen auch die Ergebnisse, die in der geplanten Zeit mit den geplanten finanziellen Mitteln realisiert wurden, den Qualitätsanforderungen der Auftraggeber entsprechen. Das Ergebniscontrolling als ein Instrument der Qualitätssicherung untersucht die Vollständigkeit der Umsetzung der fachlichen und technischen Anforderungen. Die Definition von Abnahmekriterien, die sich aus den Anforderungen ableiten, er-

9 Projektorganisation

leichtert die zielgerichtete Analyse der Projektergebnisse. Neben den Ergebnissen der Implementierung betrachtet das Ergebniscontrolling auch die Resultate des Projektmanagementprozesses. So werden Lösungskonzepte, die verbindlich für die Realisierungsphase des Projektes sind, auf ihre Eindeutigkeit, Vollständigkeit und ihren Detaillierungsgrad untersucht. Auch die abschließende fachliche wie technische Dokumentation des Projektes wird vom Ergebniscontrolling hinsichtlich der erwarteten Qualität überprüft. Auch für das Ergebniscontrolling gilt: Je früher Qualitätsmängel bemerkt und Korrekturmaßnahmen eingeleitet werden, desto kostengünstiger fallen diese aus. Das Ergebniscontrolling muss daher wie die anderen Arten des Projektcontrollings eine projektbegleitende Maßnahme sein. Nach Birker (2003) lassen sich die in Tabelle 9.1 dargestellten typischen Ursachen für Fehlentwicklungen in Projekten feststellen. Diese Tabelle ist hilfreich, um den Sinn für potenzielle Stolperfallen eines Portalprojektes zu schärfen und das Projektcontrolling darauf auszurichten. Planungsfehler

Ausführungsfehler

Änderungen der Rahmenbedingungen

Bei Tätigkeiten vergessen, falsch eingeschätzt, Termine nicht überprüft, Risiken unberücksichtigt

Mitarbeiterführung falsche Auswahl, mangelnde Einweisung, mangelnde Aufsicht, mangelndes Verständnis für Teildisziplinen

Leistungsänderungen durch Auftraggeber, Behördenauflagen u.ä.

Kapazitätsplanung Überbelastung nicht beachtet, Verfügbarkeit nicht abgestimmt Bezogen auf den Mitarbeiter Know-how nicht beachtet, Keine Schulung bzw. Einarbeitung, Urlaub etc. nicht berücksichtigt

Lösungskonzeption nicht ausreichend detailliert, nicht flexibel genug

Kündigungen

Tabelle 9.1 Typische Ursachen für Fehlentwicklungen in Projekten (nach Birker 2003)

Krankheiten Veränderte Prioritäten des Auftraggebers Hard- oder Softwareausfälle Auswirkungen anderer Projekte

9.2 Die Schritte des Projektmanagement-Prozesses

■ ■ ■

277

9.2.6 Test

Integrationstest

Leistungstest

278

■ ■ ■

Die Durchführung von Tests ist eine unabdingbare Begleitaufgabe eines jeden Portalprojektes. Durch systematisches Testen der implementierten Portalfunktionen kann sichergestellt werden, dass alle fachlichen und technischen Anforderungen korrekt umgesetzt werden. Neben dem bereits vorgestellten Prototyping und den UseCase-Beschreibungen sind Testverfahren ein wichtiges Instrument der Qualitätssicherung im Projekt. Sie sind die Voraussetzung für die erfolgreiche Einführung und Abnahme des Projektes. In Abhängigkeit vom Anwendungszweck und den Rahmenbedingungen des Portalprojektes kommen bei der Überprüfung des implementierten Portals verschiedene Testverfahren zum Einsatz. Einige Testverfahren, wie beispielsweise Akzeptanztests mit Prototypen, haben wir bereits angesprochen. Im Folgenden sollen die wichtigsten technischen Testverfahren kurz vorgestellt werden. Beim Integrationstest werden zum einen das Zusammenspiel der einzelnen Portalkomponenten untereinander und zum anderen die Schnittstellen zu externen Anwendungen überprüft. Im Rahmen des Integrationstests wird insbesondere analysiert, ob alle Informationen aus den Backend-Systemen korrekt übertragen und miteinander verwoben wurden. Durch die zentrale Bedeutung des Themas Integration in Unternehmensportalen kommt diesem Test eine besondere Wichtigkeit zu. Voraussetzung für einen aussagekräftigen Integrationstest ist ein Testaufbau, der dem späteren Produktivsystem entspricht. Alle Systembestandteile und alle anzubindenden BackendSysteme werden in den Test einbezogen. Beim Leistungstest wird das Portalsystem gegen die nichtfunktionalen Anforderungen wie z.B. Last, Datenmenge oder Zeitverhalten geprüft. Der Leistungstest stellt fest, ob die geforderten Antwortzeiten für einen Datenabruf eingehalten werden können und wie sich das Portalsystem unter extremen Bedingungen verhält. Dabei ist auch mit Werten zu testen, die deutlich höher sind als die im Pflichtenheft definierten Lastgrenzen, da dies auch im späteren produktiven Betrieb geschehen kann. Wichtig dabei ist, dass das System stets einen definierten Zustand behält. Auch wenn das System unter extremen Bedingungen nicht mehr seine normale Funktionalität liefert, so muss es jedoch den Benutzer angemessen informieren und die Datenintegrität wahren. Auch extreme Bedingungen dürfen nicht zu einer fehlerhaften Datenverarbeitung führen.

9 Projektorganisation

Mit Sicherheitstests wird überprüft, ob ein unbefugter Zugriff auf das Portal möglich ist. Bei Sicherheitstests (Penetrationstests) wird beispielsweise versucht, sich unbefugt am Portal anzumelden oder Sicherheitslecks in der Datenübertragung zu finden. Das Portal muss unter Beweis stellen, dass kein unberechtigter System- und Datenzugriff möglich ist und von außen keine Daten unbefugt manipuliert, gelesen oder gelöscht werden können. Mit Ein-/Ausgabetests wird die korrekte Datenverarbeitung des Portals überprüft. Dabei wird nicht nur mit allen zulässigen Eingabedaten getestet, sondern es werden auch bewusst falsche Eingaben gemacht. Das Portal muss fehlerhafte Eingaben zurückweisen und dem Benutzer eine entsprechende Meldung anzeigen. Durch fehlerhafte Eingaben dürfen sich keine instabilen Systemzustände ergeben. Browsertests spielen insbesondere bei Portalen mit einem Benutzerkreis, bei dem keine spezielle Clientsoftware (Browserversion und -typ) vorausgesetzt werden kann, eine große Rolle. Browsertests überprüfen die Korrektheit der Portaloberfläche mit verschiedenen Browsern in verschiedenen Versionen auf mehreren Betriebssystemen. Neben Layoutabweichungen können sich durch verschiedene Clientanwendungen auch Fehler in der Funktion der Portalapplikationen ergeben. Diese sollen durch Browsertests aufgespürt werden. Bei multimodalen Portalen müssen neben verschiedenen Webbrowsern auch die anderen Kommunikationskanäle des Portals getestet werden, z.B. Mobiltelefone oder PDAs. Mittlerweile gibt es eine Vielzahl von Softwareprodukten auf dem Markt, die bei der Durchführung der verschiedenen Testverfahren unterstützen. Insbesondere für Leistungstests gibt es spezialisierte Werkzeuge, mit denen sich Testfälle aufzeichnen und automatisiert ausführen lassen. Diese Werkzeuge zeichnen die Ergebnisse ihrer Tests auf und werten diese aus. Vor der Einführung eines Portals werden im Regelfall Abnahmetests durchgeführt. Diese Abnahmetests leiten sich aus dem Anforderungskatalog des Portalprojektes ab (vgl. Abschnitt 8.2.5) und dienen dazu, die Erfüllung aller Anforderungen nachzuweisen. Abnahmetests werden in der Regel von Repräsentanten der Fachabteilungen durchgeführt. Um zu aussagekräftigen Ergebnissen zu kommen, müssen Abnahmetests systematisch vorbereitet werden. Es müssen repräsentative Testfälle entwickelt werden, mit denen die Funktionsfähigkeit des Portals verifiziert werden kann. Diese Testfälle müssen beliebig wiederholbar sein, so dass sich Fehler später nachvollziehen lassen. Außerdem müssen Messkriterien definiert werden, die festlegen, welches Testergebnis (z.B. Fehleranzahl) Voraussetzung für die Erteilung der Abnahme des Portals ist.

9.2 Die Schritte des Projektmanagement-Prozesses

Sicherheitstest

Ein-/Ausgabetest

Browsertests

Automatisiertes Testen

Abnahmetest

■ ■ ■

279

9.2.7 Rollout

Voraussetzungen schaffen

Checklisten zum System-Rollout

280

■ ■ ■

Dem Rollout eines Unternehmensportals sollte eine intensive Testphase vorangegangen sein, in der das Portal bewiesen hat, dass es sowohl den technischen als auch den fachlichen Anforderungen genügt. Ist von autorisierter Stelle eine offizielle Freigabe für den produktiven Betrieb des Portals erfolgt, dann kann mit der Einführung des Portals begonnen werden. Einem organisierten Einführungsprozess sollten dabei ein organisatorisches und technisches Einführungskonzept zugrunde liegen. Bevor das Portal flächendeckend seinen produktiven Betrieb aufnehmen kann, muss sichergestellt werden, dass alle Adressaten über die notwendigen Voraussetzungen zur Nutzung des Portals verfügen. Dies können in technischer Hinsicht beispielsweise entsprechend leistungsfähige Computerhardware oder spezielle Browserversionen sein. Im organisatorischen Sinne müssen die Anwender des Portalsystems durch Schulungen auf den Umgang mit dem Portal vorbereitet werden. Nur wenn die Anwender in der Lage sind, mit dem Portal effizient umzugehen, wird das Portal für sie seinen vollen Nutzen entfalten können. Neben Schulungen haben sich Guided Tours, die den Benutzer durch das Portal führen und dessen Anwendung verdeutlichen, in vielen Fällen als hilfreiche Unterstützung bei der erfolgreichen Einführung eines Portalsystems erwiesen. Die Einrichtung eines User Helpdesks hilft außerdem, die organisatorischen Probleme bei der Einführung eines Portals schnell in den Griff zu bekommen. Die Komplexität des Rollout-Prozesses steigt mit der Anzahl der an das Portal angeschlossenen Standorte und Abteilungen. Checklisten, die bereits in einer frühen Projektphase angelegt und über den Verlauf des Projektes weiterentwickelt werden, helfen bei einem reibungslosen System-Rollout. Anhand der Checklisten kann sichergestellt werden, dass alle relevanten technischen und organisatorischen Bedingungen berücksichtigt werden und somit die Basis für die Portaleinführung geschaffen ist. Auch die Einführungskonzeption profitiert von einem Prototyping. Bereits beim Rollout des Prototyps kann die bestehende Einführungskonzeption verifiziert und wichtige Erkenntnisse für den produktiven Betrieb des Systems gewonnen werden. Diese Erkenntnisse fließen in die Checklisten für die Einführung des Portals ein und sichern so die Qualität und Effizienz des Einführungsprozesses.

9 Projektorganisation

9.3 Iteratives Vorgehen Insgesamt hat sich bei der Einführung eines Unternehmensportals eine Politik der kleinen Schritte bewährt. Nach dem Motto „Think big – start small“ ist es in der Regel zielführender, die Vision eines voll ausgebauten Portals in kleinen iterativen Etappen umzusetzen, als direkt mit einem 100-prozentigen Vollständigkeitsanspruch in ein Portalprojekt zu starten. Sonst riskiert man, in der Vielzahl umzusetzender Funktionen den Überblick über das Gesamtprojekt und seine Rahmenbedingungen zu verlieren. Plant man dagegen von vornherein ein iteratives Vorgehen in einzelnen abgeschlossenen Projektschritten, so verringert man die Komplexität des Gesamtprojektes und kann deshalb die Qualität der Ergebnisse im Projektmanagementprozess besser überwachen und sicherstellen. Diese Vorgehensweise verringert außerdem die Projektlaufzeit bis zu einer ersten produktiven Einführung des Unternehmensportals. Fokussiert man in den ersten Ausbaustufen des Portals auf jene Funktionen, die den größten Mehrwert für die Anwender darstellen, dann kann die Motivation der Anwender für die Benutzung des Portals und folglich auch deren Interesse für die weitere Entwicklung des Portals sichergestellt werden. Da die meisten Unternehmen mit dem Aufbau eines Unternehmensportals sowohl fachlich als auch technisch Neuland betreten, führt der Anspruch, das Unternehmensportal in seiner vollen Ausbaustufe in einem einzigen Projekt umzusetzen, nur selten zu zufrieden stellenden Ergebnissen. Oftmals werden Rahmenbedingungen und Aufwände falsch eingeschätzt, unbekannte technische Hürden sind zu nehmen, und bislang unberücksichtigte fachliche Aspekte werden erst während der Projektlaufzeit sichtbar. Wie Abbildung 9.3 des Projektmanagement-Prozesses zeigt, fließen die Erfahrungen und das während der Durchführung eines Projektes gewonnene Wissen in die Planung späterer Projekte ein. Diesen Lernprozess kann ein Unternehmen bei einem stufenweisen Aufbau eines Portals für sich nutzen. Erkenntnisse über den Umgang der Anwender mit dem Portal, technisches Know-how bei der Entwicklung der Portalinfrastruktur und das Wissen um die kritischen Rahmenbedingungen des Projektes helfen, das Portal konsequent an den Anforderungen der Anwender auszurichten und die Umsetzung effektiv und weitestgehend sicher zu planen. Nicht selten verschieben sich bei der tatsächlichen Benutzung eines Portals die Prioritäten fachlicher Anforderungen. Bei einer iterativen Herangehensweise an ein Portalprojekt können diese Veränderungen weitestgehend flexibel berücksichtigt werden, ohne die Planung der aktuellen Projektiteration oder das

9.3 Iteratives Vorgehen

■ ■ ■

281

System selbst in Frage zu stellen. Deshalb ist es wichtig, den Anforderungskatalog über alle Stufen der Portalentwicklung hinweg weiterzuentwickeln und auch zukünftige Anforderungen zu antizipieren und in der Gesamtplanung zu berücksichtigen.

9.4 Inhalte vor- und aufbereiten Inhalt ist alles – ohne Inhalte ist ein Portal wertlos. Ein Portal soll schließlich in erster Linie die Informationsversorgung im Unternehmen verbessern und die Qualität der verfügbaren Informationen steigern. Dies geschieht zum einen durch die Integration vorhandener Datenquellen und das Verweben der dort abgelegten Informationen. Zum anderen soll ein Portal aber auch dezentrale Informationen, die nur in bestimmten Abteilungen oder gar ausschließlich in den Köpfen einzelner Mitarbeiter existieren, dem ganzen Unternehmen zur Verfügung stellen. Aus diesem Grund kommt der Inhaltspflege in einem Portalprojekt ein besonderer Stellenwert zu. Die Vorbereitung und Überarbeitung der bestehenden Informationen ist eine der wesentlichen Aufgaben, bevor das Portal aufgesetzt und betrieben werden kann. Diese Aufgabe ist nicht zwangsläufig ein Vorreiter des eigentlichen Projektes, sondern kann parallel zu den Entwicklungs- und Testaktivitäten stattfinden. Allerdings müssen hierbei bereits Abhängigkeiten zu den Redaktionswerkzeugen des Portals berücksichtigt werden. Die Aufbereitung der Inhalte ist eine Aufgabe, die auf dem Weg zu einem produktiven Portal bewältigt und vom Projektmanagement entsprechend berücksichtigt werden muss. Bestehende Dokumente müssen überarbeitet, formatiert und kategorisiert werden. Wissen, das bislang noch nicht in elektronischer Form vorliegt, muss über die Redaktionsmasken des Portals erfasst werden und so in den zentralen Wissensspeicher des Unternehmens einfließen. Doch auch nach der Einführung des Portals müssen die im Portal verwalteten Inhalte gepflegt, aktualisiert und ergänzt werden. Ein häufiger Stolperstein in Portalprojekten ist, dass – nach einer anfänglichen Euphorie für das Projekt – die Inhalte später nicht mehr aktualisiert und erweitert werden und Benutzer folglich weniger Anreize haben, um das Portal zu nutzen. Management der Portalinformationen

282

■ ■ ■

Das Management eines Portalprojektes hat dafür Sorge zu tragen, dass das Portal zum Einführungszeitpunkt ein dem Anwendungszweck entsprechendes, in sich konsistentes Informationsangebot be-

9 Projektorganisation

reithält. Außerdem müssen frühzeitig Verantwortlichkeiten zugeordnet und Prozesse etabliert werden, um sicherzustellen, dass die Portalinformationen langfristig weiterentwickelt und auf einem aktuellen Stand gehalten werden. Diese Prozesse steuern, dass neue Informationen auf die Einhaltung von Qualitätsrichtlinien überprüft und kategorisiert werden und alte Informationen am Ende ihrer Laufzeit archiviert werden. Dazu müssen Richtlinien zur Informationsqualität des Portals im Unternehmen etabliert werden. Diese geben Anweisungen für die Erstellung von Informationsobjekten und schreiben Metadaten vor, die der Autor den Informationsobjekten beizufügen hat. Über die Redaktionskomponenten der meisten Portalsysteme lassen sich diese Prozesse weitestgehend technisch unterstützen und automatisieren. Entscheidend ist, dass bei der Modellierung des Redaktionsworkflows die Kultur und die Gegebenheiten des Unternehmens berücksichtigt werden. Ist der Aufbauorganisation des Unternehmens ein starkes Verantwortungs- und Informationsgefälle zueigen, wird sich dieses beispielsweise in strikten Freigabemechanismen ausdrücken. Auch werden bestehende Datenhoheiten einzelner Personen oder Abteilungen oft nur sehr ungern aufgegeben. Diese informationspolitischen Aspekte müssen in die Gestaltung der Redaktionsprozesse einfließen. Datenhoheiten, die der Zielsetzung des Portals zuwider laufen, müssen durch das Projektmanagement im Rahmen des Projektes weitestgehend aufgehoben werden. Wo dies nicht möglich ist, müssen Konzepte für eine sinnvolle Reglementierung des Informationszugriffs entwickelt werden. Neben diesen politischen Überlegungen muss auch die tatsächliche Durchführbarkeit des geplanten Redaktionsprozesses betrachtet werden. Die meisten Autoren sind Mitarbeiter der Fachabteilungen, die sich neben ihren eigentlichen Aufgaben nun auch um die Informationspflege des Portals kümmern sollen. Für diese Mitarbeiter stellt das Portal erst einmal eine Mehrbelastung dar. Um dauerhaft eine Weiterentwicklung der Portalinformationen sicherzustellen, müssen den Mitarbeitern für ihre Autorentätigkeit Freiräume in ihrer täglichen Arbeit geschaffen werden. Die Vorgesetzten müssen durch das Projektmanagement angehalten werden, Möglichkeiten für die zusätzlichen Autorentätigkeiten der Mitarbeiter zu schaffen und auf ihre Umsetzung zu achten. Neben der Vermeidung einer Überbelastung des Mitarbeiters sind diese Freiräume wichtig, um dem Mitarbeiter die Wertschätzung seiner Autorentätigkeit zum Ausdruck zu bringen und ihn so zu motivieren. Ein entsprechender Redaktionsprozess wird im Abschnitt 10.3 dargestellt.

9.4 Inhalte vor- und aufbereiten

Informationsqualität

■ ■ ■

283

Kategorisieren der Informationen

Oftmals ist es hilfreich, gemeinsame Taxonomien zu entwickeln, um die Fachlichkeit des Unternehmens in einer standardisierten Sprache beschreiben zu können. Anhand dieser Taxonomien können die Portalinformationen kategorisiert und für Suchanfragen indiziert werden. Taxonomien können folgendermaßen gebildet werden:

Wertschätzung von der Unternehmensspitze

284

■ ■ ■

■

Spezielle Softwarewerkzeuge können Datenpools durchsuchen und eine Liste von potenziellen Kategorien ableiten und entsprechend zuweisen.

■

Für einige vertikale Märkte bestehen bereits Taxonomien, die zum Teil auch frei erhältlich sind.

■

Indem man bestehende Dokumente durcharbeitet, kann eine Taxonomie manuell zusammengestellt werden.

Alle Inhalte eines Portals, ob strukturierte oder unstrukturierte Informationen, müssen gewissen Qualitätsstandards unterliegen. Die konkreten Qualitätsanforderungen hängen von der Art der Informationen ab. An betriebswirtschaftliche Kennzahlen werden beispielsweise andere qualitative Anforderungen gestellt als an den Kantinenplan oder einen Newsticker. Taxonomien helfen, Inhalte mit einer gemeinsamen Systematik zu kategorisieren und so für den Benutzer transparent im Portal zu verwalten. Mitarbeiter, die als Redakteure oder Autoren in den Redaktionsprozess eingebunden sind, müssen darauf geschult werden, diese Taxonomien zu verstehen und Inhalte richtig zu kategorisieren. Insbesondere in großen Organisationen wird eine einzige Taxonomie nicht ausreichend sein, um allen Portalbenutzern und Anwendungszwecken gerecht zu werden. Für verschiedene Fachlichkeiten müssen entsprechend unterschiedliche Kategorien definiert werden. Gerade im Zusammenhang mit der Inhaltspflege und -verwaltung eines Portals wird die Bedeutung der Unterstützung des Portalprojektes durch die Unternehmensführung besonders deutlich. Von Seiten des Managements muss Wert auf die Qualität der Portalinformationen gelegt werden. Zum einen muss die Unternehmensleitung die Mitarbeiter dazu auffordern, Inhalte zu erstellen. Zum anderen hat nur sie die Möglichkeit, die für zusätzliche redaktionelle Tätigkeiten notwendigen Freiräume zu schaffen. Die Bedeutung der redaktionellen Aufgaben, die die Mitarbeiter übernehmen, müssen sich entsprechend auch in der Leistungsbeurteilung der Mitarbeiter widerspiegeln.

9 Projektorganisation

Noch ein kleiner Tipp zum Thema Content Management: Kann zum Einführungszeitpunkt des Portals noch keine für die Benutzererwartungen ausreichend breite Informationsbasis sichergestellt werden, dann bietet es sich (je nach Anwendungszweck des Portals) an, anfänglich externe Inhalte zu kaufen.

9.5 Portalmarketing Gerade durch die kulturellen Veränderungen, die sich durch die Einführung eines Portals vollziehen bzw. dadurch notwendig werden, ist die erfolgreiche Einführung eines Portals eine organisatorische Herausforderung. Schlussendlich hängt der Erfolg eines Portals von dessen Nutzungsintensität und somit der Akzeptanz der Benutzer ab. Das Marketing des Portals gehört folglich zu einer der wichtigsten Aufgaben des Projektmanagements. Wie bereits dargelegt, stellt ein Portalprojekt erhebliche Ansprüche an die kommunikativen Fähigkeiten des Projektmanagements. Der Projektstatus muss transparent gemacht werden, alle Beteiligten auf die Ziele des Projektes eingeschworen und ein Gespür für die Ängste, Ideen und Wünsche des Projektteams entwickelt werden. Diese kommunikativen Fähigkeiten sind auch der Schlüssel, um den organisatorischen Herausforderungen einer Portaleinführung zu begegnen und die Portalbenutzer frühzeitig für die Arbeit mit dem Portal zu motivieren. Die Vorteile, die ein gut auf das Unternehmen zugeschnittenes Portal dem einzelnen Benutzer bietet, können dabei als Argumentations- und Werbehilfe während und auch bereits vor der Einführungsphase genutzt werden. In diesem Zusammenhang ist es wichtig, bereits in der ersten Iterationsstufe eines Portals den Anwendern Funktionen zur Verfügung zu stellen, die für sie einen klaren Mehrwert darstellen und sie zur täglichen Nutzung des Portals motivieren. Dies können beispielsweise eine Online-Gehalts- oder Spesenabrechnung, Mitarbeiterumfragen oder der Kantinenplan sein. Welche Funktionen sich in diesem Zusammenhang konkret eignen, hängt natürlich stark von der Zielsetzung des Portals und seiner Zielgruppe ab. Manche Organisationen vertreten die Ansicht, dass die Personalisierbarkeit der Benutzungsoberfläche in der ersten Stufe eines Portalprojektes noch nicht notwendig ist. Diese Einschätzung teilen wir nicht. Die Möglichkeit, die neue Arbeitsumgebung nach seinem persönlichen Geschmack und seiner individuellen Arbeitsweise einrichten zu können, gibt dem Benutzer das Gefühl persönlichen Eigen-

9.5 Portalmarketing

■ ■ ■

285

tums und ist eine wichtige Maßnahme, um Benutzer für die Arbeit mit dem Portal zu begeistern. Das rechtfertigt auch den Zusatzaufwand, der mit der Einführung der Personalisierung verbunden ist. Für ein erfolgreiches Portalmarketing haben sich beispielsweise folgende Maßnahmen vor und während der Einführungsphase eines Unternehmensportals bewährt: Marketingmaßnahmen

■

Einbeziehung der Anwender in die Anforderungsanalyse,

■

Projektberichte in der Mitarbeiterzeitung,

■

Schulungen, die den Nutzen des Portals erläutern und den Umgang mit der neuen Technik lehren,

■

eine Veranstaltung, die auf die Produktivsetzung des Portals aufmerksam macht. Hier sind der Kreativität des Einführungsteams keine Grenzen gesetzt – von einer Firmenfeier bis hin zu Give-aways, die an die Mitarbeiter verteilt werden, ist vieles möglich.

Anreize

Eine andere nützliche Taktik versucht, Anreize für die Benutzung des Portals zu schaffen. Dies kann z.B. eine Belohnung in Form von Give-aways für Benutzer sein, die sich erstmalig im Portal angemeldet haben. Auch der spielerische Umgang mit dem Unternehmensportal kann helfen, die Angst vor dieser technischen Neuerung zu überwinden. Hierzu kann z.B. ein Gewinnspiel dienen, bei dem Fragen über den Aufbau und die Struktur des Portals beantwortet werden müssen. Welche Maßnahmen das Projektmanagement auch wählt, auf jeden Fall gilt, dass man nie etwas versprechen sollte, was man am Ende nicht halten kann. Dies führt zu Frustrationen und bestätigt damit gegebenenfalls die negativen Vorurteile gegenüber dem Portal. Wichtig ist, dass in allen Hierarchiestufen des Unternehmens ein Bewusstsein für die Entwicklung des Unternehmensportals und der damit verfolgten Ziele geschaffen wird. Nur wenn das Warum des Portalprojektes klar ist, kann Vorurteilen sinnvoll begegnet werden und eine Zustimmung für das geplante Portal entstehen. Ein effektives Portalmarketing hält die Kommunikation zu den Anwendern des Portals und den Beteiligten des Projektes über die gesamte Laufzeit der Portalentwicklung und darüber hinaus aufrecht. Dabei adressiert es nicht nur die (zukünftigen) Anwender des Systems, sondern auch die Unternehmensführung, von deren Aufmerksamkeit und Unterstützung der Erfolg des Portalprojektes maßgeblich abhängt.

286

9 Projektorganisation

■ ■ ■

9.6 Den Projekterfolg messen – Nutzenbetrachtung Wir wollen an dieser Stelle dem Kapitel 11 nicht vorgreifen, sondern abschließend den Aspekt der Nutzenanalyse als einen wesentlichen Aufgabenbereich des Projektmanagements betrachten. Wie bereits dargestellt, beginnt die Nutzenbetrachtung für ein Portal schon in dessen Planungsphase. Das Projektmanagement ist aufgefordert, Business Cases zu entwickeln, die den Nutzen eines Portals verdeutlichen und konkret in Zahlen ausdrücken. Eine solche Nutzenbetrachtung muss die Investition in ein Portal untermauern oder kann diese gegebenenfalls auch verhindern – wenn nämlich die Gegenüberstellung von Nutzen und Kosten den erwarteten betriebswirtschaftlichen Zielen des Unternehmens nicht gerecht wird. Neben der anfänglichen Entscheidung für eine Portaleinführung und der weiteren Planung des Projektes dient die Nutzenbetrachtung auch dazu, das Portal kontinuierlich an seiner betriebswirtschaftlichen Zielsetzung auszurichten. Dazu müssen spezielle Kriterien erstellt werden, die relevant für das Portalprojekt sind, selbst wenn diese sich auf wenig greifbare Vorteile wie Produktivitäts- oder Effektivitätsverbesserungen beziehen. Diese Kriterien helfen, den Projektverlauf auf die initiale Projektzielsetzung zu beziehen, und können außerdem hilfreich sein, um organisatorische oder technische Fallstricke zu identifizieren, bevor diese zu ernsten Problemen werden. Bei der Nutzenanalyse können unterschiedliche betriebswirtschaftliche Methoden eingesetzt werden. Ein Beispiel ist die SWOTAnalyse.

Ausrichtung an den betriebswirtschaftlichen Zielen

SWOT-Analyse

Die SWOT-Analyse (Strength-Weakness-Opportunity-Threat) ist ein Instrument der strategischen Unternehmensplanung. In der SWOTAnalyse werden die internen Stärken und Schwächen des Unternehmens den Chancen und Risiken im Wettbewerb gegenübergestellt. Ziel ist es, aus dieser Analyse Parameter für die Strategieentwicklung des Unternehmens zu gewinnen. SWOT-Analysen können nicht nur sinnvoll für die unternehmerische Strategieentwicklung eingesetzt werden. In Portalprojekten können sie helfen, die Nutzenpotenziale einzelner Portalfunktionen zu analysieren. Dabei werden die aus den Anforderungen abgeleiteten potenziellen Portalfunktionen hinsichtlich ihres StärkenSchwächen- und Chancen-Risiken-Potenzials bewertet. Die Ergeb-

9.6 Den Projekterfolg messen – Nutzenbetrachtung

■ ■ ■

287

Balanced Scorecards

nisse der SWOT-Analyse fließen dann neben organisatorischen Aspekten in die Prioritätsbewertung und Release-Planung der geforderten Portalfunktionen ein. Balanced Scorecards erweisen sich in diesem Zusammenhang als hilfreiches betriebswirtschaftliches Verfahren. Ausgehend von allgemeinen strategischen Planungen eines Unternehmens finden die Balanced Scorecards ihre Anwendung auch bei der konkreten Planung und der Entwicklung von Konzepten und Maßnahmen für ein Portalprojekt. Die Balanced Scorecard ist ein Kennzahlensystem, das eine ganzheitliche und ausgeglichene Betrachtung eines Unternehmens oder eines Projektes aus verschiedenen Perspektiven erlaubt. Unter der Berücksichtigung interner wie externer Einflussfaktoren sowie der Stakeholder des Unternehmens bzw. Projektes werden kritische Erfolgsfaktoren bestimmt. Daraus wird ein Kennzahlensystem abgeleitet, das dann die Messgrößen für die Erreichung von strategischen Zielen repräsentiert. Dabei werden diese strategischen Ziele aus verschiedenen Sichtweisen betrachtet, für die jeweils Kennzahlen festgelegt werden. Die Herausforderung liegt hier in der Auswahl weniger, aber aussagekräftiger Kennzahlen, die als Messgrößen für die Zielerreichung geeignet sind. Die Balanced Scorecard kann das Projektmanagement in Portalprojekten dabei unterstützen, alle relevanten Aspekte des Projektes im Blick zu behalten und zu einem ausgewogenen („balanced“) Bild zusammen zu führen. Damit ermöglicht sie zum einen die Operationalisierung der Portalstrategie und zum anderen die Dokumentation und Präsentation des Projektstatus. Durch die Definition von Messkriterien wird die Gesamtaufgabe zerlegt und somit die Komplexität des Projektes reduziert. Diese Übersetzung der Strategie mittels Messgrößen in konkretes Handeln macht die Balanced Scorecard zu einem hilfreichen Indikator, mit dem Defizite und wichtige Aufgaben identifiziert werden können. Die Balanced Scorecard kann außerdem als Argumentationsgrundlage für Maßnahmen und Verantwortlichkeiten genutzt werden. Ein derartiges Kennzahlensystem stellt folglich ein effektives Projektmanagementwerkzeug dar, das hilft, die Projektprozesse im Hinblick auf die Zielerreichung richtig zu justieren. Dieses System kann auch über die Projektlaufzeit hinaus ein wichtiger Wegweiser für die Optimierung und Weiterentwicklung des Unternehmensportals sein.

288

■ ■ ■

9 Projektorganisation

10 Betrieb und Evolution

Mit dem Übergang in die Betriebsphase sieht sich das Portalteam veränderten und neuen Herausforderungen gegenüber. Das Erreichte muss angemessen präsentiert und bei den potenziellen Benutzern bekannt gemacht werden. Darüber hinaus müssen Maßnahmen zur Pflege und Weiterentwicklung der Inhalte eingeleitet werden. Diese Maßnahmen sind abhängig von der Art der Inhalte (vgl. Abb. 10.1). Bei unstrukturierten Informationen stehen „intelligente“ Suchmöglichkeiten im Vordergrund. Selbsterstellte Texte hingegen werden in einem Redaktionsprozess erstellt, kontrolliert und veröffentlicht. Zusätzliche strukturierte Informationen und die Systeme, die solche Informationen liefern, müssen sinnvoll in das Portal integriert werden. Schließlich soll das Portal auch in der Organisation expandieren, indem es die Bedürfnisse weiterer Abteilungen abdeckt. Soll die Miteinanderarbeit vom Unternehmensportal unterstützt werden, so können die Auswirkungen auf die gewohnten Arbeitsweisen revolutionär (im positiven Sinne) sein. Während des Portalbetriebs ist darauf zu achten, dass man die Ziele der Revolution nicht aus den Augen verliert. Der Begriff des „lernenden Unternehmens“ fokussiert hier auf den Betrieb des Unternehmensportals: Welche Erfahrungen sammeln Benutzer, aber auch Entwickler mit einem produktiven Portal? Wie können diese Erfahrungen die Weiterentwicklung des Portals positiv beeinflussen? Schließlich widmet sich dieses Kapitel noch einem technischen Thema: Dem Release Management eines Unternehmensportals. Wir gehen der Frage nach, wie eine reibungslose Weiterentwicklung des Portalsystems bei gleichzeitiger Bereitschaft zur schnellen Fehlerbeseitigung gewährleistet werden kann.

10.1 Portalmarketing

Kurz gefasst

■ ■ ■

289

R

Abb. 10.1 Maßnahmen zur Pflege und Weiterentwicklung der Inhalte

Strukturierte Daten

Unstrukturierte Daten

Portal

N O TI K E A H ED SUC

Originäre Daten

O TI

A

R G

TE IN N

Extrahierte und aufbereitete Daten

10.1 Portalmarketing Dieses Kapitel beginnt so, wie das vorige Kapitel endet: Mit dem Marketing des Unternehmensportals. Die Kommunikation über das Portal hört nicht etwa mit dessen Inbetriebnahme auf – sie verlagert allerdings ein wenig ihren Schwerpunkt. Während der Entwicklungsphase steht die Vermittlung des späteren Nutzens im Fokus des Portalmarketings. Man will das Interesse der späteren Benutzer wecken und gleichzeitig die Entscheider und Sponsoren über den plangemäßen Fortgang ihrer Investition informieren. Dabei hat man, abgesehen von einem eventuell entwickelten Prototypen, nichts wirklich Greifbares zur Hand. Die Kunst besteht in der erfolgreichen Vermittlung einer Idee. Diese Idee ist jetzt, in der Betriebsphase, Wirklichkeit. Das Portal ist – zumindest in einer ersten Ausbaustufe – implementiert, installiert und steht den Benutzern zur Verfügung. Sie können nun überprüfen, inwieweit die Vision des Unternehmensportals und die darauf aufbauenden persönlichen Erwartungen tatsächlich erfüllt werden. Je mehr sich die Funktionalität des Unternehmensportals mit

290

■ ■ ■

10 Betrieb und Evolution

den Erwartungen der Benutzer deckt, desto höher wird die Akzeptanz des Portals sein, was sich wiederum in einer intensiveren Nutzung niederschlägt. Je länger und häufiger sich die Benutzer mit dem Portal auseinandersetzen, desto besser sind sie in der Lage, ihre Anforderungen zu formulieren, die vom Portal derzeit nicht erfüllt werden. Dieser Anforderungskatalog bildet die Basis für die zielgerichtete Weiterentwicklung des Portals. Der ermittelte Nutzungsgrad wiederum dient den Sponsoren als Kennzahl für den Projekterfolg und kann entscheidend für die Bewilligung weiterer Budgets sein. Ein gezieltes Marketing kann diese positive Entwicklung unterstützen. So werden in der ersten Ausbaustufe eines Portals oft nur ausgewählte Anforderungen tatsächlich eine Umsetzung finden, während andere der ursprünglich aufgestellten Anforderungen für spätere Versionen des Unternehmensportals geplant sind. Diese Planung muss den Benutzern bekannt gemacht werden – sonst besteht die Gefahr, dass jede fehlende Funktionalität von den Benutzern als eklatanter Mangel betrachtet wird. Woher sollen sie wissen, dass die geforderte Funktion nicht vergessen, sondern nur verschoben wurde? Verfügen die Benutzer aber über dieses Wissen, so werden sie nicht vorrangig nach fehlenden Funktionen suchen. Stattdessen werden sie die bereits implementierten Funktionen bewerten, was für die Weiterentwicklung des Portals wesentlich wertvoller ist. Als Entwickler bzw. Betreiber eines Unternehmensportals darf man nicht davon ausgehen, dass die Bewertung der Benutzer automatisch in einer Rückmeldung resultiert. Viele Benutzer bilden sich ihre Meinung, teilen diese aber nicht mit. Deshalb müssen die Portalverantwortlichen die konstruktive Kritik aktiv von den Benutzern einfordern. Durch gezielte Maßnahmen wird ermittelt, wie die Benutzer die einzelnen Funktionen des Portals wahrnehmen, und was getan werden kann, um das Angebot an Dienstleistungen und Informationen zu verbessern. Tabelle 10.1 listet einige dieser Maßnahmen auf und bewertet deren Eignung, speziell für die Meinungsforschung eines Unternehmensportals. Maßnahme

Bewertung

Umfrage per E-Mail oder Formular im Portal

Ein geeignetes Mittel für die erste Rückmeldung der Benutzer nach einer ausreichenden Phase der Eingewöhnung. Im Gegensatz zur E-Mail erlauben Webformulare eine anonyme Form der Kritik. Die Herausforderung liegt in der Formulierung der Fragen und der späteren Auswertung. Je mehr Freiraum die Umfrage bietet (z.B. Freitextfelder), desto schwieriger ist eine formale (automatische) Auswertung.

10.1 Portalmarketing

Was ist? Was kommt?

Aufforderung zur konstruktiven Kritik

Tabelle 10.1 Maßnahmen zur Portalbewertung

■ ■ ■

291

Maßnahme

Bewertung

Persönliche Interviews Durch gezielte Auswahl der Benutzer kann die mit Benutzern Berücksichtigung aller Benutzerrollen des Portals gewährleistet werden. Die Art der Fragestellung, der Aufbau des Gesprächs und die Inhalte der Fragen können auf die Person abgestimmt werden. Das erschwert aber unter Umständen die Auswertung. Die Vorbereitung eines Interviews ist weniger aufwendig als die Ausarbeitung einer Umfrage. Deshalb können Interviews spontaner durchgeführt werden. Die Auswertung ist allerdings aufwendiger als z.B. bei einer OnlineUmfrage, wo die Ergebnisse auf Knopfdruck zur Verfügung stehen. Bewertungssystem für Benutzer können während der Nutzung einer Portalangebote Portalanwendung direkt eine Bewertung abgeben (z.B. Schulnotensystem). Diese Art der Rückmeldung ist sehr zielgerichtet. Andererseits ist die Nutzung optional. Es kann deshalb kein Rückschluss von der Anzahl der Rückmeldungen auf den Nutzungsgrad der Portalanwendung gezogen werden. Außerdem ist das Feedback oft spontan und unreflektiert – so kann z.B. ein Netzwerkproblem, das zu einem verzögerten Antwortverhalten des Portals führt, eine (ungerechtfertigte) negative Bewertung zur Folge haben. Softwareergonomische Diese Maßnahme ist sehr aufwendig und in der Regel nur dann tragbar, wenn die Bedienbarkeit Untersuchungen der einer Portalanwendung oder die Integration verBenutzbarkeit (Usability Lab) schiedener Anwendungen signifikant verbessert werden muss. Auch in solchen Fällen ist zunächst zu prüfen, ob nicht bereits weniger aufwendige Maßnahmen zum gewünschten Erfolg führen können. Gegenstand der Untersuchung

Protokolldateien liefern Nutzungsprofile

292

■ ■ ■

Bevor die in der Tabelle genannten Maßnahmen ergriffen werden, muss klar sein, welche Bereiche des Portals Gegenstand der Befragung sein sollen, und welche Aspekte der Benutzbarkeit zu analysieren sind. Hinweise zur Klärung dieser Fragen liefern die Protokolldateien des Portalsystems und des Webservers. Durch Auswertung der Protokolle kann der Nutzungsgrad einzelner Portalangebote ermittelt

10 Betrieb und Evolution

und mit dem Nutzungsgrad anderer Bereiche des Portals verglichen werden. Die Ergebnisse der Auswertung müssen jedoch differenziert betrachtet werden, um fundierte Aussagen über die Wichtigkeit einer Portalanwendung treffen zu können. So wird z.B. eine allgemeine Portalfunktion wie die Suche sehr häufig aufgerufen werden. Ein Report, der nur für den Monatsabschluss benötigt wird, hat eine weitaus geringere Nutzungsfrequenz, ist aber eventuell für den Monatsabschluss von hoher Bedeutung. In jedem Fall sind die Ergebnisse einer Protokollanalyse der Ausgangspunkt für weitere Untersuchungen. Die Anfragen von Benutzern an die für das Unternehmensportal zuständige Support-Abteilung können Aufschluss über die Stabilität und den Funktionsumfang des Portalsystems, aber auch über die Zufriedenheit seiner Benutzer geben. Ähnlich den in Tabelle 10.1 genannten Interviews kann ein Support-Mitarbeiter, ausgehend von einer konkreten Frage bzw. einem Problem, die Akzeptanz des Portals ergründen. Fragen zur Bedienung bestimmter Portalanwendungen weisen auf Defizite in der Gestaltung der Benutzungsoberfläche hin. Wird immer wieder eine bestimmte, noch nicht implementierte Funktionalität nachgefragt, so sollte deren Priorität bei der Planung der Folgeversionen des Portals entsprechend steigen. Berichten Benutzer immer wieder von demselben Problem, so muss dieses in der Fehlerbehebung bevorzugt behandelt werden. Sind Fehler behoben worden, neue Funktionen verfügbar oder allgemeingültige Lösungen für wiederkehrende Probleme entwickelt worden, so müssen diese kommuniziert werden. Eine Ankündigung der Verbesserungen bzw. der neuen Funktionen an prominenter Stelle im Portal steigert den Bekanntheitsgrad. Ein eigenständiger Support-Bereich innerhalb des Portals animiert zur Selbsthilfe und entlastet die Support-Abteilung, die sich auf die schwierigeren Fälle konzentrieren kann. Ein solcher Support-Bereich enthält unter anderem eine Liste häufig gestellter Fragen (engl. Frequently Asked Questions, FAQ) und eventuell ein Forum, in dem sich die Portalbenutzer gegenseitig helfen können. Solche Foren sollten moderiert sein. Idealerweise stammt der Moderator aus dem Portalteam. Er kann die diskutierten Themen aufgreifen und in den Verbesserungsund Weiterentwicklungsprozess einbringen. Außerdem haben unmoderierte Foren eine Tendenz zum „thematischen Wildwuchs“. Nicht selten arten die Beiträge sogar in Polemik und Provokation aus. Ein Moderator kann dieser Tendenz entgegenwirken. Insbesondere zu Beginn eines Unternehmensportals deckt dieses nur einen Teil der gewünschten Funktionen ab. Diese Funktionen stehen zudem nur ausgewählten Personen (bzw. Rollen) oder Abteilungen zur Verfügung. Ein erfolgreiches Portalmarketing spricht ei-

10.1 Portalmarketing

SupportAnfragen ergründen Problembereiche und Benutzerakzeptanz

Einladung zur Integration

■ ■ ■

293

ne Einladung an all jene Mitarbeiter des Unternehmens aus, die noch nicht in den Genuss des Unternehmensportals kommen. Sie sollen aufgefordert werden, sich Gedanken zu machen, wie ihre tägliche Arbeit durch die Portalunterstützung einfacher, effizienter und günstiger erledigt werden kann. Die wichtigste Unterstützung erfährt das Portalmarketing durch zufriedene Portalbenutzer. Sie können die interessierten Kollegen am besten von den Vorzügen des Unternehmensportals überzeugen, weil sie auf der anderen Seite auch dessen Schwächen offen kommunizieren werden. Einen überwiegend positiven Eindruck bei den Mitarbeitern vorausgesetzt, wird dem Portalteam die Integration weiterer Benutzergruppen und deren Anforderungen in das Portal deutlich leichter fallen.

10.2 Bereitstellung aktueller und relevanter Informationen

„Intelligente“ Suche

294

■ ■ ■

Ein erfolgreiches und akzeptiertes Unternehmensportal wird mit der Zeit den Großteil der im Unternehmen vorhandenen Informationen zentral verfügbar machen. Das allein genügt den Benutzern nicht – sie wollen aktuelle Informationen, die ihre konkrete Tätigkeit und Situation berücksichtigen. Die Herausforderung besteht also in der strukturierten, situationsabhängigen Präsentation relevanter Informationen. Um diese Herausforderung meistern zu können, müssen die Informationen entsprechend aufbereitet sein, z.B. durch die Annotation von Metadaten (vgl. Abschnitt 5.3). Der Forderung nach Aktualität der Informationen kommen die operativen Systeme implizit nach, da ihr Datenbestand im Rahmen der Geschäftsprozesse ständig aktualisiert wird. So lange ein Portal direkten Zugriff auf diese Systeme hat, kann es die aktuellen Informationen dieser Systeme direkt anbieten – im Gegensatz zu älteren Data Warehouses, die zu festgelegten Zeitpunkten mit operativen Daten befüllt werden und somit immer einen definierten historischen Zustand des Informationshaushalts repräsentieren. Wie im Abschnitt 6.2.5 beschrieben, bieten auch diese Systeme vielfach den direkten Zugriff auf die operativen Datenbestände (Online Analytical Processing, OLAP). Neben der Aufbereitung der Daten und deren direkter Verfügbarkeit sind die Recherchemöglichkeiten des Portalsystems ausschlaggebend für den Nutzen. Unterstützt die Suchmaschine eine situationsabhängige Relevanzbewertung als Sortier- und Filterkriterium für die Ergebnismenge, so werden dem Benutzer nur jene Ergebnisse präsentiert, die ihn in seiner derzeitigen Situation interessieren. Die kleinere Ergebnismenge ist besser und schneller zu verarbeiten.

10 Betrieb und Evolution

Dank der automatischen Selektion kann sich der Benutzer zudem besser auf seine Aufgabe konzentrieren, ohne von unpassenden Suchergebnissen abgelenkt zu werden. Da sich die Aufbau- und Ablauforganisation eines Unternehmens mit der Zeit ändert, müssen auch die Relevanzalgorithmen regelmäßig einer Prüfung unterzogen werden. Stimmen die ursprünglich aufgestellten Annahmen weiterhin? Fehlen Bewertungskriterien, weil z.B. neue Abteilungen oder Geschäftsprozesse hinzugekommen sind? Sind die bereits definierten Relevanzregeln zu streng oder zu locker definiert, d.h. ist die Ergebnismenge zu klein bzw. zu groß? In Anbetracht obiger Ausführungen ist es nicht verwunderlich, dass robuste, ausgereifte und „intelligente“ Suchmechanismen zu den häufigsten Forderungen von Portalbenutzern zählen. Die Portalsystemhersteller tragen diesem Umstand Rechnung, indem sie ihre Suchmaschinen erweitern und verbessern, so dass diese immer mehr Datenformate durchsuchen können, Metainformationen zu den Suchergebnissen speichern und sowohl automatische als auch benutzerdefinierte Filter anbieten.

Review der Relevanzkriterien

10.3 Die Redaktion eines Unternehmensportals Wie im vorigen Abschnitt beschrieben, können wir die Aktualität der über das Unternehmensportal verfügbaren operativen Daten als gegeben hinnehmen. Wie aber steht es um jene Informationen, die nicht das Ergebnis der Kernprozesse des Unternehmens sind? Die Rede ist von den informationellen Inhalten, wie sie z.B. in Mitarbeiterportalen anzutreffen sind. Dort stellen sich häufig die einzelnen Abteilungen eines Unternehmens kurz vor. Sie beschreiben den Inhalt ihrer Tätigkeit, führen Schnittstellen zu anderen Abteilungen an, benennen Ansprechpartner für bestimmte Themen und veröffentlichen aktuelle, die Abteilung betreffende Informationen. Ziel dieser Selbstdarstellung: Den Mitarbeitern soll der sprichwörtliche Blick über den Tellerrand der eigenen Abteilung ermöglicht werden. Die Kenntnis der Aufbauorganisation und der Zusammenhänge zwischen Abteilungen im Rahmen von Geschäftsprozessen ist eine Voraussetzung, um effizient zu arbeiten und Verbesserungspotenziale erkennen zu können. Zudem kann eine solche Darstellung die Identifikation mit der Abteilung und dem Unternehmen positiv beeinflussen. Angesichts des kontinuierlichen Wandels, der Unternehmen jeder Größenordnung ergreift, müssen diese Informationen regelmäßig gepflegt werden, um für die Kollegen von Nutzen zu sein. Das Interesse wird schlagartig sinken, wenn die in der Portalseite genannten

10.3 Die Redaktion eines Unternehmensportals

■ ■ ■

295

Schreiben für Nicht-Experten

Frische Ideen für frische Texte

296

■ ■ ■

Ansprechpartner nicht mehr für das Unternehmen arbeiten oder die im Bereich „Aktuell“ genannten Termine mehrere Monate zurückliegen. Jede Abteilung muss einem oder mehreren Mitarbeitern die Rolle des Redakteurs zuweisen. Nur große Unternehmen können es sich leisten, einen ausgebildeten Journalisten in Vollzeit mit der Pflege des (Mitarbeiter-)Portals zu beauftragen. In der Regel aber wird diese Aufgabe neben der eigentlichen Tätigkeit im Unternehmen ausgeübt. Der Inhaber der Rolle „Redakteur“ hat meistens keine Zeit, wenig Motivation und oft keinen journalistischen Hintergrund vorzuweisen. Damit die Abteilungsdarstellung und andere informationelle Inhalte trotzdem zufriedene Leser finden, gilt es, einige Regeln zu beachten. Inhalte eines Unternehmensportals werden von vielen verschiedenen Menschen gelesen. Deren Interessen, aber auch ihr Bildungsstand sind mitunter sehr verschieden. Dies gilt es zu berücksichtigen, wenn in der Planungsphase des Portalauftritts die Informationstiefe, die Sprache, der Umfang und das benötigte Vorwissen für die Texte festgelegt werden. Dabei darf der Aufwand, um schwierige Sachverhalte einfach und verständlich zu formulieren, nicht unterschätzt werden. So haben viele Journalisten Respekt vor den Redakteuren der Bild-Zeitung. Diesen gelingt täglich das Kunststück, jede noch so komplexe Nachricht derart auf wenige Sätze zu kondensieren, dass die wesentlichen Informationen trotzdem erhalten bleiben. Der Vergleich mit der Tageszeitung ist durchaus angebracht, denn auch in einem Unternehmensportal möchten sich die meisten Mitarbeiter möglichst schnell einen Überblick verschaffen. Weiterführende Texte, auf die von den kurzen Artikeln verwiesen wird, runden das Informationsangebot ab und geben ihm Tiefe. Das Schreiben lebendiger, interessanter und überzeugender Texte will gelernt sein. Die meisten der von Reins (2002) befragten Werbetexter sind der Auffassung, dass man Schreiben lernen kann – für sie ist es vor allem ein Handwerk, und weniger eine Kunst. Zum Einstieg in das Schreiben von Texten vermittelt Wensky (2003) die Grundlagen des Schreibens und gibt wertvolle Tipps für bessere Texte. Je länger ein Mitarbeiter in einer Abteilung arbeitet, desto schwerer wird es ihm fallen, die Aufgabenbereiche der Abteilung allgemein verständlich zu beschreiben. Das hat mehrere Gründe. Zum einen kennt er zu viele Details und innere Zusammenhänge, deren Beschreibung einen Außenstehenden überfordern – die er aber dennoch für wichtig hält. Eine erfolgreiche Außendarstellung beschränkt sich aber auf wenige wesentliche Merkmale. Zum anderen wird ein langjähriger Mitarbeiter viele Dinge für selbstverständlich halten und

10 Betrieb und Evolution

deshalb nicht beschreiben. Tatsächlich haben aber nur die Kollegen innerhalb der Abteilung das von ihm vorausgesetzte Wissen. Kollegen, die neu in der Abteilung sind, haben noch den nötigen Abstand, um die Abteilung allgemein verständlich darzustellen. Ihre eigene Einarbeitung in die neue Abteilung besteht im Wesentlichen darin, den Überblick über die Aufgaben, Prozesse und Außenbeziehungen der Abteilung zu gewinnen – also genau jene Informationen, die man in einem Mitarbeiterportal erwartet. Fehlendes Wissen lässt sich aus Interviews mit altgedienten Kollegen ergänzen. Diese sind auch geeignete Lektoren, da sie aufgrund ihres Abteilungswissens falsche Informationen und Zusammenhänge sofort entdecken werden. Nach dem abteilungsinternen Review sollten die Texte auch von abteilungsfremden Personen gegengelesen werden – der endgültige Eignungstest vor der Veröffentlichung im Portal. Ein Problem haben die Geschäftsprozessanalyse und die Recherche für eine Abteilungsdarstellung gemeinsam: Viele Mitarbeiter, auf ihre Tätigkeit angesprochen, werden zunächst die interessanten und außergewöhnlichen Aufgaben beschreiben. Der Normalfall wird – wenn überhaupt – nur am Rande erwähnt. Dabei soll vor allem das normale Leistungsspektrum der Abteilung im Portal präsentiert werden. Nur so können sich die Benutzer des Portals ein realistisches Bild von der Abteilung machen und einschätzen, welche Dienste sie in Anspruch nehmen können. Gerade Mitarbeiterportale leben von aktuellen Nachrichten. Damit sind nicht nur die von den Nachrichtenagenturen eingespielten Tickermeldungen gemeint, sondern auch die unternehmensinternen Bekanntmachungen und Termine. Diese haben häufig ein Verfallsdatum, bleiben aber nicht selten über diesen Zeitpunkt hinaus im Portal verfügbar. Das erweckt beim Benutzer den Eindruck einer schlecht gepflegten Informationsquelle. Um dem vorzubeugen, müssen aktuelle Bereiche häufig und regelmäßig gepflegt werden. Veraltete Einträge können (unter Umständen automatisch) in ein Archiv verschoben oder gelöscht werden. Das Archiv wiederum kann über das Portal zur Verfügung gestellt werden, denn es mag den Fall geben, dass ein Kollege an Details zu zurückliegenden Ereignissen interessiert ist. Ob der aktuelle Bereich auch zur Veröffentlichung abteilungsinterner Bekanntmachungen und Termine genutzt werden sollte, ist gut abzuwägen. Einerseits sind auch die Kollegen aus der Abteilung Nutzer des Portals. Andererseits widerspricht diese Idee dem allgemeinen Wunsch nach einer Eindämmung der Informationsflut. Eine allgemeingültige Regel gibt es jedoch nicht. Eine in der Praxis oft eingesetzte Lösung basiert auf der Kategorisierung der Nachrichten. Der Benutzer hat dann die Möglichkeit, einzelne Nachrichtenkategorien zu abonnieren. Einige Kategorien (z.B. alle Nach-

10.3 Die Redaktion eines Unternehmensportals

Der Normalfall ist interessant

Die Halbwertszeit des Aktuellen

■ ■ ■

297

Abb. 10.2 Schema des Freigabezyklus (nach Büchner et al. 2001)

Vorlage

Inhalte akzeptieren

Redaktion als Prozess

richten, die Abteilung und das Unternehmen betreffend) bekommt er automatisch geliefert. Eine Qualitätskontrolle der zur Veröffentlichung bestimmten Texte ist eine sinnvolle und oft anzutreffende Forderung. Im Rahmen interner und externer Reviews werden die Texte von Personen mit unterschiedlichem fachlichen Hintergrundwissen begutachtet. Die Entscheidung, ob ein Text veröffentlicht wird, liegt in der Regel bei einer bestimmten Person oder einem Gremium, genauer: Einer Rolle, die etwa als „leitender Redakteur“ bezeichnet wird. Es liegt deshalb nahe, den Prozess der Erstellung, Kontrolle und Freigabe eines Textes als eigenständigen Geschäftsprozess aufzufassen. In der Tat bieten viele Content-Management-Systeme entsprechende Funktionen. Bei Unternehmensportalen, in denen in größerem Umfang Inhalte manuell erstellt und eingepflegt werden, muss bei der Softwareauswahl darauf geachtet werden, dass das Portalsystem einen Redaktionsprozess unterstützt. Dieser sollte flexibel genug sein, um sich den Anforderungen des Unternehmens anzupassen. Nicht immer ist eine umfassende Workflowlösung gefragt – insbesondere dann nicht, wenn bereits eine teilautomatisierte Lösung existiert. Der Workflow soll die Redaktion der Portalinhalte vereinfachen, standardisieren und deren Qualität sichern. Dies wird nur gelingen, wenn die Handhabung einfach und sicher genug ist, um auch die „Gelegenheitsredakteure“ eines Unternehmensportals zufrieden zu stellen.

Neue Inhalte

Autor

Portal

Redakteure

Revision

Nachbearbeitung erforderlich

Die Modellierung der redaktionellen Abläufe sowie die Festlegung von Rollen und Qualitätssicherungsmechanismen ist ein Spagat zwischen der Verwaltbarkeit und Standardisierung des Redaktionsprozesses einerseits und einer möglichst großen kreativen Freiheit der Autoren andererseits. Mit einem verzahnten Redaktionsprozess, wie in Abbildung 10.2 dargestellt, kann am besten die Balance in diesem Spannungsfeld gehalten werden. In einem derart strukturierten Redaktionsprozess sind zahlreiche Mitarbeiter des Unternehmens aufgefordert, als Autoren Inhalte zu erstellen. In jedem Team oder jeder Abteilung wird ein Redakteur eingesetzt. An diesen

298

■ ■ ■

10 Betrieb und Evolution

werden die erstellten Inhalte zur Überarbeitung und Freigabe weitergeleitet. Neben den Experten einzelner Domänen werden auch Mitarbeiter, die für Unternehmenskommunikation oder Datenschutz zuständig sind, redaktionell in den Freigabeprozess eingebunden. Die entsprechend geschulten Redakteure stellen so sicher, dass die Unternehmensstandards zur Informationserstellung und Informationspräsentation eingehalten werden und so ein einheitliches Qualitätsniveau erreicht wird.

10.4 Erkennen von Integrationspotenzialen Die im Abschnitt 5.7 vorgestellte Strategie „Think Big – start small“ empfiehlt, ein Portal auf Wachstum auszulegen. Beginnend mit einigen Anwendungen und Geschäftsprozessen ausgewählter Abteilungen, werden mit der Zeit immer mehr technische Systeme, Prozesse und Abteilungen integriert. Dieses Wachstum muss kontrolliert und zielorientiert vonstatten gehen. Deshalb ist es wichtig, Integrationspotenziale frühzeitig zu erkennen und in die Zukunftsplanung des Unternehmensportals einfließen zu lassen. Dabei sind alle drei in Tabelle 10.2 genannten Sichten zu berücksichtigen. Sichtweise

Fokus

fachlich

Die Geschäfts- Ziel ist die durchgängige technische Unterprozesse des stützung aller geeigneten GeschäftsprozesUnternehmens se. Die Integration in das Portal bietet einen zentralen Zugang zu diesen Geschäftsprozessen und ermöglicht deren durchgängige Implementierung. Je mehr Abteilungen in das UnternehmensDie Aufbauportal eingebunden werden, desto wichtiger organisation wird dessen Rolle in der Informationspolitik des Unternehmens des Unternehmens. Es vereinfacht die zielgerichtete Informationsverteilung, bietet seinerseits abgeleitete Informationen, basierend auf aktuellen Daten (Kennzahlen) und schafft die für ein effizientes Arbeiten nötige Transparenz. Alle techniIntegration ist hauptsächlich bei den Anschen Systeme wendungssystemen sinnvoll. Aber auch die des UnterInfrastrukturdienste (Middleware, Websernehmens ver, etc.) sollten hinsichtlich einer Zentralisierung analysiert werden.

organisatorisch

technisch

Integrationspotenzial aus Sicht des Portals

10.4 Erkennen von Integrationspotenzialen

Tabelle 10.2 Die drei Sichten auf ein Unternehmen

■ ■ ■

299

Da die Integrationspotenziale auch einer Wirtschaftlichkeitsbetrachtung standhalten müssen, muss das Verhältnis von Aufwand und Nutzen eine wesentliche Rolle bei der Analyse spielen. Sun Microsystems (2004) hat bei der Entwicklung eines konzernweiten Unternehmensportals vier wesentliche nutzbringende Komponenten identifiziert: ■

Effizientere Abläufe: Webbasierte Unterstützung einiger Tätigkeiten, Unterstützung administrativer Prozesse (Employee SelfService) und die Durchgängigkeit von Geschäftsprozessen resultierten in signifikanten Kosteneinsparungen. Die Standardisierung von Abläufen beschleunigte zudem deren Ausführung.

■

Umsatzsteigerung: Dank des schnellen Zugriffs auf relevante Informationen über Kunden, Produkte und Mitbewerber kann schneller reagiert werden – sowohl bei der Anbahnung eines Geschäfts als auch bei der Lieferung der Produkte und Dienstleistungen.

■

Infrastrukturintegration: Die Eliminierung redundanter Infrastruktur (Softwareanwendungen und technische Systeme) reduzierte die Anschaffungs- und Wartungskosten.

■

Mitarbeiterproduktivität: Das Portal erleichtert den schnellen Zugang zu den richtigen Informationen. Damit verbessert sich die Effektivität jedes einzelnen Mitarbeiters und in Folge auch des gesamten Konzerns. Zudem kultiviert das Portal den Wissensaustausch und bildet die Basis für ein global verfügbares Unternehmenswissen.

Diese nutzenzentrierte Betrachtungsweise mag als Unterstützung bei der Wachstumsplanung für das eigene Unternehmensportal dienen. Sie erleichtert die Priorisierung der verschiedenen Integrationskandidaten und hilft bei der Rechtfertigung der zu tätigenden Investitionen, da den Investitionen immer auch Einsparungen gegenübergestellt werden.

10.5 Miteinanderarbeit in Portalen Portale für die Miteinanderarbeit (Collaborative Portals) erheben den Anspruch, einer Gruppe von Personen einen virtuellen Raum für die Miteinanderarbeit und die Organisation der im Rahmen dieser Miteinanderarbeit entstehenden Artefakte zu schaffen. Die beteiligten

300

■ ■ ■

10 Betrieb und Evolution

Personen arbeiten nicht zwangsläufig im selben Unternehmen und am selben Standort. Im Rahmen von Kooperationen oder Beziehungen zu Kunden bzw. Lieferanten oder bei standortübergreifenden Projekten können mehrere Unternehmen bzw. Niederlassungen auf einen solchen virtuellen Raum Zugriff haben. Der klassische Datenaustausch über Dateiserver ist für organisatorisch getrennte Projektmitglieder oft nicht gangbar, denn in der Regel ist der Zugriff auf die Dateiserver von außerhalb aus Sicherheitsgründen nicht erlaubt. Hier zeigen die Portale für Miteinanderarbeit ihre Stärke. Deren Sicherheitsmechanismen sind nämlich auf örtliche Unabhängigkeit beim Zugriff ausgelegt. Auch innerhalb eines Unternehmens kann ein Portal für Miteinanderarbeit die Prozesse von Arbeitsgruppen aller Art standardisieren und beschleunigen. Informationsaustausch, Terminkoordination und -verwaltung sowie die Dokumentenablage werden einheitlich geregelt. Das reduziert den Einarbeitungsaufwand und erlaubt die Übernahme von Daten zwischen verschiedenen Projekten. Damit eine Arbeitsgruppe diese Möglichkeiten auch tatsächlich nutzt, muss das Portalmarketing entsprechende Aufklärungsarbeit leisten und Unterstützung bieten. Doch gerade innerhalb des Unternehmens muss darauf geachtet werden, dass das Unternehmensportal nicht nur einen weiteren Baustein im bunten Mosaik der Bürokommunikations- und Organisationssysteme bildet und damit zur Zergliederung der Informationsquellen beiträgt. Wir haben in einem internationalen Projekt eines großen europäischen Konzerns eine ganze Reihe von Dokumentablagen vorgefunden. Jede nationale Organisation hatte ihren eigenen Dateiserver. Da ein Austausch von Dokumenten über diese getrennten Server nicht möglich war, behalf man sich mit dem Versand der Dokumente per E-Mail. Darüber hinaus gab es verschiedene Webserver, begonnen mit dem Webauftritt im Intranet des Konzerns über verschiedene Informationsserver für das Technikteam bis hin zu Informationsangeboten für die Benutzer, wie z.B. Online-Hilfen oder Release Notes. Hinzu kamen Spezialanwendungen, z.B. für die Verwaltung von Programmfehlern. Erst in einer späten Projektphase haben wir durch einen Zufall erfahren, dass es neben diesen Dokumentablagen auch eine Plattform für Miteinanderarbeit gab. Dort fanden wir neben vielen redundant zum Dateiserver abgelegten Dokumenten auch das eine oder andere Dokument, das an keinem anderen Ort zu finden war. Einige dieser neu entdeckten Dokumente hätten uns viel Arbeit ersparen können – hätten wir von ihrer Existenz früher erfahren. So haben die fehlende Konzentration auf ein Werkzeug für die Miteinanderarbeit und ungenügendes Marketing die Projektdauer negativ

10.5 Miteinanderarbeit in Portalen

■ ■ ■

301

beeinflusst. In diesem Projekt konnten wir zudem beobachten, wie wichtig zentral gepflegte Verteilerlisten sind. Da das Projekt intensive Beziehungen zu mehreren angrenzenden bzw. querschnittlichen Projekten pflegte, gab es verschiedene Statusmails, die bestimmte Rollen unseres Projekts betrafen. Leider wurden personelle Veränderung, diese Rollen betreffend, nicht immer kommuniziert. Die Folge: Die E-Mails landeten bei der falschen Person oder – im Falle externer Mitarbeiter, die das Projekt und das Unternehmen verlassen hatten – im Nichts. Mit viel Glück erreichten solche E-Mails über Umwege dann doch noch die richtige Person – nicht selten zu spät.

Sanfte Revolution

Wie können solche Kommunikationsprobleme verhindert werden? Das Beispiel deutet es bereits an: Wir plädieren für eine radikale Konzentration auf jeweils ein Medium für die Kommunikation, die Terminverwaltung und die Dokumentablage. Idealerweise sind alle drei Funktionen Bestandteil einer einzigen Kollaborationslösung. Diese wiederum sollte in das Unternehmensportal integriert sein, um dessen Sicherheitsmechanismen zu nutzen, wenn die Miteinanderarbeit auf Personen außerhalb des Unternehmens ausgedehnt werden muss. So einfach diese Forderung formuliert werden kann, so schwer ist sie in der Praxis umzusetzen. Die gängigen Kommunikations- und Organisationswerkzeuge sind zentraler Bestandteil heutiger PC-Arbeitsplätze. Eine Ablösung dieser etablierten Werkzeuge, deren Bedienung die Mitarbeiter beherrschen, käme einer Revolution gleich. Dass diese auch sanft vonstatten gehen kann, zeigen die Integrationsbestrebungen der Hersteller dieser Kommunikationsund Organisationswerkzeuge. Für viele der gängigen E-MailKlientensysteme (z.B. Lotus Notes) gibt es mittlerweile Pendants in Form von Portalanwendungen. Je mehr diese vom Aussehen und der Bedienung her dem „Original“ ähneln, desto eher werden die Benutzer den Übergang in die Portalwelt akzeptieren. Spätestens dann, wenn ihnen die Unterstützung der Miteinanderarbeit durch das Portal einen signifikanten Mehrwert bringt, werden sie nicht mehr auf der altbekannten Lösung beharren, sondern das Neue offen erkunden und sich dessen Möglichkeiten zunutze machen.

10.6 Das lernende Projekt Kaum ein Projekt, das nicht nach einem erreichten Meilenstein oder am Projektende die gemachten Erfahrungen aufarbeitet (Lessons Learned). Doch was geschieht anschließend mit diesen Erkenntnissen? Werden sie als Anlass zur Veränderung verstanden? Haben sie

302

■ ■ ■

10 Betrieb und Evolution

einen Einfluss auf den Prozess der Weiterentwicklung des Softwaresystems? Was so selbstverständlich erscheint, wird in der Praxis doch nur selten bewusst gelebt. Dabei bedarf es nur wenig, um aus dem Gelernten einen Nutzen für die Folgeversionen der Software zu ziehen. Die Tatsache, dass die Erkenntnisse aus dem Projekt heraus entstanden sind, zeigt, dass sie bereits in den Köpfen der Projektbeteiligten gespeichert sind – sie müssen lediglich aktiviert und verankert werden, um den gewünschten Verbesserungseffekt zu erzielen. Dieser Zyklus der kontinuierlichen Verbesserung durch derartige Reviews endet nicht mit dem Projektende. Er setzt sich in der Betriebsphase des Unternehmensportals fort, denn gerade diese Phase zeichnet sich durch ihren besonderen Erfahrungsreichtum aus. Aus Sicht der Entwickler muss sich das Portalsystem unter Bedingungen beweisen, die im Entwicklertest nur annähernd erreicht werden können. Erst jetzt zeigt sich, ob bestimmte Lastkonstellationen und die Verteilung von Systemressourcen zu Engpässen führen können, oder ob z.B. die Performanz unter bestimmten Bedingungen deutlich nachlässt. Die Analyse solcher Auffälligkeiten führt in der Regel zu robusteren Folgeversionen. Interessant ist für die Entwickler auch die Art und Weise, in der die Benutzer mit dem System umgehen. Es ist immer wieder erstaunlich, mit welch großer Kreativität die Benutzer zu Werke gehen. Sie entwickeln Umgangsformen und Kommandofolgen, die kein Testfall abdecken kann. Oft erkennen die Entwickler erst in der Betriebsphase, welche Möglichkeiten in der von ihnen entwickelten Software stecken. Das wiederum weckt deren Kreativität und schärft zugleich deren „fachlichen“ Blick. Sie lernen, das System mit den Augen der Benutzer zu sehen. Die Benutzer haben zu Beginn der Projektphase ihre Anforderungen an das Unternehmensportal formuliert. Eventuell haben sie im Laufe des Projekts Prototypen gesehen oder sogar in Tests bedienen können. Diese wiesen unter Umständen noch Fehler auf oder umfassten nur einen Teil des geplanten Funktionsumfangs. Performanzprobleme und Fehlverhalten werden bei einem Prototypen noch geduldet. Nun aber steht die produktive Version des Portals zur Verfügung, die ihre Funktionsfähigkeit in verschiedenen Tests unter Beweis stellen konnte (vgl. auch den folgenden Abschnitt über das Release Management). Die Erwartungshaltung der Benutzer ist entsprechend höher – und oft auch der Druck. Häufig sind die Termine für die Inbetriebnahme eines Portals auch Bestandteil der Planung von anderen (fachlichen) Projekten. So kann z.B. die Arbeit einiger Abteilungen von einem der vom Unternehmensportal unterstützten Geschäftsprozesse abhängig sein. Eventuell hängen die Terminzusa-

10.6 Das lernende Projekt

Entwicklersicht

Benutzersicht

■ ■ ■

303

gen für bestimmte Liefergegenstände dieser Abteilungen von der termingerechten Verfügbarkeit des Workflows ab. Doch auch ohne Termindruck werden die Portalbenutzer überprüfen, ob die Versprechungen des Portalmarketings von dem Unternehmensportal tatsächlich gehalten werden. Ein Portal kann aber nur so gut sein wie die Anforderungen, die seinen Funktionsumfang festlegen. Und so werden die Benutzer im Umgang mit dem Portal feststellen, dass Funktionen fehlen, weil sie nicht gefordert worden sind. Auf der anderen Seite wird es auch Funktionen geben, die überflüssig oder überspezifiziert sind. Sind diese an prominenter Stelle im Portal verankert, so können sie durchaus störend wirken. Oft genügt eine Vereinfachung solcher Funktionen, um die Bedienbarkeit des Portals zu verbessern. Schließlich gibt es noch jene Funktionen, die zwar spezifikationsgemäß implementiert worden sind, bei denen aber die Spezifikation unvollständig oder fehlerhaft ist. Es macht nun keinen Sinn, als Portalverantwortlicher auf der Erfüllung der Spezifikation zu beharren – die Folge sind unzufriedene Benutzer, die das Unternehmensportal ablehnen oder zumindest dessen Potenzial nicht voll ausschöpfen wollen. Stattdessen sollten auch diese Hinweise der Kategorie „Lessons Learned“ zugeordnet werden – solange der Kosten- und Zeitaufwand für die Behebung dieser Schwächen vertretbar ist. Auch zufriedene Benutzer des Unternehmensportals, die keine Fehler oder Lücken aufdecken, können die Weiterentwicklung des Portals wesentlich beeinflussen. Je mehr Erfahrungen sie im Umgang mit dem vom Portal angebotenen Umgangsformen sammeln, desto genauer werden sie neue Anforderungen an das Portal formulieren können. So wird vor allem die Inter-Portlet-Kommunikation die Benutzer dazu anregen, neue Szenarien zu definieren, bei denen Portalanwendungen neue Verbindungen eingehen und die Benutzungsqualität des Portals weiter erhöhen. Sicherlich gibt es auch den Typ von Benutzern, die ihr gesamtes kreatives Potenzial in den Entwurf phantasievoller Anwendungsfälle investieren. Auch bei diesen Personen gilt grundsätzlich der aus der Kriminalistik bekannte Leitspruch: Es lohnt sich, zunächst jedem Hinweis nachzugehen, bis man sich davon überzeugt hat, dass er nicht zielführend ist. Es lohnt sich also, die Erfahrungen der Entwickler und Benutzer aus dem Umgang mit dem Unternehmensportal in dessen Weiterentwicklung explizit einzubeziehen. Dank der Rückkopplung des Gelernten ist man zudem in der Lage, Veränderungen in den Anforderungen wahrzunehmen, die sich im Laufe der Zeit zwangsläufig ergeben. Technische Neuerungen fließen auf ähnliche Weise in die Systemarchitektur des Portals ein. Damit kann das Portal nicht nur

304

■ ■ ■

10 Betrieb und Evolution

heute, sondern auch morgen den geforderten Funktionsumfang auf der Basis einer soliden technischen Architektur bieten.

10.7 Release Management Neben den genannten fachlichen Aspekten hat der Betrieb und die Weiterentwicklung eines Unternehmensportals auch eine technische Seite, die wir hier abschließend beleuchten wollen. Um es vorwegzunehmen: Der Betrieb eines Unternehmensportals unterscheidet sich aus administrativer Sicht nicht von anderen Softwaresystemen. Da ein Unternehmensportal aber zu den größeren Softwareprojekten zählt und weitreichende Auswirkungen auf viele Unternehmensbereiche hat, sollte das Release Management entsprechend ernst genommen werden. Während kleinere Softwaresysteme oft aus der Entwicklungsumgebung direkt in die Produktionsumgebung überspielt werden, haben wir bei umfangreichen Systemen mit einem mehrstufigen Freigabeprozess die besten Erfahrungen gemacht. Der zusätzliche Aufwand beim Aufbau und der Pflege der zugehörigen Systeme sowie die längeren Durchlaufzeiten bis zur Produktionsfreigabe werden durch ein hohes Maß an Betriebssicherheit, die Nachvollziehbarkeit von Programmfehlern sowie durch die Möglichkeit einer Weiterentwicklung des Systems parallel zum Test der aktuellen Version aufgewogen. Die Rolle des Release Managers sollte von einer Person wahrgenommen werden, die über weitreichende (möglichst praktische) Kenntnisse des Softwareentwicklungsprozesses verfügt. Der mit dieser Rolle verbundene zeitliche Aufwand unterliegt starken Schwankungen. Während es in der Implementierungsphase für den Release Manager wenig zu tun gibt, ist er zunehmend beschäftigt, je näher ein neues Release rückt. Diese besondere zeitliche Anforderung muss bei der Projektplanung berücksichtigt werden. Abbildung 10.3 zeigt den Prozess und die beteiligten Systeme. Diese sollten von ihrer Hardware- und Betriebssystemausstattung grundsätzlich technisch identisch sein. Sicherlich wird man für ein Testsystem einen weniger leistungsfähigen Server wählen als für das Produktionssystem, das mit größeren Benutzerzahlen umgehen muss. Werden für die verschiedenen Systeme verschiedene Rechnerarchitekturen gewählt (z.B. ein Intel-PC unter Linux für das Validierungssystem, ein Sun Server unter Solaris als Produktionsmaschine), dann kann eine fehlerfreie Validierung den fehlerfreien Produktionsbetrieb nicht mehr gewährleisten. Einsparungen bei der

10.7 Release Management

■ ■ ■

305

Hardwareausstattung können auf diese Weise schnell zu Folgekosten bis hin zu Produktionsausfällen führen. Abb. 10.3 Der Release ManagementProzess

Entwicklung

Support

Entwickler

Version x Version x' Version x+1

Validierung

Version x Version x'

Training

Benutzer

Version x Version x'

Version x Version x'

Produktion

Version x Version x'

Entwicklungssystem

306

■ ■ ■

Der Prozess beginnt mit der Entwicklung einer Version x des Unternehmensportals mit dem Ziel, diese Version in den produktiven Betrieb zu überführen. Das Entwicklungssystem dient der Entwicklung einer Version des Unternehmensportals. Auf dieses System haben grundsätzlich nur Entwickler Zugriff. Zu oft enden „spontane“ Tests durch Mitarbeiter der Fachabteilungen – die späteren Benutzer des Systems – mit einem unerwarteten Fehler, weil sich Teile des Systems mitten in der Entwicklung befinden. Der Imageverlust ist in der Regel größer als der beabsichtigte Sympathiegewinn, weil man einem Benutzer „mal eben“ Einblick in die tollen neuen Möglichkeiten der

10 Betrieb und Evolution

kommenden Version geben wollte. Die Beurteilung dieser neuen Funktionen, aber auch der Test der gegenüber der Vorgängerversion behobenen Fehler, findet daher später im Validierungssystem statt. Ein Unternehmensportal besteht aus verschiedenen selbstentwickelten Komponenten (z.B. Portalanwendungen), Anpassungen der eingesetzten Standardsoftwaremodule (z.B. Templates, die den Richtlinien der Corporate Identity des Unternehmens entsprechen), kleinen Helfern und Werkzeugen für die Entwicklung und den Test sowie Testdaten und Testfällen. All diese Artefakte sollten versioniert und dokumentiert werden. Dadurch ist gewährleistet, dass Änderungen nachvollzogen und gegebenenfalls wieder rückgängig gemacht werden können. Außerdem kann der Release Manager das auszuliefernde Gesamtpaket – sprich: das Unternehmensportal – eindeutig definieren: Eine Version des Gesamtsystems setzt sich zusammen aus der Gesamtheit aller Artefakte, von denen jedes eine bestimmte Versionsnummer trägt. Diese Versionsnummern sind nicht notwendigerweise identisch, da sich Komponenten unterschiedlich schnell weiterentwickeln können. Für die Versionierung sollte ein Versionsverwaltungssystem eingesetzt werden, z.B. CVS (Concurrent Versioning System), dessen Nachfolger Subversion oder das kommerzielle Produkt Rational ClearCase. Diese Produkte versionieren jede einzelne Datei, erlauben aber auch das Setzen eines gemeinsamen Kennzeichens (z.B. die Versionsnummer des Portals) für alle Dateien. Auf eine ausführliche Beschreibung des technischen Projektmanagements und des Release Managements soll an dieser Stelle verzichtet werden. Wir verweisen stattdessen auf das Werk zum Thema „Service Support“ aus der IT Infrastructure Library (ITIL, Berkhout et al. 2000). Weiterführende Informationen zum Produkt- und Konfigurationsmanagement von Softwaresystemen finden Sie z.B. bei Sneed et al. (2004) oder Versteegen et al. (2003). Der Release Manager ist verantwortlich für die Fertigstellung aller Artefakte zu einem definierten Zeitpunkt, ab dem keine weiteren Änderungen mehr akzeptiert werden (Code Freeze). Anschließend wird in der Entwicklungsumgebung die technische Verträglichkeit der einzelnen Komponenten getestet (technischer Integrationstest). Der Release Manager sorgt auch dafür, dass alle integrierten Systeme in der geforderten Version für diesen Test zur Verfügung stehen. War der Test erfolgreich, dann wird die fertiggestellte Version x in das Validierungssystem überführt. Dazu wird ein offizielles Versionspaket erstellt, bestehend aus allen Komponenten in den jeweiligen Versionen.

10.7 Release Management

Code Freeze

Validierungssystem

■ ■ ■

307

Sollten eine oder mehrere Komponenten fremdentwickelt worden sein, so empfehlen wir, den Quellcode nebst Dokumentation und Übersetzungsanleitung (Make-Datei, Apache-Ant-Build-Datei, etc.) einzufordern. Erst wenn Sie selbst in der Lage sind, diese Quelldateien zur fertigen Komponente zu übersetzen, sollte die Abnahme des Liefergegenstands gegenüber dem externen Dienstleister erfolgen. Der Vorteil dieser Vorgehensweise liegt auf der Hand: Sie sind jederzeit in der Lage, das Unternehmensportal aus den Quelldateien ohne fremde Hilfe zu erzeugen. Damit sind sie weitgehend unabhängig von ihren Dienstleistern und können zudem Fehler selber beheben. Die meisten Portalsysteme profitieren von dem Umstand, sich des Quellcodes von Softwarekomponenten zu bedienen, diesen den eigenen Bedürfnissen entsprechend anzupassen und damit den Anforderungen besser gerecht werden zu können. Die Version x ist bisher nur von den Entwicklern getestet worden. Diese konzentrieren sich auf die technische Funktionsfähigkeit und das reibungslose Zusammenspiel der Komponenten des Unternehmensportals. Das Testen von realistischen Nutzungsszenarien, wie sie später im Betrieb auftreten werden, fällt in vielen Fällen nicht in den Aufgabenbereich der Entwickler. Das liegt oft daran, dass den Entwicklern die fachliche Erfahrung fehlt, ohne die solche Nutzungsszenarien nicht erstellt werden können. Hier sind die späteren Benutzer bzw. deren offizielle Vertreter gefragt. Deren Hauptaufgabe ist es nun, im Validierungssystem die fachliche Eignung der Version x zu überprüfen. Dabei werden sie automatisch auch die technischen Aspekte der Zuverlässigkeit und Performanz sowie das Verhalten im Fehlerfall überprüfen. Die Ergebnisse dieses Tests werden in Protokollen oder Fehlerlisten festgehalten. Oft werden auch spezielle Softwarewerkzeuge eingesetzt, die das Beschreiben von Fehlern und der Maßnahmen zur Fehlerbehebung vereinfachen. Diese Werkzeuge bieten die Möglichkeit, Fehlerreports zu erstellen, die nach bestimmten Kriterien gefiltert und sortiert werden können. Abhängig von der Anzahl und Schwere der gefundenen Fehler sowie der Planung für die Fehlerbehebung erteilen oder verweigern die Tester die formale Abnahme der Version x. Für eine abgelehnte Version können Bedingungen formuliert werden, deren Erfüllung eine zügige Abnahme in Aussicht stellt. Um insbesondere die Performanztests unter produktionsähnlichen Bedingungen durchführen zu können, sollten das Validierungs- und das Produktionssystem technisch so ähnlich wie möglich bzw. im Idealfall identisch aufgebaut sein. Aufgrund der geringeren erwarteten Last, resultierend aus der kleineren Anzahl an Benutzern während des Tests (im Vergleich zum Produktivsystem), kommt das Va-

308

■ ■ ■

10 Betrieb und Evolution

lidierungssystem unter Umständen mit weniger Festplattenplatz und Hauptspeicher sowie weniger oder leistungsschwächeren Prozessoren aus. Nach erfolgter Abnahme der Version x wird diese in das Trainingssystem überspielt. Hier werden die Benutzer im Rahmen von Schulungen mit den neuen Funktionen des Portals vertraut gemacht. Auch während der Schulungen können Fehler auftreten. Diese werden ebenfalls protokolliert und in der Planung für die Fehlerbehebung berücksichtigt. Die Durchführung der Schulungen in einer eigenen Systemumgebung erlaubt später das Testen neuer Funktionen im Validierungssystem parallel zum Schulungsbetrieb. Schließlich wird die Version x des Unternehmensportals im Produktionssystem installiert – vorausgesetzt, die integrierten Systeme sind in der erforderlichen Version ebenfalls produktiv verfügbar. Um die Fehler, die während des produktiven Betriebs auftreten, sicher nachvollziehen zu können, ohne den Betrieb zu stören, existiert mit dem Supportsystem eine Kopie des Produktionssystems. Von Zeit zu Zeit sollten die Datenbestände aus dem Produktions- in das Supportsystem kopiert werden, um für die Fehleranalyse eine realistische Datenbasis verfügbar zu haben. Fehler, die im Supportsystem analysiert wurden, werden im Entwicklungssystem korrigiert und als Version x' zunächst im Validierungssystem getestet und schließlich in das Trainings-, das Produktions- und das Supportsystem überführt. In der Entwicklungsumgebung kann nun mit der Entwicklung der Folgeversion x+1 begonnen werden. Der Code für die nächste Version x+1 soll aber nicht Bestandteil der korrigierten Version x' sein. Für diesen Fall bieten Versionsverwaltungswerkzeuge wie CVS das Konzept des „Branch & Merge“ an. Zu Beginn der Weiterentwicklung wird ein neuer Zweig (Branch) vom Hauptentwicklungsstrang abgezweigt. In diesem Zweig werden die Änderungen für die Version x+1 vorgenommen. Aufgetretene Fehler werden im Hauptstrang korrigiert und resultieren in einer Version x' (und eventuell weiteren Korrekturversionen x'', x''' usw.). Bevor die Version x+1 für den Integrationstest in der Entwicklungsumgebung freigegeben wird, werden die Änderungen des Zweiges in den Hauptstrang eingearbeitet (Merge). Das Resultat ist eine Version x+1, die alle Fehlerkorrekturen aus dem Hauptstrang enthält (vgl. Abb. 10.4).

10.7 Release Management

Trainingssystem

Produktionssystem Supportsystem

Branch & Merge

■ ■ ■

309

Abb. 10.4 Branch & Merge

Version x

Version x+1 (inkl. x')

Version x'

Merge

Branch Version x+1

Testen als Maßnahme zur Qualitätssicherung

310

■ ■ ■

Release Management ist eine anspruchsvolle und zeitaufwendige Tätigkeit. Je mehr getrennt voneinander entwickelte Komponenten ein Softwaresystem besitzt, desto größer ist der Koordinationsaufwand, um jeweils eine Version dieser Komponenten zu einem funktionierenden Ganzen zusammenzufügen. Auch die Planung und Dokumentation der Releases erfordert viel Zeit und Erfahrung. Aus diesen Gründen wird das Thema mitunter vernachlässigt. Die Erfahrung aber zeigt, dass die Zeit- und Kostenersparnis nur von kurzer Dauer ist. Je mehr Fehlerbereinigungen „mal eben“ direkt im Produktionssystem durchgeführt werden, desto schwieriger wird es, den Systemzustand zu rekonstruieren. Das geordnete Zurücksetzen auf eine ältere Systemversion ist schließlich nicht mehr möglich. Auch die Weiterentwicklung ist gefährdet, da nicht sichergestellt werden kann, dass alle Fehlerbereinigungen in den Folgeversionen berücksichtigt sind. Ein Unternehmensportal ist aufgrund seiner enormen Außenwirkung ständig „unter Beobachtung“ durch eine große Benutzergemeinde. Auch wenn Erfolge aufgrund schnell behobener Fehler die Benutzerzufriedenheit kurzfristig steigern – mittel- und langfristig kann dieses Vorgehen dem Ansehen des Portals nachhaltig schaden – und nichts ist so schwer zu reparieren wie ein schlechter Ruf. Um den Abnahmeprozess eines Releases zu beschleunigen, sollten Testfälle und Testdaten definiert werden. Werden diese Tests im Rahmen jeder Abnahme wiederholt durchgeführt (Regressionstest), so kann z.B. gewährleistet werden, dass Funktionen der letzten Softwareversion auch in der neuen Version noch fehlerfrei zur Verfügung stehen. Mit jedem Release wird sich dieser Satz von Testfällen und Testdaten erweitern. Die Testverfahren sind im Detail im Abschnitt 9.2.6 beschrieben.

10 Betrieb und Evolution

11 Nutzenanalyse und Erfolgskontrolle

Die Einführung eines Unternehmensportals ist stets mit betriebswirtschaftlichen Zielen verbunden. Doch die konkrete Ermittlung des wirtschaftlichen Nutzens eines Unternehmensportals stellt sich zumeist als nicht ganz einfach dar, auch wenn die sogenannten Business needs eindeutig beschrieben werden können. Die Schwierigkeiten bei der Ermittlung des Wirtschaftlichkeitspotenzials resultieren aus den zahlreichen Berührungspunkten eines Portals innerhalb eines Unternehmens (Organisation, Prozesse, Technik) und aus den schwer in Zahlen bewertbaren Vorteilen in den Bereichen der Miteinanderarbeit und der gemeinsamen Informationsnutzung. In diesem Kapitel werden die beiden Kennzahlen Return on Investment (ROI) und Total Cost of Ownership (TCO) näher betrachtet, und es wird erläutert, wie diese trotz der schwierigen Bewertungsgrundlage für Unternehmensportale ermittelt werden können.

Kurz gefasst

11.1 Was nützt der Nutzen? Die TechConsult-Studie „Portale in Deutschland“ (Berg 2004) ergab, dass Organisationen Schwierigkeiten haben, den Return on Investment (ROI) von Portalen zu messen. In der Studie führen 48 Prozent der Unternehmen, die weder ein Portal einsetzen noch eines planen, diese Unklarheit als Hauptgrund für den Verzicht auf eine Portaleinführung an. Die Studie unterstreicht, dass die Investition in ein Unternehmensportal betriebswirtschaftlich gerechtfertigt sein muss. Demzufolge muss sich ein Portal am Grad seiner Zielerreichung messen lassen.

11.1 Was nützt der Nutzen?

■ ■ ■

311

Abb. 11.1 Einsparungspotenziale (nach Delphi Group 2003)

Hard Facts A Verringerte Druck- und Verteilkosten B Verbesserter Zugang zu nützlichen Informationen C Zentralisierter Einkauf von Waren Hard Skills D Verringerte Kommunikationskosten E Bessere Unterstützung bei Entscheidungen F Erweiterte Corporate Identity G Geschärftes Bewusstsein für Best Practices H Verdichtete Trainingszyklen

H C

G

D F

A

E

B 1 2 3 4

Einsparpotenzial groß durchschnittlich gering

Strategische und betriebliche Vorteile 1 Verbesserung der organisatorischen Effizienz 2 Aufbau einer offenen Informationskultur 3 Personalisierbarer Single Point of Entry 4 Unterstützung für schnelleres Wachstum

Wie Abbildung 11.1 zeigt, sind die mit einem Unternehmensportal zu realisierenden Einsparpotenziale vielfältig. Dabei sind die „Hard Facts“ dieses Potenzials, wie z.B. die Senkung direkter Prozesskosten oder die Reduktion von Materialkosten für Kommunikationsmittel, relativ einfach zu bewerten und in Zahlen auszudrücken. Betrachtet man aber die weiteren Ziele, die mit der Einführung eines Unternehmensportals einhergehen, beispielsweise ein verbessertes Wissensmanagement oder eine erhöhte Servicequalität, so stellt man schnell fest, dass sich viele Nutzenaspekte eines Portals nicht in quantifizierbaren Größen ausdrücken lassen. Dennoch tragen diese qualitativen Faktoren einen erheblichen Teil zum Nutzen eines Unternehmensportals bei. Daher müssen sie einerseits in der Nutzenbetrachtung eines Portals berücksichtigt werden, dürfen aber auf der

312

■ ■ ■

11 Nutzenanalyse und Erfolgskontrolle

anderen Seite nicht dazu missbraucht werden, den ROI-Wert eines Portals schönzurechnen. Neben den quantitativen und qualitativen Faktoren sollte die Analyse des Portalnutzens auch die Auswirkung des Portals auf zukünftige IT-Projekte berücksichtigen. Dabei darf die Nutzenbetrachtung nicht allein retrospektiv geschehen. Wie im Kapitel 9 dargestellt, muss sie einerseits bereits am Anfang des Projektes stattfinden, um die Entscheidung für die Einführung eines Unternehmensportals zu untermauern und Fehlstrategien zu vermeiden. Anderseits dient eine kontinuierliche Wirtschaftlichkeitsanalyse vor, während und nach der Portaleinführung dazu, das Portal auf seine strategischen Ziele zu beziehen und es konsequent an diesen auszurichten.

11.2 Return on Investment (ROI) Eine der wichtigsten Kennzahlen zur Beurteilung der Wirtschaftlichkeit eines Unternehmensportals ist der Return on Investment. Der Return on Investment (ROI; Kapitalrendite) ermittelt das Verhältnis der Investitionen (in ein bestimmtes Projekt) zu den resultierenden höheren Umsätzen oder gesenkten Kosten. Der ROI ist eine aus der Rentabilitätsrechnung abgeleitete Kennzahl für die Rentabilität einer Unternehmung bzw. ihrer Teilbetriebe, Abteilungen oder Einzelinvestitionen. ROI-Berechnungen dienen als Grundlage für die Unternehmenspolitik und Unternehmensplanung. Sie sind ein Mittel der Entscheidungsvorbereitung, das die Verantwortlichen zu einer Kosten-Nutzen-Analyse sowie einer Risiko-Analyse zwingt. Während bei der Anschaffung von Produktionsmaschinen der Nutzen dieser Investition relativ einfach in Zahlen zu fassen ist, stehen Unternehmen bei der Rentabilitätsbetrachtung von IT-Projekten im Generellen immer wieder vor dem Problem, Effizienzsteigerungen (z.B. bei der Informationsrecherche), Mitarbeitermotivation, Kundenbindung und -zufriedenheit und ähnliche „weiche“ Faktoren in monetären Größen ausdrücken zu müssen (vgl. Tabelle 11.1). Gerade bei Portalprojekten hängt diese Betrachtung außerdem sehr von dem Einsatzzweck und der Zielsetzung eines Portals ab. Viele Kennzahlen für die Berechung der Rentabilität eines internen Unternehmensportals unterscheiden sich sehr von den beispielsweise für Absatzportale im B2C-Bereich verwendeten Kennzahlen. Die Nutzenpotenziale eines Unternehmensportals sind vielfältig. Die wesentlichsten Potenziale, die in die Wirtschaftlichkeitsbetrach-

11.2 Return on Investment (ROI)

Rentabilität von Unternehmensportalen

■ ■ ■

313

Senkung der direkten Prozesskosten

Qualitative Verbesserung der operativen Prozesse

Reduzierung der operativen Kosten

314

■ ■ ■

tung eines Portals einfließen sollten, werden im Folgenden etwas genauer betrachtet. Durch die Automatisierung und Strukturierung von Geschäftsprozessen lassen sich erhebliche Einsparungseffekte erzielen. Die Automatisierung von Routineaufgaben verkürzt die Prozesslaufzeiten und reduziert den Ressourcenbedarf des Geschäftsprozesses. Die Standardisierung des Prozesses verringert den Abstimmungsaufwand und die Wartezeiten in der Prozesskette. Die automatische Bereitstellung kontextrelevanter Informationen erhöht zudem die Durchlaufgeschwindigkeit des Prozesses. Durch die technische Abbildung der Prozessketten lässt sich der Ablauf des Geschäftsprozesses verfolgen und seine Warte- sowie Durchlaufzeiten ermitteln, die dann in die Nutzenanalyse des Portals einfließen können. Die technische Abbildung und Steuerung von Geschäftsprozessen beschleunigt und verschlankt diese aber nicht nur, sondern trägt auch zu einer steigenden Qualität der Prozesse bei. Die Strukturierung und eindeutige Definition der Prozesse führt zu einer Standardisierung der Arbeitsweisen und lässt die Geschäftsprozesse geradliniger und mit einer verbesserten und einheitlichen Ergebnisqualität ablaufen. Die Priorisierung einzelner Prozesse hängt beispielsweise nicht mehr von der subjektiven Sichtweise einzelner Mitarbeiter ab, sondern wird aufgrund definierter Regeln durch das Portal vorgegeben. Die Standardisierung der Arbeitsweisen in den einzelnen Prozessschritten führt außerdem zu einer höheren Planbarkeit für die Unternehmensführung. Durch die technische Steuerung und Protokollierung der Geschäftsvorfälle wird deren Status transparent. Ineffektive Prozessschritte und Fehlerquellen können erkannt und gezielt optimiert werden. Des Weiteren kann die Arbeitsmotivation der Mitarbeiter erhöht werden: Sie erfahren eine qualitative Aufwertung ihrer Arbeit, da sie sich dank der Automatisierung der routinemäßigen Tätigkeiten auf die kreativeren und strategischen Aspekte ihrer Arbeit konzentrieren können. Durch den Einsatz eines Unternehmensportals als zentrale Kommunikations- und Datenaustauschschnittstelle des Unternehmens lassen sich im operativen Bereich erhebliche Einsparpotenziale aktivieren. So können beispielsweise die Aufwände für Portokosten, Papierverbrauch sowie Telefon- und Faxgebühren durch den Einsatz eines Portals erheblich reduziert werden. Während diese Faktoren neben Aspekten wie einem etablierten Wissensmanagement oder einer Optimierung der geschäftskritischen Prozesse relativ unspektakulär anmuten, darf deren Beitrag zu einem positiven ROI nicht unterschätzt werden. Bisweilen reichen alleine die Einsparungen im

11 Nutzenanalyse und Erfolgskontrolle

Bereich der Kommunikation aus, um den Einsatz eines Portals betriebswirtschaftlich zu rechtfertigen. Ein Unternehmensportal verbessert die Informationsversorgung der Mitarbeiter. Das Portal stellt dem Anwender kontextbezogen die relevanten und aktuellen Informationen zur Verfügung. Damit ist die Voraussetzung für die Verbesserung der Informationsqualität und die Reduzierung von Rechercheaufwänden geschaffen. Diese ermöglichen dem Unternehmen schnellere Reaktionszeiten auf Veränderungen im Markt, eine erhöhte Auskunftsfähigkeit gegenüber Anteilseignern, verbesserte Dienstleistungen gegenüber seinen Kunden und optimierte Lieferketten. Je nach Ausrichtung des Portals und der Branche des Unternehmens schlagen sich diese Potenziale mitunter direkt in einem Umsatzplus nieder. Das Unternehmensportal kann die bestehenden Prozesse eines Unternehmens nicht nur optimieren. Bestimmte Geschäftsprozesse werden erst durch die Infrastruktur eines Portalsystems möglich. Dies ist vor allem bei allen Prozessen des Wissensmanagements und der Miteinanderarbeit der Fall. Ohne ein Portal als technische Basis ist die zeitgleiche Verteilung von Informationen innerhalb des gesamten Unternehmens kaum möglich. Ein noch größeres Potenzial entwickelt das Portal, wenn es um das Management des Unternehmenswissens geht. Durch die kontextabhängige Präsentation von Informationen werden Wissenshoheiten innerhalb des Unternehmens aufgelöst. Die Wissensbasis, die dem einzelnen Mitarbeiter zur Verfügung steht, verbreitert sich und wird durch die Konzentration auf aktuelle und relevante Informationen qualitativ hochwertiger. Die Redaktionsprozesse des Portals stellen die Infrastruktur dar, mit der das in den Köpfen einzelner Mitarbeiter vorhandene Wissen erfasst und so dem gesamten Unternehmen zur Verfügung gestellt wird. Unternehmensportale können auf diese Weise dazu beitragen, dass auch geographisch stark diversifizierte Unternehmen enger zusammenwachsen. Dieser Aspekt kommt besonders bei Fusionen und Übernahmen zum Tragen und macht das Portal zu einem wichtigen Werkzeug bei der Umsetzung strategischer Zielsetzungen. Auch Portalfunktionen, die keinen direkten Beitrag zur Wertschöpfung eines Unternehmens leisten, müssen, wenn auf sie nicht verzichtet werden kann, mit ihren Opportunitätskosten in die Nutzenbetrachtung einfließen. Diese Funktionen werden dann mit den Kosten bewertet, die dem Unternehmen durch ihren Verzicht entstanden wären. Die Integration von Daten und Anwendungen durch eine zentrale und skalierbare Integrationskomponente reduziert die Anzahl der Schnittstellen innerhalb der IT-Infrastruktur. In Kombination mit der Auflösung einer redundanten Datenhaltung durch einen zentralen

11.2 Return on Investment (ROI)

Umsatzgenerierung

Strategische Potenziale

Opportunitätskosten

Integration der bestehenden ITLandschaft

■ ■ ■

315

Einhaltung gesetzlicher Bestimmungen

Tabelle 11.1 Beispielhafte Kriterien einer Nutzenanalyse

316

■ ■ ■

Zugriff auf die Unternehmensinformationen reduziert sich so der Wartungs- und Entwicklungsaufwand für die Pflege der ITLandschaft. Ebenfalls in die Nutzenbetrachtung des Portals muss der Aspekt des Investitionsschutzes einfließen. Die Einführung eines Portals stellt in den meisten Fällen die bereits getätigten ITInvestitionen nicht in Frage, sondern nutzt die bestehende Infrastruktur und bündelt sie in einer zentralen Benutzungsoberfläche. Daneben ermöglicht es die Single-Sign-On-Funktionalität, die Zugriffsberechtigungen an einer zentralen Stelle zu administrieren. Dadurch werden zum einen die Administrationskosten für die Benutzer- und Rechteverwaltung verringert und zum anderen ein einheitliches Sicherheitskonzept für die gesamte Systemlandschaft implementiert. Je nach Branche, Gesellschaftsform und Größe des Unternehmens gelten für dieses mehr oder minder strikte gesetzliche Bestimmungen. Diese gesetzlichen Vorgaben beziehen sich z.B. auf die Archivierung von Dokumenten oder die Publikation von Geschäftszahlen. Das Portal unterstützt beispielsweise durch eine automatische Archivierung von Informationen oder das Aufzeichnen einzelner Prozessschritte die Einhaltung derartiger Archivierungsvorschriften. Darüber hinaus hilft die Transparenz der Geschäftsprozesse und das automatische Ermitteln von Kennzahlen dem Unternehmen bei der Erfüllung seiner Informationspflicht gegenüber den Anteilseignern und Kontrollorganen. Diese technische Unterstützung gibt dem Unternehmen eine größere Verfahrenssicherheit bei der Einhaltung gesetzlicher Vorgaben, da die Ausführung nicht mehr von persönlichen Arbeitsweisen einzelner Mitarbeiter abhängt. Kritische Erfolgsfaktoren

Potenziale

Messbare Kriterien

Zeit

Höhere Transparenz Reduzierung manueller Schnittstellen Verfügbarkeit von Wissen Schnellere Integration neuer Anwendungen Zentraler, einfacher Betrieb und Wartung

Zahl der manuellen Schnittstellen Zahl der verwendeten Schnittstellenstandards

11 Nutzenanalyse und Erfolgskontrolle

Kritische Erfolgsfaktoren

Potenziale

Messbare Kriterien

Kosten

Höheres Maß an Standardisierung Nutzung von Synergien zwischen Abteilungen in einer Gruppe von Unternehmen Vermeidung unwirtschaftlicher Investitionen Reduzierung der Kosten für spätere Rekonfiguration Größere Benutzerakzeptanz Höhere Qualität von neuen Applikationen Höhere Sicherheit Bessere Auskunftsfähigkeit Einfach an neue Anforderungen anzupassen bzw. zu erweitern Einfache Internationalisierung

Einführungskosten Integrationskosten Betriebs- und Wartungskosten Zahl der Medienbrüche Zahl der Schnittstellen

Qualität

Flexibilität

Anzahl der Beschwerden Fehlerrate Performanz Verfügbarkeit Kosten für Wartung und Betrieb Zeit und Aufwand für Weiterentwicklungen

Tabelle 11.1 gibt einen Überblick über verschiedene beispielhafte Potenziale einer Portaleinführung und deren Messbarkeitskriterien. In der Tabelle wird deutlich, dass sich auch schwer quantifizierbare Aspekte, wie z.B. die Benutzerakzeptanz eines Portals, anhand von messbaren Kriterien wie Fehlerrate oder Beschwerdenanzahl quantifizieren lassen. Die Herausforderung liegt hier darin, Richtgrößen zu definieren, die aussagekräftig sind und eine Interpretation der ermittelten Zahlen ermöglichen. Der Portalnutzen kann mit Hilfe einer Matrix realisiert werden. In dieser werden die einzelnen Effizienzziele aufgeführt, die sich durch den Einsatz eines Portals ergeben. All diese Ziele – harte, weiche und strategische Faktoren – werden einzeln bewertet und mit Richtgrößen versehen. Lassen sich für einen Faktor keine objektiven Messgrößen ermitteln, so werden die Richtgrößen als Anforderungen von den Fachabteilungen definiert und beruhen oftmals auf Erfahrungswerten. Der Unsicherheit bei der Ermittlung des ROI, bedingt durch den Einfluss vieler nicht exakt bekannter Parameter, kann entgegengewirkt werden, indem man den Grad der Unsicher-

11.2 Return on Investment (ROI)

Nutzenmessung

Konzepte zur Berechnung des ROI

■ ■ ■

317

Portal-ROI in der Praxis

heit zu den jeweiligen (geschätzten) Parametern angibt. Danach wird abgeschätzt, wie realistisch die Zielerreichung dieser ausgewählten Eingangsparameter durch die Einführung eines Portals ist. Eine Balanced Scorecard, wie sie im Abschnitt 9.6 dargestellt wird, kann beispielsweise als Grundlage für diese Nutzenanalyse dienen. Durch die Untersuchung des gesamten Spektrums der möglichen Eingangsparameter für die Rentabilitätsrechnung lässt sich die Spannbreite des ROI ermitteln. Diese ROI-Analyse lässt erkennen, inwieweit ein Unternehmensportal die Prozesse zur Wertschöpfung optimieren kann, und dient zur Überprüfung der eigenen Zielsetzung bzw. einer Anpassung derselben. Auch wenn sich der ROI eines Unternehmensportals nicht völlig exakt ermitteln lässt, motiviert eine Studie der Delphi Group (2003) doch für einen (betriebswirtschaftlich begründeten) Einsatz eines Unternehmensportals. Der Studie zufolge verfehlen nur zwei Prozent aller Portalinstallationen das Ziel eines positiven ROI. Bei CRM-Installationen sind dies beispielsweise schon 40 Prozent. Die Studie beschreibt, dass 22 Prozent der befragten Unternehmen einen ROI-Wert von 21 bis 50 Prozent ermittelten. Bei 18 Prozent der Unternehmen überstieg der ROI-Wert sogar 100 Prozent.

11.3 Total Cost of Ownership (TCO) Total Cost of Ownership (TCO) ist ein von der Gartner Group entwickeltes Modell, demzufolge beim Erfassen der tatsächlichen Kosten verteilter Informationssysteme alle Faktoren berücksichtigt werden müssen. Zu diesen Gesamtbetriebskosten zählen unter anderem die Beschaffungskosten, der technische Support und die Administration. Im Wesentlichen geht es darum, dass die tatsächlichen Kosten für die Beschaffung, Bereitstellung und Wartung von Computeranwendungen für eine Gruppe von Benutzern weit höher sind als die ursprünglichen Anschaffungskosten für Hard- und Software. Im Rahmen der TCO-Betrachtung muss beleuchtet werden, aus welchen Faktoren sich die Kosten für Computeranwendungen zusammensetzen. Außerdem müssen Antworten auf die Frage gefunden werden, welche Möglichkeiten es gibt, diese Kosten zu erfassen und zu reduzieren.

318

■ ■ ■

11 Nutzenanalyse und Erfolgskontrolle

Die TCO-Betrachtung für ein Unternehmen umfasst die folgenden Kostenarten: ■

Anschaffungen für Hardware, Netzwerk und Software (Neuanschaffungen und Aktualisierungen),

■

Kosten für System- und Netzwerkmanagement,

■

Wartungskosten,

■

Laufende Kosten beim Anwender,

■

Softwareentwicklungskosten,

■

Netzwerk-Kommunikationsgebühren,

■

Kosten durch entgangene Erträge aufgrund von Systemausfallzeiten.

Die Anschaffungskosten für Hard- und Software sind diejenigen TCO-Kosten, die am leichtesten zu erfassen sind. Obwohl diese Kosten erheblich sein können, machen sie bei der Bereitstellung eines Client-Arbeitsplatzes im Verlauf seiner Betriebszeit weniger als ein Drittel des TCO-Wertes aus. Zur Reduzierung der Kosten wird in den meisten TCO-Analysen die Anschaffung komplett neuer Hardware- bzw. Systemmanagement-Lösungen vorausgesetzt. Die Kosten eines solchen Austauschs wesentlicher Komponenten in umfangreichen IT-Umgebungen sind jedoch hoch. Eine ideale Lösung sichert daher die getätigten Investitionen in die Arbeitsplatzinstallationen, arbeitet mit verschiedenen Client-Hardwarekonfigurationen und Plattformen und bindet die vorhandene Netzwerkinfrastruktur effizient ein. Im Vergleich zu herkömmlichen Client-Server-Systemen lassen sich bei Portalen die Kosten pro Arbeitsplatz vergleichsweise gering halten, da die Anwendungslogik auf wenigen zentralen Servern liegt und die Anwender keine eigene Client-Software benötigen, sondern über einen Webbrowser (oder gegebenenfalls mobile Endgeräte) auf das Portal zugreifen können. Damit können Clients unabhängig von der Hardwarekonfiguration, dem Betriebssystems (eine gewisse Minimalkonfiguration vorausgesetzt) und vor allem vom Standort auf das Portal zugreifen. Kosten- und zeitintensive Rollouts sowie Administration, Support und Updates für Client-Software entfallen. Der Administrations-, Archivierungs- und Konfigurationsaufwand beschränkt sich auf die Server, auf denen die einzelnen Portalkomponenten installiert sind. Außerdem lässt sich eine hohe Ausfallsicherheit kritischer Systemfunktionen über redundante Komponenten garantieren.

11.3 Total Cost of Ownership (TCO)

TCOKomponenten

Kostenerfassung und -reduzierung

TCO von Portalen

■ ■ ■

319

Wenn nicht sichergestellt werden kann, dass der Zugriff auf das Portal stets mit einem definierten Browsertyp erfolgt (da beispielsweise auch externe Partner das Portal nutzen), muss beachtet werden, dass den reduzierten Kosten für die Clients ein entsprechend erhöhter Aufwand für Test und Implementierung gegenübergestellt werden muss. Die Portaloberfläche muss in diesem Fall mit einer Vielzahl von Browsern auf unterschiedlichen Plattformen getestet und für diese entsprechend optimiert werden. Durch eine komponentenbasierte, serverzentrierte Portalarchitektur, die auf Standardprotokollen basiert, kann die bestehende Netzwerkinfrastruktur genutzt werden. Clients können sich entweder über das lokale Netzwerk oder über das Internet mit dem Webserver des Portals verbinden. Durch den Einsatz von Webtechnologien ist die Anzahl der Clients, die parallel auf das Portal zugreifen, theoretisch unbeschränkt. Allerdings muss berücksichtigt werden, dass der Portalzugriff, abhängig von der gewählten Technik für die Benutzungsoberfläche, eine erhebliche Netzlast verursachen kann. Die bestehende Netzwerkinfrastruktur muss auf diese Lastanforderungen hin untersucht und gegebenenfalls aufgerüstet werden. Mit einem Webbrowser als Standard-Client und einem intuitiven Aufbau der Portaloberfläche, der sich an gängigen Navigationskonzepten orientiert, kann der Schulungsaufwand für den Betrieb eines Portals sehr gering gehalten werden.

11.4 Nutzensicherung Zukunftsfähigkeit

320

■ ■ ■

Moderne Unternehmensportale, die sich durch eine zukunftsweisende, komponentenbasierte Architektur auszeichnen, stellen eine offene und skalierbare technische Plattform dar. Eine derartige Architektur kann sich flexibel mit den Anforderungen eines Unternehmens weiterentwickeln und lässt sich um weitere Portalfunktionen ergänzen. Durch einen komponentenbasierten Entwurf kann die vorhandene IT-Infrastruktur genutzt werden. Die Verwendung moderner, offener Middleware-Technologien als Integrationsplattform erlaubt die Anbindung beliebiger Datenquellen, um das Unternehmensportal zur zentralen Informationsquelle des Unternehmens auszubauen. Dadurch werden die bereits getätigten Investitionen in IT-Systeme gesichert, und neue Systeme lassen sich flexibel in das Portal integrieren. Der Einsatz standardisierter Technologien sichert darüber hinaus die technische Zukunftsfähigkeit eines Portals.

11 Nutzenanalyse und Erfolgskontrolle

Zusammenfassend lässt sich zum Thema Nutzenanalyse und Nutzensicherung sagen, dass im Bereich der Prozesse die größten Beiträge zur Wirtschaftlichkeit eines Unternehmensportals zu erwarten sind, da mit einer verbesserten Effizienz der Geschäftsprozesse im Regelfall eine Steigerung der Produktivität einhergeht. Zum Ende dieses Kapitels sei noch einmal darauf hingewiesen, dass der Nachweis der Wirtschaftlichkeit einer Portalinstallation immer dann besonders leicht gelingt, wenn man bereits in die Konzeption des Portals Nutzenaspekte einfließen lässt. Die Einführungsprioritäten von Portalfunktionen sollten sich vorrangig an deren direktem Beitrag zur Wirtschaftlichkeit eines Portals orientieren. Allerdings sollte man gerade bei der Auswahl eines Portalproduktes die langfristige Entwicklung und Sicherung des Nutzenpotenzials eines Unternehmensportals betrachten. Im Regelfall fällt die Wahl auf ein bestimmtes Portalprodukt, weil es eine geforderte Funktion besonders gut adressiert. Für diesen initiierenden Anwendungsfall wird man damit in relativ kurzer Zeit einen positiven ROI realisieren können. Die alleinige Betrachtung dieses kurzfristigen Erfolges vernachlässigt aber die Vorteile, die langfristig realisiert werden können. Bei einer langfristigen Planung erweisen sich oftmals andere Produkte als besser geeignet.

11.4 Nutzensicherung

Steigerung der Produktivität

Frühzeitige Berücksichtigung von Nutzenaspekten

Langfristige Entwicklung des Nutzenpotenzials

■ ■ ■

321

12 Vorgehensmodell

Alle Aspekte eines Unternehmensportals werden in diesem Kapitel in einen Projektprozess eingebettet. Dadurch werden die behandelten Phasen, Themen, Prozesse und Artefakte zueinander in Beziehung gesetzt. Anstatt das Rad neu zu erfinden haben wir uns an etablierten Vorgehensmodellen für IT-Projekte orientiert. Zu Beginn dieses Kapitels gehen wir der Frage nach, welchen Nutzen ein Vorgehensmodell erbringt. Danach entwerfen wir ein Vorgehensmodell für Portalprojekte, dessen einzelne Schritte und Aktivitäten im Anschluss genauer betrachtet werden.

Kurz gefasst

12.1 Warum ein Vorgehensmodell? Portalprojekte leiten sich zumeist aus einer übergeordneten Unternehmensstrategie ab. Damit betreffen Portale sowohl die Organisation als auch die Prozesse und die IT-Landschaft des Unternehmens. Portalprojekte befinden sich dadurch in einem komplexen Spannungsfeld mit unterschiedlichen Einflussfaktoren (vgl. Abb. 12.1). ■

Wirtschaftlichkeit: Ein Unternehmensportal muss einen nachweisbaren betriebswirtschaftlichen Nutzen erbringen.

■

Fachliche Anforderungen: Sie sind komplex, zum Teil konträr und müssen von den Projektbeteiligten verstanden werden.

■

IT-Know-how: Die Bandbreite der zu integrierenden Systeme sowie die Architektur des Portalsystems selbst erfordern ein breit gefächertes Wissen, das die verschiedensten technischen Disziplinen umfasst.

■

Organisatorische Herausforderungen: Sie entstehen durch die Vielzahl der von einem Portalprojekt betroffenen Interessengruppen und durch die organisatorischen Veränderungen, die mit der Einführung eines Unternehmensportals einhergehen.

12.1 Warum ein Vorgehensmodell?

■ ■ ■

323

Abb. 12.1 Einflussfaktoren eines Portalprojektes

■

Portalkompetenz: Für eine realistische Aufwandsabschätzung und eine stringente Umsetzungsphase sind fundierte Erfahrungen mit Portaltechnologien erforderlich.

■

Projektorganisation: Während der gesamten Projektlaufzeit müssen die verschiedenen Einflussfaktoren des Portalprojektes verstanden und koordiniert werden. Portalprojekt ITKnow-how

Fachlichkeit

Organisation

Portal Portalkompetenz

Wirtschaftlichkeit

Projektorganisation

Aufgabe eines Vorgehensmodells

324

■ ■ ■

Zur Koordination dieser unterschiedlichen Aspekte in einem Portalprojekt ist ein objektives und neutrales Vorgehen vonnöten. Ein entsprechendes Vorgehensmodell dient dem Projekt als roter Faden und sorgt für eine konsequente und effektive Verfolgung der zu Beginn definierten Ziele. Je komplexer ein Projekt ist, desto größer ist die Bedeutung, die einem Vorgehensmodell zukommt. Die im Vorgehensmodell definierten Projektphasen und Ergebnisdokumente sind das Raster, an dem sich der spätere Projektplan orientiert. Das schafft schon früh eine gewisse Planungssicherheit hinsichtlich der benötigten Ressourcen (Zeit, Geld und Personal). Der Markt für Portalsysteme bietet eine Vielzahl verschiedener Produkte und Zusatzkomponenten mit unterschiedlichen fachlichen und technischen Schwerpunkten. Um nicht schon zu Projektbeginn eine Softwareauswahl treffen zu müssen, die den weiteren Projektverlauf einschränken würde, ist eine hersteller- und technikunabhängige Sichtweise erforderlich. Diese Sichtweise lenkt den Blick auf die fachlichen Anforderungen. Der Abgleich mit den technischen

12 Vorgehensmodell

Möglichkeiten einzelner Portalprodukte findet erst dann statt, wenn alle Anforderungen bekannt und beschrieben sind. Gute Vorgehensmodelle entstehen nicht am Reißbrett, sondern sind das Ergebnis früherer Erfahrungen aus ähnlichen Projekten. Best Practices helfen bei der Vermeidung typischer Stolperfallen und unterstützen einen zeit- und kosteneffizienten Projektverlauf.

12.2 Das Vorgehensmodell für Portalprojekte Wir haben etablierte Vorgehensmodelle für IT-Projekte (z.B. VModell XT, www.v-modell.iabg.de) als Grundlage gewählt und diese um portalspezifische Aspekte ergänzt. Das Ergebnis ist ein modular aufgebautes Vorgehensmodell, das den gesamten Prozess von der Zielfindung bis zum Betrieb des produktiven Portals unterstützt. Die Projektschritte und Methoden können flexibel an die konkreten Belange eines Unternehmens angepasst werden. Dabei adressiert das Vorgehensmodell alle Dimensionen eines Portalprojektes – von organisatorischen Belangen über Portaltechnologien bis hin zur Geschäftsprozessoptimierung. Abbildung 12.2 stellt die verschiedenen Aktivitäten bei der Einführung von Unternehmensportalen in einen fachlichen Zusammenhang und zeigt die Artefakte, die im Laufe der Portaleinführung entstehen. Diese Dokumente „leben“. Im Gegensatz zu phasenorientierten Vorgehensmodellen gilt ein Dokument nach Abschluss eines Teilprozesses nicht als fertig, sondern wird iterativ und evolutionär weiterentwickelt. Die Prozessdokumente werden kontinuierlich und kontrolliert an die Erkenntnisse und strategischen Entscheidungen sowie Änderungen aus dem Entwicklungsprozess angepasst. Dementsprechend ist die Dokumentation – neben dem Prototyping, das mit der visuellen Modellierung der Systemidee ebenfalls Dokumentationscharakter besitzt – als kontinuierlicher Prozess ausgestaltet.

Iterative, evolutionäre Vorgehensweise

Bei der folgenden Betrachtung der einzelnen Prozessschritte des Vorgehensmodells wollen wir insbesondere dessen portalspezifische Eigenschaften herausstellen. Wir gehen davon aus, dass Sie grundsätzlich mit der Durchführung von IT-Projekten vertraut sind. Deshalb verzichten wir an dieser Stelle auf eine vollständige Erläuterung aller Prozessdetails. Die querschnittlichen Themen Projektmanagement und Prototyping werden an dieser Stelle nicht betrachtet. Die sind Gegenstand der Kapitel 8 und 9.

12.2 Das Vorgehensmodell für Portalprojekte

■ ■ ■

325

Abb. 12.2 Vorgehensmodell für Portalprojekte

Zielfindung Vision, Systemidee Anforderungsanalyse - Funktionale Anforderungen - Nicht-funktionale Anforderungen - Analyse des Integrationspotenzials - Change Management

Anforderungskatalog Analyse der Informations-, prozess- und Systemlandschaft - Relevante Geschäftsprozesse - Relevante Inhalte (Content) - Analyse der Organisation - Technische Schnittstellen

Projektmanagement

Zielfindung

- Wirtschaftliches Potenzial

Fachkonzept Portalkonzeption - Grobkonzeption - Sicherheits- / Berechtigungskonzept - Technologie- und Produktauswahl - Feinkonzeption - Wirtschaftlichkeitsbetrachtung

Portalkonzept Implementierung - Umsetzung - Qualitätssicherung - Einführungskonzeption - Schulungskonzeption

Test

Einführung - Schulungen - Deployment - Wirtschaftlichkeitsanalyse

326

■ ■ ■

12 Vorgehensmodell

nächste Iteration

12.2.1 Zielfindung Aus der übergeordneten Strategie des Unternehmens werden in der ersten Phase der Zielfindung die wertschöpfenden Potenziale für ein Unternehmensportal identifiziert und konkret und verbindlich in den Projektzielen festgehalten. Zur Erarbeitung der Portalvision und zur Feststellung des IstZustandes eignen sich Zielfindungsworkshops. In diesen werden die verschiedenen, mitunter konträren Interessen der beteiligten Parteien beleuchtet. Um zu tragfähigen Zielen zu kommen, müssen die Ergebnisse eines solchen Zielfindungsprozesses vor dem Hintergrund der Organisation des Unternehmens und seiner Kultur betrachtet werden. Die allgemeine Forderung nach Quantifizierbarkeit und Messbarkeit von Zielen gilt auch im Kontext von Unternehmensportalen. Ohne diese Eigenschaften lässt sich weder der Projekterfolg bestimmen noch eine Kosten-Nutzen-Analyse durchführen. Der Prozess der Zielfindung mündet in einer Vision, die in einer Systemidee konkretisiert und verfeinert wird. Die Vision dient während des gesamten Projektverlaufs als roter Faden. Sie verändert sich üblicherweise nicht – im Gegensatz zur detaillierteren Systemidee, die in Teilen revidiert oder erweitert werden kann, wenn neuere Erkenntnisse oder technische Entwicklungen den Projektverlauf beeinflussen. Aus dieser ersten Idee eines Portalsystems lässt sich eine grobe Übersicht über die erforderlichen Optimierungen in der Organisation, den Prozessen und den Systemen des Unternehmens ableiten. Bereits jetzt sollte der wirtschaftliche Nutzen eines Unternehmensportals abgeschätzt werden, um die Investitionen in das Portalsystem gegenüber dem Management rechtfertigen zu können.

Vision und Systemidee

12.2.2 Anforderungsanalyse Je genauer die Anforderungen an das Unternehmensportal erfasst werden, desto sicherer lässt sich dessen Einführung planen. Im Rahmen der Anforderungsanalyse werden alle funktionalen und nicht-funktionalen Anforderungen gesammelt, aggregiert und analysiert. Dabei gilt grundsätzlich, dass Anforderungen erst als solche bezeichnet werden, wenn sie detailliert definiert und niedergeschrieben sind. Um sich über Anforderungen zu verständigen, Unklarheiten zu klären und domainspezifische sprachliche Barrieren zu überwinden, muss eine für das Projekt geltende Normsprache, beispiels-

12.2 Das Vorgehensmodell für Portalprojekte

Funktionale und nicht-funktionale Anforderungen

■ ■ ■

327

Analyse des Integrationspotenzials

Change Management

Anforderungskatalog

weise in Form eines Glossars, entwickelt werden. Vielfach werden außerdem Prototypen und Anwendungsfallbeschreibungen (Use Cases) in die Anforderungsanalyse einbezogen. Ausgehend von den erhobenen Anforderungen wird das Integrationspotenzial der relevanten (von der Portaleinführung betroffenen) Geschäftsprozesse und der darunterliegenden IT-Infrastruktur analysiert. Dies ist notwendig, um die technischen Anforderungen an das Portalsystem vollständig beschreiben zu können. Die Anforderungsermittlung ist ein iterativer Prozess, der mehrfach durchlaufen wird und auch in späteren Iterationen noch wichtige Erkenntnisse zutage fördern kann. Bereits in der ersten Iteration ist es sinnvoll, einen Change-Management-Prozess im Projekt einzuführen. Auf diese Weise kann sichergestellt werden, dass jene Anforderungen, die nicht in der ersten Realisierungsphase des Portals berücksichtigt werden, später nicht in Vergessenheit geraten. Das Ergebnis der Anforderungsermittlung ist ein Katalog der funktionalen und nicht-funktionalen Anforderungen. Dieser Anforderungskatalog wird für die Beschreibung der konkreten Anforderungen an ein Softwaresystem (System Requirements) in eine technische Sprache übersetzt. Dieser Katalog der technischen Systemanforderungen ist die Basis für die spätere Softwareevaluation. In dem Anforderungskatalog des Portalprojektes sollten auch die Abhängigkeiten der Anforderungen untereinander aufgeführt sein. Zumindest die Beziehungen „setzt voraus“ und „widerspricht“ sollten abgebildet werden. So lässt sich vermeiden, dass beispielsweise im Rahmen einer Aufwandsreduzierung jene Funktionen in der Implementierung zurückgestellt werden, die zur Realisierung anderer Funktionen benötigt werden.

12.2.3 Analyse der Informations-, Prozess- und Systemlandschaft

Relevante Geschäftsprozesse

328

■ ■ ■

Sind die Anforderungen bekannt, so muss zunächst die bestehende organisatorische und technische Infrastruktur analysiert werden, bevor das Fachkonzept für das Unternehmensportal festgelegt werden kann. Im Rahmen einer Geschäftsprozessanalyse werden die für das Portal relevanten Geschäftsprozesse identifiziert und – soweit noch nicht geschehen – beschrieben. Insbesondere implizite Geschäftsprozesse, die nur in den Köpfen der Akteure existieren, sind gesondert zu analysieren, bergen sie doch oft ein erhebliches Optimie-

12 Vorgehensmodell

rungspotenzial. Viele dieser impliziten Prozesse sind historisch gewachsen und haben sich getreu dem Motto „Das haben wir schon immer so gemacht“ nicht wesentlich verändert, obwohl die Organisation, in die sie eingebettet sind, unter Umständen mehrere gravierende Veränderungen erfahren hat. Auch die Datenhaltung des Unternehmens muss analysiert werden, damit zumindest jene Geschäftsprozesse im Unternehmensportal zur Verfügung gestellt werden können, die für relevant erachtet werden und technisch unterstützt werden können. Um bewerten zu können, ob ein Geschäftsprozess für eine Portalunterstützung in Frage kommt, können folgende Kriterien herangezogen werden: Mengengerüste, Durchlaufzeiten, Ressourceneinsatz, Standardisierungsgrad, Ausführungshäufigkeit. Die Ergebnisse der Datenanalyse sollten in Form eines Datenkatalogs dokumentiert werden. Dieser kann in der Systementwicklung weiterverwendet werden. Außerdem lassen sich durch einen Abgleich des Datenkatalogs mit den Anforderungen und Geschäftsprozessen Informationslücken und Redundanzen aufdecken. Fehlen laut Datenkatalog Informationen, so muss untersucht werden, ob diese im Unternehmen überhaupt zur Verfügung stehen (eventuell in einem noch nicht berücksichtigten System). Redundante Informationen bergen die Gefahr der Dateninkonsistenz. Hier stellt sich die Frage, welche Datenquelle bzw. welches System das führende sein soll – eine vornehmlich organisatorische und weniger technische Frage. Ist diese Frage beantwortet, dann muss für die konsistente Aktualisierung der Daten Sorge getragen werden. Für die technisch unterstützten Geschäftsprozesse sowie die Datenquellen der relevanten Informationen müssen anschließend die technischen Systeme untersucht werden, aus denen die benötigten Daten stammen bzw. auf denen die entsprechende Software läuft. Ein besonderes Augenmerk liegt auf den technischen Schnittstellen, die diese Systeme anbieten. Nur über diese Schnittstellen ist es möglich, die Systeme ohne Anpassungen an das Unternehmensportal anbinden zu können. Schließlich muss der Benutzerkreis definiert werden, den das Unternehmensportal adressieren soll. Aus den Benutzern lassen sich dann die Benutzerrollen ableiten, die schließlich den relevanten Geschäftsprozessen zugeordnet werden. Es bietet sich an, die späteren Portalbenutzer insbesondere bei Analyse und Entwurf des Portals zu beteiligen, um sicherzustellen, dass deren Anforderungen und Wünsche frühzeitig bekannt sind und entsprechend berücksichtigt werden können – eine notwendige Voraussetzung, wenn auch kein Garant für die spätere Akzeptanz des Unternehmensportals.

12.2 Das Vorgehensmodell für Portalprojekte

Relevante Inhalte

Technische Schnittstellen

Analyse der Organisation

■ ■ ■

329

Wirtschaftliches Potenzial

Fachkonzept

Die bereits in der Zielfindungsphase begonnene Wirtschaftlichkeitsbetrachtung des Projektes wird in der Analysephase detailliert und fortgeführt. An dem hier ermittelten Nutzen müssen sich alle ermittelten fachlichen Anforderungen messen lassen. Nur die Anforderungen, die sich mit den strategischen Zielen des Projektes decken, werden weiter verfolgt. Die Ergebnisse der Wirtschaftlichkeitsbetrachtung müssen die Entscheidung für ein Unternehmensportal untermauern – ansonsten wird das Projekt an dieser Stelle abgebrochen. Ergebnis der Analyse ist das Fachkonzept. Es bildet die verbindliche fachliche Grundlage für die Portalentwicklung. Da die fachliche Analyse ein iterativer Prozess ist, ist auch das Fachkonzept fortlaufenden Änderungen unterworfen. Eine kontrollierte Verwaltung der Änderungen (Change Management) verhindert, dass die Portalentwicklung mit ständig wechselnden fachlichen Vorgaben konfrontiert wird.

12.2.4 Portalkonzeption

Grobkonzept

Sicherheits- und Berechtigungskonzept

330

■ ■ ■

Ausgehend von der fachlichen Strategie werden in der Portalkonzeption die fachlichen und technischen Grundlagen für den Entwurf und die Umsetzung des Unternehmensportals gelegt. Alle Aspekte der Portalkonzeption finden Sie ausführlich im Kapitel 9 beschrieben. Aus diesem Grund beschränken wir uns an dieser Stelle auf eine kurze Wiederholung der Aspekte. Die Phase der Portalkonzeption beginnt mit der Erstellung des Grobkonzeptes. In diesem werden die Anwendungsschwerpunkte des Portals definiert. Davon ausgehend kann die Organisation des Portals hinsichtlich der zu integrierenden Prozesse, Systeme und Organisationseinheiten festgelegt werden. Für diese Organisation werden bereits erste Rechte- und Rollenmodelle entworfen. Aus der Analyse der Informationslandschaft werden die Informationsstrukturen des Portals abgeleitet. Die Prozesse werden hinsichtlich ihrer Möglichkeiten einer technischen Unterstützung untersucht und als Workflows modelliert. Ausgehend von den beschriebenen fachlichen Anwendungsschwerpunkten kann eine erste technische Grobstruktur entwickelt werden, die allerdings noch von konkreten Technologien und Produkten abstrahiert. Aus den allgemeinen Anforderungen des Datenschutzes und der Informationssicherheit sowie den unterschiedlichen Informationsbedürfnissen und Restriktionen der Organisationseinheiten des Unternehmens leitet sich das Sicherheits- und Berechtigungskonzept ab.

12 Vorgehensmodell

Die erwarteten Zugriffsprofile der Portalbenutzer werden zu Benutzerrollen abstrahiert. Diese Rollen bilden die Basis für die Autorisierungs- und Personalisierungsregeln des Portals. Der integrative Charakter eines Unternehmensportals bedingt einen zentralen Zugriff auf die verschiedenen Informationssysteme des Unternehmens. Dabei ist zu berücksichtigen, dass diese Systeme unterschiedliche Authentifizierungsmechanismen verwenden. Im Sicherheits- und Berechtigungskonzept muss der Einsatz einer SingleSign-On-Funktionalität diskutiert und gegebenenfalls spezifiziert werden. Mit den Ergebnissen der Anforderungsanalyse und der technischen Grobstruktur sind die notwendigen Voraussetzungen geschaffen, um Technologien und Portalprodukte zielgerichtet zu evaluieren. Wie eine solche Softwareauswahl vonstatten geht, haben wir bereits im Kapitel 8 beschrieben. Ist die Entscheidung für bestimmte Technologien und Produkte gefallen, dann kann das Portalkonzept weiter detailliert werden. Im Feinkonzept wird die technische Architektur des Portals konkretisiert. Da nun alle relevanten Schnittstellen bekannt sind, kann die Integrationsschicht des Portals entworfen werden. Daran schließt sich die Konstruktion der Portalapplikationen an. Diese machen von Diensten und Informationen Gebrauch, die von der Integrationsschicht angeboten werden. Neben der inneren Struktur und Logik der Portalapplikationen wird in diesem Zuge auch die Benutzungsschnittstelle entworfen. Dabei werden unter anderem die grundlegenden Navigationsstrukturen, die Logik der Benutzungsschnittstelle sowie Layoutrichtlinien und Präsentationsraster festgelegt. Mit der Verfügbarkeit einer detaillierten fachlichen und technischen Portalarchitektur lässt sich die Nutzenbetrachtung des Portals weiter konkretisieren und gegebenenfalls um weitere Nutzenaspekte ergänzen. Um diesen Nutzen tatsächlich messen zu können, müssen aus der Portalkonzeption konkrete Kennzahlen abgeleitet werden. Dabei hilft die Tatsache, dass die Aufwände zu diesem Zeitpunkt besser abgeschätzt bzw. genau benannt werden können. Ergebnis der Portalkonzeption ist das Portalkonzept. Es bildet die verbindliche technische Grundlage für die Portalentwicklung. Gemeinsam mit dem Fachkonzept, beide kontrolliert durch einen Change-Management-Prozess, dient das Portalkonzept als Pflichtenheft, auf dem die Implementierung des Unternehmensportals basiert.

12.2 Das Vorgehensmodell für Portalprojekte

Technologieund Produktauswahl

Feinkonzeption

Wirtschaftlichkeitsbetrachtung

Portalkonzept

■ ■ ■

331

12.2.5 Implementierung Make or Buy

Qualitätssicherung

Einführungskonzeption

332

■ ■ ■

Der Prozess der Implementierung eines Unternehmensportals ist in seinen Inhalten stark abhängig von der fachlichen und technischen Portalkonzeption sowie der Entscheidung für Make or Buy. Wird das Unternehmensportal mehr oder weniger selbst entwickelt (Make), so wird die Implementierung ein zeitlich aufwendiger Prozess sein – im Falle des Buy hofft man hingegen auf einen deutlich geringeren Implementierungsaufwand, der sich im Wesentlichen auf die Komposition vorhandener (zugekaufter) Komponenten beschränken sollte. In der Praxis lassen sich diese beiden Prinzipien meist nicht sauber voneinander trennen. Einerseits stecken in jedem selbstentwickelten Portal in der Regel auch zugekaufte Komponenten. Andererseits muss auch ein Portalsystem „out of the box“ meist noch individuell erweitert werden. Diese Anpassung und Erweiterung kann – abhängig von der Anzahl der zu integrierenden Komponenten und Datenquellen – schnell umfangreich werden. Hinzu kommt, dass die verschiedenen marktreifen Komponententechnologien für verteilte Systeme (J2EE, CORBA, .NET) zwar miteinander kommunizieren können, dies aber zu Lasten der Performanz und der Einfachheit des Systementwurfs geht. Bei der Auswahl der Kaufkomponenten sollte also nicht nur die Funktionalität im Vordergrund stehen, sondern auch die Möglichkeit der Integration über Middleware- und Komponententechnologien berücksichtigt werden. Eine frühzeitig eingeführte und konsequent verfolgte Qualitätssicherung zahlt sich spätestens im Betrieb des Unternehmensportals aus. Zu den qualitätssichernden Maßnahmen in Softwareprojekten zählen unter anderem ■

Programmierrichtlinien,

■

Entwurfsmuster (Design Patterns),

■

Einheitliche Entwicklungswerkzeuge,

■

Programmieren im Team (Peer Programming),

■

Konzept- und Code-Reviews.

Die Einführung des Portalsystems ist frühzeitig zu planen. In die Konzeption fließen neben der gewählten Einführungsstrategie (Stepby-step oder Gesamteinführung, vgl. Abschnitt 9.2.2) auch die technischen und die organisatorischen Aspekte der Portaleinführung ein. So muss z.B. die Verfügbarkeit der technischen Systeme gegeben sein, alle Benutzer müssen im System eingerichtet und mit entspre-

12 Vorgehensmodell

chenden Authentifizierungsdaten versorgt werden. Für den Zeitraum der Portaleinführung sollten die Entscheidungsträger des Projektes (Projektleitung, Auftraggeber, ausgewählte Benutzer) zur Verfügung stehen, um Fragen zu beantworten und im Problemfall schnell Entscheidungen treffen zu können. Um eine möglichst reibungslose Einführung auch von Seiten der Benutzer zu gewährleisten, müssen Einführungskonzeption und Schulungskonzeption aufeinander abgestimmt werden. Im Rahmen der Schulungskonzeption wird ein Maßnahmenkatalog entwickelt, anhand dessen die Benutzer auf den produktiven Einsatz des Portals vorbereitet werden. Dabei ist zu berücksichtigen, dass die Benutzer im Regelfall sehr unterschiedliche Vorkenntnisse mitbringen. Je unterschiedlicher deren Tätigkeitsbereiche sind, desto vielfältiger sind auch die Erwartungen der Benutzer an das Unternehmensportal. Die Wahl der Trainingsmethoden (z.B. Präsenzschulungen, computer- oder webbasierte Trainings) hängt ab von der Anzahl der Portalbenutzer und deren zeitlicher und räumlicher Verfügbarkeit.

Schulungskonzeption

12.2.6 Test Nach den in der Implementierungsphase durchgeführten Entwicklertests muss ein fachlicher und technischer Systemtest die Funktionalität des produktionsreifen Unternehmensportals sicherstellen. Das projektbegleitende Prototyping hat, wenn es konsequent durchgeführt wurde, die Übereinstimmung der implementierten Funktionalität mit den Anforderungen der Benutzer und die Bedienbarkeit des Systems sichergestellt. Beim fachlichen Test kommt es deshalb vor allem auf die Zusammenarbeit der verschiedenen Portalkomponenten an. Weitere Testszenarios betreffen die Personalisierung, das Single Sign-On, die kontextabhängige Gestaltung der Präsentationskomponenten sowie das Verhalten bei Rollen- und Kontextwechseln. Die technischen Tests sollen hauptsächlich das reibungslose Zusammenarbeiten der unterschiedlichen Portalkomponenten sicherstellen. Hinzu kommen Lasttests, die Überprüfung des Verhaltens in Ausnahmefällen (Exception Handling), Sicherheitstests sowie das Verhalten beim Ausfall einer oder mehrerer Komponenten. Kapitel 9 und 10 geben einen ausführlichen Überblick über die verschiedenen fachlichen und technischen Testverfahren.

12.2 Das Vorgehensmodell für Portalprojekte

■ ■ ■

333

12.2.7 Einführung

Schulung

Deployment

Wirtschaftlichkeitsanalyse

334

■ ■ ■

Die Einführung des Unternehmensportals ist konzeptionell vorbereitet und kann nun durchgeführt werden. Diese Phase umfasst aber mehr als die eigentliche Installation des Portalsystems auf einem Produktionsserver. Ein Unternehmensportal wird nur dann eine breite Akzeptanz finden, wenn es den Erwartungen der Benutzer entspricht und ein einfaches und durchgängiges Bedienkonzept besitzt. Deshalb sollten die Portalbenutzer den richtigen Umgang mit dem Unternehmensportal im Rahmen eines Trainings vermittelt bekommen. Dabei wird ein einheitliches Verständnis für die angebotenen Informationen und Dienste in unterschiedlichen Kontexten geschaffen und die Geschäftsprozesse sowie deren Zusammenhänge beschrieben. In einem Training kann außerdem ein erstes Feedback eingeholt werden, das als Ausgangspunkt für die Weiterentwicklung des Portals dienen kann. Wie bereits erwähnt, müssen die unterschiedlichen Vorkenntnisse und Erwartungen der Benutzer berücksichtigt werden. Das Deployment bezeichnet die Überführung des Portals in den produktiven Betrieb und ist damit Teil des Betriebskonzeptes. Insbesondere bei nachträglichen Änderungen und Fehlerkorrekturen muss das Deployment-Konzept für ein kontrolliertes Change Management und einen reibungslosen Betrieb des Produktionssystems sorgen. So muss z.B. im Falle eines fehlgeschlagenen Portal-Updates die letzte funktionierende Version schnell wiederhergestellt werden können. Um den Erfolg des Portalprojektes ermitteln zu können, wird nach der Einführung des Systems eine detaillierte Wirtschaftlichkeitsanalyse durchgeführt. Die während der Projektlaufzeit erhobenen Ist-Daten (d.h. der Ressourcenverbrauch) werden um die Laufzeitdaten aus dem Betrieb des Portals ergänzt. Das Ergebnis sind gesicherte Kennzahlen, aus denen dann der tatsächlich erreichte betriebswirtschaftliche Nutzen errechnet werden kann. Diese Wirtschaftlichkeitsanalyse wird während des Portalbetriebs kontinuierlich wiederholt, um Veränderungen und Abweichungen rechtzeitig erkennen zu können. Sie liefert wertvolle Hinweise für die Entwicklung weiterer Versionen des Unternehmensportals.

12 Vorgehensmodell

13 Ausblick

Sie haben jetzt einen umfassenden Überblick über die Konzepte und Technologien aktueller Portalsysteme. Sie wissen, welche Informationen, Anwendungen und Prozesse von einem Portal abgedeckt werden können, und welche Prozesse bei der Entwicklung und dem Betrieb eines Portals eine Rolle spielen. Wie aber geht es weiter? Welche Portaltrends kann man bei Unternehmen ausmachen? In welche Richtung entwickelt sich der Portalmarkt? Was sind die Anwendungsgebiete der Portale von morgen? Welche Technologien werden in Zukunft mehr Gewicht bekommen? In diesem Kapitel wagen wir Antworten auf diese Fragen. Dabei handelt es sich allerdings lediglich um Prognosen, die wir auf der Grundlage unserer Erfahrung und Markteinschätzung sowie ausgewählten ITMarktanalysen getroffen haben. Wie sich der Portalmarkt in den kommenden Jahren tatsächlich entwickeln wird, können auch wir nicht vorhersagen. Wir rechnen aber damit, dass unsere Prognosen zumindest in Teilen zutreffen werden. Dieser Ausblick kann als Anregung dienen, um für das eigene Portalsystem bzw. -projekt eine Vision zu entwickeln.

Kurz gefasst

13.1 Anforderungen der Unternehmen an die Portale von morgen Für ein Unternehmen, das ein Portal einsetzt, muss sich dessen Einsatz lohnen. Betriebswirtschaftlich ausgedrückt, muss der Portaleinsatz Kosten reduzieren helfen, um die getätigte Investition innerhalb eines festgelegten Zeitraums zu kompensieren. Portale stellen einen Ausweg aus einem klassischen Dilemma der Kosteneinsparung dar: Für die üblichen Maßnahmen zur Kostenreduzierung (Personalabbau und Beschränkung der angebotenen Dienstleistungen) muss letztendlich der Kunde bezahlen. Er muss Abstriche vom gewohnten Service hinnehmen. Die Folge ist eine sinkende Kundenzufrieden-

13.1 Anforderungen der Unternehmen an die Portale von morgen

Hoher Nutzen, geringe Kosten

■ ■ ■

335

Automatisierung der Kundenservices

Automatisierung des Bestellprozesses

336

■ ■ ■

heit. Aber gerade in wirtschaftlich schweren Zeiten, die solche Einsparungen erfordern, spielt die Kundenbindung eine wesentliche Rolle. Ein gut geplantes und gepflegtes Portal kann einen gewissen Anteil der Kundenservices übernehmen und automatisieren. Durch den Aufbau eines Wissensspeichers, der ständig aktuell gehalten wird, werden die Experten entlastet. Mussten sie bisher für spezielle Fragen und Wünsche der Kunden von den Service-Mitarbeitern persönlich konsultiert werden, so reicht in Zukunft eine Recherche im Wissensspeicher des Portals. Auch die Kundendienstabteilung kann entlastet werden, wenn etwa Teile des Wissensspeichers über das Internet allen Kunden zur Verfügung gestellt werden. Hier finden Interessierte Antworten auf die am häufigsten gestellten Fragen (Frequently Asked Questions, FAQ). Der Kundendienst kann sich nun mehr auf die Kundenpflege konzentrieren, anstatt die meiste Zeit mit der Beantwortung immer derselben Fragen zu verbringen. Die Arbeit der Service-Mitarbeiter wird aufgewertet – auf der anderen Seite wird nicht mehr so viel Personal benötigt. Konzepte für die Automatisierung des Kundendienstes finden sich auch in den heute verfügbaren Portalsystemen. Ihre Bedeutung wird in Zukunft aber noch zunehmen. Wenn die Kunden das Portal als neuen, schnellen Informationskanal entdeckt haben, dann werden sie auch bereit sein, Bestellungen über das Internet aufzugeben. Durch die Verlagerung der automatischen Erfassung einer Bestellung vom Unternehmen auf den Kunden lassen sich Kosten in signifikanter Höhe einsparen. Um die Kunden zur Nutzung dieses neuen Bestellwegs zu bewegen, kann ein Teil dieser Kosteneinsparung als finanzieller Anreiz an den Kunden weitergegeben werden. Da die erste Bestellbestätigung automatisch und sofort erfolgt, erfährt der Kunde eine direkte Reaktion auf seine Bestellung – und fühlt sich gut betreut. Damit dies auch so bleibt, muss natürlich der Prozess der Warenlieferung und Rechnungsstellung ebenso schnell und reibungslos vonstatten gehen. Das Portal stellt auch für diesen Prozess den Dreh- und Angelpunkt dar. Diese Funktionen werden schon heute von den diversen Shoppingportalen im Internet angeboten. Die meisten Bestellungen zwischen Unternehmen (Business-to-Business, B2B) werden hingegen noch auf traditionellem Wege abgewickelt. Viele Unternehmen scheuen den Planungs- und Investitionsaufwand, der mit der Modellierung, Implementierung und Etablierung der B2BGeschäftsprozesse verbunden ist. Deshalb findet man automatisierte Bestellprozesse heute fast ausschließlich in großen Unternehmen. In der Zukunft wird sich aber dank weitreichend akzeptierter Standards und entsprechender Softwarelösungen auch für ein mittelständisches

13 Ausblick

Unternehmen die Installation oder Erweiterung eines Portals mit Verkaufsfunktionalität lohnen. Die damit verbundene Neuorientierung der Bestell- und Lieferprozesse wird diese Kernaktivitäten des Unternehmens weiter beschleunigen. Geeignete Kandidaten für automatisierte Bestellung sind Produkte, die möglichst weit standardisiert sind. Für Dienstleistungen wird in der Regel der persönliche Kontakt wichtig bleiben, da sich diese nur selten formalisieren und standardisieren lassen. Das Portal, als zentrale Informationsquelle und Schaltzentrale der Unternehmensprozesse und der angeschlossenen technischen Systeme, wird schließlich auch den Informationshaushalt des Unternehmens positiv verändern. Sobald ein Unternehmen den Schritt zum Prozessportal wagt, muss es sich zwangsläufig mit der Struktur und Qualität der in den Anwendungssystemen gespeicherten Daten befassen. Mängel und Redundanzen werden aufgedeckt und beseitigt. Die ewige Frage nach den führenden Systemen für bestimmte Daten eröffnet die Diskussion um einen zentralen Datenbestand mit fachspezifischen Metadaten. Ein solcher zentraler Datenspeicher wird mit einer ausgewählten Datenmenge beginnen und kontinuierlich erweitert werden. Das wiederum hat positive Auswirkungen auf die Integrationsschicht des Portals, die zunehmend einfacher wird und gleichzeitig mehr Querbeziehungen zwischen den Daten abbilden kann. Das auf diese Weise verbesserte Informationsangebot kommt den Benutzern des Portals zugute. Ein zentraler Metadatenserver dient zudem der Schaffung bzw. Neuordnung der unternehmensweiten Datenmodelle. Diese Modelle werden im Metadatenserver hinterlegt. Ihre Definition basiert auf den gespeicherten Metadaten. Unter Einsatz von BusinessIntelligence-Lösungen können die Metainformationen ausgewertet werden, z.B. hinsichtlich redundanter oder inkonsistenter Datenmodelle. Die Optimierung dieser Modelle wird sich wiederum positiv auf die Fachanwendungen und Geschäftsprozesse auswirken.

Konsolidierung des Informationshaushalts

13.2 Die Entwicklung des Portalmarkts Analysiert man die in Abb. 8.5 (Abschnitt 8.4) dargestellte Dynamik des Portalmarkts in den Jahren 2002-2004, so stellt man fest, dass sich im Wesentlichen die Portalsysteme der großen Hersteller behauptet haben. Fast alle „Leader“ konnten ihre Führungsposition weiter ausbauen. Dies nicht selten durch Firmenzukäufe, die den Portalsystemen wichtige Zusatzfunktionen bescherten. Solche gezielten Akquisitionen verlangen von einem Portalanbieter nicht nur

13.2 Die Entwicklung des Portalmarkts

Welche Anbieter setzen sich durch?

■ ■ ■

337

Was setzt sich durch?

Generalisierung der „Großen“

Spezialisierung der „Kleinen“

Standardisierung

338

■ ■ ■

einen strategischen Weitblick und ein konsequentes Produktmanagement. Er braucht auch eine gute finanzielle Ausstattung, und hier haben die Branchengrößen oft den entscheidenden Vorteil. So können sie ihre Produkte schneller an die sich ändernden Erfordernisse des Marktes anpassen. Was aber sind diese Erfordernisse – und was werden sie in Zukunft sein? Derzeit fordern die meisten Kunden von einem Portal ein Funktionsspektrum, das die im Kapitel 1 vorgestellten Anwendungsschwerpunkte umfasst: ■

Informationen publizieren,

■

Informationen aufbereiten und Wissen extrahieren,

■

Anwendungen bereitstellen,

■

Miteinanderarbeit ermöglichen.

Die Marktführer bieten für ihre Portalsysteme Komponenten an, die alle genannten Anforderungen erfüllen. Damit sind sie in der Lage, die Wünsche der meisten Kunden zu erfüllen. Für spezielle Anforderungen gibt es Nischenanbieter, deren Portalsysteme auf bestimmte Branchen oder Anwendungsbereiche zugeschnitten sind. Es sind also zwei Trends auszumachen: Die „Großen“ der Branche versuchen, über einen hohen funktionalen Abdeckungsgrad den Großteil der Portalkunden zu gewinnen. Das bedeutet aber auch, dass auf veränderte Anforderungen frühzeitig reagiert werden muss, um die entsprechenden Komponenten rechtzeitig anbieten zu können. Den kleinen Anbietern bleibt nur noch der Rückzug in die Nischen, und dort haben sie durchaus eine Daseinsberechtigung. Schließlich können sie mit ihren Portalsystemen sehr spezielle Anforderungen bestimmter Kundenkreise abdecken. So gibt es z.B. branchenspezifische Portale und Systeme, die für die Anforderungen kleiner und mittelständischer Unternehmen zugeschnitten sind. Für diese Unternehmen ist die Einführung und der Betrieb eines „großen“ Portalsystems finanziell und personell nicht realisierbar, zumal eine Vielzahl der von solchen Systemen angebotenen Funktionen überhaupt nicht genutzt wird. Ein Trend, dem alle Portalsystemhersteller folgen, ist die Unterstützung von Standards. Die allmähliche Adaption der Portlet-API zeigt, dass die Hersteller den Wunsch der Kunden nach herstellerübergreifender Austauschbarkeit von Systemkomponenten ernst nehmen. Zudem arbeiten viele Hersteller aktiv an der Entwicklung dieser Standards mit.

13 Ausblick

Bleibt nur noch die Frage zu beantworten, wie sich die Anforderungen der Benutzer verändern werden. Larry Bowden, Vice President, IBM Portal and Lotus Products, unterteilt die bisherige Entwicklung in drei Phasen (vgl. Portals Magazine 2004): ■

Phase 1: Grundsätzliches Interesse an Portalen, „Make or Buy“Diskussion, ROI-Betrachtungen,

■

Phase 2: Schnelle Integration bestehender Anwendungen, Standardisierung (Portlet-API),

■

Phase 3: Mehr Produktivität durch Reduzierung der Prozessdurchlaufzeiten, Steigerung der Mitarbeiterproduktivität, kontextbezogene Entscheidungsunterstützung, Verbesserung der Benutzerzufriedenheit, bessere Verfügbarkeit.

Die dritte Phase wird laut Bowden noch ca. zwei Jahre andauern. Da der Einsatz von Portalen die Betriebskosten für Unternehmen beträchtlich senken wird, steigt deren Bedeutung weiter an.

13.3 Technische Entwicklungen Obwohl Portalprojekte mehr fachliche als technische Fragestellungen aufwerfen, ist die Technik sehr dominant und trotz aller Fortschritte immer noch nicht ausgereift. In einer Expertenstudie von Binder & Company wurden Ende 2004 die CIOs und Portalmanager von 32 Unternehmen mit überwiegend mehr als 15.000 Mitarbeitern zu ihren Erfahrungen befragt. Eine wesentliche Hürde bei der Portaleinführung stellte nach Aussage der Portalexperten die Technologie dar (vgl. Binder & Company 2004). Ein guter Grund, um das Optimierungspotenzial der Portaltechnologien näher zu untersuchen.

13.3.1 Komponentensysteme Im Abschnitt 5.9 haben wir die Architektur der entkoppelten Komponenten vorgestellt. Aus lose gekoppelten Komponenten, die nur über Funktionsschnittstellen kommunizieren, entsteht ein flexibles Gesamtsystem. Die Stabilität dieser Schnittstellen vorausgesetzt, sind die Komponenten immun gegen Änderungen der inneren Struktur der von ihnen referenzierten Komponenten. Mit dieser Unabhängigkeit ist die wesentliche Voraussetzung für eine Austauschbarkeit

13.3 Technische Entwicklungen

■ ■ ■

339

aller Komponenten gegeben. Die anderen Voraussetzungen sollen hier nur kurz wiederholt werden:

Standards unterstützen die Entkopplung

340

■ ■ ■

■

Einheitliche Schnittstellen: Sie bestimmen die „äußere Form“ der Komponenten und sorgen für Passgenauigkeit.

■

Definierte Minimalfunktionalität: Diese garantiert einen fachlichen Funktionsumfang, der über die Schnittstellen den angeschlossenen Komponenten zur Verfügung steht.

■

Standardverhalten: Dieses bietet verlässliches Verhalten im Rahmen von technisch unterstützten Geschäftsprozessen.

Sind alle genannten Voraussetzungen gegeben, dann hat man als Betreiber eines Portalsystems tatsächlich die Wahl: Komponenten verschiedener Hersteller lassen sich zu einem Portalsystem zusammenstellen, das fachliche Anforderungen erfüllt, anstatt von technischen Zwängen diktiert zu werden. Die anforderungsgerechte Konstruktion der Systemarchitektur kann auch mit Änderungen bei den Anforderungen umgehen, denn nachträgliche Änderungen (oder Erweiterungen) sind jederzeit möglich. Leider ist der oben beschriebene Grad der Entkopplung noch nicht erreicht; die Entwicklung hat jedoch bereits begonnen. So begreift der Portlet-Standard die Portalanwendungen als unabhängige Komponenten, die über standardisierte Schnittstellen verfügen. Die definierte Minimalfunktionalität ist jedoch nur technischer Natur – so sind z.B. verschiedene Portlet-Modi (View, Edit, Help) und Fensterzustände (normal, maximized, minimized) vordefiniert. Auch das Standardverhalten bezieht sich nur auf die technische Kommunikation mit dem Portlet Container. Immerhin lassen sich Portlets verschiedener Hersteller in Portlet-kompatiblen Portalen einsetzen. Der verwandte WSRP-Standard (Web Services for Remote Portlets) ermöglicht in Zukunft sogar das Abonnieren von Portlets als Dienste. An anderer Stelle ist noch einiges an Standardisierungsarbeit zu leisten, etwa bei der Formalisierung der Verhaltensbeschreibungen und dem Ausnahmeverhalten von entkoppelten Komponenten. Auch verteilte Transaktionen sind derzeit noch nicht hinreichend standardisiert. Offene Schnittstellen können noch mehr: Sie erlauben die Integration von Komponenten zur Abdeckung neuer Funktionsbereiche, die von heutigen Portalsystemen nicht unterstützt werden. Damit sind Portale auch für zukünftige Anforderungen gut gerüstet.

13 Ausblick

13.3.2 Web Services Das Verständnis von Funktionen als (Software-)Dienste trägt dazu bei, die Funktionen als Module zu sehen, mit denen über definierte Schnittstellen kommuniziert wird. Das fördert die oben beschriebene Architektur autarker, austauschbarer Komponenten. Die ortsunabhängige Verfügbarkeit über das Internet bzw. das Intranet und das Auffinden von Diensten über standardisierte Verzeichnisdienste sind weitere Vorteile. Der Web Service-Standard bildet dabei lediglich die Basis. In Zukunft werden spezialisierte Dienste die zielgerichtete Verwendung vereinfachen. Die ersten spezialisierten Web Services gibt es bereits heute, z.B. WSRP (Web Services for Remote Portlets) oder BPEL (Business Process Execution Language). Der Wandel von der Funktionskomponente zum Dienst wird die Architektur technischer Systeme in Zukunft maßgeblich beeinflussen. Diese Idee wird mit dem Begriff „Service-Oriented Architecture“ umschrieben und derzeit intensiv diskutiert.

Basisstandard Web Services

13.3.3 Service-Oriented Architectures SOA – diese drei Buchstaben stehen für einen Trend, der laut Gartner Group das Ende der Client/Server-Architektur einläutet. Serviceorientierte Architekturen (SOA), verknüpft mit Business Process Management (BPM), werden den Analysten zufolge die Unternehmenssoftware der nächsten Generation dominieren. Fachlich betrachtet, verfolgen diese Architekturen dasselbe Ziel wie prozessorientierte Unternehmensportale: Sie sollen die Anwendungen, Informationen und Dienste mehrerer Unternehmensbereiche (z.B. Abteilungen) in einen durchgängigen Workflow integrieren. Der Wirkungsbereich eines solchen Workflows kann auch Kunden, Lieferanten oder Partner des Unternehmens mit einschließen. Aus technischer Sicht lassen sich in serviceorientierten Architekturen die verschiedenen Komponenten flexibel miteinander kombinieren und gegeneinander austauschen. Das entspricht den Ideen der entkoppelten Komponenten, übertragen auf das Dienstkonzept der Web Services. Das Ergebnis ist eine technische Integration von Systemen und Prozessen.

13.3 Technische Entwicklungen

Workflowintegration

Technische Integration

■ ■ ■

341

Real-Time Enterprise (RTE)

Fachlich wie technisch sind damit laut Gartner die Voraussetzungen für ein zukunftsweisendes Unternehmenskonzept geschaffen: Das Real-Time Enterprise (RTE) wird auf der Basis stets aktueller Informationen geführt. Sollten Änderungen der Prozesse oder Unternehmensstrukturen notwendig werden, so erlaubt die technische Architektur eine schnelle Anpassung der Systemintegration und der Workflows. Das Ziel ist die Verkürzung der Prozesslaufzeiten sowie die Verbesserung der Reaktionszeit, um die Bedürfnisse der Kunden schneller und besser bedienen zu können. Zur technischen Infrastruktur eines Real-Time Enterprise zählt Gartner auch die Unternehmensportale. Soweit der Blick in eine mögliche Zukunft der Ad-hocUnternehmensführung. Ob sie Realität wird, hängt davon ab, ob die heute von vielen Unternehmen zur Schau gestellte Entschlossenheit bei der Verfolgung der SOA-Ziele auch morgen noch Bestand hat. Es fehlt an eindeutigen Definitionen – aber vielleicht sind diese gar nicht so wichtig. Schließlich kommt es vor allem darauf an, die grundlegenden Ideen zu verinnerlichen und das eigene Unternehmen aus einem anderen Blickwinkel zu betrachten. Wenn sich aus dieser Betrachtungsweise neue, schnellere und besser integrierte Geschäftsprozesse ableiten lassen, ist der wichtigste Schritt bereits getan. Da aller Anfang bekanntlich schwer ist, bieten die SOA Blueprints (www.soablueprints.com) Best Practices für serviceorientierte Systeme.

13.3.4 Semantic Web

Annotation – automatisch und manuell

342

■ ■ ■

Tim Berners-Lee propagiert mit seinem Semantic Web-Konzept eine Idee, mit der das Internet der Zukunft von Softwareagenten und „intelligenten“ Suchmaschinen im Auftrag von Menschen durchstreift wird. Voraussetzung für die automatische Informationsrecherche ist, dass die Bedeutung von Webinhalten und deren Beziehungen untereinander so beschrieben werden, dass eine maschinelle Verarbeitung möglich ist. Zunächst ist aber eine wahrhafte Pionierarbeit zu leisten. Die weitreichende Verfügbarkeit semantischer Annotationen für die unstrukturierten Informationen des World Wide Web lässt sich nur beschränkt automatisiert sicherstellen. Die manuelle Annotation ist jedoch keine reine Fleißarbeit: „Gute“ Annotationen verlangen Erfahrung, Zeit und viele Abstimmungen. Hinzu kommt, dass Annotationen immer kontextabhängig für eine bestimmte Domäne gelten. Dementsprechend ist die Definition universell gültiger und akzep-

13 Ausblick

tierter Taxonomien eine der großen Herausforderungen auf dem Weg zum Semantic Web. Die aufwendige Alternative, Übersetzer zwischen verschiedenen Taxonomien einer Domäne zu entwickeln, wird recht schnell zu einem unüberschaubaren Regelwerk und umfangreichen Mappingbeschreibungen führen. Der Weg zum Semantic Web ist also lang und steinig. Getreu dem mehrfach beschworenen Motto „Think big – start small“ ist auch hier die primäre Konzentration auf Teilbereiche und eine begrenzte Anzahl von Domänen der Schlüssel zum initialen Erfolg, auf den man später aufbauen kann.

13.3.5 Intelligente Recherche Wie bereits im Abschnitt 6.2.6 erläutert, dient die Informationsextraktion dazu, bestimmte gewünschte Informationen in unstrukturierten Texten zu identifizieren und in eine strukturierte Form zu überführen. Diese Anreicherung um strukturierte (Meta-)Informationen erlaubt formale Anfragen und eine weitere maschinelle Verarbeitung des Textdatenbestandes. Analysiert man die Entwicklungen im Bereich der Informationsextraktion, so muss man ernüchtert feststellen, dass die Fortschritte geringer sind als erwartet. Die verwendeten Konzepte und Techniken haben sich wenig verändert. Dennoch konnte dieser Forschungsbereich von anderen Entwicklungen in der Informationstechnologie profitieren. Ein handelsüblicher Personal Computer ist heute leistungsfähig genug, um unstrukturierte Texte in akzeptabler Zeit zu analysieren und annotieren. Frei verfügbare Werkzeuge wie GATE (vgl. Abschnitt 5.2.2) tragen dazu bei, dass die Textextraktion einem breiteren Anwendungsspektrum zugeführt wird. Der Quantensprung für die unkomplizierte Nutzung von Textanalysewerkzeugen gelang jedoch erst, als standardisierte und flexibel erweiterbare Datenformate auf der Basis von XML die hierarchischen oder relationalen Datenbankstrukturen ablösten bzw. erweiterten. Schon heute gibt es viele, zum Teil sehr spezielle Anwendungsfelder für die Analyse großer Bestände unstrukturierter Informationen. Zu den Beispielen für solche Anwendungsfelder gehören die Patentrecherche und die automatische Analyse wissenschaftlicher Fachliteratur. Solche domänenspezifischen Analysen sind vergleichsweise einfach zu realisieren, wenn das verwendete Vokabular beschränkt ist und die zu analysierenden Dokumente eine möglichst einheitliche Struktur besitzen. Schwieriger wird es im unbeschränk-

13.3 Technische Entwicklungen

Fortschritt dank XML

Vom Spezialthema zur Standardfunktion

■ ■ ■

343

ten natürlichsprachlichen Bereich, z.B. bei der Analyse von Pressemeldungen oder Weblogs. Solchen frei formulierten und formatierten Texten lässt sich der Sinn nur mit Hilfe von kontextueller Analyse und probabilistischen Methoden entlocken. Die zunehmende Strukturierung dieser Informationen (auf dem Weg zum Semantic Web, siehe oben) erleichtert der Textanalyse ihre Arbeit und verbessert die Qualität der Ergebnisse. Je mehr sich die Standardisierung und die Textanalyse aufeinander zu bewegen, desto besser werden die automatisch annotierten Metainformationen. Gelingt es schließlich, semantisch formulierte natürlichsprachliche Suchanfragen verarbeiten zu können, dann gehören die endlosen Ergebnislisten heutiger Suchmaschinen vielleicht schon bald der Vergangenheit an.

13.3.6 Mobilität und Multimodalität Das Geschäftsleben findet immer seltener am Büroschreibtisch statt. Mit Smartphones und PDAs ausgestattete Manager und Außendienstmitarbeiter, Telearbeitsplätze (Home Offices), Wireless LANZugänge in Cafés und Business Lounges – der Wahl des Arbeitsplatzes sind praktisch keine Grenzen mehr gesetzt. Dieser zunehmenden Mobilität müssen auch die technischen Systeme Rechnung tragen, und damit auch die Unternehmensportale. Ergänzend zum Browser müssen auch mobile Endgeräte als Ausgabemedium unterstützt werden. Verbunden mit dieser Multimodalität sind neue Anforderungen an ein Portalsystem. So wird ein Mitarbeiter unterwegs in der Regel weniger Zeit für eine Informationsrecherche aufbringen können als im Büro. Zudem sind seine Eingabemöglichkeiten beschränkt, da viele mobile Endgeräte keine bzw. nur eine kleine Tastatur besitzen. Auch deren Bildschirme sind in der Regel deutlich kleiner als der PC-Monitor im Büro. Trotzdem erwartet der Benutzer eine übersichtliche und zielgerichtete Präsentation der Ergebnisse. Schließlich müssen die geringen Datenübertragungsraten in Betracht gezogen werden, die nach einer Optimierung des Datenverkehrs verlangen, um die Antwortzeiten so gering wie möglich zu halten. Viele der genannten Herausforderungen mögen der Grund dafür sein, dass multimodale Portale heute bereits zwar möglich sind, aber noch keinen Massenmarkt gefunden haben. Man findet mobile Zugriffsszenarien für Portale derzeit nur in speziellen Anwendungsfällen, und sie umgibt immer noch die Aura des Besonderen. Damit sie in zukünftigen Portalen zur Selbstverständlichkeit werden, muss nicht nur die Technik einfacher programmierbar und bedienbar wer-

344

■ ■ ■

13 Ausblick

den. Auch die organisatorischen Voraussetzungen müssen geschaffen werden. So muss bei der Formulierung der fachlichen Anforderungen an ein Portalsystem auch ein mobiles Szenario berücksichtigt werden. Dessen spezielle Anforderungen (hochgradig fokussierte Informationen, schneller Zugriff auf Schlüsselfunktionen und Kennzahlen) unterscheiden sich unter Umständen von den „stationären“ Portalanforderungen, wie z.B. große Navigationstiefe (Drill-downFunktionalität), Durchgriff auf den vollen Datenumfang der Backend-Systeme, und umfangreiche (grafische) Reports. Die Mobilität der Benutzer verlangt nach einer robusten und vor allem sicheren IT-Infrastruktur. Alle Systeme müssen gegen unerlaubte Zugriffe von außen geschützt werden, ohne den multimodalen Zugriff negativ zu beeinflussen. Fehler müssen erkannt und durch schnelle Gegenmaßnahmen ausgemerzt werden, bevor sie die Funktionsfähigkeit des Systems beeinträchtigen. Zugegeben: Diese Anforderungen sind nicht spezifisch für multimodale Portalsysteme – allerdings treten sie im Kontext dieses hochgradig integrativen Systemverbunds am deutlichsten zutage. Ein Begriff, der in letzter Zeit häufig mit Portalen in Verbindung gebracht wird, ist der „Webtop“ – der webbasierte elektronische Schreibtisch. Gene Phifer, Analyst bei Gartner, verknüpft einen möglichen Siegeszug des Webtop mit der Ablösung der traditionellen Schreibtisch-Metapher, die von der grafischen Oberfläche des Betriebssystems verwendet wird. Seiner Meinung nach hat Microsoft viel zu verlieren, weil das Unternehmen seine Rolle als „Eigentümer der Augen des Unternehmens“ einbüßen könnte (vgl. Knorr 2004). Diese Augen könnten sich in Zukunft auf das Portal richten, das unabhängig vom Betriebssystem auf verschiedenen Endgeräten seine Dienste anbietet. Einen Vorteil, den erfolgreiche Betriebssysteme derzeit noch für sich verbuchen können, ist die Verfügbarkeit einer ausreichenden Anzahl von Interaktionselementen. Diese lassen sich in den Fachanwendungen wiederverwenden und sorgen – zumindest bezogen auf ein bestimmtes Betriebssystem – für ein einheitliches Aussehen und eine konsistente Bedienung (Look & Feel). Bei Bedarf können zusätzliche Interaktionselemente entwickelt werden, wodurch die Fachanwendung jedoch die standardisierten Pfade verlässt und dem Benutzer einen zusätzlichen Einarbeitungsaufwand aufbürdet. Webbasierte Anwendungen, wie sie üblicherweise in Portalen zu finden sind, bieten nur eine beschränkte Anzahl von Interaktionselementen. Je komplexer die Benutzungsoberfläche einer Fachanwendung ist, desto schneller erreicht der Webdesigner die Grenze des Machbaren. Die Folge: Es werden zusätzliche Techniken verwendet, die nicht selten auf einen bestimmten Browsertyp zuge-

13.3 Technische Entwicklungen

Sicherheit

Webtop kontra Desktop

Fenstersystem kontra Weboberfläche

■ ■ ■

345

Die Lösung: Rich Thin Clients

schnitten sind und somit die Erreichbarkeit des Portalsystems einschränken. Allerdings bietet diese Architektur den Vorteil, dass die Fachanwendung zentral auf dem Server läuft. Die Lösung der Zukunft könnte in einer Mischform bestehen, die derzeit in der Literatur als Rich Thin Client bezeichnet wird. In dieser Architekturvariante läuft die Fachanwendung auf dem Server. Die Aufgaben der Präsentation und Interaktion werden von einem Thin Client übernommen, der auf dem Client abläuft. Für jedes Interaktionsobjekt des Clients existiert ein Pendant auf der Serverseite, das über alle Änderungen informiert wird und diese an die (ebenfalls auf dem Server befindliche) Applikationsschicht weiterreicht. Dort werden die Benutzeraktionen ausgewertet und entsprechende fachliche Aktivitäten ausgeführt (vgl. König 2004). Mit der Programmiersprache Java steht eine Technologie zur Verfügung, die mittlerweile auf ausreichend vielen Systemplattformen verfügbar ist und sich somit als Werkzeug für die Implementierung der Thin Clients anbietet. Diese Kombination der besten Konzepte beider Welten (Client und Server) erlaubt die Entwicklung wartungsfreundlicher, serverbasierter (Portal-)Anwendungen mit komfortablen Benutzungsoberflächen.

13.3.7 Agilität Ein agiles Unternehmen zeichnet sich durch das Vorhandensein organisatorischer Rahmenbedingungen für schnelle, flexibel anpassbare Prozesse sowie eine robuste, sichere und komponentenbasierte ITInfrastruktur aus. Unter diesen Voraussetzungen kann das agile Unternehmen schnell auf Veränderungen reagieren und bleibt somit immer konkurrenzfähig. Diese Flexibilität lässt sich aber nicht kaufen im Sinne von Beratungsleistung oder technischen Systemen. Allenfalls ein Coaching bei der Schulung der Mitarbeiter in agilen Denkweisen sowie eine Unterstützung bei der Auswahl „passender“ Softwaresysteme ist denkbar und sinnvoll. Letztendlich entscheidet auch hier die überzeugende Darstellung der Vorzüge dieser neuen Denkweise über die Akzeptanz bei den Mitarbeitern und damit letztendlich über den Erfolg dieser Maßnahme. Ein in agilem Vorgehen geschulter Mitarbeiter wird seinerseits einen veränderten Anspruch an die technischen Systeme haben, die ihn in seiner täglichen Arbeit unterstützen sollen – allen voran das Unternehmensportal. Dieses muss der neuen, von schneller Veränderung geprägten Arbeitsweise geeignete flexible Funktionen bieten. Mit anderen Worten: Die Portalanwendungen müssen nicht nur be-

346

■ ■ ■

13 Ausblick

nutzerspezifisch konfigurierbar, sondern möglichst einfach änderbar sein. Wenn für jede Änderung ein neues IT-Projekt aufgesetzt werden muss, wird die IT-Abteilung schnell zum Flaschenhals des agilen Prozesses. Deshalb sollte die Anpassbarkeit und Automatisierung der Portalanwendungen durch den Benutzer möglich sein – in Grenzen, versteht sich. Ein Beispiel aus der Betriebssystemwelt mag dies illustrieren. Apples Betriebssystem Mac OS wird mit einer Skriptsprache namens AppleScript ausgeliefert. In einer dem Englischen ähnlichen Sprache können Skripte geschrieben werden, die Aktionen des Betriebssystems und der Anwendungsprogramme automatisieren (www.apple.com/applescript/). Die Nähe zur natürlichen Sprache und die Möglichkeit, Skripte automatisch aufzuzeichnen, öffnen auch Nicht-Programmierern den Zugang zu AppleScript. Ein einfaches Beispiel (aus Altenburg 2003) zeigt die Struktur eines AppleScript-Skripts: set temp to display dialog "What is your age in years?" default answer "" set ageEntered to text returned of temp try -- First we check if the user entered a number set ageEntered to ageEntered as number set ageInMonths to ageEntered * 12 display dialog "Your age in months is " & ageInMonths on error -- If it is not a number, the entry must -- have been text display dialog "Instead of a number, like 30 , you entered text." end try

Listing 13.1 AppleScript

Die 11 Skriptzeilen enthalten ein komplettes Programm, inklusive Dateneingabe, Prüfung auf numerisches Format, Fehlerbehandlung und Ergebnisausgabe. Eine Portalanwendung ließe sich mit einer ähnlichen Skriptsprache wie AppleScript automatisieren und eventuell sogar verändern. Damit stünde ein Unternehmen vor dem agilen Durchbruch.

13.3 Technische Entwicklungen

■ ■ ■

347

13.4 Fazit Das Portal der Zukunft schafft Mehrwerte – in finanzieller Hinsicht wie auch im Hinblick auf die Kunden- und Mitarbeiterzufriedenheit. Die zunehmende Automatisierung der Informationsrecherche sowie ausgewählter Geschäftsprozesse (z.B. Bestellung) bietet neue Kommunikations- und Vertriebsmöglichkeiten und entbindet zugleich die Mitarbeiter des Unternehmens von Routinetätigkeiten. Schließlich werden die Integrationsaktivitäten bei der Einführung und Pflege eines Unternehmensportals die Diskussion um die Konsolidierung und Zentralisierung der Unternehmensdaten anregen – Voraussetzung für eine Vereinfachung der technischen Integration und eine Verbesserung und Erweiterung des integrierten Informationsangebots. Das Portalsystem der Zukunft ist eine Komposition entkoppelter Komponenten, die ihre Funktionalität als Dienste anbieten. Serverbasierte Portalanwendungen geben eine integrierte Sicht auf die Informationen und Dienste des Unternehmens wieder. Dieser Sicht wird in Thin Clients mit komfortablen ergonomischen Benutzungsoberflächen Ausdruck verliehen. Diese Flexibilität spiegelt sich auch auf der Prozessebene wider. Agile, leichtgewichtige Prozesse lassen sich leicht an veränderte Bedingungen anpassen. Diese Änderungen wirken sich wiederum auf die Portalanwendungen aus, die von den agilen Akteuren nach deren Anforderungen angepasst werden können. Die Zukunft wird zeigen, wie nahe die real existierenden Portalsysteme diesem Idealbild kommen werden.

348

■ ■ ■

13 Ausblick

Literaturverzeichnis

Abdelnur, A., Hepper, S.: Java Portlet Specification. Version 1.0. 2003 www.jcp.org/en/jsr/detail?id=168 Altenburg, B.: AppleScript for absolute starters. 2003 http://www.applescriptsourcebook.com/tips/AS4AS/AS4ASb2.pdf Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Business Process Execution Language for Web Services. Version 1.1. 2003 www.ibm.com/developerworks/webservices/library/ws-bpel/ Aulds, C.: Linux Apache Web Server Administration (Craig Hunt Linux Library). 2nd Edition. Alameda: Sybex, Inc. 2002 Balzert, H.: Lehrbuch der Software-Technik: Software-Entwicklung. Heidelberg Berlin Oxford: Spektrum Akademischer Verlag 1996 Bearman, D., Sochats, K.: Metadata Requirements for Evidence. 1995 www.archimuse.com/papers/nhprc/BACartic.html Behme, H., Mintert, S.: XML in der Praxis – Professionelles Web-Publishing mit der Extensible Markup Language. München: Addison-Wesley 2000 Berg, H.: Portale in Deutschland 2004 und 2005 – Einsatz, Planung, Strategie, Hemmnisse. Kassel: TechConsult GmbH 2004 Berkhout, M., Harrow, R., Johnson, B., Lacy, S., Lloyd, V., Page, D., Goethem, M. van, Bent, H. van den, Welter, G.: Service Support. IT Infrastructure Library 2000 Binder & Company: Unternehmensportale – noch ein langer Weg zum digitalen Arbeitsplatz (Studie). 2004 Birker, K.: Projektmanagement. Berlin: Cornelsen 2003 Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C., Orchard, D.: Web Services Architecture. W3C Working Group Note 11. February 2004 www.w3.org/TR/2004/NOTE-ws-arch-20040211/

Literaturverzeichnis

■ ■ ■

349

Borchers, D.: Juchhu!, Yahoo!: 10. heise online. 2005 www.heise.de/newsticker/meldung/56977 Born, A., Diercks, J.: Universaleingang – Portale: Hype oder Arbeitsumgebungen der Zukunft? iX Magazin für professionelle Informationstechnik 11, 108–113 (2004) Büchner, H., Zschau, O., Traub, D., Zahradka, R.: Web Content Management – Websites professionell gestalten. Bonn: Galileo Press 2001 Busch, C., Daum, H., Graf, F.: Evaluierung von Gesichtserkennungssystemen – Project BioFace. In: IT-Sicherheit im verteilten Chaos, 8. Deutscher ITSicherheitskongress des BSI, 121–131 (2003) Davenport, T.H., Prusak, L.: Working Knowledge. Boston: Harvard Business School Press 2000 Delphi Group: Enterprise Portals – Total Market Perspective. 2003 www.delphigroup.com/research/reports/total-market.htm Fallside, D.: XML Schema. Part 0: Primer. 2001 www.w3.org/TR/xmlschema-0/ Floyd, C.: Einführung in die Softwaretechnik. Scriptum zur gleichnamigen Vorlesung. Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik 1997 Gadatsch, A.: Management von Geschäftsprozessen. Wiesbaden: Vieweg 2002 Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns – Elements of Reusable Object-Oriented Software. Reading: Addison-Wesley 1995 Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D.: HTTP Extensions for Distributed Authoring – WEBDAV. 1999 www.ietf.org/rfc/rfc2518.txt Gray, J., Reuter, A.: Transaction Processing Concepts and Techniques. San Mateo: Morgan Kaufmann 1993 Haberer, P.: Lightweight Directory Access Protocol (LDAP). 2003 www.mitlinx.de/ldap/ Harold, E., Means, W.: XML in a Nutshell. 3rd ed. Sebastopol: O’Reilly & Associates 2004 Heldt, S.M., Koschek, H.: Larry Ellisons Kaffeefarm – Orace 10g Application Server Containers for J2EE. Java Magazin 3, 78–82 (2005) Hoffmann, M.: Portale auf breiter Front. e-commerce magazin 06/2004, 14–17 (2004)

350

■ ■ ■

Literaturverzeichnis

Hollingsworth, D.: Workflow Management Coalition – The Workflow Reference Model (TC00-1003). Issue 1.1, 1995 www.wfmc.org Horn, T.: EAI Enterprise Application Integration. 2004 www.torsten-horn.de/techdocs/eai.htm Huseby, S.H.: Sicherheitsrisiko Web-Anwendung. Heidelberg: dpunkt-Verlag 2004 Ihns, O., Heldt, S., Wirdemann, R., Zuzmann, H.: Enterprise JavaBeans komplett – Grundlagen, Überblick und Einsatz. München Wien: Oldenbourg Verlag 2004 Klaus, A.: Business Intelligence – Basis für Wissensmanagement. 2004 www.competence-site.de/bisysteme.nsf/ König, D.: Reiche Kunden. iX Magazin für professionelle Informationstechnik 7, 40–42 (2004) http://www.heise.de/ix/artikel/2004/07/040/ Königer, P., Reithmayer, W.: Management unstrukturierter Informationen – Wie Unternehmen die Informationsflut beherrschen können. Frankfurt New York: Campus Verlag 1998 Koschek, H.: Erstmals Standards für Portalsysteme. Computerwoche 51/52, 18 (2003) Koschek, H.: Porta(be)l – Portlet-Spezifikation harmonisiert Portale. iX Magazin für professionelle Informationstechnik 9, 108–111 (2004) Kossmann, D., Leymann, F.: Web Services. Informatik Spektrum 26, 117–128 (2004) Knorr, E.: The new Enterprise Portal. InfoWorld 2, 42–52 (2004) Monson-Haefel, R.: Enterprise JavaBeans. 3rd Edition. Sebastopol: O’Reilly & Associates 2001 Müller, J.: Workflow-based Integration – Grundlagen, Technik, Management. Berlin Heidelberg New York: Springer 2004 Münz, S.: SELFHTML 8.0 – HTML-Dateien selbst erstellen. 2004 selfhtml.teamone.de/ Niemann, F.: SAP erklärt Portal zur Standardoberfläche. Computerwoche 21 (2003) www.computerwoche.de/index.cfm?pageid=255&artid=49332 Nuescheler, D.: Content Repository for Java Technology API. Proposed Final Draft. 2005 www.jcp.org/en/jsr/detail?id=170 Oestereich, B.: Objektorientierte Softwareentwicklung – Analyse und Design mit der Unified Modeling Language. München Wien: Oldenbourg Verlag 2001

Literaturverzeichnis

■ ■ ■

351

Phifer, G., Valdes, R., Gootzit, D.: Big Change Evident in 2H02 Horizontal Portal Product MQ. Gartner Internet Strategies Research Note M-16-3524. 2002 Phifer, G., Valdes, R., Gootzit, D., Underwood, K.S., Correia, J.M., Andrews, W.: Magic Quadrant for Horizontal Portal Products, 2004. Gartner Research Note Number M-22-5213. 2004 Portals Magazine: Working it out – IBM sees an integrated future. Interview with Larry Bowden, Vice President, IBM Portal and Lotus Products. Portals Magazine 28(4), 14–16 (2004) Probst, G.J.B., Raub, S., Romhardt, K.: Wissen managen. Wiesbaden: Gabler (2003) Raepple, M.: IT-Ballett – Vier Process Engines im Vergleich. iX Magazin für professionelle Informationstechnik 12, 62–67 (2004) Ramge, T.: Die DINer. brand eins Wirtschaftsmagazin 6, 70–75 (2004) Rath, H.H.: GPS des Web – XML Topic Maps: Themenkarten im Web. iX Magazin für professionelle Informationstechnik 6, 115 ff. (2002) Reins. A. (Hrsg.): Die Mörderfackel – Das Lehrbuch der Texterschmiede Hamburg. Mainz: Verlag Hermann Schmidt 2002 Rupp, C.: Requirements-Engineering und -Management. München, Wien: Hanser 2002 SAGA – Standards und Architekturen für E-Government-Anwendungen. Version 2.0. Schriftenreihe der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt). Band 59. Dezember 2003 www.kbst.bund.de/saga Schnetzer, R.: Business Process Reengineering kompakt und verständlich. Wiesbaden: Vieweg 1999 Schwarze, J.: Informationsmanagement. Herne: Verlag Neue Wirtschafts-Briefe 1998 Sneed, H.M., Hasitschka, M., Teichmann, M.: Software-Produktmanagement. Heidelberg: dpunkt-Verlag 2004 Sun Microsystems: The Business of Delivering Portals – A Technical White Paper. July 2004 Tanenbaum, A.S., Steen, M. van: Distributed Systems – Principles and Paradigms. New Jersey: Prentice-Hall 2002 Troike, M., Lemmer, G.: Unternehmensweites Content-Management – Synthese von Inhalten und Prozessen. IT Management 7, 30–41 (2004) Versteegen, G., Weischedel, G.: Konfigurationsmanagement. Berlin Heidelberg New York: Springer 2003

352

■ ■ ■

Literaturverzeichnis

Wahl, M., Howes, T., Kille, S.: Lightweight Directory Access Protocol (v3). 1997 www.ietf.org/rfc/rfc2251.txt Wensky, J.: 25 heiße Tipps für tolle Texte. München: verlag moderne industrie 2003 Widhalm, R., Mück, T.: Topic Maps. Berlin Heidelberg New York: Springer 2002 Züllighoven, H.: Das objektorientierte Konstruktionshandbuch nach dem Werkzeug& Material-Ansatz. Heidelberg: dpunkt-Verlag 1998 Zwicky, E.D., Chapman, B.D.: Building Internet Firewalls. 2nd Edition. Sebastopol: O’Reilly & Associates 2000

Literaturverzeichnis

■ ■ ■

353

Stichwortverzeichnis

A abaXX 256 Abnahme Kriterien 276 Test 279 Adapter 46, 87, 173 Adressierbarkeit 143 Agent 22, 23, 342 Agilität 346 Amazon 208 Analyse Integrationspotenzial 248 Kosten-Nutzen 266, 313, 327 Risiko 313 Wirtschaftlichkeit 313 Anforderung 231, 324 Eigenschaften 244 funktionale 240, 246, 327 gesetzliche 241 nicht-funktionale 240, 246, 327 technische 115 Anforderungsanalyse 230, 270, 327 Annahmen 235 Bedeutung 249 Glossar 235 Herstellerkriterien 241 Methoden 242 Vorgehensweise 241 Zielgruppe 234 Anforderungskatalog 245, 282, 291, 328 technischer 246 Annotation 128, 131, 294, 342

Anwendungsfall 29, 76, 195, 244, 304, 321, 344 Anwendungsorientiertes Unternehmensportal 32 Apache Ant 170, 308 HTTP Server 177 Software Foundation 113 AppleScript 347 Application Portal Siehe Operational Portal Applikation 21 Arbeitsplatz 72 für eigenverantwortliche Expertentätigkeit (Leitbild) 52 mobiler 344 Architekturmodell fachliches 157 technisches 170 Arcplan 256 ATG 255 Audit 139 Auskunftsfähigkeit 80 Auszeichnungssprache 185, 197 Authentifizierung 98, 106, 158, 168 f., 172, 178 Authentifizierungstoken 101 Authentizität 103, 132 Autorisierung 169, 331

B B2B 336 Backend-Integration 25, 122 Backend-System 48, 89, 107, 153, 157 ff., 171, 173, 176, 208, 278

Stichwortverzeichnis

■ ■ ■

355

Balanced Scorecard 288, 318 BAPI 45 BEA 255, 256 Benutzer 329 Akzeptanz 109, 237, 268 ff., 317, 334 Freundlichkeit 98 Konten 106 Management 105 Profil 96 Rollen 94, 106, 329 Test 303, 308 Verwaltung 105, 158, 167, 168 Benutzungsoberfläche 25, 32, 52, 108, 241 Design 111 durchgängige Gestaltung 121 ergonomische 70, 121 für die kombinierte Integration 123 medienoptimierte 110 Präsentationskomponente 163 Rich Thin Client 346 Sicherheit 138 Berners-Lee, Tim 197, 342 Best Practice 342 Bestellprozess Automatisierung 336 Betriebliches Vorschlagswesen 18 BildschArbV 70 BPEL(4WS) 48, 120, 161, 341 BPM Siehe Business Process Management Branch 309 Browsertest 279 Buffer Overflow 138 Business Application Programming Interface Siehe BAPI Business Case 287 Business Intelligence 36, 92, 165, 337 Komponente 158, 163, 165, 174 f. Business Objects 256 Business Process Execution Language for Web Services Siehe BPEL(4WS)

356

■ ■ ■

Stichwortverzeichnis

Business Process Management 341 Siehe auch Geschäftsprozess Business-to-Business Siehe B2B

C Cache 144 Proxy 172, 178 Cascading Stylesheet Siehe CSS CGI 149 Change Management 270, 328, 330 Click2Action 26 Code Freeze 307 Cognos 256 Collaboration Siehe Miteinanderarbeit Collaborative Portal 35, 57, 116, 300 Commit 174 Common Gateway Interface Siehe CGI Common Object Request Broker Siehe CORBA Computer Associates 255, 256 Content 18, 19, 40, 130, 285 Repository 42 Syndication 41 Trennung vom Design 110, 149, 196 ff. Content Management 40, 176, 282 Abgrenzung zu Portalen 40 Standards 220 System 18, 21, 39, 164, 220, 298 Content Provider 41 Content Repository for Java Technology API 220 Content Sharing 41 CORBA 22, 45, 120, 176 Corechange 256 Corporate Branding 109, 229 Corporate Design 199 Corporate Identity 108, 121, 307 Cross Site Scripting 138 CSS 197 ff. CVS 307, 309

D Data Warehouse 36, 165, 294 Daten 12, 14 ff., 32, 36, 75 f., 123, 157 abgeleitete 74 als Ressource 141 Analyse 36 Annotation 130 aufbereitete 14, 165 Integration 116 konsistente 75 MVC 150 operative 165, 294 originäre 14, 74 Präsentation 163 prozessrelevante 84, 161, 248 redundante 75, 248, 315 redundante Speicherung 133 relevante 36 Replikat 143 Schutz 33, 158, 172 schützenswerte 103, 168 strukturierte 13, 40, 88, 125 Transformation 89, 196, 200 über Daten 88, 129 unstrukturierte 13, 88, 127, 158, 166 unvollständige 75 verzeichnisartige 168 Zentralisierung 348 zur Prozesskontrolle 161 Datenaustausch 44, 55, 88 Datenbank 45, 123 f., 133, 138, 149, 186, 208 Datenbanksystem 125, 148, 175, 181 Datenbeziehungen 49 implizite 125 Semantik 125 Datenerfassung 11, 14, 20, 77, 298, 336 Datenhaltung 87, 248 Datenintegration 45 Datenintegrität 125, 278 Datenkatalog 329 Datenkonsistenz 143 Datenmapping 46 Datenmodell 36 Analyse 123 Beziehungen 122, 157

Standardisierung 117 unternehmensweites 337 Datenpflege 75, 111 Datenqualität 75, 163, 337 Datensatz 22, 123, 126, 186 Datenschutz 55, 330 Datenselektion 87 Datensicherheit 106, 132 Anforderungen 133 Datensicherung 134 Datenspeicherung 56 Datentyp 13 Datenübernahme 77, 301 Datenzugriff 55, 87, 279 DCOM 45 Deadlock 142 Decision Portal 36, 116 Deployment 334 Design Trennung vom Content 149, 196 ff. Design Pattern Siehe Entwurfsmuster Desktop-Anwendung 224 Dienst 22, 28, 120, 122, 157, 159, 171 Adressierbarkeit 143 BPEL(4WS) 120 JCA 208 Netzwerkprotokoll 179 räumliche Transparenz 142 SOA 120 verteilte Anwendung 140 Web Service 120, 172, 205, 341 WSRP 213, 340 Zugriffstransparenz 142 Digitales Zertifikat 100 DIN 183 Distributed System Siehe Verteiltes System Document Object Model Siehe DOM Dokumenttyp-Definition Siehe DTD DOM 196 Drag and Drop 123 Drag&Relate 26 DTD 185, 189, 191, 195, 206 Vergleich mit XML-Schema 193

Stichwortverzeichnis

■ ■ ■

357

Dynamische Webseite 177 Generierung 150 Programmierung 149

E EAI Siehe Enterprise Application Integration ebXML 195 EDIFACT 55 Ein-/Ausgabetest 279 Einführung 332, 334 Strategie 268 Einmalpasswort 101 Einzelinterview 242 EJB Siehe Enterprise JavaBeans Employee Self-Service 66 Enterprise Application Integration 23, 25, 44, 117, 124, 171, 173 Adapter 46, 118 Bus 49, 117 f. Definition 44 in Portalen 48 Integrationsformen 45 Komponente 173 Sternarchitektur 118 Systemkomponenten 46 Workflow 47 Enterprise JavaBeans 45, 120, 147, 176, 209 Enterprise-Content-ManagementSystem Siehe Content Management Entkoppelte Komponenten 145, 180, 339 Minimalfunktionalität 146 Schnittstellen 146 Standardverhalten 146 Entwicklertest 303, 308 Entwicklungssystem 306 Entwurfsmuster 151, 184 Epicentric 255 Erfolgsfaktoren für Portalprojekte 230, 237 Messkriterien 85 Ergonomie 70, 108, 121, 241 Eskalationsstufe 81 Exception Handling 333 Experte 16, 57, 68, 336 Experten-Arbeitsplatz 52

358

■ ■ ■

Stichwortverzeichnis

Expertentätigkeit 52, 64 Expertenwissen 57, 65 Extensible Markup Language Siehe XML Extensible Stylesheet Language Siehe XSL Extract, Transform and Load 165

F Fachkonzept 330 Fachliche Referenzarchitektur 157 Fachsprache 52 FAQ Siehe Frequently Asked Questions Fehlerreport 308 Feinkonzept 331 Fernsehen, digital Siehe iTV Firewall 172, 179 Formatierungsobjekt 200 Fragebogen 242 Fragment 163, 178, 212, 214 Frequently Asked Questions 293, 336 Frontend-Integration 25, 43, 120 Führendes System 21, 74, 122, 126 f., 337 Funktionsaufruf 45 Funktionsunterstützung 81

G Gartner-Quadrant für Portalsysteme 254 GATE 128, 343 Gauss 256 Geschäftsprozess 19, 21, 31 ff., 37, 233, 299 Abbildung und Steuerung 79 Analyse 233, 297, 328 Evolution 80 Management 62 Messbarkeit 85 Modellierung 80, 161 Optimierung 59, 61, 80, 165, 342 Simulation 161 Standardisierung 64 Steuerung 86, 161

technisch unterstützbarer 73 Transparenz 65 Workflow 160, 218 Geschäftsvorfall 19, 81 f., 92, 161, 314 Geschlossenes Portal 30 Google 58 Graphical User Interface Siehe GUI Siehe GUI Grobkonzept 268, 330 Groupware 35 Gruppeninterview 242 GUI 108, 121 Guided Tour 280

H Handheld 110 Hersteller 254 Kriterien 114 Marktübersicht 253, 258 Partnerschaften 257 High Availability Siehe Hochverfügbarkeit Hochverfügbarkeit 134 Kenngrößen 135 Horizontales Portal 29 Hosting 225 HTML 177, 197 Frame 198 Historie 198 Link 197 Spezifikation 204 Struktur 197 XHTML 198 HTTPS 178 Hummingbird 256 HyperText Markup Language Siehe HTML

I IBM 26, 255, 256 IDE 170 IIOP 22 i-mode 110 Implementierung 274, 332 Phasen 275 Information 15, 19 Aktualität 297

Bedarf 76 Eigenschaften 91 Extraktion 128, 166, 343 Filterung 94 Heterogenität 87 Kontextrelevanz 82, 84, 88, 93, 105, 314 Modellierung 89 Präsentation 60 Information Portal Siehe Publishing Portal Informationsmanagement 11, 51, 87, 159 Informationspflicht 60 Informationspool 16, 57, 75 Informationsqualität 59, 71, 75, 84, 90, 283 Informationsquelle 87 Informationsrecherche Siehe Suche, Recherche Informationsspektrum 88 Informationssystem 14 Informationszugriff 87, 92, 228, 283 Inhalt Siehe Content Inhaltskomponente 163 Insellösung 85 Integrated Development Environment Siehe IDE Integration Architektur 49, 173 Backend 25, 122 Bedarf 76 Dimensionen 23 Frontend 25, 43, 120 Funktionsaufruf 45 kombinierte (Frontend/Backend) 25, 62, 122 Middleware 45 nachrichtenbasiert 46 Nutzen 300 technische 115 terminologiebasierte 88 ungenügende 76 von Anwendungen 48 von Content-ManagementSystemen 42 von Daten 45 von Geschäftspartnern 226

Stichwortverzeichnis

■ ■ ■

359

von Prozessen 24, 37, 46, 62, 119, 122, 159, 248 von Systemen 24, 37, 62, 76, 116, 119, 342 Integrationskomponente 157, 159, 163, 173 Integrationspotenzial 248, 299, 328 Integrationstest 278 Integrität 103, 132 International Press Telecommunications Council 113 Inter-Portlet-Kommunikation 124, 304 Intranet 21, 66, 166, 224 Investitionsschutz 114, 316 IONA 256 ITIL 307 IT-Systemmanagement 181 iTV 110 iView 210 f. Ixos 256

J J2EE 45, 175 f., 208, 209 J2EE Connector Architecture Siehe JCA Jahr-2000-Problem 186 Java Community Process Siehe JCP Java Database Connectivity Siehe JDBC Java System Portal Server 255 JavaScript 197 f. JCA 208 JCP 209 JDBC 45 Jetspeed 257 JSP 138, 257 JSR 168 Siehe PortletSpezifikation JSR 170 Siehe Content Repository for Java Technology API

K Kennzahl 14, 60, 85, 92, 165, 226, 228, 299, 345 für die Wirtschaftlichkeit 313, 334 Projekterfolg 291 ROI 67 Kennzahlensystem 288 Know-how-Transfer 27 Knowledge Management 16, 57, 92, 131, 166 Komponente 158, 162 f., 166, 174 f. System 17, 222 Knowledge Portal Siehe Decision Portal Kombinierte Integration (Frontend/Backend) 25, 62, 122 Kommunikation im Projekt 262 Schnittstellen 90 zwischen Systemen 89 Komponenten enge Kopplung 145 lose Kopplung 146 Komponententechnologie 250, 332 Kontext 130 Kopplung enge 145 lose 146 Kosten 318 für Betrieb 114 operative 314 Opportunitäts- 315 Reduzierung 61, 335 Kundenbindung 67, 76, 336 Kundenmehrwert 226, 234 Kundenservice 57, 59 Automatisierung 336 Kundenzufriedenheit 59, 67, 336

L Ladezeit 109 Last 278 Lastanforderung 320 Lasttest 153, 333

360

■ ■ ■

Stichwortverzeichnis

Lastverhalten 272 Lastverteilung 172, 177, 178, 253 LDAP 168 Leistungstest 278 Leitbild 69 Arbeitsplatz für eigenverantwortliche Expertentätigkeit 52 Leitfaden des Bundesamtes für Sicherheit in der Informationstechnik 104 Lernendes Projekt 302 Lernendes Unternehmen 17, 33, 167 Lernprozess 83, 86 Lessons Learned 302, 304 Lightweight Directory Access Protocol Siehe LDAP Load Balancing Siehe Lastverteilung

M Machtpolitik 64 Management Dashboard 61 Management-Informationssystem 227 Marktübersicht 253, 258 Markup Language Siehe Auszeichnungssprache Medienbruch 20, 31, 44 Mehrbenutzertest 153 Mehrstufiger Freigabeprozess 40, 298, 305 Merge 309 Message Queue 45 Messaging Server 47 Metadaten 88, 129, 283, 294 Repository 46 Typen 130 Metadatenserver 123 ff., 157, 172, 175, 337 Microsoft 256 Middleware 171, 173, 332 komponentenorientierte 45 nachrichtenbasierte (MOM) 45 objektorientierte 45

Middleware/EAI-Komponente 173 Migration 43 Miteinanderarbeit 26, 30 ff., 54, 144, 167, 226, 300, 311, 338 Mobiles Endgerät 110, 177, 319, 344 Mobiltelefon 110 Model-View-Controller 150, 158, 164 Moderator 71, 293 Monitoring 153, 172, 219 Motivation der Anwender 281 der Mitarbeiter 64, 69, 82 für ein Portalprojekt 232 Multimodalität 110, 344 MVC Siehe Model-ViewController

N Nachricht 15, 19 f., 45, 47, 140 NewsML 195 RSS 215 SOAP 207 Nachvollziehbarkeit 103, 132 Nacktmull 152 Namensdienst 143 Natürlichsprachlicher Text Analyse 344 Beziehungen 167 Informationsextraktion 128, 166 Navigation 108, 110, 320, 331 Navigationskomponente 163 Netscape 198, 215 NewsML 195 Norm 183 Normsprache 89 Nutzen Analyse 316, 321 Betrachtung 287, 312, 331 messbarer 67 nicht messbarer 67 wirtschaftlicher 311, 327 Nutzungsprofil 292

Stichwortverzeichnis

■ ■ ■

361

O OASIS 113, 209 ODBC 45 ODS 47 Offener Standard 184 Offenes Portal 30 OLAP Siehe Online Analytical Processing OMG 113 Online Analytical Processing 165, 294 Open Database Connectivity Siehe ODBC Open Source Projekte 257 Workflow 219 Open Text 256 Operational Data Store Siehe ODS Operational Portal 35, 116 Oracle 181, 255 f.

P PDA 110 PDF 201 Peoplesoft 256 Performanz 151, 240, 250, 253, 272, 317 Messung 152 Personal Digital Assistant Siehe PDA Personal Information Manager 224 Personalisierung 94, 107, 111, 164, 285, 331 implizite 95 nach persönlichen Einstellungen 95 nach Rollen 94 Pflichtenheft 331 Phishing 138 PHP 197 PIN 101 PKI Siehe Public-KeyInfrastruktur Plugin 170 Plumtree 255 f. Portal 28

362

■ ■ ■

Stichwortverzeichnis

Abgrenzung zu Content Management 40 Einsatzbereiche 37 ERP 257 Erweiterung 169 geschlossenes 30 Historie 28 horizontales 29 Informationsmanagement 282 Kategorien 29 Kategorisierungsmatrix 30 Konzept 331 Konzeption 330 multimodales 110, 344 Nutzer 233 offenes 30 Strategie 68 vertikales 29 Portaladministration 172, 180 Portalapplikation 111, 158, 162, 163, 166, 172, 176 Portalarchitektur 113, 274, 320 fachliche 157 nach Portlet API 212 technische 170 Portalbewertung 291 Portalfunktion Bewertung 267 Portalmarketing 70, 285, 290, 301, 304 Portalprodukt Siehe Portalsystem Portalprojekt Beteiligte 233 Einflussfaktoren 260 Herausforderungen 259 initiale Planung 266 iteratives Vorgehen 281 Kommunikation 262 Konventionen 235 Motive 232 Projektplan 269 Randbedingungen 236, 237 Ressourcen 237 ff., 266, 324 Risikomanagement 238 Sprache 235 Start 265 Team 262 Ziel 237 Portalseite 163 Portalserver 163, 172, 176, 212

Portalsoftware-Marktübersicht 112, 254 Portalsystem Hersteller 254 Open Source 257 Portalüberwachung 172, 180 Portlet 163, 172, 176, 257 CMS-Integration 42 Portlet-Container 172, 176, 212 Portlet-Spezifikation 63, 122, 162, 165, 176, 183, 210, 340 Historie 211 Portlet-Standard Siehe PortletSpezifikation Präsentationskomponente 158, 163 Produktionssystem 309 Programmierschnittstelle 159, 169 Programmierwerkzeug 159, 169 Projektcontrolling 275 Ergebniscontrolling 276 Kostencontrolling 276 Termin- und Ablaufcontrolling 276 Projektmanagement 260 Change Management 270 Controlling Siehe Projektcontrolling Kennzahlensystem 288 Marketing 285 Nutzen 263 Projektplan 269 Prozess 264 Projektprozess 264 Proof-of-Concept 271 Protokolldatei 292 Prototyp 244, 271, 328 Entwicklung 273 Prototyping Siehe Prototyp Proxy Cache 172, 177 f. Prozess betriebswirtschaftlicher 79 Integration 24, 37, 46, 62, 119, 122, 159 Komponente 158, 160 Kosten 86, 314 Management 19 Messbarkeit 85 Modellierung 80 Qualität 314

Schritt 81 Standardisierung 82 Unterstützung 81 Wissen 82 Prozesskette 62, 81, 85, 314 informationstechnische 153 Prozesskontrolldaten 161 Prozessorientiertes Unternehmensportal 31 Prozessrelevante Daten 161 Public-Key-Infrastruktur 101 Publish and Subscribe 46 Publishing Portal 35, 116 Punkt-zu-Punkt-Verbindung 49, 117 Push- und Pull-Mechanismen 84

Q Qualität als Erfolgsfaktor 317 der Benutzerführung 108 der Daten 75, 163, 337 der Geschäftsprozesse 37, 61, 79, 86, 314 der Informationen 33, 59, 71, 75, 84, 90, 283, 315 der Rechercheergebnisse 58 f., 158, 167 der Services 58 der Software 148, 153 der Textanalyse 344 der Texte 298 der Workflows 161 des Portals 231, 304 im Portalprojekt 72, 281 Qualitätsbewertung 90 Qualitätsmerkmal 90 Qualitätsrichtlinie 90 Qualitätssicherung 17, 82, 137, 275 ff., 298, 326, 332 Datenbeziehung 125 Portalentwicklung 156 Recherche 167 Test 310 Qualitätsstandard 91

R RAID 133

Stichwortverzeichnis

■ ■ ■

363

Rapid Application Development 271 RDF 222 Real-Time Enterprise 342 Recherche 16, 58, 84, 98, 166, 272, 343 Rechteverwaltung 105, 161 Rechtssicherheit 104 Redakteur 296, 298 Redaktion 295 Prozess 40, 298 Workflow 283 Referenzarchitektur 155 fachliche 157 technische 170 Regressionstest 272, 310 Release Management 137, 270, 288, 305 Release Manager 305 Relevanz 28, 37 Regeln 295 Remote Function Call Siehe RFC Remote Method Invocation Siehe RMI Remote Procedure Call Siehe RPC Rentabilität 37, 313 Replikation 143 Report 36, 165, 293, 345 Requirements Engineering Siehe Anforderungsanalyse Resource Description Framework Siehe RDF Ressource Deadlock 142 des Portalprojektes 235 ff., 266, 324 gemeinsame Nutzung 141 Return on Investment Siehe ROI Siehe ROI RFC 45 Rich Thin Client 346 Risikomanagement 238, 269 Risikominimierung 60 RMI 45 ROI 30 f., 37, 67, 228, 266, 267, 313, 339 Berechnung 317 Rollback 174

364

■ ■ ■

Stichwortverzeichnis

Rolle 27, 29, 40, 68, 79, 81, 94, 105 ff., 158 ff., 237, 292 f., 296 ff., 305, 329 Rollenmanagement 105 Rollout 280 Checkliste 280 RPC 45, 207 RSS 215 RTE Siehe Real-Time Enterprise Rückkopplung 304

S SAP 26, 210 f., 255 f. SAS 256 SAX 196 Schlagwortkatalog 167 Schnittstelle 87 Beschreibung 116 Bündelung 117 entkoppelter Komponenten 146 offene 148, 340 Programmier- 159, 169 Schufa 20 technische 329 von Knowledge-ManagementSystemen 17 Workflow Reference Model 218 Schreiben von Texten 296 Schulung 309, 333 f. Schutzziele 103 SeeBeyond 256 SELFHTML 204 Semantic Web 222, 342, 344 Service Siehe Dienst Service Level Agreement 135 Service Provider 241 Servicekatalog 116 Service-Oriented Architecture Siehe SOA Servicequalität 58 SGML 185 Shell Command Injection 138 Sicherheit 102 Audit 139 beim Portal-Login 99 der Investition 112 der Projektplanung 249, 324

Kommunikation 169 Konzept 330 Mechanismen 168 multimodaler Portale 345 Schutzziele 103 technischer Systeme 138 Sicherheitskomponente 158 Sicherheitsmechanismen 168 Sicherheitstest 279, 333 Siebel 256 Simple API for XML Parsing Siehe SAX Single Point of Access 226 Single Point of Failure 136 Single Sign-On 33, 35, 98, 158, 168 ff., 331 Skalierbarkeit 262 entkoppelter Komponenten 145 fachliche 114 horizontale 178 technische 139 verteilter Systeme 140 SOA 120, 341 SOAP 22, 207 Softwarearchitektur 155 Softwareauswahl 118, 210, 250, 324, 331 Checkliste 252 Marktübersicht 253, 258 Softwareentwicklungsumgebung 170 Softwaresystem externes 21 internes 21 SQL Injection 138 Stammdaten 21, 26, 75, 77 Standard 63, 183 für Content Management 220 für Integration 47, 205 für Kommunikation 114 für Portalinhalte 215 für Portaltechnik 208 für Präsentation und Layout 196 für Prozesse 218 nicht normierter 184 offener 113, 184 technologischer 147 Standard Generalized Markup Language Siehe SGML

Standardisierung 82, 250 Sternarchitektur 118, 173 Strength-Weakness-OpportunityThreat Siehe SWOT-Analyse Strukturierte Daten 88, 125 Stylesheet 111 Cascading 199 XSLT 201 Suche im Content Repository 43 intelligente 158, 222, 294, 342 natürlichsprachliche 58, 344 Suchmaschine 58, 222, 295, 342 Sun Microsystems 255, 256 Supportsystem 309 SWOT-Analyse 287 Sybase 256 System Requirements 328 Siehe Anforderungskatalog, technischer Systembruch 20, 31 Systemintegration 24, 37, 62, 76, 116, 119, 342 Systemüberwachung 134

T Taxonomie 88, 167, 175, 284, 343 TCO 318 Technische Referenzarchitektur 170 Technischer Integrationstest 307 Template 163 Terminologie 89, 125 f., 159 Test 310, 333 Abnahme 279 automatisierter 279 Browser 279 durch Benutzer 303, 308 durch Entwickler 303, 308 Ein-/Ausgabe 279 Exception Handling 333 fachlicher 333 Integration 278 Last 333 Leistung 278 Protokoll 308 Sicherheit 279, 333 technische Integration 307

Stichwortverzeichnis

■ ■ ■

365

technischer 333 Usability 109, 272 Verfahren 278 Testdaten 307, 310 Testfall 307, 310 Textanalyse 128, 343 Thin Client 257 TIBCO 255, 256 Topic Map 93, 167, 221 Total Cost of Ownership Siehe TCO TP-Monitor 175 Trainingssystem 309 Transaktion 133, 143, 171, 181, 220 ACID-Eigenschaften 174 verteilte 143, 174, 340 Transaktionsmanager 171, 174 Transaktionsmonitor 176 Trennung von Content und Design 110, 149, 196 ff. Trust Center 100

U UDDI 207 Umsatzgenerierung 315 UMTS 110 Unicode 188, 198 Universal Description, Discovery and Integration Siehe UDDI Unstrukturierte Daten 88, 127 Unternehmen 10 Kategorien 223 lernendes 17, 83, 167 Sichten 299 Unternehmensdaten Siehe Daten integrierte Sicht 92, 248 Unternehmenskommunikation 229 Unternehmenskultur 229 Unternehmensportal 32, 251 anwendungsorientiertes 32 Anwendungsschwerpunkte 34 prozessorientiertes 31 Zielgruppen 33 Unternehmensstrategie 260 Unternehmenswissen 17, 27, 65, 131, 166, 300, 315 Usability 108

366

■ ■ ■

Stichwortverzeichnis

Test 109, 272 Use Case 244, 328 User Helpdesk 280 User Tracking 96, 97

V Validierungssystem 307 Velocity 257 Verantwortlichkeit 72, 106, 235, 269 Verfügbarkeit 22, 103, 132 ff., 178 prozentuale 135 rechtzeitige 16 Verschlüsselung asymmetrische 100 Versionierung Siehe Versionsverwaltung Versionsverwaltung Branch 309 CVS 307 für Content 220 für Dokumente 56 für Software 307 Merge 309 Verteilte Anwendung 140 Verteilte Transaktion 143, 174 Verteiltes System 22, 141 Vertikales Portal 29 Vertraulichkeit 103, 132 Vignette 255 Virtuelle Informationsquelle 87 Virtueller Raum 35, 57, 167, 300 Vision 69, 290 V-Modell XT 325 Voice XML 195 Volere 231 Vorgehensmodell 323 Aufgabe 324 für IT-Projekte 325 für Portalprojekte 326 Vorschriften gesetzliche 241, 316 Vortal Siehe Vertikales Portal

W W3C 113, 196, 207 Web Design 149

Web Mining 96 Web Service 22, 46 f., 120, 172, 205, 341 Architektur 206 Funktionsweise 48 Intermediary 207 Komponente 180 SOAP 207 UDDI 207 WSDL 207 Web Services Description Language Siehe WSDL Web Services for Remote Portlets Siehe WSRP Web-Applikationsserver 172, 176 Web-based Distributed Authoring and Versioning Siehe WebDAV WebDAV 220 WebMethods 256 Webserver 176, 177 Webtop 345 Web-Trojaner 138 Wertschöpfung 29, 62, 67, 267, 318, 327 WfMC Siehe Workflow Management Coalition WfMS Siehe WorkflowManagement-System Wirtschaftlichkeit Analyse 334 des Unternehmens 79 Potenzial 311, 321, 330 Wissen 12, 15, 19, 27, 64 f., 74, 162, 166, 338 abgeleitetes 221 Austausch 82 Fluss 83 Generierung 93, 95 Nutzung 93 Randbedingungen 16 Wissensmanagement 18, 36, 57, 93 Wissensspeicher 33, 65, 166, 282, 336 Wizard 170 Workflow 40, 146, 160, 171, 218, 298, 341 f. Aktivität 119, 124 EAI-Komponente 47

Eskalationsstufe 81 geeignete Prozesse 160 Integration 124, 341 Komponente 119, 167, 174 Standard 161 Steuerung 81, 119 System 119, 161, 219 Workflow Management Coalition 218 Workflow Reference Model 218 Workflow-Management-System 160, 218 Workflowsystem 161 Workgroup-System 35 World Wide Web Consortium Siehe W3C WSDL 207 WSRP 213, 257, 340, 341 WYSIWYG 40

X X.509-Zertifikat 100 XHTML 198, 204 XML 55, 120, 175, 184, 185, 197, 343 Attribut 185, 189 Bezeichner 188 Blattelement 188 Definition eigener Sprachen 195 Element 185, 189 Erweiterbarkeit 195 gültiges Dokument 191 mit DTD 191 mit XML-Schema 194 Namensraum 193 Namespace Siehe XMLNamensraum RSS 215 Topic Map 221 Unterelemente 188 valides Dokument 191 Web Service 205, 206 wohlgeformtes Dokument 191 Wurzelelement 188 XHTML 198 XSL 200 XSL-FO 200 XSLT 200

Stichwortverzeichnis

■ ■ ■

367

XML Encryption 207 XML Signature 207 XML-Dokument gültiges 191 valides 191 wohlgeformtes 191 XML-Schema 185, 191, 195, 206 Elementtyp 193 komplexer Elementtyp 193 Vergleich mit DTD 193 XSL 111, 200 XSL Transformation Siehe XSLT Siehe XSLT XSL-FO 200 XSL-Formatierer 201 XSLT 111, 200 Prozessor 201

Y Yahoo! 28, 29

368

■ ■ ■

Stichwortverzeichnis

Z Zeit 144 Zentraler Datenbestand 337 Zertifikat 100 Zertifizierungsstelle 100 Ziel 232 betriebswirtschaftliches 311 des Portalprojektes 237, 265 Findung 327 Konflikt 237 wirtschaftliches 287 Zugriff Kapselung 88 Kontrolle 98 multimodaler 110 plattformunabhängiger 228 Profile 331 Schicht 87 Steuerung 168 Zukunftsfähigkeit 320