top of page
  • AutorenbildBernd Lohmeyer

Adaptive Case Management – Das Ende der Sesamstraße

Aktualisiert: 27. Apr. 2021

Traditionelle BPM-Prozesse scheitern bei der Modellierung von Knowledge Work. Hierfür ist keine neue Modellierung, sondern ein neuer Denkansatz gefordert. Adaptive Case Management hilft weiter.

Als Geschäftsprozessanalytiker oder auch als UX Designer kennen Sie vielleicht die Situation: Sie müssen einen Geschäftsprozess verstehen, um ihn in einem IT-System abzubilden. Also lassen Sie ihn sich von einem User zeigen und erklären. Und weil Sie sehr gewissenhaft an die Sache gehen, lassen Sie sich das von einem anderen User auch noch mal zeigen. Doch nicht nur die Abfolge der einzelnen Unterschritte ist sehr unterschiedlich, auch sind diese noch nicht mal die selben. Das ganze Chaos wird mit jeder weiteren Beobachtung anderer User nur noch schlimmer.

Und jetzt stellen Sie sich die quälende Frage: Wie soll ich das denn jemals in einem Geschäftsprozess modellieren? Der wird ja riesig!

Ok, Sie können nun zu Ihrem Auftraggeber gehen und um mehr Zeit für die Modellierung bitten, weil es ja so viele Wege und Ausnahmen in diesem Prozess gibt. Auch sind ja die Unteraktivitäten so unterschiedlich. Es sei ein riesen Aufwand, das alles zu berücksichtigen. Richtig. Und doch so falsch!


Ende der Sesamstraße

Warum? Was ist passiert? Sie haben in’s berühmte Wespennest gestochen. Sie haben einen Wissensprozess aufgespürt. Einen Prozess, der nicht durch schiere Produktionserfordernisse, sondern von dem Wissen und der Erfahrung der individuellen Personen getrieben wird. Wir sprechen in diesem Fall von Knowledge Work. Wissensarbeit – oder besser Arbeit von Wissenden.

Diese Prozesse zeichnen sich durch individuelle Lagebeurteilungen und flexible Entscheidungen aus. Sie sind nicht planbar und von Fall zu Fall sehr unterschiedlich. Der Ausgang eines Vorgangs ist zu dessen Beginn nicht vorhersehbar. Es liegt auf der Hand, dass man solche Prozesse nicht mit traditionellen Methoden wie BPMN oder EPK abschließend beschreiben kann. Das Sesamstraßenspiel “Was passiert dann?” funktioniert hier nicht.

Beispiele sind:

  1. Leitung eines Großeinsatzes bei der Feuerwehr

  2. Beurteilung eines Patentantrags

  3. Gerichtliches Verfahren bei einer Straftat


Was ist Knowledge Work?

Knowledge Work darf man nicht falsch verstehen. Sie ist nicht auf Nobel-Preisträger beschränkt. Oh nein, das wäre schrecklich. Es ist einfach eine Arbeit, bei der der User am besten weiß, was in dieser speziellen Situation zu tun ist, um den Fall zu einem erfolgreichen Ende zu bringen. Der User entscheidet, welche Folgeaktivitäten von wem – es muss nicht er selbst sein- wann durchgeführt werden müssen. Bei dieser Arbeit zählt ausschließlich der Erfolg. Und der wird verantwortlich vom Prozessteilnehmer / User gesteuert. Diese Prozesse sind also weniger durch die auszuführenden, vordefinerten Aktivitäten als viel mehr durch die verfolgten Ziele gesteuert:

  1. Löschung des Brandes

  2. Bewilligung / Ablehnung des Patentantrags

  3. Rechtsprechung


Warum BPMN bei Knowledge Work versagt

