Det er mangt og mye man opplever. I lunsjen idag fortalte en av lunsjkameratene mine om en fyr hos seg som kom med en dyr, halvannet år gammel bærbar. Den hadde svart skjerm ... hvilket ikke er helt uvanlig. Etterhvert kom det frem hva som hadde skjedd. Familiens katte hadde pisset i den bærbare PC'en.

Hva gjør så denne personen (som er fast vitenskaplig ansatt på et institutt som har elektronikk som fokusområde)? Jo, han vil tørke PC'en, og den beste måten er å skru på strømmen, så det blir varme i elektronikken slik at kattepisset tørker opp, og en vifte som kan blåse det ut ... tenkte han. Etter lunsj skal de forsøke å ta ut harddisken og se om de i det minste kan få ut dataene.

Og sånn går dagene.

Man kan se på automatisering som en løk med flere skall, eller med flere lag eller nivåer. Innerst inne er kjerneaktiviteten i automatisering, men uten de ytre lagene blir det pislete og stakkarlige greier. La meg forklare:

• Innerst inne ligger funksjonaliteten. Dersom ikke en automatisert oppgave faktisk løser oppgaven som er målet, så er og blir den dysfunksjonell samme hvordan du snur og vender på det. Dette er gjennomføringen, og de som tror dette er alt det er ved automatisering, har misforstått noe fundamentalt.

• Neste nivå er stabilitet, som er et systems evne til å fortsette å virke over tid. Det motsatte - et ustabilt system - er noe som mer eller mindre faller sammen av seg selv. Stabilitet er viktig i en automatisert oppgave fordi den skal fortsette å kjøre gang på gang i overskuelig fremtid, men det tar tid og testing å sikre at den automatiserte oppgaven er stabilt spesifisert og programmert.

• Tredje nivå er robusthet, som er beslektet med stabilitet, men allikevel fundamentalt forskjellig. Med robusthet menes et systems evne til forsatt å virke selv om omgivelsene rundt det endrer seg. Et stabilt korthus fortsetter å stå av seg selv, mens et robust korthus i tillegg takler at du puster på det og rugger litt i bordet. Stabilitet er viktig for en automatisert oppgave fordi miljøet det skal kjøre innen, garantert kommer til å endre seg over tid - du har kanskje ikke planlagt endringene ennå, men de kommer!

• Det fjerde og siste nivået er elegant feiling. Det betyr at når systemet tross funksjonalitet, stabilitet og robusthet allikevel ikke kan fullføre oppgaven sin, så sier det ifra på en grei og informativ måte. Ting som den ikke har blitt programmert til å takle, skal den heller ikke forsøke å ordne.

Jeg misliker automatiserte jobber når de inntrengende, repeterende og pågående forteller meg om alt som er normalt. Jeg har allerede nok avbrytelser og oppmerksomhetsavledninger i arbeidsdagen til at jeg trenger noe som støyer bare for å fortelle meg at alt er i orden. Nettopp derfor er det viktig at en automatisert jobb holder kjeft sålenge alt er i orden, og kun skriker opp dersom noe er galt. Enkle, hyppige og lettolklige feil bør den settes opp til å håndtere selv, mens de øvrige bør videresendes til en systemadministrator i mest mulig ordrett kopi og med best mulig bakgrunnsinfo. Manuell, inkrementell tilpassing av den automatiserte oppgaven over tid er den enkleste måten å gjøre den stabil og robust på.

Dette betyr ikke at jeg har noe imot statistikkrapportering og logging av at alt er greitt. Det må imidlertid skilles skarpt mellom to ting som har hvert sitt bruksområde: På den ene siden er det som er tilstandslogging som en systemadministrator kan oppsøke for rapportgenerering eller post-mortem debugging. På den andre siden er det som varsler om at noe er galt, og som systemadministrator bør få som avbruddshåndtering.

Ikke misforstå meg dithen at jeg har noe i mot proaktivtitet, tvert imot! Men jeg observerer at proaktivitet er noe som 'alle' skryter av men 'ingen' gjør. Med proaktivitet mener jeg i forbindelse med problemer å handle før de negative konsekvensene har sprunget ut og rammet brukerne. Proaktivitet er hva som ligger bak ordspråket 'bedre føre var enn etter snar'.

Det vanligste er det motsatte av proaktivitet: nemlig reaktivitet. Man fikser ikke doseringene i en sving på E6 før man har fått dødsulykker der, man trekker ikke et produkt fra markedet før man har sett at det er utrygt, man skifter ikke strømforsyningen før man merker at den ikke lengre virker.

Årsaken til dette er kanskje at det er så ufattelig mange ulike feil som kan oppstå, at man av ren matthet ignoreres de fleste. Oftest går det jo allikevel bra, og alternativet er vanligvis å bruke mye ressurser på noe man i ettertid 'ikke fikk bruk for'. Derfor satser man på at det er billigere å rydde opp reaktivt for de relativt få crashene som faktisk kommer.

