Die Erfindung betrifft ein System zum Bereitstellen von Daten nach dem Oberbegriff des Anspruchs 1, d.h. von Daten mit Informationen über Geschäftsereignisse, die innerhalb eines Geschäftsprozesses auftreten. Außerdem betrifft die Erfindung ein von dem System ausgeführtes Verfahren nach dem Oberbegriff des nebengeordneten Anspruchs.

In vielen technischen Anwendungen müssen Geschäftsprozesse verwaltet und überwacht werden, um beispielsweise die technischen Abläufe in einem Kassensystem oder dergleichen ereignisbezogen steuern zu können. Unter einem Geschäftsprozess wird im Allgemeinen die Abfolge von Einzeltätigkeiten bzw. Schritten verstanden, die zur Erreichung eines geschäftlichen oder betrieblichen Ziels durchgeführt werden. Geschäftsprozesse können im Gegensatz zu Projekten öfters durchlaufen werden. Auch kann ein Geschäftsprozess wiederum Teil eines anderen

Geschäftsprozesses sein oder andere Geschäftsprozesse enthalten bzw. diese anstoßen. Innerhalb eines Geschäftsprozesses wiederum treten Geschäftsereignisse auf, sog. Business-Events. Darunter versteht man insbesondere die vor oder nach einem jeweiligen Schritt auftretenden Zustände. Aus der DE 102007046049A1 sind ein System und ein Verfahren zur Unterstützung der Schaffung bzw. Erzeugung von Geschäftsprozessen bekannt. Die dort beschriebene Lösung betrifft insbesondere das Bestimmen eines optimalen Geschäftsprozess-Modells für ein gegebenes Geschäft, insbesondere das Aufstellen einer Geschäfts-Elementenliste anhand von Geschäftsprozess-Vorlagen . Mit dem Verwalten oder Auftreten der Geschäftsereignisse befasst sich die Druckschrift nicht. Jedoch ist es wünschenswert, dass auch das Verwalten von auftretenden Geschäftsereignissen innerhalb eines Geschäftsprozesses mit technischen Mitteln möglichst effizient umgesetzt werden kann.

Zur Darstellung der Ausgangslage der Erfindung wird nachfolgend auf die Fig. 1 und die Fig. 2 Bezug genommen, welche den derzeitigen Stand der Technik wiedergeben:

Die Fig. 1 zeigt in einer schematischen Darstellung einen Geschäftsprozess GP mit seinen einzelnen Elementen sowie mehrere Datenkonsumenten K, die über auftretende Geschäftsereignisse informiert werden sollen. Der Geschäftsprozess GP kann beispielsweise das Verwalten eines Kassenbestandes in einem Kassensystem betreffen, so wie dies anhand der Fig. 2 dargestellt ist. Als Datenkonsumenten K kommen sowohl Personen KA wie auch Systemkomponenten KB, KC, KD bis KN infrage. Üblicherweise umfasst ein Geschäftsprozess GP einzelne Geschäftsereignisse, die innerhalb des ablaufenden Geschäftprozesses austreten können, wie hier z.B. die Geschäftsereignisse GE1, GE2, GE3 bis GEZ. Beim Übergang von einem Geschäftsprozess zum nächsten (s. beispielsweise Übergang von GE1 auf GE2) wird üblicherweise eine Geschäftsfunktion FKT ausgeführt. Hierbei kann es sich um eine von einer Person durchgeführte Funktion handeln sein, wie zum Beispiel das Ermitteln eines aktuellen Kassenbestands durch Zählen der vorhandenen Geldmittel. Die Person nimmt dabei eine bestimmte Rolle R ein, hier zum Beispiel die Rolle des Kassierers. Eine Geschäftsfunktion FKT kann auch durch eine technische Vorrichtung ausgeführt werden, wie beispielsweise das Versenden von Bestellungen und dergleichen. Zur Ausführung einer Geschäftsfunktion sind in der Regel Eingangsdaten DE erforderlich, die zum Beispiel Anzahl der vorhandenen Scheine und/oder Münzen betreffen. Eine Funktion kann dann bestimmte Ausgangsdaten liefern DA, wie z.B. die Parameter „Menge", „Stückelung" usw. für eine auszuführende Bestellung. Ein solcher Geschäftsprozess wird später noch anhand der Fig. 2 näher beschrieben.

