Slik brukte vi smidig utvikling og blokkjede til å bygge en intelligent forsyningskjede for vaksiner

 

Les transkripsjonen:

Vi prøver ut et dataprogram for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Galen Low: Covid-19-pandemien tok verden med storm og satte i gang tusenvis av prosjekter for å håndtere krisen. Og likevel har vi, nå som pandemien offisielt er erklært over av helsemyndigheter over hele verden, fortsatt ikke virkelig stoppet opp for å feire de menneskelige samarbeidene som bokstavelig talt hjalp menneskeheten gjennom den.

Det sier seg selv at jeg ble svært begeistret da dagens to gjester takket ja til å snakke med meg om hvordan teamet deres hjalp myndighetene med å etablere en innovativ, formålsbygd, blokkjedebasert og intelligent forsyningskjede på få måneder, slik at vaksiner kunne leveres trygt og innenfor kravene i et enormt geografisk område.

Så hvis du er interessert i å få et innblikk bak kulissene i et virkelig smidig og virksomhetskritisk digitalt prosjekt, sett fra perspektivet til den ledende prosjektlederen og den ledende produkteieren, bør du lytte videre. Vi skal se nærmere på utfordringene de møtte knyttet til teknologi, utforming av brukeropplevelsen, utbrenthet i teamet og de lite smidige begrensningene i offentlige prosesser – og hvordan de overvant dem for å holde landet sitt trygt.

Hei alle sammen, og takk for at dere lytter. Jeg heter Galen Low og kommer fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et oppdrag om å hjelpe hverandre med å utvikle ferdigheter, bli tryggere og knytte kontakter, slik at vi kan øke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedigitaprojectmanager.com.

I dag skal vi gå i dybden på et prosjekt som virkelig satte smidige metoder og blokkjedeteknologi på prøve for å få vaksiner i hendene på dem som trengte dem under pandemien. Med meg i dag har jeg Martin Gelb og Bill Moroz, produktlederen og prosjektlederen som sto i spissen for prosjektet.

Herrer, takk for at dere blir med meg i dag.

Martin Gelb: Takk, Galen. Vi er veldig glade for å kunne fortelle litt om hva teamet klarte å få til i denne perioden.

Galen Low: Nei, jeg setter pris på det. Det er så sjelden vi får gå i dybden på prosjekter, og særlig med denne kombinasjonen, der vi har produktlederen og prosjektlederen for et prosjekt av denne størrelsen. Jeg vet at vi kan dele noen virkelig gode innsikter med lytterne våre i dag. Så takk igjen for at dere er med i programmet. Jeg gleder meg til å gå i dybden.

Men først lurte jeg på om dere kunne fortelle lytterne våre litt mer om dere selv. Martin, du beskriver deg selv som en teknologiproduktleder som liker å skrive. Kan du fortelle lytterne litt om hvilke typer produkter du har jobbet med, og hvordan du først begynte med produktledelse?

Martin Gelb: Det var interessant, for jeg begynte egentlig som teknisk skribent for lenge siden. Det gjorde meg svært interessert i teknologi som konsept, og deretter i hvordan disse produktene faktisk blir ferdigstilt.

Hvordan skjer det? Noe av det første jeg jobbet med, var krav- og avklaringsmøter. Dermed fikk jeg forståelse for metodikken og for hvordan man kunne snakke litt med utviklere på den tiden. Men det vokste på meg. Jeg jobbet en stund mer med markedsføring, men ble trukket inn i produktledelse av mannen som hentet meg inn i offentlig sektor.

Vi hadde jobbet sammen for lenge siden, og det var en svært tidlig skyapplikasjon. Jeg skal ikke avsløre alderen min, men det var et av de første virkelig morsomme og vellykkede produktene jeg hadde fått lede. Det var mer som et planleggings- og tidsregistreringssystem for helsesektoren i Ontario, i samarbeid med en tysk partner.

Det neste jeg er virkelig stolt av, var innen finansielle tjenester. Jeg kjente også en mann som startet et selskap for etterlevelse innen finansielle tjenester. Altså noe innen kundekontroll og tiltak mot hvitvasking, det de nå kaller, tror jeg, finansteknologi. Men dette var rundt 2013 eller 2014, så forkortelsen hadde ennå ikke kommet inn på markedet.

Vi dreide tidlig mot kundekontroll og tiltak mot hvitvasking og gikk svært vellykket ut i markedet med dette. Deretter gjorde vi noen andre ting, og så kom pandemien. Mannen jeg hadde jobbet med, ringte, og resten er historie. Her er vi to år senere, og forrige uke ble pandemien offisielt erklært over.

Galen Low: Den er offisielt over. Der har du det. Det er tre ting jeg liker ved dette. A) Jeg liker tanken på at folk i den digitale verdenen bare blir trukket inn i den, ikke sant? Du nevnte at du nærmest ble dratt inn i produktledelse. Og så vokser alle disse teknologiene frem. De dukker ikke bare opp på dag én og sier: «Her er finansteknologi, her er blokkjede, her er alle disse tingene.»

De utvikler seg sakte og har blitt videreutviklet underveis.

Martin Gelb: Ja, og det er som å gjete katter, ikke sant? Å være produktleder er bokstavelig talt som å gjete katter. Jeg visste med en gang jeg endte opp her, at den første personen jeg måtte ringe, var Bill.

Galen Low: Det er sannsynligvis en god overgang. Bill, faste lyttere av programmet kjenner deg nok, men for dem som er nye her, kan du fortelle litt om hvilke typer prosjekter og programmer du har ledet tidligere?

