Radikal outsourcing skubber it-afdelingen ud til siden – vil det ramme dig?

It-afdelingen og it-chefen oplever i stigende grad, at ansvaret for al it inden for et område bliver placeret uden for it-afdelingen. Det sker, når hele services fra interaktionen med kunden til driften af it udføres af eksterne leverandører.

De mere perifere services i en virksomhed har i lang tid været sourcet på den måde: Lagerløsninger med lagerhotel, lager-håndtering, transport og håndtering af retur-varer er velkendte. På samme måde er lønbogholderen mange steder ved at blive erstattet af løn-som-en-service, hvor både bogholder, lønsedler og udbetaling med tilhørende systemer er håndteret af en ekstern leverandør.

Turen er nu kommet til nogle af selve virksomhedens it-kerneprodukter. Afhængig af hvad din organisation producerer, kan white-label services nemlig vise sig at være et bedre strategisk valg, end det produktionssystem du bruger i dag.

Lad os kalde denne tendens for vertikal sourcing for at skelne den fra klassisk it-sourcing. Klassisk it-sourcing diskuterer hvor vi placerer ansvaret for driften af it-understøttelsen af forretningsprocesser i form af drift af servere og systemer. Vertikal sourcing handler snarere om placeringen af hele ansvaret for at udføre forretningens processer, eller dele af dem, lige fra kunde-interaktion til driften af servere og systemer.

Hvilken konsekvens har tendensen mod vertikal sourcing så for it-afdelingerne som den, du måske sidder i?

Baseret på mine erfaringer fra kunder over de seneste år er her mine bud:

It-afdelingen mister rollen som primær it-leverandør – men er nødvendig som facilitator.

De dele af din it-afdeling, som har med sourcing, anskaffelser og leverandørstyring at gøre, vil få en ny rolle. It-afdelingen vil sidde på samme side af bordet som forretningen og rådgive om og facilitere indkøbet fra service-leverandører. Fordelen for it-chefen er at komme tættere på forretningen, en klassisk målsætning for it-chefer. Dog vil det være usædvanligt hvis alle systemer kan outsources. It-afdelingen vil derfor skulle udvikle sig til at fokusere på de få kompetencer og systemer, som gør netop den virksomhed til noget særligt. Det vil typisk være områder som kundedata, CRM, BI og ikke mindst integrationer på tværs af datamodeller, system-arkitekturer og frontends.

Blød principperne op – men sørg for at de fortsat sætter en retning.

Det er dyrt at tvinge leverandøren ud i at ændre deres standarder. Arkitekten skal derfor sikre sig, at I holder jer på leverandørens hoved-udviklingsspor. Samtidigt skal I gerne undgå at blive gift med leverandøren, for leverandøren skal kunne skiftes ud når en anden viser sig at være bedre om nogle år. Dét kræver fleksible, eller bløde, principper i kombination med effektiv leverandørstyring.

80 % af arkitekturen bliver irrelevant – de resterende 20 % bliver ekstremt relevante.

It-afdelingen vil ikke længere have direkte kontrol over væsentlige dele af virksomhedens it. Arkitekturen i leverandørens teknologistak og drifts-setup er (principielt) ligegyldigt. Arkitektens rolle i stedet bliver at sikre, at de indkøbte elementer fungerer med hinanden i kontekst af virksomheden. Integrationer på tværs af datamodeller og system-arkitekturer bliver måske det vigtigste at fastholde kontrollen over.

Prøv som en øvelse at tegne forretnings- og it-arkitekturen med whitelabel-produkter i midten og så ”resten” - virksomhedens specialsystemer - ude til højre. Hvis det giver mening, så er muligvis I kandidater til at indføre vertikal sourcing.

Hvis strategien med vertikal sourcing passer til dit firma, så rammer den nok også din it-afdeling. Er du klar til at håndtere den?

PA Consulting Group er i øvrigt vært ved en IT Breakfast Club på torsdag d. 29. november med temaet vertikal multi-vendor sourcing, hvor Mærsk Line IT og Danske Spil har indlæg. Deltagelse er kun for beslutningstagere med ansvar for it, men hvis du mener dig i målgruppen kan du kontakte mig via email på peter.norregaard hos paconsulting.com og høre om mulighederne for at deltage.

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Flemming T. Sjølin

Hej Peter

Tak for dit indlæg her på Version 2. Jeg vil meget gerne vide, hvilke tendenser, som du ser inden for ”vertikal outsourcing” og hvilke dele af ”it-arkitekturen” det som regel går udover.

