Smidig ledelse

Forfatteren tar på seg ambisjonen det er å beskrive de mer grunnleggende egenskapene i de smidige metodene vi kjenner. Han beskriver hvordan vi både kan lede prosjekter og team bedre. Appelo tar utgangspunkt i forskningsbaserte metoder og funn, og setter den smidige tenkningen i perspektiv. Han peker på en retning for å utvikle en mer helhetlig modell for ledelse basert på suksessen smidige metoder har hatt både innenfor systemutvikling, produksjonsprosesser og tjenesteyting.

Helhetlig tilnærming

Gjennom å delta i og lede smidige systemutviklingsprosjekter har jeg vært borti flere ulike modeller for smidig utvikling. Det være seg timeboksbaserte metoder som Scrum og XP, eller flytbaserte som Lean og Kanban. Alle modellene har elementer som er gode og dårlige, og det har etterhvert utviklet seg en praksis hvor utviklerteam og prosjekter tar elementer fra ulike smidige teknikker og setter sammen etter teamets og leverandørenes smak. Av og til oppstår energitappende “religionsdebatter” om metoder og teknikker. Apellos bok beskriver et tankesett som frigjør oss fra spesifikke metoder. Med en helheltlig tilnærming beskriver han hvorfor smidig virker, og hvordan vi kan få det til å virke enda bedre.

Appelos utgangspunkt er at alle tradisjonelle ledelsesmodeller er fokusert rundt optimalisering (1.0) og suboptimalisering (2.0) av deterministisk tenkning og hierarkiske strukturer. Han mener, og eksemplifiserer at, de tradisjonelle ledelsesmodellene har bevist sin utilstrekkelighet og beskriver svært overbevisende en ny modell han kaller Ledelse 3.0. Nøkkelbegrepet er kompleksitet.

Seks hovedegrener

Modellen Appelo har laget for Ledelse 3.0 har han kalt “Martie”. I boken ser han mer detaljert på hver av disse grenene:

Management 3.0

• Energizing people
  Hva er det som får mennesker til å “tikke og gå”?
• Empower teams
  Hvordan kan en gruppe gjøres selvstendig og å ta sine egne beslutninger?
• Allign constraints
  Hvordan beskrive rammebetingelser slik at de kan sees på som hensiktsmessige og ikke som hindringer?
• Develop competance
  Hvorfor er kompetanse så viktig?
• Grow structure
  Hvordan styrer man komplekse strukturer når de blir store?
• Improve everything
  Hvordan jobbe med læring i komplekse organisasjoner?

Forfatteren diskuterer en forståelse av menneskelig samspill og kommunikasjon basert på psykologiske og biologiske fakta. Determinisme, kompleksitetsteori, reduksjonisme og holisme er alle begreper som omtales. Som eksempel bruker forfatteren bl.a vannets egenskaper. Man kan ikke ved å beskrive vann etter formelen H2O forklare (på en enkel måte) vannets oppførsel og egenskaper. Summen av argumentene er at det gir mening å legge en kompleks modell til grunn for en smidig planlegging og styring av menneskelig aktivitet og interaksjon. For å forutse adferden til slike strukturer , og lede dem, bør man forstå hvilke egenskaper som kjennetegner dem. Mange av de teoriene vi kjenner fra smidige metoder kan gjenkjennes fra denne grunntenkningen.

Heller tankegang enn metode

Jeg har jobbet med smidige systemutviklingsprosesser siden 2006. Det begynner å bli lenge siden Agile Manifesto ble skrevet (2001). For meg var det veldig stimulerende å lese en bok hvor jeg drar kjensel på utfordringene i prosjekthverdagen, og forstå hvorfor disse utfordringen oppstår. For meg bidro boken til å bygge bro over de smidige metodesiloene.

Anbefalt lesning for alle som jobber med smidig ledelse: Management 3.0; Leading agile deveolopers – Developing agile leaders av Jurgen Appelo