Bill Moroz: Det handler om virksomhetskritiske leveransesystemer og plattformer. Jeg er teknisk prosjektleder, programleder – kall det hva du vil. Jeg begynte etter McGill University, langt tilbake i tiden, med programmering i dBase III. Arven min er data: dataaggregering og innholdsaggregering.

Det finnes alltid et forretningsproblem som må løses. Så får jeg en telefon fra Martin som sier: «Du, er du ledig? Jeg trenger virkelig hjelpen din.» Og helt ærlig var det den beste telefonen jeg noen gang har fått, fordi vi gjør en forskjell, og vi har lagt til rette for at forskjellen skal fortsette å bli gjort, uavhengig av om vi er der eller ikke.

Dette beveger seg fremover av seg selv, med fundamentet og pilarene vi har etablert for dette viktige initiativet.

Galen Low: Jeg elsker det. Og når det gjelder hvor virksomhetskritisk dette er, så er dette saken. Jeg vet at vi har gått litt rundt beskrivelsen av prosjektet, men jeg tror dette er en god overgang. La oss bare gå rett inn i det.

Når det gjelder konteksten, er situasjonen slik: Pandemien har rammet. Myndigheter over hele verden har ansvar for å distribuere vaksiner etter hvert som de blir tilgjengelige, til lokalsamfunnene og områdene som trenger dem mest. Hva vil dere si var utfordringen dere fikk?

Martin Gelb: Det var egentlig et konseptbevis, Galen. Og la oss være tydelige: De hadde allerede bygget et system. Det var ikke skybasert. Det var bygget av det kanadiske forsvaret, som var hentet inn for å gjøre dette, for hvem andre kunne de egentlig få tak i? Hvor skulle de finne hundre, 150 eller 200 personer og bemanne dette?

De ble hentet inn. De begynte med regneark, og de er svært gode på regneark. De hadde hundre, som jeg sa, et par hundre personer som kunne hamre på regneark hele dagen og hele natten. Og ikke nok med det: Det var drift døgnet rundt på det tidspunktet.

Da jeg kom inn, hadde de allerede utviklet eller i det minste utformet det de kalte et minimumsprodukt, basert på plattformen jeg beskrev for deg. Og det var minimalt – virkelig et minimumsprodukt i ordets rette forstand. Det var kanskje et knapt levedyktig produkt. Så vi hadde mye arbeid foran oss. I tillegg var det lite kontroll rundt forretningskravene og utviklingen, altså produktledelsen. Dette skjedde ikke.

Bill Moroz: Når det er sagt, så fungerte det, men det fungerte på en veldig …

Martin Gelb: Manuell måte. Det som foregikk, var så manuelt. De kunne sette 40 eller 50 personer på hver side av prosessen, ta imot ordren i SAP, hente den ut og gjøre hva som helst – det var slik det fungerte.

Så dette måtte vi selvsagt ordne, og vi hadde verktøyene til å gjøre det. Vi hadde S/4HANA – en komplett premiumpakke for virksomhetsressursplanlegging – utviklingsressurser og penger. Med en gang etablerte Bill og jeg et ganske sterkt rammeverk rundt dette. Og jeg vil ikke gå så mye lenger inn på hvor hardt vi måtte presse prosessen, men rundt september eller oktober trakk forsvaret seg ut, og vi gikk over til sivil styring.

Det var vanskelig, fordi de tydeligvis ikke kom til å ha 150 personer å hente inn. Det var rett og slett umulig å finne folk på den tiden. Så vi gikk fra 150 personer til rundt 30 eller 40. Vi måtte derfor gjøre mye raskt arbeid, smidig arbeid rundt prosessene, og begynne å ta det som en salami: Her er det vi har automatisert, så la oss begynne å bevege oss ut i begge retninger så langt vi kan. La oss prøve å finne ut om det finnes andre ting vi kan gjøre her ute for å få dem inn også. Konseptuelt var det slik vi gikk frem, og da vi kom til jul, innså vi at det faktisk fantes mange spesialkodede prosesser, API-er og all mulig annen søppel der, egentlig.

Bill Moroz: Det var her prosjektlederperspektivet faktisk ga meg en ny erfaring, fordi vi måtte bygge inn livskvalitet som en parameter. Operatørenes livskvalitet gikk fra en klassisk digital transformasjon fra rundt hundre til rundt 30 personer, og videre til neste fase, som er der vi er nå.

Martin Gelb: Nå er vi nede i færre enn ti personer som drifter systemet.

Galen Low: Wow. For å presisere: Dette er en krise når det gjelder krisehåndtering og respons, ganske typisk for enhver offentlig virksomhet. Man henter inn ressursene man har, sannsynligvis hæren, for å etablere noe. Det du beskriver for meg, var det knapt levedyktige produktet fortsatt ganske smart?

Det har en S/4HANA-bakside. Dere har mange mennesker og bemanningen til å drifte det, men det er fortsatt svært regnearkdrevet. De tar ut data, legger dem inn igjen og manipulerer dem på egen hånd. Det er mange hender i den deigen, og dermed stor feilmargin.

Og etter hvert trenger vi selvsagt å sette på et plaster, men vi må også bli smartere. Feilmarginen er faktisk så liten i noe som en pandemi at systemet må bli smartere, slik at det finnes færre feilkilder. Det var her dere kom inn og sa: Hvordan kan vi forbedre dette systemet og gjøre deler av det mer intelligent underveis, slik at det kan driftes av færre mennesker med større nøyaktighet i dataene de arbeider med?

Og uten nødvendigvis å ha et punkt der noen kan si: «Jeg glemte at formelen for denne cellen måtte rettes.» Og plutselig blir ikke vaksiner levert til menneskene som trenger dem i disse regionene.

Martin Gelb: For oss handler alt til syvende og sist om dataene. Vi står ikke på en lasterampe og ser lastebiler kjøre ut med paller bak og krysser dem av på et papir. Alt vi har, er dataene. Hvis vi kan låse dem på en eller annen måte og sikre at vaksinene har bestått kvalitetssikringen og er klare for levering, har vi det vi trenger.

Det finnes et partinummer, en utløpsdato, temperaturgrenser og informasjon om hvor den skal. Den er på vei. Den er levert. Den er innenfor temperaturgrensen. Den er nå på anlegget der borte, og alt er i orden. Det er dette vi må vite. Noe av denne informasjonen er tilgjengelig for oss, men noe var det ikke.

Vi fikk den asynkront fra flere forskjellige steder. Jeg vil ikke snakke for mye om alt dette, men hva har vi egentlig? Hva arbeider vi med? Hva er plattformen vår? Jeg kan snakke raskt om det. Vi har en SAP S/4HANA-bakside, altså en komplett ERP-løsning.

Vi bruker hovedsakelig modulene for materialstyring samt salg og levering, med litt orkestrering av forretningsprosesser og noen andre ting. På forsiden har vi en sikker portal med rundt 50 eller 60 brukere over hele Canada, som bestiller for sine jurisdiksjoner, altså provinser og territorier.

I tillegg finnes det føderale etater som har sin egen bestilling. Frontenden er bygget i React, en ganske vanlig frontend. Det er bestillingsfunksjonen. Det presenteres også noe data der. Det er faktisk en ganske god portal.

Bill Moroz: Martin, bare så jeg kan legge til noe: En del av portalutformingen handlet om kundeopplevelsen, ikke sant?

Vi har kunder, og det handler om brukervennlighet. Vi ville ikke at dette bare skulle være enda en offentlig, flat eller kjedelig portal. Jeg vil understreke brukeropplevelsen, kundeopplevelsen og brukervennligheten. Dette er et viktig produkt.

Dette er i praksis vaksiner som skal inn i folks armer for å redde liv. Covid-19 har tatt livet av mange mennesker. Derfor er brukervennligheten viktig. Vi lyttet til kundene for å forstå hvordan de ønsket å se ting ut fra et brukbarhetsperspektiv. Vi har faktisk opprettet en brukergruppe for å få denne tilbakemeldingen og ta innspillene inn i fremtidige utgivelser.

Martin Gelb: Ja. Vi gjennomførte intervjuer én til én og prøvde virkelig å få så mye tilbakemelding som mulig, fordi vi visste at dette var noe – og la oss være ærlige: Dette var folkehelseansatte i ulike jurisdiksjoner som var presset inn i arbeidet.

De var for det meste ikke logistikkmedarbeidere eller noe lignende. Derfor ønsket vi å være så vennlige og samarbeidsorienterte som mulig da vi bygget portalen på nytt. Den første var ikke særlig god, men vi bygget den om med mye tilbakemelding, gjennomganger og presentasjoner.

Tradisjonelle ting innen produktledelse. Jeg kunne komme inn og si: «Dette er tingene vi må gjøre.» Bill sa: «Her er grunnen til at vi må gjøre dem», og sørget for at alle gjorde det. Vi fungerer ganske godt som et team på den måten.

Galen Low: Det liker jeg. Det liker jeg.

Jeg må spørre, fordi jeg som kanadier vanligvis ikke forbinder den kanadiske regjeringen med at smidig utvikling er noe den er god på. Jeg sier dette ut fra et inntrykk: Jeg tror den gjennomsnittlige kanadieren, eller noen som ser inn utenfra, tenker at vi gjør mye bra i den kanadiske staten, særlig digitalt, men det er ikke slik det vanligvis oppfattes.

Men det er fortsatt mye byråkrati, antar jeg. Dere jobbet raskt. Dere fortalte meg om en tidsperiode fra en gang etter mars 2020 til oktober, der dere hadde gjennomført flere iterasjoner og fått tilbakemeldinger fra kunder. Hvordan var det? Hva var noen av utfordringene med å være smidige?

Martin Gelb: Vi fikk et litt løsere sett med rammer enn det som vanligvis ville vært tilfellet. Ikke at vi utnyttet det på noen måte, men vi så hvor langt og hvor raskt vi kunne gå, og så gjorde vi det. Det handlet om å gjøre livet bedre for operatørene, slik Bill sa, fordi de var overveldet. Vi jobbet alle helt vanvittige timer på det tidspunktet, kvelder og helger, og alle måtte bidra hele tiden.

Vi overvåket systemet, e-postene og meldingene våre hele tiden, fordi det hele tiden skjedde noe. Plutselig kom det en ny variant, og vi måtte lage et nytt produkt. Plutselig kom det nye behandlingsmidler, og vi måtte registrere dem. Deretter kom forebyggende midler som også måtte registreres.

Så kom vi til et punkt der vi gjorde en analyse og innså at det fantes over 50 eller 60 forekomster av spesialtilpassede ting der inne som ikke var standard SAP, og heller ikke egentlig standard for forsyningskjeder.

Vi laget en plan, og Bill gjorde dette utrolig godt. Han laget planen for det vi skulle kalle versjon 2.0. Samtidig lanserte vi ni versjoner under versjon 1 og fire underversjoner. Altså rundt 13 utgivelser på litt over ett år. Det er utrolig i ethvert miljø jeg har jobbet i, og på virksomhetsnivå er det ubegripelig.

Vi hadde 35 eller 40 utviklere og andre prosjektledere på den andre siden, og en hel rekke mennesker involvert. Dette skjedde ikke uten teamet, uten Bill og uten noen av de andre. Jeg vil ikke nevne navn her, men dette er personer som var helt avgjørende for at dette skulle lykkes. Jeg sier stadig at jeg, Martin, ikke gjør noe.

Disse menneskene gjør bokstavelig talt alt arbeidet, og hver eneste en fortjener en medalje for innsatsen i denne perioden. For meg er det et høydepunkt i karrieren. Først gjennomførte vi alle disse utgivelsene, så laget vi 2.0, som i praksis skrev om alt.

Vi fulgte beste praksis og SAP-standarder og gjorde løsningen dataorientert og brukerorientert. Alt dette ble bygget inn. Samtidig bygget vi også et datavarehus.

Bill Moroz: Hvorfor ikke?

Martin Gelb: Ja. Hvorfor ikke? Når vi først var i gang med full fart.

Galen Low: Jeg liker det. Bill, kan vi gå litt inn på teamet og metoden?

Vi har snakket om utviklerne og menneskene som forsket. Vi har snakket om smidig utvikling. Hvordan så dette ut i praksis? Hvordan klarte dere å få ut 14 utgivelser på så kort tid? Hvilken variant av smidig utvikling brukte dere, og hvordan samarbeidet teamene? Hvordan fungerte samarbeidet?

Bill Moroz: Vi la for stor vekt på kommunikasjon. Det handler om å kommunisere for mye, ikke nødvendigvis om å fylle hele dagen med kalenderinvitasjoner, men om å kommunisere hele dagen, hver dag. Arbeidsmøter, demonstrerte resultater og målrettet arbeid: Dette er det vi ønsker å oppnå i løpet av de 45 minuttene vi har sammen i denne avklaringen.

Nådde vi målet? Ja. Da feirer vi suksessen, så mye vi kan i et virtuelt miljø. Og igjen: Alle jobbet virtuelt. Martin, du vil kunne si at det finnes personer på teamet mitt som jeg ennå ikke har møtt fysisk. Vi hadde et teammøte med noen av leverandørene våre i Toronto for noen måneder siden.

Vi hadde jobbet sammen i to år, eller nesten to år, og dette var første gang vi faktisk møttes. Likevel var alt sømløst. Det var som om vi hele tiden hadde jobbet sammen i det samme samarbeidsrommet. Suksessfaktoren var å forstå helhetsbildet og målet, men også de enkelte delmålene som bringer oss dit. Vi feiret suksessene og sørget for at holdningen var: Det handler ikke om hva vi ikke kan gjøre, men om hva vi kan gjøre og hvordan vi kan gjøre det. Og om å håndtere forventningene.

Dette er svært teknologibasert. Martin, vil du fortsette? Noen tenker på teknologi som å trykke på en knapp.

Martin Gelb: For mange er digital transformasjon fortsatt regneark. Regneark har vært en plage for meg. Misforstå meg rett: Jeg mener faktisk at Excel er det beste programmet Microsoft noen gang har lansert.

Men det er ikke et verktøy for datahåndtering, særlig ikke når det ligger på noens OneDrive. Derfor måtte vi virkelig fokusere på å fjerne dette, uten samtidig å gjøre livet vanskelig eller være mer forstyrrende enn nødvendig. Disse menneskene har en jobb å gjøre hver dag: behandle vaksiner, sørge for at de blir sendt, ta imot bestillinger, sende dem ut og så videre.

Måten vi jobbet på, var likevel ganske klassisk produktledelse. Daglige standup-møter, blokkeringer og hindringer. Hva trenger du? Kan noen her hjelpe deg? Kan jeg kontakte noen for deg? Og så videre. Vi hadde også faste møter om bestemte temaer. Når det gjaldt blokkjeden, møttes vi ukentlig.

Hva er neste steg? Neste steg. Vi samarbeidet med et team hos FedEx-hovedkontoret i Memphis og med teamet her i Canada. Bill utviklet faktisk hele prosessen. Vi satte sammen en rekke forsendelser: flere til samme sted, flere til forskjellige steder, med kryssinger, omfordelinger og andre bevegelser.

Vi ser fortsatt på en internasjonal variant. FedEx må finne ut hvordan sensorene deres fungerer på noen av disse stedene. Det ser vi fortsatt på, fordi det internasjonale aspektet er svært interessant.

Galen Low: Kan du si litt om forholdet til FedEx?

Martin Gelb: Ja, absolutt. Vi fikk møte teknologidirektøren i FedEx. Bill og jeg møtte ham på blokkjede-konferansen til Don Tapscott for en stund siden. En fantastisk person, og han snakket svært varmt om dette, fordi det er viktig for denne typen materialer.

Bananer er selvsagt viktige, og T-skjorter og caps er viktige, men disse produktene har mange kriterier som må opprettholdes, ikke bare når de står stille, men også under transport og ved levering.

Det finnes en omfattende kvalitetssikringsprosess før produktene i det hele tatt fordeles og legges på lager. Alt dette må dokumenteres. Til syvende og sist handler hovedboken om nettopp hovedboken. Hovedbøker er ikke noe nytt; mennesker førte hovedbøker i oldtiden. Men nå har vi stor datakraft, svært intelligente mennesker og fantastiske nettverk, så vi kan gjøre mye spennende med hovedbøker. Det er det en blokkjede er.