Jeg har set, at du har behandlet emnet it-principper før, men jeg synes ikke rigtig, at jeg har set din definition på begrebet princip, hvormed jeg bliver en smule forvirret, når du skriver, at du gerne vil have, at principperne skal blødes op. Vil du have, at principperne bliver mindre konkrete og virke som slogans eller det Greefhorst & Propper (2011) kalder for ”credos”? Eller bør arkitekten fokusere på helt andre arbejdsområder? I givet fald hvordan fastholdes styringen af it-arkitekturen og hvilket fundament skal teknologistrategien så bygges på, hvis det da ikke er principper?

Du ønskes en god dag.

Med venlig hilsen

Peter Flemming Teunissen Sjølin

  • 0
  • 0
#2 Peter Nørregaard Blogger

Specifikt ser jeg en tendens til at white-label produkter i stigende grad kan erstatte proprietære produktionssystemer, og at de systemer købes som en service, som blot er underkastet en let integration før de fungerer og kunderne anvender dem direkte.

Der er ikke mange arkitekter, som i min erfaring har en formel definition af hvad principper er, men som stadigt er gode til deres arbejde. Så det er ikke lige dér jeg ser et indsatsområde. Du efterspørger eksempler på principper. Et eksempel, som det for mig har været nødvendigt at bløde op, var ”Da vi ønsker løst koblede systemer på en ensartet måde, skal leverandøren integrere via en kø-mekanisme” (vi havde ikke engang specificeret MQ/JMS/...). Da vi så hørte at de leverandører, som var i spil, stort set alle sammen integrerede via en stream og så noget catch-up i tilfælde af nedbrud, besluttede vi at bløde det op til ”… skal leverandøren levere en integrationsmekanisme som er robust overfor utilgængelighed af en den eller anden part i integrationen”.

Du nævner en teknologi-strategi – sådan nogle er overflødige for vertikal sourcede forretningsprocesser da leverandørernes teknologi er leverandørens eget ansvar og da vi som kunder blot aftager en service. Og hvis du fravælger leverandører på basis af deres teknologi så kan du meget vel fravælge leverandøren med den bedste løsning. Dér er en udfordring for den traditionelle arkitektrolle, som vi skal blive bedre til at håndtere.

  • 0
  • 0
#3 Peter Flemming T. Sjølin

Hej Peter Mange tak for dit svar. Jeg kan forstå, at du ser leverandørerne som en form for betroet partner der via sine kompetencer kan få omdannet legacy-systemer (mainframes, egenudviklet kode osv.) til en standardiseret platform og de på sigt vil arbejde på at få dem integreret med eller erstattet af COTS (commercial of the shelf) software.

Synspunktet er spændende især fordi det vil kræve at sourcing-kunderne (de organisationer der vil anvende vertikal outsourcing) skal have ret godt styr på deres it-arkitekturer for at overdage den til en sourcing-partner, og for at sourcing-partneren på en meningsfyldt måde kan få it-arkitekturen integreret med eller konverteret til en COTS-platform (eller service).

Om vertikal sourcing er ensbetydende med at teknologistrategier fra ”kundernes” perspektiv kan skrottes og alt ansvar kan overdrages til sourcing-partneren må tiden i bedste fald vise. Det fraholder mig dog ikke for at se visse komplikationer med den fremgangsmåde:

1) Sourcing-kunden bliver stadig nød til at have en holdning til udvikling og en holdning til, hvordan der udvikles i tilfælde af at de vil skifte sourcing –partner. Uden en sådan holdning er sourcing-kunden de facto bundet låst til sin leverandør. En for stor en tilknytning til leverandøren vil have konsekvenser for sourcing-kundens forhandlingssituation og derigennem den strategiske situation 2) Teknologistrategien repræsentere i udgangspunktet organisationens de facto holdning til hvilke teknologier, som organisationen vil satse på og på den måde også organisationens teknologiske udviklingsstrategi 3) Øvelsen bag at formulere en teknologi-strategi er efter min mening også den øvelse der ligger til grobund for identificering af ”capabilities” organisationen på sigt kan opnå 4) It-principperne er vel egentlig designet til at fungere som et grundlag for at beslutningstagerne træffer beslutninger baseret på et bestemt rationale og ved at forkaste principperne skal budskaberne så egentlig kommunikeres ud igen, men på en anden måde.

Med venlig hilsen Peter Flemming Teunissen Sjølin

  • 0
  • 0
#4 Peter Nørregaard Blogger

Det er nogle interessante overvejelser om principper, du har.

