---
mpf: '0.7'
title: Die Reihenfolge — ESFI Docs
url: https://docs.esfi.eu/de/our-approach/the-sequence/
mpf-url: https://docs.esfi.eu/de/our-approach/the-sequence/index.mpf
organization: European Strategy & Future Infrastructure
domain: docs.esfi.eu
lang: de
updated: '2026-11-03'
author: ESFI
provenance: human
source-hash: 2c275f9a05b106b6c69e15c6d6be8ab3fa0001950afed21ecbf2ec599b4d5d7e
toc:
  - level: 1
    text: Die Reihenfolge
    id: die-reihenfolge
  - level: 2
    text: 'Intelligence: die Struktur verstehen'
    id: intelligence-die-struktur-verstehen
  - level: 2
    text: 'Architecture: für reale Bedingungen entwerfen'
    id: architecture-für-reale-bedingungen-entwerfen
  - level: 2
    text: 'Operations: bauen, bis es ohne uns läuft'
    id: operations-bauen-bis-es-ohne-uns-läuft
  - level: 2
    text: Gates zwischen den Phasen
    id: gates-zwischen-den-phasen
  - level: 2
    text: Warum Partner in jeder Phase sind
    id: warum-partner-in-jeder-phase-sind
  - level: 2
    text: Auf dieser Seite
    id: auf-dieser-seite
spec-origin: esfi.eu
content-origin: docs.esfi.eu
content-id: esfi:page:our-approach-the-sequence
content-parity:
  html: true
  human-visible-source: true
  hidden-sections: false
summary: Verstehen. Entwerfen. Bauen. In dieser Reihenfolge, jedes Mal.
index: true
confidence: probable
content-type: narrative
companion-footer: ESFI — civilization infrastructure · https://esfi.eu
companion-contact: mailto:hermes@esfi.eu
preferred-representation: mpf
companion-scope:
  cite: true
  summarize: true
  train: true
  index: true
  relay: true
language-variants:
  en: https://docs.esfi.eu/our-approach/the-sequence/index.mpf
  fr: https://docs.esfi.eu/fr/our-approach/the-sequence/index.mpf
  nl: https://docs.esfi.eu/nl/our-approach/the-sequence/index.mpf
  de: https://docs.esfi.eu/de/our-approach/the-sequence/index.mpf
  hr: https://docs.esfi.eu/hr/our-approach/the-sequence/index.mpf
mpf-id: 3af7a5bd7aea34b98ff847473074c91f863f0778b26a8f04915d875df02942ce
---

Sprache

✕

/de/our-approach/the-sequence/index.mpf[Datei öffnen ↗](/de/our-approach/the-sequence/index.mpf)[Spezifikation ↗](/de/standards/mpf/0.7)✕

wird geladen…

# Die Reihenfolge {#die-reihenfolge}

**Verstehen. Entwerfen. Bauen. In dieser Reihenfolge, jedes Mal.**

Jede ESFI-Initiative durchläuft nacheinander drei Disziplinen: **Intelligence, Architecture, Operations.** Das ist kein Organigramm. Es ist eine Methode, um sicherzustellen, dass das Richtige gebaut wird, dass es unter realen Bedingungen funktioniert und dass es weiter funktioniert, nachdem die Menschen, die es gebaut haben, gegangen sind.

Die Reihenfolge zählt. Architecture ohne Intelligence erzeugt gut entworfene Lösungen für das falsche Problem. Intelligence ohne Architecture erzeugt Berichte. Operations ohne beides erzeugt Piloten, die enden, wenn ihre Finanzierung endet.

Die Reihenfolge ist das Produkt.

## Intelligence: die Struktur verstehen {#intelligence-die-struktur-verstehen}

Intelligence bedeutet für uns nicht Informationssammlung. Es ist strukturelles Verständnis: sehen, warum sich ein System verhält, wie es sich verhält, wo es fragiler wird und wo die Lücke zwischen dem, was beabsichtigt war, und dem, was tatsächlich passiert, wächst.

In einem Auftrag kartieren wir hier die Funktion, ihre Abhängigkeiten und die Menschen und Institutionen, auf die sie sich stützt. Hier testen wir auch die Diagnose aus [Wo die Arbeit beginnt](/de/our-approach/where-the-work-begins) gegen Evidenz statt Annahme.

**Was es erzeugt:** ein gemeinsames Verständnis der Lücke, in Begriffen festgehalten, die beide Seiten akzeptieren, mit der Evidenz, auf der es beruht, und den Unbekannten, die bleiben.

