Den digitaliseringsplan som HCL och Volvo Cars arbetat fram innehåller åtgärder för att skapa en flexibel och produktinriktad organisation. ”Därmed,” skriver man i pressmaterialet, ”kan Volvo hantera komplexiteten i verksamheten på ett effektivt sätt och få ut produkterna snabbare på marknaden, men också dra nytta av fördelar som mobilitetslösningar, prenumerationsbaserade tjänster liksom eldrivna och förarlösa fordon.”
– HCL ser fram emot att som en av Volvo Cars viktigaste leverantörer hjälpa företaget att uppnå sina digitaliseringsambitioner genom att dra nytta av våra expertkunskaper om fordonsbranschen, säger Tagra Pankaj, vice VD och chef för Nordic & DACH Business vid HCL Technologies.
Men Volvo lutar sig inte bara mot HCL i detta. I juli tidigare i år tecknade man också ett samarbetsavtal med den globala jättekonsulten Capgemeni, som nu levererar ett brett utbud av transformationstjänster, inklusive DevOps och molntjänster. Det gör också Capgemini till ytterligare en av Volvos partners inom digital transformation och molntjänster.
Tyngdpunkten i Capgemini-dealen ligger dock på tjänster och annat relaterat till den svensk-kinesiska fordonstillverkarens SAP-lösningar (S/4HANA). Utanför Volvo Cars affärssystemsida, på PLM-området, är det således andra leverantörer som gäller. Här är det Siemens Teamcentersvit och Dassaults CAD-lösning CATIA som är huvudverktygen.
DevOps är en central del, men vad handlar det egentligen om?
Hur som helst har HCL och Volvo Cars alltså sedan 2016 bedrivit ett samarbete kring digitalisering. När omvandlingsprocessen nu utökas till att omfatta flera aspekter av digital omvandling med sånt som exempelvis produktorientering, applikationsintegration och ett affärsorienterat arbetssätt spelar detta med DevOps en viktig roll.
Detta utvecklingskoncept är i och för sig inte nytt inom Geelyfamiljen, utan har med framgång använts inom dotterbolaget på produktutvecklingssidan, göteborgsbaserade CEVT. De senare har under ledning av PLM-ansvarige, Erik Gräns, jobbat med DevOps och nått utmärkta resultat, vilket speglas i bolagets väl uppbyggda fordonsplattformar som används bl a av Volvo Cars inom Geelygruppen. Vi talar här om CMA-arkitekturen, vilket i princip är bottenplattan till de nya bilar som tas fram. Man använder i detta ett upplägg som bygger på ett modulärt koncept baserat på en långt driven digitalisering, där PLM-systemet i allmänhet – CEVT använder Siemens PLMs Teamcenter – och produktkonfigurationen i synnerhet är bärande pelare i utvecklingsarbetet.
DevOps är i skenet av detta sålunda både intressant och centralt när Volvoorganisationen går vidare i utvecklingsarbetet. Men vad handlar det egentligen om?
En kontinuerlig, integrerad och helhetsbaserad utvecklingsprocess
Man skulle kunna beskriva DevOps-konceptet som en kontinuerlig utvecklingsprocess med den välbekanta ”liggande evighetsåttan” som illustrativ symbol (bilden ovan); förloppet tar nämligen egentligen aldrig slut.
Frontit-konsulten Robert Gistvik har gjort en utmärkt beskrivning av saken:
”DevOps är ett resultat av den agila metodikens behov av snabba cykler och handlar om samarbetet mellan utveckling (Dev som i Development) och IT Operations (Ops). Vad man tar sikte på är att möjliggöra en kultur och miljö där det går att bygga, testa och lansera ofta, snabbt och tillförlitligt.
Fokus ligger på kulturella och strukturella förändringar med syfte att föra samman de som utvecklar och de som ansvarar för infrastrukturen. Det finns inte ett specifikt verktyg för DevOps utan det är istället en uppsättning av verktyg som används i en verktygskedja, toolchain, där varje verktyg passar in i en eller flera av faserna.
Notera att kedjan inte har någon riktig början eller slut så resultaten av mätningar och slutsatser av senaste lanseringen ska tillbaka in i planeringsdelen. Tiden mellan en planering till nästa beror helt och hållet på vilka förutsättningar ens system har och vad man vill uppnå, men hela DevOps-tanken bygger på att korta den så mycket det går.
* Kontinuerlig integration
Ett av målen är ”continuous integration” (CI), eller kontinuerlig integration, vilket handlar om att minska antalet komplexa kodsammanslagningar genom att kontinuerligt slå ihop koden som utvecklas till en gemensam kodbas, helst så fort någon ny funktionalitet eller del av funktionalitet blivit klar. Utöver att koden samlas ihop kontinuerligt ska den även byggas och testas automatiskt vid varje incheckning med enhetstester för att se att den nya koden inte ger några oväntade följder. CI är en vital del för att kunna uppfylla Create-delen (och delvis Verify-delen) i DevOps toolchain.
* Kontinuerliga leveranser & utrullningar
Dessa begrepp blandas ofta ihop dels med huvudtermen DevOps, men även med varandra. De är liknande, men med en viktig skillnad: Med ”continuous delivery” (CD) avses att varje bygge teamet levererar kan släppas ut i produktion, men det är däremot inte säkert att så blir fallet på grund av andra skäl, t ex affärsmässiga. ”Continuous deployment” (”utrullningar”) å andra sidan betyder att det är just detta som görs. Alla byggen som går igenom med godkänd status kommer att läggas ut i produktion. Dessa metoder kopplas till Verify- (delvis), Package-, Release- och Configure-delarna i DevOps verktygskedja (”toolchain”).
Båda dessa upplägg kräver väl utbyggd testautomatisering för att kunna vara framgångsrika.
* Vinster med DevOps
I kvalitetssammanhang talar man ibland om att, ”man blir vad man mäter”. Samma princip kan tillämpas i detta område. Med DevOps kan verksamheten styras åt det håll som är önskvärt. Är det viktigaste målet att snabbt kunna få ut sina releaser så finns det verktyg för det, men DevOps kan lika gärna användas till att enbart höja en produkts kvalitet.
Att börja med DevOps innebär alltså lite kort att få bättre koll på sin leveransprocess, skapa en medvetenhet om hur verksamheten fungerar och förhoppningsvis öka samarbetet mellan avdelningar.”
”Det gäller att hela tiden vara på tårna”
Så långt Robert Gistviks beskrivningar av DevOps. Men det kan i sammanhanget också vara intressant att se hur detta kan te sig i praktiken och hur CEVT funderat i detta, sett ur ett PLM- och konfigurationsperspektiv.
En kort bakgrund: Både CEVT och Volvo Cars jobbar med Siemens Teamcenter som PLM-system, medan Dassaults CATIA är det grundläggande CAD-systemet; en inte ovanlig kombination för OEM-bolag inom automotive.
För CEVTs del började PLM-resan med Teamcenter vid bolagsstarten 2013, för att hantera produkt- och systeminformation på ett tätt integrerat sätt. Samtidigt är fordonsutvecklingsvärlden dynamisk, inget är hugget i sten och tillägg i funktionaliteten är sånt som måste göras kontinuerligt.
Här valde Erik Gräns och hans kollegor att ”attackera” med ett arbetssätt inspirerat av DevOps, ett attackvinkel som använts sedan 2013.
I detta har CEVT jobbat tätt tillsammans mellan affärs- och PLM-utveckling för att leverera snabba och effektiva lösningar. PLM-teamet består såväl av folk med affärsrelaterad analyskapabilitet, som av de som kan kodning, implementering och drift av PLM-systemet, vilket ger ett effektivt resultat med hög affärsnytta.
Nya Teamcenter-funktioner för konfigurationshantering är exempel på dynamiken.
– Det gäller att hela tiden vara på tårna och ta in sånt som vässar våra processer, konstaterar Erik Gräns. Fordonsplattformar är komplexa och allt som förenklar komplexiteten och underlättar förmågan att effektivt hantera komplexitet och variation ”över” flera bilplattformar är värdefullt.
Vill du veta mer om hur Erik Gräns och CEVTs resa sett ut? Missa inte att läsa den längre artikeln av PLM&ERP News’ chefredaktör, Verdi Ogewell, där han diskuterar med Erik Gräns kring detta. Klicka på rubriken eller bilden nedan för att länkas till:
