Die Wahl der richtigen Plattform für ein Unternehmensportal ist nicht einfach. Alle am Markt verfügbaren Produkte decken (laut Datenblatt der Hersteller) zunehmend einen ähnlichen Funktionsumfang ab, Unterschiede sind ohne vertiefte Projekterfahrung kaum auszumachen. Doch sie existieren und entscheiden oft über Erfolg oder Mißerfolg des konkreten Projektes. Denn nicht jedes Produkt passt zu jeder Anforderung. Hier einmal unsere Gedanken und einige kleine Denkanstösse:
Was sind überhaupt meine Anforderungen?
Bevor technische Funktionen verglichen werden, sollte man sich über die konkreten inhaltlichen Anforderungen einmal Gedanken machen. Wo liegen wirklich die Schwerpunkte? In der Prozessabbildung, der Kollaboration oder evtl. in der Darstellung von reinen Informationen und Dokumenten? Gliedern Sie doch einmal Ihre Fachanforderungen in 6 Portal Services:
- Information Services
- Document Services
- Content Distribution Services
- Application Integration Services
- Process Integration Services
- Collaboration Services
Sie werden erstaunt sein, wie deutlich sich hier Schwerpunkte herausbilden. Hier einmal ein Projektbeispiel:
Inhaltsanforderungen gruppiert nach Portal Services
In diesem Fall liegt der Schwerpunkt klar auf Informationen (gelb und orange) und der Integration von Applikationen (blau). Die Abbildung von Prozessen macht nur einen kleinen Teil des Portals aus. Analysiert man jetzt die technologische Grundlage der Informationen Applikationen, kann man einen ersten Hinweis auf eine passende Plattform gewinnen. Eine heterogene Landschaft wird ideal durch offene Standards eingebunden (IBM, Open Source), Applikationen aus dem Microsoft-Umfeld ideal mit MOSS, Reports und Informationen aus SAP und Applikationen mit SAP-Bezug ideal über das SAP Enterprise Portal.
Wie passt das Produkt zur bestehenden IT-Landschaft und dem Skill der Mitarbeiter?
Auch hier zeigen sich deutliche Unterschiede. MOSS erfordert z.B. durch seine Plattform aus .NET-Komponenten und dem MS SQL Server Erfahrung in der Administration und Entwicklung der entsprechenden Module. Eine rein auf Oracle und Java spezialisierte IT-Abteilung wird hier das Know-How mühsam aufbauen müssen. Das SAP Portal hingegen stürzt durch seine Java-Architektur die klassischen SAP-Betriebsabteilungen in tiefes Grübeln. In allen Fällen ist es wichtig, die jeweiligen Betriebshandbücher, Deployment-Prozesse und Support-Wege zu analysieren und zu erweitern.
Fazit aus unseren Projekten
Aus der Vielzahl der Projekte haben wir in unserem Team einmal folgendes Resümee gezogen:
!HInweis: das ist unsere persönliche Einschätzung und ersetzt keine fundierte Bewertung im Rahmen eines projektbezogenen Portal Assessment!
- SAP Enterprise Portal
Zeigt deutliche Stärken in der Integration der SAP Welt, liefert vordefinierten Content aus, hat überzeugendes Rollenkonzept, ist in sich mit den Single Sign On – und KM-Komponenten das kompletteste System.
Zeigt Schwächen beim täglichen Umgang mit Dokumenten (für Anwender komplex zu erlernen), führt zu teuren Projekten, ist komplex zu administrieren
- Microsoft Office SharePoint Server (MOSS)
Ist für den Umgang mit Dokumenten einfach zu bedienen, kann Szenarien weitgehend mit Customizing umsetzen, hat seine Stärken als Plattform für Collaboration und einfache Systemintegration, Projekte sind vergleichsweise schnell und kostengünstig umzusetzen
Erfordert für den vollen Nutzen Office 2007 und eine weitgehend auf Microsoft abgestimmte Landschaft, ist nur für einfache Workflows im Standard zu nutzen, hat nativ keine Lösung für Single Sign On
- IBM WebSphere Portal Server
Unterstützt die Anbindung einer heterogenen Systemlandschaft, ideal für hochperformante Massenszenarien, durch die Konzentration auf Java und Web-Standards durch eine grosse Entwicklergemeinde getragen.
Ist komplex in der Administration und Konfiguration, führt bei Portalen mit signifikanten SAP-Inhalten zu hohen Intgrations- und Entwicklungsaufwänden
- Open Source – Frameworks
Geeignet für schmale Projektbudgets, zeigen oft hohe Performance, integrieren ideal heterogene Systemlandschaften, sind ideal für Spezialportale geeignet
Werden eher durch eine Community und nicht durch einen Hersteller supported, weniger geeignet für komplexe (SAP-)Prozessportale oder dokumentenorientierte Kollaborationslösungen
