Forretningsutvikling og digitalisering

Forord

Til Anne Mette

Året 2020 kommer til å gå inn i historien som et unntaksår. En alvorlig pandemi rystet samfunnet, og både som privatpersoner og arbeidstakere måtte vi forholde oss til nye leveregler. Vår evne til å håndtere endring ble satt på en hard prøve. Virksomhetenes digitale plattformer likeså. Digitale samhandlingsplattformer som Teams og Zoom ble den obligatoriske infrastrukturen som «alle» måtte forholde seg til i det vi kan kalle en sosial digitalisering. Digitalisering på overflaten. Den dype digitalisering handler om noe langt mer. La oss kalle det digital samhandling mellom systemer både innad i en organisasjon og mellom organisasjoner. Det dreier seg om det komplekse digitale maskineriet som alle virksomheter, private som offentlige, strever med å få på plass for å kunne levere varer og tjenester til markedet. Dette maskineriet består av regnskapssystemer, logistikksystemer, produksjonssystemer, salgssystemer, lønnssystemer og innkjøpssystemer for å nevne de viktigste. Vårt mål er at systemene skal danne selve fundamentet for effektive forretningsprosesser og en god arbeidsdag for de ansatte.

Slike systemer skal inspirere, ikke irritere. I tillegg skal systemene være tilgjengelige fra hjemmekontoret på en like sikker og stabil måte som fra din faste arbeidsplass.

Pandemien og den påfølgende unntakstilstanden har vært en vekker for mange, der systemenes sterke og svake sider har kommet tydelig til uttrykk. Den tekniske gjelden ble for mange ubehagelig konkret.

I denne boken retter jeg søkelyset mot virksomhetenes forretningssystemer. Den er skrevet for alle som har et ansvar for at det digitale maskineriet fungerer knirkefritt. Dette er et ansvar som hviler på manges skuldre. Både styret, toppledelsen og de fagansvarlige har åpenbart en aksje i denne problemstillingen. Systemer skal velges, implementeres og forvaltes. Økonomiske aspekter skal brynes mot de tekniske og funksjonelle. Risiko skal balanseres opp mot muligheter. Den presise formelen for å lykkes finnes dessverre ikke, men visse kriterier for suksess tør jeg allikevel å presentere etter gode 40 år i bransjen. Dette er med andre ord ikke en tradisjonell lærebok med overveldende akademiske referanser. Den bygger naturligvis på anerkjente teorier, men viktigere er det at disse teoriene sees i en erfaringsbasert kontekst. Kunsten er å omsette teori til god praksis.

Lykke til med lesingen.

Bo Hjort Christensen Ljan, september 2021

KAPITTEL 1 INTRODUKSJON

Innhold . . . . . . . . . . . . . . . . . . . . . . . . . 12

KAPITTEL 2 PERSPEKTIV

(Virksomhetsperspektivene) . . . . . . . . . . . . . . . . . . . . . . . 34

KAPITTEL 3 PENGER

KAPITTEL 1 INTRODUKSJON

Prosesskvalitet

Prosess: Håndtering av inngående faktura . . . . . . . . . . .

12

Digitalisering som fenomen . . . . . . . . . . . . . . . . . . . . . . . 13 Begrepet digitalisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Digitaliseringens ulike posisjoner . . . . . . . . . . . . . . 22 Digital kompetanse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Systemenes formål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 P7-rammeverket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

