1) Die Treppenleiter : Beobachten, Erklären, Beschreiben und dann Umsetzen

Projektentwicklung ist wie ein Treppensteigen, es geht aber nicht nur aufwärts, manchmal  auch  wieder abwärts, und dann und wann  fängt man auch wieder ganz unten an.

Abb. 1: Projektenwicklung als Treppensteigen

Zunächst beobachtet man den Gegenstand, der projektiert werden soll, z.B. den Immatrikulationsvorgang an Universitäten oder den Auftragseingang in einer Firma. Manchmal gibt es auch  keinen Gegenstand, dann muss man den Gegenstand erst entwickeln. In der freien Wirtschaft spricht man von der Entwicklung eines Geschäftsmodells.  In einem Modell muss der potentiellen Kundenkreis bestimmt werden, das Produkt und seine Herstellung  ist festzulegen, um dann den Wertzuwachs, den „ value added“ zu kalkulieren. Nach dem Beobachten (observation), ein rein empirischer Vorgang der Wahrnehmung (perception) und einer  Erklärung (explanation), meist in Form von wenn – dann – Sätzen (if – then sentences), z.B. „wenn der Notendurchschnitt akzeptabel ist, kann immatrikuliert werden“, oder„ wenn der Auftrag den Spezifikationen entspricht, kann er genehmigt werden“.  Beobachten und Erklären fällt in den üblichen Vorgehensweisen (Methodologien)  in die Phase der ist-Analyse oder Feststellung des Istzustandes. Im Zeitalter der Disruption ist diese Phase schon problematisch, weil sie zu einem bekannten „Weiter-so“ führen könnte. Das leitet in eine Sackgasse über.  Ein bloßes Abbilden dessen, was man Wirklichkeit nennt, hilft nicht weiter. Bedenken sollte man den Satz: „Die Wirklichkeit redet nicht, sie schweigt. Reden  tun die Menschen nach ihrem Gusto“. Radikale Darstellungen  wie die von Christian Keese in seinem neuen Buch „ Disrupt yourself“ verlangen sogar im Anblick der Digitalisierung eine „Selbstzerstörung“, ein Neuerfinden seiner selbst. Keese greift dabei zurück auf Ideen eines Josepf Schumpeters (1883-1950), der österreichische Ökonom, der  einen dynamischen, und auch zerstörerischen Unternehmer forderte, um Neues schaffen zu können.

Jetzt kommt das Beschreiben (description), unser Thema.

Es helfen uns jetzt Naturwissenschaftler und Philosophen. Wir greifen zunächst auf  ein Buch von Inthetveen und Kötter (Hrsg)  zurück über „Betrachten-Beobachten-Beschreiben in Kultur-und Naturwissenschaften“ und hier  auf den Aufsatz von Inhetveen und Kötter: „Beschreibung in Kultur-und Naturwissenschaften. Zur Einführung“ (pdf Beschreibung). Nicht erklären, sondern beschreiben sollte das Ziel aller wissenschaftlichen Bemühungen sein, heißt es da, und man zitiert den berühmten  Physiker Gustav Kirchhoff (1824-1887), bekannt durch die „Kirchhoffschen Gesetze“. Kirchhoff schrieb:  „Aus diesem Grund stelle ich es als die Aufgabe der Mechanik hin, die in der Natur vor sich gehenden Bewegungen zu beschreiben, und zwar vollständig und auf die einfachste Weise zu beschreiben. Ich will damit sagen, dass es sich nur darum handeln soll, anzugeben, welches die Erscheinungen sind, die stattfinden, nicht aber darum, ihre Ursachen zu ermitteln“. Der Physiker Kirchhoff um 1876 will also beschreiben und nicht über Ursachen erklären. Erstaunlich! Und bei Ludwig Wittgenstein (1889-1951) ist in seinen Philosophischen Untersuchungen  von 1953   zu lesen: „Alle Erklärung muss fort, und nur Beschreibung an ihre Stelle treten“. Das steht im §109, an dessen Ende der berühmte Satz zu finden ist „Die Philosophie ist ein Kampf gegen die Verhexung unseres Verstandes durch die Mittel unserer Sprache“.     Wittgenstein fordert uns zum Treppensteigen auf.

Was unterscheidet nun ein Erklären von einem Beschreiben

