1) Kann man aus der Geschichte lernen?
„Kann man aus der Geschichte lernen? war das Thema vom Ex-Bundespräsidenten Roman Herzog (1934-2017) im September 1996 auf dem Deutschen Historikertag in München. Herzog problematisierte die Fragestellung in souveräner Art und Weise. Und wir zitieren ihn, weil er uns ganz zu Anfang schon eine Steilvorlage für unser Thema liefert. Er schreibt:
„ Und gefährlich wird die Sache dadurch, dass der Rückgriff auf die Geschichte meist in solchen Momenten geschieht, in denen es um eine grundsätzliche Neuorientierung der
Politik geht, in denen also das Bedürfnis nach Orientierung besonders groß und
die Berechenbarkeit der Zukunft besonders klein ist. Die Geschichte wird meist
dann zum Argument, wenn man in einer Gegenwart nicht mehr so recht weiter weiß.“
Wir sprechen heute in Sachen Digitalisierung kurz von Disruption und meinen die vollkommene Veränderung unserer Lebenswelt, die uns binnen Kurzem blüht. Man schreit in der Presse, Pädagogik und Politik nach schnellen Übertragungen von riesigen Datenmengen, von Geräten und properer Software. Das ist sicherlich alles sehr wichtig, ist aber zu kaufen. Ich spreche etwas süffisant von Bestell-Digitalisierung. Die ist mit unserer Methodischen Digitalisierung nicht gemeint. Man bemängelt in der Presse aber auch die mangelhafte Digitalisierung in den Organisationen, nicht erst in der Corona – Zeit. Die Organisations-Digitalisierung, die ist mit „Methodischer Digitalisierung“ gemeint. Hier ist unser Bedürfnis nach Orientierung besonders groß, im Sinne von Roman Herzog, wegen der Disruption. Und wir greifen auch in seinem Sinne zur Geschichte, weil wir in „der Gegenwart nicht mehr so recht weiterwissen“. Es ist keine politische Geschichte, es ist die Geschichte der Informatik, die uns weiterhelfen soll. Schließlich ist Informatik die Wissenschaft, die die Digitalisierung begründet hat. Unsere Antwort wird sein: „Ja wir können aus dieser Geschichte lernen“. Und gefährlich ist der Ansatz im Sinne Herzogs auch nicht, weil Geschriebenes in Hülle und Fülle zur Verfügung steht und man keiner Deutungshoheit über Lebenswelten durch Koryphäen im Historischen bedarf, um zu einer fundierten Aussage zu gelangen.
2) „Der Weg ist das Ziel“
„Methode“ vom Griechischen „μεθoδοζ“ (methodos) heißt der Weg. Statt „Methodisches Digitalisieren“ hätte man auch sagen können „Wegsuchendes Digitalisieren“. In unserem Sinne kann es ein Weg in einem Organisations – Dschungel sein, den wir erkunden wollen. Wir meinen natürlich in unserem Zusammenhang die Ablauforganisation, nicht die Aufbauorganisation. Das ist nicht leicht, das ist schwer, sehr schwer sogar; der Weg ist nicht mit journalistischer Leichtigkeit zu finden. Die Aufgeregtheit um das Digitalisieren ist heute groß, sehr groß sogar. Ihm wird eine zukunfts-bestimmende Bedeutung zugemessen und ist fester Bestandteil von Talkshows und Sonntagsreden der Politiker.
Ein gewichtiger Teil in der Geschichte der Informatik ist die Geschichte der Programmierung; das ist die Planung eines Ablaufs mit den sprachlichen Mitteln eines Rechners. Uns interessiert aber nur ein kleiner Teil dieser Geschichte, nämlich als es methodisch wurde. Und das geschah 1968 mit Dijkstras (1930-2002) epochemachendem Aufsatz „GO TO considered harmful“. Vor diesem Paradigmawechsel programmierten wir wild vor uns hin. Den Code, den wir so um 1960 z.B. in FORTRAN produzierten, verstanden wir selber nach einigen Wochen schon nicht mehr. Es war ein wüstes Herumspringen im Code, was heute Spaghetti-Programmieren genannt wird. Dijkstra mit seinem „ GO TO considered harmful“ führte uns den Weg in die disziplinierte Strukturierte Programmierung, die methodisch ist. Jetzt auf einmal wurde Programmieren zu einer Wissenschaft, eben weil in Strukturen gedacht wurde und auch die soziale Verantwortung mit ins Spiel kam. Denn man kann ja im Sozialen nicht einfach etwas nach Lust und Laune produzieren, was kein anderer Mensch ordentlich lesen und verstehen kann. Denn ein Anderer muss den Code ja pflegen und Veränderungen anpassen können. „Programming is a social activity“ hieß es nunmehr. Wir waren so um 1960, also vor rund 60 Jahren, tief in der Softwarekrise, die wir heute glauben überwunden zu haben, weil Disziplinlosigkeit langsam verschwand. Die akademische Lehre hat viel zu dieser Krisenbewältigung beigetragen.
Ein weiterer großer Schritt in der systematischen Programmierung war der Übergang zur Objektorientierten Programmierung (OO-Programming). So um 1990 kamen objektorientierte Programmiersprachen wie Java und dann das objektorientierte C, umbenannt in C++, die heute in den Anwendungen dominant sind. OO-Programming als methodisches Programmieren hat sich heute durchgesetzt. Seit 1989 gibt es sogar ein Industriekonsortium Object Management Group (OMG), das das methodische Objektorientierte Denken auch durch Standardisieren fördert. Ein Hauptprodukt von OMG war die Modelliersprache UML (Unified Modeling Language), sie ist objektorientiert.
Was ist das nun Objektorientierung? Eigentlich ganz einfach. Objekte der Programmier- Sprachen sind Begriffe wie in unserer Alltagsprache. Unser Denken ist begriffsorientiert aufgebaut, wohlwissend, dass Begriffe Abstrakta sind. Die Disziplin, die aber gefordert wird, lautet: Weg von der Beliebigkeit des täglichen Lebens und hin zu einer disziplinierten Nutzung. Bildlich gesprochen kann ein Objekt oder ein Begriff mit einer Kapsel verglichen werden. Man hat nur über wohl definierte Schnittstellen Zugang zu einer Kapsel. Wildes Zugreifen ist unmöglich. Der innere Bau einer Kapsel bleibt verborgen, das ist etwas für IT –Leute, die das bereitzustellen haben. Nutzen hier, z.B. einer Fachabteilung, und Bereitstellung als Servicegebot einer IT-Abteilung dort. Man nennt das auch informatik-universell Separation of Concerns (SoC) oder Trennung von Aspekten. SoC ist einer der wichtigsten Informatik-Prinzipien überhaupt. Wissenschaftstheoretisch spricht man von Abstraktion, weil eine Nutzung invariant, unabhängig bzgl. diverser, möglichen Implementierungen gültig sein soll. Die Implementierung kann hochgradig digitalisiert sein oder total manuell ablaufen. Die Nutzung muss funktionieren. Man merkt den Zustand der Implementierung nur an der Arbeitsproduktivität, die bei manuellem Ablauf drastisch in den Keller sinkt. An einer hohen Arbeitsproduktivität sind auch die Gewerkschaften interessiert, weil bei hoher Arbeitsproduktivität auch hohe Löhne gezahlt werden können.
3) Vom Methodischen Programmieren zur Methodischen Digitalisierung in der Zukunft
1975 erschien der bekannte Aufsatz von Frank de Remer und Hans Kron mit dem Thema “Progamming- in- the- large versus programming- in -the – small“. Hier wurde dargetan, dass es nicht nur ein Ablaufplanen im Kleinen gibt, das wir als Programmierer bisher bevorzugten, sondern auch ein Ablaufplanen im Großen, das Gegenstand einer Methode sein sollte. Hans Kron kam damals 1974 von der TH Darmstadt zu mir ans IBM Research Lab nach San Jose (Cal). Ich war im Sabbatical dort. Er ging dann leider weiter an die University of California in Santa Cruz zu Prof. De Remer, mit dem er dann den bekannten, häufig zitierten Aufsatz schrieb.
Aus der UML, der Uniform Modeling Language der OMG, wurde im Großen dann 2005 das BPMN (Business Process Management and Notation) der OMG mit der beachtlichen Versionsverbesserung und -erweiterung zu BPMN 2.0 im Jahre 2011. Im Jahre 2013 erschien dann das für das Methodische Digitalisieren bedeutsame Buch von Volker Stiehl: „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN“. Keine Programmschritte werden jetzt „ im Großen“ aus Ausgang genommen, sondern ganze Prozesse, von denen Edwards Deming (1900-1993) sagte: „ If you can’t describe what you are doing as a process, you don’t know what you are doing“. Bechreibung von Prozessen ist also für das Bechreiben von Abläufen fundamental. Und mit einer Prozessbeschreibung steht dann auch die Frage an, welche Prozesse digitalisierbar sind oder zumindest digital unterstützt werden können.
Im Blogbeitrag von Volker Stiehl „The Process Driven Approach( PDA)-Past, Present and Future” vom 2. Nov. 1015 wird, basierend auf BPMN 2.0, in alter Terminologie systematisch eine „Kapsel für Prozesse“ entwickelt, die aus dem Gedanken einer Kapsel für Operationen der Objektorientierung entstanden ist. Es gilt das Prinzip „Separation of Concerns“(SoC). In Bild 1 wir beispielhaft ein Bestellvorgang dargestellt, der den Aspekt (concern) der Fachabteilung für Bestellungen und den Aspekt (concern) der zugeordneten Dienstleistungsabteilung sorgfältig trennt.
Bild 1: Digitalisierung mit BPMN. Große Prozess-Kapsel mit Digitalisierungsmöglichkeiten
Aus historischer Sicht, und wir hoffen ja wie Roman Herzog aus der Geschichte lernen zu können, ist diese Trennung nicht neu. Von alters her unterscheidet man nach REFA, dem Reichsausschuss für Arbeitsstudien, bei Fertigungsprozessen zwischen Hauptzeiten und Nebenzeiten:
Hauptzeiten für Prozesse sind solche, die zum unmittelbaren Fortschritt im Sinne der Auftragserteilung beitragen. Nebenzeiten hingegen sind solche, die nur mittelbar beitragen. Sie sind zum Dienen (engl. service) der Hauptzeitprozesse bestimmt. Sämtliche Kontroll- und Bereitstellungszeiten in der Fertigung sind Nebenzeiten. Z.B. sind die Zeiten für das Abdrehen eines Zylinders Hauptzeiten, das Aufrüsten einer Drehbank und das Nachmessen mit einer Schieblehre geschieht in Nebenzeiten.
Digitalisierung hat eine dienende Funktion. Es ist eine Service-Funktion. Deshalb ist die Service-Schicht in Bild 1 wichtig für eine Digitalsierung. Das doppelte Zahnrad oben links in den Service- Prozessen in Bild 1 bedeutet im BPMN-Jargon, dass ein beliebiger automatisierter Dienst in Anspruch genommen werden kann. Aber auch wenn die Büste eines Menschen oben links erscheint, ist eine Digitalsierung möglich. Warum sollte ein Prozess in Bild 1 „Resolve Communication Problem“ nicht mit Mitteln der KI (Künstliche Intelligenz) in Angriff genommen werden.
Vom „Go To considered harmful“ (1968) und dem Spaghetti Programmieren bis zum durchgängigen objekt-orientierten Programmieren hat es ca. 25 Jahre gedauert. Wenn wir aus der Geschichte in disruptiven Zeiten lernen, dann sollte ein methodisches Digitalisieren, was unser Thema ist, mindestens auch in 25 Jahren gang und gäbe sein. Beginnen wir 2011 mit BPMN 2.0 dann wäre das im Jahre 2036 der Fall. Ob wir uns das im Jahre 2021 leisten können, noch 15 Jahre zu warten, steht hier nicht zur Debatte.
Unser großer Dichter Johann Wolfgang von Goethe (1749-1832) hat auch für uns Digitalisierer immer einen schönen Spruch parat:
„Willst du dich am Ganzen erquicken, so musst du das Ganze im Kleinen erblicken.“
Er sagt uns Digitalisierern deutlich: „ Schaut ruhig mal auf die Programmierung im Kleinen. Dann könnt ihr euch auch an euren Methoden im Großen erfreuen“