Når du flytter materialer gjennom prosessen, eller egentlig hva som helst, og ulike parter berører dem, legger til noe, tar bort noe eller gjør noe med dem, flyttes de videre i kjeden.

Materialet har beholdt sin integritet gjennom hele prosessen. De numeriske verdiene som legges til, er ikke selve materialet. Men ved slutten av prosessen vet du hva som skjedde fra begynnelse til slutt, og du kan låse det fast. Denne uforanderlige hovedboken og sporbarheten er uvurderlig.

Særlig når du snakker om materialer som dette.

Bill Moroz: Jeg mener det finnes uttalelser om, jeg vet ikke om det var FedEx eller en annen transportør, at dataene er like viktige som, om ikke viktigere enn, det som faktisk ligger i esken. Det er datadrevet.

Martin Gelb: Det er mottoet deres, og jeg er enig. For personen i dette tilfellet er det selvsagt viktig å få vaksinen inn i armen. Men de får ikke vaksinen i armen hvis vi ikke gjør jobben vår, hvis vi ikke vet at vi leverte den, og at integriteten ble opprettholdt. Det er den viktigste delen.

Bill Moroz: For vaksiner handler det om kjølekjeden. Dette er offentlig kjent. Vaksinene må oppbevares ved minus 200 grader eller en annen helt utrolig temperatur.

Martin Gelb: Det avhenger av produktet. La oss ikke gå inn i alle detaljene her. Det vi ønsker, er å kunne forstå prosessen. Vi har samarbeidet med FedEx helt fra begynnelsen. De er en svært god samarbeidspartner. Vi har et godt forhold til dem og teamet deres.

Så får vi se hvor dette går. For meg er dette en punktløsning, og alle disse tingene er punktløsninger. Blokkjede er en fantastisk teknologi, og mange har tro på den og prøver fortsatt å finne forretningsanvendelser. Det avgjørende er hvor du kan bruke den til å spare eller tjene penger.

Det er de to tingene vi gjør med produkter: Vi sparer penger eller tjener penger. For oss handler blokkjeden om å spare tid og penger, og om å sikre dataene våre. Dataene er alt vi har.

Vi kan nå samle inn det meste av dette asynkront, men det er ikke optimalt. Når du oppdager at noe har endret seg tidligere i prosessen på grunn av en e-post eller noe annet, blir det vanskelig. Jeg overdriver litt – det meste kommer fra systemet – men noe skjer fortsatt asynkront. Vi vil selvsagt synkronisere transaksjonene etter hvert som de beveger seg nedover i kjeden, og kunne spore dem tilbake.

I offentlig sektor har vi revisoren. Revisoren kommer og spør: Hvor er alt dette? Hva gjorde dere her? Hva gjorde dere der? Da kan vi vise til den uforanderlige hovedboken og si: Her er den blokkjedeforankrede dokumentasjonen.

Bill Moroz: Canadas riksrevisor er overalt, og av alle de riktige grunnene. Plattformen må oppfylle revisjonskravene.

Martin Gelb: Dette er en god idé vi har kommet frem til. Når man snakker om revisjoner, hører revisjon og blokkjede naturlig sammen. I offentlig sektor er det ofte svart eller hvitt: Du gjorde det du sa du skulle gjøre, eller så gjorde du det ikke. Det finnes ingen mellomting.

Galen Low: På en måte var dette den ultimate utfordringen. Det var ikke bare en rask utfordring med høy risiko som dere måtte håndtere, men også noe som krevde logistikk, sanntidsdata, svært nøyaktige data og et brukergrensesnitt som gjorde det mulig for et mindre og mer effektivt team å arbeide med svært høy risiko og stor virksomhetskritisk betydning.

Det var en utfordring. Men som dere sier, finnes det mange bruksområder, fordi dere har implementert dette i en så stor skala og under så grundig kontroll. Slik jeg forstår det, er dette et av de tidlige blokkjedeprosjektene når det gjelder blokkjedeløsninger i denne størrelsesordenen.

Nå som alt dette er avklart, finnes det mange muligheter for å bruke det til andre ting, som revisjonsspor for andre prosesser og alt som krever synlighet og åpenhet i en prosess, en dataoverføring eller en vareoverføring.

Det var et øyeblikk med svært stressende innovasjon.

Martin Gelb: Vi tenkte ikke på det slik. Det var nesten zen, Galen, fordi vi bokstavelig talt bygget flyet mens vi fløy det. Vi tenkte: Hvilken ståltråd og hvilken gaffatape kan vi bruke nå?

Jeg overdriver, men vi hadde mange gode ressurser, et godt utviklingsteam og mange dyktige prosjekt- og støttefolk. Kjerneteamet vårt hadde også noen svært gode analytikere, datamennesker og støttepersoner.

Det er en laginnsats. Dette skjer ikke uten mange mennesker som er virkelig dedikerte. Til syvende og sist handler det om tjeneste. Selvfølgelig får vi lønn, men jeg mener folk presterte langt over det man kunne forvente.

Bill Moroz: Igjen handler det om å gjøre en forskjell for Canada. Det er en sterk motivasjon, fordi vi alle var her av de riktige grunnene. Dessverre hadde vi et par personer som ikke trakk i samme retning, og de har kommet og gått.

