-
Die
Erfindung betrifft ein Verfahren zur Koordinierung dezentraler Systeme
für ein
Eventmanagement. Bei den Events handelt es sich um große Veranstaltungen,
etwa Olympische Spiele, Weltmeisterschaften, Konzerte oder Konferenzen.
Veranstaltungsort hierfür
sind etwa Stadien, Arenen, Hallen oder auch Multifunktionshallen
oder -arenen, sowie Messen. Um ein solches Event zu managen, müssen eine
Reihe dezentraler Systeme koordiniert werden. Bei den dezentralen
Systemen handelt es sich um Anwendungen aus den Bereichen Ticketverkauf,
Zutrittskontrolle für
Zuschauer, Zutrittskontrolle für
akkreditierte Personen wie Mitarbeiter, Sportler, Presse oder VIPs,
elektronische Zahlung, Callcenter, Leitstelle für Sicherheit, Feuerschutz oder
Notarzt, Parkraumverwaltung, öffentliche
Verkehrsmittel uvm. In den meisten dieser dezentralen Systeme werden große Datenmengen
bearbeitet, teilweise auch mit hohen Zeitanforderungen. So müssen etwa
bei einem Stadion für
100.000 Zuschauer alle 100.000 Zuschauertickets in einem Zeitfenster
weniger Stunden bei der Zutrittskontrolle elektronisch überprüft werden.
Weiterhin muss ein am Veranstaltungsort verkauftes Ticket unmittelbar
vom Ticketverkauf zur Zutrittskontrolle übermittelt werden, da die Zutrittskontrolle
direkt nach dem Ticketverkauf erfolgt. Auch die Akkreditierung kann
bei einer großen
Veranstaltung zehntausende Personen umfassen.
-
Für einen
reibungslosen Verlauf des Events ist es erforderlich, dass die dezentralen
Systeme zueinander konsistente Datenbestände haben und miteinander synchronisiert
werden. Wegen der hohen Datenaufkommen und den Zeitanforderungen
kann dieses nur durch elektronische Kommunikation zwischen den dezentralen
Systemen erfolgen.
-
Eine
solche Kommunikation erfolgt im Stand der Technik lediglich bilateral
zwischen Zutrittskontrolle und Ticketverkauf. Heutige dezentrale
Systeme weisen höchst
unterschiedliche Schnittstellen auf. Dies erschwert die Planung
und Durchführung
von Events, da diese mit komplexen Prozessen verbunden sind. Eine
Koordinierung der dezentralen Systeme zur Planung und Durchführung eines
Events ist somit nur unter erheblichem personellen Aufwand möglich. Für die Planung
wird in dieser Domäne
bislang hauptsächlich
manuell mit Excel-basierten Checklisten gearbeitet.
-
Es
stellt sich somit die Aufgabe, ein Verfahren zur Koordinierung dezentraler
Systeme für
ein Eventmanagement anzugeben, mit welchem die bisher händischen
und daher aufwändigen
Planungsprozesse automatisiert werden können.
-
Diese
Aufgabe wird durch das Verfahren nach Anspruch 1 gelöst. Bevorzugte
Weiterbildungen ergeben sich aus den abhängigen Ansprüchen.
-
Bei
dem Verfahren zur Koordinierung dezentraler Systeme für ein Eventmanagement
werden Zeitdaten und Aktionsmuster zur Planung und Durchführung eines
Events in einem Planungssystem elektronisch gespeichert. Anhand
der Zeitdaten und Aktionsmuster werden Prozessschritte zur Planung
und Durchführung
des Events in den dezentralen Systemen koordiniert, indem Befehle
aus einem vorgegebenen Befehlssatz über eine einheitliche Schnittstelle
zwischen dem Planungssystem und den dezentralen Systemen ausgetauscht
werden.
-
Das
Computerprogramm wird in einem Prozessor abgearbeitet und führt dabei
das Verfahren aus.
-
Auf
dem computerlesbaren Datenträger
ist ein Computerprogramm gespeichert, welches das Verfahren ausführt, wenn
es in einem Prozessor abgearbeitet wird.
-
Das
Verfahren hat den Vorteil, dass in den dezentralen Systemen konsistente
Datenbestände hergestellt
werden können,
obwohl die dezentralen Systeme unabhängige Einheiten sind. Weiterhin
wird es möglich,
die dezentralen Systeme entsprechend einem vorgegebenen Aktionsmuster
miteinander zu koordinieren. Das Verfahren unterstützt so eine
effiziente Planung von unterschiedlichsten Eventarten und übernimmt
alle automatisierbaren Prozessschritte im Rahmen des Eventmanagements.
Somit wird über
die einheitliche Schnittstelle und das Planungssystem eine Integrationslösung für das Eventmanagement
geschaffen. Die einheitliche Schnittstelle ermöglicht eine höchstmögliche Flexibilität und Austauschbarkeit
unter den dezentralen Systemen. Dies ist gerade deshalb von Vorteil,
da für
die dezentralen Systeme eine Vielzahl kleiner und wechselnder Anbieter
am Markt existieren. Die Verwendung eines vorgegebenen Befehlssatzes
ermöglicht
eine Standardisierung und Optimierung der einheitlichen Schnittstelle.
-
In
einer Weiterbildung wird in dem Planungssystem für jedes Event ein eventbezogener
Datensatz gespeichert, der ein Datum des Events, einen Eventstatus
und einen Eventtyp enthält.
-
Durch
Aufnahme dieser drei Felder in einen entsprechenden Datensatz ergibt
sich der Vorteil, dass diese Felder als Basisparameter für die Koordinierung
der dezentralen Systeme herangezogen werden können.
-
In
einer besonderen Weiterbildung wird zur Planung und Durchführung des
Events ein Aktionsmuster gewählt,
welches dem Eventtyp entspricht.
-
Diese
Weiterbildung bietet den Vorteil, dass für unterschiedliche Eventtypen,
etwa Konzerte, Fußballspiele
oder Messen, spezifische Aktionsmuster im Planungssystem gespeichert
und zur Planung und Durchführung
eines Events mit dem jeweiligen Eventtyp herangezogen werden können.
-
Gemäß einer
Ausführungsform
sind die Aktionsmuster fest vorgegeben oder können durch einen Benutzer adaptiert
werden.
-
Die
Ausführungsform
bietet den Vorteil, dass vorgegebene Aktionsmuster entweder passend
zum jeweiligen Eventtyp bereitgestellt werden oder aber durch einen
Benutzer individuell an das jeweilige Event angepasst werden können.
-
Gemäß einer
weiteren Ausführungsform synchronisiert
ein dezentrales System einen eigenen Datenbestand mit Datenbeständen der
anderen dezentralen Systeme und des Planungssystems über einen
Befehl aus dem vorgegebenen Befehlssatz.
-
Der
Vorteil dieser Ausführungsform
liegt darin, dass etwa ein Event abgesagt werden kann, wenn bis
vier Wochen vor dem Event noch nicht ein vorgegebener Prozentsatz
von Tickets verkauft wurde. In diesem Fall sendet der Ticketverkauf
einen entsprechenden Befehl an das Planungssystem und die anderen
dezentralen Systeme, um das Event abzusagen.
-
In
einer Weiterbildung werden die Prozessschritte in den dezentralen
Systemen durch zeitabhängige
Trigger oder Benutzerinteraktionen im Planungssystem ausgelöst.
-
Diese
Weiterbildung bietet den Vorteil, dass entsprechend den jeweiligen
Anforderungen die Prozessschritte automatisch oder durch Benutzereingaben
vorangetrieben werden können.
-
Gemäß einer
besonderen Ausführungsform werden
die Prozessschritte in Abhängigkeit
von einem der Aktionsmuster (130) und aktuellen Werten von
Feldern des eventbezogenen Datensatzes ausgelöst.
-
Diese
Ausführungsform
ermöglicht
es insbesondere, das Eventmanagement dynamisch anhand der Aktionsmuster
und etwa dem aktuellen Eventstatus durchzuführen. Wechselt etwa der Eventstatus von
optional zu verbindlich, werden weitere Prozessschritte ausgelöst, die
einen verbindlichen Status des Events voraussetzen. Hierzu gehört etwa
der Ticketverkauf.
-
Gemäß einer
Weiterbildung werden bei der Koordinierung der Prozessschritte neben
den Zeitdaten und Aktionsmustern Nebenbedingungen berücksichtigt.
-
Dies
bietet den Vorteil, dass etwa notwendige Zeiträume zwischen Events etwa wegen
Auf- und Abbauzeiten eingeplant werden können. Die automatische Berücksichtigung
von Nebenbedingungen stellt sicher, dass die Zeitdaten im Planungssystem nicht
nur konsistent mit den Datenbeständen
der dezentralen Systeme gehalten werden, sondern in Bezug auf die
Durchführung
des Events auch realistisch sind.
-
In
einer Weiterbildung werden die Zeitdaten oder Aktionsmuster auf
einer Bedienoberfläche
für einen
Benutzer angezeigt.
-
Dies
bietet den Vorteil, dass die Zeitdaten etwa in Form eines Kalenders übersichtlich
dargestellt werden können.
Weiterhin können
die Aktionsmuster visualisiert und durch einen Benutzer bearbeitet
werden. Die Bedienoberfläche
kann auch die Nebenbedingungen anzeigen und ihre Bearbeitung ermöglichen.
-
Gemäß einer
Ausführungsform
besitzt jedes der dezentralen Systeme eine eigene Steuerungskomponente.
-
Diese
Ausführungsform
bietet den Vorteil, dass das Planungssystem speziell für eine übergeordnete
Koordinierung der dezentralen Systeme konzipiert werden kann. So
müssen
auch beim Ändern oder
Absagen eines Events nur entsprechende Informationen durch das Planungssystem
an die dezentralen Systeme weitergegeben werden. Alle weiteren, oft
sehr komplexen Folgeaktionen werden anschließend selbständig durch die dezentralen
Systeme ausgeführt.
-
Im
Folgenden wird die Erfindung anhand von Ausführungsbeispielen näher erläutert, die
in der Zeichnung schematisch dargestellt sind. Es zeigt:
-
1 ein
integriertes Eventmanagement-System,
-
2 ein
Aktionsmuster,
-
3 Tabellen
zur Bearbeitung eines Aktionsmusters.
-
1 zeigt
ein Ausführungsbeispiel
der Erfindung, hier eine Beispielarchitektur für ein integriertes Eventmanagement-System 9.
Das integrierte Eventmanagement-System 9 besteht
aus einem Planungssystem 1 und dezentralen Systemen 2.
Das Planungssystem 1 und die dezentralen Systeme 2 sind über eine
einheitliche Schnittstelle 3 verbunden. Die einheitliche
Schnittstelle 3 kann etwa als gemeinsame Middleware (Hardware
und/oder Software zur Kommunikation zwischen dem Planungssystem 1 und
den dezentralen Systemen 2) implementiert werden. Die einheitliche
Schnittstelle 3 stellt hierbei individuelle Schnittstellen
zu den jeweiligen dezentralen Systemen 2 bereit, da diese
oft über
proprietäre
Datenformate und Kommunikationsprotokolle verfügen. Solche individuellen Schnittstellen
können
etwa als Konnektoren implementiert werden.
-
Über die
einheitliche Schnittstelle 3 werden bidirektional Daten
zwischen den dezentralen Systemen 2 untereinander sowie
zwischen den dezentralen Systemen 2 und dem Planungssystem 1 ausgetauscht.
Bei den dezentralen Systemen 2 handelt es sich um unabhängige Einheiten,
die in der Regel über eigene
Datenbestände
und lokale Steuerungskomponenten verfügen.
-
Eine
graphische Benutzerschnittstelle (GUI), hier ein Portal-Framework-GUI 7,
ermöglicht
einen einheitlichen Zugriff auf alle Systeme. GUI-Integrationsschnittstellen 6 binden
die jeweiligen Systeme an das Protal-Framework-GUI 7 an.
Ein Auswertungsmodul 5 stellt eine gemeinsame Funktionalität zum Beobachten
(Activity Monitoring) und Bericht erstatten (Reporting) bereit.
Alle Systeme greifen auf gemeinsam genutzte Datenspeicher und Dienste 4 zu. Über einen
Single-Sign-On-Dienst 8 kann
ein einheitlicher Authentifizierungsmechanismus für alle Systeme
im Rahmen des Portal-Framework-GUI 7 genutzt werden. 1 zeigt
somit eine Gesamtarchitektur, welche eine Integrationslösung für ein Eventmanagement
bereitstellt. Die GUI-Integrationsschnittstelle 6 kann
etwa auf die Protokolle und Programmiersprachen HTTP, HTML, CSS
oder JAVA-Script zurückgreifen
und Möglichkeiten
zur Personalisierung und Vereinheitlichung der Benutzerschnittstellen
der einzelnen Systeme bereit stellen. Der Single-Sign-On-Dienst 8 kann
etwa über
LDAP oder PKI implementiert werden. Die einheitliche Schnittstelle 3 kann
etwa auf XML oder Web-Services beruhen.
-
Das
Planungssystem 1 besteht aus einem Event-Daten-GUI 11,
also einer Benutzerschnittstelle, welche das Eingeben, Anzeigen
und Bearbeiten aller eventbezogenen Daten erlaubt. Das Planungssystem 1 verwaltet
hierzu pro Event einen eventspezifischen Datensatz, der das jeweilige
Event charakterisiert. Für
jedes Event können
etwa ein zugehöriges
Datum, ein Eventstatus und ein Eventtyp in den Feldern des eventspezifischen
Datensatzes gespeichert werden. Weitere mögliche Felder sind Name, Veranstalter
oder Serientyp. Diese Daten könne
mithilfe des Event-Daten-GUI 11 erfasst und bearbeitet werden.
-
Weiterhin
verfügt
das Planungssystem 1 über
ein Kalendermodul 12. In dem Kalendermodul 12 sind
etwa Zeitdaten 120 für
ein Event gespeichert. Das Kalendermodul dient weiterhin zur zeitlichen
Organisation und Visualisierung der Events.
-
Drittens
enthält
das Planungssystem 1 ein Aktionsmustermodul 13.
Im Aktionsmustermodul 13 sind Aktionsmuster 130 elektronisch
gespeichert. Diese können
wiederum über
eine Benutzerschnittstelle einem Benutzer angezeigt oder zur Bearbeitung
zur Verfügung
gestellt werden. Ein Aktionsmuster (Workflow) beschreibt hierbei
Prozessschritte, welche für
die Planung und Durchführung
eines Events erforderlich sind. Die Aktionsmuster können hierbei
optional die Einhaltung von Nebenbedingungen berücksichtigen, etwa zeitliche
Mindestabstände zwischen
Events.
-
Das
Planungssystem 1 stellt eine automatische Steuerung für die Planung
und Durchführung der
Events bereit, indem es die dezentralen Systeme 2 koordiniert.
Bei den dezentralen Systemen 2 handelt es sich im einzelnen
um ein Zutrittskontrollsystem 21, ein Akkreditierungssystem 22,
ein elektronisches Zahlungssystem 23, ein Ticketverkaufssystem 24,
eine Eventkontaktzentrale 25 und eine Leitstelle 26.
Da es sich bei den dezentralen Systemen 2 um unabhängige Einheiten
handelt, die die einzelnen Prozessschritte selbständig durchführen, übernimmt das
Planungssystem 1 lediglich die Koordination der dezentralen
Systeme 2 sowie die Auslösung der einzelnen Prozessschritte
in Abhängigkeit
von den Zeitdaten 120 und Aktionsmustern 130.
-
Die
in 1 gezeigte Architektur ist lediglich als Beispiel
zu verstehen. Natürlich
können
einzelne Module oder Systeme hinzugenommen oder fortgelassen werden.
-
Felder
wie der Eventstatus oder der Eventtyp im eventspezifischen Datensatz
können
als Basisparameter bei der Abarbeitung der Aktionsmuster 130 durch
das Planungssystem 1 berücksichtigt werden. So ist etwa
jedes Aktionsmuster 130 auf einen bestimmten Eventtyp (Konzert,
Fußballspiel,
Messe ...) bezogen und wird in Abhängigkeit von diesem durch das
Planungssystem 1 oder einen Benutzer für die Planung und Durchführung des
Events selektiert. Das selektierte Aktionsmuster gibt hierbei an,
welche der dezentralen Systeme 2 in dem jeweiligen Szenario
einbezogen werden müssen.
Weiterhin enthält das
Aktionsmuster zeitliche Bedingungen relativ zu dem Zeitpunkt, an
dem das jeweilige Event stattfinden soll. So kann das Aktionsmuster
etwa angeben, dass der Ticketverkauf 6 Wochen vor dem Termin des
Events beginnen soll. Weiterhin können die Aktionsmuster im System
fest voreingestellt sein oder von einem Benutzer adaptiert werden.
In der ersten Variante wird das Planungssystem 1 bei der
Installation mit einer festen Menge Aktionsmuster angeboten, aus
denen für
ein jeweiliges Event abhängig
von dessen Eventtyp passende Aktionsmuster ausgewählt werden
können.
Bei der zweiten Variante handelt es sich um ein generisches System,
bei dem Benutzer zur Laufzeit des Planungssystems 1 neue
Aktionsmuster anlegen oder bestehende Aktionsmuster bearbeiten können.
-
Der
Eventstatus besagt, ob der für
ein Event geplante Termin noch optional (beispielsweise erst angedacht)
oder bereits verbindlich (in der Regel also vertraglich festgelegt)
ist. Der Eventstatus kann weiterhin auch mit einem Wert zwischen
0 und 1 eine Wahrscheinlichkeit dafür angeben, dass das Event stattfinden
wird. Für
die Koordinierung der Prozessschritte in den dezentralen Systemen 2 spielt
der Eventstatus eine wichtige Rolle. So werde bei optionalem Eventstatus
nicht alle dezentralen Systeme 2 informiert, da etwa ein
Tickethandel in diesem Stadium sinnlos wäre. Jedoch kann in diesem Stadium
bereits überprüft werden,
ob zeitliche Nebenbedingungen erfüllt sind, die etwa angeben
können,
dass zwischen zwei Events abhängig
von deren Eventtyp bestimmte Abstände wegen Ab-, Auf- oder Umbauzeiten
berücksichtigt
werden müssen.
Beispielsweise kann in einem Stadium abends kein großes Rockkonzert
stattfinden, wenn nachmittags noch ein Fußballspiel ausgerichtet wird.
Das Planungssystem 1 beobachtet den Eventstatus fortlaufend.
Sobald der Eventstatus etwa durch eine Bestätigung von optional nach verbindlich
wechselt, werden weitere Prozessschritte in den dezentralen Systemen 2 ausgelöst. Beispielsweise
können
an das Ticketverkaufssystem 24 notwendige Daten übermittelt
werden, um den Vorverkauf starten zu können, sobald der Termin für das Event
vertraglich fest vereinbart wurde. Ebenso kann die Leitstelle 26 zu
diesem Zeitpunkt informiert werden, um beispielsweise Behörden und öffentliche Verkehrsbetriebe über das
geplante Event in Kenntnis zu setzen.
-
In
einem konkreten Szenario soll ein Konzert abgehalten werden. Hierzu
wird ein Aktionsmuster selektiert, welches auf den Eventtyp Konzert
zugeschnitten ist. In dem Aktionsmuster ist vorgegeben, dass sechs
Wochen vor dem Konzerttermin mit dem Kartenvorverkauf begonnen werden
soll. Dementsprechend sorgt das Planungssystem 1 dafür, dass gemäß dieser
vorgegebenen Frist die entsprechenden Daten rechtzeitig an das Ticketverkaufssystem 24 übermittelt
werden. Voraussetzung hierfür
kann jedoch sein, dass der Eventstatus verbindlich ist. Ist jedoch
der Eventstatus sieben Wochen vor dem geplanten Konzerttermin immer
noch optional, so können
beispielsweise entsprechende Alarme generiert oder die Planung des
Events automatisch aufgehoben werden. Sofern nötig, werden die beteiligten
dezentralen Systeme 2 hierüber informiert.
-
Umgekehrt
kann auch ein dezentrales System 2 auf das Planungssystem 1 Einfluss
nehmen. Dies ist etwa dann sinnvoll, wenn ein aktueller Fortschritt,
etwa im Verkauf von Tickets, gegenüber einer betriebswirtschaftlich
motivierten Größe, etwa
einer Mindestverkaufszahl in Relation zur verbleibenden Zeit, einen
vorgegebenen Schwellwert unterschreitet. Ist beispielsweise vier
Wochen vor einem geplanten Eventtermin ein vorgegebener Prozentanteil
der Tickets noch nicht verkauft, kann das Event durch das Ticketverkaufssystem 24 abgesagt
werden, indem dieser einen entsprechenden Befehl an das Planungssystem 1 übermittelt.
-
Die
Befehle werden hierbei als Datentransfers über die einheitliche Schnittstelle 3 übermittelt. Hierfür wird ein
kleiner und einheitlicher Befehlssatz verwendet. Mit Hilfe der Befehle
kann in allen Systemen ein konsistenter Zustand hergestellt werden.
Die Koordinierung der Prozessschritte kann hierbei wahlweise durch
zeitabhängige
Trigger oder Benutzerinteraktionen angestoßen werden, welche durch das jeweilige
Aktionsmuster vorgegeben sind. Hierbei werden auch immer die aktuellen
Werte der Basisparameter, etwa der Eventstatus, berücksichtigt.
-
Beispielsweise
können
Befehle zur Synchronisation von Feldern der eventbezogenen Datensätze wie
folgt lauten:
- – Neues Event (Erzeuge einen
neuen eventspezifischen Datensatz)
- – Aktualisiere
Event (Ändere
Felder des eventspezifischen Datensatzes)
- – Lösche Event
(Lösche
den eventspezifischen Datensatz)
- – Zeige
Event (Anzeigen des eventspezifischen Datensatzes)
-
Mit
Hilfe dieses Befehlssatzes können Änderungen
an einem eventspezifischen Datensatz sofort an alle betroffenen
dezentralen Systeme weitergeleitet werden. So wird eine Konsistenz
der eventspezifischen Daten in allen dezentralen Systemen gewährleistet.
-
Analog
hierzu enthält
der Befehlssatz weitere Befehle für den Abgleich anderer Daten
wie etwa Personendaten für
Ansprechpartner zu verschiedenen Rollen wie etwa Betreiber, Veranstalter,
Sponsor, Catering usw..
-
Im
Folgenden wird ein zweites Ausführungsbeispiel
beschrieben, welches die Abarbeitung eines Aktionsmusters durch
das Planungssystem 1 näher erläutert. 2 zeigt
eine graphische Darstellung 30 eines Aktionsmusters. Die
graphische Darstellung 30 beinhaltet ein Flussdiagramm,
welches ein Aktionsmuster von der Definition eines neuen Events
bis zu dessen Abschluss umfasst. Jedem einzelnen Schritt im Aktionsmuster
werden hierbei eine Bezeichnung des Schritts, seine Teilnehmer,
die auszuführenden Aktionen
sowie zu prüfende
Vorbedingungen zugeordnet und im Aktionsmuster gespeichert. Bei
den Schritten handelt es sich um Schritte, die das Planungssystem 1 oder
ein Benutzer des Planungssystems 1 ausführt. Die Schritte können hierbei Prozessschritte
in den dezentralen Systemen 2 auslösen oder koordinieren.
-
Die
graphische Darstellung 30 in 2 zeigt zu
Beginn des Aktionsmusters einen Schritt 31. Im Schritt 31 werden
nötige
Informationen für
ein neues Event in ein entsprechendes Formular im Event-Daten-GUI 11 durch
einen Benutzer eingegeben. Der Eventstatus wird als optional definiert.
Danach erfolgt ein Zustandsübergang 311,
bei dem ein eventspezifischer Datensatz angelegt und in einem Datenspeicher
gespeichert wird. Das Aktionsmuster fährt nun wahlweise mit einem
Schritt 321 oder 322 fort. Im Schritt 321 sendet
das Planungssystem 1 eine Mitteilung (etwa eine E-Mail) an einen Eventmanager.
Im Schritt 322 sendet das Planungssystem 1 eine
Mitteilung an einen Promoter. Die Mitteilung enthält jeweils eine
Buchungsinformation für
das Event. Anschließend
wird eine Bedingung 323 überprüft, welche fordert, dass der
Eventstatus verbindlich geworden ist. In einem folgenden Schritt 33 gibt
ein Eventmanager fehlende Informationen in ein Eingabeformular im Event-Daten-GUI 11 ein
und bestätigt
die Buchung. Zusätzlich
werden in einem Schritt 331 weitere Events mit optionalem
Eventstatus, die sich zeitlich mit dem in Bearbeitung befindlichen
Event überschneiden,
durch das Planungssystem 1 abgesagt. Eine Mitteilung darüber erfolgt
in einem Schritt 332, in dem das Planungssystem 1 Promoter
der anderen Events durch eine Absagemitteilung informiert. Hierbei
können
die optionalen anderen Events automatisch aus dem Kalendermodul 12 entfernt
werden. Auf den Schritt 33 folgt weiterhin ein Schritt 34,
in dem das Ticketverkaufssystem 24 durch das Planungssystem 1 mit
den nötigen
Informationen versorgt wird, um den Ticketverkauf für das bearbeitete Event
zu starten. Sobald Bedingung 35 erfüllt ist, welche erfordert,
dass der geplante Termin für
das Event weniger als sechs Wochen in der Zukunft liegt, wird Schritt 36 ausgeführt. In
diesem sendet das Planungssystem 1 eine Nachricht an den
Eventmanager. Dieser gibt in einem nachfolgenden Schritt 37 Informationen
gemäß einer
Checkliste für
die Leitstelle 26 in ein Eingabeformular im Event-Daten-GUI 11 ein.
Anschließend
leitet das Planungssystem 1 die eingegebenen Informationen
in einem Schritt 38 an die Leitstelle 26 weiter.
Abschließend
wird eine Bedingung 39 geprüft, die dann erfüllt ist,
wenn das aktuelle Daten dem geplanten Termin für das Event entspricht. Daraufhin
wird Schritt 40 ausgeführt,
in welchem nötige
Informationen an das Zutrittskontrollsystem 21 weitergeleitet
werden.
-
Das
beschriebene Aktionsmuster sowie die einzelnen Schritte sind lediglich
als Beispiel zu verstehen. Natürlich
kann in analoger Weise etwa auch das Akkreditierungssystem 22 analog
zum Schritt 38 einbezogen werden. Gleiches gilt für alle anderen
dezentralen Systeme 2.
-
In
einem dritten Ausführungsbeispiel
wird im Folgenden ein Aktionsmuster für die Absage eines Events mit
einem verbindlichen Eventstatus beschrieben. In diesem Fall müssen alle
dezentralen Systeme 2, welche bereits bei der Planung des Events
einbezogen wurden, über
dessen Absage informiert werden. Dieser Fall ist darum komplizierter als
die Absage eines Events mit einem optionalen Eventstatus, welcher
intern im Kalendermodul 12 des Planungssystems 1 ohne
weitere Informationen an die dezentralen Systeme 2 erfolgen
kann.
-
Gemäß dem dritten
Ausführungsbeispiel nimmt
ein Benutzer eine Eingabe im Event-Daten-GUI 11 vor, mit
welcher der eventbezogene Datensatz im Datenspeicher des Planungssystems 1 gelöscht wird.
Anschließend
sendet das Planungssystem 1 eine Nachricht an den Promoter.
Danach sendet das Planungssystem 1 einen Befehl an das Ticketverkaufsystem 24,
um diesen über
die Absage des Events zu informieren. Sofern die Leitstelle 26 bereits
involviert wurde, wird ein entsprechender Befehl auch an die Leitstelle 26 gesendet.
Analog hierzu werden entsprechende Befehle auch an das Akkreditierungssystem 22 und
das Zutrittskontrollsystem 21 sowie beliebige weitere dezentrale
Systeme 2 geschickt, sofern diese im Rahmen der Planung
des Events bereits involviert wurden.
-
Abweichend
von diesem Ausführungsbeispiel
muss die Absage des Events nicht durch einen Benutzer des Planungssystems 1 erfolgen.
Die Absage kann auch durch einen Benutzer etwa der Leitstelle 26 erfolgen,
hier beispielsweise aus Sicherheitsgründen. Weiterhin kann auch ein
physikalischer Sensor, welcher mit der Leitstelle verschaltet ist
und die Nässe
eines Rasens etwa in einem Fußballstadion
misst, über
die Leitstelle 26 eine Absage des Events veranlassen, wenn
etwa anhaltender Regen ein geplantes Fußballspiel unmöglich macht.
In diesem Fall sendet die Leistelle 26 einen entsprechenden
Befehl an das Planungssystem 1, woraufhin dieses den eventspezifischen
Datensatz löscht.
-
Gemäß einem
vierten Ausführungsbeispiel wird
im Folgenden ein Aktionsmuster beschrieben, welches die Änderung
eines Events mit verbindlichem Eventstatus umfasst. Dieses Aktionsmuster besteht
aus einer Kombination der Aktionsmuster aus dem zweiten und dritten
Ausführungsbeispiel. Zunächst wird
das Aktionsmuster des dritten Ausführungsbeispiels ausgeführt, um
das zu ändernde Event
zunächst
zu löschen.
Anschließend
wird das Aktionsmuster aus dem zweiten Ausführungsbeispiel ausgeführt, um
das Event in der geänderten
Form neu anzulegen.
-
Änderungen
an Events mit optionalem Eventstatus können intern im Kalendermodul
des Planungssystems 1 erfolgen. Hierfür ist kein Aktionsmuster erforderlich,
da in diesem Stadium noch keine dezentralen Systeme 2 involviert
sind.
-
3 zeigt
zwei Tabellen, wie sie im Rahmen des Event-Daten-GUI 11 zur Visualisierung
und Bearbeitung der eventspezifischen Datensätze und Aktionsmuster verwendet
werden können.
Etwa kann in der oberen Tabelle Zeile 51 einen Identifikator
für das
aktuell angezeigte oder bearbeitete Aktionsmuster enthalten. Zeile 52 kann
mit dem Titel des Aktionsmusters belegt werden. Weiterhin kann Zeile 53 eine Beschreibung
des Aktionsmusters enthalten. Zeile 54 enthält hier
den Status des Aktionsmusters, welcher etwa durch ein Element der
Menge {in Bearbeitung, warten, erledigt, abgeschlossen} bestimmt wird.
Abschließend
kann Zeile 55 noch Bemerkungen zu dem jeweiligen Aktionsmuster
enthalten.
-
In
der unteren Tabelle in 3 sind nun die eigentlichen
Schritte des Aktionsmuster in jeweils einer Zeile dargestellt. Spalte 61 enthält hierbei
für jeden
Schritt eine Information über
dessen Position im Aktionsmuster. Durch eine entsprechende Codierung wird
sichergestellt, dass Schritte dahingehend unterschieden werden können, ob
sie parallel bzw. alternativ oder nacheinander auszuführen sind.
In Spalte 62 wird eine Bezeichnung des jeweiligen Schrittes aufgeführt. Spalte 63 enthält einen
Vermerk, ob der jeweilige Schritt bereits abgearbeitet wurde. Spalte 64 enthält gegebenenfalls
eine Frist für
den jeweiligen Schritt. Spalte 65 enthält den jeweiligen Bearbeiter.
Spalte 66 dient als Kommentar. Spalte 67 enthält das Erledigungsdatum.
Spalte 68 enthält
eine Schaltfläche, über die
der jeweilige Schritt beispielsweise bearbeitet werden kann.
-
Die
genannten Ausführungsbeispiele
können
frei miteinander kombiniert werden.