Beispiel für Arbeitspriorisierung
Dieses Beispiel zeigt, wie eine Organisation Arbeitspriorisierungsregeln für alle drei Datensatztypen konfigurieren kann und was passiert, wenn Datensätze anhand dieser Regeln ausgewertet werden.
Eine Fertigungsorganisation hat die SPO-Anwendung bereitgestellt und konfiguriert zum ersten Mal die Arbeitspriorität. Ihr Beschaffungsteam hat sich auf drei verschiedene Kriterien geeinigt, eines pro Datensatztyp, die die für sein Unternehmen relevantesten Faktoren widerspiegeln.
Beispielkonfiguration
Bei Bestellanforderungen priorisiert das Team basierend auf dem Gesamtwert jeder Position. Linien mit größeren Ausgaben erfordern eine schnellere Abwicklung und eine strengere Aufsicht.
| Regel | Bedingung | Priorität zugewiesen |
|---|---|---|
| 1 | Der Gesamtbetrag der Bestellposition beträgt 100.000 USD oder mehr | Kritisch |
| 2 | Der Gesamtbetrag der Bestellposition liegt zwischen 50.000 und 99.999 USD | Hoch |
| 3 | Der Gesamtbetrag der Bestellposition liegt zwischen 25.000 und 49.999 USD | Mittel |
| 4 | Der Gesamtbetrag der Bestellposition beträgt maximal 24.999 USD | Niedrig |
Bei Beschaffungsanforderungen priorisiert das Team basierend auf dem Organisationsalter des Geschäftsinhabers. Anforderungen, die von leitenden Führungskräften gesponsert werden, erfordern eine schnellere Antwort.
| Regel | Bedingung | Priorität zugewiesen |
|---|---|---|
| 1 | Der Stellencode des Geschäftsinhabers ist CFO oder CEO | Kritisch |
| 2 | Der Stellencode des Geschäftsinhabers ist IC4 oder höher | Hoch |
| 3 | Der Stellencode des Geschäftsinhabers ist eine Managerebene | Mittel |
| 4 | Der Stellencode des Geschäftsinhabers ist IC1, IC2 oder IC3 | Niedrig |
Bei Beschaffungsfällen priorisiert das Team basierend auf der Art der angeforderten Änderung. Lieferantenänderungen und Vertragsänderungen bergen ein höheres Organisationsrisiko als routinemäßige Katalogaktualisierungen.
| Regel | Bedingung | Priorität zugewiesen |
|---|---|---|
| 1 | Der Änderungstyp der Fallposition ist „Lieferantenänderung“ oder „Vertragsänderung“ | Hoch |
| 2 | Der Änderungstyp der Fallposition ist „Preisänderung“ | Mittel |
| 3 | Der Änderungstyp der Fallposition ist „Katalolaktualisierung“ oder „Beschreibungsänderung“ | Niedrig |
Bestellanforderung mit gemischten Positionswerten
Ein Abteilungsmanager übermittelt eine Bestellanforderung für drei Artikel: Büromöbel (000 USD), Desktop-Workstation (8.500 USD) und Konferenzraum-Anzeigesystem (67 000 USD).
Wenn die Anforderung gespeichert wird, wertet das System jede Position anhand der Entscheidungstabelle aus. Die Möbellinie ($12.000) entspricht Regel 4 und gibt „Niedrig“ zurück. Die Workstation-Zeile ($8.500) entspricht ebenfalls Regel 4 und gibt „Niedrig“ zurück. Die Anzeigesystemzeile ($67.000) entspricht Regel 2 – ihr Betrag liegt zwischen $50.000 und $99.999 – und gibt „hoch“ zurück.
Das System wählt das dringendste Ergebnis für alle drei Zeilen aus: Hoch. Das Prioritätsfeld in der Bestellanforderung wird auf „hoch“ aktualisiert.
Wenn die Anforderung in der Warteschlange des Spezialisten angezeigt wird, wird sie als hoch gekennzeichnet – angetrieben von der einzelnen Zeile mit großem Wert, auch wenn die anderen beiden Zeilen Routine im Maßstab waren. Der Spezialist weiß, die Anforderung umgehend zu überprüfen, und findet die Anzeigesystemzeile für 67.000 $, wenn er sie öffnet.
Beschaffungsanforderung basierend auf Geschäftsinhaberrang
Ein Beschaffungsereignis wird erstellt, um Lieferanten für eine neue Kategorie von Rohmaterialien zu bewerten. Der Geschäftsinhaber in der Anforderung enthält einen Auftragscode, der einer Rolle auf IC4-Ebene entspricht.
Wenn die Beschaffungsanforderung gespeichert wird, wertet das System den Auftragscode des Geschäftsinhabers anhand der Entscheidungstabelle aus. Der IC4-Auftragscode entspricht Regel 2, und die Beschaffungsanforderung erhält hohe Priorität.
Wenn dasselbe Beschaffungsereignis von einem Geschäftsinhaber auf Managerebene initiiert wurde, hätte die Anforderung stattdessen eine moderate Priorität erhalten. Dasselbe Beschaffungsereignis, das von einer anderen Person gesponsert wird, landet anders in der Warteschlange – was die organisatorische Wichtigkeit der Person widerspiegelt, die die Arbeit sponsert.
Beschaffungsfall mit gemischten Änderungstypen
Ein Spezialist erstellt einen Beschaffungsfall, um Aktualisierungen für drei Elemente zu verarbeiten. Zwei der Fallpositionen sind Routinebeschreibungsänderungen. Das dritte Dokument dokumentiert einen Lieferantenwechsel – eine strategische Entscheidung mit Vertragsauswirkungen.
Wenn der Fall gespeichert und seine Positionen ausgewertet werden, entsprechen die beiden Beschreibungsänderungspositionen Regel 3 und geben „Niedrig“ zurück. Die Change-Position des Lieferanten entspricht Regel 1 und gibt „hoch“ zurück.
Das System wählt „hoch“ als Priorität für den übergeordneten Fall aus. Wenn ein Manager die offene Arbeitswarteschlange des Teams überprüft, wird dieser Fall über den Routine-Katalogaktualisierungsfällen angezeigt. Dies signalisiert, dass mindestens eine strategisch bedeutende Zeile enthalten ist.
Datensatz ohne Übereinstimmungsregel
Bevor diese Organisation die Konfiguration der Entscheidungstabelle für Beschaffungsfälle abgeschlossen hat, wird ein Beschaffungsfall erstellt. Die Tabelle enthält noch keine Regeln. Das System wertet die Entscheidungstabelle aus, findet keine übereinstimmende Regel, und der Fall erhält die Priorität „Planung“ – der Systemstandard. Wird unten in der Arbeitswarteschlange angezeigt.
Nachdem die Regeln in der Tabelle konfiguriert wurden, wertet das System den Fall bei der nächsten Erstellung oder Aktualisierung neu aus. Wenn eine Übereinstimmungsregel gefunden wird, wird die Priorität entsprechend aktualisiert.
Dies bedeutet, dass die Arbeitspriorisierung nicht erfordert, dass alle Regeln vorhanden sind, bevor die Funktion aktiv ist. Datensätze, die vor der Konfiguration von Regeln erstellt wurden, werden mit der Planungspriorität gesammelt und bei der Aktualisierung auf natürliche Weise neu ausgewertet.