Her er en klassiker innen det å snakke forbi hverandre i en driftssammenheng.

Bruker: kontor-PC'en min fungerer ikke.
Sysadmin: (Feilsøker) ahh, det er xxx, den må bootes.
Bruker: Åja. (Drar tilbake til kontoret.)

Ved første øyekast ser jo dette helt greit ut. Men det er ingen som sjekket at begge hadde samme oppfatning av hvem som skulle boote den aktuelle maskinen. Det er fullt mulig at brukeren sitter på kontoret og venter på at en eller annen som skal komme og fikse problemet, mens sysadmin lener seg godt tilbake i stolen i trygg forvisning om at brukeren selv fikser det og saken dermed er løst.

Om vi i dette tenkte tilfellet spoler et par timer fremover, er det mulig at systemadministrator har en sint og frustrert bruker på døra. Da vil kanskje brukeren insistere på at «Du sa du skulle komme og fikse det, men du kom ikke.» I beste fall har man spilt tid, i verste fall er det der og da saken virkelig tar av.

Forsøk å legge merke til hvor ofte man blir enige om at noe skal gjøres, bare ikke hvem som skal gjøre det. Spesielt møter er ille på det, og gjerne mot slutten når alle er litt slitne og det er dårlig tid. Der kommer gjerne problemene når og hvis møtereferatet sier at en eller annen skal gjøre noe, og vedkommende er uenig i at den fremstillingen. Folk som er drevne i å skrive møtereferater vet at man må eksplisitt ta med med hvem, hva og innen når.

For en stund tilbake fikk en av mine kolleger helt ufrivillig en leksjon i hva kombinasjonen av dårlig kundebehandling og manglende systemforståelse kan lede til. Han hadde en tjeneste som var såpass viktig at de hadde bestilt tjenermaskinvare som den kjørte på - deriblant ECC-minne.

ECC betyr Error Correcting Code, og litt forenklet kan vi forestille oss det som minne med dobbelt paritet: en paritetsbit for hver byte, og en paritetsbit for alle n'te bits i en blokk med minne - dvs en paritetsbit for alle LSB i hver byte osv. Da har man en matriselignende layout av bits, med paritet både kolonne- og radvist. Hver minnebit er med i to paritetsbits, og hvert par av paritetsbit deler maksimalt en enkelt bit. Det er da mulig ikke bare å detektere at det er bitfeil - som man kan med vanlig paritetsminne. Man kan i tillegg også bestemme posisjonen som har feil verdi, og dermed kan man korrigere den. Som en bonus er man også sikret deteksjon av alle dobbeltfeil.

Bitfeil i minnet er en del av livets realiteter. Det kan skyldes en så uunngålig ting som at kosmisk stråling har fått inn en fulltreffer på den delen av en minnebrikke der en bit lagres. Normalt er raten lav, og den druker i de fleste systemens iboende ustabilitet. Selvfølgelig kan også bitfeil skyldes at det er feil på minnebrikken, og det er ikke ignorerbart.

Om du ønsker å ha maksimal oppetid og stabilitet, er ECC-minne en god ide. Dessuten kan man formodentlig anta at hovedkort og systemer med ECC-minne også har høyere kvalitet forøvrig. Det er i hvert fall lov å håpe.

Min kollega kjøpte altså ECC-minne til tjeneren med den kritiske tjenesten. Etter en tids bruk ble det konstatert repeterende minnefeil på et bestemt punkt. Han samlet all informasjon som han visste support ville trenge og ringte dem. En av livets merksnodigheter er at jo større en organisasjon blir, jo mer frustrerende er det generelt å forsøke å kommunisere med deres supportavdeling, og dette var en av de aller største og formodentlig mest seriøse. Men min kollega fikk bakoversveis da han fikk beskjed at den modellen skiftet de ikke minne på, fordi den hadde ECC-minne, som korrigerer feilene, og dermed er ikke minne-feil noe problem.

Dette er et så blantant overtramp på tanken bak og forståelse av redundans at det er verd å analysere det. ECC-minne har innebygget redundans, nærmere bestemt en slags N+1-redundans selv om konseptet ikke helt passer. I det øyeblikket et redundant system får en feil, reduseres redundansen. Det er ikke en sikring mot feil, det er en galgenfrist du har kjøpt deg og som løper fra feilen har oppstått. Det gir deg litt mer tid til å fikse den uten at tjenesten rammes. Litt forenklet: systemet kan rammes av feil, men redundansen sikrer at tjenesten ikke rammes. Dersom du er så dumdristig å kjøre videre, kjører du uten eller med redusert redundans. Treffes du av enda en feil risikerer du at også tjenesten feiler.