En vanlig felle å gå i er å fokusere for mye på IT-systemer, og for lite på prosesser og kunder. Mange tenker at hvis vi bare erstatter systemene våre så kommer resten av seg selv. Det hadde vært veldig behagelig om det var så vel, men dette er en farlig vei å gå. IT-systemer i seg selv løser ingenting. Systemene må passe inn i de riktige prosessene, og prosessene er riktig når de løser kundenes behov mest mulig effektivt. Formålet med modernisering er derfor å re-etablere hvordan vi jobber, for å kunne skape mer verdi for kundene. Dette krever et godt samspill mellom kunder, prosesser og systemer.

Kunder: Bedrifter er til for kunder og ikke omvendt. Hva er de vesentligste driverne for kundene deres i dag og i fremtiden? Ønsker de gode kjøps- og bruksopplevelser? Gode produkter? Råd og veiledning? Lave priser? Ja faktisk – hvem er kundene? Er de alle like? Er det forskjeller i hvordan de ønsker å betjenes? Og gitt bedriftens egne strategiske mål – hva er det viktig for dere at dere lykkes med? Bundling av flere produkter og tjenester for å øke kundelønnsomheten? Effektivisere kundebetjeningen? Uansett om du velger å tenke overflatisk eller tenke grundig gjennom dette vil det være en viktig øvelse å gjøre.

Vellykket modernisering krever et samspill mellom kunder, prosesser og systemer

Prosesser: Kjernen i all kommersiell virksomhet er å dekke kundenes behov mest mulig ressurseffektivt. Et viktig spørsmål å avklare er om dette først og fremst handler om å redusere ressursbruken og øke lønnsomheten gitt dagens kundeomsetning, eller om det også handler om å skalere opp dagens operasjoner og sikre at dagens prosesser kan ta unna for en forventet kundevekst? Et annet viktig spørsmål er hvilke muligheter vi har for å forbedre prosessene – gjennom å utnytte teknologi til for eksempel digitalisering, automatisering, samhandling eller informasjons- og kunnskapsdeling. Og hvilke muligheter har vi rett og slett for å gjøre ting enklere – med eller uten teknologi?

Systemer: En modernisering krever til syvende og sist en utskiftning eller større videreutvikling av IT-systemer. En vellykket modernisering krever at fremtidens IT-systemer samspiller godt med hverandre og med hvordan bedriften ønsker å jobbe. Moderne IT-systemer må ikke bare understøtte effektive prosesser og møte bedriftens strategiske behov. De må også være kostnadseffektive i drift. Og enda viktigere er det at de understøtter en fleksibilitet og en smidighet som sikrer at dere har muligheten til å snu dere rundt når markedet og kundene sine behov atter igjen skifter retning. Systemene må være tilpasset prosessene, men prosessene må ofte også tilpasses systemene. Dette gjelder særlig ferdigutviklet programvare som kjøpes inn for å tilpasses bedriftens ønskede arbeidsform.

Mange starter moderniseringsarbeidet med det konkrete systemet de opplever som flaskehalsen. En slik systemorientert innfallsvinkel kan gi mer effektive systemer, men det gir også lite rom for å tenke nytt rundt hvilke behov kundene våre har som vi må løse, eller hvordan vi skal utforme arbeidshverdagen til våre medarbeidere slik at de enklest mulig kan møte kundenes behov. En modernisering som kun fokuserer på systemet reproduserer bare gamle prosesser i nye farger. En vellykket modernisering av prosesser og systemer avhenger derfor av et helhetlig samspill mellom kundebehov, prosesser og IT-systemer.

Lykkes man med dette samspillet gir det desto større muligheter for store gevinster.
• Økt inntjening og verdiskapning gjennom prosesser, systemer og kundeløsninger som skaper betydelig merverdi for virksomheten og kundene og som reduserer graden av manuelt arbeid
• Redusert time-to-market og reduserte kostnader gjennom prosesser, systemer og kundeløsninger som gir økt fleksibilitet, økt smidighet og økt endringsevne
• Mer kostnadseffektiv systemforvaltning gjennom systemer og løsninger som er moderne, tjenesteorienterte og helhetlige