Men hovedbudskapet er at vi er her for å gjøre en forskjell og få jobben gjort, fordi dette er virksomhetskritisk. Menneskers liv står på spill. Kanadiernes liv står på spill. Det er en av de viktigste motivasjonene.

Det handler egentlig ikke om vaksiner, men om produkter. Det handler om produktsentrering gjennom en produktkatalog som trenger et ordrebehandlingssystem, et system for ordreoppfyllelse og et rapporteringslag.

La oss gjøre teknologien mer forståelig for ikke-tekniske mennesker. Ved hjelp av plattformen vår kan produkter som må håndteres, leveres og oppfylles, styres. Uavhengig av hvilken teknologisk plattform vi bruker, og hvordan rapporteringen foregår, handler det om å få ting til riktig sted, til riktig tid, med integritet og kvalitet.

Galen Low: Det liker jeg. Og er ikke dette selve kjernen i digitale produkter og digitale prosjekter: integrasjonen av teknologi, noen ganger ny teknologi, forretningslaget – eller i dette tilfellet interessentene i offentlig sektor – og brukerne som faktisk skal samhandle med dette for å få jobben gjort og prosessen til å fungere?

Jeg lurer likevel på utfordringene. Martin, du sa at dere bygget flyet mens dere fløy det, og at folk jobbet svært hardt. Kan du fortelle om utbrenthet i teamet og hvordan dere håndterte det?

Martin Gelb: Jeg skal være ærlig med deg: Jeg er utbrent nå. Jeg har jobbet i to år med 120 prosent innsats. Jeg skal ta litt fri etter dette, men etaten har vært svært god mot oss. De sendte alle som hadde jobbet med pandemiresponsen, på et to ukers dekompresjonsprogram, som var virtuelt.

Det omfattet rådgivning og terapi fra en tredjepart. Du var sammen med kolleger fra hele etaten, mennesker du kanskje ikke kjente. Jeg kjente ingen i gruppen min, men det var fantastisk. Det tok opp mange ting. Jeg sørget for at alle på teamet mitt deltok. Jeg skulle egentlig ikke bli med, men alle kom tilbake og sa omtrent: «Dette er som Fight Club. Vi kan ikke snakke om det, men du må delta.»

Bill Moroz: Men du må delta.

Martin Gelb: Og de hadde rett. Det var fantastisk. Jeg tror aldri jeg har hatt en arbeidsgiver som gjorde noe slikt for meg, men det viste at ledelsen forsto at folk faktisk var i ferd med å falle fra.

Vi så det komme. Bill og jeg har vært rundt kvartalet mer enn én gang. Vi snakket om det og så det hos menneskene rundt oss allerede etter omtrent ett år. Noen viste tydelige tegn. Jeg har alltid følt at jeg kunne presse meg gjennom mange situasjoner, men det går ikke over så lang tid. Du kan ofre deg selv i en periode, men etter to år fant jeg ut at grensen min var nådd.

Så jeg trenger litt tid til å fiske. Når det gjelder å bygge teamet virtuelt og finne de riktige menneskene, var Bill den rette personen. Vi fant en erfaren analytiker. Jeg leste noen notater fra et annet møte og spurte hvem som hadde skrevet dem. Hun var der, og vi fant støttepersoner, sikkerhetsfolk og førstelinjestøtte for ting som glemt passord.

Deretter eskaleres saker til et miljø med administrerte tjenester og profesjonelle administrerte tjenester. Alt utover det går videre oppover. Dette har også blitt gjennomført svært godt.

Vi har en leverandørstyringsfunksjon som hjelper oss med å styre systemintegratoren og andre avtaler for data og andre ting. De hjelper oss også med anskaffelser som må gjennomføres i offentlig sektor. Man kan selvsagt ikke bare kjøpe et program og installere det. Det må anskaffes, vanligvis gjennom en formell prosess.

Teamet har skrevet mange dokumenter om forretningskrav og lignende. Vi har gode ressurser rundt dette. Som du sa i begynnelsen, Galen, er jeg en produktleder som liker å skrive. Jeg liker faktisk å skrive forretningskrav og gjøre dem om til en form for design, før vi får alle til å bli enige om det.

Deretter går vi til utviklerne og forsøker å oversette det til utviklerspråk og avgrensede arbeidsoppgaver. Hva er akseptansekriteriene? Vi får dem til å arbeide med dette, og så går vi opp og ned i kjeden igjen. Det er en kontinuerlig prosess.

Vi har daglige standup-møter, individuelle møter om bestemte temaer og jevnlige presentasjoner av alt vi arbeider med. Brukerakseptansetesting er selvsagt en stor begivenhet i kalenderen. Ved hver utgivelse er endringsledelse en viktig del. Hvis jeg skulle si én ting til en produktleder som ikke ønsker å høre på, ville jeg sagt: Vær oppmerksom på endringsledelsen.

Hvis du er produktleder og kan forretningskrav, må du også ta hensyn til endringsledelsen for brukerne og for menneskene som faktisk har anskaffet løsningen, enten det er i næringslivet eller offentlig sektor. Sørg for at ledelsen forstår hvordan dette skal innføres, at brukerne forstår hvordan det skal innføres og hvordan det påvirker hverdagen deres, og gjør det så enkelt som mulig for dem.

Mye av det som skjer, er at løsningen bare blir levert og dumpet på folk. Jeg har sett dette mange ganger. Ledelsen har kjøpt inn noe, en ny versjon eller et nytt program, og så blir det lagt foran brukerne. De spør: «Hva skal jeg gjøre med dette?» De har brukt regneark i 30 år eller hatt sin egen metode, sin egen måte og sine egne verktøy.