Så lenge feilene oppstår med lav rate, sporadisk og på tilfeldig steder uten noe mønster, er det ikke grunn til å bytte minnet - det var denne feilkorrigeringen du kjøpte ECC-minne for. Dersom feilene kommer på samme sted og kanskje med økende hyppighet, så vet du at det er minnet i seg selv som er problemet, og det må byttes.

Det er som med reservedekket til bilen. Når du har punktert, er det reservedekket som lar deg kunne kjøre videre. Men samtidig kjører du nå videre uten redundans, og bør reparere dekket (reetablere redundansen) snarest råd.

Har du vært ute for en IT-driftsavdeling med tekniske problemer? Joda, visst kan systemadministratorer stri med tekniske problemer, men det som virkelig skaper utfordringene er - satt på spissen - noe annet:

1. Skalering. Det kan være lett nok å lage en løsning sålenge den ikke trenger å skaleres opp. Men når en løsning, en installasjon eller et design går fra å være nærmest et proof-of-concept til å være en reell løsning med et bruksvolum som totalt overskygger trivielle testeksempler, først da er det man får se om den skalerer. Husk at selv mange NP-komplette problemer lar seg enkelt løse om de bare er tilstrekkelig små nok. Gjør man ting rett, tester man for skalerbarhet. Gjør man det feil, antar man at skalerbarhet er brikken av puslespillet som faller på plass av seg selv helt på slutten.

2. Endringshåndering. Rett nok kan det synes som om ting slutter å virke helt av seg selv, og tidvis - som en harddiskkrasj - er vel også det den beste forklaringsmodellen. Men oftest er noe endret, gjerne med vilje, men uten at man har hatt tilstrekkelig oversikt over problemer og bieffekter. Kontroll på og styring med endringsprosessene er essensielt dersom endringer skal være en målrettet forflytning i positiv retning, og ikke bare en krysning mellom risikosport og lotto.

3. Personkommunikasjon. Folk snakker sammen, men de snakker også forbi hverandre, misoppfatter hverandre, forvirrer og avsporer hverandre, glemmer hva de avtalte, tolker begreper forskjellig osv. Kommunikasjon er ikke bare tale eller E-post, det er også dokumentasjon - som er kommunikasjon fra ett tidspunkt til en litt uspesifiert mottaker på et senere tidspunkt. Hver gang problemer koker ned til at noen «ikke visste», så har man trolig et kommunikasjonsproblem.

Min høyst udokumenterbare antakelse er at disse tre ikke-tekniske aspektene er forårsakende eller i det minste deltakende eller forsterkende årsaker i nesten alt av hva som tolkes som tekniske problemer.

Driftsstaber, eller i det minste personene som utgjør dem, er ofte flinkere til å takle de rent tekniske problemene enn disse tre aspektene. Utfordringen ligger i å lære dem til å takle også disse sidene. ...samt å lære av det når man først har gjort en feil.

Faget som jeg har undervist siden omkring 2000 - TDT4285 Planlegging og drift av IT-systemer - blir tatt ut av fagplanen etter at det er undervist dette vårsemesteret. Det er en generell revidering av fagplanen for å konsolidere fagutvalget og tematisk spredning på instituttet som økser bort blant annet driftsfaget. Jaja, alt har tross alt en ende.

Dersom det er noen som ønsker å få med seg dette faget, må de kaste seg rundt realtivt fort. Siden det er et datateknikkfag, så er det visse formelle krav: såvidt jeg husker er det generell studiekompetanse og fordypning i matematikk. Men merk at jeg ikke jobber på studieadministrasjonen, så det er mulig at jeg tar feil her. Jeg har tatt feil i dette før! Sjekk med studieadministrasjonen eller kontakt meg direkte om du er usikker.

Kravet om matematikk er mest et formelt krav for fag som er en del av det gamle siv.ing-løpet. Selve driftsfaget har ikke i seg selv noe matematikk som konkret krever at man har fordypning i matematikk.

