Datum
16.09.2013
Dieser Beitrag wurde verfasst von:
Die Umbenennung von Produkten stellt oft eine entscheidende Weiterentwicklung dar. Man möchte zeigen, dass die Änderungen zur letzten Version so groß sind, dass eine simple Versionsnummernänderung nicht ausreicht, um dieser gerecht zu werden. Oft möchte man auch deutlich machen, dass es sich nicht um eine reine Weiterentwicklung eines Produkts handelt, sondern die Einflüsse mehrerer Produkte zu einem neuen Produkt verschmolzen sind. In der Automobilbranche oder im IT-Bereich: Technologien verschiedener Produkte werden nicht selten zusammengeführt und in neuem Design mit einem neuen Namen präsentiert.
Hinter einer solchen Zusammenführung stecken sicherlich lange, wohldurchdachte Überlegungen. Dennoch können Sie beim Anwender auch für Verwirrung sorgen, wie wir im IT-Bereich oft selbst feststellen. Unternehmensumstrukturierungen, Firmenkäufe oder eben das Einführen neuer Produktsparten führen oft zu einem hohen Klärungsbedürfnis auf Kundenseite.
Ein aktuelles Beispiel sind die Produkte der ILOG-Sparte bei der IBM. ILOG war bis vor einigen Jahren ein eigenständiges Unternehmen, bevor es von der IBM übernommen wurde. IBM siedelte die ILOG Produkte innerhalb ihrer Websphere-Sparte an, womit sie zu IBM WebSphere ILOG Produkten wurden.
Einige Jahre später teilte man die ursprünglichen ILOG-Produkte neu auf: Die Business Rules-Produkte blieben bei WebSphere, während die Optimierungsprodukte der Sparte Industry Solutions zugeordnet wurden. Zu letzteren zählt nun unter anderem das IBM ILOG Optimization Decision Management Enterprise, kurz ILOG ODM Enterprise bzw. ILOG ODME.
IBM ist in der Fortführung und Entwicklung seiner Produkte stark engagiert. Entsprechend wurden die Business Rules-Produkte innerhalb der WebSphere-Sparte kontinuierlich weiterentwickelt, so dass schließlich eine neue Versionsnummer nicht mehr ausreichend war. Daher wurde ein neuer Name gewählt: Aus dem bekannten Produkt mit dem ursprünglichen Namen ILOG JRules wurde IBM ILOG WebSphere Operational Decision Management, kurz WODM oder WebSphere ODM.
Wir haben nun also 2 Produkte unterschiedlicher Unternehmenssparten, deren Abkürzungen sich allerdings stark ähneln. Gibt es denn tatsächlich Überschneidungen der Produkte? Oder sind sie vollkommen unterschiedlich? Da diese Frage bereits bei einigen Kundengesprächen aufkam, kam mir die Idee zu diesem Blogbeitrag, bei dem ich Ihnen den Unterschied und die Einsatzmöglichkeiten der beiden Produkte näherbringen möchte.
Regelbasiert Entscheidungen treffen
Bei regelbasierten Engines werden Anfragen nacheinander abgearbeitet. Stellen Sie sich vor, Sie arbeiten in einem Mietwagenverleih. Vor Ihnen steht nun eine Menschenschlange, die alle ein Auto mieten wollen. Manche werden Mittelklassewagen fordern, wären aber auch mit einem Kleinwagen zufrieden. Manche, die einen Mittelklassewagen anfragen, würden im Notfall eher einen Oberklassewagen mieten. Manche können sich nicht auf Kompromisse einlassen, andere wiederum wollen einfach irgendein Fahrzeug und würden zur Not auch einen Kleinbus nehmen.
Sie arbeiten diese Schlange nun nacheinander ab. Doch was machen Sie dabei genau? Welchen Wagen geben Sie dem Kunden? Sie arbeiten automatisch einen Regelkatalog ab, ohne es zu merken. Die überlegen sich: Wenn ein Kunde einen Mittelklassewagen verlangt, dann sehe ich nach, ob es einen Mittelklassewagen gibt, der noch frei ist. Wenn solch ein Wagen frei ist, sehe ich nach der Ausstattung, und gleiche diese mit den Kundenwünschen ab. Anschließend nenne ich den Preis und warte ab, ob der Kunde zustimmt oder ablehnt. Wenn er zustimmt, fülle ich den Vertrag aus, ansonsten sehe ich nach, welcher Wagen eher in der Preiskategorie des Kunden liegt. So wird diese Entscheidung so lange fortgeführt, bis der Kunde sich endgültig für einen Wagen entscheidet oder Ihre Filiale wieder verlässt.
Nichts anderes macht eine regelbasierte Engine wie WODM: Sie hinterlegen vorher eine bestimmte Abfolge an Abfragen, die das System automatisch durchführt, bis letztendlich eine Entscheidung für einen Wagen oder gegen das Mieten gefallen ist. Dann folgt der nächste Kunde, für den der gleiche Regelkatalog gilt, und alle Anfragen werden nacheinander abgearbeitet. Bei einer regelbasierten Lösung werden also einzelne Entscheidungen nacheinander getroffen. Der Vorteil liegt auf der Hand: Solche vorgefertigten Entscheidungsbäume, Entscheidungstabellen, Entscheidungsregeln etc. sind sehr schnell, auch komplizierte Fragen lassen sich damit oft in Echtzeit beantworten.
Entscheidungen mit Hilfe von mathematischer Optimierung
Dass regelbasierte Systeme teilweise an ihre Grenzen stoßen, wird spätestens dann deutlich, wenn nicht eindeutig vorhersehbare Faktoren hineinspielen: In unserem Fall heißt dass, das einige Kunden die Filiale ohne einen Autoschlüssel verlassen müssen, weil ihr Wunschauto zuvor bereits an einen anderen Kunden vergeben wurde. Hätten sich die Kunden vorab absprechen und Kompromisse aushandeln können, hätte sich dies möglicherweise vermeiden lassen.
Um also gleichzeitig mehrere Anfragen zu berücksichtigen, wird mathematische Optimierung, zum Beispiel mit ODME, verwendet. Diese Kompromissfindung wird mit Hilfe von mathematischer Modellierung, also der Interpretation des Anwendungsfalls als Gleichungen, dargestellt. Eine Zielfunktion gibt dabei die Richtung vor. Das Ziel könnte zum Beispiel darin bestehen, die Anzahl der unzufriedenen Kunden zu minimieren. Eine mathematische Entscheidungsengine finden nun in kurzer Zeit die idealen Zuordnungen von Auto zu den verschiedenen Kunden. Aufgrund der Vielzahl an Möglichkeiten kommt die Performance natürlich nicht ganz an die regelbasierte Entscheidungsengine heran, liefert dafür aber bessere Ergebnisse unter Einbeziehung aller Faktoren.
Die Kombination beider Verfahren
In der Praxis werden solche Verfahren oft kombiniert. Da Sie als Vermieter auch vorab Reservierungsanfragen bekommen, können Sie Ihrem Kunden mit Hilfe des regelbasierten Systems in Echtzeit direkt zusagen, dass ein Fahrzeug verfügbar ist. Im System wird dieses Fahrzeug vorläufig reserviert, aber zugleich die Ausweichmöglichkeiten berücksichtigt. So haben Sie mit Hilfe der mathematischen Optimierung später die Möglichkeit, die Reservierungen zu optimieren. Auf diese Weise wird Ihre Flotte auf Grundlage des aktuellen Bestands optimal ausgelastet. Außerdem besteht die Möglichkeit, weitere Bedingungen wie beispielsweise das Freihalten von Fahrzeugen für spontane Anfragen zu berücksichtigen.
Haben Sie weitere Fragen zur Verwendung von ODME und WODM? Verwenden Sie bereits eine regelbasierte oder mathematische Engine? Welche Erfahrungen haben Sie gemacht? Ich freue mich auf Ihre Kommentare.
Autor
Philipp Schnürer
X-INTEGRATE Software & Consulting GmbHKontakt