Systemintegration - en unik kompetens

Vägledning till läsaren

Denna berättelse ger en överblick över de frågor som man måste förstå för att bli kunna driva ett komplext systemutvecklingsarbete, som innefattar utveckling av avancerade produkter. Att få stora komplexa system att fungera på avsett sätt kräver att man vet hur man driver ett utvecklingsarbete och hur man skall integrera alla system.

För att kunna hålla tidplaner i utvecklingsarbetet erfordrar detta att man kan styra många olika utvecklingsteam.

Man måste kunna testa varje system för sig så att det har de funktioner och egenskaper som finns specificerat. När man sedan testar flera system tillsammans så finns många beroenden som kan påverka varje enskilt system.

Därför måste integrationsarbetet drivas på sådant sätt att man på ett strukturerat sätt har en mycket god kontroll på hur hela funktionen med alla system i samverkar i ett delsystem. Den tekniska mognaden av ett system växer fram successivt genom iterativ utveckling.

Detta innebär att ett helt delsystem också kommer att ha en teknisk mognadsutveckling varefter man kommer vidare i utvecklingsarbetet. Av detta skäl är det av högsta vikt att man kan styra utvecklingsarbetet på ett sådant sätt att alla utvecklingsteam ligger i fas i den tekniska mognaden av sitt system och att man håller tidplanen.

I det exemplet som beskrivs i slutet av detta kapitel visas på behovet att alla utvecklingsteam arbetar i en synkad takt.

Bakgrund

Integrationsförmåga inom Saab har byggts sedan det första militära stridsflygplanet togs fram efter andra världskriget. Det som har förändrats sedan dess är att komplexiteten har vuxit dramatiskt.

Rekommendation

Författaren rekommenderar nedanstående texter som har koppling till denna berättelse: Under Kundvärde, läs gärna Utveckling av Teknikdemonstratorer, under Livscykelkostnad, läs gärna Systems Engineering och under  Utvecklingskompetens, läs gärna Utveckling av världens bästa styrsystem.

Texten berör markerade områden inom förändringsresan i flygindustrin

Sammanfattning

Vad är integrationsförmåga? Denna fråga kommer att få flera svar. Dock kan man konstatera att svaren har samband med varandra.

För att integrationsförmåga skall ”vara värt något” krävs att denna förmåga kommuniceras och förstås av de som utvecklar en produkt. Kommunikation mellan alla som är involverade i en produktutveckling är därför centralt. Man måste kommunicera vilka arkitekturer och designbeslut som är tagna, vilka gränssnitt som är definierade.

Särskilt viktigt är det att gränssnitt är kommunicerade. Det gäller alla typer av gränssnitt mekaniska, elektriska, systemtekniska, frekvenser, signaler, protokoll etc. Vilka typer av tester, systemtester, mekaniska tester behövs etc. Ett väl fungerande integrationsarbete är en delmängd av hela utvecklingsprocessen för ett system eller produkt.

I Saabs verksamhetsledningssystem finns ett antal processer som beskriver hur man skall säkerställa och godkänna den design man utvecklar och levererar. Integrationsarbete är en del i ett värdeflöde för att utveckla en produkt eller ett system. För att få en överskådlig bild av detta så måste man se vilka planer som styr utvecklingsarbetet och därmed integrationsarbetet.

När teknikområdet Airframe (strukturutveckling) 2008 startade sitt arbete med att utveckla Gripen E fanns inte tillräckligt många erfarna ingenjörer att tillgå. Det innebar att man under några år både fick utveckla både smarta arbetssätt och att man fick bygga upp erforderlig kompetens.

Detta genomfördes genom en mycket väl strukturerad förmågeutveckling. I detta arbete drev man systematiskt förmågeutveckling inom alla teknikområden inom Airframe. Efter några år kunde man både se och mäta att den totala förmågan i hela Airframe hade ökat dramatiskt!

Beskrivning av innehåll

  • Systemintegration i utvecklingsarbetet beskrivs kortfattat med olika aspekter på integrationsförmåga och vad som krävs för att man skall kunna lyckas med systemintegration i stora system och produktutvecklingsprojekt.
  • Integrationsarbete i utvecklingsprocessen sammanfattas och beskrivs med principer och övergripande arbetssätt för integration vid system- och produktutveckling.
  • Effektiv utveckling inom teknikområde Airframe belyser hur en förändringsresa kan se ut när det handlar om ett arbete där integration av olika typer av system är i fokus. Arbetet avser förbättring av process, metod och arbetssätt för "Airframe-delen" av produkten Gripen E.

