Erarbeitung eines Konzepts für die Integration eines Shop-Systems mit ERP-Anbindung in ein Geschäftskundenportal

Inhaltsverzeichnis

1 Einleitung
1.1 Aufgabenbeschreibung
1.2 Vorgehensweise

2 Festool Portal Szenario
2.1 Systemumgebung
2.2 Anforderungen von Festool an das Portal

3 Definition und Klassifizierung von Portalen
3.1 Definitionen von Portalen
3.2 Klassifizierung - vertikale und horizontale Portale
3.3 Typen von Unternehmensportalen
3.3.1 Mitarbeiterportale
3.3.2 Geschäftskunden- und Lieferantenportale
3.4 Endkundenportale
3.5 Abgrenzung zum Marktplatz

4 Funktionen von Portal-Software
4.1 Grundfunktionen
4.1.1 Benutzer-Management
4.1.2 Personalisierung
4.1.3 Single-Sign-On
4.1.4 Content-Management
4.1.5 Layout-Management
4.1.6 Struktur-Management
4.1.7 Suche
4.2 Erweiterte Funktionalitäten

5 Aufbau von Portalen
5.1 Allgemeine Portal-Architektur
5.1.1 Präsentationsdienste
5.1.2 Portal-Server
5.1.3 Integration Services
5.1.4 Backend Systeme
5.2 Beispiele für Portal-Architekturen
5.2.1 IBM WebSphere-Portal
5.2.2 Serverseitige Skriptsprachen

6 Das Oracle 9iAS Portal
6.1 Portal-Architektur
6.2 Portlets und Provider
6.2.1 Die Oracle Portlet-API
6.2.2 Die Provider- und Portlet-Konfigurationsdatei
6.2.3 Provider Runtime Framework
6.2.4 Kommunikation und Ereignisbehandlung zwischen Portlets
6.3 Ablauf und Behandlung einer Portalanfrage

7 Intershop Enfinity
7.1 Komponenten
7.2 Prozessmodellierung
7.3 Schnittstellen eCAPI, eRXI und Cartridges

8 Web Services
8.1 Das SOAP Protokoll
8.2 Web Services Description Language
8.3 UDDI

9 Konzeption und Implementierung
9.1 Integrationskonzepte
9.1.1 Integrationsarten
9.1.2 Datenformat
9.1.3 Anordnung der EKS-Komponenten im Portal
9.2 Anpassung der Enfinity Templates
9.3 URL umschreiben
9.4 Einbinden von Informationen aus dem Content-Management-System Zope
9.5 Umsetzung des Single-Sign-On
9.6 Entscheidungsfindung
9.7Übertragung mittels HTTP Request/Response-Prozess
9.8 Konfigurator
9.9 Definition des Portlets in der Provider-Deklarationsdatei
9.10 Code Optimierung
9.11 Einbindung in das Portal
9.11.1 Deployment der Portal-Anwendung
9.11.2 Einsetzen des EKS Portlets

10 Zusammenfassung und Ausblick
10.1 Ergebnisse der Arbeit
10.2 Fazit zu den verwendeten Systemen
10.2.1 Oracle9iAS Portal
10.2.2 Enfinity
10.2.3 Web Services SAP/R3
10.3 Ausblick

11 Anhang
11.1 Abkürzungsverzeichnis
11.2 Abbildungsverzeichnis
11.3 Tabellenverzeichnis
11.4 Literaturverzeichnis

Vorwort

Die vorliegende Arbeit entstand am Fraunhofer Institut für Institut für Arbeitswissenschaft und Technologiemanagement (IAT) in Stuttgart. Sie ist Teil eines internen Projekts zur Entwicklung eines Portaldemonstrators. Dieser soll die verschiedenen Aspekte eines Portals, insbesondere die Integration von externen Systemen, darstellen. Ich möchte mich bei allen bedanken, die zum Erfolg dieser Arbeit beigetragen haben. Herzlich danken möchte ich Herr Dipl.-Inf. Thorsten Gurzki für die hervorragende Betreuung. Die wertvollen Kommentare und Anregungen ermöglichten das Gelingen dieser Arbeit.

Mein besonderer Dank gilt meiner Familie. Annette Schweizer für die Korrekturen und Anmerkungen, Helga Schweizer für ihre Unterstützung.

Stuttgart, den 06. 10. 2003

Patrick Schweizer

1 Einleitung

Die Integration unternehmensweiter und unternehmensübergreifender Geschäftsprozesse und Software-Systeme gewinnt heute immer mehr an Bedeutung. Unternehmensportale, welche im weitesten Sinne eine spezielle Form des Intranets sind, haben in der Umsetzung eine bedeutende Rolle. Sie entwickeln sich zum wesentlichen Eckpfeiler der globalen E-Business-Strategie und zur zentralen Schnittstelle zu den relevanten Informationen und Diensten eines Unternehmens. Auf Basis der Internettechnologie können unterschiedliche Backend¹ -Systeme, wie Warenwirtschaftssysteme (WWS), Beschaffungssysteme und Kundenverwaltungsprogramme unternehmensweit als erweitertes Intranet, wie auch als globale Schnittstelle zwischen Unternehmen und Kunden verfügbar gemacht werden. Alle Systeme sind damitüber eine einheitliche, webbasierte Plattform organisiert und erreichbar.

