Jeg vil ha en sånn!

Her i familien har vi en gammel firehjulstrekker (en Mercedes ML320 fra 2003) til å dra hageavfall og annet med. (Den har vært kommandobil for Vestre Viken helsedistrikt, så vi kaller den bare «kommandobilen».) Den er grei nok, men som med alle fossilbiler har den en komplisert arkitektur og mange delsystemer som kan slå feil. Jeg har tenkt å ha den 3-4 år til, til det kommer elbiler som har kombinasjonen hengerfeste og enkelhet. (Jada, Tesla X, men den er dyr og jeg synes bakdørene er overkompliserte.)

Og nå ser det ut til at det begynner å skje: Ta en kikk på Bollinger B1, som er en av de første elektriske 4×4-bilene jeg har sett som er bygget som elbil fra grunnen av. Her er et lite innslag med Rob Llewellyn:

Jeg er særlig fascinert av at man kan lage en tunnel tvers gjennom hele bilen for lange gjenstander.

Nå vet jeg i alle fall hva jeg skal ønske meg som leketøy om en tre-fire års tid….

Kunnskapsrepresentasjon

Fredag var jeg på «toppmøte» om digitalisering, et møte der regjeringsmedlemmer (8 ministre på hvert sitt bord), universitetsrektorer, og andre samfunnstopper diskuterte digitalisering i Norge, primært rundt offentlig sektor. Det var innledende presentasjoner av Camilla Tepfers, Morten Dæhlen, Camilla Serck-Hanssen og Hege Skryseth. Gjennomgangstemaene var de det pleier å være: Vi mangler digital kompetanse, mangler tverrfaglighet (i mange dimensjoner) og skal det skje noe i offentlig sektor må vi rive eller i alle fall forbinde siloene.

Jeg fikk mye å tenke på og skrive om – og mitt hovedinntrykk er at vi vet hva vi skal gjøre, men vi gjør det bare ikke.

Nok om det. I denne omgang skal jeg ta for meg noe mer spesifikt, nemlig kunnskapsrepresentasjon.

Morten hadde et utmerket innlegg som han har delt på mat-nats blogg, og der hadde han dette som et av fire hovedpunkter:

Digital representasjon og visualisering. Behovet for kunnskap om digital representasjon av kunnskap synes å være undervurdert, men dette området er i vekst, noe som i all hovedsak skyldes dataeksplosjonen. Kunnskap om hvordan digitale representasjoner presenteres og visualiseres er også en vesentlig del av dette.

Jeg kunne ikke vært mer enig, men hva betyr egentlig digital representasjon og visualisering? Ved første øyekast kan det se ut som evnen til å lage delikate fremstillinger av data, som for eksempel Hans Roslings fantastiske TED-foredrag. Men egentlig betyr uttrykket mer å klare å gjøre data tilgjengelig i en form som datamaskiner kan behandle.

Wikipedia beskriver knowledge representation and reasoning som «the field of artificial intelligence (AI) dedicated to representing information about the world in a form that a computer system can utilize to solve complex tasks». Er det en ting jeg har funnet ut ved å undervise kurs i strategisk dataanalyse, så er det at det å få dataene inn i en form og med et innhold der man faktisk kan gjøre noe med dem er kanskje den nest største vanskeligheten. (Den største er å formulere spørsmål som faktisk lar seg besvare, mer om det en annen gang.)

La oss ta et helt banalt eksempel: Sett at du underviser et kurs (som jeg ofte gjør) og du skal lage deg et regneark for å holde orden på studentene. Du ber administrasjonen om en liste over hvem som er med i kurset, og får et regneark eller en tabell som ser slik ut:

hogwarts

Utmerket, i og for seg. Men vent litt – hva om jeg har lyst til sortere studentene alfabetisk på etternavn, eller å lage navneskilt til studentene med fornavnet på en linje og etternavnet under? Da er det ganske klart at kolonne B ikke er satt opp for dette, siden for- og etternavn ikke er adskilt. Hvis jeg skal gjøre det, må jeg enten gå gjennom alle studentene og manuelt skille for- og etternavn (tidkrevende og kjedelig), eller skrive en liten makro som gjør det automatisk. Den siste løsningen introduserer feilkilder: En av Harry Potters medstudenter hetter «Choo Chang» og omtales som Choo, men egentlig burde hun jo vært «Chang Choo» siden navnet er aseatisk. For ikke å snakke om studenter med navn som «Jose Maria Casiento Gomez-Caseres de Monteleon», hvor det ikke er helt enkelt å finne ut hva man skal kalle dem.

Og her er vi fremme ved hva kunnskapsrepresentasjon er – hvordan gjør man data tilgjengelig slik at man kan bruke det til noe, uten at man på forhånd vet hva dette «noe» er?

Dette er vanskeligere enn man tror, og har å gjøre med informasjonsarkitektur, databasestrukturer, metadata, APIer og masse annet morsomt. Men bare ha dette lille eksempelet i mente, så har du i alle fall litt av den digitale kompetansen Morten etterlyser…