Systemintegration i utvecklingsarbetet

I detta kapitel beskrivs kortfattat olika aspekter på integrationsförmåga och vad som krävs för att man skall kunna lyckas med systemintegration i stora system och produktutvecklingsprojekt.

Vad är integrationsförmåga? Denna fråga kommer att få flera svar. Dock kan man konstatera att dessa svar har samband med varandra. Man måste då kunna besvara nedanstående frågor:

  1. Har vi en korrekt kravbild så att kunden får efterfrågad operativ nytta?
  2. Går det att ta fram en lösning inom definierad tid och inom ekonomiska ramar som svarar mot den operativa nyttan?
  3. Går systemet att vidareutveckla?
  4. Har vi en underhållsösning som kan som klarar kraven på operativ förmåga?
  5. Har vi gjort bedömningar från ett helhetsperspektiv och tagit hänsyn till livscykelkostnaderna för systemet?

Kan svaret på ovanstående frågor vara, att integrationsförmåga är kompetens för att få komplicerade system att fungera tillsammans?

För att reda ut allt detta måste vi först definiera integrationsförmåga. Integrationsförmåga är en kompetens som består av flera delar:

  1. Integrationsförmåga är att förstå vad som är bra systemlösningar för produktens egenskaper. Detta innebär att förstå helheter, alltså en förmåga att förstå och omvandla kundens operativa krav till en effektiv produkt. Till detta erfordras en konceptuell förståelse och kunskaper kring operationsanalys.
  2. Integrationsförmåga är att omsätta en helhetsförmåga till en teknisk lösning. Till detta erfordras arkitektur- och designkunskaper som skall skapa en produkt som med fördel bör vara modulär och flexibel till sin utformning. Därigenom kan produkten utvecklas på ett flexibelt sätt och olika delar bytas, allt efter som att teknik utvecklats eller att behov av något annat slag gör detta lämpligt.
  3. Integrationsförmåga är att utveckla och producera produkten. Till detta krävs erfarenheter och kunskaper om "Systems Engineering". Detta innebär att man förstår hur man skall lösa ingenjörsmässiga problem, så att man kan få många system att fungera tillsammans. Man måste då ha erforderlig kunskap för att lösa komplexa och sammansatta problem.

Förenklat kan man då säga att integrationsförmåga är en förmåga att se helheter och en förmåga att skapa helheten av olika delar.

Integrationsförmåga kräver kommunikation

För att integrationsförmåga skall vara värt något krävs att denna förmåga kommuniceras och förstås av de som utvecklar en produkt. Kommunikation mellan alla som är involverade i en produktutveckling är därför centralt. Man måste kommunicera vilka arkitekturer och designbeslut som är tagna, vilka gränssnitt som är definierade. Särskilt viktigt är det att gränssnitt är kommunicerade. Det gäller alla typer av gränssnitt, mekaniska, elektriska, systemtekniska, frekvenser, signaler, protokoll etc. Vilka typer av tester behövs, systemtester, mekaniska tester etc.?

För att få en balanserad design krävs att systemkraven har väldefinierade och accepterade mål. Det krävs att man har entydiga ”designbudgetar” och fastställda gränssnitt för ”Overall Design”. Designbudgetar krävs för tillgänglighet, systemsäkerhet, operativ förmåga, vikt/storlek och kraft/kyla.

Då en komplicerad produkt som Gripen omfattar väldigt många komponenter, delsystem, system och apparater som skall fungera tillsammans krävs både en gedigen utbildning och lång erfarenhet för att kunna leda integrationsarbetet.

För att kunna ta ansvar för en produkt krävs det att man förstår hur en produkt är uppbyggd i alla dess nivåer.

Integrationsförmåga kräver en lång kunskapsuppbyggnad

Integrationsförmåga byggs över lång tid genom att erfarna ingenjörer utvecklar en helhetsförmåga, som sedan överförs till många personer som är ansvariga på olika nivåer sett ur en produktarkitektur. För Gripen finns en materielgruppstruktur som entydigt definierar helhet av de olika delarna och hur de skall fungera tillsammans. För att upprätthålla integrationsförmåga krävs ett relativt begränsat antal personer som kan arbeta tillsammans under lång tid.

Det som karakteriserar den svenska filosofin på att utveckla produkter är att med små medel och små resurser hitta innovativa lösningar som ger effektiva resultat. Detta kräver att erfarenheter inom de olika teknikområdena och teknikdisciplinerna förs vidare över tid för att man skall kunna behålla denna förmåga. Om det tar för lång tid mellan tillfällena då nyutveckling sker av produkter kan man tappa denna förmåga.