Wie die Fig. 1 darstellt, werden üblicherweise die einzelnen auftretenden Geschäftsereignisse GE1, GE2 bis GEZ direkt an den oder die von dem Ereignis betroffenen Konsumenten übertragen. In dem hier dargestellten Beispiel wird der Konsument KA von dem Auftreten der Geschäftsereignisse GE1 und GE2 direkt informiert. Dazu werden für den jeweiligen Konsumenten Daten mit Informationen über das jeweils auftretende Geschäftsereignis übertragen. Im dargestellten Beispiel erhält der Konsument KB, bei dem es sich um einen Server handeln kann, ebenfalls die Daten über die Geschäftsereignisse GE1 und GE2. Ein anderer Konsument, nämlich der Server KD, erhält hingegen Daten von den auftretenden Geschäftsereignissen GE2, GE3 und/oder GE4. Das bedeutet, dass für jedes auftretende Ereignis eine auf den oder die betroffenen Konsumenten zugeschnittene

Datenaufbereitung und Datenübertragung durchgeführt werden muss. Konkret kann das bedeuten, dass bestimmte von den Konsumenten benutzte Formate und/oder Übertragungsstandards eingehalten werden müssen. Das wiederum verursacht einen hohen technischen Aufwand und somit Kosten bei der Realisierung einer solchen herkömmlichen Lösung.

Die Fig. 2 stellt exemplarisch den Ablauf eines typischen Geschäftsprozesses GP dar, der in einem Kassensystem durchgeführt wird. Der Geschäftsprozess umfasst mehrere Geschäftsereignisse 100, 200, 300 usw., die hier durch Rauten-Symbole dargestellt sind, sowie Funktionen 110, 210, 310 usw., die durch abgerundete Rechtecke dargestellt sind. Außerdem sind logische Verknüpfungen 220 und 520 zu berücksichtigen, die hier als kreisrunde Symbole dargestellt sind. Zudem umfasst der Geschäftsprozess GP noch Dateneingaben sowie Datenausgaben, die durch Rechteck-Symbole dargestellt sind. Bestimmten Funktionen, wie hier beispielsweise die Funktion 110, können bestimmten Rollen zugeteilt sein, hier z.B. der Rolle bzw. der Person des Kassierers .

Nachfolgend wird der in der Fig. 2 aufgezeigte Geschäftsprozess im Einzelnen beschrieben:

Der Geschäftsprozess GP beginnt mit dem Geschäftsereignis 100, welches die Zeit zur täglichen Bestellung von Zahlungsmitteln in Form von Scheinen und/oder Münzen zur Bestückung des Kassensystems angibt. Darauf folgt eine Funktion 110, bei der der aktuelle Kassenbestand geprüft wird. Diese Funktion wird durch den Kassierer ausgeübt. Dazu erfolgt eine Dateneingabe 101, die die Anzahl der im Bestand gezählten Scheine und/oder Münzen umfasst. Als Ergebnis der Funktion 110 erhält man die Datenausgabe 102, welche die Daten für den aktuellen Bestand des Kassensystems bzw. Cash- Point angibt. Das führt zu dem Geschäftsereignis 200, welches bedeutet, dass der aktuelle Kassenstand ermittelt worden ist. Nachfolgend wird die Funktion 210 ausgeführt, welche eine Entscheidung betrifft, ob eine Bestellung von weiteren Zahlungsmitteln erforderlich ist oder nicht. Als Dateneingabe 202 werden Parameter angegeben, wie etwa Liefertage, Versicherungsgrenze bezgl. der maximal möglichen Bestellung oder Logistikschwelle bezgl. der maximal möglichen Bestellung. Als weitere Dateneingabe 203 kann auch die Bestandsentwicklung eines vorhergegangenen Zeitraums herangezogen werden. Mit diesen Dateneingaben kann die Funktion 210 ausgeführt werden, wodurch eine logische Verknüpfung 220 bzw. Auswertung der Daten dazu führt, dass entweder das Geschäftsereignis 300 auftritt oder das Geschäftsereignis 300*. Das Geschäftsereignis 300 bedeutet, dass eine Bestellung von weiteren Zahlungsmitteln erforderlich ist. Hingegen bedeutet das Geschäftsereignis 300*, dass eben keine Bestellung notwendig ist.

