Att leverera affärsvärde med Data Science på Finnair: Femstegsmodellen

Flygverksamhet är svårt. Att hålla flyg i tid, omdirigera passagerare som missat sina anslutningar och i allmänhet reagera på oväntade händelser är bara några av de problem som driftkontrollanter måste hantera, samtidigt som de tar hänsyn till faktorer som väderförhållanden, resebegränsningar och besättningens tillgänglighet. Vid hantering av operationer fattar flygbolag otaliga beslut varje dag, vars utfall kan bero på varandra och kan ha spridningseffekter på många flyg. Till exempel kan en försening av ett flyg för att vänta på anslutande passagerare leda till att flygplanet anländer sent till sin returflygning, vilket kan göra att andra passagerare missar sina anslutningsflyg. 

Sådana effekter beror på många faktorer, såsom sammansättningen av passagerare på alla drabbade flyg, vilket gör det svårt att väga deras betydelse vid beslutsfattande. Följaktligen har grova, heuristiska modeller traditionellt tillämpats, vilket kan förenkla problemet men också drabbas av bias, vilket leder till suboptimala beslut. I dagens konkurrensutsatta marknad är det allt viktigare för flygbolag att utnyttja sina dataresurser fullt ut i operativa beslut för att kunna erbjuda bästa möjliga service. 

Nyligen fick vi en möjlighet att arbeta med Data Science tillsammans med Finnair, med fokus på deras operativa analysinsatser. Vårt arbete resulterade i matematiska modeller och mjukvaruverktyg, vars användning avsevärt förbättrade kundupplevelsen, förbättrade arbetsflödena i Operations Control Center och ledde till anmärkningsvärda kostnadsbesparingar. I detta blogginlägg beskriver vi de fem viktigaste stegen som bidrog till framgången med vår resa med Finnair. 

1. Identifiera problemet 

Att arbeta på ett flygbolag i Finnairs skala är för en datavetare som en dröm som går i uppfyllelse: data är rikligt och välorganiserat, och det finns till synes oändliga optimeringsproblem att lösa. Naturligtvis är många av de grundläggande problemen redan lösta, som i alla mogna industrier. När vi började vårt arbete var därför de första frågorna: vilka problem kan vi lösa, och vilka problem bör vi lösa genom att utnyttja kundens dataresurser för att skapa så mycket värde som möjligt, både ekonomiskt och för kundernas framgång. 

När vi startar ett projekt är vårt mål som konsulter att förstå de utmaningar kunden står inför. Därför är det naturligt att börja med workshops tillsammans med kundens experter inom området. I detta skede är fokus avgörande: verkliga situationer består alltid av många interagerande variabler, och mängden detaljer kan vara överväldigande. Att filtrera bort irrelevanta egenskaper hos problemet och sträva efter att förenkla en möjlig lösning kommer att löna sig i form av bättre och snabbare resultat. 

När vi kom till Finnair hade en lista över viktiga affärsproblem redan samlats in under interna workshops. Tillsammans prioriterade vi denna lista och övervägde potentiella lösningar mer i detalj. Vi identifierade snabbt att den mest användbara startpunkten skulle vara en matematisk modell av passagerarnas resor från början till slut, för att ersätta de mindre exakta, högre nivåindikatorerna som användes tidigare. Detta skulle ge oss en tydligare bild av kommande och pågående flygningar, vilket leder till enklare och mer informerat beslutsfattande. 

2. Få ut den första versionen 

Efter att ha valt det första problemet att ta itu med, satte vi igång med att bygga en Minimum Viable Product (MVP). Inom mjukvaruutveckling är en MVP en applikation med det minsta uppsättningen funktioner som krävs för att tillfredsställa användarna. Målet är att nya funktioner läggs till efter lansering baserat på användarfeedback. Däremot kan en MVP i en Data Science-produkt även innefatta förenklade antaganden i en modell. Tanken är att det är lättare att engagera intressenter i en feedback-loop när de kan interagera med resultaten och jämföra dem med sin egen expertkunskap inom området. Modellen kan sedan göras mer komplex baserat på feedback, om det visar sig vara nödvändigt. 

När vi började arbeta med MVP behövde många subtila tekniska och datarelaterade aspekter klargöras med kunden. Typiska frågor som tas upp i detta skede inkluderar till exempel vilka datakällor som är rätt att använda för att lösa problemet och hur de olika datakällorna behöver kombineras, rengöras och förbehandlas för vidare modellering. Att dyka ner i data, formulera och validera modellens antaganden samt utarbeta initiala lösningsdesigner gör det klart om den planerade metoden kommer att fungera. Ur kundens perspektiv validerar denna fas att kopplingen mellan expertkunskap och data är korrekt tolkad och verifierar att resultaten som produceras av modellen verkar rimliga. Ofta skapas även sekundärt affärsvärde i detta skede, eftersom det till exempel kan avslöja brister i datakvalitet och förtydliga vissa aspekter av befintliga affärsprocesser. 

I vårt arbete med Finnair var det en stor mängd expertkunskap att ta in, särskilt under de första veckorna. Som tur var kunde vi arbeta nära deras hjälpsamma och extremt kunniga personal, och vi lyckades ha en MVP – en Python-applikation som periodiskt körde modellen och en R Shiny-visualisering – igång på två månader. 

