Kategoriarkiv: Ukategorisert

For eller imot offshoring av IT?

Det siste tiåret har det pågåt mye Offshoring av IT, dvs. at større private og offentlige virksomheter kjøper IT-tjenester fra et land utenfor Norden. Ikke bare IT, men tjenesteutsetting er også tatt ibruk på flere andre sektorer som bank, finans, HR og f.eks. på kvalitetssikring, leverandøravtaler for å nevne noe. Stikkordet har vært: Har dere repeterende arbeidsprosesser som er timeintensive, så tilbys lavkost ressurser og en tjenestemodell. Dette er gjerne samtidig en sentralisering av tjenester hvor mange små enheter eller avdelinger slås sammen til en stor som betjenes fra utlandet.

Rasjonalet for offshoring er selvsagt i økonomisk teori – lov om spesialisering, og lov om lønnsomhet av skalering. Offshore selskapet er spesialist på den aktuelle tjenester, de er mao. effektive og gjør dette for flere andre kunder i samme situasjon. De kan også bedre dra ut skalaeffekter. De som selger deg «Offshoring av IT» kan love deg kanskje 30-35% reduksjon av årlige IT kostnader. Dette høres jo forlokkende ut, men hvilke fordeler og ulemper er der i dette bildet? Store konsern som f.eks. Telenor, Aker m.fl. har sett at slike storskaleffekter kan oppnås også internt ved å slå sammen stabsenheter. Dette resulterer så i spin-offs hetende såkalte Business Partners. Kostnadsreduksjonen blir da en lønnsom investering.

Nye momenter kommer inn ift. de tradisjonelle mot argumentene som  har vært 1) mangel på nærhet, 2) kommunikasjonsutfordringer, 3) fremmedgjøring av tjenesten overfor brukere osv. De økonomiske gevinstene har i noen tilfeller uteblitt eller tatt lengre tid, men så er det fundamentale også at IT utvikling går så fort at man har problemer med å tilfredstille avanserte forbrukere fra en intern IT avdeling.

Kravet om innvoasjon, digitalisering og brukerens krav om forbrukerløsninger er også momenter for outsourcing. Offshoring er bare en type medisin for et symptom – interne krav mot IT avdelingen, men det er unektelig økonomiske gevinst som er hovedargumentet. At den du outsourcer til har skalafordeler og kan spesialisere seg på IT og digitaliering er en annen fordel. Dermed oppnår du ideelt sett både kostnadsfordeler og innovasjonsgevinst på tjenestetilbudet for IT leveranser.

Offshoring sementerer muligheten for endring, hevder noen. Man har jo ikke lenger innsikt i prosessen og forutsetninger for å si om den er digital nok. Her vil motargumentet være benchmarking av tjenester mot andre tilsvarende leverandører. Likevel er det unektelig faktum at mange nå henter hjem igjen arbeidsplasser for å få kortreist effekter, samt kunne robotisere eller aksellere digitaliseringen.

Avhengigheten øker ift. business partneren. Dette kan over tid medføre lavere IT servicenivå. Hvis man da ikke har klare KPIer og muligheter for å begrense skadene – eller hindre mulige «hold-up» situasjoner.

Når man så har bestemt seg og skal igang med offshoring av IT, så kreves god bestillerkompetanse. Foruten gode standarder og krav til kontraktsforståelse i innkjøpsprosessen, så kreves godt definerte tjenester som lar seg outsource. Det du vurderer å sette bort må være på et vis standardisert – eller ha som mål å bli standardisert.

Leverandører tilbyr deg gjerne å gjøre standardiseringen, men det kan fort blir dyrt om man outsourcer før man har laget en god beste praksis prosess med KPI-er som måler effektivitet.

Forholdet til ITIL bør avklares. ITIL er en beste praksis IT service management standard som nyttes av tjenesteleverandører. Ikke alle er like flinke til å bruke en ITIL-leverandør. ITIL kjøp gir  også en rigiditet som ikke alltid oppleves som brukervennlig, Man må derfor ha gode avtaler som er forståelig og ikke kun iht. IT leverandørens standard.

Det bør være snakk om å sette igang med benchmarking og at IT leverandøren har opplegg for å gi ut måltall. Dette må inn i kontrakten med IT leverandøren for å unngå at denne får for mange soveputer under armene som vi kaller det på godt norsk. Uten målinger blir oppfatning av service subjektivt og individuelt – og vi blir ute av stand til å ha et objektivt kritere for reduksjon i betaling.

