Är CIO:s mål att rationalisera bort sig själva?
Jag sitter på en konferens om souricng och lyssnar på flera talare. Efter ett tag är det svårt att hålla fokus och jag börjar pilla med telefonen. Plötsligt hör jag CIO:n som talar för tillfället säga: "Mitt mål är att kunna bortrationalisera mig själv." Jag hoppar till, tittar upp, får en skarp blick och tänker: Är inte det att kapitulera och missa en fantastisk chans just nu till att förändra IT-avdelningens roll?
CIO:n som talar förklarar sin ståndpunkt och jag känner igen den från andra som uttryckt sig liknande. Alla, inte bara IT, kommer att i framtiden lära sig att nyttja ny teknik. Inte bara IT-personal kommer att kunna göra enklare programmering, ta fram rapportvyer, ändra processer för robotar etc. Detta handhavande måste ligga nära ett djupt verksamhetskunnande. Kort sagt, digitaliseringen kommer att ske av verksamheten själva (med undantag av tyngre IT-relaterade mastodontprojekt). Kvar blir en rad infrastrukturtjänster som allt bättre kan paketeras i lådor och skickas i väg till outsourcing-leverantören. Samt förvaltning av osexiga legacy applikationer som för många företag gärna får följa med.
När hela processflödena kring infrastrukturtjänsterna och alla dess system ägs och styrs av outsourcingleverantören och detta är enligt en generell standard hos alla deras kunder, så är det inte så mycket att skruva på längre. När basförvaltning av applikationer ersatts av en näst intill komplett portfölj SaaS-tjänster så rullar det också på ganska bra. När Microsofts, Googles eller Amazons PaaS-miljöer är plats så kan (teoretiskt) verksamheten själva labba och göra prototyper eller egenutveckling. Och när väl BI-verktygen är uppsatta och mappade mot master-databaser så kan verksamheten själva och göra sina rapportvyer.
Så, kanske har CIO:n rätt, tänker jag? Nej, rättar jag mig snabbt och skakar för mig själv på huvudet. Varför inte se detta läge som det motsatta - detta är chansen för IT-avdelningen att stärka sin roll. Att på allvar bli involverad i förändringsresan och digitaliseringen inom företaget. Detta är ju världens chans! Varför skall vi ge bort den? Låter jag protektionistisk? Det handlar inte om att stoppa verksamheten i någon av ovanstående möjligheter. Det handlar bara om att ständigt jobba för att erbjuda ett allternativ från IT som är kraftfullare. Detta är minsann inget som kommer av sig själv, utan något man måste kämpa för. Men det går. Låt mig ge några exempel.
Inom flera företag så har Business Intelligence funktionen länge legat inom ekonomiavdelningen. Det är för många ganska logiskt eftersom Business Controllers har många förfrågningar från ledningen att redovisa ekonomiska siffror på många olika leder. Det som dock inte alltid är lika tydligt, är ifall det inom andra delar av företaget också behövs BI-tjänster och hur gör man där? Jag hörde mig runt och fick tre typer av svar: De som hade behov och hade löst det själva med egna system och egen kompetens (som inte delades med någon annan). De som hade behovet men var frustrerade för att de inte hade verktygen eller kompetensen och de som inte initialt hade något behov men som när man pratade med dem plötsligt började se många behov.
För vår IT-organisation var detta en möjlighet till utveckling för hela företaget och ITs roll. Kunde vi inom IT samla utvecklarkompetens (back-end och front-end) kring Data & Analytics, standardisera plattformarna för detta, ha en högtillgänglighet med poolade resurser och vara evangelister för D&A i företaget, så skulle det finnas ett behov. Och så blev det. Idag är denna gruppering 12 personer. Betyder det att verksamheten inte får göra något själva? Absolut inte. Men mycket av deras behov är det enklare för dem att nyttja vårt team till.
Ett annat område är Robot Process Automation & AI (RPA). Flera CIO:er säkert hört ledarna inom divisionerna säga: "Detta är robotar som kan likställas med anställda i verksamheten - bara det att muspekaren på deras skärmar rör sig automatiskt." Dvs det är fullt logiskt att detta skall ligga inom verksamheten. När en del infrastruktur frågor efter ett tag börjar komma om hur dessa Robot-verktyg skall sättas upp, så blir det snabbt en typisk tråkig teknikfråga som verksamheten gärna ser att IT löser...okej då, ansvarar för. Vem skall då programmera robotarna? Inte så svårt, det kan verksamheten göra. Men förvaltningen och incidenthanteringen av dessa? Behöver verksamheten ha beredskap för detta? Hmm. Lika bra att IT på uppdrag av verksamheten programmerar och förvaltar robotarna. Kvar är processanalysen - BA-rollerna (business-analysts) och där är verksamheten ofta glasklar på att det är en absolut självklar roll som skall ligga i verksamheten.
Jag har sett när man startat igång enligt ovanstående uppdelning, men där det efter ett tag märks att vissa avdelningar trots stora behov och bra business case för RPA, ändå inte kommer igång. Problemet har visat sig vara att de inte har sina processer tillräckligt tydligt beskrivna - och de har inte tid att göra det heller. "Ok, kan IT stötta oss med detta också?" Efter drygt ett år så har idag vår IT funktion en avdelning för Automation & AI som har hela fabriken från ax-till-limpa för att stötta verksamheten med automatisering av deras processer. Och plötsligt är verksamheten tvärt om tacksam för denna kompletta leverans.
Ytterligare ett exempel är inom Change Management. Denna term har på senare år blivit allt viktigare. Företagen inser att deras flexibilitet och förändringstakt för att parera saker som sker på marknaden, måste vara mycket större än tidigare. Den är ändå inte helt ny i sitt intågande och har länge funnits på olika sätt, tex. som Champions och Superuser för olika nya vitala system som brukar lanseras. Även delprojektledare för Change i större IT-relaterade projekt har länge varit en naturlig del i projektmetodiken. Däremot den långsiktiga förändringshanteringen och den kontinuerliga uppföljningen om vi får effekt av de nya digitala verktyg vi inför, brukar det slarvas med en del när sista styrgruppsmötet är avslutat. I diskussionen om hur man förstäker Change fokuset i ett företag har jag stött på många falanger och åsikter. Ledare i verksamheten som blir oroliga att IT ens för frågan på tal och som menar att Champions och Superusers inte kan vara något annat är verksamhetspersonal som är extra kunniga i systemen. I företag som verkar i konsultbranshen och många gånger har en spets inom området och framgångsrikt hjälper många andra kunder med detta, så är det från den falangen självklart all typ av förändringshantering borde drivas dessa expertkonsulter. Till detta så har vi ofta en HR avdelning som ansvarar för utbildningen av alla anställda.
Men när man väl kommer igång med dessa diskussioner - Hur skall vi förbättra vårt förändringsbeteende - så börjar också en del frågor dyka upp: Vem håller ihop alla Champions? Är det effektivt eller ej att ha olika för varje system vi lanserar? Hur underhåller vi våra grupper av Champions eller dör dessa roller ut av sig själva efter ett tag? Och hur fungerar vår förändringledning i projekt långsiktigt om det ofta är olika expertkonsulter som tillfälligt kommer in och håller i detta och ibland t o m tvungas att bytas ut för de skall på kunduppdrag. Och utbildningskatalogen, är den proaktiv eller reaktiv? Diskussionerna hos oss slutade med att IT tillsammans med HR och kommunikationsavdelningen fick bilda ett virtuellt team för företagets förändringshantering (Change Management Team). Efter ett tag såg vi synergierna med att de i förändringsteamet som var ute och hade örat mot rälsen behövde vara nära systemförvaltarna av applikationerna och teamet kom att ledas av en person med skarp profil inom detta men som flyttade in i IT organisationen.
Detta är några exempel där jag ser att det nu är världens chans för IT att transformeras och få en central roll i verksamhetens digitalisering. Prototyphantering, Projektledarpooler och Kravare är andra områden där vår satsning och vårt erbjudande från IT slagit väl ut. Har man varit med ett tag så vet man att pendeln slår fram och tillbaka.
ALLT INOM KATEGORI: transformation ➔TILLBAKA TILL DIGITAL ENGINE REFLEKTERAR ➔