Hur behåller man integrationsförmågan över tid

En av anledningarna till att Saab har satsat på teknikdemonstratorer är för att upprätthålla kompetensen inom alla teknikområden och inte minst för att behålla den unika integrationsförmågan. Genomförande av teknikdemonstratorer ger möjlighet att träna och testa nya personer på att lösa avancerade tekniska utmaningar, i syfte att kunna upprätthålla och utveckla teknisk kompetens och integrationsförmåga. Ett utmärkt exempel på detta är den Avionik-demo som gjordes inom ramen för teknikdemonstratorn Gripen Demo. Här utvecklades en ny arkitektur som kommer att kunna vara ”modern” och utvecklingsbar under flera decennier.

De som var inblandade i detta projekt hade kunskap om hela produkten Gripen och dess användning, samt idéer och kunskap om möjliga framtida nya produkter.

Integrationsförmåga kräver att alla teknikområden har en bred teknisk kunskap, förstår hur man löser problem och använder teknik. Därför är det nödvändigt att teknikdisciplinen integrationsförmåga har en sådan status och har ett sådant mandat att man kan styra och driva långsiktig kompetensutveckling inom teknikdisciplinen. Man behöver därför ha tillräckliga resurser för att kontinuerligt över tid kunna ge erforderligt metodstöd till alla teknikområden och till alla produktutvecklingsprojekt.

Varje produktprojekt och varje produktägare skall naturligtvis ansvara fullt ut för sin produkt men för att själva integrationsförmågan och kompetensen kring denna skall kunna behållas över tid måste en ledning för det långsiktiga arbetet med integrationsförmåga ha erforderligt mandat och kraft.

Integration kräver successiv utveckling

Integration innebär att man arbetar med en successiv utveckling. Man har då en iterativ samverkan med kunder när man testar olika varianter av lösningar på de operativa behoven. Detta arbete kan ofta ske med ett modellbaserat arbetssätt. Nästa steg är konceptarbete, förprojekt, utveckling etc.

Man kan också i vissa fall starta arbetet med ett ”rundabordssamtal och en skrivbordssimulering”. Naturligast är att man använder någon form av simulatoranläggning för att beskriva och testa olika scenarier som skall ge en operativ förmåga för en kund.

Konceptarbete är ett riskminimeringsarbete. Konceptarbete består av tre delsteg, Behovsanalys (Needs Analysis), Konceptutredning (Concept Exploration) och Konceptdefinition (Concept Definition).

Livscykelstegen är rekursiva, d.v.s. de beskriver ett arbetssätt som återkommer flera gånger under ett utvecklingsprojekt. De rekursiva flödena ses vanligtvis som en hierarkisk nedbrytning av system till delsystemnivåer, koncept skapas för varje nod i varje ben av nedbrytningen.

De rekursiva flödena kan även vara dynamiska, där konceptens mognad successivt utvecklas tills de nått en mognad som passar för en produktdefinition. Mognaden kan ske genom funktionell tillväxt. Respektive funktion sätts sedan successivt samman till system och till samverkande system. När konceptet har ”mognat” övergår man till en systemutveckling som följer samma principer, men har en högre teknisk mognad och som kommer att skapa produkten.

Koncept är grundläggande för integrationsarbetet

Arbetet med utveckling av koncept är grundläggande för integrationsarbetet. De operativa förutsättningarna som föreslås via behovsinventering, scenariobeskrivningar och taktisk/tekniska uppdragsbeskrivningar, Concept of Operations (CONOPS) sammanställs i en Operative Concept Description (OCD). OCD:n som innehåller scenarier och produktkoncept måste utvecklas i symbios med utvecklingen av designlösningen.

Analys och fastställande av det taktisk/tekniska samspelet förutsätter ett arbetssätt som är iterativt. Därefter fokuserar man på ”bryta ner och fördela” egenskaper, krav och designbudgeter inom olika system. Därefter sker en mognadsutveckling allt efter som system utvecklas och verifieras. Resultaten följs därefter upp avseende tid, risk, kostnad och tekniskt innehåll. Man genomför därefter kontinuerligt tester, granskningar och demonstrationer i det fortsatta utvecklingsarbetet.

Principiellt kan kravvalidering ske då resultatet från ett utvecklingssteg stäms av mot ett CONOPS. Beroende på resultatet från dessa prov, rättas resultatet eller fortsätter utvecklingsarbetet vidare, en iterativ utveckling. Ofta har man någon form av projektvärderingsgrupp som beslutar om ”mognaden på resultaten är den rätta” i förhållande till projektets integrationsplan.

