Av Sveinung Sande Dalatun, seniorkonsulent i Miles
Sjå for deg ei verksemd der arbeidet i alle team må koordinerast for å lansera eit nytt produkt. Sjå deretter for deg ei verksemd der berre eitt team treng å bli involvert. Kva for eit selskap ville du kjøpt aksjar i?
De fleste verksemder ligg nok ein plass imellom desse ytterpunkta. Men faktum er at me alle til ein viss grad har bygd organisasjonen og IT-arkitekturen vår på ein måte som gir konkurrentane våre meir glede enn oss sjølve.
Arbeid som går over team-grenser er som regel dyrare enn arbeid innenfor eit team, fordi ulike team har ulike prioriteringar og målsettingar. I tillegg får du ekstra kostnadar knytta til koordinering. Difor bør du organisera kvart team rundt det du jobber ofte med og som er forretningskritisk, så kan alt det andre heller gjerast gjennom prosjekt på tvers.
Uheldigvis er det lite hjelp i å omorganisera om ikkje IT-arkitekturen blir bygd med tanke på den flyten som organisasjonen treng. IT-arkitektar og organisasjonsutviklarar må difor jobba saman om korleis organisasjonen og arkitekturen til saman skal fungera. Tradisjonelt har arkitektar vore vand til å optimalisera arkitekturen for å redusera kostnadar, auka sikkerheita og sikra stabil drift, medan flyt og innovasjonsevne ofte blir oversett. Men innovasjonsevne og konkurransekraft er òg eigenskapar me må investera i etter behov. Gløymer me det, får me ikkje den nyskapinga og utviklinga bedrifta treng.
Sannsynligvis kan ikkje alle typar arbeidsoppgåver flyta like godt gjennom organisasjonen. Du må bestemma deg for kva typar endringar det er viktig skjer raskt og til ein rimeleg kostnad. Då er det nyttig å kategorisera endringane etter kor differensierande dei er for di verksemd. Det som skiljer deg frå konkurrenten bør du prøva å isolera innanfor enkelte team for å unngå blokkerande avhengnadar i produktutviklinga.
Plasser gjerne felles funksjonalitet i eigne team, men ikkje gjer det berre fordi det er felles. Gjer det berre viss det auker evna til dei som jobber med differensierande oppgåver til å gjera differensierande arbeid. Men følg med på oppgåvene som kjem inn til sånne fellestenester. Om ei fellesteneste må endrast ofte når ein lager nye eller endrar gamle produkt, kan det skuldast at arkitekturen ikkje traff heilt.
Om du innarbeider nokre sånne prinsipp som skildra ovanfor, som tydeliggjer kva slags avhengnadar mellom team og system som er ønskelege og kor sterke desse avhengnadane bør vera, auker sannsynet for å lukkast. Ei verksemd som ikkje har eit bevisst forhold til avhengnadane mellom team og IT-system vil fort hamna bakpå. Eg ville i alle fall ikkje kjøpt aksjer i eit sånt selskap.