RECADV receiving advice

Die Wareneingangsmeldung ist eine EDIFACT- Nachricht für die Bestätigung eines Wareneingangs durch den Empfänger. Sie kann Abweichungen gegenüber vorausgehenden Nachrichten wie zum Beispiel der Liefermeldung (DESADV), Bestellung (ORDERS) oder Lieferabruf (DELFOR) enthalten.

zurück nach Oben

Reengineering

siehe Business Process Reengineering BPR

zurück nach Oben

REMADV remittance advice

Mit einem Zahlungsavis, einer EDIFACT- Nachricht, zeigen Partner im Geschäftsverkehr (zum Beispiel Verkäufer, Käufer, Banken) eine durchzuführende Zahlung oder finanzielle Regelung zu Rechnungen, Gutschriften, Lastschriften usw. an.

zurück nach Oben

RFID- Middleware

Mit der Technologie von RFID (Radio Frequency Identification) können Daten zwischen einem an einem Objekt (z.B. Artikel, Packstück, Behälter usw.) angebrachten Datenträger (Transponder, Tag) und einem Lesegerät (Scanner) durch elektromagnetische Wechselfelder übertragen werde, ohne Sichtkontakt und sogar bei bewegten Objekten. Das zukünftige Einsatzgebiet ist mannigfaltig, zur Zeit erproben insbesondere große Handelsunternehmen und deren Lieferanten in Szenarien der Logistik und des SCM (Supply Chain Managements) die Einführung. über RFID- Tags können Stati und Prozesse an beliebigen Stellen identifiziert und kontrolliert werde, bei der Fertigung von Produkten, der Lagerung, Kommissionierung, Verpackung und Verbringung in Behältern, dem Transport und der Behandlung in Logistikketten. Hier wird RFID in Zukunft die Barcode- Technik ergänzen.

Der Nutzen von RFID kann jedoch nur dann realisiert werden, wenn die RFID- Technologie mit der bestehenden Unternehmenssoftware integriert ist, wenn die gewonnenen Daten in den verschiedenen Anwendungssystemen für SCM, ERP usw. verwertet werden können. Die derzeitigen Anwendungssysteme sind in der Regel noch nicht auf RFID- Schnittstellen eingerichtet. Die Schnittstellen der Barcode- Technik reichen nicht aus.

Bei der Integration besteht ein wesentlicher Unterschied zwischen der RFID-Technik und der Barcode- Technik in dem bedeutend größeren Datenvolumen, das bei RFID übertragen wird. Dieses Datenvolumen muss einerseits für das jeweilige Anwendungssystem auf das zutreffende Maß reduziert werden. Andererseits bietet das große Angebot an Information die Möglichkeit, diese nicht - wie beim Barcode üblich - nur an ein Anwendungssystem zu übertragen, sondern durch eine entsprechende Intelligenz selektiert verschiedenen Systemen, unternehmensintern und unternehmensübergreifend, z.B. entlang Logistikketten oder Produktionsketten, zur Verfügung zu stellen.

Eine RFID- Middleware muss die Anforderungen für die Integration von RFID in die bestehende IT- Infrastruktur erfüllen. Die Schnittstelle zur RFID- Hardware sollte über entsprechende Adapter die unterschiedlichen Technologien der verschiedenen Anbieter bedienen können. Die übertragenen Daten werden in einer Datenbank gespeichert und anhand von Regeln und Filtern auf ihre Relevanz für definierte Prozesse überprüft, für die jeweils angesprochenen Anwendungssysteme selektiert, auf das notwendige Maß reduziert, für die jeweilige Schnittstelle aufbereitet und an das Anwendungssystem geleitet.

Bis hierhin entspricht die Aufgabenstellung im Prinzip derjenigen von EAI - Szenarien (bis auf die zusätzlichen Adapter zur RFID- Hardware). Dementsprechend werden sich Softwareanbieter für EAI auf die RFID- Technologie einstellen. Dies um so mehr, da die derzeitigen Anwendungssysteme überwiegend nur auf die Verarbeitung von importierten Daten eingerichtet sind, die aus den heutigen EAI- Szenarien (z. B. aus Schnittstellen korrespondierender Anwendungssysteme, aus Barcode- oder BDE- Schnittstellen, aus EDI- Schnittstellen mit externen Partnern) zur Verfügung stehen. So kann RFID parallel zur Weiterentwichlung der Anwendungssoftware über eine Erweiterung der EAI- Szenarien schrittweise in die IT- Struktur eines Unternehmens eingeführt werden.