Integrationsarbete kräver teknikprojekt som går i takt

Man kan säga att integrationsarbete kräver att man kan hålla ihop många olika teknikprojekt som skall gå i takt och resultaten från dessa projekt skall fungera i en helhet.

För att få en integrationsförmåga måste man bygga upp metoder och arbetssätt som beskriver tillvägagångssätt att bygga ett system, man måste utbilda, leda och stödja det tekniska arbetet. Man måste kunna simulera möjliga val innan man sätter igång ett utvecklingsarbete. Vid utvecklingsarbete har man omfattande tester och granskningar för att verifiera mognad i funktioner och system. Kontinuerliga avstämningar med kund erfordras från början till dess att produkten är godkänd. Vid varje test och granskning måste man verifiera att man kan möta definierade krav.

Integration kräver styrning där integrationsledningen finns med. Det är viktigt att testa den konceptuella modellen ett antal gånger under ett projekts utvecklingstid för att prova om systemen motsvarar den ursprungliga kravspecifikationen, OCD:n.

Arbete med integration kräver en stor erfarenhet och bred kompetens. Nedanstående punkter är särskilt viktiga för att få ett effektivt integrationsarbete.

  1. Att ledarskapet vilar på en värdegrund där man ser till att ha resurser i balans.
  2. Att ha rätt kunskap, respekt för kunnande och nyfikenhet lära nytt.
  3. Att det finns ett bra nätverk där kommunikation karakteriseras av prestigelöshet och där man vågar visa sin okunskap.
  4. Att man vågar välja bort och vågar ändra ordningsföljd.
  5. Att alla arbetar i takt och enligt definierade metoder och processer.
  6. Att man har ett särskilt fokus på frågor kring luftvärdighet, verifiering och validering och på att skapa en väl strukturerad dokumentation.

Integrationsarbete i utvecklingsprocessen

I detta kapitel sammanfattas principer och övergripande arbetssätt för integration vid system- och produktutveckling.

I Saabs verksamhetsledningssystem finns ett antal processer som beskriver hur man skall säkerställa och godkänna den design man utvecklar och levererar.

I figuren visas den del av Saabs verksamhetsledningssystem som berör teknisk utveckling.

Utvecklingsarbetet kräver ett antal iterationer för att testa och validera en design. För att leda och planera detta iterativa utvecklingsarbete kräver att man har en tydlig och väl fungerande integrationsledning på flera nivåer i ett produktutvecklingsprojekt. Man måste i tidiga faser av systemutvecklingsarbetet säkra förutsättningar för det fortsatta utvecklingsarbetet.

Utvecklingsarbetet sker som ett iterativt arbete och man gör stegvis utveckling och har täta integrationer av system. Man gör också många tester och validerar system och funktioner.

Rationell integrationsförmåga kräver korta ledtider

Vid utveckling av stora system finns en stor komplexitet. Man har många gränssnitt att ta hänsyn till och systemen kan ha olika beteende beroende på hur man har utvecklat dem. Då är det viktigt att man gjort en sund nedbrytning/uppdelning av systemet. Mycket ofta sker förändringar vid stora systemutvecklingsprojekt, som gör att system kan ändra karaktär när dessa integreras med andra system.

För att öka kvalitet och teknisk mognad i systemet och dessutom spara tid, är det lämpligt att utveckla systemet iterativt. Efter att ha utvecklat ett tillräckligt bra resultat bör man testa hela systemet, rätta eventuella avvikelser och fel och göra om detta förfarande i 3-4 försök.

Detta arbetssätt ger i de flesta fall ett resultat som är så komplett som det rimligen kan göras på en minimal tid.

Normalt växer mognaden på ett system som den vänstra figuren visar. Med ovan beskrivna arbetssätt kan man få tillväxt och mognad av systemet på en mycket kortare tid, som den högra figuren visar.

Integrationsförmåga - skapa helhet och balansera designen

För att erhålla en god integrationsförmåga krävs ett tydligt konceptarbete så att man kan sätta förutsättningar tidigt.

Man måste då ha gjort en tidig validering av såväl krav som design. Det gäller att kunna hålla samman en helhet och balansera designen. Det är också nödvändighet att säkra en gemensam och sammanhållen design för att kunna få en helhetsförmåga i systemet, genom väl fungerande integration av alla berörda delsystem. Integration förutsätter att man har kontroll över ekonomiska budgetar för att få kostnadseffektiva lösningar. Man behöver också hålla kontroll över de tekniska budgetarna som definierar hur mycket vikt, elförbrukning, minneskapacitet, kyla m.m. man har till sitt förfogande för att hela systemet skall fungera tillsammans.