Neben dem klassischen Einzelhandel und dem Versandhandelüber Druckkataloge hat sich inzwischen der Verkauf von Güternüber Online Einkaufssysteme (EKS) etabliert. Damit verändern sich für die verkaufenden Unternehmen die Rahmenbedingungen. Der Markt wird transparenter durch den unkomplizierten, ortsunabhängigen Zugang zu den Einkaufssystemen. Diese Technologien bringen eine Reihe von Vorteilen für die Unternehmen. Durch die weltweite Verfügbarkeit ist es leichter möglich in neue Absatzmärkte vorzudringen. Es können Prozesse automatisiert und damit Kosten gesenkt werden. Dazu ist es jedoch unerlässlich das Einkaufssystem nicht als isoliertes System zu betrachten, sondern Strategien zu entwickeln um sie in die vorhandene IT Landschaft der Unternehmen nahtlos einzubetten. Sie müssen ein integraler Bestandteil der IT Infrastruktur werden. Hierin ist auch die Herausforderung in diesem Bereich zu sehen. Die Einkaufssysteme wurden bisher in der Regel als alleinstehende Lösungen konzipiert. Erst in jüngerer Zeit ging der Trend zu offenen Schnittstellen um die Interoperabilität mit anderen Systemen zu gewährleisten. Zum Beispiel ist die enge Vernetzung des WWS mit dem EKS anzustreben um Bestellungen direkt an das WWS System weiterleiten zu können. In dieser Arbeit sollen Konzepte zur Integration eines Einkaufssystems in ein Portal einerseits und die Anbindung des EKS an ein WWS System andererseits erarbeitet werden.

1.1 Aufgabenbeschreibung

Die Arbeit wird im Competence Center »Electronic Business Integration« (CC EBI) am Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Fraunhofer Gesellschaft durchgeführt. Ziel der Fraunhofer Gesellschaft ist die Förderung der angewandten Forschung und ein schneller Wissens- und Innovationstransfer zwischen Wissenschaft und Wirtschaft.

Das IAT erarbeitet Lösungen aktueller Fragen und Probleme im Bereich des Technologiemanagements. Forschungsschwerpunkt ist die Entwicklung fortschrittlicher Informations- und Kommunikationssysteme. Das CC EBI entwickelt informationstechnische Lösungen und Verfahren zur integrierten Unterstützung unternehmensübergreifender Geschäftsprozesse. Das IAT unterhält ein E-Business- Innovationszentrum, eines von fünf Innovationszentren der Fraunhofergesellschaft in Deutschland. Innerhalb dieser Innovationszentren werden die am IAT erarbeiteten Lösungen für interessierte Unternehmen ausgestellt und präsentiert. Ein aktuelles internes Projekt des CC EBI bildet den Rahmen dieser Arbeit. Das CC EBI plant und entwickelt ein Geschäftskundenportal für die Firma Festool. Eine exemplarische Realisierung des gesamten Portal-Szenarios wird als Portal-Demonstrator für mittelständische Unternehmen im E-Business-Innovationszentrum eingesetzt. Das Portal richtet sich an Festools Fachhändler und bietet unter anderem ein personalisiertes Einkaufssystem. Durch den Einsatz von innovativen Lösungen und IT-Systemen zeigt das Projekt zukunftsweisende Möglichkeiten auf.

Portal-Umgebungen bauen als Integrationsplattform auf bestehende Software-Systeme auf und integrieren deren Inhalte bzw. Funktionalität. Diese Portal-Szenarien werden in der Regel mit Portal-Servern realisiert. Diese stellen Funktionen und Dienste für die Entwicklung neuer und die Integration bestehender Anwendungen bereit. Eine Portalsoftware bietet in der Regel keine Einkaufsfunktionalität an. Diese ist jedoch für den Vertrieb von Warenüber das Internet unerlässlich. Daher ist es das Ziel ein Portal- Szenario zu entwickeln, in das ein EKS integriert wird. Es ist davon auszugehen, dass sowohl das EKS als auch das WWS System bereits vor dem Portal existierten. Die Integration des EKS in das Portal soll mittels vorhandener Internettechnologien und mit geringem Entwicklungsaufwand gelöst werden. Innerhalb des Portal-Szenarios soll das EKS weiterhin direkt, also ausserhalb des Portals, genutzt werden können.

Der Benutzer authentifiziert sich via Single-Sign-On² am Portal-Server und ist somit gleichzeitig an dem Einkaufssystem angemeldet. Der angemeldete Benutzer kann damit auf alle Dienste und Prozesse des EKS, wie auf Katalogstruktur oder Bestellvorgänge zugreifen.

1.1 Aufgabenbeschreibung

1.2 Vorgehensweise

Abbildung 01 stellt den Aufbau und die Abhängigkeiten in der Arbeit schematisch dar. Nach einer Einleitung wird in Kapitel 2 das Festool Portal Szenario vorgestellt. Es stellt die Rahmenbedingungen für diese Arbeit. Kapitel 3, 4 und 5 beschäftigen sich mit den Eigenschaften von Portalen. Es wird eine Definition gesucht und der Aufbau von Portalsoftware und deren Funktion beschrieben. Kapitel 6, 7 und 8 widmen sich den in dieser Arbeit verwendeten Systemen und Techniken. Es wird Aufbau und Funktionweise der Portalsoftware Oracle 9iAS und dem Einkaufssystem Intershop Enfinity betrachtet. Ein Kapitelüber Web Services rundet diesen Block ab. Kapitel 9 beschäftigt sich mit der Erarbeitung von Konzepten zur Integration von Systemen in ein Portal. Anhand dieser Konzepte wird eine Beispielimplementierung vorgenommen und in das Portal eingebunden. In Kapitel 10 wird die Zusammenfassung und ein Ausblicküber die zu erwartende Entwicklung gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 01: Aufbau der Arbeit

2 Festool Portal Szenario

2.1 Systemumgebung

Selten sind Unternehmen in der Situation beim Aufsetzen eines Portals auch alle anderen relevanten Softwaresysteme neu aufzubauen. Dieses kommt in der Regel nur bei Unternehmensneugründungen vor. Im Regelfall müssen eine Vielzahl von bereits bestehenden Anwendungen in das neu zu erstellende Portal eingebunden werden. Da die Systeme hierfür meist nicht vorbereitet sind, ist je nach System mit einem mehr oder weniger umfangreichen Anpassungsaufwand zu rechnen.

