In vier Schritten das Kundenlager befüllen

Feature | 18. April 2007 von admin 0

Dieter Busche ist Friseurmeister und Inhaber eines kleinen Salons mit vier Angestellten. Der Mittelständler muss sein Lager regelmäßig alle vier Wochen mit neuen Haarwaschmitteln und Haarsprays auffüllen und bezieht deshalb die Produkte direkt von einem großen Hersteller für Haarkosmetik. Wie viele andere kleine Firmen hat der Friseursalon Busche eine sehr einfache IT-Infrastruktur und keine eigene ERP-Lösung. Deshalb übermittelte Dieter Busche bislang seine Bestellungen per Telefon oder per Fax an den Hersteller, der SAP ERP verwendet. Dort wiederum musste Gerhard Locke, Mitarbeiter im Verkaufsinnendienst, Busches Bestellungen von Hand in SAP ERP eingeben. Das ist nicht nur zeitaufwändig, sondern auch fehleranfällig. Manchmal verzögerten sich die Lieferungen, zum Teil wurden falsche Produkte geliefert. Beide Seiten waren unzufrieden.

Für Anwender ohne eigene ERP-Lösung

Das hat sich nun geändert. Denn: Der Hersteller füllt nun die Lager seiner Abnehmer mit Hilfe der Composite Application SAP xApp Inventory Level Replenishment (SAP xILR) auf. Mit der Anwendung hat der Hersteller die Bestellabläufe mit Kunden, die kein eigenes ERP-System haben, gewissermaßen in die eigenen Hände genommen und damit für seine Abnehmer die Situation deutlich vereinfacht und verbessert. Davon profitieren beide Seiten.
Heute schickt Gerhard Locke, erinnert von SAP NetWeaver Portal, alle vier Wochen eine E-Mail mit einem angehängten interaktiven und personalisierten Bestellformular im PDF-Format an den Friseursalon Busche. Dieter Busche öffnet das Bestellformular, trägt in vordefinierte Felder die benötigten Mengen an Haarspray und Haarwaschmittel ein, die er nachbestellen will, und schickt das ausgefüllte Dokument per E-Mail zurück.
Gerhard Locke bekommt diese E-Mail mit dem ausgefüllten Bestellformular dank eines portalgestützten Prozesses wiederum direkt an seinen Arbeitsplatz geliefert. Er prüft die Angaben in der Bestellung und erteilt die Freigabe. Das interaktive Formular übergibt mit der Freigabe via SAP xILR die Bestellung mithilfe eines Enterprise-Services automatisch an SAP ERP 2005, wo der Kundenauftrag angelegt wird. Die weiteren Prozesse, wie die Abwicklung des Lieferauftrags, werden dann in SAP ERP bearbeitet und sind nicht Bestandteil von SAP xILR. Bereits zwei Tage später ist die bestellte Ware im Friseursalon Busche. Bestimmte Prozessparameter, etwa Vereinbarungen über Produkte und deren Ziellagerbestände oder welcher Kunde wie häufig ein Bestellformular bekommt, werden ebenfalls in der Composite Application festgelegt. Ob und wann Verkaufsmitarbeiter Locke welche Kunden anschreiben muss, ist darüber hinaus farblich kodiert. Die eingehenden Bestellungen arbeitet er dann über eine Aufgabenliste ab.

Architektur-SAP-xILR

Architektur-SAP-xILR

SAP hat die Composite Application SAP xILR zunächst für Hersteller in der Konsumgüterbranche entwickelt, um einen automatisierten und medienbruchfreien Ablauf von Bestellprozessen mit Kunden zu ermöglichen. Dieser Prozess funktioniert aber auch in anderen Branchen. SAP xILR strukturiert, automatisiert und vereinheitlicht den Prozess der Lagerbefüllung beim Kunden über die einzelnen Kommunikationskanäle hinweg. Bei SAP xILR sind es die vier Schritte Ziellagerbestand pro Kunde und Produkt pflegen, Bestellformular senden, aktuellen Lagerbestand in das Bestellformular eintragen und zurücksenden, Bestellung prüfen und freigeben. Diese Prozessschritte sind für jeden Kunden gleich, können jedoch über Prozessparameter kundenindividuell zugeschnitten werden und integrieren über Enterprise-Services Funktionen aus unterschiedlichen Anwendungen unter einer einheitlichen und auf den spezifischen Vorgang hin angepassten Benutzeroberfläche.

Wenige Enterprise Services genügen

Die für Composite Applications notwendigen Funktionalitäten werden von SAP ERP 2005 sowie den Anwendungen der SAP Business Suite als wieder verwendbare Enterprise-Services zur Verfügung gestellt. Um beispielsweise die Lagerauffüllung beim Friseursalon Busche durchzuführen, nutzt SAP xILR sowohl Kundenstammdaten aus der Finanzbuchhaltung – etwa Kundenname, Kundenadresse, Kundennummer und Ansprechpartner – als auch Materialstammdaten aus der Logistik-Anwendung, wie zu liefernde Produkte, Produktnamen sowie Materialnummern. Die entsprechenden Enterprise-Services werden der Composite Application über ein Enterprise Service Repository (ESR), Bestandteil von SAP NetWeaver, zugreifbar gemacht. .
Manchmal genügen bereits wenige solcher Enterprise-Services, um ein entsprechendes Szenario aufzubauen. SAP xILR etwa ist eine“schlanke” Composite Application. Sie greift auf die fünf Enterprise-Services “Find Customer”, “Read Customer”, “Find Material”, “Create Material” und “Create Sales Order” zu.

Einheitliche Entwicklungsumgebung

