2003/8 | Fachbeitrag | Wissensmanagement einführen
Lotus Notes mit Mehrwert in Portale integrieren
Inhaltsübersicht:
- Lotus Notes wird unterschätzt
- Eine typische Notes-Anwendung
- Die Lösung: Portalintegration
- Beispiel: Workplace für Vertriebsmitarbeiter
- Mehrwert durch Datenkombination
- Technische Varianten
- Fazit
Viele Wissensmanagement-Initiativen werden in Zukunft als Portale oder Dynamic Workplaces Gestalt annehmen. Ein Großteil der Arbeit wird darin bestehen, die über die Jahre gewachsenen Anwendungen in das neue Portal zu integrieren. Besonders Lotus-Notes-Anwendungen spielen in vielen Unternehmen eine wichtige Rolle, wird diese Plattform doch schon lange als flexibler Informationsspeicher vielfältig eingesetzt.
Lotus Notes wird unterschätzt
Erste Praxiserfahrungen aus Portalprojekten zeigen, dass Unternehmen die Bedeutung von Lotus-Domino-Anwendungen für ihre Geschäftsprozesse unterschätzen. Ist beim Portalaufbau die Rede von unternehmenskritischen Anwendungen, konzentriert man sich meist auf die großen ERP- oder BI-Systeme. Domino wird häufig auf E-Mail und Kalender reduziert. Die mehreren hundert Notes-Anwendungen mit einer Vielzahl wertvoller Soft Facts werden in ihrer Bedeutung massiv unterschätzt. Eine der möglichen Ursachen dafür: Viele Portalprojekte werden gerade im Pilotstatus von der zentralen Unternehmens-IT durchgeführt. Diese verwaltet und administriert zwar die Domino-Server, kann aber Komplexität und Wichtigkeit der Domino-Anwendungen für den einzelnen Fachanwender schwer beurteilen.
Eine weitere große Herausforderung ist die technische Integration. Denn hier ist es beileibe nicht damit getan, auf die Standard-Webfähigkeit von Notes-Anwendungen zu verweisen und diese per URL-Link in das Portal zu integrieren. Zu Recht fragen die Anwender dann nach dem Nutzen des Portals – zum Anschauen einer Notes-Datenbank im Web reicht der Browser aus. Doch wie kann eine aus Anwendersicht wertschöpfende Integration aussehen, ohne einfach alten Wein in neuen Schläuchen zu servieren? Dieser Problemstellung soll nachfolgend mit verschiedenen Lösungsansätzen begegnet werden.
Was also tun? Wenn schon das eigentliche Wissen nicht immer dokumentiert werden kann, so sollten zumindest Informationen darüber, wer im Unternehmen über solches Wissen verfügt, bereitgestellt werden. Aus diesem Grund versucht man seit einigen Jahren, in Form von Profilen oder Gelben Seiten Meta-Informationen über Mitarbeiter abzulegen und so mehr Transparenz über die im Unternehmen vorhandenen Fähigkeiten und Erfahrungen zu schaffen. Werden diese Informationen nicht nur verwaltet und durchsucht, sondern gibt es darüber hinaus auch noch eine Koordinations- und Planungsinstanz, die diese Daten analysiert und daraus Schulungs-, Einstellungs- oder gar neue Akquisitionsprogramme ableitet, so entsteht eine eigene Management-Disziplin: das Kompetenzmanagement.
Eine typische Notes-Anwendung
Ein Unternehmen nutzt seit mehreren Jahren eine Notes-Anwendung für die Vertriebs- und Projektsteuerung. Die Anwendung ist nicht webfähig und kann nur über den Notes-Client bedient werden. Das System wird bereichsübergreifend eingesetzt und deckt den gesamten Kundenlebenszyklus ab: Das Marketing nutzt das System zur Durchführung von Online-Werbekampagnen, der Vertrieb steuert die Kundenakquisition, die Projektteams wickeln die Dokumentation ihrer Projekte über das System ab. Während des Nutzungszeitraums von mittlerweile vier Jahren wurde die Anwendung funktional stark erweitert. Unterzieht man das aktuelle System einer kritischen Betrachtung, so erkennt man einen Anwendungsmonolith, dessen Möglichkeiten nur wenige Power User ausschöpfen können. Auf alle anderen Mitarbeiter wirkt das komplizierte System zunehmend abschreckend. Die Funktions- und Informationsfülle passt einfach nicht mehr zum persönlichen Arbeitsbild und Wissensbedarf. Hier zeigt sich ein typisches Problem: Die Assets in Form von Informationen sind zwar theoretisch vorhanden, das Zugangswissen ist aber nicht in gleichem Maße mitgewachsen. Wichtige Informationen liegen brach und verlieren über die Zeit ihren Wert.
 |
