Versionsverwaltung

Einleitung

Im folgenden werden die Ziele und der Nutzen auf Basis einer Situtation beschrieben.

Ausgangssituation

Vertriebskonditionen treten in unterschiedlichen Formen auf. Diese sind unter Umständen teil von Verträgen und müssen dementsprechend verwaltet werden, so dass verhandelte Konditionen zu den richtigen Zeitpunkten zur Verfügung stehen. Beispielsweise müssen in der Angebotsphase verhandelte Rabatte oder Preise verwendet werden.

Konditionen werden bisher nach bestem Wissen und Gewissen gepflegt.

Eine Verifikation der Konditionen gibt es bis dato nicht, es beruht alles auf Expertenwissen und dem Vertrauen, dass dieses komplett und 100% richtig ist.

Da Konditionen nicht formal definiert werden, ist es auch nicht möglich eine formale Verifikation durchzuführen und deshalb werden nur die wichtigsten Geschäftsfälle in 100% manueller Arbeit getestet.

Durch diese Vorgehensweise ist nie sichergestellt, dass die wirkliche Intention (Z.B. Verträge) korrekt im System abgebildet ist.

Des Weiteren werden “Abkürzungen” bzw. “Bequemlichkeiten” eingeführt, da der entstehende manuelle Aufwand die Intentionen in Konditionen darzustellen zu hoch wird (bspw. werden weitere Zugriffsfolgen verwendet um andere Konditionen zu “deaktivieren”). Dadurch werden weitere Komplexitätsstufen erzeugt, welche von Anfang an, mit einer formalen Definition, nicht nötig gewesen wären und weitere Fehlerquellen darstellen !.

Ziele

Zum einen soll die Verwaltung der Konditionen vom System so unterstützt werden um manuelle Eingriffe und damit erhöhten manuellen Aufwand zu reduzieren. Des Weiteren sollen Aktionen auf einzelnen Konditionssätzen verringert bzw. vereinfacht werden.

Darauf aufbauend sollen Intentionen (Verträge bzgl. Preise, Rabatte, etc.) formal definiert werden können um notwendige Konditionen ableiten bzw. errechnen zu lassen.

Sobald eine Verwaltung ermöglicht wurde, soll es möglich sein Simulationen durch zu führen. Die Simulationen sollen dabei die gesamte Konditionstechnik abbilden (Konditionen und Kalkulation).

Nutzen

Durch formale Definitionen können ein leichtes Updates und Konditionen ermittelt werden. Dadurch bleiben Konditionen aktuell, auch wenn Ausprägungen / Parameter, also Rahmenbedingungen, verändert werden.

Des Weiteren soll es möglich sein Simulationen über diverse Geschäftsmöglichkeiten zu erstellen und dadurch die tatsächlichen Auswirkungen der Konditionen zu prüfen und zu vergleichen. Um die Simulationen durch zu führen muss es möglich sein Parameter zu definieren, welche Geschäftsfälle definieren und mittels definierbaren Kalkulationsschemen Konditionen zu ermitteln und Ergebnisse zu berechnen. Daraus können Vergleiche her- und dargestellt werden und somit Unterschiede einfach identifiziert werden.

Die Simulation(en) soll nicht nur bei neu definierten Konditionen verfügbar sein, sondern auch separat aufgerufen werden können und Konditionen, Konditionsarten, Zugriffsfolgen und Kalkulationsschemen verändern können. “Verändern” bedeutet, dass diese Objekte innerhalb der Simulation neu definiert, verändert, als auch gelöscht/deaktiviert werden können.

Mit Hilfe der Simulationen von Konditionen können Eingriffe in die Konditionstechnik im vorhinein geprüft und mit dem aktuellen bzw. anderen Zuständen verglichen werden. Dadurch wird es möglich sein geplante Veränderungen im vorhinein für alle Geschäftsfälle zu simulieren, ob die gewünschten Ergebnisse erzielt werden.

Grundlagen

In diesem Bereich werden Basiselemente beschrieben und definiert, welche für den späteren Verlauf notwendig sind.

Konditionen

