Ein Unternehmen, das eine Infrastruktur für mobile Anwendungen implementieren möchte, sollte eine Architektur wählen, die technisch sinnvoll, in fachlicher Hinsicht ausbaufähig und flexibel ist. In der SAP-Welt stehen dafür, je nach existierender Infrastruktur und den geforderten Funktionen, vier verschiedene Alternativen zur Verfügung. Sie unterscheiden sich fachlich, technisch und wirtschaftlich. Welches dieser Szenarien in Frage kommt, hängt von verschiedenen Kriterien ab. Zu berücksichtigen sind beispielsweise die drei Ebenen "Anwendung" mit ihren hauptsächlich funktionalen Anforderungen, "Middleware" (in erster Linie technische Anforderungen) und "Backend" (meistens faktische Voraussetzung). Sie beeinflussen sich gegenseitig, was die Entscheidung für eine ideale Wunschkombination möglicherweise erschwert.

Szenario 1:

Mobile Infrastructure (MI)

Das erste Szenario basiert auf SAPs "Mobile Infrastructure" und bietet einen hohen Standardisierungsgrad mit einem Funktionsumfang für alle wesentlichen mobilen Anwendungsbereiche. SAP liefert mit "Mobile Asset Management" (MAM), "Mobile Asset Management for Utilities" (MAU) und "Mobile Sales für R/3" (MSR) sowie einigen weiteren Anwendungen vorgefertigte Lösungen. Das System unterstützt fast alle Endgeräte. Flexibel lassen sich Erweiterungen integrieren und Benutzerschnittstellen anpassen. Dieses moderne Szenario hat andererseits noch keinen hohen Reifegrad. Das offline replizierbare Datenvolumen ist begrenzt (Beispiel: rund 50000 Materialstammsätze), und der Funktionsumfang konzentriert sich auf Kernprozesse aus den R/3-Modulen.

Die MI ist, wie der Name schon sagt, die mobile Infrastruktur von SAP zur Versorgung offline laufender Anwendungen. Die mobilen Anwendungen der MI werden als Thin Clients betrieben, da offline nur die Daten vorgehalten werden sollen, die für den jeweiligen Anwender und Anwendungsfall erforderlich sind. Die MI hat eine Client-Komponente, die unter anderem die Datensynchronisation zwischen Middleware und mobilen Frontends (Clients) steuert und die zu liefernden Daten zwischenspeichert. Entsprechend behandelt die Server-Komponente den Datenaustausch zum beziehungsweise vom Backend. Die auf Netweaver basierende Implementierung der MI geht von drei Instanzen aus: R/3 4.x, "Web Application Server 6.x" (WAS) und MI 2.x sowie mobile Anwendung.

Auf der Plusseite stehen für dieses Szenario auch die Investitionssicherheit durch die Modernität der Infrastruktur und die mitgelieferte Entwicklungsumgebung, so dass Anwender selbst Erweiterungen und Anpassungen vornehmen können. Es kommt deshalb am ehesten in Frage, wenn der benötigte Funktionsumfang am mobilen Gerät durch die Standardfunktionen der SAP-Lösungen vollständig bereitgestellt wird.

Szenario 2:

MI plus J2EE am Client

Wird auf dem mobilen Endgerät jedoch ein größerer Funktionsumfang benötigt, als ihn Szenario 1 mit MAM, MSR etc. bietet, sollte eine Individualentwicklung für den Client auf J2EE-Basis in Betracht gezogen werden. Die Mobile Infrastructure kann dafür als Middleware mit ihrer relativ schlanken Implementierung gut verwendet werden. Insofern bietet auch dieses Szenario Investitionssicherheit und Modernität.

Beschränkungen hinsichtlich des replizierbaren Datenvolumens und der Prozessunterstützung gibt es mit dieser Architektur praktisch nicht. Sie bietet neben dem Zugriff auf R/3 als Backend auch die Möglichkeit, CRM-Prozesse und -Funktionen zu unterstützen.

Szenario 3:

J2EE am Client und Server