(Kost–nytte-analysen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

KAPITTEL 4 PRODUKT

(Applikasjoner) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

KAPITTEL 5 PROSJEKT

(digitaliseringsprosjekter) . . . . . . . . . . . . . . . . . . . . . . . 210

KAPITTEL 2 PERSPEKTIV

(Virksomhetsperspektivene) . . . . . . 34 IT-strategier versus digitale strategier . . . . . . . 36 Et mulig årsak–virkningsscenario . . . . . . . . . . . . . . . 40 Virksomhetsarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

(anskaffelses- og implementeringsprosessen) . . . . . 252

KAPITTEL 7 PARTNER

(digitaliseringspartner) . . . . . . . . . . . . . . . . . . . . . . . . . 310

FORRETNINGSUTVIKLING OG DIGITALISERING

79

KAPITTEL 3 PENGER

(Kost–nytte-analysen) . . . . . . . . . . . . . . . . . . 84 Fra endring til gevinst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Effektprofil og gevinstpotensial . . . . . . . . . . . . . . . . 90 Effekt- og gevinststiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Business case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 ROI-modellens konstruksjon . . . . . . . . . . . . . . . . . . . . . . 99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

Eksterne kostnader: Del 1

. . . . . . . . . . . . . . . . . . . . . . . . . . .

100

Eksterne kostnader: Del 2

. . . . . . . . . . . . . . . . . . . . . . . . . . .

100

Gevinster: Del 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A: Organisasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Gevinster og tap: Del 2

B: Prosess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Kostnadspåslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

C: Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Return on investment (ROI)

Systemarkitektur – en dypere beskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . 50

...............................

..........................

100

101

ROI-MODELLEN (Return on investment) . . . . . . . . . . . . 102

TCO-modellens konstruksjon . . . . . . . . . . . . . . . . . . .

103

Volumtall (som påvirker lisensleien) . . . . . . . . . . . . . . . . 103

E: Teknisk infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Kostnader (lisensleie) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Relasjonene mellom arkitekturdomenene

52

Kostnader (arbeidsinnsats) . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Business-to-business: Når arkitekturene koples . . . . . . . . . . . . . . . . . . . . . . . 57 Arkitekturens nytteverdi . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Bransjebegrepet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Bransjenormen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Prosess: En begrepsavklaring . . . . . . . . . . . . . . . . . . . . 69 Prosessforbedring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Kostnader (forvaltning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

. . . . . . . . . . .

Den kronglete veien fra anskaffelse til gevinst

6

. . . . . . . . . .

78

Undersøkelsen til MIT Center for Digital Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Interne kostnader

D: Systemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

KAPITTEL 6 PROSESS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

77

TCO-MODELLEN (total cost of ownership – SaaS) . . 105 Volumtall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Lisenskostnader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Kostnader (prosjekt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Kostnader (forvaltning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 TCO-MODELLEN (total cost of ownership – on premise)

. . . . . . . . .

Innhold

108

7

Cost breakdown structure (CBS) . . . . . . . . . . . . . . . Økonomimodellen i praksis . . . . . . . . . . . . . . . . . . . . . .

Estimeringsteknikker og statistisk usikkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

En forenklet kalkylemodell . . . . . . . . . . . . . . . . . . . . . .

Kalkylemodellen i en SaaS-kontekst . . . . . . . . .

Akkumulert kost/gevinst over tid . . . . . . . . . . . . .

110 112

Forretningssystemet; en begrepsavklaring .

Fra MRP 1 til «postmodern ERP» . . . . . . . . . . . . .

ERP-suite vs. best-of-breed . . . . . . . . . . . . . . . . . . . . .

Integrasjon som en tjeneste – API-økonomien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Masterdata og produktdata . . . . . . . . . . . . . . . . . . . . .

Systemegenskaper – en overordnet vurdering . . . . . . . . . . . . . . . . . . .

Aksessnivå – persepsjon . . . . . . . . . . . . . . . . . . . . . . . . .

Datanivå . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Funksjonsnivå . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ytelsesnivå . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Software as a service – en begrepsavklaring . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

171

ERP-markedet i Norge . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

174

Et rammeverk for kategorisering . . . . . . . . . . . . . . . . . . . . 174

Variantene

Løpende risikovurderinger i

Vannfallsmetoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

280

prosjektgjennomføringen . . . . . . . . . . . . . . . . . . . . . . . . 233

Agile metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Malbasert implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Leverandørenes historie, status og strategier . . . . . 179

Løpende risikovurderinger etter oppstart . . . . . . . . . . 234

127 131

134 136

ERP-løsningene i et historisk perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Oppgraderinger av SaaS-løsninger . . . . . . . . . . .

Bransjeløsninger – en begrepsavklaring . . . . . . . . . . . . . . . . . . . . . . . . .

Det globale forretningssystem . . . . . . . . . . . . . . . .

Forretningssystemets livsløp hos kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Roboter og robotisering . . . . . . . . . . . . . . . . . . . . . . . . . .

Valgrisiko – funksjonelt og finansielt . . . . . . . . . . . . . . . 234 186

Leverandørens leveranseevne

187

Kundens mottaksevne

196

154 158

245

Rapportering av risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

246

Team versus gruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

212

Delprosjekt omstilling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

164

Delprosjekt prosess

250

KAPITTEL 6 PROSESS

(anskaffelses- og implementeringsprosessen) . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

297

Byttekostnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Systemforvaltning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Kontraktmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

298

WBS 1.8: Omstilling

300 307

KAPITTEL 7 PARTNER 252

(digitaliseringspartner) . . . . . . . . . . . . . . .

310

214

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

214

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215

Kvalitetsrevisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Public cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Prosjektlederstøtte

Private cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Styringsgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Single tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Kontraktforum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

FORRETNINGSUTVIKLING OG DIGITALISERING

........................................

Risikoregister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Delprosjekt masterdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

169

293

WBS 1.7: Prosjektledelse

Prosjektorganisering – det store bildet . . . . .

Djevelen ligger i detaljene . . . . . . . . . . . . . . . . . . . . . . .

Ressursmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referater fra styringsgruppens møter . . . . . .

. . . . . . . . . . . . . . . . .

WBS 1.6: Masterdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

164

SaaS-arkitekturene

WBS 1.4: Oppstart og stabilisering

291

Tilgjengelighet

162

Multi tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integritet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

210

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

243

WBS 1.3: Bygge og teste

204

(digitaliseringsprosjekter) . . . . . . . . . .

Delprosjekt teknologi

WBS 1.2: Analyse og design . . . . . . . . . . . . . . . . . . . . . . . . . 288

relasjoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Digitalisering og sikkerhetsrisiko . . . . . . . . . . . . .

285

WBS 1.1: Valg og kontrahering . . . . . . . . . . . . . . . . . . . . . . 287

201

KAPITTEL 5 PROSJEKT

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

238

284

WBS 1.5: Forvaltning og optimalisering . . . . . . . . . . . . 294

160 160

236

Hva er da den beste metoden? . . . . . . . . . . . . . . . .

Arbeidspakker (work breakdown structure) . . . . . . . . . . . . . . . . .

Konfidensialitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

142 153

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Samarbeidsevne og mellommenneskelige 193

SaaS – en arkitekturmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 167

8

Risikovurderinger før kontraktsinngåelse . . . . . . . . . . 232

Risikovurderinger forut for oppstart . . . . . . . . . . . . . . . . 233

Testleder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

. . . . . . . .

280

ERP-systemenes DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Arkitektene

– en dypere beskrivelse av forskjellene

Implementeringsmetoder . . . . . . . . . . . . . . . . . . . . . . . .

ERP-suitenes posisjon i rammeverket . . . . . . . . . . . . . . 176

167

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

229

122

167

Kjennetegnene

Prosjektrisiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

KAPITTEL 4 PRODUKT

(Applikasjoner) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Born SaaS vs. Been SaaS

217

220 221 225

Det store bildet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Begrunnelser for å skifte ERP-system . . . . . .

Kjøp av ERP-system – en overordnet analyse . . . . . . . . . . . . . . . . . . . . . .

Tvunget valg – en refleksjon . . . . . . . . . . . . . . . . . . .

Valgets kvaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Feilkilder i evalueringen . . . . . . . . . . . . . . . . . . . . . . . . . .

Dialogbasert anskaffelsesprosess . . . . . . . . . . . .

Kontraktstyrt tilbudsprosess . . . . . . . . . . . . . . . . . . .

Alternativ modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

254 256

260

Applikasjonssentriske økosystemer . . . . . . . . .

Programvarehusenes partnerstrategier . . . .

Det nye trekantforholdet . . . . . . . . . . . . . . . . . . . . . . . . .

Valg av implementeringspartner . . . . . . . . . . . . . .

312

Litteratur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stikkordsregister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324

317 320 322

264 265 271 272 278 279

Innhold

325

9

Figurliste

Tabelliste

Figur 1.1 Digitalisering anno 2017 ............................................... 18

Figur 3.8 Fra TCO-modell til regnskap ..................................... 112

Figur 4.23 Livsløpet hos programvareeier .............................. 199

Tabell 3.1 Et eksempel på et målprisregime ......................... 117

Figur 1.2 Den «digitale» mekaniske regnemaskin

Figur 3.9 ROI – fra teori til praksis .............................................. 114

Figur 4.24 Livsløpets faser hos kunden .................................... 203

Tabell 3.2 Beregning av usikkerhet ............................................. 119

anno 1950 ................................................................................. 19

Figur 3.10 Estimeringsusikkerhet .................................................. 116

Figur 4.25 Fra Karel Čapeks

Tabell 3.3 Faktorer som påvirker prosjektkostnad .......... 125

Figur 1.3 Tre ambisjonsnivåer ........................................................... 21

Figur 3.11 Stor estimeringsusikkerhet ....................................... 116

«Rossums Universal Robots» ................................. 204

Figur 1.4 Digitaliseringens posisjoner ........................................ 24

Figur 3.12 Betafordeling, eller skjevfordeling ...................... 118

Figur 4.26 Robotens fire uttrykk ..................................................... 207

Figur 1.5 Utviklingen mot intelligente

Figur 3.13 Kalkulator ................................................................................. 123

Figur 4.27 PEPPER – den humanoide robot ............................ 209

Tabell 3.4 Løsningsnivåer (noen eksempler) ....................... 126 Tabell 4.1 Eksempel på løsningskonsepter som støtter multi-platform/single-cloud-arkitekturen ..... 151

handelsplattformer ............................................................. 26

Figur 3.14 Prosjektkostnad SaaS .................................................... 128

Figur 5.1 Prosjektorganisering ...................................................... 216

Figur 1.6 Hva er til hinder for digitalisering? ........................ 28

Figur 3.15 Prisdrivere i SaaS-leveranser ................................... 130

Figur 5.2 Djevelen ligger i detaljene ......................................... 220

Figur 1.7 Arbeidsutførelse i tre varianter ................................ 30

Figur 3.16 Akkumulert kost/gevinst (on-premise) ............ 133

Figur 5.3 Ressursmodell ...................................................................... 222

Tabell 4.3 Hvilke prosesser har behov for hva .................... 160

Figur 1.8 Overordnet arkitektur ....................................................... 31

Figur 3.17 Akkumulert kost/gevinst (SaaS) ........................... 133

Figur 5.4 Referat fra styringsgruppemøte ........................... 228

Tabell 4.4 Bedriftskategorisering .................................................. 175

Figur 1.9 P7-rammeverket .................................................................... 33

Figur 4.1 Systemenes posisjoner ................................................ 138

Figur 5.5 Risikovurderinger i et tidsperspektiv ............... 232

Tabell 5.1 Intervallene ............................................................................ 247

Figur 2.1 IT-strategiens utvikling .................................................. 38

Figur 4.2 Et eksempel på avgrensning av hva

Figur 5.6 Kunden involverer seg i leveranseprosjektet

Tabell 4.2 Eksempel på løsningskonsepter som støtter multi-platform/multi-cloud-arkitekturen ....... 151

Tabell 5.2 Risikoregister ........................................................................ 249

Figur 2.2 En utvikling ............................................................................... 39

ERP-systemet skal støtte ........................................... 139

og vice versa ......................................................................... 240

Tabell 6.1 Et tenkt bedriftsscenario anno 2022 .............. 257

Figur 2.3 Et årsak–virkningsscenario .......................................... 42

Figur 4.3 En moderne kategorisering av tjenester ....... 141

Figur 5.7 Risikomatrise ........................................................................ 246

Tabell 6.2 Triggere og opprinnelse ............................................... 259

Figur 2.4 «Architecture framework» ............................................. 45

Figur 4.4 Fra MRP I til «postmodern ERP» .......................... 142

Figur 5.8 Risikoposisjoner ................................................................. 248

Tabell 6.3 Eksempel på en omfattende

Figur 2.5 Virksomhetsarkitektur ..................................................... 45

Figur 4.5 Single-platform/single-cloud ................................... 148

Figur 6.1 Den lange reisen mot målet ..................................... 256

Figur 2.6 Bikubemodellen: En nedbrytning av

Figur 4.6 En tredeling av systemlandskapet ...................... 149

Figur 6.2 Det vi egentlig kjøper .................................................... 263

hovedprosessområdene .................................................. 52

Figur 4.7 Multi-platform/single-cloud ...................................... 150

Figur 6.3 Evalueringsmodell ............................................................ 269

Figur 2.7 Når arkitekturene koples ............................................... 58

Figur 4.8 Multi-platform/multi-cloud ........................................ 152

Figur 6.4 Rekkefølgen er viktig ..................................................... 272

Figur 2.8 Næringsnedbrytning i henhold til SN2007 .... 60

Figur 4.9 Arkitekturer og integrasjonsmetoder

Figur 6.5 Kalkylemodellen som leverandørene skal

Figur 2.9 Normalfordeling med standardavvik 1 ............... 62

på en tidslinje ....................................................................... 156

forholde seg til (TCO-modellen) ............................ 275

Figur 2.10 Bransjenormen = normalområdet ........................... 64

Figur 4.10 Dokumentasjon av et API i Workday .................. 157

Figur 6.6 Dialogbasert anskaffelse (RFI+) ........................... 277

Figur 2.11 Bransjenormen – et taktskifte ................................... 68

Figur 4.11 MDM–PIM–PDM .................................................................... 159

Figur 6.7 Dialogbasert anskaffelse (RFI+ og RFP) ........ 278

Figur 2.12 Porters verdikjede ............................................................... 71

Figur 4.12 Faksimile fra Dagbladet

Figur 6.8 Implementeringsmetodene ....................................... 280

Figur 2.13 Et hierarki – fra det abstrakte til det

2. desember 2019 ............................................................ 166

Figur 6.9 Arbeidspakkestruktur (WBS) .................................... 287

konkrete ....................................................................................... 72

Figur 4.13 kjennetegn ved SaaS ..................................................... 167

Figur 6.10 Plannivåene ........................................................................... 297

Figur 2.14 Systemstøttet prosess .................................................... 73

Figur 4.14 Arkitekturvariantene ...................................................... 170

Figur 6.11 Forvaltningsmodell .......................................................... 303

Figur 2.15 SCOR-modellen ....................................................................... 75

Figur 4.15 Utviklingsløpet fra on-premise til SaaS .......... 173

Figur 6.12 To ulike kontraktstrategier ........................................ 309

Figur 2.16 Analyseskjema ....................................................................... 79

Figur 4.16 De ulike modellene fra Born SaaS – multi

Figur 7.1 Et applikasjonssentriks økosystem .................... 313

Figur 2.17 Prosesskvaliteter .................................................................. 80

tenant til managed cloud single tenant ......... 174

Figur 7.2 Tre viktige ISO-standarder ......................................... 315

Figur 2.18 Arketypene og de finansielle indikatorene ..... 81

Figur 4.17 ERP-markedet i Norge ................................................... 176

Figur 7.3 Det utvidede økosystem ............................................. 317

Figur 3.1 Planverket etter oppstart .............................................. 88

Figur 4.18 Multi-platform/single-cloud i en

Figur 7.4 Ansvarsdelingen ................................................................ 318

Figur 3.2 Fra endring til gevinst ...................................................... 89

Microsoft-kontekst ........................................................... 181

Figur 7.5 Multi-brand-modellen .................................................... 319

Figur 3.3 Gevinstprofil og effektprofil ........................................ 93

Figur 4.19 SaaS-løsninger i et historisk perspektiv ......... 186

Figur 7.6 Spillereglene endres ....................................................... 320

Figur 3.4 Eksempler på effekt- og gevinststiler ................ 94

Figur 4.20 Det brede spekteret av verdiøkende

Figur 7.7 Partnerens kompetanseprofil .................................. 321

Figur 3.5 ROI-modellens konstruksjon .................................... 102

produkter ................................................................................. 192

Figur 3.6 TCO-modellens konstruksjon (SaaS) .................. 105

Figur 4.21 Eksempel fra ISIC ............................................................... 194

Figur 3.7 TCO-modellens konstruksjon (on-premise) ... 108

Figur 4.22 Fire alternative virksomhetsmodeller .............. 197

10

FORRETNINGSUTVIKLING OG DIGITALISERING

tjenestekatalog ................................................................... 306

Figur 7.8 Evaluering av leveranseteam .................................. 322

Figurliste og tabelliste

11

Digitalisering som fenomen

KAPITTEL 1 INTRODUKSJON

12

FORRETNINGSUTVIKLING OG DIGITALISERING

I 2003 leste jeg en tankevekkende artikkel i det anerkjente amerikanske tidsskriftet Harvard Business Review. Artikkelens tittel var ganske provoserende og vekket derfor umiddelbart min interesse. Den var skrevet av den amerikanske forfatteren og IT-kommen­tatoren Nicholas G. Carr, som hadde valgt følgende slående tittel: «IT Doesn’t Matter». Min første tanke var at dersom man tok dette budskapet bokstavelig, stod mitt fagområde for fall. Det ville i så fall være et dypt fall – jeg hadde tross alt viet mesteparten av mitt yrkesaktive liv til, ja nettopp: informasjonsteknologi. Helt siden uteksamineringen fra NTH på midten av 70-tallet hadde jeg vært fasinert av systemer som bidro til å skape struktur og orden, eller rettere sagt til bedre planlegging og oppfølging av byggeprosjekter, som var mitt arbeidsområde den gangen. Det er et godt ordtak som sier at man skal ikke skue hunden på hårene. Man skal heller ikke trekke forhastede konklusjoner på basis av en spissformulert overskrift. Overskriften skal først og fremst være en interessevekker, skape lyst til å lese. Jeg leste og ble beroliget – etter hvert også ganske enig. Til slutt var jeg blitt en svoren tilhenger av Carrs tankesett. Carrs hovedpoeng er meget kort som følger: Alle bedrifter benytter i dag systemer for ulike formål og i ulikt omfang. Det kan for eksempel være for regnskapsføring, lønnsadministrasjon, salg, logistikk eller produksjonsstyring. Dersom vi spør bedriftsledere om disse systemene utgjør viktige komponenter i bedriftenes velsmurte driftsmaskineri, er svaret etter all sannsynlighet et rungende ja. Mange ville understreke viktigheten ved å si at systemene er av strategisk betydning. Da er vi brått ved sakens kjerne. Et system kan godt være viktig uten at det er av strategisk betydning. Nicholas Carr hevder nettopp dette – nemlig at de fleste av de systemene vi benytter ikke er strategiske, men derimot en del av vår infrastruktur.

Min gode kollega på Handelshøyskolen BI, førsteamanuensis Espen Andersen, definerer infrastruktur som følger: «Den underliggende struktur, noe obligatorisk, eller noe den ansatte og næringslivet kan ta for gitt» (Andersen, 1995). Revisoren tar for gitt at regnskapet er ført i et IT-basert regnskapssystem. Det er obligatorisk, et pålegg fra myndighetene. Kunden forutsetter at leverandøren kan gi et umiddelbart svar på når en artikkel kan leveres. De ansatte forutsetter at bedriften kan tilby gode og moderne verktøy (les: systemer), slik at arbeidet kan utføres effektivt og lystbetont. Når en ressurs defineres som infrastruktur blir det samtidig vanskeligere å bruke denne ressursen til å skape et konkurransemessig fortrinn. Slik er det også med de fleste systemene vi omgir oss med. Det kan tenkes at systemene representerte noe innovativt da de ble introdusert første gang, noe konkurrentene ikke hadde. I en slik innledende fase i et systems livsløp kan det defineres som en strategisk ressurs, men så snart en dominerende andel av konkurrentene anskaffer noe tilsvarende, må systemet redefineres til å være infrastruktur. Det vil si «noe vanlig», noe som ikke lenger skiller bedriften fra konkurrentene. Samtidig forstår vi at dersom en bedrift ikke har fulgt med i timen og

KAPITTEL 1

INTRODUKSJON

13

kommer til et punkt der systemene gjennomgående har en dårligere kvalitet enn det som er normen i bransjen, er det alvorlig. Bedriften har da, ofte selvforskyldt, navigert seg inn i en utsatt konkurranseposisjon. Eller for å være helt presis – systemene utgjør en strategisk trussel. Man har opparbeidet en tyngende teknisk gjeld. På samme måte vil en bedrift som investerer i nye innovative systemer som bidrar til radikale endringer i drifts- eller styringsmodellen kunne hevdes å være av strategisk betydning. Rett og slett fordi de skaper et konkurransefortrinn. Inntil konkurrentene «kopierer» praksisen og dermed skaper en ny norm, en utvidet obligatorisk infrastruktur. Dette skal vi komme tilbake til senere i boken.

I denne boken vil jeg beskrive hvordan ledere på ulike nivåer kan bidra til å anskaffe, implementere og forvalte forretningssystemer som både understøtter effektiv drift, innovasjon og forretningsutvikling. Å bygge opp en infrastruktur av forretningssystemer krever et betydelig lederengasjement. Det er ikke et teknologisk prosjekt, men et prosjekt som domineres av tanker om prosessforbedring, markedsutvikling, kvalitetsforbedringer og relasjonsbygging. Derfor er slike prosjekter altfor viktige til å bli dominert av teknologer eller en gruppe eksterne konsulenter. Eksterne ressurser og teknologer er svært viktige bidragsytere, men det må presiseres at systemvalg, system­utforming og systemimplementering må være dypt forankret hos forretningsledere og ansatte. Av den enkle grunn at det er de som blir berørt, og som er ansvarlige for at systemene gir positive effekter og aller helst gevinster som kan måles på bunnlinjen. La oss kalle det klingende mynt.

Begrepet forretningsutvikling er for meg en samlebetegnelse for alle aktiviteter som bidrar både til å skape nye eller forbedrede produkter og tjenester, og nye eller for­bedrede måter å produsere, selge og levere disse tjenestene og produktene på.

Forretnings­utvikling kan med andre ord brytes opp i et antall dimensjoner, som f.eks.: • prosessutvikling • produktutvikling • tjenesteutvikling • markedsutvikling • kompetanseutvikling Det er grunn til å anta at alle disse utviklingsdimensjonene kan påvirkes av smart bruk av digitale teknologier. I denne boken vil jeg først og fremst konsentrere meg om prosessutvikling, og i noen grad tjeneste- og markedsutvikling.

Jeg har arbeidet med digitalisering siden midten av 70-tallet. Først og fremst med anskaffelse og implementering av transaksjonssystemer, så som økonomisystemer, logistikksystemer og produksjonssystemer. Dette er en type systemer (produkter) som vil bli nærmere omtalt i kapittel 4. I disse 45 årene har jeg kommet på innsiden av prosjekter både i privat og offentlig sektor, og både i store og små virksomheter.

14

FORRETNINGSUTVIKLING OG DIGITALISERING

Dette har gitt en betydelig grad av erfaringsbasert læring og som danner et viktig fundament for denne boken. I samfunnsvitenskapen er det en vitenskapelig metode som heter deltakende observasjon som innebærer at forskeren nettopp deltar i de prosessene som skal studeres. Metoden er mye brukt av sosialantropologer, men også av sosiologer som skal studere hvordan grupper av mennesker samhandler på en arbeidsplass for å nå et felles mål. Dette er en ganske dekkende beskrivelse for min tilnærming til forskning.

Jeg har deltatt i, og studert, prosjektgrupper på nært hold. Studert hvordan beslutninger fattes og hvordan valg tas. Jeg har sett hvor viktig miljøet i prosjektgruppen er for utfallet – at kunde og leverandør samarbeider godt og trives i hverandres selskap. Noe som er helt avgjørende for også å kunne håndtere kriser, komplikasjoner og ikke minst uenigheter, som alltid vil oppstå i denne type prosjekter. Men jeg skal være forsiktig med å generalisere. Blant annet av den enkle grunn at prosjektets resultater kan ha blitt påvirket av min egen deltakelse, noe som faktisk var litt av hensikten. I vitenskaps­ teorien kalles dette for Hawthorne-effekten. Det er betegnelsen på et fenomen som ble dokumentert i forbindelse med Hawthorne-studiene i USA i 1920-årene, nemlig at det å bli undersøkt i seg selv frembringer atferdsendringer. Dermed kan det skapes et feilaktig inntrykk av at en årsaksvariabel kan ha innvirkning på effektvariabelen.

Denne effekten er ikke lett å måle, og kan medføre bias i forskerens resultater. Jeg må derfor være varsom når jeg konkluderer.

Det avsluttende arbeidet med denne boken er gjennomført i en meget spesiell tid preget av en pandemi vi ikke har erfart i moderne tid. Koronaviruset lammet samfunnet våren 2020. En interessant følge av denne krevende situasjonen var det jeg vil betegne som en tvungen digitalisering, der seminarer, møter og sosial kontakt ble flyttet til digitale plattformer. Må man så må man, og for mange var læringskurven bratt. Den digitale atferd ble løftet til et helt nytt nivå, og med gode resultater. Det virket, vi fikk det til. Når butikkene stengte måtte vi ty til digitale handelsplattformer. Kjøp av matvarer på nett fikk en betydelig oppsving, noe bl.a. Kolonial.no fikk erfare. En kritisk faktor for å håndtere den store etterspørselen var nettopp den digitale plattformen, i denne sammenheng en kombinasjon av en velfungerende nettbutikk og integrerte logistikksystemer.

Koronapandemien var for mange en vekker, både når det gjelder mulighetene som ligger i digitale samhandlingsplattformer og ikke minst viktigheten av å støttes av moderne systemer som kan nås fra hvor som helst via internett. Hjemmekontoret ble den nye normalen. Selskaper som slet med tung teknisk gjeld, dvs. utdaterte forretningssystemer og gammel teknisk infrastruktur, fikk alvorlige forretningsmessige utfordringer.

Min påstand er at når denne vanskelige tiden er over vil det føre til varige endringer i atferd, og mange virksomheter vil iverksette en digital moderniseringsprosess. Da vil de kunne ha god nytte av å lese denne boken.

KAPITTEL 1

INTRODUKSJON

15

Begrepet digitalisering – I de siste to årene har jeg med stigende interesse registrert den økende bruken av begrepet digitalisering. Vi møter det i avisartikler, på konferanser, i undervisning og ikke minst i dagligtalen. La oss dvele litt ved hva dette begrepet faktisk betyr. Store norske leksikon (Dvergsdal, 2019) har en ganske jordnær og praktisk tilnærming, og mener det omfatter to dimensjoner: 1. Å gjenskape en fysisk prosess, hendelse, eller et fenomen digitalt, i form av tallverdier til en gitt matematisk modell. Betydningen brukes blant annet om digitalisert lyd og bilde.

2. Å ta i bruk datatekniske metoder og verktøy for å erstatte eller effektivisere manuelle eller fysiske oppgaver. Denne betydningen gjelder når en bruker datateknikk for å produsere varer og tjenester eller for å opprette infra­ strukturer som datanett og datasamlinger. Eksempler på bruk: digitalisering av telenettet; digitalisering av offentlig sektor; elektroniske resepter.

Jeg tror det er lett å støtte denne definisjonen, men det er samtidig mulig å argumentere for at begrepet ofte assosieres med en dyp, innovativ og enkelte ganger disruptiv anvendelse av teknologien. Det vil si at dyp digitalisering representerer et bestemt nivå på en modenhetsskala. Et nivå som ligger over det som jeg tidligere har betegnet som det infrastrukturelle nivå. Det betyr at dyp digitalisering kan bety å utvide bruken av teknologi til helt nye anvendelsesområder som åpner for en ny tilnærming til markedet, ofte i form av nye produkter og tjenester, eller en endret modell for fordeling av oppgaver mellom kunde og leverandør (digital samhandling). Denne type teknologianvendelse krever ofte nye måter å organisere seg på, og noen ganger også en redefinering av forretningsmodellen. Det interessante er at denne type teknologibruk forutsetter en god digital infrastruktur, dvs. et godt fundament, blant annet et godt ERP-system (enterprise resource planning).

Begrepet ERP blir grundig behandlet i kapittel 4. Men la oss allerede slå fast at betegnelsen ERP ble skapt av analyseselskapet Gartner tidlig på 90-tallet. Det handler om et system som støtter et bredt spekter av virksomhetskritiske prosesser knyttet til varestrøm og pengestrøm. Det viktigste kjennetegnet ved denne type systemer er integrasjon og transaksjonsbehandling. De lange varestrømprosessene forutsetter god integrasjon. På samme måte som god transaksjonsbehandling forutsetter enhetlige behandlingsregler og god datakvalitet. Det er her ERP-systemet har sitt viktigste verdibidrag. En hovedgrunn til at ERP-systemet går igjen som en rød tråd i denne boken er at ingen bedrifter kan velge det bort. Spørsmålet er bare hvilken form det skal ha, hva det skal støtte (prosesser) og hvilken leveranseform som er best. Det første spørsmålet er krevende, det andre ganske enkelt. Enkelt i den forstand at den klart dominerende trenden er SaaS (software as a service). I dagligtalen er det flere måter å betegne ERP på. Selv har jeg i flere år benyttet begrepet bunnsvillen. I og med at jeg opprinnelig er

16

FORRETNINGSUTVIKLING OG DIGITALISERING

sivilingeniør med spesialisering innen byggfaget er dette en naturlig metafor. Det meste vi gjør innen digitaliseringsfeltet starter med en god bunnsvill. Men jeg merker meg samtidig at leverandørmarkedet i økende grad bruker betegnelsen kjernesystem. Også dette er et godt uttrykk og sier noe om betydningen. Jeg vil komme til å bruke begge betegnelsene i denne boken, i tillegg til de tradisjonelle og godt rotfestede begrepene system og løsning. Digitalisering inkluderer, i tillegg til ERP-systemet, ofte et bredt spekter av teknologier som f.eks.: • apper av ulike slag • IoT (internet of things) • machine learning • kunstig intelligens (AI, artificial intelligence) • roboter • chatbot • blockchain På BI har vi etablert et senter for digitalisering som ledes av tidligere nevnte Espen Andersen og førstelektor Ragnvald Sannes. De har tatt digitaliseringsbegrepet til et nytt nivå, og definerer det som følger: «Digitalisering er transformasjonen fra at IT er et støtteverktøy i virksomheten til at det er en del av dens DNA. Det betyr at forretningsmodell, organisasjon og prosesser er designet mht. å utnytte dagens og morgendagens teknologi» (Andersen & Sannes, 2017). Dette er en definisjon som jeg mener fanger tidsånden på en meget god måte og som samsvarer med mitt synspunkt om at digitalisering som begrep reflekterer et visst modenhetsnivå og en bestemt holdning til de digitale teknologiers viktighet og potensial.

Jeg henviste innledningsvis til Nicolas Carr, som definerte begrepet IT-infrastruktur.

Det kan være vel så interessant å referere til en annen amerikaner, nemlig Marc Andreessen, og hans berømte artikkel «Why Software Is Eating The World» i The Wall Street Journal i 2011. Dette er en tittel som ble brukt på forsiden av Dagens Næringsliv 10. januar 2017 (ref. figur 1.1). Poenget er at programvare som evner å utnytte det fremste av hva markedet kan frembringe av moderne informasjonsteknologi (IT) gjør det mulig å automatisere prosesser, transaksjoner og oppgaveløsning på en måte vi aldri tidligere har sett. Dette kan ha betydning for arbeidslivet i den forstand at enkelte yrkesgrupper kan bli utkonkurrert av teknologi. Jeg minner om det som skjer i bankverden, der f.eks. yrkestittelen «kasserer», dvs. hun som møtte kundene i skranken, nærmest er utradert. I en artikkel i Nettavisen så tidlig som 26. januar 2017 sier konsernsjef Rune Bjerke i DNB at banken etter all sannsynlighet vil halvere staben i løpet av de nærmeste 5–10 årene. Det er dramatisk, og det skjer som følge av smart digitalisering og endret kundeatferd. På samme tid, i en artikkel i DN den 15. mai 2017, beskrives en suksesshistorie fra Borregaard, der man ved hjelp av robotteknologi har klart å styre fabrikkene på en svært effektiv måte. Å styre en fabrikk handler i dag om å sitte i et såkalt «digitalisert kontrollrom», ikke nødvendigvis på fabrikken, men et

KAPITTEL 1

INTRODUKSJON

17

passende sted der alle produksjonsprosesser kan monitoreres og styres fra et avansert kontrollpanel. Det er faktisk mer et spørsmål om produksjonsovervåking enn om produksjonsstyring, fordi den ansatte først og fremst skal håndtere varsler om avvik. Det er ikke tilfeldig at jeg tar frem disse oppslagene fra 2017. Jeg vil nemlig senere i boken argumentere for at vi nådde et viktig vendepunkt i 2016. Da uttalte bl.a. analytikeren Nigel Rayner på et Gartner-symposium i Barcelona at «business applications are undergoing the biggest level of change since the 1990s».

Jeg minnes at min far, med stor entusiasme, beskrev den mekaniske desimalregnemaskinen (figur 1.2) som gjorde data om til sifferform. For hver sifferposisjon kunne man ha 10 tilstander (0–10). I det binære systemet kunne man derimot bare ha to tilstander for hver posisjon (0–1), noe som var helt nødvendig når selve regneoperasjonen gikk fra å være mekanisk til elektronisk. Den mekaniske regnemaskinen var på mange måter utgangspunktet for vår tids datamaskiner og kalkulatorer.

Figur 1.2 Den «digitale» mekaniske regnemaskin anno 1950 Figur 1.1 Digitalisering anno 2017

DAGENS NÆRINGSLIV 10. JANUAR 2017

NETTAVISEN 26. JANUAR 2017

FINANSAVISEN 15. MAI 2017

La oss ta et steg tilbake og drøfte definisjonen til BIs senter for digitalisering. Den impliserer helt klart at IT videreutvikles fra å være obligatorisk infrastruktur til å bli en strategisk ressurs. Dermed kan det hevdes at kreftene er snudd, i den forstand at det er teknologiens iboende potensial som til en viss grad setter premissene for hva som er fornuftig organisering, gode prosesser og riktig forretningsmodell.

Hva betyr så begrepet digital i en språkvitenskapelig kontekst? Det etymologiske opphavet er det latinske digitus, som igjen er tatt inn i det engelske språk som substantivet digit. Som en kuriositet kan jeg nevne at digitus betyr finger, og som i Romerriket ble brukt som en betegnelse på en lengdeenhet, nærmere bestemt en fingerbredde (1,65 cm). Det engelske ordet digit betyr som kjent tall, og er, som man forstår, utgangspunktet for vår betydning av ordet digital. Det motsatte av digital er som kjent analog.

18

FORRETNINGSUTVIKLING OG DIGITALISERING

Verbet å digitalisere betyr å gjøre noe om fra analog til digital form. Det er dette verbet som har vært gjenstand for en nominalisering, som i språkvitenskapen betyr å lage et substantiv av et verb. Digitalisering er et slikt konstruert substantiv som mer presist kalles et verbalsubstantiv. Begrepet digitalisering viser til (eller tilsvarer) prosessen å digitalisere. I utgangspunktet er det et verdinøytralt substantiv, i den forstand at digitalisering kan være både vellykket og mislykket. I definisjonen til BIs senter for digitalisering er derimot, som tidligere antydet, begrepet gitt en utvidet og utelukkende positiv betydning. Det kan naturligvis diskuteres om det er en riktig vei å gå.

KAPITTEL 1

INTRODUKSJON

19

Jeg vil derfor gi definisjonen en, etter mitt skjønn, viktig forklarende undertekst som kunne lyde som følger: Forutsetningen for en vellykket digitalisering er at styret og bedrifts­ledelsen endrer holdning fra å se på digitale teknologier (DT) som et kostnads­krevende støtteverktøy til å se på DT som en potensielt verdiøkende del av virksomhets­­ arkitekturen. Det betyr at både forretningsmodell, organisasjon og prosesser kan bli sterkt påvirket som en følge av de muligheter som ligger i utnyttelse av

digitisering. Digitalisering forutsetter at man retter et kritisk blikk mot prosessenes formål, struktur og forretningsregler.

Begrepet digital transformasjon bør også sees i sammenheng med anvendelse av disruptive digitale teknologier, dvs. teknologier som erstatter eksisterende teknologier som har en opparbeidet en posisjon i en bransje. Slike teknologier har et potensial for utnyttelse som langt overgår de som blir erstattet. Blockchain kan f.eks. betraktes som en disruptiv teknologi fordi den skaper en helt ny mulighet for sikring (forsegling) av informasjonspakker som utvikles i en prosess.

dagens digitale teknologier (DT).

Digitalisering som fenomen er en del av samfunnsdebatten og et svært viktig tema i mange akademiske miljøer. I enkelte artikler i den mer kulørte del av fagpressen har jeg merket meg at det ofte benyttes to begreper, nemlig digitization og digitalization.

Dette er nyanser som ikke benyttes så ofte i norsk dagligtale. Mye tyder på at enkelte mener at digitization representerer den enkleste form for modernisering av prosesser, f.eks. digitalisering av dokumenter og anvendelse av noen spredte digitale funksjoner innen ulike bruksområder. Digitalization blir dermed knyttet til den dypere og bredere anvendelse av digitale teknologier. Ofte i en slik grad at driftsmodellen endres og kundenes adferd likeså. Dette er i så fall i tråd med den betydningen BIs senter for digitalisering legger i begrepet.

For ytterligere å påpeke potensialet som ligger i de digitale teknologier bruker vi stadig oftere begrepet digital transformasjon. Det er naturlig å tenke seg at dette reflekterer en høyere grad av teknologiutnyttelse enn det vi vanligvis legger i begrepet digitalisering. Digital transformasjon innebærer en radikal endring, ofte i form av en endret forretningsmodell. Når forretningsmodellen endres, vil bedriften skape verdi (inntjening og resultat) på en helt ny måte. Når driftsmodellen endres radikalt, vil også bedriftens måte å produsere og levere produkter og tjenester på endres – f.eks. som følge av automatisering og robotisering. En radikal endring av driftsmodellen kan imidlertid skje uten å endre forretningsmodellen.

Kort oppsummert har vi å gjøre med tre ambisjonsnivåer: nemlig digitisering (digitization), digitalisering (digitalization) og digital transformasjon (DT, digital transformation) (figur 1.3). Ofte observerer jeg at bedrifter hevder å ha digitalisert prosesser, mens det ved nærmere ettersyn er en ren digitisering. I dagligtalen snakkes det ofte om å «sette strøm på en gammel manuell prosess». Da er det digitisering, fordi man viderefører prosessens struktur ukritisk. I Aftenposten-kronikken «Smerten ved digital endring er umiddelbar. Gevinsten kommer på sikt» skriver Camilla Tepfers (inFuture) og Håkon Haugli (Innovasjon Norge) til ettertanke: «Det er stor forskjell på virksomheter som ettermonterer teknologi på eksisterende prosesser, og dem som tar en helhetlig tilnærming for å gi bedre bruker- og kundeopplevelser og mer effektiv drift» (Tepfers & Haugli, 2019). Dette er etter mitt skjønn den beste beskrivelsen på forskjellen mellom digitisering og digitalisering. Å ettermontere digitale teknologier er per definisjon

20

FORRETNINGSUTVIKLING OG DIGITALISERING

Figur 1.3 Tre ambisjonsnivåer

1. Meget høyt —> digital transformasjon Når resultatet fører til endring i selskapets forretningsmodell og/eller radikal endring i måten verdier skapes på (driftsmodell).

2. Høyt —> digitalisering Når resultatet fører til vesentlige endringer i forretningsprosessene i en slik grad at kostnadene reduseres samtidig som kundene responderer positivt.

3. Lavt —> digitisering Når resultatet bare er en overgang fra analog til digital representasjon uten vesentlige endringer i forretningsprosessene eller i måten man kommuniserer med markedet generelt og kundene spesielt.

Det kan også være interessant å analysere begrepet digitalisering i lys av hvordan språket (dagligtalen) utvikler seg over tid. Dersom vi går tilbake til 80-tallet brukte vi begrepet EDB (elektronisk databehandling) i den folkelige dagligtale. Begrepet digital var et begrep for ekspertene, noe vi leste om i den tekniske EDB-litteraturen. I løpet av 90-tallet fikk vi et fullstendig begrepsskifte fra EDB til IT eller IKT (informasjons- og kommunikasjonsteknologi). På 2000-tallet fikk vi, i kjølvannet av internett og netthandel, en ny begrepsdannelse rundt bokstaven «e» for elektronisk. Vi snakket om e-handel (e-commerce) og elektronisk forretningsdrift (e-business). Alt handlet om «e». Det er, slik jeg ser det, denne bokstaven «e» som nå er erstattet med «digital-».

I litteraturen har jeg merket meg at det i økende grad fokuseres på det digitale selskap; som en samlebetegnelse for virksomheter som kan betegnes som digitalt modne og som

KAPITTEL 1

INTRODUKSJON

21

har evnet å digitalisere både den interne og eksterne samhandlingen: «The Digital Firm is a general term for organizations that have enabled core business relationships with employees, customers, suppliers, and other external partners through digital networks» (Laudon & Laudon, 2009). I det digitale selskap har man evnet å spinne et nettverk av digitale tråder som bærer både den formelle og uformelle informasjonsflyten mellom de ansatte og mellom virksomheten og omgivelsene. Men fundamentet for dette digitale nettverket er våre forretningssystemer og deres kapasiteter – det vil si ERP-, CRM- eller HRM-systemet. Disse vil bli behørig behandlet senere i denne boken.

Digitaliseringens ulike posisjoner Hvordan kommer så dette fenomenet (digitalisering) til uttrykk i konkrete løsninger?

La oss først ta for oss et begrep jeg allerede har benyttet, og som ofte brukes i sammenheng med digitalisering, nemlig ordet disruptiv. Det snakkes f.eks. om disruptive teknologier. Ordet disruptiv er opprinnelig engelsk og betyr i utgangspunktet noe forstyrrende eller banebrytende. Å snakke om banebrytende teknologier gir mening.

Likeledes forstår vi hva som menes når innarbeidede forretningsmodeller og rutiner forstyrres (utfordres) som følge av de mulighetene som ligger i anvendelse av ny banebrytende teknologi. Den som kanskje har hatt den sterkeste, og mest faglig funderte, definisjonsmakten når det gjelder begrepet disruption, er den amerikanske Harvardprofessoren Clayton M. Christensen. Allerede i 1995 behandlet han temaet i artikkelen «Disruptive Technologies: Catching the Wave» (Christensen & Boweer, 1995). Senere erstattet han begrepet med disruptive innovation fordi han la mer vekt på teknologiens anvendelse og de effekter dette ga.

I figur 1.4 beskriver jeg fire ulike posisjoner som representerer fire digitale ambisjonsnivåer. Den første posisjonen kaller jeg transaksjonsorientert digitalisering. Vi kan gjerne si at dette er digitaliseringens utgangspunkt, det vil si når vi anvender systemer og teknologi som et støtteverktøy i forretningsprosessene. Tenk på kjerneprosesser som regnskapsføring, lønnsadministrasjon, lagerstyring og ordrebehandling. Helt siden 70-tallet har vi anvendt administrativ programvare for å forenkle og støtte disse prosessene. Det er bokstavelig talt en gammel digital historie, der den ansatte fortsatt spilte hovedrollen som bruker. Transaksjoner skulle registreres. Regnskapsmedarbeideren registrerte bilag og skapte dermed en digital regnskapstransaksjon. Lagermedarbeideren registrerte hvilke varer som ble tatt ut av lageret og skapte dermed en digital lagertransaksjon. Slik kunne vi fortsette. Et hovedpoeng med denne opprinnelige form for digitalisering var å gjenskape forretningshendelser i digital form – som transaksjoner.

Derav navnet transaksjonsorientert digitalisering.

Men denne tradisjonelle digitaliseringen har det siste tiåret utviklet seg i form av flere automatiserte transaksjoner. Det betyr f.eks. at innkjøp skjer automatisk (basert på overvåking av lagernivåer) og at fakturaer i EHF-format (elektronisk handelsformat)

22

FORRETNINGSUTVIKLING OG DIGITALISERING

skapes og sendes via nettet med marginal innblanding fra en regnskapsmedarbeider.

Systemene spiller en stadig større rolle.

Den andre posisjonen (2) har jeg valgt å kalle prosessorientert digitalisering. Nå begynner det å bli noe mer krevende fordi det handler om en dypere form for automatisering, ofte av prosesstrinn der systemet må gjøre noen valg basert på programmerte eller parametersatte regler. Mange vil f.eks. hevde at regnskapsbransjen er en døende næring, fordi selve bokholderiet (regnskapsføringen) vil kunne automatiseres. Enkelte velger å kalle dette for robotisering. Ikke en fysisk robot, slik vi som oftest assosierer begrepet, men en virtuell robot i form av et program. Et mye brukt akronym i denne sammenheng er RPA (robotic process automation). Dette er en form for prosessautomatisering der roboten trer inn i brukerens rolle. Det betyr at roboten er et programprodukt som simulerer en såkalt bruker-maskin prosess. Med stor presisjon og 24 timer i døgnet, om det er ønskelig. Fordelen med en slik form for prosessautomatisering er at den kan anvendes på programvare som ikke har et potensial for å automatisere prosesser på egen hånd. Man kan hevde at dette kan betraktes som en midlertidig løsning som vil erstattes av ERP-programvare med automatiseringsmuligheter som en del av standard­ egenskapene. Eksempler på leverandører av RPA-programvare er BluePrism og UiPath.

I denne posisjonen (2) har jeg også tatt inn IoT (internet of things). Dette er også en viktig komponent i forbindelse med automatisering. Tekniske installasjoner kan utstyres med sensorer som overvåker og «rapporterer» eventuell slitasje og andre tilstander som krever service. Det betyr at en serviceprosess kan iverksettes automatisk, uten at noen på forhånd har inspisert installasjonen. Den økende bruken av IoT-teknologi kan sees på som et eget digitaliseringsspor som ofte betegnes sensorisering.

I den tredje posisjonen bruker jeg begrepet kognitiv digitalisering. Dette handler om kognitiv databehandling på et betydelig mer avansert nivå enn i forrige posisjon.

I mer folkelig og forenklet tale kan vi si at denne posisjonen handler om analyse- og beslutningsautomatisering, dvs. en forutsetning for prosessoptimalisering. Teknologibegreper som AI (artificial intelligence) og ML (machine learning) er meget relevante i denne posisjonen. Et godt eksempel er IBMs Watson-teknologi, som er et system med betydelig grad av analyse- og «tankekraft», for å si det litt pompøst. Nøkkelen til Watsons suksess er to ting: Evnen til å håndtere eventyrlige datamengder (big data) kombinert med meget avanserte algoritmer – algoritmer som utvikler seg basert på læring. Dette er en teknologi som har gitt banebrytende (disruptive) resultater, f.eks. innen kreftforskning. Vi erfarer imidlertid at denne form for avanserte «tenkende» systemer vil finne sine anvendelsesområder også i det private næringsliv.

I den siste posisjonen (X), som jeg betegner eksternalisert digitalisering, skjer det noe radikalt nytt. Oppgaver flyttes bokstavelig talt ut av virksomheten og legges i kundens hender. Vi kaller det ofte selvbetjening. Det første vi assosierer med selvbetjening er apper på mobile enheter og ulike former for chatbots. Chatbots, eller digitale assistenter, kan svare på spørsmål som stilles fra en bruker, enten en ansatt eller en kunde. Poenget er at denne type teknologier har et potensial til å kunne lære, dvs. at den over tid opparbeider

KAPITTEL 1

INTRODUKSJON

23

en evne til å svare på flere spørsmål med stadig høyere grad av presisjon. Suksessformelen for denne type forflytning av oppgaver til kunder kan sammenfattes i ett ord: forenkling. Vi ser det i tjenester som RuterBillett-appen, Vipps, Easypark, nettbank og netthandel generelt. Jeg kaller dette for hverdagsdigitalisering fordi denne type løsninger gjør hverdagen enklere, ofte i form av større fleksibilitet. Begrepet eksternalisering har sitt utgangspunkt i det latinske adjektivet ekstern, som betyr det ytre. Verbet eksternalisering betyr derfor å gjøre ekstern. I vår sammenheng betyr det at prosesser som tidligere har vært interne i en bedrift, altså utført av egne medarbeidere, løftes ut av bedriften og eksponeres for de som prosessen faktisk angår. Å betale en regning i banken er en prosess som angår meg som privatperson, og utføres derfor av meg i nettbanken. Det er i prinsippet ingen bankansatte involvert i prosessen. For noen tiår tilbake var det omvendt; i den forstand at prosessen (betaling) foregikk i en bankfilial (internt i bankens bygg) av bankansatte (interne bankansatte). Med andre ord en helt motsatt situasjon.

Betalingsprosessen er eksternalisert, og i noen grad er den også automatisert gjennom bruk av f.eks. automatisk trekk på konto. I sin ytterste konsekvens er verken bankansatte eller vi som forbrukere involvert i betalingsprosessen. Vi er bare involvert i etablering av prosessen (avtalegiro) og eventuell terminering av prosessen (avslutte kundeforholdet).

Kjøp av varer på nettet kan også kategoriseres som en form for eksternalisert digitalisering. Her er knytningene inn mot ERP-systemet av stor betydning fordi et kjøp på nettet alltid har økonomiske og logistiske konsekvenser. Dvs. at dette er prosesser som i all hovedsak løses i ERP-systemet. Som man ser av figur 1.4 kan og skal posisjon X alltid koples med én av de øvrige posisjonene. Det interessante er at koplingen er langt mer sofistikert og «intelligent» mellom X og 3, enn mellom X og 2.

Figur 1.4 Digitaliseringens posisjoner

­

24

FORRETNINGSUTVIKLING OG DIGITALISERING

Som man ser inngår begrepet ERP i tre av posisjonene (1, 2 og 3). I posisjonen eksternalisert digitalisering er ERP-systemet eller andre typer av kjernesystemer (banksystemer og andre bransjerettede plattformer) skjult for brukeren fordi de forholder seg til apper som kjører på deres egen mobile enhet.

Hvordan skal så bedriftene forholde seg til dette relativt komplekse bildet? En fornuftig digital strategi bør være å starte med opprydding i posisjon 1, transaksjonsorientert digitalisering. Det innebærer å modernisere ERP-plattformen og tilgrensende systemer, og vurdere hvordan prosessene kan forbedres (BPI – business process improvement).

Som et trinn 2 søker man seg mot posisjon 2, dvs. mot prosessorientert digitalisering (BPA – business process automation). I trinn 3 beveger man seg mot posisjon 3, dvs. kognitiv digitalisering ved hjelp av AI, ML og Watson-lignende teknologier. Hensikten med å bevege seg til posisjon 3 er en ytterligere automatisering og optimalisering av prosessene (BPO – business process optimization).

Hovedbudskapet er med andre ord at man må gå frem steg for steg, samtidig som det må understrekes at det er en glidende overgang mellom posisjonene. Hvor ble det av posisjon X i denne gjennomgangen? Slik jeg ser det bør man som en hovedregel ikke eksternalisere før man er i posisjon 2. Det er egentlig ganske åpenbart, fordi de eksterne aktørene trer inn i en prosess som skal utløse (trigge) neste steg i prosessen.

Dette krever en betydelig grad av prosessintegrasjon og automatisering.

Det viktige budskapet i figur 1.4 er med andre ord at man må utvikle sin ERP-plattform trinn for trinn. Det er f.eks. vanskelig å tenke seg at man tar spranget fra posisjon 1 til posisjon 3 direkte. Man må gå alle stegene. Den eksternaliserte del av løsningen blir aldri bedre enn kvalitetene i den plattformen som ligger bak. Det betyr at posisjon X i kombinasjon med posisjon 3 representerer en langt mer sofistikert og intelligent kundedialog enn den man kan klare å oppnå i kombinasjon med posisjon 2.

Den form for eksternalisering som er mest aktuell for handelsorienterte virksomheter, er introduksjonen av digitale handelsplattformer som inkluderer netthandel. Dersom vi omformer figur 1.4 og spisser budskapet inn mot forholdet mellom ERP-systemet og handelsplattformen, vil vi kunne fremstille utviklingen som vist i figur 1.5. Her trekker vi de store linjer tilbake til 1992, da ERP-begrepet ble skapt. La oss kalle det ERP 1.0. Fra dette tidspunktet går det et utviklingsspor mot 2016, dvs. ERP 4.0. ERP 4.0 kan lett assosieres med Industry 4.0, som var et viktig statlig tysk initiativ initiert allerede i 2012, der man etablerte et sett med anbefalinger for hvordan man ved hjelp av digitale teknologier kunne automatisere og optimalisere industrielle prosesser med betydelige effektresultater.

KAPITTEL 1

INTRODUKSJON

25

Det viktige budskapet i dette bildet er at dagens kunder krever intelligente nett­ butikker, for å si det litt enkelt. I dette ligger et ønske om at handelssystemet skal tolke vår atferd på nettet (kundereisen) og proaktivt anbefale det beste produktet. Dette er egenskaper vi allerede kjenner igjen når vi f.eks. benytter Amazons nettbutikk for å kjøpe bøker. Alle anbefalinger om f.eks. supplerende kjøp er basert på komplekse algoritmer. Vi ser en klar tendens til at denne type egenskaper implementeres i nær sagt alle typer netthandel. Dette er kognitiv digitalisering i sin mest rendyrkede form.

Figur 1.5 Utviklingen mot intelligente handelsplattformer

+

­

) *" ) * * * , * " ) ( * ) () * ** ) ) )

) * * ) ) * )," ) * ) " , * ) * , * ) () * ** )

) * ) ) , * ) * * , * ) () * ** ) ) * ** )