Jeg kan forstå, at du ser leverandørerne som en form for betroet partner der via sine kompetencer kan få omdannet legacy-systemer (mainframes, egenudviklet kode osv.) til en standardiseret platform og de på sigt vil arbejde på at få dem integreret med eller erstattet af COTS (commercial of the shelf) software

Nej, ikke helt, Peter. Jeg taler om at legacy-produktionssystemerne smides ud og erstattes af systemer fra leverandøren, ikke at nogen koder noget om.

Så situationen er i stedet at fx en bank opgiver sin egen trading-platform og erstatter den med en indkøbt og serviceret udefra - som et whitelabel-produkt. Den mulighed er meget interessant for forretningen og sætter it-afdelingen i en ny situation.

  • 0
  • 0
#5 Peter Flemming T. Sjølin

Hej Peter

Mange tak for dit svar. Med dit eksempel, hvor du mener at legacy systemer i produktionsmiljøet udskiftes med PaaS eller SaaS produkter er i og for sig ganske interessant, men det vil nu stadig kræve en omstilling for sourcing-kunderne fordi der ofte findes integrationer til applikationerne i produktionsmiljøet. Jeg betragter dermed definitionen af et legacy produktionssystem som systemer der findes i sourcing-kundens produktionsmiljø. Der kan der med god grund argumenteres for at der ikke bør udvikles i produktionsmiljøet, men det jeg hører fra mit netværk så virker det som det er noget der finder sted alligevel i mange organisationer. Det sker ofte når der opstår en ”her og nu” opgave der kan relateres til problemstillinger der høre til at konkurrenterne enten lancerer en ny feature eller en beslutningstager (typisk) uden for it-afdelingen vil have implementeret en ny funktion fordi det vil give hans afdeling en fordel (eller hvad de mener, vil være en) for et givent område eller det man kan kalde offensiv-udvikling.

Spørgsmålet bliver så, hvor vigtigt er det for de fleste organisationer at udskifte deres legacy-systemer og hvordan påvirker det konkurrencefordele? Mystisk nok er det vigtigt for it-afdelingerne at understrege, at it-legacy systemerne er vigtige at slippe af med, men alligevel bruger selv de mest it-modne organisationer legacy-systemer og legacy-platforme (se nedenfor) og der udvikles i øvrigt flittigt på dem selvom det domminerende slogan i disse tider er reduktion af omkostninger på drift og udvikling. Der findes med andre ord et paradoks i ret mange organisationer set i forhold til udviklingsstrategi, teknologistrategi og den kommunikation som it-afdelingerne typisk anvender overfor interessenterne (læs beslutningstagere) uden for it-afdelingen.

Du bruger en bank som eksempel, og tommelfingerreglen er at banker (især investeringsbanker) kan anskues som værende meget it-modne fordi denne sektor har haft krav om at deres operating platform skulle kunne håndteres effektivt og den skulle være tilgængelig fra mange forskellige steder og samtidigt være kerne stabil. Finanssektoren bruger i stor stil legacy-software og platforme, og de udvikler hyppigt på dem, af samme årsag er der med garanti også jobs til applikationsudviklere der kan udvikle i PL/1 eller Cobol om 10 til 15 år eller længere ude i fremtiden. Et eksempel på en udbyder af white-label produkter er Saxo Bank, som på nuværende tidspunkt udgiver en white-label udgave af deres investeringsplatform til andre banker eller finansinstitutioner. Det er innovativt, det er spændende og det er uden tvivl et godt produkt og konceptet ville sikkert kunne anvendes af andre aktører i finanssektoren. Men giver det mening for andre sektorer at tage white-label konceptet til sig? Som jeg tidligere har nævnt, så er finanssektoren typisk meget it-moden og der stilles i forvejen krav til at interessenterne har styr på deres it-arkitektur. Min vurdering er, at organisationer der vil købe sig adgang til en service eller capability som kræver en høj grad af it-modenhed. Tilmed vil konceptet begrænse organisationernes omstillingsparathed fordi ”hovsa løsningerne” ikke nær så nemt kan implementeres, hvormed vi så bliver nød til at antage at offensiv-udvikling og drift så kan separeres.

For at en it-afdeling i det hele taget kan flytte sig fra at alle opgaverne bliver kastet i hovedet på den til at sikre en kontrollerbar udvikling, så kræver det fundamentalt set at it-afdelingen får formuleret it-principper og en teknologistrategi. Dertil så bør at beslutningstagerne i it-afdelingen være i dialog med beslutningstagerne uden for it-afdelingen for at sikre, at projektporteføljen understøtter de forretningsideer som antageligvis skal realiseres inden for en rimelig kort tidsperiode.

