--- mpf: '0.7' title: Fähigkeitstransfer — ESFI Docs url: https://docs.esfi.eu/de/topics/capability-transfer/ mpf-url: https://docs.esfi.eu/de/topics/capability-transfer/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: de updated: '2026-11-03' author: ESFI provenance: human source-hash: 3ad1b28a28f35249c2a9870a6207d5ecdde8243f6c166846e1316437a644ff1c toc: - level: 1 text: Fähigkeitstransfer id: fähigkeitstransfer - level: 2 text: Ein geliefertes System ist keine gelieferte Fähigkeit id: ein-geliefertes-system-ist-keine-gelieferte-fähigkeit - level: 2 text: Das meiste, was zählt, wurde nie aufgeschrieben id: das-meiste-was-zählt-wurde-nie-aufgeschrieben - level: 2 text: Transfer kann nicht die letzte Phase sein id: transfer-kann-nicht-die-letzte-phase-sein - level: 2 text: Abhängigkeit wächst oft aus Erfolg id: abhängigkeit-wächst-oft-aus-erfolg - level: 2 text: Was „Fähigkeit bleibt“ tatsächlich bedeutet id: was-fähigkeit-bleibt-tatsächlich-bedeutet - level: 2 text: Fähigkeit ist ebenfalls ein Single Point of Failure id: fähigkeit-ist-ebenfalls-ein-single-point-of-failure - level: 2 text: Ohne Fähigkeit ist Kontrolle nur formal id: ohne-fähigkeit-ist-kontrolle-nur-formal - level: 2 text: Wie wir gemeinsam daran arbeiten id: wie-wir-gemeinsam-daran-arbeiten - level: 2 text: Wo wir vorsichtig sind id: wo-wir-vorsichtig-sind - level: 2 text: Weiterführende Literatur id: weiterführende-literatur - level: 2 text: Änderungen an dieser Position id: änderungen-an-dieser-position - level: 2 text: Auf dieser Seite id: auf-dieser-seite spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-capability-transfer content-parity: html: true human-visible-source: true hidden-sections: false summary: Bleibt die Fähigkeit bei Ihnen? index: true confidence: probable content-type: analysis 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/topics/capability-transfer/index.mpf fr: https://docs.esfi.eu/fr/topics/capability-transfer/index.mpf nl: https://docs.esfi.eu/nl/topics/capability-transfer/index.mpf de: https://docs.esfi.eu/de/topics/capability-transfer/index.mpf hr: https://docs.esfi.eu/hr/topics/capability-transfer/index.mpf mpf-id: 13ceb85c1b63f7229ccdc16ce533cb81580fd097a86db8356243e86cceca3377 --- Sprache ✕ /de/topics/capability-transfer/index.mpf[Datei öffnen ↗](/de/topics/capability-transfer/index.mpf)[Spezifikation ↗](/de/standards/mpf/0.7)✕ wird geladen… # Fähigkeitstransfer {#fähigkeitstransfer} **Bleibt die Fähigkeit bei Ihnen?** Ein Programm endet. Das externe Team übergibt das System, die Dokumentation und einen Abschlussbericht. Am Tag der Übergabe funktioniert alles, oft noch Monate danach. Dann muss sich etwas ändern. Eine Regelung wird aktualisiert, ein Anbieter ersetzt, ein Prozess an eine Situation angepasst, die niemand vorhergesehen hat. Und die Institution stellt fest, dass ihr das System gehört, aber nicht die Fähigkeit, es zu verändern. Die Menschen, die wussten, warum es so gebaut wurde, sind weitergezogen. Die Dokumentation erklärt, was das System tut, nicht warum. Der nächste Schritt ist eine weitere Beschaffung für ein weiteres externes Team, um Verständnis neu aufzubauen, das einmal schon existierte. Wir sehen dieses Muster in öffentlichen Verwaltungen, bei Infrastrukturbetreibern und Organisationen jeder Größe. Es wird selten durch schlechte Arbeit verursacht. Häufiger wird es durch gute Arbeit verursacht, die falsch organisiert ist: Das externe Team war gerade deshalb effektiv, weil es das Wissen hielt, und nichts im Auftrag verlangte, dass dieses Wissen weiterwandert. Unsere Position ist einfach zu formulieren. **Fähigkeit wird nicht am Ende eines Auftrags übergeben. Sie wird während der Arbeit in der Institution aufgebaut, oder sie wird überhaupt nicht aufgebaut.** Transfer ist nicht die letzte Phase eines Projekts. Er ist eine Designeigenschaft des gesamten Auftrags. Deshalb ist die letzte Stufe jeder ESFI Task Force kein Deliverable, sondern eine Bedingung: Die Funktion braucht uns nicht mehr. Fähigkeit bleibt. Die Task Force geht. Fähigkeit, die mit den Menschen geht, die sie aufgebaut haben, war nie Infrastruktur. * * * ## Ein geliefertes System ist keine gelieferte Fähigkeit {#ein-geliefertes-system-ist-keine-gelieferte-fähigkeit} Die häufigste Verwechslung, die wir sehen, ist die zwischen einem funktionierenden System und der Fähigkeit, mit ihm zu arbeiten. Ein System kann geliefert, getestet und abgenommen sein, während die Institution weiterhin nichts damit tun kann außer dem täglichen Betrieb. Das ist eine enge Form von Eigentum. Sie hält nur, solange sich nichts ändert. Wir finden es nützlich, Fähigkeit in vier Ebenen zu trennen, weil jede anders scheitert. **Betreiben.** Die Institution kann die Funktion unter normalen Bedingungen ausführen. Das ist, was die meisten Übergaben erreichen. **Warten.** Die Institution kann die Funktion gesund halten: Updates einspielen, gewöhnliche Fehler diagnostizieren und routinemäßige Ausfälle beheben, ohne das ursprüngliche Team zurückzurufen. **Verändern.** Die Institution kann die Funktion anpassen, wenn Anforderungen, Umgebung oder rechtliche Bedingungen sich ändern. Dafür muss sie nicht nur verstehen, wie das System funktioniert, sondern warum es so entworfen wurde. **Urteilen.** Die Institution kann Arbeit beurteilen, die andere in ihrem Auftrag leisten. Sie kann erkennen, ob der Vorschlag eines Anbieters solide ist, ob eine Reparatur richtig durchgeführt wurde, ob ein Preis angemessen ist. Das ist die Ebene, die am häufigsten verloren geht, und die teuerste, weil eine Institution, die nicht urteilen kann, nicht gut einkaufen kann. Eine Übergabe, die die erste Ebene liefert und sich vollständig nennt, lässt die Institution auf den anderen drei exponiert. Das zeigt sich meist erst bei der ersten echten Änderung. ## Das meiste, was zählt, wurde nie aufgeschrieben {#das-meiste-was-zählt-wurde-nie-aufgeschrieben} Die naheliegende Antwort auf Fähigkeitsverlust ist Dokumentation. Sie hilft, und wir bestehen darauf. Aber sie löst das Problem nicht, und es lohnt sich, genau zu sagen warum. Der Philosoph Michael Polanyi bemerkte, dass „wir mehr wissen können, als wir sagen können“. Vieles, was ein erfahrenes Team effektiv macht, ist Wissen dieser Art: Urteilsvermögen darüber, welche Warnzeichen zählen, welche Abkürzungen sicher sind, welche Designbeschränkung absichtlich war und welche zufällig. Es lebt in Menschen und Praxis, nicht in Handbüchern. Dokumentation hält Entscheidungen fest. Sie hält selten die Begründung fest, die zu ihnen führte, die Alternativen, die verworfen wurden, oder die Bedingungen, unter denen die Entscheidung neu betrachtet werden sollte. Eine Institution, die Entscheidungen ohne die Begründung erbt, kann betreiben, was ihr gegeben wurde, aber sie kann es nicht sicher verändern. Jede Änderung wird zu einem Raten darüber, was die ursprünglichen Designer beabsichtigten. Deshalb behandeln wir neben Dokumentation drei Dinge als Teil jedes Transfers: - **Entscheidungsaufzeichnungen**, die erklären warum, nicht nur was, einschließlich der Bedingungen, unter denen eine Entscheidung neu betrachtet werden sollte. - **Gemeinsame Praxis**: Arbeit, die gemeinsam getan wird, damit Urteilsvermögen in den eigenen Menschen der Institution entsteht, statt ihnen später beschrieben zu werden. - **Ausgeübtes Wissen**: Verfahren, die die Mitarbeitenden der Institution tatsächlich durchgeführt und nicht nur gelesen haben. Forschung zu organisatorischem Wissen, besonders die Arbeit von Nonaka und Takeuchi, macht seit Langem den Punkt, dass implizites Wissen sich hauptsächlich durch gemeinsame Erfahrung bewegt. Unsere Erfahrung stimmt damit überein. Wissen, das nie von den Menschen angewendet wurde, die es halten sollen, wurde noch nicht übertragen. ## Transfer kann nicht die letzte Phase sein {#transfer-kann-nicht-die-letzte-phase-sein} Viele Aufträge planen Transfer als letzten Schritt: eine Übergabephase, eine Schulungsrunde, eine Reihe von Dokumenten. Die Logik wirkt plausibel. Erst bauen, dann übergeben. In der Praxis geht hier Fähigkeit verloren. Bis zur letzten Phase sind die wichtigen Entscheidungen von Menschen getroffen worden, die kurz davorstehen zu gehen. Mitarbeitende der Institution sollen in Wochen aufnehmen, was das externe Team in Monaten gelernt hat, meist zusätzlich zu ihrer normalen Arbeit. Schulung beschreibt ein fertiges System statt der Begründung, die es hervorgebracht hat. Wir gestalten Transfer anders. Von der ersten Woche an haben die eigenen Menschen der Institution definierte Rollen in der Arbeit, keine Beobachtersitze. Entscheidungen werden mit ihnen getroffen, nicht ihnen präsentiert. Der Anteil der Arbeit, den das externe Team trägt, soll im Verlauf des Auftrags sinken, und diese Abnahme wird so offen verfolgt wie jeder andere Meilenstein. Das hat Kosten. Es ist am Anfang langsamer, weil eine Entscheidung zu erklären länger dauert, als sie einfach zu treffen. Wir betrachten diese Kosten als Teil des Preises für etwas, das die Institution tatsächlich besitzen wird. ## Abhängigkeit wächst oft aus Erfolg {#abhängigkeit-wächst-oft-aus-erfolg} Es ist verlockend, Fähigkeitsverlust als Ergebnis schlechter Anbieter zu sehen. Oft ist das Gegenteil wahr. Ein fähiges externes Team löst Probleme schnell. Die Institution lernt, sich darauf zu verlassen. Jeder erfolgreiche Auftrag macht den nächsten wahrscheinlicher, und jeder verschiebt etwas mehr Verständnis der Institution nach außen. Mit der Zeit wird die Institution sehr gut darin, Arbeit zu beauftragen, und weniger gut darin, sie selbst zu tun oder zu beurteilen. Dieses Muster wurde in den letzten Jahren kritisch untersucht, unter anderem in Mariana Mazzucatos und Rosie Collingtons Untersuchung darüber, wie die Abhängigkeit von Beratungen die Fähigkeiten der Organisationen schwächen kann, die sie nutzen. Man muss nicht jede Schlussfolgerung dieser Debatte teilen, um den Mechanismus zu erkennen: Wenn Erfolg an Lieferung statt daran gemessen wird, was bleibt, ist Abhängigkeit für alle Beteiligten ein rationales Ergebnis. Die Antwort ist nicht, externe Expertise zu vermeiden. Institutionen brauchen sie, und europäische Programme wie das Technical Support Instrument existieren gerade deshalb, weil spezialisierte Kapazität nicht immer rechtzeitig intern aufgebaut werden kann. Die Antwort ist, zu verändern, was als Erfolg zählt. Wir messen einen Auftrag daran, was die Institution ohne uns tun kann, wenn er endet. Deshalb hat unser Modell auch einen definierten Exit. Eine Task Force, die dauerhaft wird, ist an genau dem gescheitert, wofür sie existiert. ## Was „Fähigkeit bleibt“ tatsächlich bedeutet {#was-fähigkeit-bleibt-tatsächlich-bedeutet} „Fähigkeit bleibt“ ist leicht zu sagen und leicht zu behaupten. Wir versuchen, es beobachtbar zu machen. Wenn ein Auftrag abgeschlossen ist, erwarten wir, dass die Institution ohne uns Folgendes kann: - eine wesentliche Änderung an der Funktion vornehmen und erklären, warum sie so vorgenommen wurde; - ein neues Teammitglied mit eigenen Menschen und Materialien auf ein arbeitsfähiges Niveau bringen; - von einem realistischen Ausfall mit Verfahren wiederherstellen, die die eigenen Mitarbeitenden bereits geübt haben; - einen Anbietervorschlag oder eine abgeschlossene Reparatur beurteilen und zu einem vertretbaren Urteil kommen; - entscheiden, wenn sie will, eine Komponente, einen Anbieter oder uns zu ersetzen. Der letzte Punkt ist der wichtigste. Eine Institution, die ihre Berater nicht ersetzen könnte, hat keine Fähigkeit erhalten. Sie hat eine Abhängigkeit mit guter Dokumentation erhalten. Der ehrlichste Test kommt, nachdem wir gegangen sind: **die erste Änderung, die die Institution selbst vornimmt.** Wenn sie gut geht, hat der Transfer funktioniert. Wenn sie uns zurückrufen muss, hat er es nicht, egal was der Abschlussbericht sagte. ## Fähigkeit ist ebenfalls ein Single Point of Failure {#fähigkeit-ist-ebenfalls-ein-single-point-of-failure} Wir sprechen häufig technisch über Single Points of Failure: ein Rechenzentrum, eine Netzwerkroute, ein Anbieter. Fähigkeit kann auf dieselbe Weise ausfallen. Eine Funktion kann vollständig von einer Person abhängen, die weiß, wie sie wiederhergestellt wird, einem Auftragnehmer, der sie reparieren darf, oder einem Team, das sich erinnert, warum sie so konfiguriert wurde. Wenn diese Person in Rente geht, der Vertrag endet oder das Team reorganisiert wird, wird die Funktion fragil, ohne dass sich sichtbar etwas verändert. Deshalb behandeln wir den Ort von Wissen als Teil der Resilienz einer Institution, nicht nur ihrer Human Resources. Wo sitzt die Fähigkeit, diese Funktion zu betreiben, zu verändern und zu beurteilen, tatsächlich? Wie viele Menschen halten jede Ebene? Wurde sie von mehr als einer Person ausgeübt? Könnte die Institution sie wieder aufbauen, wenn sie verloren ginge? Hier trifft Fähigkeitstransfer auf unsere Arbeit zu [Resilienz](/de/topics/resilience). Ein System, das einen technischen Ausfall überlebt, aber nicht den Weggang eines einzelnen Spezialisten, ist nicht resilient. Es hat Glück. ## Ohne Fähigkeit ist Kontrolle nur formal {#ohne-fähigkeit-ist-kontrolle-nur-formal} Dieselbe Frage erscheint in unserer Arbeit zu [Souveränität](/de/topics/sovereignty). Eine Institution kann ihre Systeme besitzen, sie in der richtigen Jurisdiktion hosten und jeden nötigen Vertrag halten und trotzdem nicht handeln können, wenn sich eine Abhängigkeit ändern muss, weil das Wissen zur Änderung beim Anbieter sitzt. Formales Eigentum ohne die Fähigkeit, es auszuüben, ist eine schwache Form von Kontrolle. Jede wichtige Entscheidung läuft weiter durch das Verständnis eines anderen. Deshalb behandeln wir Fähigkeitstransfer als Teil jeder ernsthaften Anstrengung, Abhängigkeit zu verringern. Ein System zu verschieben reicht nicht, wenn die Fähigkeit, es zu betreiben und zu verändern, nicht mitzieht. ## Wie wir gemeinsam daran arbeiten {#wie-wir-gemeinsam-daran-arbeiten} Fähigkeitstransfer ist in die Arbeitsweise einer ESFI Task Force eingebaut, von der Diagnose bis zum Exit. **Diagnostizieren.** Wir beginnen mit der Funktion und fragen, wo Fähigkeit heute tatsächlich sitzt: wer sie betreiben, warten, verändern und beurteilen kann, wo Wissen konzentriert ist und was nie aufgeschrieben oder geübt wurde. **Bauen.** Lieferung findet mit institutionellen Counterparts in definierten Rollen statt. Entscheidungen werden mit ihrer Begründung festgehalten. Der externe Anteil der Arbeit soll sinken, und diese Abnahme ist sichtbar. **Übertragen.** Verfahren, Tools, Daten und Routinen bewegen sich in die Institution und werden von ihren eigenen Menschen geübt, bevor wir zurücktreten. **Fähigkeit bleibt.** Der Auftrag endet, wenn die Funktion uns nicht mehr braucht, nicht wenn ein Deliverable abgenommen wird. Wenn wir gemeinsam mit einem Partner eine Funktion betrachten, arbeiten wir typischerweise diese Fragen durch: | Frage | Was sie sichtbar macht | | --- | --- | | Wer kann diese Funktion heute betreiben, warten, verändern und beurteilen? | Wo Fähigkeit fehlt und auf welcher Ebene. | | Wie viele Menschen halten jede Ebene? | Wissenskonzentration; Single Points of Failure. | | Was ist dokumentiert, und erklärt es warum? | Ob Veränderung ohne Raten möglich ist. | | Was wurde tatsächlich von internem Personal geübt? | Der Unterschied zwischen beschriebenem und gehaltenem Wissen. | | Was würde die Institution brauchen, um ihren aktuellen Anbieter zu ersetzen? | Die tatsächliche Tiefe der Abhängigkeit. | | Wie sieht die erste unabhängige Änderung aus? | Der Test, den der Transfer bestehen muss. | ## Wo wir vorsichtig sind {#wo-wir-vorsichtig-sind} Wir halten uns an einige Verpflichtungen darüber, was wir behaupten. Wir betrachten einen Transfer nicht als abgeschlossen, weil Schulung geliefert oder Dokumente übergeben wurden. Das sind Inputs. Das Ergebnis ist, was die Institution tun kann. Wir messen Transfer nicht in Schulungsstunden, Seiten Dokumentation oder Zahl der Workshops. Wo Fähigkeit nicht gewandert ist, sagen wir das, und wir sagen auf welcher Ebene. Ein ehrlich beschriebener teilweiser Transfer ist nützlicher als ein vollständiger auf dem Papier. Wir bleiben nicht länger, als die Funktion uns braucht, und entwerfen keine Aufträge, die die Institution von uns abhängig machen. Der Wert unserer Arbeit sollte darin sichtbar sein, wie wenig die Institution uns danach braucht. * * * ## Weiterführende Literatur {#weiterführende-literatur} - [Michael Polanyi, _The Tacit Dimension_ (1966)](https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html). - [Ikujiro Nonaka und Hirotaka Takeuchi, _The Knowledge-Creating Company_ (1995)](https://academic.oup.com/book/52097). - [Mariana Mazzucato und Rosie Collington, _The Big Con_ (2023)](https://www.penguin.co.uk/books/451193/the-big-con-by-collington-mariana-mazzucato-and-rosie/9780241603987). - Europäische Kommission, [Technical Support Instrument, Verordnung (EU) 2021/240](https://eur-lex.europa.eu/eli/reg/2021/240/oj). **Verwandte Themen:** [Souveränität](/de/topics/sovereignty) · [Resilienz](/de/topics/resilience) · [Was bei Ihnen bleibt](/de/our-approach/what-stays-with-you) * * * ## Änderungen an dieser Position {#änderungen-an-dieser-position} - 24. September 2026 — Erstmals veröffentlicht. Materielle Änderungen werden hier mit Datum aufgeführt. Korrekturen an Formulierungen oder Links nicht. ## Auf dieser Seite {#auf-dieser-seite} ESFI — civilization infrastructure · https://esfi.eu