Dette handler om mine subjektive erfaringer med forskjellene fra tiden med SVN. Jeg kommer ikke til å skrive noe om hvordan vi migrerte til Git eller om tekniske forskjeller på de to versjonskontrollsystemene. Dette finnes det masse gode ressurser på allerede. Dette innlegget kommer til å handle om de forskjellene som faktisk har vært med på å endre min hverdag.

Branch og merge

Det er umulig å komme utenom den uovertrufne støtten for branching og merging i Git. Med Subversion opplevde jeg branching og den påfølgende mergingen som tungvint og vanskelig. Med Git er det lett å lage og håndtere flere branches. Github gjør veldig enkelt å holde oversikt over status på hver enkelt branch ved hjelp av verktøy som for eksempel network graph og branch view.

Dette har for oss vist seg å være en god støtte for å øke hyppigheten for produksjonssettinger. Når det er lett å håndtere branches er det enkelt å holde master-branchen helt ren, slik at vi kan produksjonssette når vi ønsker.

READMEs

En av de tingene som – kanskje overraskende – har vist seg å være mest nyttig er READMEs på Github. Github støtter en rekke markup-språk. Selv om det i utgangspunktet er en veldig enkel sak å skrive dokumentasjon for alle prosjektene og legge det et sted, har det vist seg svært kraftig at dette er så nært koden som mulig – og så synlig som mulig. Her har Github sin løsning vært utmerket for oss! Her legger vi instruksjoner om hvordan man kommer i gang med utvikling fra scratch (nye folk inn på prosjektet), tips til utvikling, informasjon om hvordan man deployer og så videre. At dokumentasjonen er så kodenær og synlig oppfordrer også til scripting og automatisering, som det har blitt mer og mer av.

Sosial versjonskontroll

Github kaller seg sosial versjonskontroll. Selv om dette er noe som opprinnelig ble lagd med fokus på open source prosjekter, gir det muligheter som også passer utmerker til vanlig enterprise-utvikling. Å ha en side man kan besøke for å se statusen til kildekontrollen veldig nyttig.

Sosiale features på GitHub som vi benytter oss hyppig av:

• Diskutere commits – helt ned på enkeltlinjer om ønskelig.
• Følge med på ulike branches (hvor mange commits de er bak/foran master).
• Sende pull requests på ferdige feature branches

Pris

Github har en hyggelig prismodell – hvertfall hvis man sammenlikner med andre enterprisy tilbydere av versjonskontroll. Standardprisene deres gjelder ved hosting av data i skyen (hos Rackspace). Hvorvidt det er aktuelt å hoste koden sin hos en tredjepart varierer naturligvis fra prosjekt til prosjekt. Dersom cloud hosting ikke er aktuelt finnes det et enterprise-alternativ.

Snill læringskurve

Git er et avansert versjonskontrollsystem. Likevel har det i utgangspunktet en veldig snill læringskurve. De første månedene brukte jeg Git omtrent akkurat som jeg tidligere brukte SVN. Først ved behov og lyst begynte jeg gradvis å ta i bruk mer og mer avansert funksjonalitet – funksjonalitet som jeg nå bruker omtrent hver dag.

Tilgjengelighet

Siden Github er hostet i skyen kan man få tak i det fra hvor som helst i verden, uten å måtte bruke VPN. De har også veldig god oppetid: vi har opplevd nedetid én gang på godt over ett år. Det er veldig sannsynlig at et internt hostet versjonskontrollsystem vil ha adskillig mye mer nedetid i løpet av et år enn det Github vil ha. Sikkerhet og tilgangskontroll er ivaretatt ved bruk av SSH-nøkler for hver enkelt utvikler.

Konklusjon

