Lyd og tekst fra en samtale om digitalisering og toppledere

Torsdag 14. november i år var jeg med på et EGN-webinar sammen med Berit Svendsen og Ingvild Huseby. Fokus var digitalisering og AI og hvordan dette kommuniseres og diskuteres innad i toppledelsen og styret i bedrifter rundt omkring. Her er webinaret i form av en lydfil, gjengitt med tillatelse av EGN, som man kan avnyte i bil, airpods, buss eller hvor som helst ellers. Hvis du vil se videoen, finner du den her.

Her er en oversikt over innholdet:
00:00 Jingle og min intro
01:40 Haakon Gellein introduserer
03:30 Ingvild Huseby introduserer om manglende samspill styre-toppleder om digitalisering, med kommentarer fra Espen og Berit om manglende endringskompetanse
08:30 Over til Berit sine erfaringer med teknologiendring i Telenor – fokuser på hva som endres.
10:00 Ingvild om teknologiutvikling
11:20 Espen om behovet for teknologiforståelse (henviser til denne artikkelen.)
13:45 Ingvild innleder til diskusjon
14:25 Berit (og andre) om sin teknologireise og hvordan hun holder seg oppdatert, behovet for eksperimentering, teknologisk nysgjerrighet. Hvor mye teknologi skal toppledelsen kunne? Organisasjonen vet ofte svaret, slipp frem de ansatte, still spørsmål til organisasjonen. «Ikke noe som sprer så mye mørke som en leder som har sett lyset.» Blandet erfaring med norske styrer, mange trenger en digital oppgradering – men de må erkjenne det og finne kunnskapskilder.
20:45 Espen og Berit om alder, teknologi, forretningsmodeller. Om data og hva vi kan gjøre med dem, fra et topplederperspektiv, om nye kommunikasjonskanaler.
23:30 Espen om maskinlæring og hva man trenger å kunne om det – «hvis du tror du har data, så har du ikke det». Ingvild: Nok kunnskaper til å stille de riktige spørsmålene.
24:45 Ingvild om disrupsjon og kortsiktighet vs. langsiktighet. Berit kommenterer fra sin erfaring – sette av ressurser til innovasjon, styrets rolle å etterspørre.
27:30 Over til spørsmål fra tilhørerne: Hvordan selge inn innovasjon på styrerommet? Espen: Mange innovasjonsmetoder å velge i, lag en portefølje. Må normalisere innovasjon, og lære av feil. Schibsted som eksempel på noen som brukte ressurser på eksperimentering. Ingvild: Tonen fra toppen ekstremt viktig, viktig å ha et overordnet perspektiv.
30:50 Berit: Tillit får man ved å levere på det eksisterende, da kan man innovere. Må klare begge deler. Over til Vipps – hva gjør de der? Viktig å ha radikale prosjekter, ikke sette seg i bås, tenk ut fra hva du kan gjøre for kundene? Litt om Vipps historie og hvordan dette ble kommunisert til styret.
35:30 Avstemning til tilhørerne: Hvem de er og så videre. Espen om Jotun Hull Performance Systems, eksempel på å ta noe standard og gjøre det digitalt. (Ref. denne artikkelen.)
37:30 Hvordan komme i gang – snakk med kunden, særlig de som ikke har råd til det du tilbyr.
39:00 Informasjon om de som hører på, og nytt spørsmål til dem.
40:00 Hva er beste praksis for innovasjon? Mange metoder, men gjør det selv.
41:40 Berit: Begynn i det små, ha flere prosjekter som rapporterer direkte til toppledelsen. Har erfaring med ting som har gått galt (stort prosjekt der alt hver avhengig av alt), lærte at man må stoppe i tide hvis man gjør feil. Vipps var litt det samme: Måtte fort ut, ble litt ruskete. «Scale fast, fail faster». Espen: Ny teknologi er lett og billig, det må prosjektene være også.
45:15 Spm: Hva med yngre ledere? Berit: Råd til unge: Ikke avfinn dere med at noen sier «Dette har vi prøvd før», ikke la dere stoppe. Ingvild: Ikke sikkert de trenger å være i styret, men innovasjonsperspektivet må til. Berit: Lær dere bransjer, og digitalisering. Espen: Tenk gjennom hva du kan gjøre kontinuerlig i stedet for periodisk, hva kan du gjøre for individer der du før tenkte grupper.
51:00 Ingvild: Tilbake til styret og deres rolle? Espen: Må endre hva det snakkes om, begynn med teknologien i stedet for regnskapet. Ingvild: Ikke alltid de riktige spørsmålene, særlig rundt disrupsjon og nye forretningsmodeller. Espen: Tok oljeselskap gjennom en norsk hverdag med elbiler og kollektivtransport.
54:45 Hvordan rekruttere dette inn i styrer? Berit: Bransjekunnskap viktig, lære av de som er langt fremme, f.eks. hvordan kombinere fysisk handel med netthandel. Hvis du ser noe i et vindu og butikken er stengt må du kunne gjøre noe med det. Må tenke hvor er kunden, 25% av all handel går utenfor Norge, konkurranse fra hele verden.
57:00 Ingvild: Hva er det viktigste vi må sitte igjen med etter dette seminaret? Espen: Eksperimenter med teknologi, og forstå disrupsjon (konkurranse fra aktører du ikke synes er viktig.) Berit: Tonen fra toppen. Styre og toppleder må være på lag, start omstilling i det små og skaler opp når du får konsistente resultater. Har man ikke kompetanse selv, kan man oppgradere seg for å kunne stille de riktige spørsmålene. Ingvild: Styret må måle toppledere også på det innovative, må hente inn kompetente styremedlemmer.