3. Samla in feedback och iterativ utveckling av modellen 

Efter att MVP var igång började vi samla in feedback från kundens experter inom området och andra intressenter. Från denna feedback blev det tydligt var ytterligare utvecklingsinsatser skulle koncentreras. Några viktiga insikter från denna process var: 

• För att användare ska vara engagerade och ge feedback måste användarupplevelsen vara smidig, och det måste finnas en tydlig kanal för feedback. 

• För att expertanvändare ska lita på en modell behöver de transparens kring vad som går in och vad som kommer ut ur modellen. 

Även om iterativ utveckling fortsätter efter den initiala MVP-fasen är den första iterationen avgörande eftersom den förbättrar applikationen i sin helhet och gör den mer robust för nästa fas. Till exempel, med Finnair, ledde den iterativa utvecklingen till att vissa irrelevanta funktioner i applikationernas användargränssnitt togs bort, samtidigt som andra funktioner som från början inte ansågs viktiga inkluderades. Slutanvändare upptäckte också flera undantagsfall som inte hanterades korrekt av de inledande modellerna, vilket ledde till ytterligare förbättringar. 

4. Utveckling till en produktionsklar applikation

Efter att applikationen hade itererats och validerats genom initial feedback började den bli redo för bredare användning. Genom att följa goda mjukvarudesignprinciper från början blev övergången från MVP till en produktionsapplikation smidig. För att uppnå detta följde vi några viktiga punkter: 

• Portabilitet: I Python, till exempel, genom att använda virtuella miljöer eller containrar säkerställs att koden fungerar när den distribueras i olika miljöer (t.ex. vid övergång från utveckling till staging). 

• Underhållbarhet: Genom att skriva modulär kod blir det enkelt att göra ändringar och byta ut beroenden vid behov. Att följa bästa praxis för versionskontroll hjälper till att hålla koll på förändringar och är användbart vid felsökning. 

• Prestanda: I dataintensiva applikationer hjälper det att designa kod med prestanda i åtanke från början för att hålla utvecklingsprocessen snabb. I nära realtidsapplikationer som vår är det också avgörande att säkerställa att ökad komplexitet i modellerna inte påverkar prestandan negativt. Lyckligtvis är dataorienterade programvarubibliotek som Pandas skrivna med prestanda i åtanke, så det räcker ofta att följa bästa praxis. 

• Kundens behov: Det är viktigt att välja verktyg som kunden är investerad i, vanliga rapporteringsverktyg för resultat och programmeringsspråk som ofta används i organisationen (t.ex., med Finnair var det bättre att övergå till ett rapporteringsverktyg som redan användes brett inom organisationen för att presentera resultat istället för de initialt anpassade verktygen som utvecklades). 

• Övervakning och säkerhet måste övervägas noggrant. 

I vårt projekt var vi i det "produktionsklara" stadiet efter cirka fem månader, vilket var när applikationen introducerades för en större grupp användare. Vid det här laget släppte vi den anpassade instrumentpanelen som byggdes i MVP-fasen och levererade resultaten i Finnairs interna Business Intelligence-miljö. Detta hade två huvudsakliga fördelar: 

• Den var redan bekant för användarna, vilket gjorde införandet smidigt, och 

• Hantering av användaråtkomst blev trivialt. 

Sammanfattningsvis var övergången till en bredare användarbas förvånansvärt smidig, även om mängden feedback naturligt ökade märkbart. Därför införde vi några anpassade formulär för att samla in och lagra feedback, vilket avsevärt förbättrade feedbackprocessen. 

5. En uppsättning ytterligare applikationer

Vid den här tidpunkten hade vi en matematisk modell av kärnverksamheten. Även om den fortfarande utvecklades iterativt var den tillräckligt mogen för att ge mer exakt insikt än tidigare lösningar. Genom att noggrant välja det initiala problemet visste vi att kärnmodellen skapade möjligheter för en uppsättning andra verktyg och optimeringsprocesser för att ytterligare förbättra effektiviteten i verksamhetsdriften. Tillsammans med Finnair planerade vi därför flera nya MVP 

som skulle bygga på denna modell. Det fanns två motivationer för att gå vidare med flera applikationer: å ena sidan ville vi snabbt skapa mer värde där det var möjligt, och å andra sidan ville vi lägga ut klargjorda riktningar för Finnairs operativa analys genom att utforska applikationsutrymmet och validera våra idéer. 

Den utvecklade uppsättningen applikationer antogs smidigt för daglig operativ användning, vilket stöddes av utbildningssessioner för slutanvändarna samt en pågående insamling av feedback. Att dela information om verktygen för organisationen och snabbt införliva förbättringsförslag till modellerna möjliggjorde inkluderingen av nyckelpersoner i utvecklingsinsatserna och snabb extraktion av värde från verktygen. Detta resulterade i ökad kundnöjdhet samt betydande kostnadsbesparingar för Finnair. Sammanfattningsvis har den femstegsprocess som beskrivs i detta blogginlägg visat sig vara en värdefull riktlinje när Finnairs operativa analysområde fortsätter att utvecklas.