Diese Problematik soll in dem Portaldemonstrator exemplarisch abgehandelt werden um mögliche Lösungsansätze aufzuzeigen. Daher wurde auch das Szenario für den Portaldemonstrator so ausgelegt, dass das Portal in eine bestehende heterogene IT Landschaft einzupassen ist.

Es wurde davon ausgegangen, dass bereits ein Einkaufssystem sowie auch ein ContentManagement-System (CMS) besteht. Dieses sind voneinander unabhängige Applikationen. Als Einkaufssystem wurde Intershop Enfinity gewählt. Dieses Java basierende System bietet zahlreiche Konfigurations- und Erweiterungsmöglichkeiten. Das CMS wurde auf Basis des Open Source Frameworks Zope erstellt. Als WWS fungiert das in gross- und mittelständischen Unternehmen weit verbreitete SAP R/3.

Bestandteil dieser Arbeit ist die Integration von Enfinity in das Portal mit der Vorgabe, das Einkaufssystem auch gleichzeitig ohne das Portal direkt aufrufen zu können. Bestellungen werden von Enfinity an das Warenwirtschaftssystem weitergeleitet. Informationenüber mögliche Produktkonfigurationen werden von dort abgerufen. Die Produktinformationen sollten noch durch zusätzliche Informationen, wie Anwendungsbeispiele oder Marketingtexte aus dem CMS ergänzt werden. Dieses erfolgte in Zusammenarbeit mit Erik Müller, welcher parallel eine Diplomarbeitüber die Integration des CMS in das Portal bearbeitete.

Bereits im Vorfeld wurde, durch die Planungen für das Festool Geschäftskunden Portal, die Oracle Portal-Server Oracle9iAS Portal ausgewählt. Der Server ist ein leistungsstarkes Portalframework mit zugehörigem Web-Server, Application-Server, Single-Sign-On-Server und darunter liegender Oracle9i Datenbank als Portal-Repository.

In folgendem Schaubild sind die verschiedenen Komponenten des Portaldemonstrators und ihre Interaktion untereinander abgebildet. Dabei sind die rot markierten Kommunikationswege für diese Arbeit relevant. Der eingerahmte Teil bezeichnet den Anteil dieser Arbeit am gesamten Demonstrator.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 02: Komponenten des Portaldemonstrators

Die Entwicklungsarbeiten wurden unter Verwendung von Java und der Portal-API (Application Programming Interface) durchgeführt. Die Vorlagen für die Seitengenerierung in Enfinity wurden mit der von Intershop entwickelten Intershop Markup Lanuage (ISML) erstellt. Die Kommunikation mit dem SAP System erfolgt mittels Web Services. Diese basieren auf den Protokollen Hyper Text Transfer Protocol (HTTP)³ und Simple Object Access Protocol (SOAP)⁴ welches auf XML⁵ aufsetzt.

2.2 Anforderungen von Festool an das Portal

TTS Tooltechnic Systems AG & Co. KG ist eine mit rund 1700 Mitarbeitern international agierende Unternehmensgruppe, unter deren Dach die Marken Festool, Protool und Tanos in weltweit 20 Ländern auftreten⁶.

Festool produziert hochwertige Elektrowerkzeuge für den professionellen Einsatz in der Handwerkerbranche. Diese werden in Deutschland ausschliesslichüber autorisierte Fachhändler vertrieben. Festtool hat keinen direkten Verkauf an Endkunden. Die Kunden informieren sich jedoch in zunehmendem Masse, neben dem Fachhandel, auchüber die neuen Medien. Das Festool Portal soll sowohl der Allgemeinheit Informationenüber die Festool Produkte liefern, als auch für Fachhändler die Möglichkeit bieten mit Festool zu interagieren. Der Katalog des Einkaufssystems liefert der Allgemeinheit Produktinformation, jedoch ohne Bestellmöglichkeiten zur Verfügung zu stellen. Angemeldete Fachhändler können ihre Bestellungenüber das Portal abwickeln. Für die drei unterschiedlichen Nutzergruppen (Endkunden, Fachhändler, Festool) waren verschiedene Ziele zu erfüllen.

Das Portal soll die Endkunden enger an die Marke Festool binden. Das erfolgt zum einenüber detaillierte Produktdaten aus dem Einkaufssystem, wie auch Anwendungsbeispiele und allgemeine Unternehmensinformationen aus dem CMS System. Den Fachhändlern wird eine einfache Bestellungüber das Portal ermöglicht. Damit werden sie bei der Abwicklung von Bestellungen entlastet. Die Bestellungen sollen ohne Zeitverzögerung in das Warenwirtschaftssystem eingebucht werden. Damit verringert sich die Zeit zwischen Bestellung und Warenlieferung.

Für Festool soll durch das Portal die Erfassung von Händlerbestellungen automatisiert und damit eine Zeitersparnis und Kostensenkung realisiert werden. Das Portal vermeidet Medienbrüche, die Bestellungen werden direkt an das Warenwirtschaftssystem weitergereicht. Damit werden die Verwaltungskosten gesenkt.

Festool vertreibt hochwertige Elektrowerkzeugsysteme. Diese bestehen aus einer Vielzahl von Komponenten und Ausstattungsvarianten. Diese können in bestimmter Weise miteinander kombiniert werden. Um die Auswahl verschiedener Varianten eines Produkts zu erleichtern, ist zusätzlich zum Einkaufssystem ein Konfigurator zu erstellen. Das EKS besitzt nur Informationenüber die Grundprodukte. Der Konfigurator ist in der Lage diese Produkte entsprechend zu konfigurieren. Die dazu nötigen Informationen bekommt er vom Warenwirtschaftssystem mittels Web Services geliefert.

