Der Begriff Prozess ganz allgemein bezeichnet ein System von Bewegung. Daraus lässt sich ableiten, dass das Prozess-Management die Koordinierung von Aktivitäten in einem sich bewegenden System ist. Einen Schritt weiter geht der Begriff des Geschäftsprozesses, der bereits ein bestimmtes Ziel eines Unternehmens verfolgt. Damit dieses Ziel erreicht werden kann, bedarf es verschiedener Hilfsmittel. Ein solches Hilfsmittel sind die sogenannten Prozess-Notationen. Mittlerweile gibt es auf dem Gebiet verschiedene Ansätze mit unterschiedlichen Darstellungsformen. Eine Form ist die erweiterte Ereignisgesteuerte Prozesskette (eEPK), die in einer Arbeitsgruppe unter der Leitung von August-Wilhelm Scheer im Jahr 1992 entstanden ist.

Eine weitere Darstellungsform ist unter dem Namen Business Process Model and Notation (BPMN) bekannt. Diese Notation wird von der Object Management Group (OMG) verwaltet und erlaubt eine Darstellung von Prozessen.

Die OMG ist ein Konsortium, das für verschiedene Modelle, Spezifikationen und Standards verantwortlich ist. Bekanntere Beispiele sind die erwähnte BPMN, das Common Object Request Broker Architecture (CORBA) zur Unterstützung bei der Erstellung von Anwendungen in heterogenen Systemen oder die Unified Modeling Language (UML) zur Abbildung objektorientierter Systeme.

Notationen, wie die BPMN, bieten neben einer reinen Darstellung der Prozesse auch Unterstützung für die Automatisierung dieser. Eine Automatisierung wird jedoch nicht durch die Notation an sich realisiert, sondern durch entsprechende Software, die Modelle automatisiert ausführen kann. Die Automatisierung eines Prozesses hat vor allem dann Vorteile, wenn sich damit wiederholende Abläufe abbilden lassen, um  den Durchsatz auch ohne menschlichen Einsatz zu erhöhen. Ein typisches Beispiel dafür wäre der Einkaufsprozess eines Online-Händlers.

Wie ein eEPK-Modell, bildet auch ein BPMN-Modell einen Prozess ab (s. Abb.2). Typisch für ein BPMN-Modell ist, dass der abgebildete Prozess bei einem Startpunkt beginnt, verschiedene Aktivitäten abarbeitet und letztendlich durch einen oder mehrere Endzustände beendet wird. Wichtig zu erwähnen ist, dass der Ablauf durch den Sequenzfluss (gerichtete Pfeile) vorgegeben wird. Diese Form der Prozessmodellierung eignet sich jedoch vor allem für die Abarbeitung von Prozessen mit klaren Abläufen und Entscheidungskriterien.

Schwierig gestaltet sich die Angelegenheit in Bezug auf herkömmliche Modellierungsmethoden, wenn die zu treffenden Entscheidungen auf menschlichen Erfahrungen basieren oder soziale Verbindungen involvieren. Ein Paradigma, das besonderen Wert auf individuelle Entscheidungen legt, ist das Case Management. Der Fokus des Case Managements liegt nicht auf der Vorgabe des Weges, sondern auf der Unterstützung des bearbeitenden Facharbeiters.

Ursprünglich aus dem Sozialwesen stammend, ist das Case Management in den Fokus technischer Workflowlösungen gerückt. Beim Case Management handelt es sich nicht um eine ablauforientierte Organisation der einzelnen Schritte, sondern um das Erreichen eines individuellen Ziels unter bestimmten, gegebenen Bedingungen. Durch die hohe, individuelle Ausprägung der zu bearbeitenden Fälle (Cases), wird eine technische Unterstützung zur Herausforderung.

Case Management zeichnet sich durch Unvorhersehbarkeit und Wissensintensivität aus.

Wahrscheinlich ist es unmöglich, eine allgemeingültige Definition von Case Management zu finden. Aus diesem Grund zeigt Abb.3 verschiedene Aspekte, die das Konzept Case Management eingrenzen sollen. Besondere Kriterien sind dabei die Unvorhersehbarkeit und die Wissensintensivität eines Cases. Diese stehen konträr zu Geschäftsprozessmanagement-Ansätzen, die mit linearen Workflows arbeiten.