Als Definition für eine Kondition wird die Beschreibung von SAP verwendet. Eine Kondition ist ein Wert, welcher an eine Bedingung geknüpft ist. Um Preise zu ermitteln werden diese Bedingungen in einer Kalkulation verwendet. Bedingungen können unterschiedlichste Faktoren sein, welche sich aus Rahmenbedingungen (z.B. Angebotsdatum, Kunde) und produktspezifischen Bedinungen (z.B. das Produkt, die Bestellmenge) ableiten.

Eine Kalkulation ist eine Art Rechenvorschrift, welche Arten von Werten verwendet werden und wie diese miteinander verrechnet werden sollen. In eine Angebotskalkulation gibt es bspw. die Arten

• Preis
• Abschlag / Rabatt / Discount
• Aufschlag / Mark up.

Pro Art wird eine Konditionsart definiert und für jede Art werden Bedingungen für Konditionen definiert.

Eine Kondition besitzt die Eigenschaften:

Bedingungen

Es wurde bereits von Bedingungen gesprochen welche immer an eine Kondition geknüpft sind und angibt, wann diese verwendet werden darf / kann / soll. Der Aufbau einer Bedingung besteht aus einem festen Anteil, welcher bei jeder Bedingung gleich ist und einen dynamischen Anteil. Dieser dynamische Anteil kann mit unterschiedlichsten Feldern angereicht werden, welche Teil einer Bedingung sein sollen.

Das Modell für eine Bedingung pro Kondition:

Wichtig ist die Eindeutigkeit der Konditionen. Um diese zu gewährleistungen müssen folgende Grundvoraussetzugnen beachtet werden:

• pro Konditionsart und Kombination aus Bedingungen kann es genau 0 oder 1 Ergebnis geben.
• Eine Kondition mit den selben Bedingungen kann nur 1-mal vorhanden sein
  Ist der dynamische Anteil identisch können diese bspw. durch Änderung des Gültigkeitsdatums gepflegt werden.

In folgendem Beispiel wird verdeutlicht, wie unterschiedliche Listenpreise für ein Material gepflegt werden können mit Hilfe des Gültigkeitszeitraumes:

Zugriffsfolge

Da es pro Konditionsart unterschiedliche Bedingungen geben kann muss diesen eine Gewichtung verliehen werden. Ansonsten könnte nicht unterschieden werden, wenn für eine Anzahl an Parametern mehrere Bedingungen erfüllt werden würde, welche Kondition verwendet werden soll. Deshalb wird den Bedingungen eine Zugriffs(reihen)folge verliehen, d.h. welche Bedingungen vor anderen geprüft werden sollen.

Ein Beispiel von Zugriffsfolgen für eine Konditionsart “PR00 - Listenpreis” könnte sein:

Die Zugriffsfolgen werden von “oben nach unten” geprüft und dementsprechend muss auch die Reihenfolge festgelegt werden. Die Reihenfolge richtet sich von “spezifisch zu generell”. D.h. Bedingungen welche spezifischer sind müssen vor generelleren Bedingungen geprüft werden, da ansonsten evtl. eine spezifische Bedingung nicht mehr erreicht werden kann.

In oben dargestellten Beispiel macht es keinen Sinn erst die Bedingung “Matnr” vor “Matnr + Kdnr” zu prüfen, da immer ein Preis vorhanden sein soll und bei bestimmten Situationen etwas spezifischeres gepflegt sein kann.

Konditionen und Preisfindung

Kalkulationsschema / Rechenschema

Die in den vorherigen Abschnitten definierten Modelle (Kondition, Bedingung und Zugriffsfolge) beinhalten erstmal nur Daten. Damit diesen Daten auch Sinnhaftigkeit verliehen wird muss ein Zusammenhang hergestellt werden. Dieser Zusammenhang wird mit Hilfe eines Schemas hergestellt. In einem Schema wird zuerst definiert welche Kondition(sarten) und damit deren Bedingungen und Zugriffsfolgen verwendet werden.

Ein wichtiger Fokus liegt hierbei auf den Bedingungen. Da eine Bedingung einen dynamischen Anteil besitzt muss dieser dynamische Anteil auch verwendet werden können. D.h. die Felder der Bedingungen müssen auch dem Schema bekannt sein, ansonsten können diese nicht als Parameter für eine Konditionsfindung verwendet werden. Dies kann auch eine bewusste Entscheidung sein um etwas bestimmte Bedingungen in bestimmten Schemata nicht zu verwenden, was allerdings vorher genau festgelegt werden sollte um Verwirrung zu vermeiden.