Git og Github har hos oss vært en revolusjon som ikke har føltes som en revolusjon. Ved å være litt bedre på så godt som alle aspekter av versjonskontroll har det fjernet masse små irritasjoner hos oss utviklere – og dermed git oss mulighet til å fokusere mer på kundens krav. I tillegg har det store antallet nyttige småting i kombinasjonen Git og Github gitt oss de verktøyene vi trenger til å endre prosessen vår til å møte kundens behov bedre.

Når man tar med i vurderingen av kostnaden for å gå over er ganske lav, er dette egentlig en no brainer for meg: Jeg anbefaler Git!

I kapittel 31 – Don´t Touch That Code, hevder forfatteren at utviklere ikke skal fikse feil i produksjon, og at dette bør forhindres ved at utviklere ikke gis tilgang til noe annet enn utviklingsmiljøet. Nærmere bestemt:

… a developer — even a senior developer — should never have access beyond the development server

og

Under no circumstances — ever, at all — should a developer have access to a production server.

Det er fornuftig at feilretting ikke bør skje direkte i produksjonsmiljøet. Selv har jeg imidlertid aldri opplevd dette, og har ikke intrykk av at dette utgjør et stort problem i de fleste utviklingsprosjekter. Derimot har man mange andre utfordringer, og en del av disse kan løses bedre nettopp ved å la utviklerne ha tilgang.

Feilanalyse

Ved daglig drift kan det oppstå feil eller andre hendelser som man har lyst til å se nærmere på. I slike tilfeller er det viktig å ha gode logger og at utviklerne har rask og enkel tilgang til disse. Dette er enklest å oppnå ved at utviklerne har direkte lesetilgang til loggene. Dersom man har en politikk som ikke tillater dette, ender man gjerne med lange og tidkrevende epostvekslinger mellom utviklings- og driftspersonell for å få tak i loggene det gjelder, noe som er tungvint og irriterende for alle parter – spesielt dersom det er snakk om kritiske feil der tidsfaktoren er viktig.

Monitorering

Loggene kan også benyttes til å gjenskape feilsituasjoner og/eller monitorere feilsituasjoner “live”, noe som kan være en svært effektiv og nyttig fremgangsmåte i gitte situasjoner. Slik oppfølging blir ofte enklere og mer fleksibelt dersom man har bygget applikasjonen slik at logginnstillinger og eventuelle andre parametre kan justeres mens applikasjonen kjører. Slik monitorering og justering er det utviklerne, som kjenner applikasjonen som sin egen bukselomme, som bør gjøre. Hvis utviklerne ikke har live tilgang til miljøet, nekter man seg i praksis et viktig verktøy ved feilsituasjoner.

Administrasjon og støtteverktøy

Ofte kan støttefunksjoner til en applikasjon være nyttige, enten det er operasjoner som er del av daglig drift eller ad-hoc-funksjoner som kan være nyttige ved spesielle situasjoner. Eksempler på dette kan være automatisk monitorering og varsling basert på logg-data eller interaksjon med applikasjonen som f.eks. invalidering av cache eller av-/påslåing av funksjoner på gitte tidspunkt. Mange slike støttefunksjoner kan utføres ved enkle kommandolinjescript. Igjen er det ofte utviklere som er best egnet til å lage slike støttefunksjoner, spesielt av ad-hoc-art, da det er de som best vet hvikle muligheter man har i applikasjonen.

Utrulling

Applikasjonsutrulling er også et område der utviklere kan spille en viktig rolle. Utviklere gjør gjerne utrulling på lokal maskin flere ganger daglig, og kjenner dermed denne fasen bedre enn noen. De er også ofte de som er best skikket til å forenkle, forbedre og automatisere denne prosessen.