Anhand der folgenden Grafiken wird beispielhaft die Einsparung der manuellen Schritte bei einer Bestellung verdeutlicht werden. Jeder Farbenwechsel symbolisiert einen Medienbruch. Bei der konventionellen Bestellungüber ein FAX fallen sowohl beim Händler als auch bei Festool eine Menge an manuellen Arbeitsschritten an. Zuerst schreibt der Händler einen Auftrag. Dieser wird dann mittels Faxgerät an Festool versendet. Der Sachbearbeiter bei Festtool liest das Fax,öffnet dann das Warenwirtschaftssystem, sucht den betreffenden Kunde und gibt die Bestellung ein. Dieses Procedere ist zeitintensiv und birgt Fehlerquellen. Anschliessend wird eine Bestätigung für den Händler mit einem Liefertermin geschrieben und an diesen versendet.

Zwischen Beginn und Ende der Prozesskette können je nach Auslastung des Sachbearbeiters mehrere Arbeitstage vergehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 03: Konventionelle Bestellungüber Fax

Im Vergleich dazu werden in der nächsten Abbildung die manuellen Schritte bei der Abwicklung einer Bestellungüber das Portal dargestellt. Nach der Anmeldung am Portal gibt der Händler seine Bestellung ein. Diese wird automatisch an das Warenwirtschaftssystem von Festool weitergeleitet. Medienbrüche werden vermieden, auf der Festool Seite sind gar keine manuellen Schritte durchzuführen, die Bearbeitung erfolgt automatisch. Ein weiterer Vorteil ist die ständige Verfügbarkeit des Systems. Der Händler ist an keine Geschäftszeiten gebunden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 04: Bestellungüber Portal

3 Definition und Klassifizierung von Portalen

In diesem Abschnitt wird eine allgemeine Definition für den Begriff „Portal“ erarbeitet. Danach wird einÜberblicküber dessen Klassifikation undüber die verschiedenen Portalarten im Unternehmensumfeld gegeben.

3.1 Definitionen von Portalen

Der Begriff Portal wird in der IT-Branche bereits seit einigen Jahren diskutiert. Eine eindeutige wissenschaftliche Definition findet man in der gegenwärtigen Fachliteratur allerdings nicht. Der Begriff Portal stammt aus dem lateinischen (porta, lat. Tor, Pforte) und beschreibt laut Duden ein prunkvolles Tor, Pforte oder grosser Eingang⁷. Laut dieser Beschreibung bietet ein Portal in der IT-Branche einen grossen Eingang zu mehreren, u.U. verschiedenartigen Informationsangeboten. Ursprünglich wurde der Begriff mit den Internetsuchmaschinen und Webverzeichnissen wie Yahoo! und Lycos assoziiert. Portale sind aber nicht nur auf das Internet und die Erfassung von dessen Inhalten beschränkt. Unternehmen entwickeln immer mehr geschlossene firmeninterne Plattformen, welche einen zentralen Zugriff auf unternehmensrelevante Anwendungen bereitstellen.

Darüber hinaus ermöglichen diese Plattformen ein gemeinsames, verteiltes Arbeiten (E- Collaboration) innerhalb heterogener Arbeitsgruppen und die Abbildung von Prozessen im Unternehmen⁸. Dataquest⁹ gibt folgende Definition: „Das ideale Portal eröffnet einen gemeinsamen, personalisierten Zugang zu Daten, Expertisen und Anwendungen.“ Auch Saha¹⁰ gibt diese Definition: „A portal is a single integrated point of comprehensive, ubiquitous, and useful access to information (data), applications, and people.“ Aus diesen zwei Definitionen lassen sich die typischen Merkmale von Portalen erkennen: verschiedene Informationskanäle, zentraler Zugang und Personalisierung. Das Portal selbst ist dabei nur der funktionelle Rahmen, der den Zugang zu den einzelnen Anwendungen in einer gemeinsamen integrierten Schnittstelle zusammenfasst. Die Personalisierung ist ein wesentliches Kriterium um eine normale Website von einem Portal zu unterscheiden und „wird häufig als der charakterisierende Aspekt eines Portals angeführt.¹¹ “ Erst wenn eine Website vom Benutzer auf irgendeine Weise personalisiert werden kann, sowie Prozesse bedarfsgerecht bereitgestellt werden, kann sie als Portal bezeichnet werden¹².

Zusammenfassend kann man also eine allgemeine Begriffsbestimmung ableiten:

Ein Portal ist eine eine Applikation, welche basierend auf Web-Technologien, einen zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerecht auf Prozesse bereitstellt. Die Personalisierung beinhaltet die zielgruppen- und nutzerspezifische Anpassung der Inhalte und Struktur des Portals.

Die Abbildung 05 zeigt eine derartige Portalseite, bestehend aus abgegrenzten Bereichen, welche die verschiedenen Inhalte und Funktionen aus den unterschiedlichen Quellen anzeigen. Sofern sich der Portal Besucher angemeldet hat, wird er mit Namen oder seiner Login-Kennung begrüsst (oben rechts in der Abbildung).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 05: Beispiel einer Portalseite

3.2 Klassifizierung - vertikale und horizontale Portale

Eine eindeutige undübereinstimmende Klassifizierung von Portalen lässt sich, wie bei der Definition, nur schwer finden. Es können verschiedene Kriterien zur Klassifizierung herangezogen werden, die eine grosse Menge an Bezeichnungen zulassen, welche oft nur durch Nuancen differenziert werden können. Portale lassen sich nach der angesprochenen Zielgruppe oder dem Detaillierungsgrad der Informationen unterscheiden. Häufig wird jedoch eine Unterteilung nach vertikalen und horizontalen Portalen vorgenommen. Horizontale Portale wenden sich an eine sehr breite Nutzerschicht. Sie umfassen ein weit gefächertes Spektrum an Informationsangeboten und Themengebieten, ohne Teilbereiche in der Tiefe abzudecken. Der Zweck solcher Portale ist es, den Benutzern einen erleichterten Einstieg ins Internet zu bieten. Beispiele für horizontale Portale sind Yahoo!, AOL oder Web.de.