Klassische Lotus-Notes-Anwendung |
Die Lösung: Portalintegration
Wie kann man dieser Herausforderung begegnen? Einer der Erfolg versprechendsten Lösungsansätze ist die Aufteilung der Anwendung in Teilfunktionalitäten und deren Integration in ein Portal, etwa ein WebSphere- oder SAP-Portal. Eine solche Lösung basiert auf folgenden Paradigmen:
- Personalisierung: Jeder Anwender erhält nur die Daten und Funktionen, die für seine jeweilige Rolle (Vertriebsleiter, Projektmitarbeiter, Vorstandsassistent etc.) relevant sind. Die Informations- und Funktionsfülle wird damit für den Einzelnen reduziert, die Übersichtlichkeit steigt.
- Die Ursprungsanwendung, wie sie oben dargestellt ist, wird nicht verändert. Damit ist sichergestellt, dass Power User weiterhin in ihrem gewohnten Umfeld arbeiten. Sollten kleinere Anpassungen innerhalb des Systems notwendig sein, so betreffen diese lediglich das interne Datenhandling und sind für den Anwender nicht sichtbar.
- Die einzelnen Funktions- und Informationsbausteine werden im Portal durch Mehrwertdienste und kontextbezogene Informationen ergänzt.
Folgt man diesen Leitlinien, so wird schnell klar, dass eine 1:1-Übertragung der Anwendung in den Web-Browser (Web-Enabling) nicht sinnvoll ist. Die beschriebenen Probleme lassen sich durch ein solches Verfahren nicht lösen. Stattdessen wird ein konsequentes Portalizing der Anwendung betrieben: Die Anwendung wird nach User-bezogenen Nutzungsmustern untergliedert, in Teilprozesse zerlegt und in Portlets übertragen.
Das Ergebnis eines solchen Verfahrens für die oben beschriebene Vertriebsanwendung ist in der folgenden Abbildung dargestellt. Insgesamt wurden 8 Anwendergruppen identifiziert, deren Nutzungsverhalten über maximal 21 Portlets abgebildet werden kann. Wie man bei der Betrachtung von Rollen wie Projektleiter oder Projektmitarbeiter erkennt, sind nur rund 20 Prozent der Portlets im Alltag überhaupt relevant; der Rest wird nur in Sonderfällen benötigt.
 |
Portlets und Anwendergruppen |
Beispiel: Workplace für Vertriebsmitarbeiter
Für einen Vertriebsmitarbeiter haben wir in der unten stehenden Abbildung ein mögliches Portal User Interface (PUI) skizziert. Im Portlet 1 sind die an diesem Tag zu erledigenden kundenbezogenen Aufgaben dargestellt. Eine Aktivität ist dabei immer genau einem Kunden zugeordnet. Nach einem Mausklick auf eine Aktivität wird im Portlet 2 die zugehörige Kontakthistorie des Kunden angezeigt. Analog zeigt das Portlet Task Details (3) eine Detailbeschreibung der Aktivität. Alle Informationen dieser drei Portlets stammen direkt aus der Vertriebsanwendung. Ein zusätzlicher Mehrwert für den Anwender entsteht dadurch, dass kontextrelevant zum jeweiligen Kunden aus einer anderen Datenbank (z.B. Marktforschung) Detailinformationen und kundenbezogene News angezeigt werden.
Grundsätzlich gilt: Jedes Portlet erfüllt einen bestimmten Anwendungszeck und kann beliebig mit anderen Portlets auf einem Workplace kombiniert werden. Je nach Art der Zusammenstellung kann ein Portlet auf Ereignisse in einem anderen Portlet reagieren. Die Zusammenstellung der Portlets ist nicht starr festgelegt und kann durch den Anwender jederzeit verändert werden.
 |
Ein Workplace für Vertriebsmitarbeiter |
Mehrwert durch Datenkombination
Im Vertriebsbeispiel wurden in einem Portlet bisher nur Informationen aus einer Datenbank dargestellt. Viele aus Anwendersicht besonders nützliche Portlets können aber nur dann realisiert werden, wenn Daten aus verschiedenen Anwendungen miteinander in einem einzigen Portlet kombiniert werden. Ein Beispiel für ein solches Portlet ist die Suche nach einem bestimmten Mitarbeiter. Grundsätzlich ist dies nichts Besonderes. Mit der gleichzeitigen Integration der Urlaubsdatenbank ist aber – symbolisiert durch eine kleine Palme – direkt erkennbar, ob der Mitarbeiter im Urlaub ist. Zusätzlich wird über eine grüne Sprechblase die Erreichbarkeit des Mitarbeiters über das Online-Chat-System visualisiert. Zwingende Voraussetzung für eine solche Integration ist, dass die Datenquellen über geeignete Schlüssel miteinander kombiniert werden können. Die mangelnde Verknüpfungsfähigkeit der Daten aus verschiedenen Systemen stellt somit eines der größten Hindernisse in Portalprojekten dar.
 |
