Anpassung des mySAP Enterprise Portals an Kundenanforderungen
Von Sven Kannengiesser, Christine Wiegand, & Gerd Waloszek, SAP AG – 21/02/2003
Sven Kannengiesser ist Berater bei SAP für das mySAP Enterprise Portal. Seine Aufgabe besteht zur Zeit darin, das Portal beim Kunden an dessen Corporate Design anzupassen. In einem Interview mit dem SAP Design Guild Team berichtet er von seinen Erfahrungen.
Legende: Sven = Sven Kannengiesser, DGT = SAP Design Guild Team (Christine Wiegand, Gerd Waloszek)
Das Interview
Warum wollen Kunden das Portal "branden"?
DGT: Gegenwärtig spielen Themen wie "Corporate Design" und "Corporate Identity" auch bei Software-Produkten wie dem mySAP Enterprise Portal eine große Rolle. Warum wollen Kunden das Portal "branden"?
Sven: Zielgruppe des Portals sind die täglichen Nutzer des Portals – die sollen sich in ihrem Unternehmen wieder finden und sich mit ihm identifizieren. Beim R/3-System war von Branding noch keine Rede, da ging es primär um die Frage, wie Anwender ihre Aufgaben effizient bearbeiten können. Natürlich sollen Anwender auch heute ihre Arbeit mit der Portal-Software erledigen, aber im Internet-Zeitalter legt man Wert darauf, ein eigenständiges "Gesicht" zu zeigen – eben die "Corporate Identity".
Einsatzgebiete
DGT: Zu welchen Anlässen bist Du als "Portal-Brander" im Einsatz?
Sven: Im letzten Jahr hatten wir viele kleine Projekte. Das Enterprise Portal 5.0 war neu auf dem Markt war und sollte dort zunächst getestet werden. Viele größere Unternehmen spielen mit dem Gedanken oder haben sich schon entschieden, unser Produkt einzusetzen. Deshalb haben wir eine Reihe von Pilotprojekten gestartet, deren Ergebnisse der jeweiligen Unternehmensleitung vorgestellt wurden. Gerade für diese Zielgruppe musste das Portal glänzen – in erster Linie optisch, denn für Manager muss der erste Eindruck stimmen. Natürlich sind die Funktionalität und der Nutzen des Portals wichtig, aber das Aussehen hat bei der Kaufentscheidung großen Einfluss.
Bild 1: mySAP Enterprise Portal 5.0 im Standarddesign Mango und Polarwind
Hauptwünsche und Erwartungen der Kunden
DGT: Welches sind die Hauptwünsche und Erwartungen der Kunden, wenn sie Dich als "Brander" zu sich holen?
Sven: Ganz einfach: Es soll anders aussehen als unser Standard-Portal.
DGT: Das ist eine sehr offene Aufgabenstellung.
Sven: Ja, ich komme zum Kunden, und manche Kunden haben keine klare Vorstellung, wie sie es haben wollen – Hauptsache "anders", um Eigenständigkeit zu zeigen.
DGT: Die meisten Firmen haben eine eigene Website oder ein Intranet. Dort haben sie sich sicherlich, was das Design und Branding angeht, "ausgetobt". Erwarten sie, dass das Portal dem entspricht?
Sven: Manchmal haben die Kunden nicht einmal eine solche Erwartung. Bei einem Haushaltsgeräte-Hersteller habe ich dann zunächst die externe Website als Basis genommen, weil diese besser als Vorlage geeignet war als das Intranet dieser Firma. Die Website war einfach aufgebaut, nur hatte sie einen zu großen Header. Diesen haben wir auf 20 Pixel Höhe verkleinert und den Willkommens-Gruß, unsere Suche und Personalisierung sowie das Logo oben rechts. Das kam zunächst gut an, aber dann setzte sich doch der Wunsch durch, das Portal an das Firmen-Intranet anzupassen. Allerdings habe ich den Kunden davon überzeugen können, unsere Standard-Navigation zu übernehmen.
DGT: Es gibt also auch Kunden, die erwarten, dass das Portal wie ihr Intranet aussieht?
Sven: Ja, in den Fällen, in denen das Intranet gegen unser Portal ausgetauscht werden soll. Insgesamt waren in meinen Projekten sowohl das Intranet oder die Firmen-Website Anhaltspunkt für das Design, sofern das Aussehen nicht durch einen Style Guide vorgegeben war – wobei es auch für das Intranet Style Guides geben kann.
Theme Editor
DGT: Um noch einmal auf das "anders" zurückzukommen – SAP bietet mit dem Theme Editor ein Werkzeug an, mit dem Kunden dieses "anders" innerhalb bestimmter Grenzen bereits erreichen können. Wenn Farben und Schriften im Kunden-Style Guide vorgegeben sind könnte man diese also im Theme Editor einstellen und wäre bereits einen großen Schritt weiter.
Sven: Das ist auch mein erster Schritt: Ich beginne mit dem Theme Editor und versuche damit alle Farben, Logos und grafischen Elemente anzupassen, um eine erste Annährung an das gewünschte Design zu erhalten.
DGT: Und sind die Kunden damit zufrieden? Sven: Viele Kunden reicht diese Form der Anpassung völlig aus, denn Upgrades und Patches sind so kein Problem. Selbst bei Kunden mit einem eigenen Style Guide kommt es vor, dass in bestimmten Geschäftsbereichen das Branding mit dem Theme Editor vorgenommen wird, um zum Beispiel eine große Arbeitsfläche zu erhalten.
Ansprechpartner
DGT: Wer sind Deine Ansprechpartner beim Kunden? Wer übernimmt dort das Branding des Portals?
Sven: Manche Aufgaben werden an externe Designfirmen vergeben, ansonsten nehmen Projektmitglieder die Anpassung vor.
DGT: Das nötige Wissen ist also nicht immer beim Kunden vorhanden? Sven: Nein, wenn Kunden eigene Designer haben, dann haben diese normalerweise gute HTML und Grafikkenntnisse, aber nicht das technische Wissen, um weitergehende Branding-Anforderungen umzusetzen.
DGT: In welcher Form hast Du dann mit den Designern zu tun?
Sven: Ich habe eher selten mit den Designern zu tun und wenn, dann beschränkt sich mein Kontakt mit ihnen auf Style Guides.
Einsatz-Situationen – Von frei bis durch einen Style Guide vorgegeben
DGT: Was für Bedingungen und Anforderungen triffst Du bei Deinen Projekten beim Kunden an?
Sven: Ich finde sehr unterschiedliche Situationen vor – von "alles durch einen Style Guide vorgegeben" bis hin zu "jetzt schau' mal aus dem Fenster". Letzteres war beim Heizungshersteller Weishaupt der Fall. Dort wurde mir angedeutet, dass ich, um Design-Ideen zu bekommen, auf das Gebäude draußen schauen und mich davon leiten lassen sollte. Das war eine echte Herausforderung, vor allem weil meine dortige Ansprechpartnerin bereits eigene Vorstellungen entwickelt hatte. Eines der Grundprinzipien des New Yorker Star-Architekten Richard Meier des Weishaupt-Gebäudes war nämlich, alles in Quadrate einzubetten, und das war auch ihr Vorschlag. Doch der Kachelhintergrund brachte zu viel Unruhe in die Seiten, und wir haben das Design vereinfachen müssen.
 |