Nur Bedingungen prüfen und Konditionen auslesen reicht allerdings nicht. Es muss auch festgelegt werden, wie diese ermittelten Werte angewendet werden sollen. Betrachten wir ein Angebot, dann wird in diesem bspw. die Preisermittlung über ein solches Schema gesteuert. Nachdem Preis, Aufschläge, Abschläge, etc. ermittelt wurden muss auch definiert werden wie diese Werte miteinander verrechnet werden sollen.

Das bedeutet, dass das Schema die eigentliche Intelligenz und Logik besitzt. Die Schemen sollten auch einigermaßen stabil sein und die grundsätzliche Logik nicht zu sehr geändert werden, da die Konditionen und die Schemata in Verbindung gebracht werden. Änderungen in den Modellen haben dadurch direkten Einfluss aufeinander.

Je nach Einsatzgebiet der Schemata verfügen diese über bestimmte Operationen. Häufig wird hier von Rechenoperationen gesprochen, aber auch Zwischenergebnisse oder Operationen unabhängig von Berechnungen können und müssen möglich sein.

Ein einfaches Beispiel einer Angebotsrechnung mittels eines definierten “Kalkulationsschemas”:

Fachliche Anforderungen

Die Anforderungen trennen sich in einen Verwaltungs- und einen Simulationsteil. Die Grundlagen werden für beide Teile benötigt und ein Austausch der Anteile untereinander soll ebenfalls möglich sein.

Konditionsverwaltung

Wie eingangs angesprochen wird eine formale Definition von Konditionen bzw. den Bedingungen gefordert. Diese formalen Definitionen - und damit auch die daraus hervorgehenden Konditionssätze - müssen allerdings auch verwaltet werden. Es muss also erst ein Verwaltungssystem erstellt werden, mit dessen Hilfe formale Beschreibungen möglich bzw. Bestandteil sind.

Definition

Klassische Fälle von formalen Beschreibungen sind bspw. Auf- und Abschläge, welche den gleichen Wert für mehrere Bedingungen definieren. Als Beispiel dient ein Rabatt, welcher allen Landesgesellschaften in gleicher Höher für eine bestimmte Produktgruppe gewährt werden soll. Dafür werden alle Gesellschaften ausgewählt, die Produktgruppenmerkmale und einmalig der Wert festgelegt. Durch die Definition “Alle Gesellschaften” und “einem Wert” können die Rabattsätze automatisch ermittelt werden. Durch die automatische Ermittlung lässt sich auch bei Ergänzung einer neuen Gesellschaft einfach der Rabatt erweitern.

Das Ergebnis sind die einzelnen berechneten Konditionssätze, welche in diesem Fall das Kreuzprodukt der Bedingungen ist:

In vielen Fällen ist eine formale Definition wie eine einzelne Definition, da die formale Definition so spezifisch ist, dass im Prinzip einzelne Konditionssätze definiert werden. In diesen Fällen ist es nicht sinnvoll eine formale Definition zu erstellen, sondern den Nutzer so zu unterstützen, dass die Konditionen mit einfachen Mitteln und so viel Unterstützung wie möglich erstellt werden können.

Status

Wird eine neue Defintion angelegt durchläuft diese einige Stati. Mit dessen Hilfe kann die Dateneingabe unterteilt und weitere Aktionen deterministisch gestartet werden.

In jedem Zustand sind Aktionen des Nutzers oder Systems notwendig:

• New: Fragebaum wird befüllt.
• Editing: Kondition werden befüllt.
• Released: Kondition werden eingefroren.

Aktion: Neue Konditionen (Formale Definition)

Aktion: Neue Konditionen ()

Aktion: Approval-Workflow

Aktion: Erinnerungs-Workflow

Einzelne Konditionssätze sollen nicht manuell gepflegt werden.

Fragebaum

Die erste Unterstützung für die Nutzer ist ein Fragebaum, der sie zum einen in die richtige Richtung der Konditionsarten schickt und zum anderen die Bedingungen abfrägt.