Wer beschreibt, führt  ein Schema (Typ, kulturwissenschaftlich auch Typus genannt) ein, das universelle Geltung haben soll und benutzt häufig dazu eine spezielle Beschreibungssprache. Man kann auch sagen, er schematisiert. Das ist eine generische Handlung. Z.B.: Genehmigen eines Auftrag bzw. einer Immatrikulation. Statt ‚beschreiben‘ sagt man auch wissenschaftstheoretisch zwecks Unterscheidung  von ‚ausführen‘ auch ‚anführen‘, oder auch ‚erwähnen‘ (to  mention). Die speziellen Sprachen, die man dazu benutzt (wie wir gleich mit unseren Sprachen  UML und BPMN zeigen) heißen Erwähnungssprachen (mention languages). Erwähnungssprachen werden im Sinne der klassischen Unterscheidung von „use /mention“ abgegrenzt von Gebrauchssprachen (use languages). Wer UML oder BPMN zur Beschreibung verwendet, der erwähnt, der gebraucht nicht.

Wer erklärt, der aktualisiert ein Schema und benutzt dazu eine Gebrauchssprache. Aktualisieren  ist eine individuelle Handlung. Z.B.: „Der Student mit der Nr.47111 ist ein immatrikulierter Student“ ist eine Erklärung. „ Alles Individuelle muss weg, alles muss generisch oder universell sein“ sagt Wittgenstein in §109 PU sinngemäß. Also werden wir ihm folgen.

2) Unified Modeling Language (UML) und BPMN

In einem ersten Ansatz kann das Wort ‚Modellieren‘ (modeling) mit ‚beschreiben‘ übersetzt werden, was in dem Aufsatz „Modellieren, Simulation, Visualisieren: Zu den aktuellen Aufgaben der Informatik“ (1998, Wedekind e.a.)  näher ausgeführt wird. Eine der wichtigsten Beschreibungssprachen der Informatik in den Anwendungen ist  UML, eine Diagrammsprachen-Familie. Es handelt sich um eine de facto Norm der OMG (Object Management Group).

Abb. 2: UML = Unified Modeling Language

Entsprechend der klassischen Gliederung  von Organisationen  in  Aufbauorganisation (structural organization) und Ablauforganisation (process organization) werden zwei Grundtypen von Diagrammen unterschieden. Wir beschränken uns auf die Ablaufdiagramme, die leider Gottes ‚Verhaltensdiagramme‘ (behavior diagrams) heißen, weil es im Englischen kein adäquates Wort zum Deutschen ‚Vorgang‘ oder ‚Ablauf‘ gibt, es ei denn man sagt ‚process‘ Die Angelsachsen sind eben in ihren Behavorismus mit dem stimulus/response- oder Reiz/ Reaktions-Schema verliebt.

Aus den Aktivitätsdiagrammen als Verhaltensdiagramme in der obigen Abb. 2 ist innerhalb der OMG das BPMN ( Business Process Management and Notation) entstanden, das mit der 2. Verison im Jahre  2011 einen Höhepunkt erreichte. BPMN spielt im Rahmen der Beschreibung von Prozessen in der Digitalisierung eine bedeutende Rolle. Von großer Wichtigkeit ist nun, dass der Entwurf mit der Beschreibungssprache BPMN strukuriert und nicht wild erfolgen sollte, weil man sonst wegen der Kompexität der Materie in einem unübersehbaren Chaos landet. Die Entwurfsschichten, die sich unmittelbar mit dem Zweck der Auftragserteilung befassen (die eigentliche Anwendung), sind strikt von den Schichten der technischen Mittel zu abstrahieren. Das Beipiel in Abb.3 stammt aus unserem Blog. Weitere Digitalisierungen würden heißen, man ersetzt z.B. in Abb. 3 in der  Darstellung eines  Teil-Prozesses im BPMN  eine menschliche Büste durch ein Zahnradpaar, was automatisieren, sprich digitalsisieren  bedeuten würde.

Abb 3.  Strukturiertes BPMN- Diagramm

Wie vor 50 Jahren, als das Thema „Strukturiertes Programmieren“ heftig diskutiert wurde, steht heute eine Strukturierung von BPMN- Diagrammen zur Debatte. Damals gab es einen Edsger W. Dijkstra, Turing-Preisträger 1972,  der federführend war.