Hvis du kommer langt nok i forkant av dette, vil det hjelpe deg enormt med å lykkes med produktet. Jeg kan ikke understreke dette sterkt nok.

Bill Moroz: Det er her gummien møter veien. Det kalles innføring, men det handler ikke bare om innføring. Det handler også om varig bruk. Det er svært viktig. Jeg har sett miljøer der et nytt system lanseres, og alle sier at det er flott, men så fortsetter de å bruke regnearkene etter arbeidstid eller tidlig om morgenen. Du ser dem ikke, fordi de bruker det nye systemet, men under pulten ligger regnearkene fortsatt.

Det er verst tenkelige scenario. Du tar ikke i bruk endringen og gjør den ikke til den nye og bedre måten å arbeide på. Vi har mange arbeidsmøter og avklaringsmøter, men de må alltid ha en positiv innstilling.

Dette er ikke bare enda et møte. Det er en arbeidsøkt, og dette er det vi skal oppnå. Når vi kan si at vi oppnådde det, er alle stolte, og vi fortsetter fremover. Hvis du går inn med holdningen «enda et møte, jeg har ti møter i dag og er sliten», blir arbeidsmengden overveldende og kan føre til utbrenthet.

Eller du kobler deg fra. Noen koblet seg fra og bestemte seg for at dette ikke var noe for dem. Det ble for mye. Det må man respektere, men vi må fortsette fremover.

En kritisk suksessfaktor er erfaring. Martin og jeg har vært i mange forskjellige miljøer, med mange forskjellige kunder og plattformer. Når vi legger sammen erfaringen vår, og tar med lærdommer fra det som gikk bra og det som mislyktes, ulike metoder og alle menneskene vi har jobbet med de siste 20–30 årene, har dette ført oss til et høydepunkt i hvordan vi fikk dette til og fortsatt gjør det vellykket i Canadas offentlige sektor.

Galen Low: Jeg liker det. Riktig team. Riktig holdning. Et stort oppdrag.

Martin Gelb: Det handler likevel om teamet. Jeg kan ikke understreke det nok. Dette skjer ikke uten de riktige menneskene og de riktige holdningene. Alle her er svært motiverte.

Bill Moroz: Noen ganger får vi det til å se enkelt ut, men det er ikke enkelt.

Martin Gelb: Det er det profesjonelle gjør, Bill. De profesjonelle får det til å se enkelt ut. Har du sett disse menneskene slå 300-metersslag i golf? Det ser ut som de bare er ute på en spasertur.

Galen Low: Der har du det. Det er dette som kjennetegner det digitale. Vi har fått det til å se for enkelt ut. Når folk snakker om teknologi, tror de det handler om å trykke på en knapp, fordi mennesker som dere og teamene deres faktisk har fått det til å se enkelt ut.

Martin Gelb: Det er et interessant poeng, Galen. Digital kompetanse er en stor utfordring, ikke bare i offentlig sektor, men overalt, også i næringslivet og til og med noen ganger innen teknologi.

Galen Low: Hvordan lærer dere opp interessentene rundt dere? Når dere arbeider raskt og må forklare noe, hva er metoden dere bruker for å få folk til å forstå hva teknologien kan og ikke kan gjøre?

Martin Gelb: Jeg spør dem hva problemet er. Jeg sier ikke akkurat «Hva er problemet ditt?», men jeg spør hvilket problem de har som de tror vi kan løse.

Så snakker de og sier: «Integrer dette og integrer det.» Da sier jeg: «Ikke fortell meg hvordan det skal løses. Fortell meg hva problemet er.»

Egentlig kan jeg gjøre det enda enklere: Hvilke rapporter ønsker du å se? Hvilke data vil du se presentert, og hvordan? Det kan de vanligvis beskrive. Hvis du stiller nok spørsmål, kan du takke dem og gå tilbake og omvendt utvikle dette til programvarekrav.

Mye av problemet deres finnes kanskje allerede internt, og du kan presentere det for dem på en eller annen måte. Men du kan også måtte gjøre en del arbeid. Vi er svært heldige som har en person på teamet som faktisk er del av driftsgruppen, men som i praksis er en del av teamet vårt.

Han er vår mentale kobling til det nasjonale driftssenteret. Han er en flott person, og vi er svært glade i ham. Vi hadde en person som ham tidligere også. Dette er kritisk: Hvis du kan ha en superbruker som faktisk er en del av teamet ditt, er det som nirvana for en produktleder.

Jeg sørget for at vi hadde dette, for det er ingen måte å få jobben gjort på en rimelig måte uten det. Vi sitter ikke i driftssenteret, så vi trenger disse øynene på prosessen.

Noen ganger klarer de ikke å formulere problemet tydelig, men de kan vanligvis forklare hva de ønsker å se, for eksempel i en rapport eller en form for informasjon. Det kan vi arbeide med. Det er ikke alltid enkelt, fordi man ofte må gå tilbake og få avklaringer, men vi kan vanligvis komme frem til et design og drive det videre derfra.

Det er i hovedsak prosessen vår. Vi har ikke oppfunnet dette. Det er en blanding av alt fra pragmatisk markedsføring til Marty Cagan og Silicon Valley. Vi prøver bare å håndtere forventninger, fokusere på data, gjøre det vi vet vi kan gjøre og være svært kundeorienterte.

