Der System Footprint – Vision & Scope eines Systems fixieren

Als Produktverantwortlicher, Systemarchitekt oder Projektleiter bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

• Worin besteht die Vision und der Scope eines Systems?
• Was sind die wichtigsten Funktionen, Eigenschaften und Schnittstellen dieses Systems?
• Wie gelingt es uns bereits zum Projektstart ein abgestimmtes Überblicksbild auf das Systems zu entwickeln?

Unterstützung findest Du im System Footprint und der arbeitsteiligen Erstellung im Rahmen eines Workshops.

Ergebnis: Vision, Umfang und grobe Anforderungen an ein bestehendes oder zukünftiges System definiert

Teilnehmer: mind. 1 Person (besser: im Team)

Dauer: 45 bis 120 Minuten (je Systemumfang und Teilnehmerzahl)

Utensilien: Flipchart/Whiteboard/Metaplan-Wand, Klebezettel & Stifte oder Notebook & Office Software

Zweck

Mit dem System Footprint erarbeitest, dokumentierst und vereinbarst Du den Fußabdruck eines neuen oder bestehenden Systems. Auf einer Seite erklärt das Konzept…

• wer das System einsetzt,
• welchen Mehrwert es generiert und
• wie sich seine Grobstruktur gestaltet.

Das System kann soziotechnischer Natur sein, damit neben Hardware bzw. Software auch Geschäftsprozesse, Gebäude, Anlagen sowie die nutzenden Personen umfassen.

Kennst Du den Business Model Canvas solltest Du mit dem System Footprint in wenigen Minuten zurechtkommen. Die Ähnlichkeiten zum 9-Felder Modell von Alexander Osterwalder und Yves Pigneur sind frappierend, nur das beim Footprint eben nicht das Geschäftsmodell eines Unternehmens, sondern die Vision und der Scope – also das Zielbild und der Umfang – eines Systems im Mittelpunkt stehen.

Synonyme für den System Footprint sind System Canvas oder System Leinwand, teilweise auch in Schreibweisen mit Bindestrich ‚-‚ zwischen den einzelnen Begriffen.

Aufbau

System Footprint – „Was macht ein neues oder bestehendes System aus?“

Kern des System Footprints sind neun Bereiche. Mit diesen untergliederst Du das System. Jeder Bereich enthält mindestens ein Element, welches auf einer Karte notiert wird. Das kann eine konkrete Funktion, eine wichtige Schnittstelle, eine essenzielle Komponente etc. sein.

Warum Karten? Zum einen kannst Du Karten verschieben. Zum anderen zwingt die limitierte Schreibfläche, Dich kurz zu fassen. Schließlich kannst Du Karten einfärben und somit Elementen verschiedener Bereiche in Zusammenhang bringen. Beispielsweise ordnest den Kernanwendungsfall ‚Rollen & Rechte verwalten‘ dem Kernnutzer ‚Administrator‘ zu.

Kernnutzer (engl. Key user) – „Wer agiert mit dem System?“

Dieser Bereich listet alle Anwenderrollen des Systems auf. Häufig sind das bestimmte Nutzergruppen von Fachabteilungen. Aber auch externe Dienstleister, Administratoren und Wartungsverantwortliche sind möglich.

• Wer betreibt das System?
• Wer verwendet das System?
• Wer administriert das System?

Kernnutzer arbeiten unmittelbar mit dem System. Die (in-)direkten Stakeholder der Umgebung des Systems bzw. Projekts erfasst Du beispielsweise mit dem Onion Model.

Kernnutzen (engl. Key benefits) – „Weshalb gibt es dieses System?“

In diesem Bereich notierst Du den Mehrwert des Systems für die Kernnutzer.

• Welches Problem wird gelöst?
• Welche Bedarfe befriedet?
• Welche Jobs unterstützt bzw. automatisiert?

Typische funktionale Nutzenelemente von Systemen im Geschäftskontext sind ‚Zeitersparnis‘ und ‚Fehlerreduktion‘.

