“Disruptive Innovation” – ist ein Trendthema in Wirtschaft und Management. Auch wenn Clayton Christensen, der diesen Begriff geprägt hat, ihn anders gemeint hat als er jetzt vielerorts verwendet wird [1] – hat er doch seine Wirkungen auch auf die IT-Analyse. Von den Lösungen, die wir als IT-Analytiker entwerfen, wird Innovation erwartet. Eine IT-Lösung, die nichts weiter ist als eine Kopie des Alt-Systems in neuem Gewand, wird nur selten Akzeptanz finden. Aber wie kommt die Innovation in die Lösung? Reichen die bekannten Vorgehensweisen des Requirements Engineering aus – oder brauchen wir Neues?
Der Geistesblitz als Quelle der Innovation
Hatten Sie schon einmal einen Geistesblitz? Ich meine diesen Moment, wo die Lösung plötzlich klar vor Augen steht; die Lösung eines Problems, mit dem Sie sich schon stunden- oder sogar tagelang gedanklich abgemüht haben, ohne Ergebnis. Und da spreche ich noch gar nicht von IT. Das kann auch so etwas scheinbar Banales sein, wie die Urlaubsplanung einer mehrköpfigen Familie mit sehr unterschiedlichen Interessen. Und plötzlich ist sie da – die eine Destination, für die sich alle begeistern können.
So ein Geistesblitz hilft natürlich auch bei vielen anderen Problemen – Fragestellungen beim Hausbau, technische Fragestellungen, Inhalt eines Artikels für den microTOOL Blog.
Die historisch erste Person, von der ein derartiger Geistesblitz berichtet wird, ist Archimedes von Syrakus. Der Legende nach hatte König Hieron II seinen Goldschmied in Verdacht, der neuen Goldkrone zu viel Silber beigemengt zu haben. Deshalb stellte der König Archimedes die Aufgabe, herauszufinden, wie viel Silber in der Goldkrone sei. Wir dürfen davon ausgehen, dass Archimedes lange in seiner Stube darüber gegrübelt hat, wie er diese Aufgabe lösen könne. Wahrscheinlich wollte er sich dann eine Pause gönnen und entspannen. Er hat ein Bad genommen. Und weil er dabei bemerkt hat, dass aus seiner Badewanne Wasser ausfließt, wenn er sich hinein setzt, ist ihm dieser Geistesblitz gekommen, den wir heute das „Archimedische Prinzip“ nennen. Daraufhin soll er aus seiner Wanne herausgesprungen und nackt, laut „Heureka“ rufend, durch die Straßen gelaufen sein.
Dieses Muster – ein Geistesblitz nach intensiver Vorarbeit, dann wenn man es nicht erwartet – wurde von verschiedenen Autoren zu einem „Kreativitätprozess“ ausformuliert. Einer der ersten war Graham Wallas, der im Jahr 1926 Beobachtungen des deutschen Physikers Hermann von Helmholtz und des französischen Mathematikers Henri Poincaré zu einer systematischen Theorie des kreativen Denkens zusammengefasst hat.[2] Nach dieser Theorie vollzieht sich das kreative Denken in vier Phasen:
- Präparation: Hier beschäftigt man sich intensiv mit dem Problem, man sammelt Informationen, baut Wissen auf. Auch Archimedes wird wohl viel darüber nachgedacht haben, wie er denn feststellen könne, ob die Krone des Königs wirklich aus purem Gold ist.
- Inkubation: Hier lässt man all die Informationen, die in der Präparationsphase gesammelt wurden, setzen. Man tut nichts, entspannt, bzw. beschäftigt sich mit etwas anderem. Wenn man Archimedes ist, geht man vielleicht ins Bad. Das Gehirn arbeitet trotzdem.
- Illumination: Da kommt jetzt das “Heureka” des Archimedes. Das Unterbewusstsein hat seine Arbeit getan. Die Elemente, die wir uns in der Präparationsphase angeeignet haben, werden neu zusammengefügt – und die Lösung tritt ins Bewusstsein.
- Verifikation: Geistesblitze gibt es (vielleicht) viele. Die Idee muss sich aber bewähren. Sie wird aber erst auch bei der Konfrontation mit der Realität bestätigt – oder auch nicht. So wird auch Archimedes zurück in seine Studierstube geeilt sein – nackt, wie wir wissen – und seinen Geistesblitz durch Experimente überprüft haben.
Was können wir daraus für unsere Arbeit in der IT-Analyse lernen? Hat dieser Kreativitätsprozess auch in der Vorgehensweise des Requirements Engineering Raum? Sehen wir uns dazu einmal die Haupttätigkeiten des Requirements Engineering an, wie sie etwa im Lehrplan zur IREB-CPRE-Prüfung [3] formuliert sind:
- Anforderungen ermitteln
- Dokumentation von Anforderungen
- Anforderungen prüfen und abstimmen
- Anforderungen verwalten.
Wo ist hier Raum für Kreativität? Lassen sich die vier Phasen des Kreativitätsprozesses hier unterbringen? Anforderungen ermitteln und dokumentieren – das klingt nicht nach einem kreativen Prozess. Man darf dem klassischen Requirements Engineering aber auch nicht unrecht tun. Es gibt sie schon – die Kreativitätstechniken, wie Brainstorming, oder die Six Thinking Hats. Und es gibt auch die Begeisterungsfaktoren des Kano-Modells.
Und trotzdem – wenn wir zu kreativen Lösungen kommen wollen, dann werden wird das Vorgehensmodell des Requirements Engineering weiterentwickeln müssen.
IT-Analyse – der Prozess
Wie also kommt nun Kreativität in die IT-Analyse?
Der oben angeführte Kreativitätsprozess muss in der IT-Analyse Platz haben. Zu diesem Zweck schlagen wir einen Analyse-Prozess – wir nennen ihn Systemanalyse 3.0 – mit drei Haupttätigkeiten vor:
- Analysieren: Die verfügbaren Informationen werden zu einem Lösungsentwurf geformt.
- Kommunizieren: Es werden Informationen von den Stakeholdern geholt und die Lösungsideen des Analytikers mit ihnen abgestimmt.
- Produzieren: Die für die Entwicklung erforderlichen Artefakte, die das Lösungsdesign beschreiben, werden erstellt.
Haupttätigkeiten im IT-Analyse-Prozess
Analysieren
“Analysieren” ist der Teil des Analyse-Prozesses, in dem die verfügbaren Informationen zu einem Lösungsdesign geformt werden.
Präparation
Die erste Stufe im Kreativitätsprozess nach Wallas ist die „Präparation“. James Webb Young unterteilt diese Phase in zwei Teilphasen: das Sammeln von Rohmaterial und das Bearbeiten dieses Rohmaterials.[4]
Der Analytiker wird sich beispielsweise mit folgenden Fragen beschäftigen:
- Was ist die Aufgabe dieses Fachgebietes? Warum existiert es überhaupt?
- Was sind die wesentlichen Objekte bzw. Begriffe?
- Woher kommen die wesentlichen Informationen? Was sind die Schnittstellen zu anderen Fachgebieten?
- Welche anderen Fachgebiete bauen auf Informationen des zu bearbeitenden auf?
- Wie funktioniert dieses Fachgebiet? Was sind seine Regeln?
- Was soll mit dem zu entwerfenden System erreicht werden?
Das ist ein völlig anderer Ansatz als “Anforderungen ermitteln”. Es geht dabei nicht darum, zu erfragen, was jemand anderer (die Stakeholder) vom neuen System will. Es geht um ein Eintauchen in die Welt dieses Fachgebietes und in seine Regeln.
Die Quellen dieses Wissens sind vielgestaltig: Je nach Gebiet können das Fachbücher sein und verschiedenste schriftliche Aufzeichnungen. Quellen sind natürlich auch die Stakeholder, die Experten für das Fachgebiet. Auch hier geht es in erster Linie nicht darum, Anforderungen abzuholen, sondern Wissen aufzubauen, obwohl sich das in vielen Fällen überschneiden wird. Dieses Wissen ist das Rohmaterial, aus dem unser System entworfen wird.
„Creativity is just connecting things“, lautet ein Zitat von Steve Jobs. Das erarbeitete Rohmaterial muss also neu verbunden werden. Dafür muss der Analytiker mit dem Material spielen – versuchen, die einzelnen Elemente neu zusammenzusetzen. Das wird er in ständiger Abstimmung mit den Stakeholdern machen. Es ist also nicht damit getan, einmalig die Anforderungen abzuholen – verschiedene Lösungsansätze müssen immer wieder abgestimmt werden.
Inkubation
Beim Verarbeiten des Rohmaterials werden Probleme auftreten – die einzelnen Elemente werden nicht so zusammenpassen, wie es der Analytiker vielleicht gerne hätte, es wird vielleicht Widersprüche in den Aussagen und Wünschen der Stakeholder geben. Deshalb lässt man die Aufgabe eine Zeitlang ruhen, lässt das Problem in das Unterbewusstsein hinabsinken – und lässt das Unterbewusstsein seinen Job tun. Der Projektalltag wird es wohl selten zulassen, dass man in der Arbeitszeit ein Bad nimmt, wie es Archimedes tat. Aber man hat sicher die Möglichkeit, sich anderen Arbeiten zu widmen, während das Unterbewusstsein sich der Problemlösung annimmt.
Illumination
Nach geraumer Zeit wird sich das Unterbewusstsein wieder melden – mit völlig neuen Einsichten, mit einem Geistesblitz. Natürlich wird das selten so spektakulär sein, dass man auch noch nach Jahrtausenden davon spricht – wie es bei Archimedes der Fall war. Aber es werden Ideen sein, vielleicht für ein optimales Datenmodell, eine interessante Variante für einen Prozess, ein innovatives User-Interface, oder anderes.
Verifikation
Nicht jeder Geistesblitz ist auch eine gute Idee, nicht alles ist machbar, nicht mit allem sind die Stakeholder auch einverstanden. Das herauszufinden ist Aufgabe der Phase der Verifikation. Dazu gehört einerseits wieder viel Kommunikation, andererseits ist es auch Knochenarbeit, den Geistesblitz auszuformulieren, für andere greifbar zu machen.
Kommunizieren
„Kommunizieren“ nennen wir die zweite Haupttätigkeit in unserem Analyse-Prozess. Anders als im klassischen Requirements Engineering verstehen wird darunter mehr als das “Erheben von Anforderungen”. Es ist einerseits das Sammeln von Wissen über das Fachgebiet bei den Experten und es ist andererseits die Abstimmung unserer Ideen, insbesondere nach dem (hoffentlich eingetretenen) “Heureka” in der Illuminationsphase.
Produzieren
Zu Beginn der dritten Haupttätigkeit des Analyse-Prozesses, dem „Produzieren“, ist die Lösung eigentlich schon fertig. Nun werden die Artefakte produziert, die nötig sind, um den Entwurf umzusetzen – Datenmodelle, Prozessbeschreibungen, Screen-Entwürfe. Natürlich hat es auch schon während der Analyse-Phase das eine oder andere Arbeitspapier gegeben, das mit den Stakeholdern diskutiert wurde. Aber die schönen, endgültigen Dokumente werden hier erzeugt.
Der Grund liegt darin, dass es viel Arbeit macht, ein Prozessmodell zu zeichnen – oder ein Datenmodell. Und wenn man einmal Stunden dafür investiert hat, ändert man das nicht mehr so gerne. Man verliert also Flexibilität, und Flexibilität ist eine Grundvoraussetzung für Kreativität.
Fazit
Fortschreiben der alten Lösung in modernem Gewand – oder aber echte Innovation? Die Entscheidung darüber fällt in der IT-Analyse. Damit Innovation in IT-Projekten möglich wird, muss die Analyse mehr leisten, als sich Anforderungen abzuholen und diese zu verwalten. Der Analytiker wird zum kreativen Gestalter.
Voraussetzung dafür ist aber, dass der IT-Analyse-Prozess Raum gibt für den erforderlichen kreativen Prozess. Die von uns vorgeschlagene Vorgehensweise, wir nennen sie „Systemanalyse 3.0“, vereinigt die notwendige Berücksichtigung der Anforderungen der Stakeholder mit dem Kreativitätsprozess, wie er etwa von Graham Wallas beschrieben wurde.
Quellen:
[1]: Christensen, Clayton: What is Disruptive Innovation? In: Harvard Business Review (https://hbr.org/2015/12/what-is-disruptive-innovation)
[2]: Wallas, Graham: The Art of Thought, New York 1926
[3] IREB Certified Professional for Requirements Engineering – Foundation Level – Lehrplan
[4]: Young, James Webb: A Technique for Producing Ideas, New York 2003