Grundläggande förmågor som ett gediget kunnande kring "Systems Engineering" är nödvändiga att ha. För att arbetet skall fungera smidigt krävs att de ledare som drivar arbetet är väl förtrogna med systemutveckling i allmänhet och modellbaserad systemutveckling, inklusive test och verifiering i synnerhet, för att integration skall fungera på alla nivåer.

Roller i integrationsarbetet

De ledningsroller som finns i ett systemutvecklingsprojekt kan indelas i tre grupper:

  1. Projektledare som leder projektet är ytterst ansvarig för tid, teknik och ekonomi.
  2. Designledning som leder det tekniska konstruktionsarbetet ansvarar för kravuppfyllnad och deklaration av produkten.
  3. Integrationsledning som leder och planerar integrationsarbetet och tar fram integrationsplaner på övergripande nivå.

För att kunna driva integrationsarbetet på ett praktiskt plan, upprättas olika åtagande mot berörda materielgrupper och utvecklingsteam. Där definierar man de beroenden som förekommer mellan olika system och funktioner.

I figuren visas principiellt hur man hanterar integrationsfrågor.

I den strategiska utvecklingsplanen för ett systemutvecklingsprojekt beskrivs på övergripande nivå vilka integrationer som finns till flygplanet. De kan sammanfattas som:

  • Aeronautical & Systems Integration - Vapensystem.
  • Systems Integration - System, apparater, aerodata, tekniska stödsystem till flygplan.
  • Installation kit design - Installationsbeskrivningar.
  • Underhållsrealisering - Vapen, publikationer "Ground Systems Equipment".
  • Test, Verification & Validation - Kontroll för att säkra mognad i teknik, kvalitet, funktion och flygsäkerhet.

För att kunna följa utvecklingsarbetet i detalj så är alla aktiviteter indelade i "milstolpar" av olika typer och för olika områden. Detta gör att man kan följa progressen för varje definierad aktivitet i en projektplan och har därigenom god kontroll på styrning och ledning av projektet.

Principer inom systemutveckling

Man kan principiellt beskriva systemutvecklingsarbetet i olika faser och aktiviteter.

En central del i arbetet med systemintegration är att planera för vilka konfigurationer som skall finnas med i en viss leverans av den edition som utgör slutresultatet av utvecklingsprojektet och som levereras till kunden.

För att göra detta skapas en enad bild av innehållet i editionen mellan projekt, programledare, provverksamhet och chefsingenjörer.

Den gemensamma bilden avser innehåll, viktiga tidpunkter och arbetssätt. Uppföljning sker senare så att berörda intressenter får en uppfattning av läget på editionen och kan säkerställa att alla berörda är införstådda med innehåll och påverkan på olika system.

Arbetssättet för det övergripande systemarbetet kan mycket förenklat beskrivas i figuren ovan

När sedan utvecklingsarbetet har gett ett resultat fastställs (fryses) innehållet i editionen. Efter ytterligare arbeten med utveckling och integrationsarbete tas beslut om en första flygning. Man skall därefter avsluta arbetet med att ha kontrollerat att alla godkända ändringar är genomförda och att man kan besluta att arbetet med konfigurationen är klar.

Utvecklingsplanering och integrationsarbete

Integrationsarbete är en del i ett värdeflöde för att utveckla en produkt eller ett system. För att få en överskådlig bild av detta, så måste man se vilka planer som styr utvecklingsarbetet och därmed integrationsarbetet. Övergripande finns alltid en plan på högsta nivån för utvecklingsarbetet. Denna utvecklingsplan används för att sätta ramverket för organisationen samt åtagande mot kontrakten. En sådan plan uppdateras ofta kvartalsvis eller vid behov.

För att hålla fokus på närliggande och kommande aktiviteter har man ett planeringsfönster på 6 veckor i en rullande planering. Planeringen innefattar övergripande planering, granskningsmöten, riskworkshop etc.

För varje åtagande har man en utvecklingsstrategi som beskrivs på högsta nivån i projektet. Där är aktiviteter och olika typer av viktiga milstolpar definierade. Dessutom definieras vilka produkter och konfigurationer som påverkas av leveransen. Denna avstämning görs på materielsystemnivå.

Materielsystemplanerna innehåller de olika utvecklingsstegen för produkten som svarar mot de åtagande och kundbeställningar som ingår i planen. Planen är definierad på en helhetsnivå, som är materielsystemnivån, där finns de produkter som ingår i åtagandet definierade.