Tritt das Geschäftsereignis 300 ein, so folgt die Funktion 310, welche die Ermittlung des tatsächlichen Bedarfs betrifft. Als Eingabedaten wird in Block 301 wiederum die Bestandsentwicklung der vorhergegangenen Zeit berücksichtigt. Als Datenblock 302 werden die Daten bezüglich der zugelassenen Liefertage, Versicherungslimit usw. angegeben. Weitere Daten 303 können beispielsweise Parameter angegeben, die Sonderereignisse anzeigen, wie beispielsweise Feste oder Großereignisse etc.. Aus der Funktion 310 ergibt sich als Datenausgang die Information 304 bezüglich der Ver- und Entsorgung pro Geldkassette bzw. Cash-Point. Daran anschließend ergibt sich aus der Funktion 310 dann das Geschäftsereignis 400, welches angibt, dass der Bedarf ermittelt worden ist. Daran folgt die Funktion 410, die das Erstellen einer konkreten Bestellung für den betreffenden Cash-Point betrifft. Als Dateneingabe 401 werden Informationen berücksichtigt, die beispielsweise die Bestellwege und ähnliche Daten betreffen. Als Datenausgabe erfolgt dann die Angabe über die Bestellung pro Bestellweg (siehe Block 402) .

Daraus ergibt sich dann das Geschäftsereignis 500, welches angibt, dass die Filialbestellung erstellt worden ist. Daran schließt sich die Funktion 510 an, die das Versenden der Bestellung betrifft. Ist die Bestellung verwandt worden, so können aufgrund der Verknüpfung 520 folgende

Geschäftsereignisse auftreten: Zum einen das

Geschäftsereignis 600, das anzeigt, dass die Bestellung verwendet worden ist. Des weiteren das Ereignis 600*, welches angibt, dass eine Bestellung avisiert wird. Schließlich noch das Ereignis 600**, das angibt, dass die Bestellung abgeschlossen ist.

Der hier dargestellte Geschäftsprozess GP betrifft also die Abwicklung der Bestandsaufnahme und der Bestellung von Zahlungsmitteln in einem Kassensystem bzw. Cash-Point. Die Erfindung geht insbesondere von solchen Geschäftsprozessen aus, soll aber auf beliebige Geschäftsprozesse anwendbar.

Wie anhand der Figuren 1 und 2 veranschaulicht wurde, werden im Stand der Technik die Daten über die jeweils auftretenden Geschäftsereignisse einzeln und direkt an die jeweiligen Konsumenten in den gewünschten Formaten bzw.

Übertragungsformen übertragen. Dies jedoch verursacht einen hohen technischen Aufwand.

Demnach ist es Aufgabe der Erfindung, ein System und ein Verfahren zum Bereitstellen von Daten über Informationen von auftretenden Geschäftsereignissen vorzuschlagen, bei dem möglichst viele und auch unterschiedlichste Konsumenten jederzeit die für sie erforderlichen Daten abrufen können. Das vorgeschlagene System und Verfahren soll auch skalierbar sein, um steigende Anforderungen hinsichtlich der Anzahl der Konsumenten und/oder des aufkommenden Datenvolumens effizient erfüllen zu können.