Å arbeide for å forbedre kommunikasjon, samarbeid og forståelse mellom utviklings- og driftsorganisasjonene kan være veldig nyttig og givende i mange prosjekter. Nærhet og samarbeid mellom utvikling og drift kan ofte være av avgjørende betydning for smidighet både ved utrulling av applikasjoner og ved oppfølging og overvåkning av daglig drift. DevOps er et uttrykk som er mye i vinden om dagen, og som fokuserer på nettopp dette. Artikkelen DevOps: What It Is, Why It Exists and Why It’s Indispensable gir en fin introduksjon til DevOps.

Utviklere bør altså ikke gjøre bugfixer i form av kodeendringer, omkonfigurering av programvare eller denslags direkte i produksjon. Dersom dette er et problem, bør det kunne forhindres — for eksempel ved noe så enkelt som rettighetsinnstilling på brukerne. Det er naturligvis ikke slik at utviklerne fullstendig skal ta over produksjonsmiljøet, men man gjør seg selv en bjørnetjeneste dersom man ikke benytter seg av den applikasjonsspesifikke ekspertisen utviklerne bestitter — også ved kjøretid i produksjon.

Kostnadseffektiv drift og infrastruktur

Det første suksesskriteriet for at virksomheten skal lykkes med IT er å sikre at virksomhetens IT-drift og infrastruktur er stabil og kostnadseffektiv. IT-avdelingen må ha en god evne til å sikre at både kjernekritiske IT-løsninger og mer brukerorienterte PC- og nettverksløsnininger fungerer stabilt og pålitelig uten vesentlige problemer. Jeg kaller det ofte ”å holde lysene på”. Informasjonsteknologien må i alle fall ikke være en hemsko, eller skape ustabile rammebetingelser for virksomhetens evne til å betjene sine kunder.

Slik sett er IT-driften en hygienefaktor – liten betydning for virksomheten når det fungerer, men stor betydning når det ikke fungerer. Derfor er det også av vesentlig betydning at driften er så kostnadseffektiv som mulig. I praksis er det ofte IT-driften som spiser flest IT-kroner og derfor er det sentralt at dette koster så lite som mulig. Med andre ord: mest mulig verdi, mest mulig effektivt.

Verdidrevet leveranse av løsninger og tjenester

Det andre suksesskriteriet for en vellykket bruk av IT er at virksomheten evner  å utvikle og ta i bruk teknologiske løsninger og tjenester som skaper reell verdi, så kostnadseffektivt som mulig. Ansvaret for dette ligger ikke bare hos IT-avdelingen, men også i virksomheten forøvrig. I praksis er ofte IT-avdelingen den eneste med kompetanse til å sikre at dette faktisk skjer, slik at IT-avdelingen er nødt til å ta ansvar for dette. IT-avdelingen må derfor for ta ansvar for å levere løsninger og tjenester som skaper verdi både for virksomheten og for kundene. Dette handler om å ha god nok kompetanse knyttet til å lede og gjennomføre prosjekter, initiere og fasilitere en dialog med virksomheten om behovene som ligger til grunn for løsningene, samt sikre nødvendig løsningskvalitet og –stabilitet. Den virkelig gode IT-avdelingen lykkes også å gjøre dette konsistent fra prosjekt til prosjekt.

Strategisk forretningsutvikling og innovasjon

Det tredje suksesskriteriet for vellykket bruk av IT er at virksomheten evner å utnytte teknologien til å være en nyskapende virksomhet . Dette krever som regel at IT-avdelingen evner å utnytte sin kompetanse om teknologi slik at en kan foreslå gode løsninger for virksomheten. Dette handler delvis om å ligge i forkant og kjenne mulighetene i teknologien slik at en kan rådgi systemeiere og ledere om hvilke løsningsmuligheter en står overfor. Det krever også at IT-avdelingen fokuserer på å være forretningsutviklere, gjennom proaktivt identifisere teknologibaserte forbedringer i prosesser og forretningsmodeller, kanskje til og med se muligheter i nye markeder og kundesegmenter. Et enkelt mål på en IT-avdelings forretningsfokus kan være dette: hvor mange i IT-avdelingen bruker 20% eller mer av tiden sin til å kommunisere med strategiske premissgivere fra forretningssiden?