SAP gestaltet alle Composite Applications auf der Grundlage eines modellgetriebenen Ansatzes und somit nach den Architekturprinzipien der Enterprise Service-Oriented Architecture (Enterprise SOA) die den Entwurf für umfassende und Service-basierende Geschäftsanwendungen liefert.
Hierfür stellt die Plattform SAP NetWeaver mit dem SAP Composite Application Framework (SAP CAF) eine einheitliche und leistungsstarke Entwicklungsumgebung zur Verfügung. SAP CAF besteht aus den Komponenten Guided Procedures für die Prozessgestaltung und dem CAF-Core für die Gestaltung der Services. Darüber hinaus kommen mit dem Visual Composer und WebDynpro sowie dem Enterprise Services Repository weitere Werkzeuge und Bestandteile von SAP NetWeaver zum Einsatz. Zusammengesetzte Anwendungen lassen sich hierdurch in einer einzigen Umgebung gestalten. Zudem werden Modellierungen, wie die Zusammensetzung von Services, Daten, Oberflächen sowie Prozesskoordination auf allen Ebenen des Entwicklungsprozesses unterstützt.

Getrennte Lösungsarchitektur

Lose gekoppelt, rasch entwickelt

Lose gekoppelt, rasch entwickelt

Die modellgetriebene Entwicklung wirkt sich auch auf die Architektur der Composite Applications aus. Prozessdesign, also die Prozessabläufe sowie die beteiligten Benutzerrollen, User Interfaces und Geschäfts- sowie Anwendungslogik sind voneinander getrennt. In der Prozessschicht wird definiert, welche Prozessschritte in welcher Abfolge durchgeführt werden und von welchen Anwendern. Mithilfe der Guided Procedures als Bestandteil von SAP CAF werden die anwendungsübergreifenden Arbeitsschritte, etwa die Interaktion zwischen Konsumgüterherstellern und ihren Kunden bei der Lagerbefüllung, nach festgelegten Verfahren gestaltet und auf den Endanwender ausgerichtet. Mit Guided Procedures lassen sich interaktive Geschäftsprozesse modellieren und ausführen sowie auf diverse Backend-Systeme zugreifen. Gleichzeitig können mit CAF-Core – falls erforderlich – Services erstellt werden, die ihre Daten aus Alt- oder Fremdsystemen beziehen. Darüber hinaus wird in den Guides Procedures auch der Datenfluss zwischen den unterschiedlichen Prozessschritten festgelegt, also die Frage geklärt, wann ein Anwender welche Daten erhält, und der Ablauf somit an die Bedürfnisse der Anwender angepasst.
Über die User Interfaces wird, definiert wie diese Daten aufbereitet werden und wie welche Aktionen eines Prozessschrittes durchgeführt werden. Als Standardwerkzeug für die Modellierung der Benutzeroberflächen dient der Visual Composer. In bestimmten Fällen findet auch WebDynpro (Java) Verwendung, etwa bei der Modellierung von Benutzeroberflächen für komplexe Prozessschritte. Formularbasierte Prozesse oder Offline-Bearbeitung wie Bestellabläufe werden mithilfe der SAP Interactive Forms by Adobe nachgebildet.

Modellierung-Composite-Applications

Modellierung-Composite-Applications

In der Schicht der Geschäftslogik ist festgelegt, welche Funktionen eine Composite Application benötigt. SAP CAF konsumiert hierfür die erforderlichen Enterprise-Services aus den Backend-Systemen. Auch die Anwendungslogik der Composite Application wird mit SAP CAF entwickelt. Sie beschreibt die konkrete Verknüpfung der einzelnen Bausteine zu einer Composite Application und legt die Reihenfolge fest, in welcher die Services aufgerufen werden. Zudem wird die für Composite Applications spezifische und nicht im ERP-Backend vorhandene Business Logik und Persistenz entwickelt. Diese Anwendungslogik wird den darüber liegenden UI- und Prozess-Schichten als Web-Services zur Verfügung gestellt.

Lücken schließen

Durch diese Schichtenarchitektur lassen sich Composite Applications rasch und kostengünstig aufbauen, schnell implementieren und flexibel an neue Prozessanforderungen anpassen, ohne sie komplett neu zu programmieren. Die modellgetriebene Entwicklung trägt außerdem dazu bei, dass sich IT-Infrastrukturen verstärkt an den Prozessanforderungen der Anwender orientieren sowie einfacher werden. Hierdurch verringern sich Administrationsaufwand und Kosten. Damit sind Composite Applications wie SAP xILR die Antwort auf die Herausforderungen der heutigen Wirtschaft: Unternehmen aller Branchen müssen kurzfristig auf Veränderungen in ihrem Marktumfeld reagieren können.

SAP-xApps-Industry-Portfolio

SAP-xApps-Industry-Portfolio

Insgesamt sind derzeit 15 branchenspezifische Anwendungen wie SAP xILR in der Entwicklung und werden mit Kunden zur Marktreife gebracht. Dazu zählen unter anderem SAP xApp Project Issue and Change Management, die Unternehmen beim Veränderungsmanagement in Projekten unterstützt, oder auch SAP xApp First Report of Injury for Insurance, mit der Versicherte Schadensfälle direkt an den Versicherer melden können. Durchschnittlich beträgt der Zyklus von der Ideenentwicklung einer Composite Application bis zur Marktreife rund drei bis sechs Monate. Damit erhalten SAP-Kunden zeitnah Lösungen, um ihre branchenspezifischen Prozesse durchgängig, strukturiert und effizient abzuwickeln. Zukünftig wird SAP bei der Entwicklung neuer industriespezifischer Composite Applications noch enger mit Kunden zusammenarbeiten.

Dr. Andreas Schaffry

Dr. Andreas Schaffry

Tags:

Leave a Reply