<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=463105&amp;fmt=gif">
2020-04-01 | Digital transformering

Därför ska du utvärdera leveransmodell när du väljer leverantör

Lästid: 6 minuter

Vad väger ni in när ni väljer ett nytt system? Är det enbart funktionalitet, prestanda, pris och magkänsla eller är det även typ av leveransmodell? Av förståeliga skäl så är det framförallt just dessa parametrar som avgör valet av leverantör eller partner. Enligt oss borde även leveransmodell spela en avgörande roll i detta val. 

Trots att det kan kännas som gamla nyheter att agila leveransmodeller oftast är att föredra framför den mer traditionella vattenfallsmetoden är det fortfarande ett val flera organisationer står inför. Men vad är det som kännetecknar dessa två modeller? 

VATTENFALLSMODELLEN VS AGIL

I vattenfallsmodellen utgår man från att utvecklingsprocessen följer ett flöde - likt ett vattenfall. För att nästa steg ska börja implementeras behöver således det föregående steget vara avklarat. 

Den här typen av leveransmodell är ingen nyhet och kommer i grund och botten från den tillverkande industrin och det löpande bandet. Då, på den tiden,  var det svårt att implementera förändringar på en färdig produkt. Nu lever vi i en annan värld och mjukvara har helt andra förutsättningar i utvecklingsfasen. 

Med avstampet där kliver vi in på den andra modellen i fråga - agile. Denna typ av leveransmodell har till viss del uppstått på grund av att vattenfallsmodellen i vissa fall känts förlegad och inte helt anpassad efter sättet vi vanligtvis arbetar på. 

Det som framförallt förknippas med agil är flexibilitet. Flexibilitet som gör det möjligt att byta riktning och göra snabba justeringar utifrån hur produkten används eller oförutsedda händelser runt omkring som påverkar det nuvarande läget. Det kan bland annat vara förändringar i hur verksamheten arbetar som snabbt måste mötas i form av systemstödets funktionalitet. 

UTAN SAMVERKAN BLIR MODELLEN IRRELEVANT

Oavsett vilken modell som tillämpas bör utvecklingen ske i samråd mellan avdelningar. Berörda parter bör därför medverka genom hela implementationsfasen för att förstå verktyget och hur det ska nyttjas på bästa sätt. 

Vi stöter ofta på scenarier där antingen IT eller verksamhet vill ta ett tydligt ägandeskap i frågan. Det kan vara att verksamheten efterfrågar nya systemstöd då de nuvarande inte längre möter de krav som ställd. Eller så kan det vara IT som vill ersätta eller komplettera ett system för att skapa bättre förutsättningar för verksamheten. Oavsett vilket scenario eller vem som har projektledarhatten så är inkludering en av de viktigaste frågorna i ett IT-projekt. 

Om det inte tidigt säkerställs att systemet möter säkerhetskrav eller går att integrera mot kan det betyda stora förluster i form av tid från båda sidor. Därför är det viktigt att detta görs tidigt i processen och att kravställare finns med från första början. 

Går vi då tillbaka till de olika modellerna kan det ske tvära svängar som behöver adresseras - och det snabbt. Är det tydligt specificerat när allt ska hända, vem som äger vad och hur det ska exekveras kan vattenfallsmodellen fungera alldeles utmärkt. I verkligheten kan det dock skilja sig och den ursprungliga planen kan möta oförutsedda farthinder som drar projektet mot en annan riktning. Då krävs det mer flexibla angreppssätt för att ta sig runt och över hindret. 

Fördelar och nackdelar med vattenfallsmodellen:

    +   Enkelt att applicera då modellen är lätt att förstå
    +   Tydliga brytpunkter i processen - när sker vad
    +   Kommunikation mellan avdelningar är inte lika avgörande
    -    Problem med skalbarhet
    -    Organisationen blir sårbar för oförutsedda händelser
    -    Flaskhalsar uppstår lätt då personberoendet är högt
    -    Ingen tydlig samverkan, olika avdelningar arbetar i silos 

Fördelar och nackdelar med agil leveransmodell:

    +   Flexibilitet i projekten 
    +   Koordinerade insatser leder till snabbare projekt
    +   Kollektivt ägandeskap leder till ökat engagemang
    +   Iterativ process som kan förfinas över tid
    -    Kräver att organisationen anammar ett flexibelt arbetssätt
    -    En tydlig kommunikation är en förutsättning för att lyckas
    -    Det behövs tydlig struktur och ägandeskap för säkrad framdrift

OLJETANKER VS. MOTORBÅT

Vi har fått höra några av våra kunder som liknar oss och en agil leveransmodell med en motorbåt i jämförelse med en oljetanker. Dels på grund av att den agila leveransmodellen möjliggör en förmåga att snabbt kunna ändra riktning i projektet om det skulle behövas och dels möjligheten att snabbt kunna allokera resurser som styr projektet i rätt riktning. 

Vår rekommendation är att projekt får ta max 90 dagar från idé till lösning - ofta går det snabbare än så. 

VÅR TRESTEGSMODELL

På Barium har vi valt en tydlig leveransmodell som består av tre huvudsakliga steg eller workshops. Vid varje workshop är det ett nytt steg som tas mot att få en körbar applikation redo att användas av verksamheten. 

Något som är av allra största vikt i dessa workshops är att det finns flera avdelningar närvarande. Förändringar i interna arbetssätt kräver översyn från flera parter, inte bara verksamheten eller IT. Om dessa arbetar tillsammans blir slutresultatet alltid till det bättre.


Vill du veta mer om vår produkt Barium Live? Använd knappen nedan för att komma till vår produktsida som visar en övergripande bild av funktioner och integrationsmöjligheter.

Upptäck Barium Live