Weitere Freiheitsgrade erschließt Szenario 3, wo Individualentwicklungen nicht nur für den Client, sondern auch für einen J2EE-Server, also auf der Middleware stattfinden können. Der mit der Netweaver-Plattform mitgelieferte Web Application Server stellt die Basismechanismen für den Zugriff auf Backend-Systeme zur Verfügung. Dieses Szenario bietet sich an, wenn eine J2EE-basierende Lösungsentwicklung angestrebt wird, die Mobile Infrastructure aber, zum Beispiel aus Gründen des Mengengerüsts, nicht zum Einsatz kommen kann.

Szenario 4:

SAP CRM Comstation

Das CRM-Mobile-Client-Szenario unterscheidet sich grundsätzlich von den drei anderen durch die Middleware "CRM Comstation". Es bietet neben dem hohen Grad der Standardisierung und technischen Reife (verfügbar in der fünften Generation) auch den größten Funktionsumfang verbunden mit umfangreicher Prozessunterstützung. Dies bezieht sich in erster Linie auf die vertrieblichen Funktionen mit hohen Anforderungen an Offline-Funktionalität. Auch für dieses Szenario wird eine Entwicklungsumgebung für Erweiterungen und Anpassungen mitgeliefert.

Nachteile dieser Infrastruktur sind die erheblichen Kosten für Investition und Betrieb. Der Reifegrad auf der einen Seite muss durch eine weniger moderne und weniger schlanke Implementierung erkauft werden. Die erforderliche Hardware und Systemkonfiguration ist komplex, was erhebliche Anforderungen an Ressourcen und Betriebs-Know-how zur Folge hat. Dies drückt sich auch in der Beschränkung auf Windows-32-Frontends aus; kleine Endgeräte wie Pocket PCs, Palms und Smartphones werden nicht unterstützt. Im Vergleich zu den MI-Szenarien ist der CRM-Client als Fat Client die deutlich umfangreichere Anwendung hinsichtlich Funktionalität und Offline-Datenvolumen. Sie verlangt am Frontend zum Beispiel eine freie Festplattenkapazität von mindestens 30 GB, weshalb nur Notebooks und Tablet-PCs in Frage kommen.

Die Implementierung sieht für eine mobile Lösung mit "SAP CRM" fünf Instanzen vor: R/3 4.x, "CRM Middleware", "CRM Online", Comstation sowie "CRM Mobile Client" (Sales und Service).

Von der Infrastrukturentscheidung bis zum Prototypen

Generell gilt: Der Nutzen für den Geschäftsprozess und den Endbenutzer entscheidet über den Erfolg einer IT-Lösung. Die Fachabteilung interessiert sich, abgesehen von den Kosten, die sie für das Projekt und den Betrieb zu bezahlen hat, letztlich nur wenig für die hinter einer mobilen Anwendung liegende Technik. Deshalb kommt der Funktionalität des Frontends die entscheidende Bedeutung zu. Hier bestimmen Parameter wie die physikalischen Voraussetzungen der Engeräte (Notebook/Tablet-PC, Handheld oder Smartphone), die Ansprüche an die Benutzerschnittstelle sowie die zu verarbeitenden Daten im Zuge des Arbeitsablaufs (Geschäftsprozess).

Abgleich von Funktionen und Anforderungen

Man muss also den Anforderungskatalog der Fachabteilung den Funktionskatalogen der verfügbaren Anwendungen gegenüberstellen und gewichten. Daraus ergibt sich, welches der Module geeignet ist beziehungsweise inwieweit es an funktionale und insbesondere ergonomische Bedürfnisse angepasst werden muss. Gegebenenfalls muss ein eigenes Frontend entwickelt werden.