Kernanwendungsfälle (engl. Key use cases) – „Welche Nutzeraufgaben unterstützt das System?“

Ein Kernanwendungsfall ist eine Situation, in der einer oder mehrere Kernnutzer direkt mit dem System interagieren.

• Für welche Aufgaben verwendet ein Kernnutzer das System?
• In welchen Fällen arbeitet ein Endanwender mit dem System?
• Für welche Tätigkeiten braucht ein Nutzer das System?

‚Dokument öffnen‘, ‚Dokument bearbeiten‘ und ‚Dokument schließen‘ sind beispielsweise klassische Kernanwendungsfälle bei einem Schreibprogramm wie Microsoft Word.

Kerngeschäftsobjekte (engl. Key business objects) – „Welche Elemente nutzt das System?“

In ihren Kernanwendungsfällen hantieren Kernnutzer mit realen und virtuellen Dingen – den Geschäftsobjekten.

• Mit welchen (im)materiellen Objekten interagiert ein Kernnutzer bei Systemverwendung?
• Welche Daten verarbeitet und speichert das System?
• Für welche Informationen steht das System?

So sind das ‚Giro-Konto‘ oder der ‚Bausparvertrag‘ zwei bekannte Geschäftsobjekte aus dem Bankenumfeld.

Kernfunktionen (engl. Key functions) – „Welche Routinen erledigt das System im Hintergrund?“

Systeme führen im Hintergrund Funktionen aus, meist auf Basis von Kerngeschäftsobjekten.

• Welche zentralen Funktionen stellt das System intern bereit?
• Was für Aufgaben erledigt das System im Hintergrund?
• Welche Tätigkeiten verrichtet das System automatisch?

Typische Kernfunktionen sind ‚Daten importieren‘, ‚Berechnung durchführen‘ oder ‚Daten bereitstellen‘.

Kernkomponenten (engl. Key components) – „Aus welchen Elementen besteht das System?“

Dieser Bereich zeigt alle wichtigen virtuellen und realen Bestandteile des Systems.

• Aus welchen (technischen) Teilsystemen besteht das System?
• Welche relevanten Bauteile enthält das System?
• Was sind Hardware und Software Module des Systems?

Beispiele sind ‚Datenbank‘, ‚Web-Server‘, ‚Akku‘ oder ‚SIM-Karte‘.

Schnittstellen (engl. Interfaces) – „Mit welchen Nachbarsystemen tauscht sich das System aus?“

Relevante fachliche und technische Schnittstellen, über welche das System Energie, Stoffe oder Daten mit Nachbarsystemen austauscht, werden in diesem Bereich festhalten.

• Welche technischen und organisatorischen Verbindungen besitzt das System?
• Mit welchen Nachbarsystemen im Kontext tauscht sich das System aus?
• Worin bestehen Importe und Exporte des Systems?

Übrigens ist auch die Benutzerschnittstelle, wie das Touch-Display oder die Tastatur und die Maus, eine Schnittstelle.

Technische Randbedingungen (engl. Technical constraints)

Technische Besonderheiten, Rahmenparameter und Einschränkungen für das System befinden sich in diesem Bereich.

• Welchen technischen Kontextfaktoren unterliegt das System?
• Worin bestehen die Qualitätseigenschaften des Systems?

Typisch sind Angaben zum Antwortzeitverhalten, Umgang mit großen Daten- & Nutzermengen oder Anforderungen bzgl. Gewicht, Größe, Volumen etc.

Organisatorische Randbedingungen (engl. Organizational constraints)

Schließlich gibt dieser Bereich Auskunft über organisatorische Leitplanken.

• Welche fachlichen, rechtlichen und organisatorischen Kontextfaktoren unterliegt das System?
• Worin bestehen Budgetvorgaben für den Systembetrieb?

Beispiele sind Anforderungen an die Bedienfreundlichkeit, Bedarfe des Betriebs oder Einhaltung von Informationsschutzvorgaben.