Ein vertikales Portal hingegen hat einen begrenzten, spezifischen Fokus und beschäftigt sich nur mit einer bestimmten Thematik, sozusagen einem Segment des horizontalen Angebotes. Dabei deckt es die gesamte Tiefe der Thematik ab. Vertikale Portale wenden sich daher an eine eng definierte Zielgruppe, beispielsweise an eine Branche, und bieten für diese ein themenspezifisch zusammengefasstes Angebot der Informationen. Ein Beispiel wäre das Branchenportal Werkzeugforum.de.

3.3 Typen von Unternehmensportalen

Bei Unternehmensportalen handelt es sich um vertikale Portale. Sie stellen das Unternehmen in den Mittelpunkt der Betrachtungen und konzentrieren sich auf ein bestimmtes Unternehmen. Sie untergliedern sich abhängig von ihrer Zielgruppe und damit von den angebotenen Inhalten und Prozessen, sowie den abzubildenden Beziehungen in Mitarbeiter- Lieferanten und Geschäftskundenportale¹³. Die Unternehmensportale decken hauptsächlich Funktionen und Prozesse des E-Business und der Unternehmenskommunikation ab¹⁴.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 06: Klassifikation von Unternehmensportalen

3.3.1 Mitarbeiterportale

Mitarbeiterportale (engl.: Enterprise- bzw. Corporate-Portals) stellen die zentrale Plattform, bzw. den zentralen Einstiegspunkt, für Mitarbeiter eines Unternehmens dar und bilden den Kern des Intranets. Sie bieten Zugriff auf Informationen und Applikationen des Unternehmens. Jeder Mitarbeiter hat seine personalisierte Eingangsseite die seinen Bedürfnissen abgepasst wird. Damit werden für den jeweiligen Mitarbeiter Informationen angeboten, die nur für ihn relevant sind. Ein Sicherheitskonzept mit Rollen und Rechten filtert zudem die Applikationen und Funktionen, für die der betreffende Mitarbeiter Zugang erhält. Ausser den internen Informationen, die das Unternehmen betreffen, können auch Daten aus Quellen ausserhalb des Unternehmens bezogen und dem personalisierten Angebot hinzugefügt werden. Dem Mitarbeiter bietet sich so ein effizienter Einstieg in das Unternehmensnetzwerk und dessen Informationen. Darüber hinaus besteht die Möglichkeit der Zusammenarbeit und Entscheidungsfindung der Mitarbeiter untereinander, sowie die Durchführung von geschäftsrelevanten Prozessen.

3.3.2 Geschäftskunden- und Lieferantenportale

Businessportale werden zwischen Unternehmen eingesetzt, um den Geschäfts- und Datenverkehr anforderungsgerecht zu unterstützen. Sie untergliedern sich weiter, gemäss ihrer Ausrichtung zur Bedienung der Zielgruppe, in Geschäftskundenportale und Lieferantenportale. Die Zielgruppe, die durch ein Geschäftskundenportal bedient wird, sind Geschäftspartner und Geschäftskunden, z.B. Fachhändler.Über ein solches Portal können Unternehmen Geschäfte mit Partnern und Geschäftskunden abwickeln. Aber nicht nur die Auswahl und der Kauf von Produkten werden ermöglicht, sondern auch Dienste im Bereich After-Sales-Service (z.B. Support und Bestellung von Ersatzteilen) werden angeboten. Auch umfasst das Portal die Bereitstellung von Applikationen und Prozessen für die Nutzung durch Geschäftskunden und -partner um die Beziehungen umfassend zu unterstützen. Ebenso stellen Geschäftskundenportale ein Informationsangebot bereit. Auf diese Weise können beispielsweise Nachrichten und Finanzinformationenüber das Unternehmen abgerufen werden.

Das Lieferantenportal ist dem Geschäftskundenportalähnlich, jedoch unterstützt es die geschäftsbezogenen, zwischenbetrieblichen Beziehungen zu Lieferanten anstatt zu Geschäftskunden.

3.4 Endkundenportale

Endkundenportale, auch Consumer-Portal genannt, sind ausgerichtet, um die Beziehung zwischen Unternehmen und Endverbrauchern anforderungsgerecht zu unterstützen. In erster Linie dient es dem Abwickeln von Kundengeschäften und der Bereitstellung von Produktinformationen, sowie Dienstleistungen, die das Unternehmen anbietet. Auch diese Art eines Portals bietet oftmals die Möglichkeit einer Personalisierung. Dieses dient zur Kundenbindung und zum Sammeln von relevanten Informationenüber den Kunden.

3.5 Abgrenzung zum Marktplatz

Im Gegensatz zu den Portalen, die informationsorientiert arbeiten, haben Elektronische Marktplätze einen transaktionsorientierten Charakter.Überschneidungen in manchen Bereichen sind vorhanden, jedoch stehen bei Marktplätzen der Handel zwischen Käufern und Verkäufern und die Abwicklung von Transaktionen im Vordergrund. Ein Rollen- Management oder die Personalisierung fehlen meist. Marktplatzanwendungen dienen vorwiegend der Materialbeschaffung, es werdenüberwiegend wenig beratungsintensive Güter gehandelt. Mittels der Beschaffungüber einen virtuellen Marktplatz können Unternehmen ihre Kosten senken und Prozessabläufe optimieren. Die als modulare Portallösungen verfügbaren Einkaufssysteme weisen eine 1:n Beziehung, die E- Procurement-Systeme eine n:1 Beziehung auf. Im Gegensatz dazu haben Marktplätze das typische Charakteristikum, von einer Vielzahl von Unternehmen (Anbieter und Kunden) genutzt zu werden (n:n Beziehung).