En materielsystemplan innehåller två ”delar”. Den ena är de utvecklingssteg som finns på en övergripande nivå för hela materielsystemet. Den andra delen är de produkter som ingår materielsystemet. När man ”bryter ner” en materielsystemplan skapas ett tekniskt ramverk.

Detta ramverk i form av deleditioner inbegriper ett inkrementsdirektiv som styr (innehållet) vad som är viktigt i varje deledition och vilka konfigurationer som skall tas fram. Här ingår dessutom en matris med integrationstidpunkter för de produkter som påverkas i varje deledition.

Arbete med deleditioner utvecklas iterativt med kortare utvecklingssteg och med en jämn och förutsägbar takt, samt med tydliga avslut av arbetet.

Systemutveckling kan lämpligtvis göras i olika steg. Man delar upp utvecklingsarbetet i flera inkrement som senare skall bilda/omfatta hela systemet. Inkrement är en funktionell utveckling av t.ex. ett system, som skall finnas med i leveransen. Ett inkrement är en fullt utvecklad och verifierad version av det kompletta systemet, men med begränsad förmåga.

Man kan säga att inkrementsdirektivet beskriver vilka system och funktioner som skall ingå och hur systemet skall växa till och integreras. Huvudsyftet med inkrementsdirektivet är att fastställa mål, och övergripande innehåll i inkrementet och dess deleditioner. Innehåll och definition i deleditioner och leveranser styrs av inkrementsdirektiven.

I detta ingår även att fastställa konfiguration vid integrationstidpunkter, i arbetspaket och framtagning av vissa ändringsdokument i aktuellt utvecklingsinkrement. Utifrån beslutade leveranser skapas konfigurationerna i ett specifikt konfigurationsstyrningsverktyg.

Effektiv utveckling inom "airframe"

I detta avsnitt belyses hur en förändringsresa kan se ut när det handlar om ett arbete där integration av olika typer av system är i fokus. Arbetet avser förbättring av process, metod och arbetssätt inom teknikområde "Airframe" och berör arbetet med Gripen E.

Gripen E är en vidareutveckling av befintliga versioner av Gripen. Nya kundkrav har gjort att ca 95 % av flygplansskrovet och tillhörande installationer är omkonstruerade för erhålla lägre vikt, mer utrymme, mer inre bränsle, kunna ha fler sensorer, kunna ha högre temperaturer och tryck etc.

I nedanstående beskrivning har arbetet med ovanstående avgränsats till teknikområdet "Airframe". Detta teknikområde omfattar de materielgrupper/funktioner som behövs för utveckling avseende konstruktion, hållfasthetsanalys och produktionsteknik för skrovet respektive systeminstallationerna (alla rör-, el-, bränsle-, luft- och hydraulikinstallationer). Dessutom ingår framtagning av laster på flygplanet, vikt på alla apparater och delar i flygplanet samt aeroelasticitet och fladder i teknikområde "Airframe".

Förutsättningarna 2008

När arbetet startade 2008 fanns en process för hur arbetet skulle genomföras. Denna process kallad ADI (Airframe Design and Industrialization) utgör en del av Saabs verksamhetsledningssystem.

Denna process var vid den tidpunkten beskriven på ett sådant sätt att det fordrades mycket tolkning av processens beskrivningar. Processen beskriver hur man skall arbeta för att produktkraven skall uppfyllas. Här beskrivs hur man skall realisera designen. Detta görs i tre större iterationer, en konceptfas, en preliminär konstruktion samt i en detaljkonstruktion.

Det projekt som skulle realisera ovannämnda kundkrav omfattade ca 400 projektmedlemmar.

Genom att projektet var av stor omfattning med många projektmedlemmar var det av stor vikt att aktiviteterna i utvecklingsarbetet kunde drivas med en mycket styrd planering. Det var även väsentligt att den tekniska mognaden av projektresultaten låg i takt och man arbetade iterativt i utvecklingsarbetet så att man fick en teknisk mognad som också var verifierbar.

Tidigt i projektet valdes MBD (Model Based Definition) för allt arbete, vilket innebär modellbaserad utveckling utan pappersritningar.

Huvudsyftet i detta arbete är att harmonisera data och göra en teknisk "baseline" tillgänglig för alla berörda projektmedlemmar. Genom detta arbetssätt kan man återanvända data i hela flödet samt minska överlämningar till alla intressenter av produktdata som skapas i projektet.

Nyutveckling i denna skala hade inte genomförts av den generation ingenjörer som fanns att tillgå 2008.