Mitarbeiter-Portlet mit Urlaubsanzeige und Online-Awareness |
Technische Varianten
Grundsätzlich gibt es im Falle der Portal- und Domino-Integration drei Varianten, wie eine solche Lösung technisch umgesetzt werden kann:
- Nutzung der vom Hersteller mitgelieferten Standard-Portlets für Lotus Notes
- Individuelle Programmierung der benötigten Portlets in Java mit einem geeigneten Entwicklungswerkzeug (etwa dem WebSphere Studio Application Developer)
- Einsatz eines Portlet-Generators oder eines Portlet-Entwicklungswerkzeugs, wie sie von verschiedenen Drittanbietern erhältlich sind
Jede der technischen Varianten hat naturgemäß spezifische Vor- und Nachteile. Als übergeordnete Bewertungskriterien sollen hier die Merkmale Performance/Skalierbarkeit, Funktionsumfang und Systemmanagement herangezogen werden. Die Wichtigkeit des Kriteriums Performance liegt auf der Hand: Die Anwender erwarten auch bei Portalen Reaktionszeiten im Sekundenbereich, andernfalls werden sie das System sehr schnell meiden. Des Weiteren führen Verzögerungen in einem Portlet dazu, dass die gesamte Portal-Seite nicht angezeigt wird. Vor allem in Bezug auf Domino steckt sozusagen der Performance-Teufel im Detail: Mag die Performance des Domino-Servers im Rahmen einer klassischen Notes-Client/Server-Architektur noch ausreichend sein, so kann der Domino-Server bei einem rein serverbasierten Ansatz schnell zum Engpass werden.
Variante 1: Standard-Portlets
Portal-Frameworks wie zum Beispiel das WebSphere-Portal werden mit mehreren Standard-Portlets für verschiedene Notes-Anwendungen ausgeliefert. Neben Portlets für E-Mail, Kalender und Aufgaben wird etwa auch ein konfigurierbares View-Portlet angeboten. Aber kurz gesagt: Das Beispielszenario aus dem Vertrieb ist mit den Standard-Portlets funktional nicht abzubilden. Ein weiteres Problem stellt die Skalierbarkeit dar, da direkt vom Portal auf den Domino-Server zugegriffen wird und es hier bei größeren Anwenderzahlen zu Performance-Problemen kommt. Standard-Portlets eignen sich gut für Test-Installationen und erste Versionen des Portals. Die Abbildung komplexer Workplaces gestaltet sich aber derzeit noch schwierig.
Variante 2: Individualprogrammierung
Das Standardvorgehen für die individuelle Portlet-Entwicklung ist die Programmierung in Java. Unter Benutzung diverser Hilfsmittel ist die Entwicklung von Portlets beherrschbar. Sieht man einmal von der komplexen Erstinstallation ab, so können mit einem Entwicklungsaufwand von zwei bis drei Tagen recht ansehnliche Portlets entstehen. Diese Aussage gilt allerdings nur, wenn der Entwickler bereits über gute Java-Kenntnisse und über Grundkenntnisse der Domino/WebSphere-Anbindung verfügt. Wie für die Standard-Portlets gilt aber auch hier: Die Performance ist unmittelbar abhängig von den als Basis fungierenden Domino-Servern.
Variante 3: Portlet-Generatoren
Eine weitere Alternative bieten so genannte Portlet-Generatoren. Dies sind Systeme, die eine Portlet-Erstellung über Wizards oder einfache Customizing-Anwendungen ohne Java-Kenntnisse ermöglichen. Zurzeit gibt es mehrere solcher Lösungen am Markt, die zum Teil sehr interessante Ansätze verfolgen. Das Produkt Portlet Factory 2.0 der Conet AG speichert zum Beispiel alle Daten der Portlets in einer relationalen Datenbank und kann so deutlich mehr Anwender bedienen. Wer sich im Detail für die Vor- und Nachteile der technischen Varianten interessiert, sei im Falle des WebSphere-Portals auf das IBM Redbook „Portalizing Domino Applications for WebSphere Portal“ verwiesen. Dieses technische Handbuch steht auf den IBM-Webseiten zum freien Download zur Verfügung.
Fazit
Die beiden Anwendungsbeispiele Vertriebs-Informationssystem und Mitarbeiter-Portlet zeigen, wie eine Portalanwendung aus Anwendersicht einen Mehrwert gegenüber den bekannten Notes-Basisanwendungen bieten kann. Durch den Einsatz eines Portals können die Systeme besser auf den Bedarf einzelner Anwendergruppen zugeschnitten werden und helfen so, das Potenzial vorhandener Anwendungen besser auszuschöpfen.
Verfolgt man diese Strategie, wächst die Anzahl der Portlets in der Regel rasch an. Bei manueller Entwicklung können hier schnell erhebliche Kosten entstehen. Die Consulting- und Integrationskosten übersteigen die Lizenzkosten für Das Portal dann schon bald um ein Vielfaches. Bereits zu Projektbeginn sollten deshalb die Möglichkeiten der Portlet-Entwicklung sorgfältig abgewogen werden.