­ ­

Business Process Automation (BPA)

Business Process Improvement (BPI) 0 # 0 # 0

) ) *( )

(

) * "* *) * ) ) () * ** ) ) )

!& $! & % $ !

BPM representerer en samling aktiviteter for planlegging og overvåking av ytelsen til en prosess. Begrepet refererer vanligvis til styring av forretningsprosesser og produksjonsprosesser. Begrepene forretningsprosessledelse (BPM) og endring av forretningsprosesser (BPR) er innbyrdes relatert, men ikke identiske.

Automatisering av forretningsprosesser (BPA) er strategien en bedrift anvender for å endre kostnadsstrukturen i en prosess fra å være dominert av lønnskostnader til å være dominert av teknologikostnader. I tillegg skal automatisering medføre at prosessen flyter raskere og leverer resultater med høyere kvalitet (lavere feilmargin).

Business Process Management (BPM)

Forbedring av forretningsprosesser (BPI) er en systematisk tilnærming for å forbedre og effektivisere forretningsprosessene. Metodikken ble først dokumentert i H.J. Harringtons bok Business Process Improvement (1991). Det er metoden som bl.a. business process reengineering (BPR) er basert på. Begrepet gir sterke assosiasjoner til «kontinuerlig forbedring» og LEAN.

Business Process Reenginering (BPR) Reorganisering av forretningsprosesser (BPR) er en strategi og metodikk skapt på begynnelsen av 1990-tallet, med fokus på analyse og redesign av arbeidsflyt og forretningsprosesser i en organisasjon. Målet med BPR var å redusere driftskostnadene, øke kunderservicen og dermed styrke sin konkurranseposisjon i markedet. Tankegodset bygger på Professor T.H. Davenports teorier og publikasjoner.