Wie bei Portalen und anderen Anwendungsplattformen, besteht auch bei Marktplätzen die Definition vertikaler und horizontaler Ausrichtungen. Auf vertikalen Marktplätzen werden Unternehmen (Käufer und Verkäufer) meist branchenspezifisch miteinander vernetzt mit dem Ziel, Beschaffungsprozesse zwischen den Unternehmen zu optimieren; so reicht eine Vernetzung sogar bis in die Backend-Systeme hinein. Horizontale Marktplätze sind hingegen branchenübergreifend und bieten eher ein breites Angebotsspektrum als tief greifende Prozessintegration.

4 Funktionen von Portal-Software

Im Folgenden werden funktionale Anforderungen an Portal-Software betrachtet. Dabei wird zwischen Grundfunktionen, die ein Portal mitbringen sollte, und erweiterten Funktionen unterschieden. Nicht alle Aspekte werden von jeder Portal-Software unterstützt und können je nach Softwarehersteller variieren. So können einzelne erweiterte Funktionen bereits in die Portalsoftware integriert sein oder durch externe Komponenten bereitgestellt werden.

Abbildung 07¹⁵ zeigt ein Referenzmodell des Fraunhofer IAO Institutes, das den technischen Rahmen eines Portals skizziert. Es zeigt die verschiedenen Typen von Portalen im Unternehmens-Bereich sowie ihre Funktionsbausteine und Aspekte der Anwendungsintegration in einer Schichtenarchitektur.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 07: Fraunhofer IAO Referenzmodell

4.1 Grundfunktionen

Aufgrund der vielen verschiedenen Ausprägungen von Portalen ist keine vollständige Aufzählung aller Anforderungen möglich. Es werden hier nur die wesentlichen Funktionalitäten beschrieben, die ein Portal typischerweise charakterisieren. Hierbei handelt es sich um Benutzer-Management, Personalisierung, Single-Sign-On, ContentManagement, Layout- und Struktur-Management, Suche¹⁶.

4.1.1 Benutzer-Management

Das Benutzer-Management beinhaltet die Benutzer- und Rollenverwaltung im Portal und in den Backend-Systemen. Die Rollen basierte Zugriffssteuerung ermöglicht, dass massgeschneiderte Inhalte und Geschäftsprozesse im Portal zielgruppengerecht zur Verfügung gestellt werden.

Die Benutzerverwaltungübernimmt dabei sämtliche Aufgaben, die mit dem Anlegen,Ändern und Sperren von Benutzerkonten zusammenhängen. Die Rollenverwaltung hingegen legt fest, auf welche Systeme, Anwendungen und Informationen der Benutzer Zugriff haben darf und welche ihm im Portal angezeigt werden¹⁷.

Mögliche Rollen sind beispielsweise Mitarbeiter, Lieferanten, Kunden, Partner oder die anonyme Öffentlichkeit. Jede Rolle besitzt unterschiedliche Rechte, die von der Benutzerverwaltung definiert wird. Die Benutzerdaten werden entweder in der eigenen Datenbank des Portals gespeichert, oder, wie in den meisten Fällen, in externen Verzeichnisdiensten. Hierfür setzt sich als Standard immer mehr das Lightweight Access Protocol (LDAP) durch, welches in die Benutzerverwaltung des Portals integriert werden kann¹⁸.

4.1.2 Personalisierung

Die Personalisierungsfunktionen erlauben die Anpassung des Unternehmensportals an die Anforderungen des Anwenders im Rahmen seiner Berechtigung. Dabei wird zwischen einer expliziten und einer impliziten Personalisierung unterschieden. Die explizite Personalisierung basiert auf Konfigurationswünschen der Benutzer. Sie können das Portal nach ihren persönlichen Vorlieben personalisieren. Bei Unternehmen mit vielen Beschäftigten, unterschiedlichen Mitarbeiteranforderungen und variantenreichen Aufgaben sorgt ein personalisiertes Informationsangebot dafür, dass jeder Anwender genau die Informationen erhält, die er benötigt und auch tatsächlich haben möchte.

Bei der impliziten Personalisierung kann der Benutzer keinen Einfluss auf die Art der Personalisierung nehmen, da sie ohne die Kenntnis des Benutzers geschieht. Diese Art der Personalisierung spielt bei Mitarbeiterportalen keine tragende Rolle, dafür aber umso mehr bei Kundenportalen, da eine gezielte Interaktion mit dem Kunden in den Bereichen Verkauf, Marketing und Kundendienst erreicht wird.Über das Benutzerverhalten des Kunden undüber die Auswertung vorhandener Profilinformationen werden automatisch Rückschlüsse auf die Interessen gezogen und die entsprechenden Informationen personalisiert zur Verfügung gestellt¹⁹. Je heterogener die Kundenstruktur und je diversifizierter das Produktportfolio, desto sinnvoller ist die Personalisierung. Der Prozess lässt sich in drei Phasen unterteilen: Informationsgewinnung, Informationsanalyse und die eigentliche Personalisierung (siehe Abbildung 08).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 08: Der Personalisierungsprozess

4.1.3 Single-Sign-On

Über das Single-Sign-On (SSO) Verfahren können Benutzer mit einer einmaligen Anmeldung an einem Portal auf alle Informationen, Applikationen und Dienstleistungen im Unternehmen zugreifen, für die sie die Berechtigung haben. Sie müssen sich nicht an jedem aufgerufenen System separat authentifizieren und eine Vielzahl von Passwörtern merken.

Das Ziel von Single-Sign-On ist, die Produktivität bei der Nutzung von Portalen zu steigern, indem der Zeitaufwand für die Eingabe von Zugangsdaten für die Anwendungen reduziert und zudem das Problem der vergessenen Passwörter minimiert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 09: Single-Sign-On

Sicherheitstechnisch hat diese Methode jedoch auch seine Nachteile. Werden die Anmeldedaten zu dem Portal einem unbefugten Benutzer bekannt, so kann sich dieser unter Umständen Zugang zu allen im Portal befindlichen Diensten verschaffen.

4.1.4 Content-Management