Aufgrund der Antworten des Fragebaums können Zustände errechnet werden. Die Diagramme zur Errechnungen sind wie folgt:

Wurden die Konditionsarten ermittelt, können auch die möglichen Schlüsselkombinationen ermittelt werden. Das Kreuzprodukt der im Fragebaum angegebenen Bedingungen ergibt die notwendige Schlüsselkombination (also die Kombination aller Bedingungen).

Wurde keine Schlüsselkombination gefunden soll eine entsprechende Meldung ausgegeben werden. Das eine neue Schlüsselkombination angelegt werden muss oder andere Bedingungen verwendet werden müssen.

Expertenmodus

Nicht immer ist ein Fragebaum gewünscht oder auch notwendig. In diesen Fällen wird die Annahme getroffen, dass sich der Nutzer mit der Konditionstechnik sehr gut auskennt und Erfahrung hat. Anstatt dem Fragebaum soll direkt die Konditionsart und die gewünschte Schlüsselfolge ausgewählt werden. Das Ergebnis ist somit das selbe wie, wenn der Fragebaum gewählt worden wäre und es können die selben weiter notwendigen Aktionen durchgeführt werden.

Berechnung / Ermittlung

Wurde die Konditionsart und Schlüsselfolge ermittelt müssen im weiteren Verlauf noch die notwendigen Konditionswerte eingetragen werden. Dazu sollen einige Hilfsmittel zur Verfügung gestellt werden, welche das Leben etwas erleichtern.

Konditionen errechnen

Wurde die Definition der Konditionen via Fragebaum vorgenommen können mittels der eingetragenen Bedingungen die notwendigen Bedingungskombinationen errechnet werden. Dadurch müssen diese nicht vom Nutzer selbst ermittelt werden. In einigen Fällen kann in diesem Schritt auch der Wert vorgegeben werden, wenn dieser in allen Kombinationen der selbe sein soll.

In folgendem Beispiel werden aus den Werten des Fragebaums und der ausgewählten Schlüsselkombination die notwendigen Konditionen mit Bedingungskombinationen errechnet.

Der Fragebaum wurde mit folgenden Werten beantwortet:

Die die daraus abgeleitete Konditionsart und Schlüsselkombination wird vorgeschlagen/vorausgewählt:

Aufgrund der Informationen können nun die notwendigen Konditionen mit Bedingungen errechnet werden:

Im Anschluss müssen die Werte eingetragen werden.

Konditionen/-swerte einfügen (Copy & Paste)

TODO: Konditionswerte pflegen

Datenmodell

Aktionen

Im folgenden werden Aktionen definiert die möglich sein müssen. Die Aktionen beziehen sich auf grundsätzliche Dinge wie bspw. neue Definitionen anlegen als auch spezifische Aktionen, welche in einer Definition ausgeführt werden sollen können.

Neue Definition

Der Startpunkt ist das Erstellen einer neuen Definition. Die Definition beinhaltet einen Namen und sprechende Schlagworte (Tags) um im Nachhinein die Suche zu vereinfachen. Des Weiteren wird entweder ein Fragebaum beantwortet oder im Expertenmodus direkt die Konditionsart und die Schlüsselkombination befüllt.

Eine neue Version identifiziert sich über einen Namen und eine Versionssnummer. Da Konditionen nicht für immer fix sind muss es möglich sein diese in Zukunft auch zu ändern. Dazu wird die selbe Defintion verwendet, allerdings mit einer neue Version.

Die nächsten möglichen Schritte sind: Löschen oder Konditionen bearbeiten

Definition bearbeiten

Update Definition

Ein Update ist das selbe wie eine neue Version. Das heißt, dass eine bestehende Definition verwendet wird und dazu alle oder bestimmte Kondititionen aktualisiert / verändert werden.

Mit einem Vergleich der vorhergehenden Defintion und der neuen Definition können Unterschiede ermittelt werden.

Discontinue Definition

Konditionssimulation

Geschäftsfälle

Veränderung von Konditionen

Berechnung (Kalkulation)

Vergleiche

Funktionsbeschreibung

Technische Anforderungen

Zugriffsmöglichkeiten