Bild 2: Das Weishaupt-Portal lehnt sich an den Sil des Weishaupt-Gebäudes an, das oben links auf der Portalseite zu sehen ist (ins Bild klicken für eine größere Version)
DGT: Trotz oder gerade wegen der Herausforderung war diese Aufgabe sicherlich kreativer als manche andere.
Sven: Ja, viele Großunternehmen bringen bereits einen Style Guide mit, in dem alles detailliert vorgegeben ist. Dieser kann für Print-Medien oder für das Web erstellt worden sein, möglicherweise noch unterschieden nach Intranet und Extranet. Oder das Unternehmen ist noch dabei, einen Style Guide zu erstellen, und ich muss mich mit der entsprechenden Abteilung absprechen.
DGT: Wenn kein Style Guide vorhanden ist, was machst Du dann? Schaust Du Dir die Druck-Medien und Briefköpfe einer Firma an?
Sven: Zunächst schaue ich mir die Website von Firmen an. Gibt es mehrere, sind diese leider oft nicht konsistent. Dann schaue ich mir die Druck-Medien wie etwa Broschüren an. Aber auch sie sind nicht immer als Vorlage geeignet. Zum Beispiel waren im Falle des Weishaupt-Portals die in den Druck-Medien verwendeten Farben schwarz, rot und gelb zu kräftig. Sie passten nicht zum Stil des Gebäudes, das als Grundlage für das Design dienen sollte.
Ein weiteres Kundenbeispiel: Die spielerische Variante
Sven: Ich habe einmal eine Woche für die Telekom Italia gearbeitet und gelernt dass Südländer, was Web-Oberflächen angeht, viel verspielter sind: Alles war viel bunter, und die Navigation war mit Grafiken realisiert – da sind die Deutschen nüchterner.
DGT: Dann konntest Du deren Wünsche kaum erfüllen?
Sven: Doch, dazu musste ich das Portal allerdings völlig "verbiegen". Eigentlich war das Ergebnis kein Portal mehr. Wir haben unsere Standard-Navigation ausgeblendet; stattdessen wurde eine Seite mit internen Links aufgerufen, innerhalb derer sich alles abspielte. Es gab keinen Header, nichts, was an unser Portal erinnerte. Die Seite war also sehr weitgehend an die Kundenwünsche angepasst. Für dessen Zweck war das offenbar eine geeignete Lösung.
DGT: Und wie bist Du vorgegangen?
Sven: Zunächst habe ich die Machbarkeit geklärt und dann das Konzept umgesetzt. Später als das Ganze auf ein Produktivsystem portiert war, gab es wegen der so weit gehenden Modifikationen Probleme. Man hatte die Modifikationen nicht ausreichend dokumentiert.
Modifikationen und Portal-Updates
DGT: Für Dich ist also eine gute Dokumentation lebenswichtig?
Sven: Ja, unbedingt. Deshalb kommentiere ich auch jede Modifikation im Quellkode – schon aus eigenem Interesse. Bei Upgrades muss ich nämlich einen Versionsabgleich durchführen. Dann helfen mir die Kommentare im Quellkode immens.
DGT: Wenn Du z.B. wie bei der Telekom Italia, soviel verändert hast, treten danach sicher schon mal Probleme mit Patches auf. Bist Du dann wieder gefragt? Und wenn das häufiger vorkommt, wie schützt Du Dich gegen den "Burn-Out"?
Sven: Ja, das kann ein Problem sein – natürlich muss ich diese Kunden unterstützen. Inzwischen frage ich deshalb die Kunden jedes Mal, wenn ich eine Modifikation durchführe, ob sie diese wirklich wollen und ob sie sich über die Konsequenzen im Klaren sind. Ich selbst versuche, Modifikationen, z.B. der Navigation, möglichst "intelligent" zu machen und so zu verhindern dass sie beim Update überschrieben werden. Nach dem Wiedereinspielen der Modifikationen fehlt natürlich die neue Funktionalität. Deshalb versuche ich auch, die Kunden von Modifikationen abzuhalten.
Layout – Unterschiede zwischen Portalen, Intranets und Websites
DGT: Lass uns nun auf zwei Schwerpunkte Deiner Anpassungsarbeit zu sprechen kommen, das Layout und die Navigation. Sicher entsprechen die Erwartungen des Kunden in diesen Bereichen nicht immer dem, was machbar und sinnvoll ist.
Sven: Ja, nicht alle Vorstellungen oder Style Guide-Vorgaben des Kunden lassen sich umsetzen oder sind im Portal-Umfeld sinnvoll – das muss der erst Kunde erkennen und verstehen. Oft ist er anfangs nicht bereit, Abstriche zu machen und Kompromisse einzugehen.
DGT: Die Erwartungen und Vorgaben des Kunden werden ja oft von seiner Website oder dem bestehenden Intranet bestimmt. Wo siehst Du das Portal zwischen dem Intranet und der externen Website einer Firma angesiedelt.
Sven: Bei Kunden, wo zum Beispiel interne Abteilungen bereits ein Intranet aufgebaut haben, diskutieren wir oft den Unterschied zwischen Portalen und Intranets, weil die Grenzen zwischen beiden fließend sind. Ein Intranet ist typischerweise eine interne Informationsquelle mit nur wenigen Applikationen. Bei einem Portal ist die Applikationsseite dagegen sehr viel stärker ausgeprägt. Unser Portal ist also nicht nur ein Werkzeug, mit dem wir ausschließlich Web Content Management betreiben, und es ist auch nicht einfach eine "Website". Die Style Guides der Kunden sind meistens zu detailliert und zu sehr auf Websites ausgerichtet.
DGT: Firmen geben Dir also oft einen eigenen Style Guide an die Hand.
Sven: Ja. Dann muss ich immer wieder feststellen, dass ich dessen Vorgaben nicht streng befolgen kann. Website-orientierte Style Guides liefern zwar Design-Ideen, aber als strikte Grundlage kann ich sie nicht verwenden. Das wird besonders deutlich bei den Layout-Regeln. Zwar ist es unser erstes Ziel, den Style Guide oder die Regeln eines Unternehmens so genau wie möglich abzubilden, doch manche Regeln machen in einem Portalumfeld keinen Sinn mehr oder sind sogar hinderlich: Wenn man zum Beispiel die Breite auf 600 oder 800 Pixel beschränkt, mag das für eine Website ausreichen. Im Portal braucht man dagegen eine möglichst große Arbeitsfläche, denn das Portal ist zugleich ein Werkzeug zum Arbeiten und Informationsquelle.
Oft verliert man auch dadurch wertvolle Arbeitsfläche, dass in den Style Guides die Header mit Logos und Branding-Elementen und die Navigationsfläche viel zu groß dimensioniert sind. Unser Standarddesign liegt mit seinem schmalen Header-Bereich im Grunde genau richtig. Wenn Branding-Elemente zuviel Platz beanspruchen, reicht der Raum nicht mehr für Anwendungen und iViews aus, die ja für eine bestimmte Höhe und Breite entwickelt wurden. "Quetschen" wir sie in den verbleibenden Raum hinein, erscheinen überall hässliche Rollbalken, was ich leider nicht verhindern kann.
DGT: iViews von SAP haben vordefinierte Größen. Wenn eine Firma in ihrem Style Guide für das Layout ein bestimmtes Raster vorgibt, dann passt das nicht zusammen.
Sven: Hierzu ein Beispiel: Beim Fibonacci-Gitter, das bei einem großen deutschen Unternehmen global eingesetzt wird, entspricht ein Wert der Summe der beiden vorangegangenen Werte. Bei einer Basiseinheit von 18 Pixeln erhält man die Rasterwerte 36, 54, 90, 144 usw. – das passt überhaupt nicht zusammen. Diese Layout-Vorgaben beziehen sich allerdings auf den Rahmen, sprich Header oben und die Navigationsspalte links. Der Inhaltsbereich ist frei, dort muss ich die Abstände nicht so stark beachten.
DGT: Kurz zusammengefasst, spielt Branding im Portal eine geringere Rolle als bei Websites. Dann bist Du beim Anpassen in der paradoxen Situation, dass Du versuchen musst, Branding-Elemente wegzulassen oder zumindest zu verkleinern?
Sven: Ja, ich mache dann den Kunden darauf aufmerksam, dass zu große Branding-Elemente ungünstig sind, und frage nach, ob er dennoch darauf besteht. Bei bestimmten Kunden führt kein Weg an den Style Guide-Richtlinien vorbei, bei anderen kann ich Änderungen erreichen.
Bild 3: Demo-Beispiel für ein angepasstes Portaldesign (ins Bild klicken für eine größere Version)
Navigation
DGT: Eine Deiner Hauptaufgaben beim Kunden, besteht darin, die Navigation anders zu gestalten, als SAP sie vorgedacht hat. Warum wollen Kunden die Navigation ändern?
Sven: Dazu muss ich ein wenig ausholen. Die Standardlösung, die wir mit dem mySAP Enterprise Portal anbieten, muss eine ganze Reihe von Anforderungen erfüllen: Sie muss eine unbegrenzte Anzahl an Navigationsebenen bewältigen können, flexibel verschiedene Sprachen und Browserplattformen unterstützen und strengen Ergonomie- und Accessibility-Richtlinien genügen. Manche Kunden benötigen jedoch nicht die gesamte Bandbreite dieser Fähigkeiten und können zum Beispiel vorgeben, welche Browser Ihre Mitarbeiter installieren, Text auf Bildern einsetzen, weil nur eine Sprache benötigt wird, oder die Navigationstiefe einschränken, weil der Umfang der aufzunehmenden Informationen geringer ist. In solchen Fällen kann es Sinn machen, das Standardprodukt in seinen Möglichkeiten einzuschränken und im Design so anzupassen, dass es die spezifischen Anforderungen und Wünsche des Kunden erfüllt.
Ein weiterer Grund kann sein, dass der Style Guide des Kunden ein bestimmtes Navigationskonzept, zum Beispiel Dropdown-Menüs, vorschreibt. Manche Kunden möchten wiederum die Navigation genauso wie auf ihrer Website realisieren oder wollen es einfach "anders" haben. Auch wenn viele Argumente für das SAP-Konzept sprechen, muss man akzeptieren, dass Kunden eigene Vorstellungen haben und diese verwirklichen möchten.
DGT: Ist es einfach, die Navigation des Portals zu ändern?
Sven: Zur Zeit erfordert die Änderung der Portalnavigation umfangreiche technische Kenntnisse. Wir liefern mit dem Portal zwei Navigationselemente aus, die zwar anpassbar sind, aber mehrere Technologien kombinieren: Java-Kode liest aus der Benutzerrolle den Navigationsbaum aus und geht ihn in mehreren Schleifen durch. Das Ergebnis wird an HTML übergeben, um die Navigationsstruktur darzustellen. CSS-Klassen bestimmen die Details der Darstellung; sie sind in Style Sheets definiert, die wir anpassen können. Für die Navigations-Funktionalität benötigen wir außerdem JavaScript, denn bei einem Klick passieren mehrere Dinge: Beispielsweise wird bei einem Klick in der Einstiegsnavigation (Top-Level-Navigation) der Inhalts-Bereich gefüllt und gleichzeitig oben die Navigation optisch anders, sprich das angeklickte Element aktiv darstellt.
Die gleichzeitige Kenntnis von Java, JavaScript, HTML und CSS ist beim Kunden eher selten anzutreffen. Zusätzlich muss man wissen, wie der Baum ausgelesen wird, wenn man etwas anders darstellen will als vorgegeben. Soll beispielsweise die Einstiegsnavigation nur aus einer Zeile bestehen und Dropdown-Menüs haben, muss man im Java-API schauen, wie die Java-Klassen definiert sind, und den Mechanismus verstehen; das erfordert entsprechende Kenntnisse. Die Header anzupassen ist nicht schwer, das gelingt den meisten Kunden, aber das Verändern der Navigation schon.
DGT: Es sind also mehr technische als Layout-Probleme, die das Ändern der Navigation schwierig machen.
Sven: Ja, vor allem, wenn Style Guides neben den visuellen Eigenschaften auch das Verhalten vorschreiben, zum Beispiel was passieren soll, wenn ein bestimmter Link angeklickt wird. Wenn solche Vorgaben ebenfalls umgesetzt werden müssen, dann ist das gerade bei der Navigation die zeitaufwändigere Komponente.
DGT: Zusammengefasst, kann man sagen, dass Deine Aufgabe eigentlich zweigeteilt ist.
Sven: Ja, ich komme zwar als Brander zum Kunden, und später ist dann auch der Hauptteil meiner Arbeit, das Portal an die Wünsche des Kunden anzupassen. Aber ein ebenso wichtiger Teil meiner Arbeit besteht darin, Kunden zunächst die Möglichkeiten und Vorteile der Standardlösung nahe zu bringen und sie auf die Probleme einer Anpassung, die über den Theme Editor hinausgeht, aufmerksam zu machen.
DGT: Sven, wir danken Dir für das Gespräch und dass Du Dir dafür Zeit genommen hast.
