Alle Wege führen nach Rom; unsere führen zum optimalen Ergebnis

Unsere Arbeit beginnt dort, wo Standardsoftware aufhört. Und sie endet erst, wenn es nicht mehr besser geht. Jede Aufgabe wird dabei ganzheitlich nach dem Analyseprozess des Operations Research bearbeitet.

Problem

Jede Entscheidungs- oder Planungsaufgabe muss zunächst abstrahiert und formalisiert werden. Dabei hinterfragen wir den bisherigen Entscheidungsprozess, eventuell bereits vorhandene Verfahren, was an den Lösungen nicht zufrieden stellend ist, welche Ziele verfolgt werden, welche weichen und harten Randbedingungen bestehen, welche Abhängigkeiten zwischen Entscheidungen bestehen, welche Regeln zu beachten sind usw. Diese Fragen sind sehr tief bohrend, und fördern manchmal Überraschendes zu Tage. Wir gehen erst, wenn wir 100% verstanden haben, was Sie bewegt.

Daten

Ohne Daten geht nichts, das war im OR schon so, lange bevor der Begriff Data Science populär wurde. Daten für Entscheidungsmodelle sind oft andere, als sie in Unternehmen bislang gesammelt werden. Selbst wenn sie vorhanden sind, sind sie oft nicht vollständig, nicht korrekt oder nicht repräsentativ. Sie entstammen manchmal mehreren Quellen in unterschiedlichen Formaten und Qualitäten. Viele Daten sind mit Unsicherheiten behaftet, d.h. es sind z.B. nur Verteilungen bekannt oder nicht einmal das. Alle diese Aspekte müssen in den Griff bekommen werden; nicht selten nimmt diese Phase eines OR Projekts den zeitlich größten Anteil ein.

Modell

Unsere mathematischen Modelle sind Entscheidungsmodelle, d.h. sie beschreiben alle möglichen Lösungen, die für die gestellte Aufgabe in Frage kommen. So können z.B. Reihenfolgen, Konfigurationen, Layouts, Designs oder Kombinationen modelliert werden, deren Anzahl fast immer kombinatorisch explodiert. Der Wert einer Lösung für den Entscheider wird in einer oder mehreren Zielfunktionen formuliert, die minimiert oder maximiert wird. Ein gutes Modell zu finden ist eine hohe Kunst, die all unsere Expertise erfordert.

Algorithmus

Es ist aus Zeitgründen völlig impraktikabel, alle möglichen Lösungen einer Optimierungsaufgabe auszuprobieren. Das wäre auch nicht intelligent. Algorithmen der mathematischen Optimierung nutzen Theorie und Struktur, um sehr geschickt ganze Klassen von Lösungen ausschließen. Am Ende berechnen wir eine Lösung, die beweisbar optimal ist, d.h. wir wissen, dass es keine bessere geben kann. Manchmal kommen Standard-Algorithmen wie Branch-and-Bound zum Einsatz; oft müssen aber auch neue Verfahren entwickelt werden. Hier passiert mathematische Forschung.

Implementation

Alle bisherigen Schritte münden in einem Software-Prototypen. Dieser dient als Werkzeug unsere Ideen zu testen und gleichzeitig als Proof-of-Concept. Theoretisch kann der Prototyp oft direkt im Unternehmen eingesetzt werden, praktisch sollte er aber von der eigenen IT oder einem Drittanbieter umgesetzt werden (z.B. aus Gründen der Zertifizierung, Wartung, Dokumentation, Schulung, etc.). Schnittstellen werden durch unsere Vorgehensweise bereits sehr früh im Prozess definiert.

Lösung

Die mit unseren Verfahren berechneten Lösungen sind immer bereits konkret ausführbare Pläne. Diese werden für die Praxis nachvollziehbar, und oft in "gewohnter Umgebung" dargestellt. Wir verstehen unsere Pläne als Vorschläge; die Planenden können diese modifizieren, verwerfen oder akzeptieren. Häufig steigt die Akzeptanzrate auf nahe 100% in kurzer Zeit. In manchen Situationen ist eine (Teil-)Automatisierung denkbar und sinnvoll; auch das ist möglich.

Plausibilität

Die mit mathematischer Optimierung erstellten Pläne sehen anfangs oft ungewohnt aus, auch weil der Entscheidungsspielraum restlos ausgeschöpft wird. Anhand von kleinen Beispielen und "manuellem Eingreifen" können wir oft verdeutlichen, dass die mathematisch berechnete Lösung besser ist als die "gewohnte". Pläne können oft sich so ausgeführt werden, wie berechnet. Sind die Lösungen robust gegen Störungen? Das Teilgebiet der robusten Optimierung kann von vornherein dagegen absichern.  

Umsetzung

Wir beraten und begleiten die Anbindung unseres Prototyps an die vorhandene Software. Die Einführung einer mathematischen Entscheidungsunterstützung kann Konsequenzen für andere Prozesse haben. Manche Schritte sind nicht mehr notwendig, ggf. kommen neue hinzu. Entscheidende werden von ihren Routineaufgaben entlastet und haben so mehr Zeit für knifflige Fälle. Auch wird die Qualität von Entscheidungen besser und gleichmäßiger.

Iteration

Die dargestellten Schritte greifen natürlich ineinander, laufen teilweise parallel. Oft stellt man bei der Diskussion der ersten Lösungen fest, dass manches "Wissen im Hinterkopf" noch nicht ausdrücklich beschrieben war. Oder die Rahmenbedingungen haben sich zu einem späteren Zeitpunkt verändert. Dann iterieren wir den Prozess. Bis zu einem überzeugenden Ergebnis kann es je nach Aufgabe wenige Monate dauern oder auch leicht ein mehrjähriges, anspruchsvolles Promotionsvorhaben in Anspruch nehmen. Das liegt vor allem daran, dass wir an Aufgaben interessiert sind, für die es noch keine Lösungen gibt.