Veien til vellykket IT

Veien til vellykket IT er derfor tredelt. Det er et element av modning fra det å fokusere på drift og infrastruktur til det å fokusere på leveranse av løsninger til det å fokusere på innovasjon og forretningsutvikling.Siden drift utgjør en stor del av IT-budsjettet må en evne å sikre en stabil drift av infrastrukturen før en legger stort trykk på å prioritere leveranse av løsninger og tjenester.

Videre bør en prioritere å være god på leveranse av løsninger før en prioriterer rollen som proaktiv forretningsutvikling,  siden en ikke kan lykkes med det andre hvis man ikke har kontroll på det første.

Min erfaring er at en vellykket IT-strategi må følge fire sentrale prinsipper. Når disse prinsippene brytes reduseres også slagkraften i strategien. Dessverre ser vi at mange IT-strategier synder til dels betydelig på flere av disse områdene.

1. Forretningsorientert: IT-strategier må være forretningsorientert. IT-strategien må identifisere og synliggjøre de mest sentrale utfordringer forretningen står overfor og som informasjonsteknologi kan bidra til å løse. Dette kan være f.eks. være behov for å utvikle nye markeder eller kunder eller mer generelt et behov for vesentlig mer rasjonell drift. Uansett må IT-strategien identifisere og synliggjøre  disse utfordringene og peke ut hvordan informasjonsteknologi skal bidra til å løse dem. IT-strategien må først og fremst være en strategi for forretningens bruk av informasjonsteknologi og ikke en strategi for IT-avdelingen. En strategi for informasjonsteknologi setter fokus på forretningsmessige mål. En strategi for IT-avdelingen har lett for å fokusere på IT-faglige utfordringer og intern organisasjonsutvikling – viktige områder, men ikke for andre enn IT.
2. Målrettet. Mange IT-strategier retter 80-90% av fokuset på å beskrive dagens tilstand, og da gjerne med noen avsnitt som beskriver hvordan man organiserer seg, hva som er de viktigste systemene og kanskje litt om hvordan en forholder seg til hvilke leverandører.  Det er sjelden jeg ser at IT-strategien definerer klare utfordringer som den setter fokus på og definerer en tydelig forretningsmessig ambisjon om forbedring. ”Bedre evne til å samhandle med kundene” og  ”effektivisering av hele verdikjeden” er klare forretningsmessige ambisjoner . ”Riktig leverandør til riktig prosjekt” og ”hyllevare så langt som mulig” er derimot ingen tydelige ambisjoner, men ren ønsketenkning i Ole Brumm-land.
3. Fokusert: En god IT-strategi bør fokusere på noen få (4-6) overordnede ambisjoner og ikke på alle gode formål. Strategiske valg handler ikke om å velge, men å velge bort. Summen av disse fokusområdene gir virksomheten også et strategisk konsept som henger sammen og som fungerer samlende og tydeliggjørende for de investeringer og veivalg knyttet til informasjonsteknologi en vil gjøre de neste årene.
4. Handlingsorientert. En strategi må ikke bare si noe om hvor vi vil og hva vi vil oppnå men også hvordan vi skal komme dit. Til det kreves konkrete handlingsplaner. En utfordring i mange strategiprosesser er å finne balansen mellom en strategi uten en handlingsplan og en handlingsplan uten en klar strategi.

Disse fire prinsippene hjelper deg også formulere IT-strategien konsist. Når en forretningsleder spør ved kaffemaskinen vil du for eksempel kunne svare:

”Vi skal de neste årene prioritere: å effektivisere våre kjerneprosesser og vår kundeservice, redusere IT sine driftskostnader og redusere time-to-market for nye produkter med i hvert fall 30%. Dette skal vi oppnå gjennom å 1) modernisere kjernesystemet vårt og investere tungt i CRM, 2) sentralisere drift og infrastruktur og 3) jobbe mer effektivt  i hele produktutviklingsprosessen.”