%& $! % $& & % $ !

Business Process Orientation (BPO)

Gjennom de siste 30 årene har ledende akademikere skapt begreper og teorier innen det store temaet «hvordan kan vi jobbe smartere». Her samler jeg de viktigste begrepene og henviser så langt det er mulig til hvem som skapte begrepet, når det ble skapt og hva det faktisk betyr. Alle disse begrepene har det til felles at digitale teknologier kan utgjøre et virkemiddel for å oppnå målene.

26

FORRETNINGSUTVIKLING OG DIGITALISERING

Konseptet med forretningsprosessorientering (BPO) er basert på teoriene til bl.a. kjente akademikere som Davenport, Hammer og Porter. Hovedpoenget er at organisasjoner må designes (organiseres) med utgangspunkt i de prosesser som skal utøves. Virksomhetens mål, dens prosesser og strukturer må utgjøre en konsistent helhet.

KAPITTEL 1

INTRODUKSJON

27

Digital kompetanse

Disse to punktene vil jeg gi min fulle støtte, og det er et svært godt samsvar mellom Lais definisjon av digital kompetanse og innholdet i den sekspunktslisten jeg selv har utviklet. Den inneholder følgende elementer (merk at koplingen mellom Lais og mine egne punkter er nr. 1 og 4): 1. ferdigheter i bruk av systemer og teknologi 2. kompetanse til å vurdere potensialet for digitalisering 3. kunnskap om bedriftens digitale posisjon relativt i forhold til konkurrentene 4. kunnskap om teknologiske utviklingstrekk 5. kunnskap om digital sikkerhet og sårbarhet 6. kunnskap om hva som er digital dannelse