Så er vi ved sakens kjerne:

• Jeg skulle ønske at flere hadde en bevisst holdning til proaktivitet, reaktivitet og balansen mellom dem, og at det er basert på kostnader, ressursbruk, sannsynlighet og konsekvenser.
• Jeg skulle ønske at flere i forkant var bevisste på hva de håndterte proaktivt og hva de planla å ta reaktivt dersom det skulle bli nødvendig.
• Og jeg skulle ønske at flere i etterkant var ærlige nok til å innrømme at dette krasjet fordi man vurderte at det totalt sett var billigere å rydde i ettertid enn på forhånd å fikse dette og tallrike tilsvarende problemer.

Og mekanismen er enkel: jo større skadekonsekvenser, jo større sannsynlighet og jo lavere proaktive kostnader; jo lavere er terskel for å bruke proaktivitet helt eller delvis for å unngå eller begrense skaden.

Det finnes noe tankegods som sier at større er bedre: dvs at om man er stor så er det lettere å håndtere ulike mer eller mindre uforutsette situasjoner ferie, sykdom, ansatte som slutter osv. Jeg kunne tenke meg til å erklære meg delvis uenig i dette, og la meg forklare hvorfor.

For det første, det er ikke konseptet om stordriftsfordeler jeg misliker. Stordriftsfordeler er ekte og reelle. Det er ideen om at om man er stor, så er man mange personer, og derfor har man lettere for å absorbere uforutsette ting. Jeg tror det er en logisk feilslutning av typen pose-og-sekk. Den går vanligvis slik:

1. Jo større du er, jo flere personer har du ansatt. Joda, jeg er enig i den, ikke fordi det nødvendigvis er en universell sannhet, men mer fordi det er en tommelfingerregel som er beskrivende for hva vi stort sett kan observere.

2. Når du har mange ansatte, så kan du la de ansatte kunne gå i dybden, slik at de kan bli eksperter som kan tingene godt i stedet for at de kan litt om alt, men ingenting skikkelig. Jepp, jeg er enig i det også, ikke minst fordi du har et større bruksvolum dersom du er stor, så de ansatte kommer bort i flere og mer varierte utfordringer. Dessuten er det mange kostnader som skalerer sublinært med bruksvolum, så som opplæring.

3. Når du har mange ansatte, så vil frafall av en person gjennom sykdom, ulykke, oppsigelse eller annet gi en mindre innvirkning på virksomheten. Tja, isolert sett er jeg jo enig i det, for det virker innlysende at om du mister en av hundre, så gir det mindre konsekvenser enn om du mister en av to.

Der hvor dette brister, er mellom andre og tredje påstand, for de er ikke kompatible seg imellom. Du kan ikke både la dem fokusere i dybden på et snevert område (spisskompetanse) og samtidig flushe dem rundt etter kortsiktige behov (krever breddekompetanse). Det er bare når du har svært arbeidsintensive (i motsetning til kunnskapsintensive) oppgaver, dvs der mange gjør samme jobben, at dette vil virke. Men det er jo det motsatte av ta ut en stordriftsfordel slik som vi oppfatter det innen IT-drift. Med andre ord, Trondheim parkering kan gjør det med parkeringsvaktene, og MacDonalds kan gjøre det med ekspeditørene, men en stor IT-bedrift kan ikke gjøre det, kort og godt fordi de ikke har mange ``like'' personer med samme kompetanse og bakgrunn.

Tvert imot, det aller siste du ønsker om du er stor og mangler en person eller to i avdeling A, er å ``låne'' en person fra avdeling B. Det sprer bare problemet, uten at du er sikret at det blir løst i avdeling A. Jo dyktigere den personen du flytter er, jo større er sjansen for at problemet sprer seg. Jo mindre dyktig personen er, jo større er sjansen for at det ikke er tilstrekkelig eller bare forverrer situasjonen.

For at dette skulle kunne fungere, så må alle avdelinger ha en visst overkapasitet (eller i det minste en viss sikkerhetsmargin) som kan spises opp av andre etter behov. Men en stor del av ideen med stordrift er å skrelle bort sikkerhetsmarginene og overkapasiteten. Man skal effektivisere bort og strømlinjeforme.

Se på en vilkårlig stor bedrift - det behøver ikke å være en IT-bedrift. Generelt sett: jo større de er, jo mer stresset, oppjaget og kjemisk renset for overkapasitet og slingringsmonn er de. Det er først når du kommer i liten organisasjon at breddekompetansen gjør det mulig å flytte folk mellom oppgaver, og størrelsen gjør det mulig å ha oversikt nok til å kunne omprioritere.