Das Content-Management (CM) und der Zugriff auf Informationen aus unterschiedlichen Quellen ist eine zentrale Funktion eines Portals. Web-Content-Management, also das Verwalten von Web-Inhalten und Dokumenten, wird notwendig, wenn grössere Informationsmengen nicht mehr manuellüber einen Webmaster eingepflegt werden können²⁰. Die Portal-Software stellt meistens nur eine grundlegende Verwaltung von Content als Basisfunktionalität, um das Zusammenspiel von Content-Autor und Webmaster zu unterstützen.

Bei umfangreicheren Anforderungen kann ein Content-Management System als erweiterte Funktionalität integriert werden. Ein CMS trennt den Inhalt vom Layout, somit können Content-Autoren unabhängig vom Web Designer Inhalte direkt in ein Portal einpflegen, ohne umfangreiche HTML²¹ -Kenntnisse zu besitzen. Des Weiteren wird durch das CMS der gesamte Lebenszyklus von Inhalten unterstützt. Dieser Prozess umfasst die Erstellung des Contents, Freigabeprozesse bis hin zur Publikation, sowie denÜberarbeitungs- und Archivierungsprozess. Weitere wichtige CMS Dienste sind das Strukturieren von Inhalten, ein Versions-Management um die Konsistenz der publizierten Inhalte zu sichern und der Austausch von Content, ein anderer Begriff hierfür ist Content Syndication²². Mittels Content Syndication werden Inhalte aus anderen Quellen bezogen, bzw. für andere bereitgestellt. Ein prägnantes Element eines CMS ist das Metadaten-Management. Metadaten sind Datenüber Daten, mittels derer Inhalte klassifiziert werden können und damit auch weitere Funktionen eines Portals unterstützt werden, wie die Suche, die Navigation und die Personalisierung²³.

4.1.5 Layout-Management

Das Layout-Management erlaubt die Anpassung der Portal Software an die visuellen Anforderungen des Unternehmens und der Benutzer. Das Design des Portals kann mit den Administrationswerkzeugen der Portalanbieter gemäss der Corporate Identity gestaltet werden. Des Weiteren kann das Layout und Rendern²⁴ der einzelnen Portalseiten aus verschiedenen Datenquellen vorgenommen werden²⁵. Zur Optimierung der persönlichen Arbeitsweise kann die Anzeige und Anordnung der einzelnen Informationsbausteine beliebig bestimmt werden.

4.1.6 Struktur-Management

Durch das Struktur-Management wird der strukturelle Aufbau der Portalseiten verwaltet. Der Aufbau wird entsprechend der Rolle und den Aufgaben des Benutzers festgelegt. Insbesondere definiert es den Ort im Portal, an welchem die Anwendungen platziert werden. Aufgabe ist es auch festzulegen welche Anwendungen fest definiert oder optional durch den Benutzer verschiebbar sind²⁶.

4.1.7 Suche

Suchfunktionalitäten im Portal ermöglichen es dem Nutzer relevante und nützliche Informationen innerhalb der grossen Informationsmenge, die ein Portal beinhaltet, herauszufiltern. Dabei ist es wichtig, dass der gesamte Datenbestand im Portal, sowie eingebundene externe Inhalte in die Suche miteinbezogen werden, insbesondere wenn verschiedene Informationsquellen integriert werden²⁷. Auch sollte es möglich sein Suchkriterien zu kombinieren²⁸. Es existieren verschiedene Suchtechniken um gewünschte Informationen aus einer grossen Datenmenge zu gewinnen. Oft verwendete Suchverfahren sind die Volltextsuche oder die Attribut-Suche.

4.2 Erweiterte Funktionalitäten

Neben den Basisfunktionen können zusätzliche Funktionalitäten, je nach Anforderungen des Unternehmens, ins Portal integriert werden. Diese sind im Wesentlichen Content- und Dokumenten-Verwaltungssysteme, Kommunikation und Community, Einkaufssysteme, Collaborative Work und Workflow-Management. Wie eingangs erwähnt, variieren je nach Portalanbieter die bereits ins Portal integrierte Systeme und Funktionen. Das Dokumenten-Management umfasst alle Phasen des Dokumentenlebenszyklus, von der Erstellung, bzw. Empfang, bis hin zur Archivierung und Löschung. Diese traditionellen Aufgaben der Dokumenten-Management Systeme (DMS) und CMS wachsen heute meistens zusammen, so dass die traditionellen Aufgaben des DMS häufig bereits von einem CMSübernommen werden.

Zur Intensivierung der Beziehungen zu Mitarbeitern, Partnern, Kunden oder Lieferanten spielt die Kommunikation eine wesentliche Rolle. Mit Rundschreiben können die Unternehmen und ihre Produkte beim Kunden präsentiert werden. Darüber hinaus ermöglichen Chat-Systeme eine Echtzeit-Kommunikation, welche die Zusammenarbeit und gemeinsame Problemlösungen fördern kann.

Einkaufsprozesse und die Produktdarstellung in Katalogen werden durch Einkaufssysteme bereitgestellt. Dazu zählen Funktionen wie das Ablegen von Produkten in einem Warenkorb, Bereitstellen einer Bestellhistorie oder die Berechnung von kundenindividuellen Preisen. Im Idealfall wird der gesamte Einkaufsprozess abgebildet, vom Auswählen der Ware bis zum Bezahlen und Versand der Produkte. Die Leistungen eines EKS werden in der Regelüber Fremdprodukte in das Portal integriert.

E-Collaboration fördert die elektronische Zusammenarbeit innerhalb verschiedener Nutzergruppen. Dabei kommt zum Beispiel die Ressourcenverwaltung, gemeinsam nutzbare Datenbanken und Gruppenterminkalender zum Einsatz. Des Weiteren wird eine gemeinsame Abwicklung konstruktiver und entwicklungstechnischer Vorgänge durch die Bereitstellung von CAD-Zeichnungen, technischen Dokumentationen, sowie Lastenhefen ermöglicht²⁹.