Erfaring 1: Gratis flydata bidrar til økt datakvalitet og tjenesteorientering

Umiddelbart etter lanseringen kom kommentarene, spørsmålene og forslagene. Systemutviklere og flyspottere tok raskt tak i tjenestene og meldte tilbake om inkonsistens og mangler i datasettene. Å bli utsatt for ”amatørers” (da i ordets egentlige betydning) nysgjerrige og kritiske blikk har vært en verdifull og nyttig erfaring for Avinor. Denne “kollektive kvalitetssikringen” har bidratt til å øke kvaliteten på de aktuelle datasettene.

En annen konsekvens av frislippet har vært en mer generell dreining i tankesettet internt i Avinor. At data som tidligere kun har vært i bruk internt nå er eksponert eksternt har økt fokuset på tjenesteorientering, samt bidratt til å tydeliggjøre ansvarsforholdet mellom ulike enheter i organisasjonen. Det oppleves nå som enklere å snakke om både bruk, gjenbruk og utvikling av tjenester.



Erfaring 2: Gratis flydata bidrar til “kollektiv innovasjon”

Eksempel på iPhone-app med flydata fra Avinor

Det er ikke bare Avinor som har hatt nytte av at flydataene nå er tilgjengelig eksternt. Publikum nyter også godt av frislippet.

Kort tid etter lanseringen dukket det opp løsninger som nå hjelper Avinor med å holde det reisende publikum oppdatert på flytrafikkavviklingen. I dag benyttes Avinors API til flere ulike applikasjoner på både iPhone- og Android-plattformen, samt tjenester på en rekke større norske nettsteder.

Dette var alle tjenester som Avinor selv gjerne ønsket å utvikle, men aldri hadde anledning til å prioritere. Men som antatt i forkant; slipper vi dataene fri så vil andre lage løsningene “for oss”. Resultatet blir det samme; folk får tilgang til flytider.

(Som motvekt til iPhone-hysteriet utviklet forøvrig Avinor selv en enkel webløsning som fungerer på alle mobiltelefoner.)



Erfaring 3: Gratis flydata er positivt for omdømmet til Avinor

Lanseringen av API’et har bidratt til at Avinor ved flere anledninger har fått positiv medieomtale. De siste månedene har blant annet NRKbeta, Dagbladet.no og Teknisk Ukeblad hatt oppslag hvor Avinor trekkes fram som eksempel til etterfølgelse. Rett nok har omtalen vært relativt ”smal”, men all positiv omtale er eh… positivt (særlig når man tar i betraktning at Avinor stort sett bare er interessant for mediene når ting ikke går på skinner).

Internt har lanseringen også hatt en positiv omdømmeeffekt. Open data både føles og er moderne. Og Avinor har vært relativt tidlig ute på dette området. Per i dag har ikke altfor mange statlige virksomheter sluppet sine data til fri bruk, og innen internasjonal flytrafikk er eksemplene enda færre. Tanken på det kan gjøre en og annen ansatt i Avinor stolt. Open data bør definitivt være en målsetning, men foreløpig er det ingen selvfølge. Kudos til de som går foran.

- – - – -

Kommentar: Betydningen av erfaring 3 skal ikke overdrives. Verdien av erfaring 1 og 2 skal derimot ikke underdrives. Undertegnede er forøvrig en av flere BEKKere som jobber for Avinor.

I moderne produksjonsbedrifter er det i hovedsak tre hovedstadier som inngår i administrasjonen av selve produksjonen – ”forhåndsplanleggingen”, ”produksjonsstyringen” og ”lærefasen”.

Produksjonsstadier - forhåndsplanlegging, produksjonsstyring, lærefase

Hvordan kan IKT hjelpe?