Det er alt du kan gjøre som produktleder. Hvis du har støtte fra ledelsen, en god superbruker hos kunden og støtte innen utvikling, sikkerhet, tilgjengelighet og alle andre hensyn i produktet, er du i en god situasjon.

Vi var i en svært god situasjon lenge. Jeg er sikker på at lytterne dine har sett budsjettet som nylig ble lagt frem. Det var ikke det folk forventet, i hvert fall ikke innen helse. Det blir trolig noen kutt, og de må prioritere svært hardt hva de vil bygge og fortsette å bruke dette til.

Det virkelige fokuset nå er at vi ble tatt på sengen, og det samme gjorde alle andre. Ingen var klare for det som skjedde, og vi ble svært avhengige av utenlandske ressurser. Dette er selvsagt bekymringsfullt. Det fantes ikke noe system og ingen forsyningskjede.

Beredskap og forberedelse er derfor avgjørende. Forhåpentligvis skjer ikke dette igjen i vår levetid, men man vet aldri. Pandemien var fullt ut forutsagt, og vi var ikke klare. La oss ikke gjøre den feilen igjen. Vi må sørge for at vi er klare neste gang, og at barn, barnebarn og deres barn blir beskyttet.

Jeg sier ikke at S/4HANA nødvendigvis skal eksistere for alltid. Poenget er ikke programvaren, men selve konseptet beredskap og hva det innebærer.

Bill Moroz: Det handler om økosystemet, beredskapen og forberedelsene, og om å være plattformuavhengig. Vi må være smidige i beredskapen og sørge for at det finnes en standardisert, normalisert og samhandlende plattform som er klar til å reagere på det som måtte skje.

Martin Gelb: Hold teknologien moderne, og fortsett å iterere. Men ikke i det tempoet vi hadde. Vi har allerede lansert én versjon siden 2.0, og en ny kommer i juni, med enda en etter det. Vi kommer opp til 2.3 under covid-budsjettet. Det blir faktisk et ganske imponerende system.

Det finnes alltid mer som kan gjøres. Det er noe folk ikke forstår: «Når er det ferdig?» Det blir aldri ferdig. Det er et programvaresystem. Du kan alltid legge til noe. Det finnes etterspørselsplanlegging, prognoser, full sporing, produktserialisering og mye mer.

Du kan bygge ut systemet så mye du vil. Må du det? Det vet jeg ikke. Jeg er ikke den som skal svare på det, men jeg vil anbefale at du følger med på det og holder det klart, i stedet for å legge det på hylla.

Galen Low: Du kommer med et godt poeng, særlig når det gjelder budsjetter. Vil dette bli brutalt nedprioritert fordi pandemien er over? Eller skal man tenke at beredskap betyr å holde ting oppdatert og fortsette å forbedre dem, slik at vi er klare neste gang? Det er ikke alltid enkelt å selge inn når man snakker om et nasjonalt budsjett.

Et siste spørsmål. Jeg vil rette det til Bill. Vi snakket tidligere om smidig utvikling i offentlig sektor. Dette var en presset spesialsituasjon, som selvsagt fortsatt krevde aktsomhet, men i høyt tempo.

Med noen unntak fra hvordan ting vanligvis fungerer. Føler du at dette prosjektet har bidratt til å bygge opp evnen i den kanadiske staten til å gjennomføre prosjekter på en smidig måte? Har det utviklet forståelsen hos de involverte for hvordan man arbeider iterativt og inkluderer kundens stemme i de daglige standup-møtene? Hva tror du vil fortsette? Eller var dette bare et engangstilfelle?

Bill Moroz: Definitivt ja. Dette er et eksempel på en metode som kan overføres og brukes igjen til leveranser, fordi alt handler om å levere. Jeg kan ikke svare på om det vil fortsette, fordi det drives av menneskene.

Smidig utvikling eies av menneskene som bruker den. Den defineres forskjellig i hver organisasjon. Hvis du omfavner den, konseptene, avhengigheten av kommunikasjon, effektivitet, spontanitet, kreativitet, lytting og feiring av de raske seirene, så er svaret absolutt ja.

Jeg ønsker å se dette fortsette i offentlig sektor. Det er morsomt, det er alvorlig, og til syvende og sist leverer det. Det leverer sammen med teamet som gjorde det mulig. I vårt tilfelle er vi villige til å gjøre det igjen, med det samme teamet og på samme måte, fordi det skaper fremdrift.

Galen Low: Det liker jeg. Flott. Martin og Bill – tusen takk for innsiktene deres i dag. Det har vært en stor glede å ha dere begge med i programmet. Takk for at dere kom og delte historien deres. Jeg vil gjerne ha dere tilbake, og kanskje også få dere med i fellesskapet vårt, for dem som lytter og har flere spørsmål om prosjektet, hvordan det fungerte, utfordringene dere møtte og hvordan dere overvant dem.

Martin Gelb: Takk, Galen. Det har vært flott å kunne fortelle historien vår. Jeg vet ikke om den noen gang vil bli fortalt offisielt, men det var en utrolig reise for både Bill og meg. Jeg kunne ikke vært stoltere av teamet eller mer takknemlig for muligheten til å tjene landet vårt.

Galen Low: En stor takk til dere og teamet. De usungne heltene – disse historiene blir ikke fortalt så ofte. Men det står mange mennesker bak dette og sørger for at vi alle er trygge.

Bill Moroz: Takk.

Galen Low: Da har dere det, folkens. Som alltid: Hvis du vil delta i samtalen med over tusen likesinnede forkjempere for prosjektledelse, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for å lære mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com.

Til neste gang: Takk for at du lyttet.