Freelancerens innstilling og verktøykasse

praxis-architectureJeg er ikke freelancer, men jeg har to jobber (en 100% – i praksis 200% – og en på 20%), to styreverv med tidvis svært mye involvering, leder to EGN-nettverksgrupper og snart en til, har en haug foredrag og et og annet konsulentoppdrag. Dessuten tror noen at jeg er teaterkritiker.

Så jeg føler meg litt som et enmannsfirma, en frilanser med noen lange oppdrag. Det er smart å tenke slik – man får litt selvtillit, man er ikke så avhengig av enkeltinstitusjoners vingling hit og dit, og man kan velge sine verktøy selv. (Det siste blir man som regel nødt til, ellers får man lite gjort.)

Og det er jo ikke bildet på en verdensfjern akademiker, er det vel – jeg sitter ikke på kontoret og graver meg ned i dybden i en ting, selv om jeg har en pågående fantasi om at det et det jeg driver med. Eller burde drive med. (Når det er sagt: Nokså få akademikere gjør egentlig dette. Men fantasien er der, i hvert fall blant næringslivsledere som tenker på å ta en doktorgrad for å trekke seg tilbake litt og tenke de lange tankene.

Nuvel. Etterhvert har jeg forstått at dette jeg driver med er normalt – en akademisk institusjon er, for å sitere en eller annen Clark Kerr, tidligere president ved University of California, som oppfattet et moderne universitet som «a series of individual faculty entrepreneurs held together by a common grievance over parking». På BI har vi ikke parkeringsproblemer, men ellers holder modellen: Folk gjør det de er opptatt av – som regel i løse samarbeid med andre – og er, for å bruke Ferdinand Tönnies‘ nyttige inndeling, mer opptatt av et globalt Gemeinschaft (med andre akademikere) enn Gesellschaft. «Globals» i stedet for «Locals», med andre ord.

Hvilket reiser spørsmålet – hvis man skal definere seg selv som freelancer i stedet for akademiker – hvordan blir man produktiv i en sådan setting? Og hvordan finner man folk å modellere sin arbeidspraksis etter?

Dette blogginnlegget kommer etter å ha lest Tiago Fortes glimrende The Rise of the Full-Stack Freelancer: A Portfolio Approach to Modern Work og bli slått av i hvilken forbausende grad hans arbeidshverdag ligner min. Og det tror jeg gjelder flere, også folk i fulltidsjobber, selv om de bare har én jobb.

Forte har også en artikkel nummer to, der han lister opp de verktøyene han bruker, og igjen blir jeg slått av likhetene. Jeg bruker Word, Excel og Powerpoint i stedet for Apples produkter, og har naturligvis andre løsninger for regnskap og fakturering og annet som er Norges-basert i stedet for amerikansk, men ellers er det stor overlapp. Og det har slått meg før – skal du drive en vidløftig kunnskapsvirksomhet og håndtere mange ideer og mye informasjon, kommer du ikke utenom Evernote, for eksempel. For ikke å snakke om Google-verktøyene, kalendere og annet.

Det er greit å tenke som en freelancer, selv om man ikke egentlig er det. Som Forte sier:

…the most compelling aspect of Full-Stack Freelancing is that it offers a middle ground, with potentially the best of both worlds. It is pragmatic, recognizing that most people are generalists who want to pursue diverse interests. But it is also aspirational, recognizing that you need the flexibility to take advantage of unexpected opportunities.

Og det gir jo, om ikke annet, et nokså fleksibelt syn på hva man har lyst til å holde på med. For ikke å snakke om en formidabel følelse av uavhengighet.

Robotbevegelser til neste nivå…

Jeg har tidligere vist frem roboten Handle som et eksempel på at roboter vil kunne brukes også i situasjoner der det ikke finnes infrastruktur – for eksempel i norske dagligvarebutikker.

Her er neste versjon, sylfersk video fra Boston Dynamics:

Og dermed kan hylekoret starte…

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…

Digital redsel – hva gjør man med det?

internet-thinkstock-179504580Jeg har et mulig prosjekt jeg har tenkt endel på. Jeg lagt merke til at mange mennesker er redde for digitalisering (eller for teknologi, eller matematikk, men la det ligge denne gangen). Særlig ledere er redde for digitalisering, og stritter i mot, ikke fordi de ikke forstår teknologien (skjønt det er et element) men fordi de er usikre på hvordan den påvirker deres egen rolle og situasjon. Folk som arbeider i store organisasjoner er også nervøse for ny teknologi, om ikke annet så fordi mange norske ledere ser ut til å tro at mer digitalisering ensidig betyr færre medarbeidere (eller mindre budsjetter.)

Jeg er ikke redd for digitalisering, men så har jeg jo også pustet digitalisering (og fått betalt for å digitalisere ting) siden sånn rundt omkring 1983. Og min strategi for å overbevise folk om å blir mer digitale har vært nokså klar: Å påvise muligheter og trusler og overbevise folk med vektige og rasjonelle (og nokså spissformulerte) argumenter om hvor fremtiden ligger og hvor fort man bør se å komme seg dit.

Det var greit så lenge jeg var ung og ildslukende, men nå er jeg 56 og har oppdaget at mange av de som er redde for digitalisering er betydelig yngre enn meg selv. Rollen som arrogant bråkmaker er grei nok, men jeg begynner å lure på om ikke litt mer folkeopplysning er tingen. Rasisme og innvandrerfrykt har en tendens til å forsvinne om man har positive opplevelser og bedre kunnskaper. Kanskje det er slik med digitalisering også?

En annen sak er at jeg har lyst til å begynne med et nytt medium, nemlig video. Ikke bare standup foran en tavle, som jeg har gjort masse av, men et fastere format med struktur og innhold og gjentatt over en viss periode. Det gir muligheten til å kjøpe seg en masse kul teknologi og dessuten lære nye programmer. Dessuten gir det kanskje muligheten til å komme i kontakt med et nytt publikum, nemlig de som ikke er så sikre på dette med digitalisering og kanskje trenger en bedre forklaring, gjerne med eksempler, på hva det er og hvorfor man ikke trenger å være så redd for det. Norge har mangel på arbeidskraft og et knallsterk (relativt, i hvert fall) sikkerhetsnett. Vi har ikke noe å være redd for, det er nok å gjøre og nok å tjene penger på selv om robotene kommer og tar rutinejobbene.

I alle fall, planen er å begynne å eksperimentere med videoprogrammer, kanskje en serie, kanskje noe mer formelt, rundt spørsmålet….

«Hvordan kan jeg bli litt mer digital?»

…for de som ikke føler seg så veldig digitale. Tanken er ikke bare å forklare teknologi, men også gi folk et perspektiv på hva de bør mene om den (og noen tips på veien).

Og dermed mitt spørsmål til de som måtte ha ideer der ute:

  1. Hva er folk mest redd for og vil ha forklaring (og kanskje litt trøst) om?
  2. Hva synes folk er vanskelig å gjøre med teknologi, og trenger hjelp med?

(Blockchain og Big Data og sikkerhet og kryptering og batteritid er jo selvsagte, men mer spesifikt: Hva funker og hva funker ikke, hva vil man ha hjelp til å bli bedre på?)

Noen tanker?*

*Ja, jeg er klar over at denne bloggens lesere er gode på det digitale. Men hva får dere spørsmål om?

Rask teknologiutvikling innen Big Data

DataRobot-screenFor noen uker siden var jeg i London for å lære meg DataRobot, et verktøy som automatiserer store deler av jobben rundt avansert dataanalyse. Det eneste DataRobot (og lignende verktøy) trenger, er masse data i et rad-og-kolonneformat (Excel, CSV, SQL, Hadoop, etc), og dermed kan man bare sette i gang: Dataene leses inn, hver kolonne tolkes og kategoriseres (dvs. som tekst, numeriske data, kategorier, boolsk, etc.). Deretter spør DataRobot hva som skal være den uavhengige variabelen (det vil si, hva det er man skal prøve å predikere), hva det er som skal være grunnlag for å vurdere hvilken modell som er best (forklart varians, logloss, etc.). Så kan man trykke Start og dermed setter DataRobot i gang og kjører alle analyser den vet om. Modellene listes opp med de som gir best resultat på toppen, og deretter er det bare å sette i gang og forbedre dem – for eksempel ved å finne mer data, kombinerer datapunkter, og så videre.

Med andre ord, masse av det man tidligere måtte ha spesialister til å gjøre, kan man nå gjøre selv.

Som min kollega Chandler Johnson sa: For fire-fem år siden måtte han programmere opp hver metode i Python. Så kom SciKit-Learn og andre programmeringsbiblioteker (XGBoost, RTensorFlow, Wowpal Wabbit) som gjorde at man bare kunne hente inn de metodene man ville bruke. Nå kommer grafiske verktøy som DataRobot, som velger ut og tester modeller for deg – og fjerner mye av behovet for programmering i det hele tatt. Selskapet reklamerer med at man kan redusere antallet data scientists man trenger, og det er jo gode nyheter der man må lete med lys og lykte og bruke ganske mye penger for å finne folk som kan gjøre slikt.

En stor del av jobben man trenger data scientists til, er å gjøre dataene klar for analyse. De fleste bedrifter vet at de har endel data, men når man først skal bruke dem, finner man kjapt at de har masse feil, er mangelfulle, og ofte ikke har de variablene man trodde man hadde. (For en liste av mange vanlige feil, se The Quartz Guide to Bad Data.) Også her begynner det å komme gode verktøy som reduserer behovet for programmering, som for eksempel Alteryx. Som en av våre studenter fra Analytics for Strategic Management sa: «DataRobot is soooo September…!

(Og skulle du ha lyst til å lære mer om dette: Sjekk ut dette kurset, 5-7 desember.)