Geschäftsprozessmanagement (BPM) über DEMO (1)

Dies ist eine Neufassung eines früheren Blogs, der zum Teil von [1] inspiriert wurde. Zusammenfassend lässt sich sagen, dass die Personalverwaltung in Dienstleistungsunternehmen viele Transaktionen (im Sinne von DEMO) durchführt und kollaborative Prozesse ausführt, um die Informationen zu verwalten, die für die Pflege der Beziehungen zwischen Arbeitnehmern und Arbeitgebern im Unternehmen erforderlich sind. Die Kenntnis dieser Transaktionen und ihrer Interaktionen bietet bessere Möglichkeiten zur Automatisierung und Optimierung. Obwohl viele dieser Transaktionen Routine sind, sind diejenigen, die das Ressourcenmanagement umfassen, die wichtigsten, da sie sich direkt auf die Fähigkeit des Unternehmens zur Umsatzgenerierung auswirken. Wir haben uns dafür entschieden, den Rekrutierungsprozess in vier Transaktionen zu unterteilen, die unabhängig voneinander sind und von verschiedenen Rollen ausgeführt werden. Der Teilnehmer, der die Rolle des Interviewers spielt, kann sich von jeder Ressourcenanfrage unterscheiden. Sie werden aufgrund ihrer technischen Kenntnisse und ihrer Verfügbarkeit zur Teilnahme aufgefordert. Das Muster, das der Rekrutierungsprozess abbildet, ist die "serielle Doppelbasis PR-AE", wie sie in [1] erwähnt wird. Wir haben uns einige Freiheiten mit dem ursprünglichen Muster genommen, um unserem Zweck der Analyse eines Abteilungsprozesses im Hinblick auf die Automatisierung besser gerecht zu werden.

Wir können die Transaktionen wie folgt aufzählen:

• T01 -- Verwaltung der Ressourcenanfragen
• T03 -- Suche und Beschaffung der benötigten Ressourcen
• T04 -- Bewertung der Ressourcen
• T02 - Fertigstellung und Einbindung der Ressourcen

Abbildung 2: Wurzelprozess --

Verwaltung der Ressourcenanfrage

In dieser Transaktion sind die beiden Akteursrollen der "Kunde" und der "Personalvermittler". Während die Rolle des "Personalvermittlers" Teil der Serviceorganisation ist und daher für uns von Interesse ist, interessiert uns nicht besonders, welche Rolle die Anfragefunktion für den Kunden ausführt. Es handelt sich um einen Root-Prozess im Sinne von [1], der den Geschäftsprozess für die Bearbeitung der Ressourcenanfrage innerhalb des PMD startet. Obwohl der "Wurzelprozess" korrekt aussieht, ist er unvollständig, da die abschließende Aktivität des Schritts "Personalbeschaffungsmanager" nach dem Schritt der Annahme durch den Kunden ("ac") fehlt.

Abbildung 3: ändert den Root-Prozess --

Das Problem ist, dass die Aktivität Teil der ursprünglichen Zusage "pm" ist, aber erst nach der Annahme ausgeführt werden kann. Der beste Weg, den "Root-Prozess" wie oben dargestellt zu modifizieren, ist die Abbildung links, denn dadurch bleibt die Integrität der gesamten Transaktion erhalten. Um jedoch die ursprüngliche Kundenanfrage ("rq") von derjenigen zu unterscheiden, die nach der Annahme durch den Kunden ("ac") abgefeuert wird, mussten wir die Transaktion in "T02" umbenennen. Das mag im puristischen DEMO-Sinn nicht ganz korrekt sein, aber es erlaubt uns, die letzte Stufe des "Root-Prozesses" besser zu verstehen. Denn man kann argumentieren, dass die "Anfrage" T02 tatsächlich eine Anfrage des Clients ist, die Ressource an Bord zu nehmen.

Das Aktionsmodell für diese Transaktion setzt sich aus den folgenden Aktionsregeln zusammen,

Abbildung 4: Aktionsmodell --

Die Aktionsregeln in 'Abbildung 4' dienen nur zur Veranschaulichung. Wenn die Anfrage eine Ressource mit "Mainframe"-Fähigkeiten betrifft, wird die Anfrage abgelehnt. Die eigentlichen Aktionsregeln können, wenn sie für alle Transaktionen erstellt werden, ziemlich unübersichtlich werden.

Abbildung 5: Versuchtes BPM --

Das BPMN-Diagramm in Abbildung 5 (mit freundlicher Genehmigung von ARIS Express) ist die BPMN-Darstellung der obigen Demoanalyse. Es ist zu bedenken, dass das BPMN-Design sehr subjektiv ist und es viele Möglichkeiten der Implementierung gibt. Wir haben versucht, die Aspekte des Case Managements und die Tatsache, dass der Wissensarbeiter (insbesondere der Personalverantwortliche) die Aufgaben in beliebiger Reihenfolge und so oft wie nötig ausführen kann, um die Ressourcenanforderung zu erfüllen, in den Vordergrund zu stellen. Aus demselben Grund haben wir uns dafür entschieden, die Teilprozesse als "Ad-hoc-Teilprozesse" darzustellen. Außerdem wollten wir jede Transaktion, wie im DEMO-Modell dargestellt, überwachen und haben daher die Unterprozesse so gestaltet, dass die Kommunikation zwischen den Unterprozessen als nicht unterbrechendes Nachrichtenereignis erfolgt.

Das DEMO-Diagramm in Abbildung 1 suggeriert, dass die "Beschaffung" eine Zusammenarbeit mit einem externen Partner ist, während dies in der BPMN (Abbildung 5) nicht so offensichtlich ist. Wir haben die Zusammenarbeit mit einem externen Partner nicht geschaffen, sondern die Aktivität wird als Aufgabe des "Personalbeschaffungsmanagers" durchgeführt, was in den meisten Outsourcing-Organisationen zu einem Engpass werden kann. Es gibt viel, was DEMO als Werkzeug für die Prozessanalyse und als Vorstufe zur BPM-Implementierung empfiehlt.

[1] P. Van der Horst