I en produksjonsprosess har man alltid IKT-systemer på mange nivåer. Det kan eksistere systemer ”på gulvet” for overvåkning av produksjonsmaskiner – f.eks. SCADA (Supervisory Control And Data Acquisition), eller en ”operatørterminal” for maskinene. Man bruker innkjøps- eller økonomisystemer for å sende ordre til råvareleverandører eller for å sende faktura til kunder. De mere avanserte prosessene med mye volum krever ofte et datavarehus for å lage prognoser basert på statistikk fra tidligere ukers, måneders eller års prosesser – slik at man kan få planlagt produksjonen i god tid.
Det er ofte ikke mengden av informasjon fra systemene som er utfordringen – informasjonen finnes ofte, men i en uforedlet form som behøver å bli sammenstilt for å bli forstått. Informasjon fra bemanningsplaner og stemplingsur sammenstilles med produksjonstall for å få en optimal skiftplan. Når så produksjonsstyringen trår i funksjon idet mannskap kommer på jobb vil det skje avvik i alle planer – og selv om man tar høyde for et visst sykefravær kan det skje større endringer i starten av et vaktskifte som gjør at man må håndtere avvikene som oppstår. Togstans, ulykker på veiene og annet som gjør at folk ikke kommer tidsnok på jobb. Noen bedrifter bruker værdata fra eksterne kilder (f.eks. yr.no) som grunnlag for de avgjørelsene som treffes i forkant av starten av hvert skift. Vær kan også påvirke ankomst av råvarer og avgang til ferdig produserte varer og føre til lavere eller senere produksjon og brudd på båe kvalitetskrav og leveranseavtaler med neste ledd i verdikjeden.

Ett-blikks-statusen

Når man lever med overhengende krav til produksjonen som gjør at man i løpet av noen få minutter må ta avgjørelser om prioriteringer, håndtering av avvik og sette i gang tiltak kan ikke produksjonsledelsen ha systemer som man må grave i for å få tak i informasjonen som skal til for å kunne styre produksjonen i en annen retning. Hvis man har ti parallelle produksjonsmaskiner bemannet av hvert sitt team så vil som regel ikke utfallet av en av dem ha store følger for produksjonen ettersom dette vanligvis er et håndterbart avvik som man har gode rutiner for. En situasjon hvor fire maskiner feiler samtidig vil derimot potensielt ha store følger for restproduksjonen. I et stort produksjonslokale eller der disse maskinene er plassert i adskilte lokaler kreves det umillderbar statusinformasjon inn til en produksjonssentral som får opp alarmer eller ser status på skjermer hvor informasjonsvisningen er spesialbygd for dette formålet.
Ett-blikks-statusen er viktig for å kunne agere fort. Det er som regel ikke bare et ”panel” med status over noen få maskiner som skal presenteres. Visningen av informasjon fra et stort antall systemer må syes godt sammen for å fungere visuelt og forståelsesmessig. Visninger av verdier må kunne benchmarkes mot planlagte verdier for å kunne vise om det er et avvik man snakker om eller om det er en planlagt svingning. Planlagt vedlikehold av produksjonsmaskiner må ikke dukke opp som alarmer – i motsetning til plutselige stopp som ikke er planlagte. Plutselige driftsstans trenger ikke gripes inn i fra en produksjonsledelse før en viss tid er gått – som regel håndteres driftsavvik av personell ute i driftslokalet – men ved en lengre stans kan det være nyttig for produksjonsledelsen å vite om dette – og eventuelt omprioritere vedlikeholdspersonell inn der det har størst betydning for produksjonen.

Nøkterne prosjekter

For å komme et langt skritt på veien er det langt fra sikkert at man trenger å initiere et 40-millionersprosjekt. Som så ofte ellers kan enkle midler gjøre at man får mye av den informasjonen man ønsker tidlig uten at prislappen blir stor og blodrød. Erfaring viser at systemer med enkle indikatorer og alarmer tar brodden av de store ønskene og gjør at man enten klarer seg uten Det Store Prosjektet eller uansett klarer å utsette denne investeringen i flere år.