**Wann es abgeschlossen ist:** wenn Partner und ESFI sich darüber einig sind, was das Problem ist, warum es bestehen bleibt und was zeigen würde, dass es gelöst wurde. Wenn diese Einigung nicht erreicht werden kann, geht die Arbeit nicht weiter. Für ein umstrittenes Problem zu designen ist der teuerste verfügbare Fehler.

## Architecture: für reale Bedingungen entwerfen {#architecture-für-reale-bedingungen-entwerfen}

Architecture übersetzt Verständnis in ein operatives Design: das Modell, die Standards, institutionellen Regelungen und technischen Systeme, die die Lücke schließen würden.

Die Betonung liegt auf _operativ_. Ein Design, das in einem Workshop funktioniert und in einem Beschaffungsprozess, einer Rechtsprüfung oder einem Budgetzyklus scheitert, ist kein Design. Wir bauen für reale Partner, reale Rechtsgrenzen und reale institutionelle Bedingungen, einschließlich derjenigen, die niemand gern erwähnt.

**Was es erzeugt:** ein Design, das von den Menschen mitgestaltet wurde, die es betreiben werden, mit sichtbaren Annahmen, kartierten Abhängigkeiten und benannten Failure Conditions.

**Wann es abgeschlossen ist:** wenn das Design gegen die Bedingungen getestet wurde, denen es begegnen wird, die Menschen, die es betreiben sollen, erklären können, warum es so gebaut ist, und der Partner beurteilen kann, ob es bereit zum Bau ist.

## Operations: bauen, bis es ohne uns läuft {#operations-bauen-bis-es-ohne-uns-läuft}

Operations ist die Phase, in der das Design implementiert, unter realen Bedingungen getestet und in etwas Stabiles verwandelt wird. Sie ist auch die Phase, die am häufigsten zu früh endet.

Viele Initiativen stoppen bei einem Piloten. Der Pilot funktioniert, der Bericht wird geschrieben, die Finanzierung endet und die Fähigkeit verschwindet. Wir behandeln einen Piloten als Schritt, nicht als Ergebnis. Ziel ist eine Funktion, die unabhängig, dauerhaft und im Maßstab läuft, lange nachdem die Initiative, die sie geschaffen hat, beendet ist.

**Was es erzeugt:** eine funktionierende, von der Institution betriebene Funktion mit Evidenz, dass sie unter den Bedingungen funktioniert, die zählen.

**Wann es abgeschlossen ist:** wenn die Funktion uns nicht mehr braucht. Das ist in [Was bei Ihnen bleibt](/de/our-approach/what-stays-with-you) beschrieben.

## Gates zwischen den Phasen {#gates-zwischen-den-phasen}

Jeder Übergang von einer Disziplin zur nächsten ist eine Entscheidung, kein Datum in einem Plan. Er wird gemeinsam getroffen und beruht auf Evidenz statt Momentum.

| Von | Zu | Nur wenn |
| --- | --- | --- |
| Intelligence | Architecture | Problem, Ursachen und Erfolgsmaß sind vereinbart und durch Evidenz gestützt. |
| Architecture | Operations | Das Design hat seine realen Bedingungen bestanden und der Partner kann beurteilen, dass es bereit ist. |
| Operations | Exit | Die Funktion läuft, verändert sich und stellt sich ohne uns wieder her. |

Manchmal zeigt ein Gate, dass eine frühere Phase erneut besucht werden muss. Ein Design trifft auf eine Bedingung, die das Verständnis des Problems verändert; ein Test zeigt eine Abhängigkeit, die niemand kartiert hatte. An diesem Punkt zurückzugehen ist kein Scheitern. Ungeachtet dessen weiterzumachen wäre es.

## Warum Partner in jeder Phase sind {#warum-partner-in-jeder-phase-sind}

Die Reihenfolge ist nicht etwas, das ESFI im Auftrag einer Institution durchführt und anschließend liefert. Die Menschen des Partners sind Teil jeder Phase: Sie helfen beim Aufbau des Verständnisses, formen das Design und betreiben die Funktion.

Das ist am Anfang langsamer. Es ist auch die einzige Methode, die wir kennen, um sicherzustellen, dass der Partner an jedem Gate die Arbeit selbst beurteilen kann, statt unser Wort zu nehmen. Wenn die Arbeit Operations erreicht, verstehen die Menschen, die die Funktion betreiben werden, bereits, warum sie so gebaut wurde.

**Verwandt:** [Wo die Arbeit beginnt](/de/our-approach/where-the-work-begins) · [Was bei Ihnen bleibt](/de/our-approach/what-stays-with-you) · [Sechs Fragen, die wir stellen](/de/our-approach/six-questions-we-ask)

## Auf dieser Seite {#auf-dieser-seite}

ESFI — civilization infrastructure · https://esfi.eu