Og det var det!

Berit Svendsen til BI

Jeg har kjent Berit Svendsen i noen år (hadde henne inne som gjesteforeleser på 90-tallet, for eksempel) og har alltid oppfattet henne som en av Norges fremste teknologiledere. I våres satt jeg i bilen og hørte på radioen at hun skulle slutte i Telenor – og jeg tok øyeblikkelig kontakt med Inge Jan, rektor på BI, og foreslo at vi tilbød henne en eller annen form for tilknytning.

Og nå er hun det – faktisk siden mai – med den ikke særlig norske tittelen Executive in Residence (i tillegg til at hun er utenlandsdirektør i Vipps, naturligvis.) Berit og jeg er opptatt av digitalisering av norske ledere og (hun) særlig norske styrer, og det skal vi faktisk samarbeide om, i første omgang rundt vårt Executive-program Digitalisering for vekst og innovasjon, arrangert i Sophia Antipolis i samarbeid med Accenture.

Mer om dette programmet senere – i første omgang: Fantastisk at dette har latt seg gjøre, og jeg gleder meg til i enda større grad å sette digitalisering på dagsorden sammen med Berit!

Epost og utpressing

Og der fikk også jeg en utpressingsepost, gitt…ransommail.jpg

Og hva skal man gjøre i en sånn situasjon?

Svaret er:

  1. Endre de passordene som det blir referert til (særlig om man bruker det samme passordet flere steder, noe man ikke skal gjøre.)
  2. Innstallere en passordbeskytter a la Lastpass (som jeg bruker, betaler for og er fornøyd med.)
  3. Slette eposten.
  4. Puste ut og tenke på noe annet.

Disse epostene ser ut som om de vet en hel del ting om deg, men egentlig vet de ingenting bortsett fra det ene passordet som de referer til. Dette passordet kommer fra en eller annen webside som du har opprettet en bruker med en eller annen gang, og som deretter har hatt et datainnbrudd og fått stjålet sin passordfil. (Det å ha en ikke-kryptert passordfil er naturligvis et stykke inkompetanse på linje med Bergen Kommune, men det er dessverre nokså vanlig der ute.) Deretter sender man eposter til folk, truer med å avsløre dem som pornografibrukere, håper på napp og betaling i Bitcoin.