Første forelesning er tirsdag 10. januar kl 08:15-10:00 i aud H1 i Hovedbygget på Gløshaugen (vi snakker NTNU i Trondheim). Andre forelesning er torsdag 12. januar kl 11:15-12:00 i aud F6 i Gamle fysikk. Øvingene er mandager kl 15:15-17:00, men det er bare ganske få uker der det er obligatorisk oppmøte på dette tidspunktet. Deretter repeteres det ukentlig. Det er fullt mulig å kaste seg på selv etter første forelesning, men det blir verre for hver uke, og klokka tikker i retning noen oppmeldingsfrister som er veldig absolutte.

Det har vært snakket om å bygge faget om til et EEU-kurs (eksamensrettet etterutdanning), men vi får se om det blir noe av det.

Inntil videre tenkte jeg kanskje å blogge litt om IT-drift parallelt med undervisningen i den grad tiden tillater. Forhåpningen er synergetisk å hente materiale fra det jeg foreleser, men uten at jeg har tenkt å begrense meg til tematisk til det.

I høst kjøres fordypningsemnet i drift TDT43, der vi skal gå igjennom ITIL v3 - det er ikke det samme som driftsfaget, som går på våren. Det er strengt tatt bare for femteklassinger i datateknikk, og det er bare meg og én student. Vi kommer til å kjøre det som en seminarserie, og dersom det er noen med nysgjerrighet, litt driftserfaring og deltakervilje som ønsker å kaste seg med, så kontakt meg. Da blir vi litt flere og diskusjonen går glattere og vi får flere vinklinger. Vi legger nivået på kurset i henhold til den formelle studenten, men det er sikkert noen rundt om som er på tilsvarende nivå, og som derfor kunne ha glede av å delta.

Vi bruker boka Foundation of IT Service Management Based on ITIL V3, og kommer til å ta ca ett kapittel pr uke, muligens med litt ekstra støttelitteratur som deles ut etter behov. Undervisningsformen er to timer pr uke. Hver dobbelttime starter med en kort presentasjon av kapittelet og deretter diskusjon. Alle som deltar forventes å ha lest kapittelet og på forhånd ha formulert en håndfull innspill til diskusjonen: problemstillinger, uklarheter, synspunkter, erfaringer, mangler, styrker, snubletråder osv.

Første dobbelttime er fredag 5. september kl 13.15-15.00 på Gløshaugen, rom IT-Syd 236. De resterende dobbelttimene blir på en annen ukedag, men tidpunkt er ikke bestemt, og evt deltakere kan komme med innspill. Tema for første dobbelttime er kapittel 1 og 2 i boka.

Dersom du er interessert i å delta, så send meg mail til anders@idi.ntnu.no. Det er fullt mulig å delta uten å ta eksamen - faktisk er det sannsynligvis ikke mulig å ta eksamen for andre enn de som formelt har kurset på timeplanen :-) Det er også fullt mulig å delta på bare noen av seminarene, ja til og med bare ha ambisjoner om det. I det høyst usannsynlige tilfellet at det flommer over med ønsker om å være med, så kommer jeg til å sette et tak på antall deltakelse.

Rune Andersen på IME ble nettopp tildelt tilgjengelighetsprisen for 2008 fra en eller annen instans ved NTNU med venner - jeg fikk ikke helt med meg hva eller hvem.

Når det deles ut slike priser, så tenker jeg umiddelbart: jaja, det er aldri noen jeg kjenner som får dem, og sjeldent for noe jeg synes er viktig. Men ikke slik denne gang!

Rune fikk prisen for å lage maler og gjøre websidene ved NTNU mer tilgjengelige. Han skal ikke lastes for mange av teknologivalgene ved NTNU, for hans banehalvdel er stort sett IME, samt der han har klart å komme i inngripen med NTNU sentralt. På IME har han latt være å bruke de store, interne, endringstunge, database(mis)brukende, dyre CMS-ene som ingen liker, og i stedet implementert alle websidene i en Wiki. Det er slikt man ikke alltid blir populær av, men hver gang noen har påpekt at noe ikke kunne gjøres i Runes system, så har han svart «vent litt» og så har funksjonaliteten vært der.

Rune har jobbet hardt for å følge standarder, lage maler som er renslige, ryddige, modulære, utvidbare og alle de andre tingene som vi ikke alltid finner på websider. For ham er det ikke tilstrekkelig at det fjongt og fancy ut i ens egen webbrowser, men det skal være riktig etter en standard, det skal være portabelt mellom ulike browserimplementasjoner, og koden skal være ryddig, selv om knappest noen kommer til noensinne å se på den.

