← Alle ErklärvideosAll explainer videos
Teil 2 von 5Part 2 of 5Abgrenzung, Lösung, Prinzipien, TeamBoundary, solution, principles, team
Wo du die Systemgrenze ziehst, wie du die Lösung von der Blackbox zu Modulen entwickelst, die fünf Gestaltungsprinzipien und die Rolle von Integratoren.Where to draw the system boundary, how to develop the solution from black box to modules, the five design principles and the role of integrators.
KapitelChapters
- Teil 2 von 5
- Das Problemfeld abgrenzen
- Beispiel: Systemgrenze
- Systemdenken in der Lösung
- Beispiel: Blackbox und Module
- Fünf Gestaltungsprinzipien
- Beispiel: Fünf Prinzipien
- Teamarbeit und Projektmanagement
- Beispiel: Teilprojekte und Integratoren
- Zusammenfassung Teil 2
- Part 2 of 5
- Defining the problem field
- Example: The system boundary
- Systems thinking in the solution
- Example: Black box and modules
- Five design principles
- Example: Five principles
- Teamwork and project management
- Example: Sub-projects and integrators
- Summary of part 2
EselsbrückenMnemonics
SelbsttestSelf-test German
Welches Dilemma entsteht bei der Abgrenzung des Problemfeldes?
Je weiter die Abgrenzung, desto grösser der Aufwand; je enger, desto weniger Lösungs- und Eingriffsmöglichkeiten werden entdeckt.
Was versteht man unter Architecting?
Das Modellieren des Lösungssystems auf tieferen Stufen: Baugruppen und Module, die Schnittstellen dazwischen und die Zuordnung der Funktionen zu den Elementen.
Nenne die fünf Gestaltungsprinzipien.
Idealität, Unabhängigkeit, modularer Aufbau, Piecemeal Engineering, minimale Präjudizierung.
Was bedeuten loose coupling und strong cohesion?
Wenige, einfache Schnittstellen nach aussen (lose Kopplung) und starke Beziehungen nach innen (hoher Zusammenhalt).
Welche Aufgabe haben Integratoren?
Sie kümmern sich um das Zusammenspiel der Baugruppen und um übergreifende Systemaspekte, zum Beispiel Logistik oder IT-Systeme.
TranskriptTranscript
Transkript anzeigenShow transcript
Teil 2 von 5
Willkommen zu Teil zwei! Zuletzt ging es um Elemente und Beziehungen, um Problemfeld und Lösungssystem und um vernetztes Denken. Jetzt wird es handfest: Wo ziehst du die Grenze? Wie entwickelst du die Lösung? Welche fünf Prinzipien machen sie gut? Und wie arbeitet das Team? Und ShopNova? Ist natürlich wieder dabei.
Das Problemfeld abgrenzen
Stell dir ein Qualitätsproblem vor. Du könntest dich auf den eigenen Betrieb beschränken und die Reklamationen ungeprüft als Tatsache übernehmen. Du könntest aber auch erst beim Kunden oder bei den Lieferanten nachschauen. Vielleicht bringt dort ein einfacher Hinweis mehr als teure Massnahmen im eigenen Betrieb. Und da steckt das Dilemma: Je weiter du das System abgrenzt, desto grösser der Aufwand für Analyse und Lösungssuche. Je enger du abgrenzt, desto weniger Lösungs- und Eingriffsmöglichkeiten entdeckst du. Aber: Ein weiter Blick aufs Problemfeld heisst nicht, dass die Lösung riesig sein muss! Wer erkennt, dass er nicht alles im Griff hat, wählt oft kleine Schritte. Die richtige Grenze findest du mit Intuition, Erfahrung und kritischem Abwägen.
Beispiel: Systemgrenze
Kennst du den Mann mit dem Schlüssel? Nachts sucht er seinen Schlüssel, aber nur unter der Strassenlaterne. Warum? Weil es dort hell ist! Die Grenze seiner Suche bestimmt, was er finden kann. Bei ShopNova wäre die enge Abgrenzung: nur das Support-Team. Günstig zu untersuchen, aber du findest nur Team-Ursachen. Die weite Abgrenzung nimmt Produktseiten, Lieferanten-Daten und Kunden mit hinein. Das kostet mehr, aber vielleicht fällt dort etwas auf. Und siehe da: Auf den Produktseiten fehlen Grössenangaben! Ein simpler Hebel, ausserhalb des Teams. Prüf deine Grenze mit einer Frage: Wo habe ich noch nicht hingeschaut? Nicht nur unter der Laterne suchen. Weit schauen, klein handeln.
Systemdenken in der Lösung
Auch bei der Lösung denkst du hierarchisch. Erst betrachtest du die Lösung und ihre Bausteine als Blackboxes und legst nur fest: Welche Funktionen? Welche Inputs, welche Outputs? Dann öffnest du die Box, Stufe für Stufe: Baugruppen, Module, die Schnittstellen dazwischen und die Zuordnung der Funktionen zu den Elementen. Das nennt man Architecting. So wird die Lösung Schritt für Schritt konkreter, genau wie vorher das Problemfeld.
Beispiel: Blackbox und Module
Kaffee gefällig? Für dich ist eine Kaffeemaschine eine Blackbox: Bohnen und Wasser rein, Kaffee raus. Wie sie innen arbeitet, ist dir egal. Bis du sie bauen musst. Dann öffnest du die Box: Mühle, Pumpe, Boiler und die Schnittstellen dazwischen. Der ShopNova-Chatbot als Blackbox: Eingang ist die Kundenfrage, Ausgang eine passende Antwort. Öffnest du die Box, entstehen Module: Frage verstehen, Antwort in der Wissensdatenbank finden und bei Unsicherheit an einen Menschen übergeben. Und die Schnittstellen müssen sitzen: Was wird übergeben, und in welchem Format? Merk dir: Erst was, dann wie. Erst die Funktion, dann die Form.
Fünf Gestaltungsprinzipien
Für die Lösung empfiehlt das Buch fünf generelle Gestaltungsprinzipien. Hier sind sie! Erstens: Idealität. Das Verhältnis nützlicher zu unerwünschten Funktionen soll möglichst gross sein, die Komplexität möglichst klein. Beispiele: der Dreh-Drück-Steller von B M W, der viele Komfortfunktionen bündelt, oder das Head-up-Display, das die vorhandene Frontscheibe nutzt. Zweitens: Unabhängigkeit. Jede Funktion bekommt ihren eigenen Design-Parameter, damit eine Änderung andere Funktionen nicht stört. Etwa getrennte Software-Module. Drittens: Modularer Aufbau. Untersysteme mit klar definierten, wiederverwendbaren Funktionen, wenige einfache Schnittstellen nach aussen, loose coupling, und starke Beziehungen nach innen, strong cohesion. Viertens: Piecemeal Engineering, nach Popper. Problemfeld und Konzept darfst du gross denken. Umsetzen aber in kleinen Schritten, die du zurücknehmen kannst. Fünftens: minimale Präjudizierung. Im Zweifel gewinnt die Lösung, die die meisten Freiräume offenlässt und robust auf neue Randbedingungen reagiert. Und zum Schluss, der Realitätscheck: Bette die Lösung immer wieder ins Problemfeld ein. Stimmen die Schnittstellen? Bewirkt sie die gewünschte Veränderung? Und gibt es Nebenwirkungen, an die niemand gedacht hat?
Beispiel: Fünf Prinzipien
Jetzt die fünf Prinzipien im Praxistest! Stell dir Lego vor. Jeder Stein hat eine klare Funktion, passt über genormte Noppen an andere Steine und lässt sich jederzeit ersetzen. Modularer Aufbau in Reinkultur. Idealität bei ShopNova: ein einziges Eingabefeld statt fünf Formulare. Unabhängigkeit: Die Antwortlogik ist von der Oberfläche getrennt. Ein neues Design ändert keine Antworten. Modular: Dasselbe Chatbot-Modul läuft auf Website und App. Piecemeal: Zuerst nur Fragen zu Retouren, dann der Rest. Und jeder Schritt lässt sich zurücknehmen. Minimale Präjudizierung: Das Sprachmodell bleibt austauschbar, damit niemand an einen Anbieter gefesselt ist. Die Reihenfolge merkst du dir so: Immer Unabhängig, Modular, Portionsweise, Minimal festlegen. I, U, M, P, M. Klingt fast wie ein Zauberspruch.
Teamarbeit und Projektmanagement
Bei Problemen ohne Routine brauchst du ein Team, denn Situationskenntnis, Fachwissen und Kreativität müssen zusammenkommen. Erarbeitet das Team die Problemstruktur gemeinsam nach dem SE-Modell, entsteht ein besseres gemeinsames Problemverständnis. Und Bubble-Charts am Flipchart? Perfekte Landkarten dafür. Wächst das Vorhaben, wird die Aufgabenverteilung wichtiger. Der Projektstrukturplan greift wieder auf den Systemansatz zurück: Unterprojektleiter für die Baugruppen, und zusätzlich Integratoren! Sie kümmern sich um das Zusammenspiel der Baugruppen und um übergreifende Systemaspekte wie Logistik oder I T-Systeme.
Beispiel: Teilprojekte und Integratoren
Schau dir mal eine Baustelle an. Jedes Gewerk hat seinen Vorarbeiter: Elektro, Sanitär, Maurer. Und dann gibt es jemanden, der aufpasst, dass Rohre und Kabel nicht dieselbe Wand brauchen. Das ist der Integrator! Bei ShopNova gibt es Teilprojekte: Chatbot, Wissensdatenbank und die Schulung des Teams. Jedes hat eine Unterprojektleiterin oder einen Unterprojektleiter. Und der Integrator achtet aufs Zusammenspiel: Passen die Bot-Antworten zum Retourenprozess und zum Ticketsystem? Merk dir: Gewerke bauen. Integratoren verbinden.
Zusammenfassung Teil 2
Zum Schluss von Teil zwei, die wichtigsten Punkte. Die Systemgrenze ist ein Abwägen zwischen Aufwand und Hebeln, und die Lösung darf klein bleiben. Du entwickelst die Lösung von der Blackbox über Module bis zu den Details und misst sie an fünf Prinzipien. Im Projekt bauen Unterprojektleiter die Bausteine, Integratoren sichern das Ganze. Deine Eselsbrücken: Nicht nur unter der Laterne suchen. Erst was, dann wie. Immer unabhängig, modular, portionsweise, minimal festlegen. Gewerke bauen, Integratoren verbinden. Weiter geht es in Teil drei, mit dem Vorgehensmodell!
Part 2 of 5
Welcome to part two. In part one we covered elements and relations, problem field and solution system, and networked thinking. Now come the boundary of the problem field, systems thinking in the solution, the five design principles and teamwork. Our companion stays ShopNova.
Defining the problem field
Picture a quality problem. You could limit yourself to your own operation and accept the complaints as fact, unchecked. But you could also look at the customer or the suppliers first. Maybe a simple hint there achieves more than expensive measures in your own operation. And that's the dilemma: the wider you draw the system boundary, the greater the effort for analysis and the search for solutions. The narrower you draw it, the fewer solution and intervention options you discover. But a wide view of the problem field doesn't mean the solution has to be huge! Anyone who realises they don't have everything under control often chooses small steps. You find the right boundary with intuition, experience and critical weighing.
Example: The system boundary
An analogy. A man looks for his keys at night, but only under the streetlight, because it's bright there. The boundary of his search decides what he can find. At ShopNova the narrow boundary would be: just the support team. Cheap to examine, but you only find team causes. The wide boundary includes product pages, supplier data and the customers. That costs more, but maybe something stands out there. For example, the product pages lack size information. A simple lever outside the team. Test your boundary with one question: where haven't I looked yet? Don't search only under the streetlight. Look wide, act small.
Systems thinking in the solution
In the solution you think hierarchically too. First you treat the solution and its building blocks as black boxes and only define: which functions? Which inputs, which outputs? Then you open the box, level by level: assemblies, modules, the interfaces between them, and the assignment of functions to elements. That's called architecting. So the solution becomes more concrete step by step, just like the problem field before.
Example: Black box and modules
An analogy. To you, a coffee machine is a black box: beans and water go in, coffee comes out. How it works inside only matters when you build it. Then you open the box: grinder, pump, boiler and the interfaces between them. The ShopNova chatbot as a black box: the input is the customer question, the output a fitting answer. Open the box and modules appear: understand the question, find the answer in the knowledge base, and hand over to a human when unsure. The interfaces must be clear: what gets passed on, and in which format? Remember: function first, then form. First what, then how.
Five design principles
For the solution, the book recommends five general design principles. Here they are! One: ideality. The ratio of useful to undesired functions should be as large as possible, complexity as small as possible. Examples: B M W's rotary push controller that bundles many comfort functions, or the head-up display that uses the existing windshield. Two: independence. Every function gets its own design parameter, so that a change doesn't disturb other functions. For example, separate software modules. Three: modular structure. Subsystems with clearly defined, reusable functions, few simple interfaces to the outside, loose coupling, and strong relations inside, strong cohesion. Four: piecemeal engineering, after Popper. You may think big about the problem field and the concept. But implement in small steps that you can take back. Five: minimal prejudgement. When in doubt, the solution wins that leaves the most freedom open and reacts robustly to new conditions. And finally, the reality check: embed the solution in the problem field again and again. Do the interfaces fit? Does it bring about the desired change? And are there side effects nobody thought of?
Example: Five principles
Now the five principles, applied. Picture Lego. Every brick has one clear function, clicks onto other bricks via standardised studs, and can be replaced at any time. That is modular design. Ideality at ShopNova: one single input field instead of five forms. Independence: the answer logic is separate from the interface, so a redesign doesn't change the answers. Modular: the same chatbot module runs on website and app. Piecemeal: first only questions about returns, then the rest, and every step can be taken back. Minimal prejudgement: the provider's language model stays replaceable, so you're not locked in to one vendor. Here's how to remember the order: Imagine Independent Modules, Proceed Modestly. The first letters are I, I, M, P, M.
Teamwork and project management
For problems without routine you need a team, because knowledge of the situation, expertise and creativity have to come together. If the team develops the problem structure together following the S E model, a better shared understanding of the problem emerges. And bubble charts on a flipchart? Perfect maps for that. As the undertaking grows, dividing the tasks becomes more important. The work breakdown structure falls back on the systems approach again: sub-project leads for the assemblies, and in addition, integrators! They look after the interplay of the assemblies and cross-cutting system aspects such as logistics or I T systems.
Example: Sub-projects and integrators
An analogy. On a building site every trade has its foreman: electrics, plumbing, masons. On top of that, somebody makes sure pipes and cables don't need the same wall. That's the integrator. At ShopNova there are sub-projects: chatbot, knowledge base and training the team. Each has its own sub-project lead. The integrator watches the interplay: do the bot's answers fit the returns process and the ticket system? Remember: trades build, integrators connect.
Summary of part 2
To wrap up part two, the key points. Drawing the system boundary is a trade-off between effort and levers, and the solution may stay small. You develop the solution from the black box to modules and details, and measure it against five principles. In the project, sub-project leads build the pieces, integrators secure the whole. Your mnemonics: don't search only under the streetlight. First what, then how. Imagine Independent Modules, Proceed Modestly. Trades build, integrators connect. On to part three.
Eigene Zusammenfassung mit eigenen Beispielen, Analogien und Eselsbrücken; das Beispiel «ShopNova» ist erfunden. Quelle: Haberfellner, de Weck, Fricke, Vössner: Systems Engineering – Grundlagen und Anwendung, 14. Aufl. (2018), Kapitel 3. Kein Ersatz für das Buch. Die Sprecherstimme ist KI-generiert (ElevenLabs); die Videos gibt es auf Deutsch und Englisch.
Own summary with own examples, analogies and mnemonics; the “ShopNova” case is fictional. Source: Haberfellner, de Weck, Fricke, Vössner: Systems Engineering – Grundlagen und Anwendung, 14th ed. (2018), chapter 3. Not a substitute for the book. The narrator voice is AI-generated (ElevenLabs); the videos are available in German and English.