Traditionelles Business Process Management (BPM) funktioniert hervorragend, wo es sich um eine bestimmte Form von Prozessen handelt. Diese zeichnen sich durch folgende Eigenschaften aus:

  1. Sie sind planbar.

  2. Sie wiederholen sich so häufig, dass sich auch ein hoher Planungs- und Modellierungsaufwand lohnt.

  3. Die Anzahl unterschiedlicher Wege, die ein solcher Prozess nehmen kann, ist überschaubar.

  4. Die verwendeten Ressourcen sind bekannt und determinierbar.

  5. Die relevanten Geschäftsregeln sind beherrschbar.

Ich denke, dass keiner der genannten Beispielprozesse auch nur eine dieser Eigenschaften aufweist. Nehmen wir die Beurteilung eines Patentantrags. Diesen Prozess habe ich selbst bei European Patent Office gut kennengelernt. Er ist zwar in einen durchaus planbaren und stark sequenzialisierten Verwaltungsprozess von Aufnahme, formaler Prüfung und Veröffentlichung eingebettet, die Prüfung selbst ist aber hochkomplexe Knowledge Work.

Die Patentprüfer (in der Regel absolute Ingenieur-Highflyer) müssen beurteilen, ob es sich bei dem Antrag um eine Innovation handelt, oder ob irgendwo auf dieser Welt jemand diese Idee schon mal zuvor veröffentlicht hat. Ein Artikel in einer Fachzeitschrift vom anderen Ende der Welt würde reichen, um den Antrag platzen zu lassen. Dabei recherchieren die Patentprüfer sehr verschiedene Quellen und Datenbanken – und das nicht nur abhängig vom Fachgebiet, sondern auch von teils sehr individuellen Strategien. Dazu gehört natürlich auch der Austausch mit anderen Spezialisten der entsprechenden Domäne: vom Flurfunk bis Social Media!

Es ist offensichtlich, dass kein Prozessmanager oder Designer oder sogar die Patentprüfer selbst derartige Prozesse so planen oder vorhersehen können, dass sich das in ein Modell kippen lassen könnte. Geschweige denn, eine Software mit einem Produktionszyklus von zwölf Monaten und mehr zu entwickeln.

⥤ Was tun?


Adaptive Case Management: Modellieren Sie es nicht! Lassen Sie es sein!

Ich denke, man muss die Situation einfach akzeptieren und damit kreativ umgehen. Die Object Management Group (OMG) hat die Unzulänglichkeiten der BPMN zu Anlass genommen, eine neue Notation zu entwickeln. Letztes Jahr ist das erste Beta der Case Management Modeling Notation (CMMN) erschienen. Diese Notation soll geeignet sein, Knowledge Work im Sinne des Adaptive Case Managements zu modellieren. Wenn man sich das genauer ansieht, findet man aber dennoch viele Sequentialitäten und Abhängigkeiten unter den einzelnen Prozessaktivitäten. Von ausgewiesenen ACM-Spezialisten (z.B. Keith D. Swnson, Max J. Pucher et al) wird bezweifelt, dass dieser Ansatz wirklich die Lösung für ACM ist. Gerade, weil die OMG den Versuch einer Modellierung verfolgt, sei das eine Sackgasse: Das ACM widersetzt sich der traditionellen Modellierung, weil es ACM ist. Ich muss mich diesem Argument anschließen.

Was kann man den verschiedenen Modellierungsversuchen entgegensetzen? Statt zu fragen, “Was passiert wann?” sollte man sich Gedanken machen “Was braucht der User?” Wenn wir so all die Werkzeuge und Datenquellen identifizieren, die der Knowledge Worker braucht, können wir einen passenden Werkzeugkasten komponieren. Hieraus kann sich dann der Knowledge Worker frei bedienen und den Vorgang vorantreiben.


Was der Knowledge Worker braucht!