Doch Case Management unterscheidet sich durch weitaus mehr vom linearen Geschäftsprozessmanagement, als durch seine Wissensintensität oder Unvorhersehbarkeit. Im Gegensatz zu prozessorientierten Modellen, bei denen aufgrund einer vorgeschriebenen Prozessabfolge eine enge Kopplung vorliegt, handelt es sich beim Case Management um eine lose Kopplung, welche durch eine Bündelung von Aktivitäten innerhalb eines Cases realisiert wird.  Ein solcher Case setzt sich in der Regel aus einer ungeordneten Menge von Aktivitäten und Dokumenten zusammen, die der Erreichung eines individuellen Ziels dienen. Jene Aktivitäten unterscheiden sich in zwei Kategorien: obligatorische und optionale Aktivitäten. Trotz der Individualität eines Cases ist der Grundgedanke des Case Managements, dass es einen Kern von Aktivitäten gibt, die sich immer ähneln. Dieser Kern wird durch die obligatorischen Aktivitäten abgedeckt. Die individuelle Ausprägung entsteht durch die optionalen Aufgaben des Cases. Da zwischen den Aktivitäten kein gerichteter Sequenzfluss existiert, müssen sie von sogenannten Wissensarbeitern gesteuert werden. Ein Wissensarbeiter zeichnet sich durch seine Expertise im jeweiligen Fachgebiet aus, welche ihn befähigt, individuelle Entscheidungen für jeden Case zu treffen. Mit Hilfe dieser Vorgehensweise können einzelne Cases zur Laufzeit dynamisch angepasst werden, wodurch sich unvorhergesehene Szenarien weitestgehend abdecken lassen.

Damit ein besseres Bild des Case Managements entsteht, soll an dieser Stelle ein Beispiel in Form einer Patientenpflege gegeben werden. Die Pflege eines Patienten umfasst oft sehr viele verschiedene Aspekte, wie beispielsweise rechtliche, versicherungstechnische und natürlich gesundheitsspezifische Aufgaben. Einige dieser Aufgaben ähneln sich in jedem einzelnen Case und sind somit auch mit linearen Workflow-Ansätzen umsetzbar. Betrachtet man nun jedoch die Aufgaben aus dem Gesundheitsbereich, ist jeder einzelne Fall individuell. Nehmen wir den Fall eines Knochenbruches. Hierbei ist schon zu unterscheiden, um was für einen Bruch es sich handelt. Daraus ergeben sich weiterführende Aufgaben, die für den Fall relevant sind, für den anderen nicht. Hier kann man z. B. an die Notwendigkeit eines Rollstuhles oder einer Haushaltshilfe denken. Bei einem Armbruch ist ein Rollstuhl eher unüblich, weshalb diese Aufgabe nie in dem Case aktiv werden muss. Würde man diese Aufgaben mit linearen Ansätzen modellieren, so müsste jede Eventualität fest in den Prozess eingebunden werden, was den Gesamtprozess sehr komplex werden ließe.

Wie bereits in dem Beispiel angedeutet wurde, ist es wichtig zu verstehen, dass Case Management nicht unbedingt als eigenständiges Konzept verwendet werden soll. Eher ist es so zu verstehen, dass lineare Ansätze und Case Management zusammen interagieren und ihre jeweiligen Stärken ausspielen sollen. Abb.4 zeigt dazu eine Übersicht der verschiedenen Modellierungsausprägungen.

Die linke Seite der Abbildung zeigt ein Beispiel für eine lineare Ausprägung der Geschäftsprozess-Modellierung. Diese ist durch einen starren Ablauf geprägt und auf die Abarbeitung der einzelnen Aktivitäten fokussiert. Auf der anderen Seite wird ein Case veranschaulicht, welcher sich durch seine obligatorischen und optionalen Aktivitäten sowie Dokumente auszeichnet. Im Vordergrund steht die lose Kopplung der einzelnen Aktivitäten, die durch den Facharbeiter priorisiert werden. Die mittlere Abbildung zeigt eine Kombination der beiden Ausprägungen, die durch die verschiedenen Eigenschaften besser an die jeweiligen Problemstellungen angepasst werden können. Dies geschieht durch ein gegenseitiges Aufrufen der jeweiligen Modelle.

Um den Begriff des Case Managements weiter zu schärfen, erfolgt nun eine Abgrenzung zu den in der Literatur oft synonym verwendeten Begriffen Adaptive Case Managements (ACM) und Dynamic Case Managements (DCM).

In diesem Fall wird das Geschäftsprozessmanagement in fallorientierte und prozessorientierte Konzepte unterteilt. Unter den prozessorientierten Konzepten sind Modelle wie BPMN oder EPK angesiedelt. Auf der fallorientierten Seite ist das Case Management angesiedelt, welches noch weiter unterschieden werden kann. Das Dynamic Case Management kann beispielsweise als ein technischer Ansatz zur Umsetzung von Case Management verstanden werden. Auch in dieser Form richtet sich der Fokus auf das zu erreichende Ziel. Dynamic Case Management zeichnet sich dadurch aus, dass eine Anpassung einer Instanz durch menschliche Entscheidungen erfolgt. Dies geschieht im System beispielsweise durch das Aktivieren von optionalen Aktivitäten und der Entscheidung über die Reihenfolge einzelner Aktivitäten. Gemäß Pucher wird Dynamic Case Management außerdem als semi-strukturiert, dynamisch und informationsintensiv definiert [1]. Doch dynamisch beinhaltet nicht zwangsläufig eine echte Adaptivität. Der Begriff "adaptive" bedeutet so viel wie "anpassen". So verbirgt sich hinter der Bezeichnung Adaptive Case Management eine weitere Ausprägung, welche sich durch seine Lern- bzw. Anpassungsfähigkeit auszeichnet. Den Überlegungen von Swenson in "Taming the Unpredictable" [2] zufolge, liegt auch in diesem Konzept der Fokus auf der Zielerreichung. Demzufolge soll Adaptive Case Management als Methode die Möglichkeit bieten, auch während der Laufzeit eines Prozesses flexibel auf unvorhergesehene Ereignisse reagieren zu können [3].

