Zusammenarbeit im Entwicklungsprozess

Anordnung der Aktivitäten -- Optimierungsaufgabe (Dauer und Kosten), ohne Qualität des Prozessergebnisses zu beeinträchtigen

Optimierungsansätze:

• Um die Dauer zu verringern, werden so viele Aktivitäten wie möglich parallelisiert
• Um die Kosten zu verringern, werden so wenige Ressourcen wie möglich eingesetzt und deshalb so stark wie möglich ausgelastet

Abhängigkeiten bestimmen

• Reihenfolge
• Ausschluss (beschränkte Ressource)

Eigenschaften analysieren

• Ein/Ausgangsparameter, Dauer/Varianz, Ressourcenverbrauch/Kompetenzen, Maschinen/IT/Räumlichkeiten, Randbedingungen, Stakeholder

Iteration

• Bedingungen, Wahrscheinlichkeit, veränderte Aufwände

Anordnung vornehmen

• Liste mit Abhängikeiten von der Aktivität
• so viel wie möglich parallelisieren --> Abhängigkeitslisten gegenprüfen

Netzplan ausrechnen

1. Alle Aktivitäten in Kästchen darstellen und Dauer eintragen
2. Kästchen nach der festgelegten Anordnung aufzeichnen und mit Pfeilen verbinden
3. vom Beginn an kürzest mögliche Dauer über alle Pfade aufsummieren (frühestmögliche Ende der jeder Aktivität)
4. Maximal erlaubte Dauer festlegen (vom Ende des Prozesses rückwärts den spätestmöglichen Anfang für jede Aktivität bestimmen)
5. Puffer = Punkt 3 - Punkt 4
6. Kritischer Pfad (alle Puffer = 0) --> Änderungen hier bedeuten Verschiebung des Endtermins

• besteht aus Einzelelemente, die in Beziehung zueinander stehen
• Elemente werden im Sinne des Systems als Einheit gesehen und können von ihrer Umwelt abgegrenzt werden
• System interagiert mit der Umwelt

INCOSE (International Council on Systems Engineering):

• A system is a construct or collection of different elements that together produce results not obtainable by the elements alone

• ist ein interdisziplinärer Ansatz mit dem Ziel erfolgreich (komplexe) Systeme zu realisieren
• konzentriert sich auf:

1. Definition und Dokumentation der Systemanforderungen (frühe Phase)
2. Erarbeitung eines Systemdesigns
3. Überprüfung des Systems auf Einhaltung der Anforderungen unter Berücksichtigung des Gesamtproblems:
   • Betrieb, Zeit, Test, Erstellung, Kosten & Planung, Training & Support und Entsorgung

• Aufteilung in Systemelemente
• Betrachtung der Abhängigkeiten zwischen den Elementen
• Strukturierung durch Abstufung der Elemente

• Anforderungsanalyse, Anforderungsdefinition und Anforderungsmanagement
• Systemdesign (Modellbildung, Simulation und Bewertung)
• Funktionsdesign
• Systemintegration
• Verifikation und Validation und
• Risikomanagement

• System-Engineering-Prozess ist nicht sequentiell
• Funktionen werden parallel und iterativ ausgeführt  

Der SIMILAR-Prozess beinhaltet in der Regel die folgenden sieben Aufgaben:
 

1. Anforderungsmodell erstellen (State the Problem)
2. Alternative Lösungen prüfen (Investigate alternatives)
3. Systemdesignmodell erstellen (Model system)
4. System einbetten (Integrate)
5. System implementieren (Launch the system)
6. Technische Messwerte prüfen (Assess performance)
7. Projektergebnisse prüfen (Re-evaluate)

SysML (System Modeling Language)

für Systeme mit Diagrammtypen --> Analyse, Design, Testen

Erweiterung von UML (Unified Modeling Language)

• direkte Verbindung zw. Systemelementen --> Koordination im Prozess
• Verknüpfung durch Metamodell/Systemmodell
• Verknüpfung von Ergebnissen --> Smart Hybrid Prototyping

Risiken:

• Nichterfüllung von Meilensteinen führt zu Nacharbeiten, höheren Kosten und Zeitverlusten
• Im Worst Case wird das Projekt wegen (scheinbarer) Unwirtschaftlichkeit sogar eingestellt
• Verzögerung des Starts weiterer wichtiger abhängiger Prozesse (Unkontrollierbarkeit, Dateninkonsistenzen)

Gründe:

• Unklarheit, ob die festgelegten Ziele der Meilensteine den besten Weg zum Endresultat darstellen
• Abhängigkeiten zu anderen Aufgaben und Projekten im Unternehmen sind nicht plan- und steuerbar
• Überbelastung der Mitarbeiter durch Arbeitsanstieg vor Meilensteinen
• Rückstand durch Leistungsabfall nach Meilensteinen (Hockey Stick Effect)
• Gegenseitige Adaption von Einzellösungen bei der Meilensteinannäherung führt zu Kompromissen