Gelöst wird die Aufgabe durch ein System mit den Merkmalen des Anspruchs 1 sowie durch ein Verfahren mit den Merkmalen des nebengeordneten Anspruchs.

Demnach wird vorgeschlagen, dass das System eine zentrale Daten-Diensteinheit aufweist, die eingangsseitig

Eingangsdaten über auftretende Geschäftsereignisse empfängt und diese Eingangsdaten aufbereitet, um daraus Ausgangsdaten zu bilden, welche dann ausgangsseitig mittels einer vorgebbaren Datenausgabe-Schnittstelle für den Abruf durch externe Datenkonsumenten bereitgestellt werden. Gemäß dem erfindungsgemäßen Verfahren werden in einem zentralen Datendienst folgende Schritte ausgeführt: Empfangen von Eingangsdaten über auftretende Geschäftsereignisse; Aufbereiten der Eingangsdaten zum Speichern in der Datenbank sowie Speichern derselben; und Bilden sowie Bereitstellen von Ausgangsdaten zum Abruf durch externe Datenkonsumenten.

Demzufolge schlägt die Erfindung vor, dass an einer zentralen Stelle bzw. innerhalb eines zentralen Datendienstes alle Eingangsdaten betreffend auftretender Geschäftsereignisse aufbereitet und für den Abruf über mindestens eine Datenausgabe-Schnittstelle bereitgestellt werden. Somit wird anstelle einer Einzelfall-bezogenen Übertragung von Daten zu jedem einzeln auftretenden Geschäftsereignis ein zentraler Datendienst für alle Geschäftsereignisse geschaffen, wobei die Daten über die auftretenden Geschäftsereignisse in einer zentral aufbereiteten Form über mindestens eine Datenausgabe- Schnittstelle zur Verfügung gestellt werden.

Das Empfangen und Sammeln von Eingangsdaten in dem zentralen Datendienst erfolgt vorzugsweise im Rahmen einer Push- Übertragung, d.h. die Eingangsdaten werden von den Geschäftsfunktionen automatisch an den zentralen Datendienst übermittelt, sobald ein neues Geschäftsereignis eintritt. Das geschieht z.B. durch einen sog. Publish Subscribe Mechanismus. Ausgangsseitig wiederum erfolgt eine zentrale Bereitstellung der aufbereiteten Daten, indem vorzugsweise eine einheitliche Datenausgabe-Schnittstelle eingerichtet eingerichtet wird, über die externe Datenkonsumenten bei Bedarf zugreifen und die Daten bezüglich der auftretenden Geschäftsereignisse abrufen können. Dies erfolgt vorzugsweise im Rahmen einer Pull-Übertragung .

Diese und weitere Vorteile ergeben sich auch aus den Unteransprüchen .

Nachfolgend wird die Erfindung anhand eines Ausführungsbeispiels und unter Bezugnahme auf die beiliegenden Figuren näher beschrieben, welche folgende schematischen Darstellungen zeigen:

Fig. 3 zeigt in einem funktionalen Schema die Einrichtung eines zentralen Datendienstes;

Fig. 4 zeigt in einem strukturellen Schema den Aufbau eines erfindungsgemäßen Systems mit einer zentralen Datendienst-Einheit; und Fig. 5 zeigt in einem Ablaufdiagramm die Schritte eines erfindungsgemäßen Verfahrens.

Die Fig. 3 zeigt in einer schematischen Darstellung die Einrichtung eines zentralen Datendienstes ZD, der zwischen den Konsumenten K und dem jeweiligen Geschäftsprozess GP angelegt ist. Im Vergleich mit der Fig. 1 wird deutlich, dass der zentrale Datendienst ZD möglichst alle in dem Geschäftsprozess GP auftretenden Ereignisse GEl, GE2, GE3 ... zentral erfasst bzw. sammelt und dann in einer aufbereiteten Form zum Abruf durch die Datenkonsumenten KA, KB, KC ... KM bereitstellt. Anhand der Fig. 3 wird auch ersichtlich, dass die vorgeschlagene Lösung insbesondere hinsichtlich des Zuwachses von Datenkonsumenten K sehr gut skalierbar ist. Der zentrale Datendienst hat insbesondere den Vorteil, dass die Ausgabe bzw. der Abruf von Daten über eine vorgebbare Schnittstelle erfolgen kann.

