Virksomhedens etablering, drift og videreudvikling er baseret på forretningsanalyse, der tager udgangspunkt i forretningsmodellen. Forretningsanalyse er også første skridt på vejen til etablering af virksomhedens enterprisearkitektur og de løsningsarkitekturer, den er sammensat af.
En hver forandring i virksomheden er uundgåeligt en forandring af en eller flere processer. Eventuelle forandringer i IT-arkitekturen er oftest blot et biprodukt af procesforandringerne. Det betyder også at udviklingsprojektets primære leverance altid må være en opdatering af virksomheden s processer (proceskatalog) og ændringer i IT-arkitekturen:
Systemerne er bygget af kode, der er opbygget ud fra en nøje gennemtænkt arkitektur – og den er udtænkt med udgangspunkt i de krav, løsningen skal opfylde. Hvis man køber færdige systemer, er der sjældent noget, der skal kodes (men måske noget, der skal konfigureres).
Afdæk mulighederne
Mulighederne for at forbedre og videreudvikle virksomheden gemmer sig i de processer, der følges i gennemførelsen af de aktiviteter forretningsmodellen kræver. Det kan være alt fra at et indkøbt system, der bruges i en aktivitet, kan erstattes af et andet, der kan det samme men til en lavere pris. Men oftest gemmer potentialet sig i at effektivisere hele processen ved at udtænke en bedre kombination af aktiviteter og understøttende systemer, der løser samme opgave, men med mindre ressourceforbrug og øget præcision.
Der er forskellige metoder til af afdække muligheder, men fælles for dem alle er, at de kun er effektive, hvis de involverede parter tager udgangspunkt i et fælles billede af udgangspunktet – altså hvilke processer, der arbejdes efter, og hvordan aktiviteterne gennemføres i dag – og med hvilken systemunderstøttelse.
En udmærket metode metode er SWOT-analysen [Wikipedia]. SWOT står for Strengths (styrker), Weaknesses (svagheder), Opportunities (muligheder) og Threats (trusler).
Metoden går al sin enkelthed ud på at kigge på et område, og undersøge og diskutere hvilke styrker, svagheder, muligheder og trusler, der kan påvises. Området kan være en specifik aktivitet, men oftere kigges der på hele processer eller hele fagområder eller lignende. Resultatet af analysen udgør et grundlag for at udtænke løsninger, der udnytter styrker og muligheder, samt styrer udenom svagheder og trusler.
Selv hvis man som forretningsanalytiker får til opgave at specificere krav til en meget konkret bestilling af en løsning, kan det være en god ide at snige en SWOT-analyse ind i arbejdet. Det kan afdække muligheder, der kan tages højde for i udformningen af den bestilte løsning, og dermed give endnu større værdi, uden nødvendigvis at gøre projektet dyrere.
Før der kan specificeres krav til en udviklingsopgave, er det nødvendigt at identificere hvilke eksisterende processer, der vil blive berørt af løsningen, når den implementeres i virksomheden. Nogle processer bliver måske helt overflødige, mens andre bliver ændret – helst til det bedre. De skal gerne blive mere effektive og præcise (færre fejl, der koster tid, penge, og måske endda slider på kunderelationerne). Helt nye processer kan også blive nødvendige.
For hver af de berørte processer er det relevant at afdække:
- Hvilken hændelse, der igangsætter processen.
Igangsættelsen af en proces kan ofte optimeres med hjælp af nye teknologiske muligheder både hos den initierende part og den udførende part. Fx kan en ny kanal vise sig at passe begge parter bedre, måske endda med en system-til-system integration af parternes respektive IT-systemer. - Hvilken information, der håndteres i processen.
Den løsning, der skal kravspecificeres, vil sandsynligvis påvirke hvilke informationer, der skal bruges fremover. Nogle vil måske ikke behøves længere, mens andre nye vil være nødvendige i den nye løsning. Det er også vigtigt at sikre at den håndterede information er nøje afstemt med virksomhedens informationsmodel. Hvis informationen ikke passer med modellen, risikerer man at designet at den nye løsning rammer skævt i forhold til den bagvedliggende forretningsmodel, virksomheden er baseret på. - Hvilke systemer, der benyttes i processen.
Systemer, der benyttes i processer, der berøres af den nye løsning, vil højst sandsynligt fortsat indgå i den nye løsning, måske i forbindelse med nye integrationer. Det kan også tænkes at de kan udfases, fordi den nye løsning løfter opgaven selv.
Følgende arbejdsprodukter påbegyndes så tidligt som muligt:
- Projektplan
Projektplanen sætter rammen for opgaven, og dermed for hvor vidt og bredt forretningsanalytikeren graver i sin analyse. Projektplanen redegør også for økonomien i udviklingen af løsningen. - Arkitekturdokument
Arkitekturdokumentet præsenterer et overblik over løsningen (hvem, der bruger den i hvilke processer). Den information forretningsanalytikeren kortlægger i sin analyse, præsenteres som en informationsmodel. Også de væsentligste processer præsenteres som de vil se ud når løsningen er implementeret. Trads dokumentets navn skal en forretningsanalytiker kunne påbegynde arkitekturdokumentet, og fx præsentere informationsmodellen i det dertil hørende kapitel i dokumentet. - Procesbeskrivelser
Procesbeskrivelserne beskriver aktiviteterne i processerne, og angiver hvor i aktiviteterne den anvendes IT-understøttelse. - Kravspecifikation
Kravspecifikationen kan indeholde kommercielle krav (hvem ejer systemet, hvis det bestilles udviklet af en leverandør), og forretningsregler, krav om teknologier og generelle krav. - Use case specifikationer
Use case specifikationerne specificerer nøjagtige og detaljerede krav til et systems funktionalitet, som skal opfyldes for at levere den nødvendige understøttelse til en aktivitet i en proces.
Læg mærke til at der udelukkende fremstilles arbejdsprodukter, der indgår i udviklingsprocessen, selvom det måske endnu ikke er besluttet at igangsætte et egentligt projekt. Det er helt legitimt at arbejde efter udviklingsprocessen mens det stadig analyseres om der er potentiale for at starte et egentligt projekt. Det standardiserer jo analysearbejdet, og øger genkendeligheden og dermed forståelsen af analysens konklusioner.
Udtænk løsningen
I takt med at mulighederne afdækkes i analysen, er det helt naturligt at begynde at udtænke en løsning – også inden det er besluttet at igangsætte et egentligt projekt. Den beslutning baseres jo på om det i projektplanen kan sandsynliggøres at det vil være en god investering, og det kræver oftest at man skitserer den IT-understøttelse, der må forventes at være nødvendig for at afslutte et projekt med at implementere nye og bedre processer i virksomheden.
Forretningsanalytikeren kan godt gøre sig nogle indledende tanker om en mulig IT-understøttelse, men det er en løsningsarkitekt, der skal forme den endelige tekniske løsning. Parallelt med at løsningsarkitekten arbejder videre med arkitekturen og dokumentation af denne, fortsætter forretningsanalytikeren med at udarbejde og forfine procesbeskrivelser og use case specifikationer.
Byg løsningen
Mens løsningsarkitekten og udviklerne bygger løsningen, kan forretningsanalytikeren hjælpe testerne med at forstå kravene, når de skal skrive testspecifikationer.
Implementer løsningen
Ibrugtagningen af den udviklede løsning er ikke gjort med at tænde for IT-systemet. Virksomhedens medarbejder skal jo også arbejde efter de nye og ændrede processer, der er en del af løsningen, og det kræver oftest et uddannelsesforløb parallelt med at løsningen testes og gøres leveranceklar. Forretningsanalytikeren kan hjælpe med at tilrettelægge og gennemføre undervisningen.
Efter idriftsættelsen af løsningen vil der typisk være behov for tæt opfølgning af både systemet og processernes effektivitet. Der arrangeres oftest et beredskab med deltagelse af forretningsanalytikere, arkitekten, og brugere, der måske har deltaget i testen og gennemgået uddannelsen.
Hvis der opdages fejl eller mangler i løsningen, skal forretningsanalytikeren ofte opdatere kravene, inden udviklerne kan rette fejlen. Hvis rettelserne påvirker de nye processer, skal procesbeskrivelserne også opdateres.