Meta-Informationen

Ein guter System Footprint enthält einen aussagekräftigen Titel. In der Regel ist dies der Name des neuen Systems sowie der nutzende Unternehmensbereich. In der Fußzeile beinhaltet der Footprint zudem Zusatzinfos, wie die Zielgruppe, die Autoren, das Änderungsdatum und die Iterationsschleife.

Der System Footprint enthält keine Angaben zum umsetzenden Projekt – bzw. bei großen Systemen – das Projektprogramm. Halte daher alle Einträge zu Budget, Meilensteine, Teamaufstellung, Parallelprojekte, Arbeitsweise, Release-Planung etc. an anderer Stelle wie den Projektsteckbrief, Projektbericht oder Projektauftrag fest.

Anwendung

Starte ein Entwicklungsprojekt mit dem System Footprint. Einmal definiert und verabschiedet, fungiert der One-Pager fortan als Richtschnur durch das Vorhaben. Idealerweise wirken wichtige Stakeholder am Footprint. So erlangt das Nutzer- und Entwicklungsteam in der frühen Projektphase ein einheitliches Verständnis.

1. Erstellen

Ein System dient den Kernnutzern. Beginnt daher in diesem Bereich. Anschließend widmet Ihr Euch dem Kernnutzen. Weiter geht es mit den Kernanwendungsfällen und den Kernfunktionen, anschließend den Schnittstellen, dann den Kernobjekten und Kernkomponenten.

Im letzten Schritt bestimmt Ihr die technischen und organisatorischen Randbedingungen. Notiert alle Elemente auf Karten und ordne sie den 9 Bereichen zu. Nach rund 60 Minuten steht die Initialfassung.

2. Verfeinern

Legt eine Pause ein und iteriert anschließend erneut über den Footprint.

Nach zwei bis fünf Durchgängen sollte der System Footprint stabil sein. Auch sind die Vision und der Scope des neuen Systems nun mit den Teilnehmern abgestimmt.

3. Einsetzen

Packe den System Footprint nicht zu weit weg. Am besten Du druckst das Modell aus und hängst es an prominenter Stelle im Büro aus. Ab jetzt dient Dir und Deinem Team die Visualisierung als Fixstern durch das Entwicklungsprojekt.

Beispiele

System Footprint in Unternehmen

Typische Systeme im Business Kontext sind…

• Geschäftsanwendungen (z.B. Buchhaltungssoftware, Enterprise Resource Planning Systeme),
• Mobile Apps (z.B. Kalender, E-Mail) und
• Produktsysteme (z.B. Klimaanlage, Smartphone).

Ich bringe den System Footprint bei Softwareentwicklungs- und Tool-Auswahlprojekten zum Einsatz. Meist sind die Teamkollegen bereits nach einer Stunde vom Mehrwert und der Einfachheit des Modells angetan.

System Footprint für ein Berater Notebook

Untere Abbildung zeigt einen unvollständigen System Footprint für das System ‚Berater-Notebook‘. Wie die Einfärbung zeigt, ist der Kernanwendungsfall ‚Notebook administrieren‘ dem Kernnutzer ‚Administrator‘ zugeordnet.

Jede Karte steht mit mindestens einer anderen Karte in Zusammenhang. Beispielsweise steht das Kerngeschäftsobjekt ‚Datei‘ mit der Kernfunktion ‚Datei verwalten‘ in Beziehung, der Kernanwendungsfall ‚Wissen recherchieren‘ zahlt auf den Kernnutzen ‚bietet Zugang zu Wissen‘ ein.

Vor- & Nachteile

Pro