Det er min vurdering ikke være muligt at stille krav til sourcing-partneres udviklingsspor (og især hvis der er flere sourcing-leverandører), hvis der i at der i kontrakterne ikke kan refereres til principper og ikke mindst standarder, som de skal overholde. Det er ikke nødvendigvis at formulere principperne og standarderne mere frit (eller blødere) er den rette løsning. Først og fremmest bør it-principperne kunne sikre at den udvikling og driftsarbejdet, som it-afdelingen tager sig af fører til en modning af it-arkitekturen. Når it-arkitekturen er modnet tilpas meget så vil det være muligt at kunne tilkøbe services eller capabilites, men det vil stadig påvirke organisationens strategiske situation, hvis den knytter sig til en udbyder af en white-lebel PaaS, SaaS eller forretningsservice.

Jeg vurdere at der vil være ret mange problemstillinger for de organisationer der arbejder sig i den retning, hvis de vel at mærke ikke er særdeles it-modne.

Teorien om at tilkøbe services eller capabilities lyder god og en næsten lige til at implementere, hvis man har læst Prahalad & Krishnans bog ”The New Age of Innovation: Driving Cocreated Value Through Global Networks”, men jeg tror ikke at det vil være nem øvelse for organisationer har en umoden it-arkitektur at implementere processer og services så de virker tilnærmelses gnidningsfrit, vel at mærke ved at både sourcing-kunde og sourcing-leverandører opnår det tilsigtede strategiske resultat. Den specifikke capability (evnen) til at udskifte et it-legacy produktionssystem til at koste organisationen ressourcer (ofte mange ressourcer) at opnå, og det er egentlig usikkert om organisationerne vil kunne opnå nogen nævneværdig strategisk fordel. Jeg tror, at det vil give enterprisearkitektur funktionen og arkitekterne langt større mulighed for at udvikle organisationerne, hvis fokus den udvikling der skal til for at der kommer nok styr på it-arkitekturen til, at it-afdelingen kan påvirke forretningsudviklingen. Det kan til gengæld kun opnås ved hjælp af it-principper og teknologistrategier. Med de to ting på plads har arkitekterne værktøjer der kan bruges til udvikling af organisationen ved hjælp af facilitering af beslutningstagernes holdninger. Faciliteringen bør så lede til en roadmapping proces der kan så igen kan lede til, at organisationerne opnår de ønskede strategiske fordele. Imellem linjerne kan man så læse at det arkitekterne kan identificere er de tekniske og forretningsmæssige capabilities (evner) som bør være til stede for at organisationen kan udvikles. Det er en af de perspektiver, som jeg tror, bliver vigtigst for arkitekterne i fremtiden.

Det er en fin øvelse at tegne it-landskabet med forbindelser til white-label produkter, men inden enterprisearkitekten, chefarkitekten, CTO’en og it-direktøren gnider sig i hænderne og ser hurtige løsninger til standardiseringsproblematikkerne i organisationen, så bør nogle flere faser sættes på i øvelsen som for eksempel overvejelser om hvor god vil organisationens omstillingsparathed vil være ved implementering af en PaaS, SaaS eller forretningsservice (eller måske en ekstern line of business) der drives hos en leverandør og dertil bør en fase omhandlende gradende af it-modenhed der skal til for at organisationen vil være i stand til at opnå reelle konkurrencefordele ved at anvende white-label produkterne. Jeg tror, at it-principper bliver mere vigtige at have formuleret i en it-arkitektur kontekst, da de er med til at danne en mening for it-afdelingens fokus for investering og dermed et grundlag for den holdning der skal til for at modne it-arkitekturen til det punkt at den bidrager aktivt i forretningsudviklingsprocessen. White-label produkter (PaaS, SaaS og så videre) kan på sigt nok vise sig relevante, men for at opnå fordelene med disse services kræves en stramstyring der nok først kan opnås, når it-arkitekturen er ensartet nok til at legacy-systemer kan udskiftes uden en meromkostning ved udvikling. Ensartethed kan igen kun opnås ved at it-afdelingen målrettet udvikler efter principper og standarder og ligeledes står fast ved målsætningen ved at have en holdning til udvikling og drift den selv varetager, men også den holdning og drift sourcing-leverandørerne har.

Med venlig hilsen Peter Flemming Teunissen Sjølin

  • 0
  • 0
Log ind eller Opret konto for at kommentere