Als ProduktverantwortlicherSystemarchitekt 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.


Überblick

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 sind System Canvas oder System Leinwand.


Aufbau

System Footprint

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.

System Footprint
Struktur und Elemente des System Footprints (Quelle: Modell auf Basis Björn Schorres System Footprint 4.0 unter Creative Common -BY-SA Lizenz)

Kernnutzer (engl. Key user)

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)

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)

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)

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)

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)

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)

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 maximal fünf Durchgängen sollte der System Footprint stabil sein. Und nicht nur das. Die Vision und der Scope des neuen Systems sind gleichzeitig 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 Projekt.


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.

System Footprint
Unvollständiger System Footprint für das 'System' Berater-Notebook (Quelle: Modell auf Basis Björn Schorres System Footprint 4.0 unter Creative Common -BY-SA Lizenz)

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 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 120 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 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 eine Zustandsbeschreibung (z.B. ‚Durchlaufzeit reduziert‘, ’16h/Tag verfügbar‘, ‚Datenschutzgrundverordnung berücksichtigt‘).
  • 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 klaren 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, was und warum 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 die späteren Projektphasen und andere Ergebnistypen auf. Einige Anregungen:

  • 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 spätere 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.

  • Lesetipps

    In einem lesenswerten Blogbeitrag der Berliner Firma microTool erklärt Maik Pfingsten seinen System Footprint. Auch auf seiner Webseite Agile Lastenhefte erfährst Du, wie Pfingsten das Modell in der ersten Phase der Erstellung einer Systemspezifikation zur Anwendung bringst.


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

Zuletzt aktualisiert am 25. November 2022 durch Dr. Christopher Schulz


Du möchtest Consulting Methodenkompetenz als Buch?

  • 24 erprobte Consulting Tools auf 200 Seiten
  • Mein Erfahrungswissen als eBook und Print
  • Kompakt erklärt und einfach umsetzbar
  • An einer Stelle direkt zum Nachschlagen
  • Bereits über 5.000 zufriedene Leser


Consulting Methodenvorlagen XXL

Bedarf an den passenden Arbeitsvorlagen?

  • 200 Office-Vorlagen für Deine Projektarbeit
  • Sofort einsatzbereit inklusive Beispiele
  • Im verbreiteten Microsoft Office Format
  • Frei anpassbar auf Deine Bedarfe
  • 200 Methodenspicker als Merkhilfe



Gib ein Kommentar

Your email address will not be published.