Men det er ikke så farlig som det ser ut som*. Så slapp av. Og begynn å ta passord på alvor…

*Hadde det vært et virkelig datainnbrudd i din PC, ville du funnet ut at harddisken din var kryptert og at du måtte betale en masse penger for å få låst den opp igjen. Ikke noe problem hvis du bare har skikkelig backup, men slitsomt ellers. Og nok en grunn til å ta passord og backup seriøst.

Eposter og elæring og falskhet

Fikk denne eposten i innkurven i morges:

xtramile

La meg se: En epost fra «Nasjonal Sikkerhetsmåned» (som jeg ikke har hørt om) som ber meg klikke på en lenke (som går til en annen adresse på domenet «xtramile.no») som jeg ikke vet hva inneholder – for å lære meg at jeg ikke skal klikke på eposter jeg ikke vet hvor kommer fra?

Noen bør ta seg en tenker her – hvis det hele da ikke er hensikten. I så tilfelle: Smart. Omtrent som den gamle historien om at Unix og C egentlig var en spøk som ble trodd…

Er det lov å sparke folk for inkompetanse?

Saken om skoleeleven som fant en fil med 35000 passord, meldte fra, ikke ble hørt, og derfor logget seg inn som en administrator og sendte en tullemelding, er ganske fantastisk. En ting er at man har IT-avdeling/IT-ansvarlige som gjør noe så himmelropende inkompetent som å legge en ikke-kryptert passordfil i en identifiserbar filstruktur. Men en helt annen ting er kommunaldirektørens kommentar:

Trass i at tinga han gjorde i etterkant ikkje er veldig konstruktive, anerkjenner me at han gir oss beskjed.

Konstruktive? Hva skulle han ha gjort?

Mitt spørsmål er: Hva skjer med den eller de IT-ansvarlige, som a) gjorde noe så komplett idiotisk, og b) ikke gjorde noe med det da det ble sagt fra?

Og hva skoleeleven gjelder, tror jeg han skal være glad for at han var under den kriminelle lavalder. Enkelte myndigheter setter ikke pris på å få sin himmelropende inkompetanse avslørt – og jeg er nokså sikker på at han ville blitt disiplinert for «datainnbrudd» eller lignende. Før det ble kjent hva som hadde skjedd, skyldte kommunen på «svakheter i systemet» (leverandøren, med andre ord) og vurderte politisak. (Dette er standard rutine i slike saker, og en av årsakene til at det kan være slitsomt å være leverandør til det offentlige.)

Går det an å sparke folk for inkompetanse og slendrian i Norge? Dette er faktisk ikke ment som et retorisk spørsmål (svaret er ja, det går an, selv i kommunen, men det er vanskelig.) Saken er den at vi har hatt disse systemene i så mange år nå at man faktisk bør kunne forvente alminnelig kunnskap hos administratorer og særlig IT-ansvarlige. Det er nemlig ikke nok å kunne vite at man skal klikke der og skrive der – man må kunne forvente en viss forståelse for hvordan ting ser ut under panseret – og en viss kritisk sans for hva man foretar seg.

Her for noen dager siden kjøpte vi en bok om Båtførerprøven. Den inneholder masse informasjon om regler på sjøen – som man må kunne, og blir testet på – men også generell informasjon om forskjellen på bensin- og dieselmotorer, ulike typer skrog, og så videre. Dette ut fra en forståelse for at man må kunne mer enn bare hvilke knapper man skal trykke på, så man ikke gjør noe plakat idiotisk fordi man ikke forstår hvordan ting henger sammen.

Kanskje på tide med litt «Båtførerprøve» for Bergen Kommunes IT-ansvarlige? Og en desertifisering for de som ikke forstår helt elementære sikkerhetsrutiner?

Nettverksledelse i praksis

join21Herved en invitasjon til noe som i alle fall for meg er noe nytt og spennende: Et ESP (Executive Short Program) kalt Nettverksledelse i praksis som første gang arrangeres på BI 15. mai og 12. juni.