Wir nähern uns der Arbeit des Knowledge Workers von der User-Seite. Für seine tägliche Arbeit braucht er:

  1. Direkten Zugriff auf den aktuellen und ältere Vorgänge

  2. Zugriff auf alle Dokumente, die damit zusammenhängen

  3. Status- und Trendinformationen des Vorgangs

  4. Dokumentation der geleisteten Aktivitäten

  5. Dokumentation der Untersuchungsergebnisse / Fallinformationen

  6. Unstrukturierte Ablage von spontanen Informationen

  7. Kommunikationswerkzeuge (Mail, Chat, Telefon, Social Media etc.)

  8. Terminplanung / -koordinierung

Und dahinter stecken dann solche technischen Systeme:

  1. Datenquellen, Datenbanken

  2. Knowledge Management

  3. Dokumenten Management

  4. Collaboration Tools

  5. Social Media Platforms

  6. Information Dashboards

  7. Personal Information Management

  8. Werkzeuge für

  9. Texterstellung

  10. Tabellenkalkulation

Es wird wohl sehr deutlich, dass man das nicht in einem Prozess beschreiben und in einer Software entwickeln kann. In vielen Unternehmen und Organisationen gibt es aber seit langen Jahren Anwendungen, die eben all diese Funktionen – jede auf ihre Art und Weise – erfüllen. Bei jedem Schritt von einer Anwendung zur nächsten gibt es aber Reibungsverluste. Seien es Tippfehler beim Übertragen oder Konzentrationsschwierigkeiten des Users, diese heterogene Welt ist kaum beherrschbar.


Eine Aufgabe für User Experience Designer

Viel wichtiger als die Suche nach dem einen homogenen Prozess und dem einen ultimativen Tool scheint daher die Frage zu sein, wie man eine heterogene Software-Landschaft, die all die Anforderungen der Knowledge Worker erfüllt, so zusammenführen kann, dass der User damit klar kommt. Nein, Cut Copy Paste von einer zur anderen Anwendung kann nicht die nachhaltige Antwort sein. Hier sind offensichtlich User Experience Designer gefragt.

Als eben solcher habe ich folgende Vision:

  1. Der User findet Informationen und legt diese ohne großen Verwaltungsaufwand ab. Diese Informationen sind Texte, Websites, Bilder, Audios und Videos.

  2. Der User kann Papiernotizen unkompliziert digitalisieren und ablegen. Der User kann Ideen und Anmerkungen digital handschriftlich notieren.

  3. Handschriftliche Notizen sind recherchierbar.

  4. Der User dokumentiert seine Arbeit unstrukturiert, gerade so wie sie geschieht.

  5. Der User verfügt über eine Schaltzentrale, über die er auf alle Quellen, Vorgangsergebnisse und Kommunikationsmittel Zugriff hat.

  6. Der User kann über einfache Einfeld-Suche alle Artefakte des Vorgangs durchsuchen und finden.

  7. Der User verfügt über ein Werkzeug, mit dem er sein mentales Modell des Vorgangs entwickelt und dokumentiert (Mind Mapping?)

  8. Tagging und jedwede Vorabkategorisierung sind überflüssig (weil unzureichend)

  9. Das System lernt durch semantische Analyse ständig dazu.

In diesem Zusammenhang scheint es mir so, dass die Sammlung unstrukturierter Informationen und das unstrukturierte Sammeln von Informationen deutlich an Bedeutung gewinnen wird. Es ist ein Graus für die traditionellen Informatiker, aber so ist das Leben! Vielleicht kommen wir eben diesem mit dem Adaptive Case Management näher – jedenfalls im Bereich der Wissensarbeit. Den Rest können wir ja schon ganz gut:-)

Oder anders: Mit einem Geo-Dreieck kann ich keine Kreis zeichnen. Wenn ich das unbedingt möchte, muss ich unendlich viele gleiche Dreiecke um einen Punkt konstruieren. Dann wird es irgendwann zumindest wie ein Kreis aussehen. Mathematisch wird es aber nie einer sein. Ich habe den Eindruck, wir müssen für die Knowledge Worker endlich den Zirkel erfinden!



106 Ansichten0 Kommentare

Aktuelle Beiträge

Alle ansehen
Beitrag: Blog2 Post
bottom of page