Vid denna tid hade teknikområde "Airframe" brist på tillräckligt många erfarna ingenjörer. ADI-processen och det granskningsförfarande som användes vid denna tidpunkt, var utformad för mer erfarna ingenjörer och inte lämpad för den stora den mängd av arbete som skulle göras och granskas.

Projektets konceptfas bedrevs under 2008 och 2009. Arbetet bedrevs traditionellt med studier mot funktionsmål, i nära samarbete med kunden FMV.

Inom den dåvarande organisationen fanns då inte tillräcklig insikt om omfattningen av kommande utmaningar, och man hade inte tillräcklig bemanning i projektet med erfaren personal.

När man drev arbetet i konstruktionsfasen för att ta fram en preliminär konstruktion blev det dock tydligt att kunskaperna om nykonstruktion och tvärfunktionellt arbete inte var tillräckliga bland de som då arbetade i projektet.

Vid granskning av preliminär design för vissa konstruktioner visade det sig att resultaten inte hade den tekniska mognaden som erfordrades. Dessutom var granskningsarbetet tungarbetat och höll inte tillräcklig kvalitet. Det betydde att produkten inte uppfyllde de krav och de produktdata som krävdes. Man kunde då konstatera att kunskapen om projektets omfattning, innehåll, svårighetsgrad och krav var bristfälliga och att det krävdes ett omarbete.

Erfarenheterna från de tidiga faserna i projektet var följande; produkten hade ”ojämn” mognad, granskningen var bristfällig och utfördes för sent, utbildningsnivån var för låg och information inom projektet hade brister.

Därför beslutade projektets teknikledningsgrupp att ett antal förändringar måste genomföras, vilka innebar följande:

  • Att granskning måste göras direkt på produktdata, inte på presentationer i konferensrum.
  • Att arbetssätten säkrades inom samtliga teknikområden så att man fick rätt teknisk mognad i resultaten och att man utvecklade konstruktionerna i takt.
  • Att produktkraven och dess nuvarande mognad måste vara synlig för alla projektmedlemmar.
  • Att behov av tekniska beslut måste kunna lyftas snabbt och att beslut skall kunna fattas direkt vid granskning eller uppföljning. Man behövde också förstärka beslutsstödet.

Steg 1 Förändringsarbetet 2011-2014

Det första steget i förändringsarbetet genomfördes i under åren 2011-2014.

De förändringar som genomfördes kan sammanfattas enligt följande:

  1. Större delen av granskningen genomförs tidigt processen av ingenjörsledarna. DMU-granskning med strängt styrd agenda startades. Resultaten kategoriserades i skalan röd/gul/grön efter grad av ”allvarlighet” med avseende på. kravuppfyllnad. Projektet börjar fokusera på ”röda” problem först.
  2. Många krav formuleras med ”filter” i CAD-systemet och blir visuella för alla – DRI-modeller.
  3. Samtidig teknisk mognad förtydligas i instruktioner för granskning och utbildning genomfördes i ”Sund konstruktion”. Ett ärende struktureras och nödvändiga förändringar beskrivs och fördelas till respektive materielgrupp för åtgärd.
  4. Produktens mognad syns som ett statusmarkerat (färger enligt ovan) flygplan när man loggar in i CAD-systemet.

De resultat som förändringsarbetet gav kan sammanfattas enligt följande:

  1. Det statusmarkerade flygplanet gav projektdeltagarna tydlig information om den tekniska mognaden av flygplanet och processen hur man ”mognar” flygplanet ”Röd till Gul till Grön” är tydligt styrd och tillämpas över hela "Airframe" d.v.s. de röda, omogna områdena, är tydliga för alla projektdeltagarna och man vet, via aktionslistan, vad som återstår för att vara tillräckligt mogna för godkänd granskning.
  2. Man genomförde tydligare prioriteringar. De röda områden och tillhörande aktioner prioriteras genom tillsättning av erfarna ingenjörer i en arbetsgrupp per område. Detta medförde snabbare aktionsstängning än väntat ca 1000 aktioner under 6 månader.
  3. Granskningsgrupp, teknikledning och projektledning upplever att det är mindre frågor avseende omfattning och innehåll i uppdraget.
  4. Konceptet ”Sund konstruktion” med visualisering är infört. Med hjälp av DRI-modeller har man tillfört tydlighet och mindre frågor om hur produktens krav ska realiseras i designen.

Figuren är en illustration av ovanstående text

Steg 2 förändringsarbeteunder 2015

Erfarenheterna från framtagning av ett provflygplan för Gripen E håller på att vidareutvecklas till serieanpassningen av Gripen E.

