Anforderungen an das Application-Design am Kundenbeispiel

Anforderungen an das Application-Design (im ERP-Umfeld) Erfüllung der Enterprise-Application-Strategie (technischer Fit) Wartbarkeit, Zukunftssicherheit (-> Wartungspersonal!), keine technischen Kapriolen, technische Mode Bewahrung der einheitlichen, ERP-gelernten Sprache (Domänenmodell) Konsequentes Mapping der ERP-Sprache in die Non-ERP-Welt Extreme Skalierbarkeit Effektives User-Interface Geringe User-Akzeptanz kann zu Schattenlösungen und Heterogenisierung führen: Durch kleinen Funktionsumfang kann schnell ersetzt werden

Beispiel 1: Großes europäisches Middleware-Projekt als Zwischenschicht zwischen technischem Backbone und ERP-Landschaft: Qualifizierte Datenfilterung Zentrales Argument für Implementierung außerhalb des ERP-Systems: Heterogene ERP-Landschaft! SAP + viele verschiedene Navision-Instanzen in den Landesgesellschaften; Single Point of Implementation Gemeinsame Plattform erzwingt gemeinsame Prozesse Implementierung für drei zentrale vollautomatisierte Prozesse: Service Verbrauchsmaterialien Smart-Metering Aktuell hohe sechsstellige Zahl Endgeräten Ca. 1 Mio. Transaktionen/Tag Seit Inbetriebnahme (völlig neues Geschäftsfeld): Faktor 1000 Wachstum (Datenvolumen mehr)

Beispiel 1: Technik Message-Oriented Middleware inkl. Pufferspeicher Java-basierte Middleware, nicht auf klassischer JEE-Plattform Datenhaltung im kunden-eigenen DB-Cluster Rule-Engine für Service- und Verbrauchsmeldungen mit aktuell mehr als 500K Regeln Regeln werden durch Key-User selber auf der Oberfläche gepflegt und überwacht Umfangreiche Statistik- und Monitoring-Funktionen für das nachgelagerte Backend

Beispiel 2: Anforderungen Anlass der Implementierung: Ablösung von voriger auf Lotus-Notes basierender Lösung Optimierung manueller Transaktionen bei der Verarbeitung von manuell ausgefüllten Zählerstandskarten (FAX/E-Mail) Nutzung von vorhandener OCR-Infrastruktur Enge online-anbindung an SAP zur Vorbereitung der Daten und zum Verbuchen der Daten Revisionssichere Datenhaltung der verarbeiteten Faxe in eigener Datenbank

Beispiel 2: Technik Klassische Java-Servlet-Anwendung Online-Anbindung an SAP per RFC Direkte Ladung von benötigten Daten aus SAP beim Aufruf einer Zählerstandskarte Nutzung von vorhandener OCR-Infrastruktur Anbindung an FAX- und E-Mail-Server (Exchange per EWS) Datenhaltung im kundeneigenen-db-cluster

Anforderungen im Bereich User Experience

End-to-End Application Design

Mobile ERP: Eine unter Vielen

Spezielle Anforderungen für mobile Anwendungen ERP Anwendungen stellen setzen nicht mehr den Standard (SAP holt auf!) Target-Plattformen multidimensional Anzeige Technik (CrossOrigin bei WebApps, generell Security) All Target-Plattformen müssen vom ersten Tag an berücksichtigt werden (mobile first) Bei SAP FIORI betrifft das insbesondere die Bibliotheken-Auswahl Anwendungen sind immer eine unter vielen (enormer Wettbewerb, geht nicht gibt s nicht) FIORI: Bibliotheken wachsen stark und entwickeln sich dynamisch à Extrem hohe Erwartungshaltung an UX (inkl. neue Bedienkonzepte u. Performance) UX ist so dominierend, dass Datenbeschaffung im Backbone selbstverständlich wird

Spezielle Anforderungen für mobile Anwendungen CI und Branding sind elementare Bestandteile der App (à FIORI?) META: Ganz eigene Vorgehensweise/Neue Workflows bei der Planung und Implementierung von Anwendungen (Bsp. LOFI Mockups, Wireframes,..., UX assessments) META: Wie bei SPIDER schon gesehen: Reduktion auf einen oder wenige Prozesschritte machen Effizienz gut messabar und optimierbar. UX-Assessments sind Standard META: Rückwirkungen auf die Prozesse (Multi-Funktions-Devices) man könnte doch auch... META: Apps projizieren Erwartungshaltung an Prozesse Warum geht das denn nicht mobile...? Erwartete TimeToMarket ist extrem kurz (sehr schnelle Mockups und Prototypes)

Beispiel 3: Die Actum-Uhrenwerkstatt http://localhost/~schaade/actum-serviceportal

Vielen Dank für Ihre Aufmerksamkeit!