Gevinstdeling er for de som har benyttet dette et must og resulterer i mer fornøyde kunder.
En tjenesteleverandør skal være hyggelig og imøtekommende, men det er klart at dersom man har økonomiske insentiver til å oppføre seg på en pen og høflig måte, så vil det hjelpe på. Servicemålinger kan være en måte å måle brukertilfredshet på. Slik man møter i sikkerhetskontrollen på en flyplass for eksempel.

Sikkerhetsfokus og mål for risiko er like viktig i basisorganisasjoner som har IT brukere som i
Offshoring. Ellers gir det økt sårbarhet. Vi har sett i den senere tid at persondata kommer på avveier. Vi har også sett at tilgang for offshorepersonnel til helsedata gir sårbarheter som vi vil være foruten. Å sikre seg er enkelt ved å gjennomføre sikkerhetsanaslyser før, under og etter. Man bør også lage seg et risikobasert ledelsessystem som kan monitorere kritiske prosesser og få på plass sikre katastrofeplaner. Dette gjelder både SMB og konsern.

Digitaliseringsutfordringen kommer også på dette området. Mange ønsker å våre i «lead» på digitaliseringsområdet. Tjenester vil kunne forandre og helt eller delvis eliminere prosesser – med uvisst utfall, men dette kan jo også innbakes i kontrakter med din IT business partner.

En trussel kan være at man ikke lenger trenger offshoringvirksomheten, men IT kompetansen er uansett nødvendig enten den kjøpes fra en IT business partner eller eies internt. Kunnskapen om effektive arbeidsprosesser går forhåpentligvis heller aldri av moten.

Outsourcing og nearshoring er også i endring. De fleste bransjer er i endring, og robotosering av tjenester er på vei inn – f.eks. i form av chatbots for support. Kanskje er man enda bedre rustet til å ta ibruk nye tjenester ved en kjøpsbasert IT tjenesteleveransemodell?  Vi vil nok se store endringer også på dette området i årene fremover. Man kan ha de beste intensjoner, men uten KPIer og uten gode IT kontrakter som gjenspeiler gjensidighet i  partnersavtalene så ville jeg vært skeptisk til outsourcing.

Les mer om offshoring og nearshoring i andre artikler.

Ny virksomhetsarkitektur – Hvordan prioritere riktig?

Nyere IT løsninger har den fordelen at man endelig kan se fremover og ikke trenger å tenke på fortiden. Eller er det ikke så enkelt? Hvem kan svare på det? Vi snakker ikke om enkle «apper», men komplekse virksomhetskritiske IT-løsninger. Kartlegging bør være første steg på veien. Det er her virksomhetsarkitekten kommer inn.

Eksterne konsulenter er gjerne eksperter på å lage gode business-case som et grunnlag for å foreslå ny IT arkitektur. Enten du har vokst ut av dagens ERP løsning eller vurderer hvordan du skal ta vare på kunden bedre ved hjelp av CRM. Vurderingen av hvor godt systemet passer med bedriftens interne prosesser har imidlertid ingen andre enn bedriften selv forutsetninger for å vite noe om. Her kreves analyse. Konsulenter kan i beste fall være en katalysator for endring.

shakehands

En konsulentvurdering som ikke tar hensyn til dagens arkitektur hopper gjerne også bukk over muligheten til å intervjue dagens brukere og ledere. Innføring av nytt CRM, ERP eller PLM system uten reell brukermedvirkning er ingen god ide. Man kan ha god avkastning på papiret, men uten reell forankring av nye IT-løsninger vil resultatet fort bli negativt.

En helhetlig virksomhetsarkitektur ser både på dagens og fremtidens behov. Når man planlegger prosjekt og initiativer i forhold til virksomhetens arkitekturbehov, behøves et godt rammeverk – et  som ikke er for snevert. For hensikten er ikke å lage et IT-system, men å støtte forretningsmålene og tilhørende forretningsprosesser. Metoden må sikre eierskap til krav – både prosess-, teknologi- og brukerkrav. Teknologi er oftere i seg selv et krav og en egen premissgiver for å sikre bedriftens fremtidige konkurransekraft. Storkonsernet General Electric (GE) sier i sin markedsføring av programvare at enhver produksjonsbedrift må bli en programvarebedrift for å overleve på sikt. Kanskje har de rett?

En god virksomhetsarkitektur beskriver sammenhenger mellom prosess, IT arkitektur og organisasjon. Uten en god forståelse fra eier av forretningsprosessene, får man liten gevinst. Det er derfor viktig at virksomhetsarkitekturen kan beskrives på forståelig vis for alle parter. Tilstrekkelig analyse må også til for bedriftens utgangspunkt. Endringer fra dagens til fremtidens løsninger betinger gjerne en kostnad. Hvilke kostnader finnes det? Definisjonen av begrepet kostnad må omfatte kostnad ved å endre; kostnaden ved å bytte ut dagens operative IT infrastruktur, men også kostnaden ved endring og opplæring i nye prosesser. Likevel kan det lønne seg å investere i nye løsninger, da de ofte er mer brukervennlige enn sine forgjengere.

