Er du smart nok for smarte organisasjoner?

dn-09272018-smart-nok-til-acc8a-lede-intelligente-organisasjoner_pdfLiten artikkel i DN i dag, bygget på en artikkel i BI Business Review (kommer etterhvert), som igjen bygger på dette kapittelet i BIs jubileumsbok. (Og stor takk til Audun Farbrot for en formidabel innsats i forskningskommunikasjonens tjeneste i denne sammenheng.)

Og artikkelen? Vel, jeg vedlegger en PDF, lenken (betalingsmur) finner du nedenfor, og som så meget annet handler denne artikkelen om at man ikke kan innføre nye teknologier (i dette tilfelle dataanalyse) uten samtidig å endre organisasjonen (i dette tilfelle ledelsesrollen.) Dataanalyse og den datadrevne organisasjonen må forholde seg til et faktabasert verdensbilde, noe som krever evne til å sanse, forstå, handle, lære og forklare – kontinuerlig, og i stor skala.

Lenke til DN: https://www.dn.no/innlegg/ledelse/digitalisering/smart-nok-for-smarte-organisasjoner/2-1-424362

PDF: DN 09272018 Smart nok til å lede intelligente organisasjoner

(Og nei, jeg har ikke begynt å jobbe for Accenture. Fire forfattere ble tydeligvis litt for vanskelig for DN…)

Ekstremvær for 31 år siden

Vi har nettopp hatt ekstremværet Knud, som ikke var så voldsomt ekstremt (skjønt jeg var nå ute og flyttet båter sent på natten, med hjelp av gode naboer). Men det var andre boller 16. oktober 1987. En kombinasjon av storm fra sørvest, kraftig nedbør og springflo gjorde at vannstanden ble svært høy denne ettermiddagen. Mine foreldre kom til oss på Manglerud fordi de rett og slett ikke kunne komme ut til Malmøya – veien var oversvømmet. Vannstanden var nesten en meter på Mailand (Nedre Bekkelaget like ved Ormsundbroen), og i noen timer var det ikke mulig å komme ut til Ormøya og Malmøya med bil. Mange båter slet seg, og erstatningsbeløpene bare i Oslo kom på over 100 millioner kroner. Min bror sto i kø på Mosseveien og betraktet noen skipslaster med nye Peugeot 205 som duppet i vannet på bryggen ved Kongshavn…

Her er noen bilder tatt dagen etter:

storm87-01

Dette er tatt sør for Dampshipsbryggen – her har et badehus gått på sjøen og blitt liggende i bukten.

storm87-02

storm87-03

storm87-04

Nok et knust badehus, inne i bukten ved roklubben.

storm87-05

Her ligger et badehus – og en motorseiler på grunn.

storm87-06

storm87-07

storm87-08

storm87-09

Denne fiskeskøyten drev inn til Dampskipsbryggen.

storm87-10

Her er en snekke fortøyd i en telefonstolpe ved Malmøybroen.

storm87-11

…og noen flere badehus. Noen av dem ble visstnok løftet tilbake på plass.

storm87-12

storm87-13

Ved Ormøya hadde mye vrakgods drevet i land – og flere badehus gått på sjøen.

storm87-14

Her har en liten seilbåt gått ned.

storm87-15

storm87-16

storm87-17

storm87-18

I Ormsundet lå en seilbåt – visstnok ikke særlig skadet – på det lille skjæret.

Knivskarp byggmester

Ibsen som Bergman – eller var det omvendt?

stephanbraunschweigÅrets Ibsenfestival er i gang – og første forestilling var Bygmester Solness i regi av franskmannen Stéphane Braunschweig (bildet). Han er (i følge programmet) kjent for sine tekstlike og stilrene oppsetninger. Jeg er litt allergisk overfor ting som er overtydelig og misliker effektmakeri – husker med gru en oppsetning av Brand for ti år siden der effektene totalt druknet skuespillerne – og synes det er forfriskende med en forestilling der kulisser, kostymer, lyd og lyssetting bygger opp under selve skuespillerprestasjonen. (Med et lite unntak – sluttscenen, der scenekarusellen roterer og viser den falne byggmester i en sekvens klippet rett ut av Les Miserables. Men la den ligge i denne omgang).