Der Einsatz von RFID bringt besonders dann eine erhebliche Steigerung von Wirtschaftlichkeit und Qualität, wenn durch die erfassten Daten Abweichungen und Störungen des Ablaufs von Geschäftsprozessen gegenüber diesbezüglichen Vorgaben erkannt und entsprechende Maßnahmen zu deren Behebung eingeleitet werden, soweit als möglich automatisiert. In der Logistik und beim Supply Chain Management bekommt RFID durch diese Funktionalität einen hohen Stellenwert. Die Anreicherung mit RFID- on- line erfasster Information ermöglicht die Erweiterung altbekannter Verfahren des Tracking & Tracing, d.h. der Nachverfolgung und online- Disposition von Waren, zu einem Supply Chain Event Management (SCEM) unter Einschluss von Ladungsträgern und Fahrzeugen. SCEM verbindet die Verfolgung der Geschäftsprozesse in Echtzeit mit Frühwarnmechanismen und steigert damit die Qualität bezüglich Warnungen, Entscheidungshilfen und Steuerungsmechanismen bei unvorhergesehenen Ereignissen.

Die Hersteller von SCM- Software werden zunehmend SCEM in ihre Produkte integrieren. In Logistikketten werden jedoch oftmals SCM- Softwaresysteme unterschiedlicher Hersteller eingesetzt, deren unterschiedliche Schnittstellen dann zu überbrücken sind. Das spricht dafür, SCEM in Kombination mit einer für die Branche Logistik angepassten RFID- Middleware einzuführen. Die Integration und Interaktion zwischen unterschiedlichen SCM- Systemen der an Logistikketten beteiligten Partnern ist eine typische Aufgabenstellung für eine entsprechende Dienstleistung zum EAI.

RFID ist der Anlass und die Basis- Technologie für die Einführung des Electronic Product Code (EPC) für die Identifikation von Objekten und der unternehmensübergreifenden Bereitstellung von Produktinformation über das internetbasierte EPC- Informationsnetzwerk. GS1 und GS1 US (vormals EAN International und Uniform Code Council) und die internationale Entwicklungsplattform EPCglobal treiben diese Entwicklung voran. Informationen über den aktuellen Status sowie die gesamte Historie von Produkten sollen jederzeit online abgerufen werden können.

Mit dem Open System Integration Server OSIS kann RFID an die Anwendungssysteme eines Unternehmens oder mehrerer Unternehmen angebunden werden, und die Anwendungssysteme der Unternehmen können über OSIS entweder direkt kommunizieren oder an Plattformen wie das zukünftige EPC- Informationsnetzwerk angeschlossen werden.

zurück nach Oben

RPC Remote Procedure Call

Durch einen "entfernten Funktionsaufruf" (RPC) kann ein Programm auf einem Client ein Programm auf einem Server als Unterprogramm aufrufen. Hierbei können zwischen den Programmen, trotz der unterschiedlichen Adressräume, Parameter ausgetauscht werden.

Das Programm auf dem Client ruft mit einem lokalen Prozeduraufruf einen Stub ("Stummel") auf dem Client auf, der die Parameter einpackt und den entfernten Aufruf über die Betriebssysteme der beiden Rechner an den Stub des Servers sendet. Dieser packt die Parameter aus und ruft mit einer lokalen Prozedur das Programm auf dem Server auf. Das Ergebnis aus dem Programmaufruf wird vom Server- Stub wieder verpackt, über die Betriebssysteme an den Client- Stub übertragen, von diesem ausgepackt und dem aufrufenden Programm übergeben.