managing complexity

Kompleksitet koster. Gap ikke for høyt. På bakgrunn av kompleksiteten i dagens virksomhetsarkitektur er det mange som vegrer seg for å gå i gang. Og i mange tilfeller vil bedriften ha for knappe ressurser til f.eks. å kunne løfte seg på en helt ny IT plattform. I andre tilfeller vil det oppfattes som en befrielse å forenkle løsningene som mange ganger er basert på et «lappverk» av overlappende systemer. En enkel analyse vil kunne avdekke hvor kompleks og kostbar en endring kan bli.

Plassering av ansvaret for arkitektur. Forretningssiden bør definitivt forstå viktigheten av eierskap til en helhetlig virksomhetsarkitektur. Den bør ikke for lett delegeres bort, men beholdes på forretningssiden, gjerne under en CIO rolle. Den interne IT avdeling har gjerne en annen agenda som går ut på å forvalte dagens struktur. Her ligger det en mulig konflikt; Å legge arkitektur til Intern IT kan medføre en sammenblanding av roller. Samspillet med forretningssiden bør tillegges vekt, slik at man sikrer prosesseierskap til teknologien. Arkitekten blir da som rolle tilsier – en arkitekt med oppdragsgivere.

Arkitektens egenskaper. Hun bør være mest mulig uavhengig, ha god forståelse for effektive arbeidsprosesser og en god porsjon «mot i brystet». Hvorfor det? Et spørsmål fremover kan være: Skal vi la brukerne styre mer selv og legge til rette for «selvbygging» eller skal vi sentralt styre dette ved hjelp av intern IT? Eller sagt på en mer direkte måte: Trenger du hushjelp når du har alle disse flotte husholdningsmaskinene? Arkitektens rolle blir nok mer og mer å designe og tilrettelegge kjøkkenet basert på aktørenes krav til komponentene som inngår.

Et arkitektur-prosjekt er et planleggingsprosjekt. Da må man kunne diskutere overordnet prioritering – om det er viktigst å vedlikeholde eksisterende «haltende» portefølje, eller tenke nytt og helhetlig om arbeidsprosesser. Med dagens raske utvikling kan det siste være et nødvendig skritt for å overleve. I tillegg bør man spørre hvordan prosessen kan bli mer effektiv med støtte av teknologi. Det må være lov å stille seg hypotetiske spørsmål!

Teknologi som driver i seg selv. Det er viktig at arkitekten spør seg hva ny teknologi kan gjøre for prosessene og hvilke rammebetingelser digitaliseringen gir? Alternativt kan utfallet fort bli et IT prosjekt uten avkastning om man ikke tar hensyn til alle fire sider av diamanten: Prosess, system, teknologi og organisasjon. Og så var det var det å huske på bedriftens evne til omstilling…som allerede nevnt.

Gode verktøy nødvendig. Bruk av strukturerte modeller og verktøy kan overdrives. Likevel skal man ikke undervurdere organisasjonens behov for en god visjon eller et godt «konsept» for å beskrive arkitekturutfordringen – et bilde sier mer enn 1000 ord. Vi forstår alle arkitektens utfordring i overført betydning når det er snakk om fysisk infrastruktur f.eks. hvor komplisert det er å bygge veier eller høyhus. Vi glemmer imidlertid at informasjonsstrukturer er kompliserte – og lite konkrete for de uinnvidde. Derfor kreves detaljerte planer eller programmer for endring av «informasjonsveien» i bedriften.

Til slutt. Det er viktig med felles mål og felles begreper; Et steg kan være å etablere felles referansemodell for virksomheten, slik at flere forstår helheten og kan diskutere begreper, retning og innsatsfaktorer. Ved å forstå sammenhengen mellom prosess, systemer, teknologi og organisasjon kan man bedre prioritere de riktige arkitektur-prosjektene. Dette krever imidlertid at man investerer i å få eiere av prosessene og teknologien på banen i en felles diskusjon om lønnsomme veivalg. På den måten unngår man i overført betydning å lage ubrukelige veitrasseer som ikke viser seg liv laga som pressen ynder å omtale det som – «unngå flere myslykkede IT prosjekter» som det jo allerede er for mange av.

Del gjerne dine erfaringer med virksomhetsarkitektur og kommenter på CIO bloggen.

Konfigurasjonsstyring – en kilde til lønnsomhet

