Von Thorsten Gurzki und Joannis Vlachakis*
Die wichtigsten Auswahlkriterien
1. Allgemeine produktspezifische Kriterien
Allgemeine Produktangaben;
Release-Stand;
Release-Wechsel;
Eignung für verschiedene Portaltypen und
Anzahl der bestehenden Installationen.
2. Portalbasisdienste
Content-Management;
Layout- und Struktur-Management;
Rechte- und Benutzerverwaltung;
Suche und
Single-Sign-on.
3. Portalanwendungsmodule
Collaboration;
Groupware;
Workflow-Management;
Dokumenten-Management und
Web-Shop.
4. Weitere Eigenschaften
Unterstützung von Portal-APIs;
Applikations-Server;
Entwicklungsumgebungen;
Datenbanken;
Betriebssysteme;
Lastverteilung;
Integration und EAI;
vorhandene Integration in Backendsysteme sowie Barrierefreiheit und Usability (gemäß Bildschirmarbeitsverordnung Paragraf 20/21, DIN ISO 9241, Grundsätze zur ergonomischen Dialoggestaltung).
Was Sie die Anbieter fragen sollten
- Welchen Schwerpunkt hat die Software (Content-Management/Integration, Integration von Applikationen, Integration und Abbildung von Prozessen)? Oder ist sie ein Allrounder?
- Was leisten Konnektoren und wie einfach ist die Einbindung der Backend-Systeme wirklich?
- Fallen für den Backend-Zugriff zusätzliche Lizenzkosten an (zum Beispiel ERP-Lizenzen)?
- Skaliert die Lösung kostengünstig?
- Wie wird die Ausfallsicherheit gewährleistet?
- Welche Kosten fallen für die Hardware an?
- Welcher personelle Aufwand kommt auf die Fachabteilungen zu?
- Sind weitere Lizenzen für Fremdprodukte (beispielsweise für Applikations-Server) erforderlich?
- Bietet der Anbieter Know-how in der Umsetzung von Geschäftsprozessen?
- Wie flexibel ist eine Anpassung an das firmenspezifische Layout?
- Werden die Vorgaben der Barrierefreiheit und Usability (gemäß Bildschirmarbeitsverordnung Paragraf 20/21, DIN ISO 9241) eingehalten?
- Wie sieht die langfristige Produkt-Roadmap aus?
JSR 168 und WSRP
Das Portlet-API wurde als Java-Standard JSR 168 definiert. Es soll die Austauschbarkeit von sowohl Portalanwendungen als auch der Portalsoftware selbst ermöglichen. Der wesentliche Nachteil des JSR 168 ist die fehlende Kommunikationsmöglichkeit zwischen Portlets. Dieser Mechanismus erlaubt zum Beispiel einem Shop-Portlet, einem Konfigurator-Portlet Informationen über das momentan angezeigte Produkt zukommen zu lassen und dort den Konfigurationsdialog für genau dieses Produkt zu starten. Nicht zuletzt wegen dieser fehlenden Funktionalität setzen die meisten Softwareanbieter neben der Portlet-API auf herstellerspezifische Schnittstellen mit eigenen Namen wie I-Views, I-Lets oder Gadgets. Anwendungen auf dieser Basis bleiben jedoch auf die Produkte der jeweiligen Anbieter beschränkt.
Die Einbindung von Portalanwendungen sollen die Web Services for Remote Portals (WSRP) vereinfachen. WSRP ist ein plattformübergreifender Oasis-Standard, der in Zukunft nicht nur in der Java-Welt zu finden sein wird. WSRP gestattet die Darstellung von Portalanwendungen, die auf externen Servern ablaufen. Die Kommunikation zwischen der Darstellung im Portal und der eigentlichen Anwendung erfolgt über Web-Services. Der Standard ist damit im besonderen Maße auch für die Einbindung von Services externer Dienstleister in ein Unternehmensportal geeignet.
Portale - eine Begriffsbestimmung
Die Aufgaben einer Portalsoftware bestehen darin, Anwendungen in einer Oberfläche zu integrieren. Die Referenzarchitektur für Portalsoftware stellt das typische Funktionsspektrum für Softwareprodukte dar (siehe Abbildung "Referenzarchitektur"). Die grundlegende Struktur eines Portals umfasst die Schichten Präsentation, Anwendungslogik und Backend. Die Präsentationsschicht bedient die Endgeräte mit Portalinhalten. Sie berücksichtigt die Eigenschaften der Zielsysteme, dazu gehören Web-Browser, mobile Endgeräte sowie Einrichtungen für den barrierefreien Zugriff.
Den Kern des Portals bildet die Anwendungslogik. Basis einer Portallösung ist ein Applikations-Server, der grundlegende Funktionen für die Erstellung von Anwendungen und für die Portalsoftware bereitstellt. Diese Server setzen auf Java 2 Enterprise Edition, Microsofts .NET sowie PHP und Coldfusion auf. Der Applikations-Server wird ergänzt durch Transaktions- und Integrationsdienste. Sie binden IT-Systeme und Transaktionsdienste ein, beispielsweise ERP-Systeme oder Content-Repositories.
Ein integrierter Web-Server stellt Portalseiten im HTML- und WAP-Format bereit. Er gestattet ferner den Zugriff über WebDAV. Die Visualisierung von Inhalten erfolgt in virtuellen Fenstern (Portlets), die mit HTML nachgebildet sind.
Basisdienste stellen Funktionen bereit, mit denen Anwender Portale erstellen und betreiben. Hierzu gehören Layout- und Struktur-Management, Content-Management, Rechte- und Benutzerverwaltung, Suche, Prozesssteuerung, Personalisierung und Single-Sign-on. Das Layout-Management erstellt auf Nutzeranfrage Portalseiten aus den einzelnen Anwendungen und gibt sie aus (Rendering). Ferner wird das Erscheinungsbild definiert. Das Struktur-Management legt den strukturellen Aufbau und die Navigation des Portals fest. Dies umfasst insbesondere, wo in der Portalstruktur Anwendungen platziert sind und in welcher Beziehung Portalseiten zueinander stehen.
Portale enthalten vorgefertigte Anwendungsmodule für Web-Shops, Communities, Collaboration-Umgebungen, Groupware sowie Workflow- und Dokumenten-Management. Diese Funktionen können auch individuell entwickelt werden, der Aufwand lohnt sich jedoch selten.
Hier lesen Sie ...
- woraus Portallösungen bestehen;
- nach welchen Kriterien Anwender Portalprodukte auswählen sollten;
- mit welchen Schritten Unternehmen ein Portal einführen können.
Mehr zum Thema,www.computerwoche.de/go/
*79264: IBM vereinheitlicht Websphere-Portale;
*77192: Hummingbird kauft Reddot;
*77553: Finanzministerium setzt auf Abaxx-Portal;
*76875: Vergleich mobiler Plattformen;
*77054: Jboss unterstützt EJB 3.0.
Portale sind als Werkzeug für die Integration von Prozessen, Daten und Anwendungen aus der betrieblichen Systemlandschaft nicht mehr wegzudenken. Allerdings ist es nicht eben einfach, aus der Fülle an Lösungen die geeignete Portalsoftware auszuwählen. Doch nicht nur der Angebotsumfang, sondern auch die Vielfalt an Techniken ist für Unternehmen schwer zu überschauen. Und weil Portale Organisationseinheiten, IT-Systeme und Prozesse integrieren sollen, muss die Lösung zum Unternehmen passen.
Maßgeschneiderter Zugriff
Ein Portal stellt einen Web-basierenden, zentralen Zugriff auf personalisierte Inhalte sowie bedarfsgerechte Prozesse bereit. Abhängig von Zielgruppe, Inhalten und Prozessen unterscheiden Experten zwischen Geschäftskunden-, Lieferanten-, Mitarbeiter- und Endkundenportalen.
Die Auswahl einer Portalsoftware muss Bestandteil einer übergreifenden Methode sein, die das gesamte Vorhaben von der Strategieplanung bis zum Rollout begleitet. Die Unternehmensstrategie für das konkrete Projekt, die organisatorischen Voraussetzungen sowie technischen Gegebenheiten und Anforderungen müssen im Vorfeld der Softwareauswahl erarbeitet beziehungsweise ermittelt werden. Auch die Anbieter- und Softwareauswahl sollte methodisch erfolgen.
Portalspezifisches Phasenmodell
Ein übergreifendes methodisches Vorgehen kann auf einem klassischen Phasenmodell des Software-Engineerings aufbauen, dass die fünf Einzelphasen Strategie, Analyse, Konzeption, Realisierung und Einführung umfasst. Wichtig dabei ist, dass innerhalb der Phasen portalspezifische Aktivitäten durchlaufen werden. Diese können je nach Komplexität und Bedarf des Unternehmens zyklisch wiederholt werden. Die im Folgenden beschriebenen Projektphasen basieren auf der "Portal Analyse und Design Methode" (Padem) des Fraunhofer IAO (Institut für Arbeitswirtschaft und Organisation).
Schritt 1: Strategie
Während der Strategiephase entwickelt das Projektteam eine auf das Unternehmen abgestimmte Portalstrategie. In einem Strategie-Workshop werden Optimierungen in Organisation, Prozessen und Systemen erarbeitet. Davon lässt sich die IT-Unterstützung durch ein Portal ableiten. Ergebnisse dieser Phase liefern konkrete Empfehlungen zu Projektgrößen, Finanzumfang (interne und externe Projektkosten, interner Ressourcenaufwand), organisatorischen Rahmenbedingungen, Zielgruppen, Prozessen und Projekt-Management.
Schritt 2: Analyse
Ausgehend von den Ergebnissen der Strategiephase dokumentiert die Analysephase die identifizierten Organisations- und Prozessbereiche sowie die technischen Rahmenbedingungen für die Portaleinführung (Analyse der Ist-Situation). Dazu müssen die Mitarbeiter sowohl der aus den Fachabteilungen als auch der IT frühzeitig eingebunden werden und die Geschäftsleitung verbindlich hinter dem Projekt stehen. Dies fördert die Akzeptanz durch die Angestellten.
Dabei muss von den im Portal zu realisierenden Anwenderprozessen auf Unternehmensprozesse geschlossen werden. Diese analysiert das Projektteam im Zusammenhang mit der Organisation, Geschäftsdokumenten und Daten sowie der zugrunde liegenden IT-Infrastruktur.
Schritt 3: Anforderungsermittlung
Ausgehend vom Ist-Zustand und der Strategie werden die organisatorischen, prozessbezogenen und technischen Anforderungen erarbeitet und in einem weiteren Arbeitsschritt detailliert. Auf Basis der Mengengerüste, Durchlaufzeiten, des Personal- und Materialaufwands sowie der Ausführungshäufigkeit wird das wirtschaftliche Potenzial der zukünftigen Prozesse ermittelt. Die wirtschaftliche Betrachtung umfasst nur die Nutzenseite, nicht die tatsächlichen Realisierungskosten. Die Ermittlung des wirtschaftlichen Potenzials gestattet bereits in der frühen Analysephase eine detaillierte Aussage über den zu erwartenden Gesamtnutzen und bietet eine Entscheidungsgrundlage für die Auswahl der Portalsoftware und das gesamte Portalprojekt.
Schritt 4: Grobkonzept
Im Grobkonzept werden die Kundenprozesse und die technische Grobstruktur der Architektur definiert. Die Architektur skizziert dabei die Integration von IT-Systemen und liefert Kriterien für die Portalauswahl. Dabei ist es für den Grobentwurf der technischen Systemarchitektur sinnvoll, auf anwendungsbezogene Referenzmodelle zurückzugreifen, die als Grundlage für die effiziente Entwicklung individueller Lösungen dienen (wie etwa die Padem-Referenzarchitektur für Collaboration-Portale). Die Architektur sollte produktneutral auf Basis der Kundenprozesse modelliert werden.
Bereits an dieser Stelle enthält das Konzept idealerweise Rechte- und Rollenmodelle, von denen sich der bedarfsgerechte (personalisierte) Informationszugriff ableitet. Weiterhin sollte das Team den Einsatzbereich sowie den Funktionsumfang der Portalsoftware bestimmen. Daraus ergeben sich zusätzliche Aspekte für die Evaluation von Portalsoftware beziehungsweise Ausschlusskriterien. Natürlich muss das technisch-organisatorische Konzept der Lösung die Ergebnisse der vorangegangenen Phasen (Strategie und Analyse) berücksichtigen.
Schritt 5: Lastenheft
Das Lastenheft ist eine formalisierte Niederschrift der aus dem Grobkonzept resultierenden softwaretechnischen Anforderungen. Es legt auch fest, über welches Know-how der Dienstleister oder Anbieter verfügen muss und wie das Projekt ablaufen soll. Das Team einigt sich, welche Basis- und Integrationsdienste die Software bieten und wie die Lösung skalieren soll. Hierbei lassen sich Ausschlusskriterien für die auszuwählende Software und das erforderliche Budget als Vorgabe bestimmen.
Schritt 6: Anbieterwahl
Da Portallösungen komplex sind, ist oft nicht nur die Auswahl eines Produkts, sondern eines oder gar mehrerer Anbieter für eine Gesamtlösung erforderlich. Unter Berücksichtigung des Lastenhefts und der IT-Strategie des Unternehmens sind zukunftsfähige und investitionssichere Techniken auszuwählen. Beispielsweise ist zu entscheiden, ob die Basis der Portalsoftware J2EE oder .NET sein soll. An dieser Stelle kommen im Haus vorhandene Kompetenzen der Mitarbeiter zum Tragen.
Die Verwendung von Referenzkriterien (siehe Kasten "Die wichtigsten Auswahlkriterien") vereinfacht die Vorauswahl von Anbietern. Dabei helfen auch Marktübersichten. Nach der Eingrenzung auf fünf bis acht Anbieter wählt das Projektteam mittels Lastenheft die Lösung aus.
Hier gilt es, einige Fragen zu klären. Ein wichtiger Punkt ist die angebotene Backend-Integration und ob der Hersteller dazu proprietäre oder standardisierte Schnittstellen vorsieht. Das Softwarehaus muss sich nicht nur mit den einzubindenden Backend-Systemen auskennen, sondern auch die Geschäftsprozesse verstehen und umsetzen können. Ein Anhaltspunkt sind Referenzkunden, die das Team gegebenenfalls kontaktieren kann. Ergebnis der Anbieterwahl sind drei bis vier Firmen.
Schritt 7: Feinkonzept
Mit diesen Anbietern erarbeitet das Portalteam ein Feinkonzept. Dabei werden die Prozesse in der Software abgebildet. Spätestens hier zeigt sich, ob sich die Anbieter in die Herausforderungen des Projekts hineindenken können. Während dieser Phase sollte die Portalsoftware getestet werden. Bei schwierigen Fragen empfiehlt sich eine Machbarkeitsstudie. Die Auftraggeber konfrontieren die Anbieter mit einem Proof of Concept. Die Lösungen können anhand definierter Kriterien bewertet werden.
Schritt 8: Pflichtenheft
An der Pflichtenheftphase können mehrere Anbieter beteiligt sein. Der Auftraggeber holt ein Angebot ein und bewertet das vom Hersteller erstellte Pflichtenheft. Im Portalumfeld können Produkte oder Dienstleistungen Dritter notwendig sein. In diesem Fall empfiehlt es sich, einen Generalunternehmer zu bestimmen. Es sollte seitens Anwender und Anbieter je ein Projektleiter für die gesamte Projektlaufzeit bestellt werden.
Neben den Kosten für Software und Dienstleistungen fallen zeitliche und finanzielle Aufwände in den Fachabteilungen an, die vom Anbieter zu spezifizieren sind. Die Verhandlungen umfassen neben den Lizenzen die notwendigen Anpassungen und Kosten für Portalanwendungen. Auch müssen die Verantwortlichen gegebenenfalls Lizenzen von Drittherstellern zum Beispiel für Applikations-Server berücksichtigen.
Nach Vertragsabschluss sollte sich der Auftraggeber neben dem Management des Projekts auch über ein Einführungskonzept Gedanken machen. Die Ansprache der Zielgruppen und Schulungen beeinflussen den Projekterfolg. (fn)
*Thorsten Gurzki und Joannis Vlachakis sind Projektleiter am Fraunhofer IAO (Institut für Arbeitswirtschaft und Organisation) in Stuttgart.