Die RPC- Schnittstellen können durch den Einsatz von Middleware realisiert werden, für die Konvertierung der Daten, die Durchführung der Transaktionen und die Organisation im Fehlerfall (Kommunikationsfehler oder Ausfall auf der Server- oder Client- Seite). Verwenden die Kommunikationspartner die gleiche Programmiersprache, kann die Realisierung in dieser erfolgen (Beispiel: Remote Method Invocation in Java), oder steht auf beiden Seiten das gleiche Protokoll für den entfernten Methodenaufrufe zur Verfügung, kann ein Object Request Broker (ORB) in einer verteilten objektorientierten Architektur (Beispiel: CORBA oder DCOM) genutzt werden. Bei der Kommunikation über Internet ist ein Nachteil, dass Datenpakete auf dem Weg zwischen ORBs durch Firewalls leicht ausgefiltert werden können. Beim Einsatz SOAP und http ist dies nicht der Fall.

Der beschriebene RPC- Ablauf ist synchron, das Programm auf dem Client wird so lange blockiert, bis das Ergebnis vom Server zurückkommt. Bei einer asynchronen nachrichtenorientierten Kommunikation können die Nachrichten zwischen Client und Server in einer Message oriented Middleware (MOM) zwischen gespeichert werden. Dadurch geht keine Information verloren für den Fall, dass Server oder Client zum Zeitpunkt des Aufrufs nicht verfügbar sind.

OSIS, der Open System Integration Server, kann als Middleware für RPC, auch in Kombination mit anderen Verfahren der Kommunikation in komplexen EAI- und EDI- Szenarien, eingesetzt werden.

zurück nach Oben

RTE Real Time Enterprise

In einem "Realtime Enterprise" sollen Verzögerungen und Fehler bei der Ausführung von Geschäftsprozessen vermieden werden, indem jederzeit die relevante Information zum richtigen Zeitpunkt am richtigen Ort vorliegt. Durch eine verzögerungsfreie Reaktion auf interne und externe Ereignisse soll die Wettbewerbsfähigkeit durch die Reduktion von Zeit und Kosten verbessert werden.

Die Forderung nach "Echtzeit" kann jedoch nicht so verstanden werden, dass ein Ereignis und die diesbezügliche Handlung zur selben Uhrzeit erfolgen. Insofern kann der Begriff Realtime Enterprise als eine Vision für die Unternehmensstruktur verstanden werden, als ein Ansporn für eine Zielsetzung, die niemals vollständig erreicht wird. Zwischen dem Ort und Zeitpunkt des Entstehens von Information und dem Ort und Zeitpunkt der Handlung wird, abgesehen von automatisierten Prozessen, stets eine Differenz bleiben. In vielen Fällen ist es durchaus angebracht, eine Aktion erst nach dem Sammeln von Information über einen gewissen Zeitraum durchzuführen.

Die Prozessintegration ist eine wesentliche Voraussetzung für die Realisierung von RTE. Business Process Management (BPM) ist hierzu eine geeignete Verfahrensweise. Die Geschäftsprozesse sind zu modellieren und digital zu erfassen. Das Geschäftsprozessmodell ist auf die Logik der zur Verfügung stehenden IT- Anwendungen wie zum Beispiel ERP, WWS, CRM abzubilden, gegebenenfalls sind die IT- Anwendungen anzupassen oder zu erweitern, u. U. unter Einrichtung einer Service orientierten Architektur (SOA). Für die Integration der IT- Anwendungen und für das Monitoring des Ablaufs können Verfahren des EAI und des Workflow Managements zum Einsatz kommen, Data Warehouse Systeme liefern aufbereitete Ist- Daten und Kennziffern. Abweichungen zwischen dem "Soll" und "IST" sind zu kontrollieren, soweit möglich automatisiert oder vom Anwender aufbereitet, unter Nutzung entsprechender Schnittstellen. Gegebenenfalls sind die lang- oder kurzfristigen Planungen zu ändern. Bei systematischen Abweichungen ist das Geschäftsprozessmodell zu überarbeiten.

In dem so beschriebenen RTE- Zyklus besteht bei der Überführung des fachlichen Modells in die informationstechnische Realisierung noch eine Schwachstelle, wie allgemein beim BPM.