Programmet baserer seg på kartlegging og ledelse av nettverk innen bedrifter – det er nemlig slik at bedrifter (og alle organisasjoner, for den saks skyld) ikke fungerer basert på organisasjonskart, men ved at mennesker snakker sammen. Et viktig element av å få organisasjoner til å fungere og endringer til å skje er å forstå hvordan informasjon flyter og beslutninger tas – og med moderne kartleggings- og analyseverktøy kan man få frem mye interessant.

jantaughenrik-bentzenDette seminaret skjer i samarbeid med Jan Taug og Henrik Bentzen fra Join21, som hjelper organisasjoner og folk å mestre teknologi – ikke minst ved å forstå hvordan (og med hvem) man skal kommunisere for å få til digitalisering. Ragnvald Sannes og jeg skal også være med å undervise og diskutere. Jan og Henrik har lang leder- og analyseerfaring og Ragnvald og jeg ser frem til å jobbe med dem.

Her er en liten videofilm der jeg snakker litt om kurset og viser noen (svært enkle) eksempler på nettverksanalyse. En liten bemerkning før du ser den, bare for å understreke det forretningsmessige: I filmen snakker jeg om nettverk man ikke vet om, som f.eks. mellom røykere eller kvinner – men hvis man tenker mer forretningsmessig på det, kan det være viktig å kartlegge hvem som er informasjonskilder og -formidlere gjennom hverandre, hvem som danner ekspertnettverk, for eksempel. Flere ledere jeg har kjent, ser på epost-trafikken eller de interne kommentarfeltene for å finne ut hvem det er som ikke bare har peiling, men også har kommunikasjonsevne til å hjelpe andre:

Tanken er at vi skal ha en dag først der vi ser på interne nettverk som konsept og hvordan man kan bruke dem. Så blir det noen uker i midten der man samler data fra organisasjonene som deltar, og så en dag med analyse av disse nettverkene og diskusjon om hva den nye forståelsen betyr for ledelse og innovasjon.

Dette er ikke et kurs som i utgangspunktet er beregnet på enkeltpersoner – vi er på jakt etter selskaper som ønsker å delta med flere personer fra ledergruppen. Ta kontakt med Ragnvald, meg, Jan eller Henrik om du er interessert – eller bare meld deg på på kurssiden.

Monsteret i kjelleren

220px-commodore_grace_m-_hopper2c_usn_28covered29I 1959 møttes en gruppe informatikere (tror ikke det het informatikk den gangen, men likevel) i en gruppe kalt CODASYL og laget et programmeringsspråk med navnet COBOL, delvis bygget på andre programmeringsspråk laget av Grace Murray Hopper, kanskje den nest viktigste kvinnen i datahistorien (etter Ada Lovelace).

Hele ideen med COBOL var at programmeringsspråk skulle være bygget på vanlig (engelsk) språk, slik at «vanlige» mennesker skulle kunne lese dem og bruke dem. Slik har det i grunnen aldri blitt, men tanken har vært der lenge. COBOL skulle kunne kjøres på mange ulike maskiner (før det kom, hadde man en tendens til at hver maskinleverandør hadde sine egne programmeringsspråk, men nå fikk man i stedet COBOL, om enn med litt ulike dialekter.)

COBOL (som står for Common Business-Oriented Language) ble tatt i bruk av mange bedrifter til administrative systemer, dels fordi det lignet engelsk, delvis fordi det var bra til å lese inn data, gjøre relativt enkle ting, og deretter spytte ut utskrifter. I motsetning til mange senere programmeringsspråk skilte COBOL og akademia lag – noe som førte til at språket fikk relativt lite utvikling utover tilpasning til nye maskiner. Opplæringen skjedde utenom universiteter og utenfor den faglig baserte informatikken. Etterhvert skilte også programmering lag – forretningssystemer ble skrevet i COBOL, mens akademisk orienterte systemer og etterhvert mer generell systemutvikling gikk gjennom en rekke ulike språk (C, Basic, Pascal, C++, SmallTalk, LISP, VisualBasic, Perl, Python, for å nevne noen.)