Når du skal kjøpe bil, velger du i blant teknikk- og sportspakker og andre opsjoner som tilbys. Det sies at en bil kan ha mer enn 6000 varianter å velge i for en modell. Dette er vel å bra for høyvolumprodusenter som i bilindustrien. I den norske leverandørindustrien som selger til olje- og gassbransjen er volumene så lave av like deler at det gir få eller ingen skalaeffekter. Da er det fort måten man jobber på som skiller de lønnsomme fra de ulønnsomme.

Begrepet konfigurasjonsstyring er kjent for ingeniører som jobber med produktutvikling som en måte å sikre konsistens på produktleveranser for hele produktets levetid – og for solgte individ f.eks. anleggsmaskiner. Konsistent kvalitet er en stor utfordring i norsk leverandørindustri, både fordi det er få enheter som selges og fordi det etterspørres mange endringer – en lite kostnadseffektiv kombinasjon. Ettersom det blir mange mulige kombinasjoner, blir enhetsprisen høy. Tenk om vi tross lavt volum kunne lage «unike produkter» for hver kunde slik som i bilindustrien? Med automatiserte konfigurasjonsverktøy er dette idag mulig, men det krever forståelse for standardisering av engineering på detaljnivå og evne til å bygge opp produktstrukturer og moduler som er forberedt for gjenbruk.

DB_bil

Konfigurert på bestilling

I mangel av et bedre norsk ord på Configure-to-Order, konfigurert på bestilling beskriver prosessen fra kunden velger opsjoner til du har en ferdig konfigurert maskin / bil / produkt. I industriell sammenheng innen leverandørindustrien i Norge er dette en sjelden mulighet. Vi har nå verktøy som gjør det mulig å effektivt gjenbruke dokumentasjon og holde full oversikt over hvilke komponenter og varianter som er forbrukt i de solgte individene. Dette gjør det både mulig å tilby kunden en unik serviceopplevelse, og det gir en etterlengtet kostbesparelse. Hvordan er det mulig?

Arv og Intelligens

I et verktøy som støtter en konfigurasjonsprosess bygges det opp strukturer og logikk for gjenbruk og arv. Intelligensen ligger innkapslet i hvert objekt i strukturen (f.eks. vet bildøren at den henger på bilen). Konseptuelt er dette ikke vanskelig å forstå. Derimot er det vanskelig for oss legfolk å forstå den kompleksitet som ligger i design av et produkt som f.eks. en bil representerer. Hva kreves ikke av tegningsunderlag, underleveranser, byggeinstruks, sammenstillingsveiledning, brukerveiledning og myndighetsgodkjennelser? Alt-i-alt en hel bråte med dokumenter som man gjerne vil slippe å vedlikeholde manuelt, både i innhold og utforming.

Det fine med konfigurasjonsverktøy er at du kan lage produktet som du vil innenfor gitte rammer. Utfordringen er vedlikehold av informasjon. Uten intelligens og kjennskap til bransjen og produktets egenart er det tilnærmet umulig å automatisere prosessen med verktøy. Logikken må i tillegg tilpasses kontekst.

Arv og Miljø

En leveranseprosess er det mer enn produktdesign. Når produktet ser dagens lys som en prototype, er det ennå langt fram til leveranse. Produktet skal gjennom en prosess av multiple systemer (CRM, ERP, PLM osv.). Konfigurasjonsverktøyene må være tilpasningsvennlige overfor denne konteksten de inngår i. Hvilke verktøy benyttes i bransjen osv.

Produktleveranse

Med et konfigurasjonsstyringsprogram vil man til slutt sette sammen individene ved at deler som gjenbrukes «arver» innholdet (dokumentet) og ikke dupliseres med mindre det er annerledes enn sine foreldre. Dette gjør at en sykkel med fargen rød hovedsaklig har samme dokumentasjonssett som en blå osv. (de har jo like egenskaper ellers). Uten et konfigurasjonssystem vil man derimot fort mangedoble dokumentasjonsbehovet. Tar man kopi av dokumentasjonshaugen forsvinner hele grunnlaget eller økonomien i leveransen av den blå kopien.

Konklusjon

I leverandørindustrien i Norge trengs mer bruk av verktøy for konfigurasjonsstyring for å få ned enhetskostnadene ved å produsere enkeltkomponenter og sammenstillinger. Her har vi mye å lære av bilindustrien i Sverige og Europa, men ikke alt er gjennomførbart ettersom miljøet og bruken av verktøy ofte er annerledes. Veien mot full konfigurasjonsstyring krever derfor tålmodighet, men kunnskapen kan generelt sett lett overføres på tvers av bransjer.

Lykke til med å forbedre lønnsomheten i din bedrift!

Del gjerne dine erfaringer med programvare for konfigurasjonsstyring og kommenter på CIO bloggen.