Detta arbete sker med hjälp av ”uppstart av granskningar” och uppföljningar, d.v.s. proaktiv tidigareläggning av arbetet. Man har också gjort ett införande av Scraab samt av ett dagligt ”tekniskt beslutsstöd” för alla tekniska ledare. Dessutom finns det tillgång till ett dagligt stöd av erfarna ingenjörer, MGA och CI.

Man har infört och tillämpar det iterativa arbetssättet per ”utvecklingsfas”. Detta arbetssätt har standardiserats och samlats i en tillämpningsbeskrivning. Det avser arbetet mot godkänd granskning i ett s.k. ”FIA-spel”. ”FIA-spel” utgörs av ett visuellt schema med mognadstatus för momenten som leder till en avslutad etapp (PDR).

Konceptfasen startar med en konceptstudie. Denna studie och de iterationer som fasen innehåller syftar till att bestämma, krav, budget och arkitektur och designprinciper för hela flygplanet.

Fasen med preliminär design syftar till att bestämma gränssnitt och iterera krav samt ta fram en preliminär konstruktion, som är sund robust och utvecklingsbar. Fasen detaljerad design syftar till att detaljera och dimensionera konstruktionen inom krav och överenskomna gränssnitt.

Analys av resultat visar på en förmågeutveckling

Jämför man läget inom teknikområdet "Airframe" mellan 2012 och 2015 så ser man tydligt hur en förmågeutveckling har skett. Förmågan har dramatiskt ökat genom en omfattande satsning och fokusering på modellbaserat arbetssätt – MBD. 

I tabellen görs en jämförelse av mognaden i organisationen.

Nästa steg i förändringsresan

Målen för framtida arbetssätt för en tvåsitsversion, Gripen F innebär att man kommer att genomföra en tydligare ”baseline” av all data för att säkerställa att alla itererar mot rätt data. Dessutom så kommer processen för konceptfas att förtydligas med ett FIA-spel mot CER, med lärdomar från ovanstående.

Nästa steg i förändringsresan innebär följande:

  • Att säkra kvalitet och innehåll av all produktdata för att säkerställa att alla itererar mot rätt förutsättningar.
  • Att förtydliga processen för konceptfas med ett FIA-spel mot CER d.v.s. ett visuellt schema med mognadsstatus för momenten mot avslutad etapp (CER).
  • Ett nytt arbetssätt för hur man beslutar och strukturerar studiearbete.
  • Implementation av teknikdisciplinen "Strukturtekniks" arbete i MBD-flödet.
  • Att genomföra metodik och arbetssätt med hjälp av MBD, för att spara vikt i alla konstruktioner.

Sammantaget har ovanstående medfört ett tydligare informationsflöde i projektet och bättre medvetenhet om projektläget hos medarbetaren. Man har fått en produkt som är mera harmoniserad och kvalitetssäkrad under arbetets gång. Den subjektiva uppfattningen är att detta är en mycket stor effektivisering. Det statusmarkerade flygplanet ger projektdeltagarna tydlig information om den tekniska mognaden av flygplanet.

Processen hur man ”mognar” flygplanet ”Röd till Gul till Grön” är tydligt styrd och tillämpas inom hela teknikområdet Airframe. De röda, omogna områdena, är tydliga för alla projektdeltagarna och de vet, via visualisering och aktionslistan, vad som återstår för att vara tillräckligt mogna för godkänd granskning.

Man har fått tydligare prioriteringar, eftersom röda områden och tillhörande aktioner prioriteras genom tillsättning av lämpliga ingenjörer i en arbetsgrupp per område. Detta medför snabbare aktionsstängning än väntat, vilket har bedömts till ca 1000 aktioner under 6 månader.

Man har fått en harmoniserad terminologi och målbild via utbildningen ”Sund konstruktion”. Dagligt tekniskt beslutstöd har under ett år förändrats till 4 beslut per vecka.

För att man skulle lyckas med dessa stora förändringar, så krävdes några förutsättningar, de flesta handlar om kommunikation. Man kan sammanfatta dessa enligt följande:

  1. En erfaren tvärfunktionell teknikledningsgrupp med gemensamma mål. Ca 10 personer i detta fall, med god kontinuitet. Sex av tio har varit med hela ”resan”.
  2. En medveten, långsiktig satsning på metodik- och verktygsstöd från linjeorganisationen.
  3. Ett gott samarbete mellan Projekt – Linje – Teknikledning.
  4. Ett klimat där ”kunskap” ärvs mellan projekt; Neuron – B787/Airbus-projekt – Gripen E – TX.

Författarens reflektioner