I de siste årene har begrepet digital kompetanse vært gjenstand for mye oppmerksomhet og debatt. I en spennende analyse utført av KPMG i 2014 på oppdrag fra Kommunalog moderniseringsdepartementet, ble det reist følgende spørsmål: Hva er til hinder for å digitalisere forretningsprosesser? Det er nesten et retorisk spørsmål. Svaret ser dere i figur 1.6. Desto høyere tallverdi, desto større er hinderet.

Figur 1.6 Hva er til hinder for digitalisering?

* ) ! $ +

#(

- 0 : % .

0 . % .% #

.# % 0 .% % .

1(01. % .

1.% % 9 . #1( 0 .% % .

% % .

( #% % .

Det som fanget min interesse, er særlig følgende to ting. For det første fant de at det ikke er teknologien i seg selv, eller mangel på denne, som er til hinder for digitali­ seringsprosessene. For det andre fant de at det er tre store hindre som har å gjøre med kompetanse, organisasjon og kultur som særlig skaper problemer i digitaliserings­ prosessene. Jeg vil velge å kalle disse for myke hindre. I tillegg vil jeg hevde at hver av de tre hindrene sjelden opptrer alene. Jeg vil mene at organisatoriske hindre ofte har å gjøre med bedriftskultur. Det må også kunne hevdes at kompetanse og bedriftskultur henger nøye sammen. Jeg vil senere i denne boken behandle begrepet endringskapasitet. Dette begrepet henger nemlig svært nøye sammen med de myke hindrene. Organisatorisk motstand og manglende digital kompetanse kombinert med en konservativ bedrifts­ kultur («vi holder på det gamle») gir i sum lav endringskapasitet. Derfor må vi avstemme våre digitale ambisjonsnivåer med den endringskapasitet vi faktisk besitter. Misforstå meg rett: Endringskapasitet må ikke betraktes som en fastlåst tilstand. Den kan utvikles ved bevisste tiltak og trening. Se på endringskapasitet som organisasjonens muskel.

Min kollega, professor Linda Lai, skrev i en kommentar i Dagens Næringsliv høsten 2016 at «ledere har et ansvar for å bygge digital kompetanse». Hun konkretiserte begrepet digital kompetanse i en liste med seks punkter, der følgende to etter mitt skjønn er de mest relevante: • Ledere må ha nødvendig innsikt i eksisterende og fremvoksende teknologiske plattformer og verktøy.

• Ledere må ha evne til å bruke digitale teknologier som en integrert del av lederskapet.

28

FORRETNINGSUTVIKLING OG DIGITALISERING

. % .

Merk særlig punkt 6 (digital dannelse), som jeg mener er et underkommunisert tema.

I en hverdag der vi nesten alltid (24/7) bare er et tastetrykk fra å kunne irettesette, kommentere, gi ordre, kritisere og rose, kreves det betydelig selvdisiplin og klokskap for å opptre dannet. De såkalte nett-trollene er veldig svake på dette punktet.

Avslutningsvis kan vi oppsummere med at digital kompetanse hos ledere handler om evnen til forstå hvordan moderne informasjonsteknologi, i alle sine former, kan bidra til å utvikle, endre og støtte virksomheten både med hensyn til smart drift, bedre tjenester/produkter og noen ganger også en dreining mot nye forretningsmodeller. Målet er økt konkurransekraft. I tillegg handler det om å veksle inn den digitale kompetansen i konkrete digitale ambisjonsnivåer (målbilder) og realisering av disse.

La oss reflektere over sammenhengen mellom digitale prosjekter som feiler og begrepene digital modenhet og digital kompetanse. Min hypotese er at mange prosjekter feiler fordi leverandøren ikke har analysert kundens evne verken til å bidra i prosjektet eller ta inn over seg de organisasjons- og prosessendringer som satsingen legger opp til. Jeg forstår at i en salgssituasjon er det vanskelig for leverandøren å stille kritiske spørsmål til kundens kompetanse, modenhet og endringsvilje. Men det må gjøres, og da med takt og tone. En leverandør som utfordrer kunden på en saklig og høflig måte blir som oftest lyttet til. Vi kan kalle dette en motstandsanalyse som begge parter vil tjene på fordi ambisjonsnivåer, økonomiske estimater og planer vil kunne tilpasses de faktiske forhold. Dvs. en realorientering.

Systemenes formål Bedrifter tar stadig i bruk systemer for nye formål. Det er snart ikke en liten bortgjemt rutine som ikke støttes av et eller annet system, eller i det minste av en app. En slik utvikling krever klarsyn, planlegging og ikke minst meget god innsikt i bedriftens strukturer og forretningsregler. Vi må forstå hvordan bedriften skaper verdier, dvs. bedriftens verdikonfigurasjon, for å kunne legge til rette for den mest optimale systembruk. Vi må også forstå bedriften relasjon til markedet, dvs. til leverandører, kunder og partnere.

KAPITTEL 1

INTRODUKSJON

29

Dette er bokens formål – nemlig å behandle fenomenet IT-systemer i et organisasjonsperspektiv. Det betyr å drøfte hvordan fornuftig anvendelse av informasjonsteknologi kan gjøre bedrifter bedre i stand til å konkurrere i et stadig mer krevende marked. Det betyr at vi skal drøfte hvordan de ansatte forholder seg til sine arbeidsoppgaver ved å anvende systemer. I figur 1.7 vises tre grove stilarter for hvordan arbeid kan utføres. De to ytterpunktene er den manuelle stilarten, som gjennomføres uten hjelp av systemer og teknologi, og den helautomatiserte stilarten, som ikke involverer menneskelig arbeidskraft overhodet. Da kreves det imidlertid at arbeidsprosessen er forhåndsdefinert i systemet basert på et sett entydige forretningsregler. Midt mellom disse to ytterpunktene har vi den mest vanlige arbeidsstilen, nemlig den semiautomatiserte arbeidsprosess, som betyr at den ansatte som en hovedregel forholder seg til prosessen via et system.

Figur 1.7 Arbeidsutførelse i tre varianter

nisjesystemene som retter seg inn mot et meget begrenset utsnitt av virksomhetens forretningsprosesser, f.eks. lønnsadministrasjon, HRM eller CRM. I tillegg har vi en viktig kategori systemer som er bygget inn i fysiske produkter som f.eks. roboter og laboratorieutstyr. Til sist har vi en gruppe systemer som vi med en fellesbetegnelse kan kalle apper, og som har det spesielle kjennetegnet at de lastes til en mobil enhet (telefon eller nettbrett) og kjøres på denne enheten. Via API-baserte integrasjoner er de (front-end) koplet opp mot bakenforliggende forretningssystemer (back-end). Samlet sett utgjør disse kategoriene en form for arkitektur i den forstand at de fleste bedrifter vil ha systemkomponenter fra de fleste kategoriene. Dette vil bli utførlig behandlet senere i boken, men allerede nå kan vi beskrive en overordnet arkitektur (figur 1.8) som et anslag for den videre diskusjon.

Figur 1.8 Overordnet arkitektur

%!# " 0. * &+* 3 0 ) 0

Sentralt i denne boken står begrepet forretningssystemer, dvs. en type systemer som støtter og/eller automatiserer utførelsen av en strukturert forretningsprosess. Det betyr at jeg vil søke å definere ulike kategorier av forretningssystemer og belyse disse systemenes utforming, eller nærmere bestemt deres arkitektur. I tillegg vil jeg kaste lys over programvaremarkedet, dvs. avklare hvem som produserer og hvem som leverer denne type produkter. Kort sagt skal jeg behandle begrepet forretningssystemer både fra en teoretisk og praktisk vinkel, der jeg også vil drøfte produktet forretningssystem både med hensyn til egenskaper, utviklingshistorie, utbredelse og bransjeinnretning.

I sin mest grovkornede form vil jeg skille mellom noen viktige kategorier av forretningssystemer. I fokus står ERP-systemene, dvs. de bredt anlagte programsuitene som støtter både primærprosesser og støtteprosesser. I tillegg kommer de mer spesialiserte

30

FORRETNINGSUTVIKLING OG DIGITALISERING

5 - ( 3 0 ) . + 3 0 ) .

; ** < 0 . * 0 ) .