Die Fig. 4 zeigt in einer schematischen Darstellung den Aufbau eines Systems SYS mit einer zentralen Datendienst- Einheit ZDE, die eingangsseitig Eingangsdaten Dl - Dn) bezüglich der auftretenden Geschäftsereignisse GE - GEn empfängt und die ausgangsseitig nach Aufbereitung der Daten entsprechende Ausgangsdaten DA - Dm zum Abruf durch die Datenkonsumenten KA - Km bereitstellt. Die zentrale Datendienst-Einheit ZDE ist eingangsseitig über eine entsprechende Schnittstelle IN mit Knotenpunkten, insbesondere mit Geschäftsfunktions-Einheiten GFE, verbunden, um Eingangsdaten Dl - Dn bezüglich auftretender Geschäftsereignisse GEl, GE2 ... GEN zu empfangen. Die zentrale Datendienst-Einheit ZDE umfasst dazu insbesondere ein erstes Modul BES, das mit der Dateneingabe-Schnittstelle IN verbunden ist, und die Eingangsdaten Dl - Dn empfängt und diese aufbereitet. Zu der Datenaufbereitung gehört auch die Umsetzung der Daten in ein vorgebbares Format F sowie das Hinzufügen von Zusatzdaten bzw. Meta-Daten, wie z.B. Zeitstempel und dergleichen.

Die zentrale Datendienst-Einheit ZDE umfasst auch ein mit dem ersten Modul BES verbundenes zweites Modul BET, das wiederum mit der Datenausgabe-Schnittstelle OUT verbunden ist. Das zweite Modul bildet aus den aufbereiteten Daten, welche von dem ersten Modul BES kommen, Ausgabedaten, die dann für die jeweiligen Datenkonsumenten KA, KB ... bereitstellt werden. Beispielsweise werden für den Konsumenten KA Ausgabedaten DA bereitgestellt, welche bei einer Anfrage RA durch den Konsumenten KA dann übertragen werden. Diese Ausgabedaten DA können z.B. Informationen über das auftretende Geschäftsereignis GE1 wie auch das auftretende Geschäftsereignis GE2 enthalten (vgl. Fig. 1) . Jedoch werden die Ausgabedaten nicht ereignisbezogen und automatisch ausgeliefert, sondern stehen zum Abruf über die Ausgabeschnittstelle OUT bereit. Dadurch kann der jeweilige Datenkonsument bedarfsweise die für ihn relevanten Ausgabedaten abrufen.

Die Ausgabedaten DA - Dm werden vorzugsweise in einem bestimmten Format F* bereitgestellt, das auch passend für die Ausgabedaten-Schnittstelle OUT definiert ist. Das zweite Modul BET weist auch eine Datenbank DBS auf, in der die aufbereiteten Eingangsdaten bzw. die daraus gebildeten Ausgangsdaten für den späteren Abruf gespeichert werden. Die in der Fig. 4 dargestellten beiden Module BES und BET können auch in einer Einheit realisiert werden. Um zumindest die logische Differenzierung besser zu veranschaulichen, wird hier jedoch die Darstellung von zwei Modulen BES und BET bevorzugt .