• Der System Footprint ist das Big Picture eines Systems dem ‚Weshalb‚ und dem ‚Was‘. Auf einem Einseiter beschreibt er die wichtigsten Eigenschaften, Fähigkeiten, Nutzer und Mehrwerte eines zu entwickelnden Systems. Das ist sowohl Management-kompatibel als auch eine gute Orientierung für die Projektarbeit.
• Der Footprint fungiert als Richtschnur. Jedes Teammitglied kann zu jeder Zeit prüfen, ob seine Ergebnisse auf die Elemente des System Footprint einzahlen.
• Nicht minder wichtig ist sein Erstellungsprozess. Dieser sorgt dafür, dass alle Stakeholder ein geteiltes Verständnis zum System entwickeln und sich über dessen Vision und Umfang einig werden.
• Der System Footprint vermeidet Detailversessenheit. Beißt sich ein Team an einer Karte in einem Bereich fest, signalisieren die noch leeren Bereiche den Fokus wieder auf das Gesamtbild zu richten.

Contra

• Der System Footprint ist eine statische Sicht auf ein bestehendes oder zukünftiges System. Wechselwirkungen mit Nutzern und Nachbarsystemen, interne Zustandsänderungen sowie Reaktionen auf Ereignisse und Zeitverläufe erfasst er nur eingeschränkt.
• Der System Footprint kennt keine Kennzahlen und Ziele. So definiert er zwar den (häufig qualitativen) Nutzen, nicht jedoch den messbaren Zweck eines Systems.
• Auch unterscheidet der Footprint nicht zwischen Qualitätsanforderungen und Systemrandbedingungen. Erstere definieren die Güte einer Kernfunktion bzw. Anwendungsfalles. Letztere schränken den Lösungsraum ein.
• Es bedarf etwas Übung den richtigen Detaillierungsgrad für ein System zu modellieren. Bei 9 Bereichen sind insgesamt 20 Elementekarten etwas wenig, 100 hingegen viel zu detailliert.

Praxistipps

Tipp 1 – Real vs. Digital vs. Hybrid entwickeln

Einen System Footprint kannst Du klassisch am Flipchart, Whiteboard oder der Metaplan-Wand entwickeln. Seine Bereiche sind schnell skizziert, anschließend geht es weiter mit Klebe-, Magnet- bzw. Pinsteckerkarten. Gerade das Stehen vor einer physischen Zeichnung aktiviert die Teilnehmer.

Gute Erfahrung habe ich auch mit der reinen digitalen Varianten gemacht. Gemeinsam sitzt das Team vor einer PowerPoint-Folie, ein Moderator ergänzt virtuell die Karten. Die Hybride Variante – ein PowerPoint Bild auf eine Wand projetziert und anschließendes Kleben von physischen Karten – ist ebenfalls produktiv.

Tipp 2 – Arbeitszeit auf 90 Minuten begrenzen

Je mehr Personen, an der Entstehung mitwirken, desto mehr Zeit solltest Du einplanen. Dabei gilt die erprobte Grenze von 90 Minuten – länger sollte ein Arbeitsdurchgang an einem System Footprint nicht dauern. Dieses künstliche Limit gibt Dir und dem Team durchschnittlich 10 Minuten pro Bereich. Das sorgt für Fokus und fortlaufende Aktion.

Tipp 3 – Elemente uniform und spezifisch formulieren

Notiere die Elemente auf den Karten in den Bereichen immer gleich und sorge damit für eine bessere Lesbarkeit und Verständlichkeit des Footprints. Bewährt haben sich:

• Für Kernnutzer, Kernobjekte, Kernkomponenten und Schnittstellen notierst Du immer Substantive (z.B. ‚Produktionsmeister‘, ‚Dokument‘, ‚Strukturierte Datenbank‘, ‚Microsoft Office‘).
• Für Kernanwendungsfälle und Kernfunktionen notierst Du immer Substantiv + Verb (‚Daten integrieren‘, ‚Dokument drucken‘).
• Für den Kernnutzen, Technische und Organisatorische Randbedingungen notierst Du immer eine Zustandsbeschreibung (z.B. ‚Durchlaufzeit reduziert‘, ’16h/Tag verfügbar‘, ‚Datenschutzgrundverordnung berücksichtigt‘).