De første systemene som ble laget for bedrifter var systemer for repetitive oppgaver som regnskap, lønnsutbetaling og fakturering, og disse ble gjerne programmert i COBOL. Etterhvert førte det til at flere og flere bedrifter fikk en arkitektur der kjernesystemene var laget i COBOL og sto relativt stille (først fordi de gjorde standardiserte ting, etterhvert fordi det ble stadig mer vanskelig å finne programmerere som kunne COBOL, noe som gjorde at det ble dyrt og kronglete å få endret noe.) Riktignok flyttet en hel del bedrifter, særlig produksjonsbedrifter, sine systemer over ERP-systemet SAP i løpet av 90-tallet, men for mange nettverksbedrifter (banker, forsikringsselskap, transport, etc.) er stadig kjernesystemene skrevet i COBOL, og kjøres gjerne også på en stormaskin, typisk fra IBM.

2002_03_11_cobol300_3-11-02-100717557-origDette har vært et problem lenge – jeg har rådet bedrifter til å kvitte seg med kjernesystemene sine, om nødvendig ved å skrive dem helt om, i hvert fall i 20 år. Men de fleste bedrifter har ikke gjort det, og nå begynner problemet å nå kritiske dimensjoner. Helt fra slutten av 90-tallet har unge mennesker vegret seg for å lære seg et 30 år gammelt programmeringsspråk som bare brukes til kjedelige bakgrunnsprogrammer. Mange bedrifter løste dette ved å outsource vedlikehold og oppdatering til selskaper i andre land, for det meste India. Tilbake i bedriften er det færre og færre, om noen, som egentlig forstår hvordan de gamle systemene fungerer.

Da får man en situasjon der all innovasjon skjer i ulike typer småsystemer som ligger rundt og interagerer med det gamle kjernesystemet, uten at man gjør noe med selve kjernen. Det går greit så lenge forretningen man driver er stabil, men med økende konkurranse fra digitale bedrifter som ikke har en mange millioners møllestein på maskinrommet kan det blir farlig. Jeg hørt om bedrifter som ikke tør slå av sine systemer av redsel for at de ikke kommer til å starte igjen, og systemer der den eneste tilgangen man har til dataene er gjennom brukergrensesnittet – slik at skal man hente dataene ut, er man nødt til å gå inn på hver eneste rad i databasen og kopiere den ut manuelt (en grunn til at RPA er så populært.)

Mange bedrifter med flotte websider er rett og slett slott bygget på svært råtne fundamenter, en slags informatikkens permafrost som ingen tør å tine opp av redsel for hva som kommer til å stige opp, av metangass og annet. Det man burde gjøre, naturligvis, er å starte helt på nytt igjen, men siden man har hundre- eller kanskje tusenvis av systemer og APIer og innganger som bruker det gamle monsteret i kjelleren, er det ingen som engang tør å tenke tanken. For ikke å snakke om at det blir dyrt, og synliggjør mange års manglende vedlikehold og underinvestering.

Jeg tipper at en hel del banker, for eksempel, kommer til å få det morsomt når PSD2 kommer og de blir nødt til å slippe til andre aktører inn mot sine systemer. Da vil antallet transaksjoner mangedobles og de gamle systemene ganske enkelt ikke henge med, uansett hvor mange servere man kjøper. Vi går spennende tider i møte, og jeg er i grunnen litt forundret at ikke flere styrer og investorer begynner å stille kritiske spørsmål til firmaers informasjonsarkitektur og tekniske plattform.

Kanskje på tide å begynne? Tips: Hvis det fortsatt finnes COBOL i organisasjonen, er det grunn til bekymring, i alle fall hvis det tar tid å gjøre endringer og man fremdeles har pensjonister igjen som konsulenter i IT-avdelingen…