Handlungsbedarf:

• Bei der Projektplanung müssen die Prozesse besser berücksichtigt und Meilensteine entsprechend abgestimmt werden --> WIE
• Bei der Prozessplanung müssen die Meilensteine eingeplant werden und Aktivitäten eingeplant werden, die sicherstellen, dass die am Meilenstein geforderten Arbeitsergebnisse auch erreicht werden --> WAS

Prozessanalyse:

• Fortschrittsanalyse durch die Erhebung prozessbezogener Kennzahlen mit einer Metrik (Key Performance Indicators)
• Abstimmung mit den Maßnahmen zur Meilensteinannäherung
• Erstellung eines Kennzahlensystems

Prozessbewertung:

• Definition und Bewertung von Prozess-Bewertungskriterien
• Bewertung hinsichtlich der Sicherheit und Robustheit der Prozesse

Fehlertoleranzerhöhung:

• Identifikation und Gewichtung von Fehlereinflussmöglichkeiten
• Vorsehung eines angemessenen Sicherheitsspielraums für unerwartete Störungen
• Synchronisation von Projektmanagern und Fachabteilungen

1. Eigenschaften aller Aktivitäten, ihre Abhängigkeiten und Übergabepunkte von Ergebnissen --> definieren
2. Netzplantechnik: Anordnung von parallelen Arbeitssträngen um Gesamtdauer zu reduzieren
3. domänenübergreifender Austausch von Arbeitsergebnissen kann durch SysML erleichtert werden --> Schnittstellen und Informationsfluss
4. Zusammenarbeit Prozess- und Projektmanagement erfoderlich --> Abhängigkeiten von Aktivitäten im Prozess und Meilensteine

1. Design Reviews: Design Idee, Herangehensweise, Projektierung/Angebot, Ausführung
2. Compatibility Reviews: Abstimmung von Konstruktion und System
3. System Reviews: Abstimmung von unterschiedlichen Subsystemen zu einem funktionierenden Gesamtsystem
4. Project Reviews: Fortschritt und Teilergebnisse eines Projekts werden einer Ampelbewertung unterzogen

• Fortschritt einer Entwicklung durch Erfahrung und Kompromissbereitschaft verschiedener Experten
• Entwicklungszeit stetig abgenommen --> Meilenstein
• Enge Abstimmung und Nachvollziehbarkeit der Ergenisse
• technisch komplexere Lösungselemente machen Produktsynthese von der Denkweise des System Engineering abhängig
• Multi-Domänen Produkt- und Systemkompatibilität --> Validierungs - Reviews
• Konflikte / Interessen verschiedener Entwicklungspartner und sich ständig ändernde Randbedingungen

1. System Abteilungen
2. physische Zonen des Produktes
3. Angelegenheiten / Probleme
4. Bewertungs- und Analysekriterien
5. Hauptkriterien (cost, risk, time)

formelle Teilnehmerhierarchie:

1. Auftraggeber (z.B.: Programm-Manager)
2. Offizieller Design Review Leiter
3. Integrations- und Leitungskoordinations-Team
4. Vertreter von funktionellen Tätigkeiten/Abteilungen
5. Systemanalytiker, Designer und Fertigungsplaner
6. Administrative Unterstützung
7. Integrations-Team führt durch das Review

• Gewöhnlich erklären alle anderen Teilnehmer nur, kommentieren und bewerten oder nehmen Anweisungen an
• Logik bei der Review-Durchführung ist abhängig von der Firmenkultur und Produktzusammensetzung
• Zeitdauer: 1 Tag bis zu einer Arbeitswoche

• Koordinator leitet das Review
• Teilnehmer handeln in erster Linie in ihrer Berufsrolle
• Vorbereitung der digitalen Modelle und Probleme notwendig
• Kerngruppe mit fundierten Technologie-Kenntnissen
• Review von den technischen (Funktionen, Eigenschaften, Leistung, Herstellung, Durchführbarkeit) über die wirtschaftlichen Eigenschaften (Kosten und Zeit) bis hin zu den „politischen“ (Eigentumsrecht, Verantwortung)
• Zeitdauer: 1 ½ bis 4 Stunden

• keine Teilnehmerhierarchie
• kein Koordinator notwendig
• kurze Zusammenfassung und geringer Vorbereitungsaufwand
• vertraut mit den digitalen Werkzeugen
• Berücksichtigung spezifischer Inhalte
• Zeitdauer: 30 Minuten bis 2 Stunden