Der Ergonomie kommt bei mobilen Anwendungen eine sehr hohe Bedeutung zu - vor allem wenn die Endanwender sich mit SAP-Systemen wenig bis gar nicht auskennen, was erfahrungsgemäß oft der Fall ist. Hierzu gehören Gestaltung, Interaktion und Navigation. Die Standardapplikationen der SAP heben funktional auf die Geschäftsprozesse im Backend ab. In nahezu allen Projekten hat sich jedoch herausgestellt, dass die Fachabteilung eher einen prozessorientierten Ablauf der mobilen Anwendung am Frontend wünscht. Mittels eines User-Interface-(UI-)Erweiterungskonzepts für die MI kann diesen Wünschen Rechnung getragen werden. Das heißt, es können Anwendungen bereitgestellt werden, die exakt dem Ablauf des Außendienstes entsprechen. Hierdurch wird die Akzeptanz der Lösung in den Fachbereichen und bei den Endbenutzern erreicht.

Evaluierungs-Tools bieten Entscheidungshilfe

Aus den Erfahrungen zahlreicher Projekte sind die Parameter, die zur Wahl eines der vier Szenarien herangezogen werden (siehe Kasten "Welche Aspekte werden gewichtet?"), verlässlich gewichtbar und ermöglichen damit eine nachvollziehbare Entscheidung. Eine große Hilfe dabei sind Evaluierungs-Tools auf Basis einer Tabellenkalkulation. Ein solches Werkzeug erlaubt die objektive Bewertung der unterschiedlichen Architekturszenarien nach den fachlichen, technischen und wirtschaftlichen Kriterien. Zusätzlich lassen sich fixe Entscheidungsvorgaben wie Strategiebedingungen berücksichtigen und Variablen festlegen. Variablen sind offene Werte wie Vorgaben für die Art der Endgeräte oder die erforderlichen Offline-Anwendungsfälle.

Natürlich liefert ein solches Tool nicht das ausschließliche Entscheidungsergebnis. Es gibt dem Anwenderunternehmen aber die Sicherheit, alle Faktoren mit der nötigen Gewichtung berücksichtigt zu haben, und hilft bei der Simulation unterschiedlicher Bedingungen und Annahmen (Sensitivitätsanalyse). Die endgültige Entscheidung liegt letztlich beim Management des Unternehmens.

Pflichtenheft oder Fachkonzept reichen nicht

Möchte man ein Tool als Gewichtungsverfahren zur Produktevaluierung nutzen, ist es zuvor erforderlich, seine eigenen Anforderungen bestmöglich zu kennen. Da es erfahrungsgemäß nicht ausreicht, ein technisches Pflichtenheft oder Fachkonzept zu erzeugen, da dies keine hinreichende Grundlage für Fachabteilungen und Anwender ist, hat sich ein dreistufiges Vorgehen bewährt, wobei jede Phase auf die Ergebnisse der vorherigen Stufe aufsetzt.

Im ersten Schritt erfolgt die Prozessanalyse und Listung der Anwendungsfälle. Dafür müssen mehrere Fragen beantwortet werden: Welche Prozesse und Daten müssen offline zur Verfügung stehen (Anwendungsfalldiagramm), wer sind die Akteure (Innendienst, Außendienst), aus welchen verbundenen Systemen im Backend werden die Daten beziehungsweise Prozesse bezogen und weiterverarbeitet?

Die zweite Stufe sollte klären, ob und wie die Anwendungsfälle untereinander navigierbar sind und wie sich die Anwendung gegenüber dem Benutzer verhält. Hierfür wird ein Navigationsdiagramm erstellt.

Schließlich wird im dritten Schritt ein GUI-Prototyp entwickelt. Die Anwendung wird auf Basis statisch miteinander verknüpfter Dialoge prototypisch erzeugt und kann in der Endfassung auch auf mobile Geräte aufgespielt werden. Entsprechend den Erfahrungsberichten der Benutzer lässt sich die Anwendung dann optimieren. Erst wenn ein ergonomisch einwandfreier Prototyp vorliegt, wird die Anforderungsanalyse abgeschlossen (Anwendungsfälle, Prozessanalyse, Dialogspezifikationen, erforderliche Backend-Integration im Detail). Auf dieser Basis lässt sich dann die erforderliche Standardsoftware auswählen. (ue)