Der System Footprint – Entwicklung und Einsatz

In diesem Beitrag möchte ich den System Footprint als strukturierte Systemvisualisierung diskutieren. Denn obwohl dieser Überblick enorm wertvoll und effektiv ist, wird er oft unterschätzt.

Die Geschichte des System Footprint

Der System Footprint ist im Troubleshooting entstanden. Ich befand mich immer wieder in Situationen, in denen ich sozusagen als „externes Feuerwehr-Männchen“ in ein Projekt gesprungen bin – und schnell ein klares Verständnis des Systems brauchte: Wie genau ist es aufgebaut und welche sind die wichtigsten Anforderungen?

Meist hatten wir in diesen Situationen kaum noch Zeit und konnten nur die wichtigsten Dinge umsetzen. Dazu musste entschieden werden, welche von den existierenden Anforderungen an das System in diesem oft sehr angespannten Kontext überhaupt noch relevant waren.

Und so habe ich schon 2005 angefangen, mir eine Mindmap aufzubauen, in welche ich zunächst alles hineingekippte, was wahrscheinlich relevant war und Sinn machte. Das funktionierte eine Zeit lang ganz gut – allerdings noch nicht optimal.

Kurze Zeit später bin ich über das Buch „Business Modell Generation“ vom Alexander Osterwalder gestolpert. Es beschreibt eigentlich, wie ein Business Modell visualisiert werden kann. Ich habe allerdings die Grundidee dieser Visualisierung und den Nutzen der Post-Its genommen und unsere nötigen Schwerpunkte integriert.

Dann habe ich die Inhalte auf ein „Canvas“ – so nennt sich die Fläche, auf der wir alles darstellen – übertragen und in die bereits bestehende Mindmap eingesetzt. So konnte ich dann in den Blöcken des Footprints alles Nötige wesentlich besser visualisieren als zuvor. Seit dieser zweiten Version heißt das Ganze nun System Footprint.

Stets einsatzbereit – auch im IT-Bereich …

In den letzten Jahren hat sich der SysFP enorm weiterentwickelt, zum einen durch seinen Einsatz in der Praxis, zum anderen aber auch durch starkes Feedback. Ich habe intensive Diskussionen geführt und die neuen Erkenntnisse konstant eingebaut.

Besonders spannend war für mich auch, dass der System Footprint in zwei verschiedenen Kontexten sehr gut funktioniert: In mechatronischen, technischen Projekten – und bei IT-Systemen.

Ich betrachte als Mechatroniker bzw. als System-Ingenieur Systeme als mechatronische, technische Systeme: Wir erfassen im System Footprint also alle Fraktionen, Konstruktionen, die Elektronik, Software, Optik etc. – eben alles, was es in diesem System gibt.

Mittlerweile habe ich aber auch eine Menge Anfragen rund um IT-Systeme. Das war für mich zunächst überraschend, da ich das anfänglich gar nicht im Fokus hatte, aber offensichtlich liegt dort auch Bedarf vor. Und das Gute ist: Der System Footprint funktioniert auch dort super.

… und auf allen Ebenen

Ursprünglich habe ich das Ganze als Visualisierung der Systemanforderung für ein Troubleshooting-Projekt entwickelt – also für die Systemebene. Ich greife die Ebenen hier nochmals kurz auf: Die oberste Ebene ist die Kundenebene. Auf dieser existieren Lastenhefte, Normen und weitere Spezifikationen – kurz, das „Wünsch-Dir-Was“.

Die Ebene darunter ist die Systemebene, umgangssprachlich auch als Pflichtenheft bezeichnet. Diese lässt sich aufteilen in Problembereich – die Antwort des Projekts auf das Lastenheft – und Lösungsbereich – die Systemarchitektur-Spezifikation, also die Lösungsbeschreibung.

Auf der Systemebene funktioniert der System Footprint unglaublich gut und wirkungsvoll – dafür war er ja ursprünglich gedacht. Doch er unterstützt auch die Erstellung von Lastenheften extrem gut: Wir visualisieren damit Aspekte, die bis dahin vielleicht gar nicht sichtbar waren.

Die Visualisierung der Anforderungen ist ein extrem großer Nutzen. In den zahlreichen Workshops, die ich in den letzten Jahren durchgeführt habe, haben wir den System Footprint in ca. zwei bis vier Stunden erstellt – und konnten dann sehr effektiv damit arbeiten: Die Visualisierung nahm eigentlich das gesamte Team vor, während ich es dabei begleitete und vor allem half, ein gemeinsames Verständnis für das große Gesamtbild zu erschaffen.

Ein weiterer Gewinn war die viel bessere Kommunikation. Bei einem großen Unternehmen aus der feinmechanischen-optischen Industrie beispielsweise haben wir zum Workshop nicht nur die Entwickler eingeladen, sondern auch Leute aus Vertrieb, Marketing, Produktion, Produktmanagement etc. Das Feedback sprach für sich.

Insgesamt hat sich das gemeinsame Verständnis enorm weiterentwickelt und die Kommunikation untereinander ist wesentlich besser geworden. Alle konnten das System gemeinsam betrachten, die Kundensicht nachvollziehen und mit dem Lastenheft das große Ganze erkennen. Außerdem konnten wir zusammen mit dem Project Footprint die Trennung zwischen den technischen und den Projektanforderungen auch ganz bewusst herbeiführen.

Im nächsten Teil werde ich näher auf die Formen und Inhalte des System Footprints eingehen.