Workflow-Management-Systeme dienen zur Automatisierung von Geschäftsprozessen im Unternehmen. Diese sind oftmals bereits in der unternehmensweiten Anwendungslandschaft vorhanden und werden im Zuge der Portaleinführung in das Portal integriert.

Die Prozessunterstützung gewinnt zunehmend an Bedeutung. Es können sowohl interne Unternehmensprozesse als auch zwischenbetriebliche Geschäftsprozesse im Portal abgebildet und damit eine Durchgängigkeit der Prozesse erreicht werden. Ziel ist dabei die Reduzierung der Prozesskosten, sowie die Verringerung der Durchlaufzeiten³⁰.

5 Aufbau von Portalen

Eine Portal-Software bietet den technischen Rahmen für die Realisierung internetbasierter Anwendungen³¹. Dabei werden viele unterschiedliche Technologien eingesetzt. Im Folgenden soll der Aufbau einer solchen Portal-Software aufgezeigt werden. Dazu wird zunächst eine allgemeine Portal-Architektur entworfen und anhand derer die Bestandteile von Portalsystemen erläutert. Abschliessend werden Beispielarchitekturen aus der Praxis vorgestellt, in denen man die zuvor erarbeitete allgemeine Portal-Architektur wiederfinden kann.

5.1 Allgemeine Portal-Architektur

Ein Portal ist technisch gesehen kein monolithisches System, sondern basiert auf verschiedenen Technologien und Diensten. Die Kern-Bestandteile eines Portals sind Web-Server, Application-Server und die Integration der Backend-Systeme des Unternehmens³². Die Portal-Software läuft im Application-Server und realisiert die eigentlichen Portalfunktionalitäten.

Die in Abbildung 10 dargestellte Portal-Architektur³³ basiert auf der klassischen 3-Tier- Architektur webbasierter Anwendungen. Eine solche Architektur beschreibt eine inhaltlich- technische Gliederung von Software-Bausteinen in drei Schichten (engl.: Tiers) auf eigenen Rechnern und erhöht dadurch die Skalierbarkeit. Die oberste Schicht bildet die Präsentationsschicht, auf ihr erfolgt die Darstellung der Information. Die Geschäftslogik, bzw. Anwendungslogik, befindet sich auf der mittleren Schicht (engl.: Middleware) und andere Ressourcen, wie Datenbanken auf der unteren Schicht³⁴ (engl.: Backend). In der Regel entspricht ein Portal dieser grundlegenden 3-schichtigen Architektur. Im Folgenden werden die in Abbildung 10 dargestellten Bestandteile eines Portals näher diskutiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Allgemeine Portalarchitektur

5.1.1 Präsentationsdienste

Ein Portal wird durch verschiedene Präsentationsdienste unterstützt. Clientseitig werden in der Regel die Informationen eines Portals in einem Webbrowser betrachtet, ein zusätzlicher Software-Client entfällt. Dabei wird die Darstellung mittels HTML beschrieben. Darüber hinaus gibt es noch andere Clients mit bestimmten Eigenheiten die eine angepasste Aufbereitung der Informationen erfordern. Um beispielsweise Informationen auf Geräten mit kleinem Display darzustellen wurde WAP (Wireless Application Protocol) entwickelt. Die Unterstützung unterschiedlicher Endgeräte wird auch „Multi-Channel Delivery“ (MCD)³⁵ genannt.

[...]

---

¹ Als Backend-Systeme werdenüberwiegend Systeme bezeichnet, die ein Teil einer Server-Struktur sind und Frontend-Dienste mit Daten oder Funktionen unterstützen.

² siehe. Kapitel 4.1.3

³ [W3C HTTP 1999]

⁴ siehe auch Kapitel 8.1

⁵ XML: Extensible Markup Language. Eine vom w3c Consortium erarbeitetes Format um Daten zu strukturieren (siehe http://www.w3.org/XML/).

⁶ vgl. [Festool 2003]

⁷ Der Duden, Band 5 Fremdwörterbuch

⁸ vgl. [Bullinger 2002]

⁹ Zitat in [Schweizer 2001]

¹⁰ vgl. [Saha 1999]

¹¹ vgl. [Rütschlin 2001]

¹² vgl. [Frenko 2001]

¹³ vgl. [Hinderer 2003]

¹⁴ vgl. [Bauer 2001], S.34

¹⁵ vgl. [Bullinger 2002]

¹⁶ vgl. [Gurzki 2002]

¹⁷ vgl. [Zwerger 2002], S.128ff

¹⁸ vgl. [Merz 2002], S.305

¹⁹ vgl. [Merz 2002], S.305ff

²⁰ vgl. [Zschau 2001], S.60

²¹ HTML: Hyper Text Markup Language, Seitenbeschreibungssprache des World Wide Web, siehe auch http://www.w3.org/MarkUp/

²² vgl. [Bullinger 2002], S25

²³ vgl. [Hildreth 2002]

²⁴ Der Begriff Rendern bedeutet das Generieren oder die Zusammenstellung einer visuellen Präsentation. In diesem Zusammenhang wird auch oft der Begriff Rendering verwendet.

²⁵ vgl. [Gurzki 2002]

²⁶ vgl. [Gurzki 2002]

²⁷ vgl. [Saha 1999]

²⁸ vgl. [Schweizer 2001]

²⁹ vgl. [Bullinger 2002], S.28

³⁰ vgl. [Abbaxx 2003

³¹ vgl. [Gurzki 2002]

³² vgl. [Bullinger 2002], S.20f.

³³ Basis bildet der Seminar-Workshop Portal Anwendungen an den Stuttgarter E-Business Tagen 2002, 19.-22. November 2002. Die Referenzarchitektur wurde im Projektteam am Fraunhofer IAT erarbeitet und veröffentlicht in [Gurzki 2003]

³⁴ vgl. [Monson 2001], S.6

³⁵ [Flehmig 2001]