Skuespillerne, i hvert fall hovedrollene, får rom til å utfolde seg, og griper sjansen. I de to hovedrollene finner vi Mads Ousdal (som med aldrende sminke til forveksling ligner sin far) som Halvard Solness. Han formidler en vegelsindig og muligens en smule psykotisk arkitekt som tviler på verdien av sitt livsverk og hvilken fremtid han egentlig har. Mariann Hole har den andre store rollen – hun representerer ungdommen i form av et keitete, småfrekt og ikke altfor ubehagelig gufs fra en dårlig husket fortid. (En tolkning, mener nå jeg, er at Hilde Wangel ikke er en reell person i det hele tatt, men en manifestasjon av Solness’ skyldfølelse og svermeri for sin egen betydning.) Dialogen mellom de to bærer stykket – og det er mye dialog.ovi_9804

ovi_9689De andre skuespillerne støtter godt om om hoveddialogen: Gisken Armand er rutinert som en oppgitt og ironisk Aline som lever av og for plikt og hele tiden opplyser omverdenen om det. De andre har mindre å spille på – Bjørn Skagestad leverer en troverdig skrøpelig Brovik, men er jo bare med tidlig i første akt. Resten (Rebekka Jynge, Lasse Lindtner og Mikkel Bratt Silset) har mindre å spille på, men leverer det de skal. Jynge som sekretær forelsket i sjefen er ikke særlig troverdig, i hvert fall ikke i disse #metoo-tider, men det er rollefigurens skyld, ikke skuespillerens.

Scenografien er superenkel, men tydelig: To sofaer, et minimalistisk arkitektkontor (sekretæren bør snarest gå til Arbeidstilsynet, hennes arbeidsbord er blottet for ergonomi), og en roterende scene der stilisert virkelighet glir over i perfekt lyssatt geometri. Stillheten gjør at man hører det skuespillerne sier uten mikrofoner, og gir en fortettet stemning trass i den åpne scenen. En liten musikksekvens mot slutten virker nesten sjokkerende som kontrast til stillheten, og en knirkende scenerotering i sluttscenen som en effekt i seg selv.

Ingmar Bergman var inspirert av Ibsen, men denne forestillingen er Ibsen inspirert av Bergman. Og det fungerer. Anbefales!oei_0964

Diskuter digitalisering i Sophia Antipolis!

IMG_3657Nok en gang ønsker Ragnvald Sannes og jeg velkommen til et Executive Short Program (23-26 oktober i år) kalt Digitalisering for vekst og innovasjon i Antibes og i teknologiparken Sophia Antipolis, Europas svar på Silicon Valley, like utenfor Nice i Syd-Frankrike. Hensikten er å vise frem interessante nye teknologiske muligheter og invitere til en dialog om hvordan man kan ta disse i bruk innenfor egen virksomhet.

acc-sophDette programmet er ment som et møtested (gjerne for flere mennesker fra samme bedrift,) der vi i tillegg til å vise frem mye ny teknologi setter av tid til diskusjon mellom deltakerne. Det gir en anledning for ledere og ledergrupper til ta en time-out og tid til å tenke over hva den nye teknologien (Blockchain, Internet-of-things, analytics, robotics, delingsøkonomi, automatisering, digitale tvillinger, etc.) betyr for din bedrift og din (eller dine kunders) situasjon og prosesser. Vi vil også forsøke å systematisk fange opp hvilke muligheter og utfordringer hver enkelt bedrift står overfor, og hjelpe til å finne perspektiver for hver enkelt bedrift eller organisasjon om hvordan man skal forholde seg til utviklingen.

IMG_3647Det er 11. gang Ragnvald og jeg arrangerer et seminar der nede sammen med Accenture Technology Labs, og fjerde gang vi gjør dette som et selvstendig, firedagers program. Deltakerne på det første tre programmene har vært svært fornøyd. En av tingene vi har lært av deltakerne er å sette av tid til diskusjoner – man lærer minst like mye av hverandre som av Ragnvald og meg – og at diskusjonene, i hvert fall mellom deltakerne, kommer til å være på norsk.

