Der findes et bestemt møde, de fleste arkitekter har siddet i. Forretningen forklarer, hvad den gerne vil kunne til næste år. IT forklarer, hvilke systemer der findes, og hvad de koster. Begge parter taler præcist, begge parter taler sandt, og ingen af dem taler om det samme. Efter halvanden time bliver der aftalt et opfølgende møde.
Det, der mangler i det lokale, er et ord begge sider kan bruge uden at give køb på præcision. Det ord er forretningskapabilitet.
Definitionen, og den ene ting der gør den brugbar
En forretningskapabilitet er noget, organisationen skal kunne. Håndtér kundeordrer. Onboard en ny medarbejder. Afregn en skade. Godkend en kreditansøgning.
Læg mærke til, hvad formuleringen ikke indeholder. Den nævner ikke en afdeling. Den nævner ikke et system. Den beskriver ikke, i hvilken rækkefølge arbejdet foregår. Den siger kun hvad, aldrig hvordan.
The Open Group formulerer det i TOGAF-standarden som "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome". Det er en tør definition, men den rummer det væsentlige: en kapabilitet er en evne, ikke en aktivitet og ikke et aktiv.
De tre ting en kapabilitet ikke er
Størstedelen af de kapabilitetskort, der ikke holder, fejler på en af tre måder.
Den er ikke en proces. En proces beskriver hvordan. "Ordremodtagelse, trin et til syv" er en proces. Den bliver skrevet om, hver gang nogen optimerer noget, og det gør nogen heldigvis tit. Kapabiliteten "Håndtér kundeordrer" er den samme før og efter. Tommelfingerreglen: står der et verbum, der antyder en arbejdsgang, er der sneget sig en proces ind på kortet.
Den er ikke en applikation. "Ordrestyring i D365" er ikke en kapabilitet. Det er et middel til at realisere en. Forskellen betyder noget den dag, D365 skal skiftes ud, for kapabiliteten skal stadig kunne udføres bagefter. Et kort, hvor systemnavne er sneget ind som overskrifter, skal tegnes om, hver gang der udskiftes noget, og så er halvdelen af pointen væk.
Den er ikke en afdeling. Det er den mest almindelige fejl, fordi den er så nem at lave. Organisationsdiagrammet ligger lige der, det er allerede godkendt, og det ser sorteret ud. Men et kapabilitetskort, der følger organisationen, skal tegnes om, hver gang nogen flytter en afdeling. Til gengæld kan det ikke længere afsløre, at tre enheder gør præcis det samme under tre forskellige navne, og netop det var en af grundene til at lave kortet.
Stabiliteten er hele pointen
Alt andet i et virksomhedslandskab bevæger sig. Processer optimeres løbende. Applikationer skiftes hvert femte til tiende år. Afdelinger flyttes, når der kommer en ny direktør. Leverandører kommer og går.
Kapabiliteterne står stille. Ikke for evigt, men længe nok til, at man kan bygge oven på dem. TOGAF beskriver egenskaben direkte: kapabilitetskortet "provides a self-contained view of the business that is independent of the current organizational structure, business processes, information systems and applications".
Det er derfor, kapabiliteten er den rigtige knage at hænge resten på. Applikationer kobles til de kapabiliteter, de realiserer. Omkostninger følger applikationerne. Strategiske mål kræver bestemte kapabiliteter. Beslutninger vedrører bestemte kapabiliteter. Når det stabile lag ligger i midten, overlever koblingerne, selv når enderne udskiftes.
Uden det lag findes der kun direkte forbindelser mellem ting, der bevæger sig hver for sig. Det er derfor overblik i praksis fordamper i løbet af halvandet år, uanset hvor godt det var, da det blev lavet.
Sådan er kortet bygget op
Et kapabilitetskort er et hierarki, i praksis på tre niveauer.
Niveau et er de områder, forretningen er bygget af. Her skal der være så få, at folk kan huske dem, i praksis omkring syv til ti. Kan ingen gengive øverste niveau uden at slå op, er kortet holdt op med at være et fælles sprog og blevet til et dokument.
Niveau to og tre gør kapabiliteterne konkrete nok til, at hver applikation kan placeres et præcist sted. Det er dét, der gør kortet i stand til at svare på noget.
Niveau fire findes ikke. Eller rettere: går man et niveau dybere, er man som regel holdt op med at beskrive, hvad organisationen skal kunne, og begyndt at beskrive, hvordan den gør det. Det er en procesbeskrivelse i forklædning, og den hører til et andet sted i modellen.
Der er en test, der afgør, om strukturen holder: kan en kapabilitet på niveau to placeres uden diskussion? Skal der forhandles om, hvor den hører hjemme, overlapper kortet med sig selv, og så kan det ikke bruges til at finde overlap i porteføljen bagefter.
Man behøver i øvrigt ikke opfinde strukturen selv. APQC's Process Classification Framework er frit tilgængeligt, dækker tretten kategorier på øverste niveau og har i version 8.0 en kategori, der hedder præcis Develop and Manage Business Capabilities. Det er et udgangspunkt, ikke en tvangstrøje, og det sparer de tre workshops, der ellers går med at blive enige om overskrifterne.
Ordet på dansk
Der er en tilbagevendende diskussion om, hvad begrebet skal hedde på dansk. Nogle skriver capability uoversat, fordi det er sådan, man siger det i praksis. Andre forsøger sig med evne eller kompetence, som begge betyder noget andet i almindelig dansk.
Spørgsmålet er allerede afgjort et sted, der tæller. Digitaliseringsstyrelsens vejledning om arkitekturmetode, som er en del af den fællesoffentlige digitale arkitektur, bruger ordet forretningskapabilitet direkte. Skal man skrive om det på dansk, er det den term, der findes i den officielle danske arkitekturlitteratur, og så er der ingen grund til at opfinde en anden.
Hvad kortet kan svare på, når det er koblet
Et kapabilitetskort, der bare hænger på en væg, er et pænt billede. Værdien opstår i koblingen til applikationerne, og den opstår hurtigere, end folk regner med. Allerede første gang applikationslisten møder kortet, sker der to ting af sig selv: nogle felter er tomme, og nogle felter er overfyldte. Begge dele er fund.
Fra det punkt kan der besvares spørgsmål, som ellers krævede en rundspørge:
Hvilke systemer bærer det, vi ikke må miste? Slå den kritiske kapabilitet op, og se hvad der hænger på den.
Hvor overlapper vores værktøjer? Kig efter kapabiliteter med tre applikationer på. Det er sjældent tilfældigt.
Hvad rammes, hvis en leverandør falder bort? Følg kæden fra applikation til kapabilitet til det mål, kapabiliteten skulle levere.
Hvad koster den strategi, vi har lovet bestyrelsen? Rul omkostningen op gennem kapabiliteterne til målene. Det er det spørgsmål, et rent porteføljeværktøj ikke kan besvare, fordi det ikke har et strategilag.
Hvornår ved man, at man har fået det rigtigt
Der er et enkelt tegn, og det har intet med kortets udseende at gøre.
Man har fået det rigtigt, den dag nogen træffer en beslutning på det. Ikke refererer til det i et slide, ikke roser det i en styregruppe. Beslutter noget. Vælger at samle to systemer, fordi de sidder på den samme kapabilitet. Udskyder en investering, fordi modenhedsgabet ligger et andet sted. Svarer en revisor uden at bestille en analyse først.
Indtil da er kortet en hypotese om, hvordan forretningen hænger sammen. Det er ikke ingenting, men det er heller ikke det, arbejdet blev sat i gang for.
Spekir bygger det lag, der forbinder strategi med IT-porteføljen. Se Atlas