%

- )+ ( * (( . * 00 . 00 0

. * (( . ( +. 0+. 0 -.+ 1 &+* 10 03.

Bokens målgruppe er derfor alle som er, eller vil komme til å bli involvert i anskaffelsesog implementeringsprosesser. Dette omfatter et bredt spekter av ansatte, fra daglig leder til spesialister innen et avgrenset prosessområde. Det vil si mennesker med svært ulike forutsetninger for å gå inn i problemstillingene. For noen kan det skorte litt på den tekniske kompetansen, for andre kan det være de kontraktuelle juridiske sidene ved anskaffelsen som det mangles kompetanse på. Det er derfor et mål å nøytralisere disse forskjellene ved å skape en felles kunnskapsplattform for alle deltakere, uansett bakgrunn. Det er ingen tvil om at bedriftene jevnt over har blitt mer profesjonelle innkjøpere av forretningssystemer. Ofte er det garvede andre- og tredjegangskjøpere med stor faglig ballast som leder prosjektene. I tillegg uteksamineres det kandidater fra våre høyskoler og universiteter som har gjennomført IT-kurs som gir et godt akademisk fundament å ta med seg inn i prosjektene. Kort sagt er balansen mellom kunde og leverandør i kjøpsprosessen langt bedre i dag enn for 10 år siden.

KAPITTEL 1

INTRODUKSJON

31

P7-rammeverket Boken er bygget over et rammeverk som jeg har kalt P7 (figur 1.9). Dette rammeverket inneholder, ikke overraskende, syv dimensjoner som jeg mener det er viktig å ha faglig innsikt i og gode metoder og teknikker for å håndtere. La oss knytte noen kommentarer til hver av dem: Perspektiv (kapittel 2): Dette er nok den mest abstrakte dimensjonen, men handler i korthet om hvordan vi kan dekomponere en organisasjon i et antall domener som hver for seg består av komponenter med store fellestrekk. Hvert domene er i seg selv en arkitektur. Vi tar opp begreper som forretningsarkitektur og IT-arkitektur, samt ulike måter å beskrive disse på, både med tekst og bilder.

Penger (kapittel 3): Denne dimensjonen favner både kostnadssiden og gevinstsiden ved anskaffelse, implementering, forvaltning og utnyttelse av systemene. I tillegg vil jeg behandle ulike modeller for hvordan systemer prises (lisensøkonomi), enten som tradisjonelle on-premise-løsninger eller som SaaS-tjenester (software as a Service).

Et viktig avtalepunkt er hvilken eller hvilke betalingsmodeller man skal knytte til prosjektets tjenesteleveranser. Dette er definitivt et pengespørsmål, og handler om å velge mellom fastpris, målpris eller time for time. Temaet inkluderer derfor en drøfting av risikokostnader, insentiver og sanksjonsregler.

Produkt (kapittel 4): Her drøftes forretningssystemenes arkitektur og egenskaper. I dette ligger også en overordnet beskrivelse av systemenes tekniske konstruksjon samt en drøfting av brukeropplevelsens kvaliteter og de funksjonelle egenskaper. I denne dimensjonen er vi på produktnivå, dvs. at vi drøfter konkrete løsningskonsepter som f.eks. Microsoft Dynamics 365, SAP S/4 Hana og Oracle ERP-cloud.

Prosjekt (kapittel 5): Prosjektdimensjonen er nok den som de fleste vil kjenne seg godt igjen i. Det handler om hvordan vi organiserer et anskaffelses- og implementeringsprosjekt, og hvordan vi definerer en prosjektstyringsmodell (rapporteringsmodell) som egner seg for oppfølging av prosjekter med en betydelig iboende risiko.

Prosess (kapittel 6): Med begrepet prosess menes alle faser i et systems livsløp – fra ideen om et nytt system formes, modnes og forankres, til systemet avvikles og erstattes av noe nytt. Dette bør normalt være et livsløp som strekker seg over mange år. Vi opererer med fire hovedfaser i livsløpet: (1) modning og forankring, (2) anskaffelse, (3) implementering samt (4) drift og forvaltning. Det er bare fasene 2 og 3 som organiseres som et prosjekt. De øvrige fasene håndteres innenfor linjeorganisasjonens rammer.

Partner (kapittel 7): Med partner menes tjenesteleverandører som først og fremst har en relasjon (et partnerskap) med eieren av forretningssystemet. Det vil si konsulentselskaper eller driftsselskaper som bistår under implementering og senere drift og forvaltning av systemet. Men en partner kan også være en programvareutvikler som leverer et nisjesystem som beriker et sentralt ERP-system. Partnere og kunder utgjør til sammen et økosystem som nye kunder bokstavelig talt kjøper seg inn i.

Jeg vil senere hevde at omfang og kvalitet i økosystemet er de viktigste driverne for ERP-systemets utvikling.

32

FORRETNINGSUTVIKLING OG DIGITALISERING

Persepsjon (kapittel 4): Med begrepet persepsjon ønsker jeg å rette søkelyset mot en særlig

viktig egenskap ved alle systemer, nemlig det sanseinntrykket løsningen gir. Viktigere enn noen gang er det at vi designer enkle og intuitive programmer/tjenester som krever minimal instruksjon forut for bruk. Persepsjon handler om å oppfatte og tolke sanseinntrykk. Når vi bruker et forretningssystem er det først og fremst synssansen som anvendes. Sanseinntrykket er summen av systemets ytre design, tidligere kalt brukergrensesnittet. Det handler om bruk av farger, fonter og symboler samt organisering av brukerflaten. I dag er dette helt avgjørende egenskaper ved ethvert system, og derfor en kritisk suksessfaktor. Persepsjon etterfølges av tolkning og deretter en motorisk handling (trykke på en knapp). Persepsjon kan også sees i sammenheng med universell design, som betyr at løsninger er utformet med tanke på å kunne støtte alle typer brukere, også de med særlige behov som følge av f.eks. nedsatt syn. Denne dimensjonen peker kort sagt mot en dypere evaluering av løsningens bruksvennlighet. Begrepet kan også sees i sammenheng med «mental workload» (MWL), som beskriver hvilken kognitiv belastning brukeren blir utsatt for i en interaksjon med systemet. Rent vitenskapelig defineres MWL som følger: «Mental workload refers to the portion of operator information processing capacity or resources that is actually required to meet system demands.» (Eggemeier et al., 1991, s. 207)

I de følgende kapitlene vil jeg ta for meg disse syv dimensjonene fra tre ulike vinkler, nærmere bestemt teori, metoder og verktøy og praktiske eksempler. Hver dimensjon behandles i et eget kapittel, med unntak av persepsjon, som behandles sammen med produkt i kapittel 4.

Figur 1.9 P7-rammeverket

KAPITTEL 1

INTRODUKSJON

33