Gratulerer, Rune!! Og gratulerer NTNU for at man også har satt søkelyset på at konstruksjon av websider ikke bare er en lekegrind for «webdesignere», men et område der man må tenke tilgjengelighet, skalering, standarder og slikt!

Sukk. Akkurat nå har jeg 50% oppetid på nettverket hjemme, fordi nettverksmodemet fra Bluecom fungerer annethvert halvminutt. Ja, du leste rett. Dersom jeg pinger, så kommer ca 30 pingpakker gjennom, så det ca 30 som ikke kommer igjennom, så kommer ca 30 igjennom ... og det hele repeterer seg ad neuseam. Eller rettere sagt, slik hangler det en periode på rundt en halvtime, så er nettet ok en halvtime, så og så repeterer dén rytmen seg over en periode på rundt seks timer. Vanligvis går det noen dager mellom hver gang vi har en slik periode.

Det er nærmest som tortur å regne. Når jeg har tid til å feilsøke, så er alt ok, mens når jeg har det travelt, går den inn i sykler på halvminutter oppe og nede. Derfor jeg har aldri fått feilsøkt det skikkelig. Og med litt planlegging, så overlever jeg det alltid. Jeg har utviklet en teknikk med auditable pings og multitasking, så når det plopper i høyttaleren så kontekstsvitsjer jeg over til den oppgaven som trenger nett - i 30 sekunder. Det er en overdrivelse å si at det er en behagelig måte å jobbe på: ikke er det effektivt å kontekstsvitsje oppgaver to ganger per minutt, og heller ikke er det behagelig å sitte å lytte til plingingen, men det går ...

Tidvist har det fungert å boote ADSL-modemet, men det fungerer visst ikke lengre. Jeg tror det er noe som går i metning eller krasjer eller noe slikt, og så tar det ca 30 sekunder å resette. Det er heller ikke slik hele tiden. Grafene under viser hvordan det går i perioder, for siste halvannen dag og siste halvannen uke. De måler tiden frem til først og siste overførte byte i en wget fra en webside på NTNU.

Men nå er snart tålmodigheten slutt - hvilket betyr at nettet kommer til å virke prikkfritt i et par dager. Jeg kjenner blodtrykket stige bare ved tanken på å skulle kontakte en telefonkundeservicesenterhelpdesk for å forsøke å forklare dette feilmoduset. Det har virket som om det er en tendens til at det er verst på natta, enten frem mot midnatt eller like etter - så det er ikke helpdeskserviceåpningstidsvennlig. Som allerede nevnt er det heller ikke repeterbart på kommando, så det er et feilsøkingsmareritt.

Det er et feilmønster som ikke kunne vært mer frustrerende om det var ondsinnet designet av mine verste fiender. Det enkleste er vel å innse at Bluecom var et dårlig teknisk valg, og skifte til ny leverandør. Arrrrrgh!

Limoncelli og Hogan har - sammen med Strata Chalup som ny medforfatter - kommet med ny utgave av «The Practice of System and Network Administration», og dermed har jeg et valg foran neste års TDT4285-fag. Skal jeg bruke den nye boka, eller skal jeg velge en annen bok.

Den nye utgaven har vært annonsert lenge. De siste 2-3 årene har den kontinuerlig lagt omkring seks måneder frem i tid ... vanligvis et dårlig tegn. En kjapp blading i den viser at det er noen nye kapitler, og endel tillegg her og der, men generelt sett er det ikke de store fundamentale endringene. Prisen er også stiv, på 536,- men det er likevel billigere enn den forrige utgaven.

Alternativet er å bruke «IT Service Management based on ITIL - an introduction», som er på overkommelige 240 sider og rundt 330,- på Amazon, og full av presise definisjoner og TLA-er. På mange måter er den diametralt motsatt av Limoncelli-boka, for der Limoncelli formidler at det viktige er å gi deg som systemansvarlig en forståelse som du kan tilpasse og bruke i fremtidige situasjoner, så er ITIL-boka tilsynelatende et presist kart for hvordan en driftsenhet bør fungere. På et overordnet nivå er de egentlig ikke så forskjellige i filosofi, men i presentasjon og fremtoning er de ekstremt forskjellige.

Jaja ... livet er fullt av valg. Er det noen gamle studenter som leser denne bloggen og kan komme med råd og forslag til hvilken bok som er mest hensiktsmessig?

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?