Obwohl bereits vor einiger Zeit erkannt wurde, dass für die Bearbeitung vieler Szenarien sowohl prozessorientierte als auch fallorientierte Aspekte gleichermaßen wichtig sein können, steckt die technische Umsetzung eines solchen, adaptiven Konzepts noch in den Kinderschuhen. Zwar existieren bereits gute Ansätze, die in der Lage sind, Case Management und Prozessmanagement zu kombinieren, allerdings fehlt es ihnen immer noch an Adaptivität. Für die technische Umsetzung eines solchen Adaptive Case Management-Konzepts könnten Lernalgorithmen verwendet werden, die ein System dazu befähigen, Informationen aus vergangenen Cases automatisiert zur Verfügung zu stellen oder zu nutzen. Demnach können beispielsweise Algorithmen eingesetzt werden, die anhand von Informationen vergangener Prozessinstanzen Vorschläge für künftige Entscheidungen generieren oder sogar eigenständige Entscheidungen treffen. Mit Hilfe von adaptiven Systemen könnte ein Leitsystem entwickelt werden, das aufzeigt, wie sich andere Facharbeiter in einer bestimmten Situation entschieden haben. Dies kann dabei helfen, richtige Entscheidungen in bestimmten Situationen zu treffen. Eine weitere Möglichkeit besteht darin, dass Mitarbeiter zur Laufzeit eigenständig Aufgaben anlegen, die den Verlauf beeinflussen können und vom System berücksichtigt werden.

DCM und ACM unterscheiden sich durch die Verwendung von intelligenten Lernalgorithmen

Aus diesen Erkenntnissen lässt sich ableiten, dass der Unterschied zwischen DCM und ACM in der Verwendung von intelligenten Lernalgorithmen liegt. Die Lernfähigkeit der Systeme beschränkt sich dabei nicht nur auf Cases, welche zur Laufzeit angepasst werden sollen, sondern auch auf Cases, die bereits bei ihrer Erstellung anhand von abgeschlossenen Instanzen lernen können.

Auch im Bereich des Case Managements bietet die OMG seit Mai 2014 eine Spezifikation mit dem Namen Case Management Model and Notation, kurz CMMN. Die CMMN an sich ist ein DCM-Ansatz, was jedoch nicht heißt, dass sie nicht um ACM-Aspekte erweitert werden kann.

Auf den ersten Blick erinnert die CMMN stark an die BPMN. Die einzelnen Elemente sehen sehr ähnlich aus, die Funktionsweise und der Fokus liegen jedoch auf anderen Aspekten. Bei der BPMN wird der Ablauf durch den linearen Sequenzfluss, der durch gerichtete Pfeile dargestellt  wird, vorgegeben. Auch die CMMN bietet durch sogenannte Sentries (Wächter) Möglichkeiten, um einen Ablauf zu definieren. Ein wesentlicher Aspekt der CMMN ist jedoch, dass es Aktivitäten gibt, die weder in einen gerichteten Ablauf eingebunden sind, noch zwangsläufig immer ausgeführt werden müssen.

In Abb.6 ist ein beispielhafter Case zu sehen, der mit der CMMN modelliert wurde. Prinzipiell besteht ein Case aus verschiedenen Aktivitäten, welche von einem Case-Plan-Model (Ordner-Symbol) zu einem Case zusammengefasst werden. Diese Aktivitäten können verschiedene Ausprägungen haben, sodass sie verschiedene Aufgaben und Aufgabentypen repräsentieren. Die Stages (achteckige Symbole) fassen eine Menge von Aktivitäten logisch zusammen und können als eine Art Sub-Case angesehen werden. Runde Symbole stellen Events dar, die bestimmte Aktivitäten auslösen können.

Gestrichelte Linien zwischen den einzelnen Elementen sind Assoziationen. Diese stellen nicht wie bei der BPMN einen gerichteten Ablauf dar, sondern weisen nur darauf hin, dass die verbundenen Elemente irgendwie voneinander abhängig sind. Die eigentlichen Abhängigkeiten werden durch die an den Rändern angehangenen Sentries (Rauten-Symbole) dargestellt. Diese Sentries werden als Eingangs- (weiße Raute) bzw. Ausgangskriterium (schwarze Raute) genutzt und dazu verwendet, dass Bedingungen definiert werden können. Jene Bedingungen beschreiben, unter welchen Umständen eine Aktivität gestartet bzw. beendet werden kann. Dadurch ist es möglich, einen indirekten Sequenzfluss zu definieren, welcher jedoch komplexer sein kann, als ein einzelner gerichteter Pfeil.