Als Eingangsdaten Dl - Dn werden Informationen über die auftretenden Geschäftsereignisse GEl - GEn werden auch solche Daten erfasst, die insbesondere folgende Parameter bzw. Attribute umfassen: eine eindeutige Kennung bzw. ID, eine Versionsnummer, ein Erzeugungsdatum, eine Geschäfts- Transaktionsnummer, Laufzeitparameter , Benutzer-Informationen und/oder Mandanten-Informationen. Der Umfang der gelieferten Eingangsdaten Dl - Dn bestimmt sich insbesondere durch die Geschäftsfunktions-Einheit GFE und das auftretende Geschäftsereignis. In dem ersten Modul BES können noch zusätzliche Daten, wie z.B. Zeitstempel oder dergleichen hinzugefügt werden. Ein Merkmal des ersten Moduls BES ist es, eine einheitliche Dateneingabe-Schnittstelle IN zur Verfügung zu stellen, um eine zentrale Anbindung der Einheit ZDE an bestehende Systeme (z.B. Kassensysteme) zu ermöglichen.

Innerhalb des ersten Moduls, das auch als Business-Event- Service bezeichnet werden kann, erfolgt auch eine

Aufbereitung der Eingangsdaten Dl - Dn bzw. eine Formatierung dieser Daten. Das Hinzufügen bzw. Anreichern von Daten durch Zusatzdaten, wie z.B. Zeitstempel, ermöglicht eine

umfangreichere Zwischenspeicherung in dem nachgeschalteten zweiten Modul BET. Dieses zweite Modul BET kann auch als Business-Event-Topic bezeichnet werden, und stellt

insbesondere die Datenausgabe-Schnittstelle zum Zugriff für beliebige Konsumenten bereit. Das zweite Modul BET bereitet nicht nur die Ausgangsdaten DA - Dn auf, sondern stellt diese mittels Speicherung auch zentral zum Abruf bereit.

Beispielsweise können die Datenkonsumenten KA, KB ... sich für einen automatischen Ausgabedienst eintragen. Dann wird ähnlich einem Abonnement die Datenausgabe regelmäßig

ausgeführt. Neben der Registrierung kann auch eine

Authentifizierung an der Ausgabeschnittstelle OUT vorgesehen sein, so dass unbefugte Konsumenten von dem Abruf von Daten ausgeschlossen sind. Es kann vorgesehen sein, dass bei der Registrierung auf die Ereignisse jeder Konsument, der sich registriert, Filter definieren kann, die sich z.B. auf IDs des Events, Zeitstempel, etc. beziehen.

Die Fig. 5 stellt in einem Ablaufdiagramm die wesentlichen Schritte des erfindungsgemäßen Verfahrens dar. Das Verfahren

10 weist die Schritte 11 bis 15 auf. In einem ersten Schritt

11 werden die Eingangsdaten Dl - Dn (siehe auch Fig. 4) von der zentralen Datendienst-Einheit empfangen. In einem nachfolgenden Schritt 12 werden die Daten aufbereitet, wobei sie insbesondere in ein vorgebbares Format umgesetzt werden. Außerdem werden Zusatzdaten bzw. Metadaten hinzugefügt. Dann wird in einem Schritt 13 eine Zwischenspeicherung der Daten in einer Datenbank ausgeführt. In einem weiteren Schritt 14 folgt das Bilden und Bereitstellen von Ausgabedaten, wie z.B. der Daten DA (siehe Fig. 4). Die eigentliche Ausgabe erfolgt in einem Schritt 15 durch Abruf bzw. Anfrage RA (siehe Fig. 4) . Dabei gibt die Datenausgabe-Schnittstelle OUT die Ausgabedaten in einem bestimmten Format F* aus.

Zusammenfassend schlägt die Erfindung einen zentralen Datendienst vor, der Daten bezüglich auftretender Geschäftsereignisse in einem Geschäftsprozess für Datenkonsumenten auf Abruf bzw. bei Bedarf bereitstellt. Die Daten werden in einer aufbereiteten Form und über eine definierte Ausgabe-Schnittstelle zur Verfügung gestellt, so dass das vorgeschlagene System und Verfahren sehr einfach hinsichtlich wachsender Anzahl von Konsumenten und auftretenden Datenvolumen skalierbar ist.