Her er noen linker til notater jeg har tatt ved tidligere besøk. Jeg ser frem denne uken, til å lære nye ting, og til å bli kjent med nye mennesker med interessante utfordringer og et ønske om å forstå hvilket potensiale som ligger, forretnings- og arbeidsmessig, i ny teknologi!

Vi sees! (Og har du spørsmål, send meg gjerne en epost.)

berne.jpg

Hvordan skrive et undervisningscase

Siden jeg av og til underviser i undervisningsteknikk (særlig case-undervisning) og har skrevet en bok om dette med Bill Schiano, blir jeg av og til spurt om hvordan man skal skrive et undervisningscase. Det følgende er en kjapp oppsummering av hva jeg mener er viktig (i hovedsak en oversettelse av denne bloggposten.)

Hva er hensikten med caset?
For det første: Et case skrives i en spesifikk undervisningshensikt. (På Harvard Business School får man faktisk ikke skrive et nytt case uten at det er satt inn i en spesifikk undervisningssituasjon. Det holder ikke at man har en interessant bedrift som har gjort noe spennende – selv den mest spennende og nyskapende historie trenger å ha et pedagogisk poeng, en teori eller et dilemma å illustrere.

Standard disposisjon
Cases – særlig de som skrives på Harvard – følger en disposisjon som nok er en klisjé, men som er svært effektiv. Den ser omtrent slik ut:

  • 0.5 side: Introduksjon: Casets hovedperson introduseres, vanligvis en leder eller mellomleder som lurer på hva han eller hun skal gjøre i et viktig spørsmål. Tanken er å fortelle studentene fra hvis perspektiv caset er skrevet, sette scenen, kanskje si noe om analysenivået – og det er det hele. Det at det er personlig skrevet, hjelper studentene å identifisere seg med personen og føle det litt som om de har den samme utfordringen selv.
  • 1 – 1.5 sider: Beskrivelse av firmaet eller organisasjonen – ikke hele histoiren, men relevante detaljer. Man må forklare hva bedriften eller organisasjonen gjør, hvordan den tjener penger, hva den produserer, hvordan den har kommet til den situasjonen som beskrives. Bedrifter og organisasjoner er i stor grad formet av sin historie, så i alle fall jeg mener at man heller bør ha for mye enn for lite detaljer her.
  • 1 – 1.5 sider: Bransje/omgivelsesbeskrivelse. Bedrifter og organisasjoner eksisterer innenfor en kontekst, og du må beskrive den. Beskrive bransjen, dens utvikling, og bedriftens plass innenfor den. Vær kortfattet, men presis, og legg gjerne inn mer detaljer enn strengt tatt nødvendig.
  • 1 – 5 sider: Problem. Dette er casets tema – beskriv det utførlig og nøytralt, få med kompleksiteten i situasjonen. Et undervisningscase skal skrives slik at flere alternative løsninger er mulige, så man har noe å diskutere.
  • 0.5 side: Avslutning, typisk at casets hovedperson(er) oppsummerer spørsmplet og lurer på hva de skal gjøre – ofte i form av en eller annen form for hendelse (et styremøte, for eksempel) der de skal legge frem en anbefaling til løsning.

De fleste case er et enkeltcase, men man kan ha B-case (som deles ut til studentene etter at man har diskutert det første caset) og til og med et C-case. Det er viktig at B og C cases er kortfattet, siden de skal leses i klasserommet. B-caset sier typisk noe om hva bedriften eller organisasjonen gjorde og introduserer kanskje et problem som oppsto på grunn av avgjørelsen. C-caset, hvis det er nødvendig, bør bringe en slags avslutning. Etter min erfaring er vanskelig å generere noe særlig diskusjon etter et C-case – studentene blir slitne. En fersk caseforfatter som skrive rom et firma med en lang historie kan nok bli fristet til å lage en lang rekke med korte case, men i praksis fungerer ofte dette dårlig – ikke minst fordi det gjør diskusjonen svært forutsigbar.

Det man ikke skal gjøre
Jeg har sett en hel del nybegynnerfeil som kommer når man skal skrive et case for første gang. Her er noen av de tingene man bør unngå:

Ikke teori. Et godt case skal være en beskrivelse av en interessant situasjon, ofte en avgjørelse som må tas – og ikke noe annet. Det betyr at det skal ikke være teori og ikke diskusjon i selve caseteksten. Spar teori og diskusjon til en eventuell «teaching note» eller skriv en separat akademisk artikkel. Ikke bare gjør dette caset mer realistisk, det åpner også for at man kan bruke caset innenfor kurs og undervisningssituasjoner det ikke opprinnelig var ment for. Å holde teori utenfor kan være vanskelig hvis du bare er vant til å skrive akademiske artikler – men det er god praksis å legge frem «just the facts». (Hvilke fakta du velger å legge frem er naturligvis også en form for diskusjon og tolkning, men vi lar den ligge i denne omgang.)

Ingen helter, ingen skurker. Når jeg lærer studenter å analysere et case (og når jeg hjelper organisasjoner å forstå komplekse situasjoner) pleier jeg å si at for de fleste situasjoner innenfor ledelse og forretningsdrift et det god praksis å gå ut fra at folk ikke er dumme og ikke onde. Så – når du skriver et case, pass på at det har ingen helter og ingen skurker. Hvis et case hare en klar helt eller en klar skurk, er det et tegn på at du ikke har lagt inn nok detaljer. Skriv det så studentene kan se situasjonen fra flere sider.

Ingen vurderinger. Et vanlig problem er at man finner karakteristikker og vurderinger fra forfatteren i et case – særlig hvis caset er skrevet av en firma som skriver om seg selv. Et case (også et kundecase man bruker i reklame) er mest troverdig hvis det er skrevet i en nøytral og beskrivende tone. Ikke skriv at et firma er «ledende» – beskriv hva firmaet gjør og hvilke resultater de har oppnådd, og la leseren selv vurdere hvor ledende firmaet er eller hvor vellykket hovedpersonen er. For eksempel: «Nilsen var en dyktig leder, med ansvar for et stort og vellykket prosjekt.» Legg til opplysninger som forteller noe, og skriv. «29 år gammel ble Nilsen forfremmet til den yngste direktøren i firmaets historie, etter å ha utviklet og innført bransjens første maskinlæringsplattform.»

Ikke noe konsulentspråk. Vær svært forsiktig med motepreget språk og konsulentuttrykk. For eksempel: Er firmaet i ferd med å inngå en strategisk allianse eller samarbeider man bare med et annet firma i den hensikt å oppnå noe spesifikt? (Som en britisk venn av meg pleier å si: Jeg kjøper alle sokkene mine på Marks & Spencer – det betyr ikke at jeg har inngått en strategisk allianse med dem.) Unngå uttrykk som ikke er veldefinert, og vær presis i din språkbruk. Husk at et undervisningscase har lengst holdbarhet når det beskriver en situasjon som involverer mennesker og dilemmaer, ikke spesifikke situasjoner eller teknologier (som Fabritek-eksempelet nedenfor).  Jeg bruker ofte eldre case om teknologi, og hvis studentene klager over at casene er gamle og datamaskiner er mye raskere nå, så ber jeg dem bare ta en penn og endre alle årstallene og oppdatere datamaskinenes ytelse – og se om noe annet endrer seg.

Dramatisk struktur
Et virkelig velskrevet case har en dramatisk struktur – det er en begynnelse, en midtseksjon som bygger opp historien, og et virkelig interessant dilemma til slutt. De beste casene er som detektivhistorier, hvor du må grave deg langt ned i detaljene for å der du finner overraskende og ofte kontraintuitive konklusjoner. Et eksempel på en skikkelig «detektivhistorie» er Fabritek 1992, et gammelt (først publisert 1967, oppdatert 1992 av Jan Hammond) case om et kvalitetskontrollproblem i et mekanisk verksted. (Takk til Robert D. Austin, glimrende caseunderviser, for å ha gjort meg oppmerksom på dette caset og lært meg hvordan det skal undervises.) Fabritek er glimrende fordi det starter med en beskrivelse av bedriften (strategisk nivå), beskriver arbeidsprosessen og aktørene (organisasjonsnivå/forretningslogikknivå) og deretter problemet (operasjonelt nivå). En detaljert analyse av de operasjonelle detaljene leder til en noe overraskende konklusjon, som så kan diskuteres på organisasjons- eller prosessnivå, og deretter plasseres i en strategisk kontekst. Caset er glimrende fordi det tillater studentene å trekke linjer mellom disse nivåene, lærer dem at djevelen virkelig er i detaljene, og at du som leder bør ha en dyp, operasjonell forståelse for hvordan bedriften din faktisk gjør ting og faktisk tjener penger.

iPremier-front-pageEt annet case som viser kvalitet og innovasjon er iPremier, skrevet av Robert D. Austin og Jeremy C. Short. Det er det første og eneste tegneseriecaset jeg kjenner til. Historien handler om et lite, nettbasert firma som selger gaveartikler, og hvis webside og systemer blir angrepet av hackere. Angrepet avslører store sikkerhetshull og manglende beredskapsrutiner, og tvinger ledere på mange nivåer og innen mange spesialiteter til å ta vanskelige beslutninger. Det grafiske formatet gjør figurene levende og bygger opp historien (selv om jeg tviler litt på om de ansatte i et slikt firma i gjennomsnitt er like vakre, veltrente go velkledde som tegnerne fremstiller dem.) Caset illustrerer nokså innfløkte tekniske problemer på en forståelig måte (også for ikke-tekniske studenter) og har et glimrende plot med et B- og et C-case. Jeg liker å bruke endel tekniske case i mine kurs fordi, vel, en av mine kjepphester er at det ikke er nok teknologi på handelshøyskoler, og et case som iPremier illustrerer med all ønskelig tydelighet hva som kan skje hvis ledere neglisjerer teknologi og betrakter det som noe de kan overlate til teknologer i et hjørne. Det grafiske formatet (det finnes filmbaserte case også) gir studentene en liten pause fra vanlig tekst – standard case-tekster kan bli litt ensformige i lengden.

Detaljer, detaljer, detaljer!
Forskningscases – slike som publiseres i akademiske tidsskrifter – tenderer til å være skrevet for å passe i en spesifikk sammenheng, noe som betyr at bare opplysninger som er relevant for den sammenhengen blir tatt med – ofte nokså abstrahert. Et undervisningscase er det stikk motsatte: Det trenger masse opplysninger, gjerne tilgjengeliggjort som appendikser (grafer, bilder, tabeller, dokumenter, etc.) bakerst i caset, etter hovedteksten. En caseforfatter, når han eller hun besøker et firma eller en organisasjon for å lage et case, må legge merke til de små detaljene og legge dem inn, omtrent slik en god journalist gjør. I et av mine kurs lar jeg studentene skrive case som fagoppgave, og sier til dem at de skal skrive caset så detaljert at når du har lest det føles det litt som om du har jobbet der. For å få til det, må du få tak i nødvendige opplysninger. (Det kan av og til være nødvendig å maskere opplysninger for å kunne publisere dem, men hvordan man gjør det får jeg heller ta i en annen bloggpost.) Studentene klager av og til over at det er for mange detaljer i et typisk Harvard-case, og at ikke alle av dem er relevante (i hvert fall ikke i alle kurs). Men slik er det jo i den vanlige verden også – og det å finne ut hva som er relevant og hva du ikke skal legge vekt på er en egenskap det er svært viktig å oppøve hos prospektive ledere.

Lesing – og jobb.
grandongillJeg kjenner ikke til så mange gode bøker om hvordan man skal skrive et godt undervisningscase, kanskje med et unntak: Grandon Gill (bildet), professor ved University of South Florida og en glimrende caseforeleser har skrevet Informing with the case method, gratis nedlastbar i PDF, MOBI og EPUB format fra hans webside. Den har masse detaljer, tips og tricks, ikke bare om caseskriving, men også om caseundervisning og kursplanlegging. (Og, ahem, for de siste to er jeg vel nærmest forpliktet til å anbefale Bill Schianos og min bok Teaching with Cases: A Practical Guide.)

Sist men definitivt ikke minst: Ikke underestimer hvor mye jobb det er å skrive et skikkelig undervisningscase. Å få detaljene riktige, beskrive dramatis personae, og å utvikle en skikkelig historie er litt av en utfordring, forskjellig (i mange dimensjoner) fra å skrive en akademisk artikkel. På den annen side: Får du det til, har du et meget effektivt læringshjelpemiddel i mange år fremover.

Lykke til!