Der Footprint soll eindeutig und zugänglich sein. Eine unterhaltsame und abwechslungsreiche Sprache findest Du in der Unterhaltungsliteratur.

Tipp 4 – Elemente um quantitative Aspekte ergänzen

‚Kurze Antwortzeiten‘, ‚Transaktionsdatei‘, ‚Zeitersparnis‘ – diese Technischen Randbedingungen, dieses Kerngeschäftsobjekt bzw. dieses Kernnutzenversprechen sind zwar korrekt, jedoch sehr allgemein formuliert.

Ergänze die Elemente Deines System Footprints im zweiten Schritt mit eindeutigen Mengenaussagen. ‚Antwortzeit < 0,5 Sekunden‘, ‚Transaktionsdatei (3.000 pro Tag)‘ und ‚Zeitersparnis von 2 Stunden / Tag‘ sind viel spezifischer und nützlicher für die Weiterarbeit.

Tipp 5 – Für den initialen Überblick nutzen

Gerade zu Beginn eines Systementwicklungsprojektes ist der System Footprint ein überaus nützliches Tool. Mit dem Modell schaffst Du bei den Stakeholdern Klarheit, weshalb und wofür ein System entwickelt werden sollte.

Auch wenn es verlockend ist, bei der Erstellung in die Einzelheiten der verschiedenen Systemelemente zu gehen – hebe Dir Detailarbeit für spätere Projektphasen und detaillierende Ergebnistypen auf. Einige Anregungen:

• Das Klassendiagramm präzisiert die Kerngeschäftsobjekte.
• Das Persona-Konzept bzw. die Empathy Map beschreiben die Kernnutzer.
• Das Use Case Diagramm und die Story Map detaillieren die Kernanwendungsfälle.
• Das Kontextdiagramm definiert die Schnittstellen.

Tipp 6 – Elemente untereinander verknüpfen

Achtet darauf, dass jedes Element im System Footprint mit mindestens einem anderen Element in Verbindung steht. Daher:

• Kernfunktionen, Kernanwendungsfälle und Schnittstellen referenzieren fast immer auf Kernobjekte.
• Ein Kernanwendungsfall wird von mindestens einem Kernnutzer benötigt.
• Eine Technische bzw. Organisatorische Randbedingungen betrifft ein anderes Footprint Element.

Tipp 7 – System Footprint für die Projektarbeit nutzen

Ziehe den System Footprint in der darauffolgenden Projektarbeit immer wieder heran. Einige Ideen:

• Ein jedes Element des Footprints steht für eine Eigenschaft oder Fähigkeit des Systems und dient als Ausgangspunkt für eine Verfeinerung.
• Im Projekt geäußerte Anforderungen, die nicht auf ein Kernnutzenelement einzahlen, werden kritisch hinterfragt.
• Zu jeder Schnittstelle, die auf dem Footprint hinterlegt ist, wird ein Ansprechpartner der Gegenstelle ausfindig gemacht.

Alle (Zwischen-)Ergebnisse, die später im Projekt entstehen, sollten einen Bezug zu den Elementen im System Footprint haben. Falls nicht, sind sie Verschwendung oder die Vision bzw. der Scope sind unvollständig.

Ursprung

Der System Footprint ist die Schöpfung von Maik Pfingsten. Der studierte Systemingenieur, Trouble Shooter a.D. und heutige Solopreneur entwickelte den Footprint als Werkzeug für seine System Engineering Projekte und übergab diesen 2021 an Björn Schorre.

Pfingsten stellte in seinen internationalen Engagements fest, dass ein System entweder mit viel zu viel, oder weitaus zu wenig Dokumentation beschrieben wurde. Inspiriert vom Business Model Canvas konzipierte er den System Footprint als Mittel der Erkenntnisgewinnung und Konsensbildung unmittelbar zu Beginn eines Entwicklungsprojektes.

Bonusmaterial

• Maik Pfingsten: The System Footprint – Anforderungen strukturieren und visualisieren (30min) – im Podcast stellt Pfingsten das Canvas vor