Og hvorfor snakkes det bare om stordriftsfordeler? Hvorfor er det ingen som snakker om smådriftsfordeler eller stordriftsulemper?

Så kom den da, rapporten fra Sølvbergutvalget. Den er i alle fall lagt for alle ansatte og studenter ved IME, så da er den vel å regne som offentlig. Det er mye spennende i den, og kanskje jeg kommer tilbake til mer senere, men la meg først ta tak i det viktigste, hva rapporten sier om ``sentral'' og ``lokal''.

Det store gjennomgående temaet ved NTNU har de siste 20-25 årene har kunne oppsummeres med ``sentralt eller lokalt''. Da jeg begynte her i 1985, så hadde IDT (en delforløper til IDI) allerede året før sparket ut Runit av grunnopplæringen innen IT (eller EDB som man sa dengang), og faset over fra Fortran på Nord-10-anlegget til Pascal på IBM-PC-maskiner. Allerede den gang kranglet man så filler og minnebrikker flagret om IT skulle være sentralt eller lokalt, og evt hva slags fordeling det skulle være mellom dem. Og for å gjøre en meget lang historie kort: det holder man fremdeles på med.

Hva sier så Sølvbergutvalget om dette? De gjør noe nytt og ganske genialt. Først formlerer de problemstillingen: ``Skal IT-tjenestene organiseres lokalt eller sentralt?'' og så kommenterer de: ``Utvalget mener det ikke finnes enkle og endelige svar på [dette] spørsmål[et].''

Verdensoppfattelsen vår består gjerne av enkle todelinger, og Sølvbergutvalgets rapport introduserer en ny todeling som en erstatter til den gamle lokalt/sentralt-todelingen. Den nye todelingen går mellom ``primærprosessene'' og ``sekundærprosessene''. Når jeg underviser i faget mitt deltar jeg i en primærprosess, mens når jeg tar backup av hjemmekataloger deltar jeg i en sekundærprosess.

Primærprosessene er det som er direkte relatert til forskning, undervisning, formidling og nyskaping - mens sekundærprosessene er det som er relatert til det som støtte opp under primærprosessene. Bjørn Østby liker å fortelle om en episode fra ``Javel, hr statsråd'' der St Andrew's Hospital hadde 2000 ansatte men hverken pasienter eller leger. Departementsråden forstod dette meget godt, for det var tross alt en kompleks og vanskelig oppgave å drive et hospital, om man ikke i tillegg skulle ha leger og pasienter å bale med. Det er et ekstremt eksempel på en organisasjon med bare sekundærprosesser og ingen primærprosesser.

I innstillingen fra Sølvbergutvalget tenker man altså ikke lengre på om man jobber sentralt eller lokalt (altså hvor på organisasjonskartet), men om man jobber med primærprosesser eller sekundærprosesser. I det ligger også at man kan jobbe med begge deler. Da har man ulike roller i ulike prosesser. Jeg har det når jeg underviser og når jeg tar backup. Det er viktige at, primær- og sekundærprosesser må ikke mistolkes som et synonym til viktige og mindre viktige oppgaver, men bare som en referanse til hvor nært en står NTNUs hovedformål, eller som de sier på engelsk: ``where the rubber meets the road.''

Og så kommer vi til det hvor Sølvbergutvalget vil endre på ting: det skal bli primærprosessene som skal legge premissene for sekundærprosessene. Med andre ord, IT er noe som en IT-ansvarlig implementerer, men ikke bestemmer mål og rammer for. Det er noe der proffer og studenter stiller kravene, og der IT-ansvarlig oppfyller dem.

Det er også en annen endring her, for hvor vi før har vært enten lokale eller sentrale, så er vi nå alle sammen deltakere i sekundærprosessene - enten vi jobber på instituttnivået, fakultetsnivået etter på NTNU-nivået. Kanskje er det forskjeller i antall indireksjonsnivåer til primærprosessene, men vi er allikevel alle sammen i sekundærprosessene.

Det kan kanskje være like så bra med denne begrepsendringen. Jeg har alltid mislikt merkelappene ``sentralt'' og ``lokalt''. Ord har alltid konnotasjoner, og satt på spissen kan man oppfatte ``lokalt'' som noe smått, noe tuslete, noe dilletantisk, noe hjemmesnekret, noe enkelt, noe billig, noe perifert, noe uvesentlig, noe irrelevant og noe som er uvesentlig i det store bildet. Mens ``sentralt'' har konnotasjoner til noe som er stort, noe viktig, noe komplekst, noe fjernt, noe dyrt, noe som er i samhandling med alt og alle, noen kompetansekrevende, noe omfattende.

Dette er den store, fundamentale endringen i Sølvbergutvalgets rapport. Alt det andre er enten bare opprettholdelse av status quo eller endringer for å implementere dette ene, store endringsgrepet.