Abakions Projektmodel

I et IT-projekt skal projektmodellen sikre, at du når i mål på tid og budget – men også at du opnår dine forretningsmæssige målsætninger med projektet.

Rådgivning om dit næste ERP-projekt

Michael Møller-Jensen, Chief Customer Officer, Abakion A/S

"I Abakion har vi 3 forskellige tilgange til IT-projekter, du kan vælge mellem.
Vælg den, der passer bedst til din situation og dine behov."

Projekter - 3 tilgange

Abakions Projektmodel
styrer dit projekt gennem workshops, implementering og intern forandring - og sikrer at du når dine forretningsmæssige mål.

Onboarding: Unbox
Vi kalder det Onboarding, når vi implementerer pakkeløsninger med en standardmetode. Unbox er konceptet inden for ERP.

Self Service
er gør-det-selv metoden. Så tegner du bare et abonnement og går i gang. Klik her og se priser på abonnementer.

Vores holdninger til rådgivning
Vi har en klar holdning til, hvordan vi rådgiver dig i et projekt, og du skal forvente, at vi giver dig modspil i hele processen.

Hør mere om Projektmodellen
Stil os et spørgsmål her
eller ring til os på 70 23 23 16

3 projektmodeller for Microsoft-projekter Unbox af Dynamics 365 Business Central Unbox af Dynamics 365 Business Central Self Service Dynamics 365 Business Central

Abakions Projektmodel i overblik

Når vi sammen skal gennemføre et IT-projekt i din virksomhed, så sikrer Abakions Projektmodel, at vi kommer succesfuldt i mål med projektet.

Vi følger en standardiseret skabelon, så vi har styr på alt, får dokumenteret alt, og ikke behøver at opfinde den dybe tallerken i hvert projekt.

I overskrifter har vores projektmodel følgende faser:

  1. Gevinstafdækning: Vi aftaler målsætningerne for projektet.
  2. Gemba walk: Vi aftaler hvilke forretningsprocesser, projektet skal omfatte (scope).
  3. Workshops: Vi gennemgår/designer processerne og aftaler systemunderstøttelse.
  4. Implementering: Vi opsætter, udvikler og implementerer.
  5. Test: Løsningen skal testes op mod user stories for hver proces.
  6. Go live: Din virksomhed går i gang med at anvende løsningen.
  7. Gevinstopfølgning: Vi evaluerer projektets målsætninger.

Modtag beskrivelsen af Projektmodellen som et PDF-dokument »

Send dokumentet til:

  • Ved udfyldelse accepterer du at modtage et link til en PDF-fil med beskrivelsen af Projektmodellen og email-nyhedsbrevet fra Abakion, og du accepterer vores generelle betingelser for behandling af dine data.

Vi er ikke tilhængere af projekter, der kun begynder med en teknologivinkel. Der er ikke nogen virksomheder, der vil opgradere eller implementere ny IT udelukkende for teknologiens skyld. Der er et forretningsmæssigt mål med at indføre ny teknologi, og vi synes, at det er bedst, at alle parter har dette mål for øje i hele projektet.

Derfor begynder vores projektmodel med en gevinstafdæknings-workshop.

Gevinstafdækning er en forventningsafstemning af, hvilke gevinster ledelsen ønsker at opnå med IT-projektet.

1. Gevinstafdækning

Det første skridt i projektmodellen er en gevinstafdækning, som er en workshop, der skal afstemme de forretningsmæssige målsætninger med projektet.

Din virksomheds ledelse (eller beslutningsansvarlige) samt din projektejer deltager, og formålet er at afdække hvilke gevinster virksomheden ønsker at realisere med projektet.

Målsætninger for både forretning og teknik

Det handler om at skrælle ind til det egentlige formål med it-projektet. Der er stor forskel på de forretningsmæssige mål og de it-tekniske mål i et projekt – og som IT-leverandør vil vi gerne være med til at tage ansvar for at nå begge typer af mål.

Når en virksomhed henvender sig til en IT-leverandør og siger: “Vi vil gerne have opgraderet vores IT-system,” så er det nemt for it-leverandøren at falde i fælden og betragte det som en simpel teknologi-opgave, der bare skal udføres.

Efter projektet bliver virksomheden skuffet over resultatet. Ja, IT-løsningen blev opgraderet, men det viste sig desværre, at den ikke skabte de forretningsmæssige forbedringer, som virksomheden havde håbet på.

Pointen er, at der er altid en masse forudgående overvejelser, som er vigtige at få til overfladen i et teknologi-projekt. Alle implicitte forventninger og mål skal på bordet fra begyndelsen.

Udfordringen hos virksomheden var måske, at deres tidsregistrering ikke var god nok, og at de regnede med at de nye funktioner til tidsregistrering i den nye version ville hjælpe.

Opgaven til it-leverandøren var måske at opgradere, men det forretningsmæssige mål var at øge faktureringsgraden via bedre tidsregistrering. Vi får kun opfyldt begge dele, hvis alle parter har fokus på det fra begyndelsen.

Det handler ikke kun om IT

Nogle gange erkender virksomheden i denne fase, at det ikke kun handler om IT. Det handler måske om forretningsprocesser eller uddannelsesbehov.

Måske kræver tidsregistreringsløsningen ikke nogen opgradering. Måske er problemet, at medarbejderne får registreret for sent, fordi virksomheden har en uhensigtsmæssig proces for at oprette opgavenumre. Denne slags erkendelser kan ændre it-projekter helt. Derfor er gevinstafdækning så vigtig at begynde med.

Det leder os til den anden del af gevinstafdækningen: dine interne forhold. Vi skal nemlig ikke udelukkende se på projektets formål – men også hvilke interne forudsætninger, som er nødvendige for at din organisation kan gennemføre projektet med succes.

Din organisation og kultur

Der kommer mange bløde ting ud af en gevinstafdækning. Når du har afklaret de forretningsmæssige mål, så hjælper vi dig med at afdække forudsætningerne for, at det er muligt at realisere – helt uafhængigt af teknik.

Kan dine medarbejdere det nødvendige? Kræver det kompetenceløft? Kræver det reorganisering? Kræver det intern forventningsafstemning? Kræver det afstemning af mål og holdninger?

Alt dette skal du tage hånd om, før du går i gang med et teknologiprojekt.

Vi oplever ofte på en gevinstafdækning, at vores kunder bliver mere bevidste om, hvor stor en opgave de har, som slet ikke handler om teknik. Mange bliver overraskede.

Vores mål er at øge din virksomheds bevidsthed om sig selv. Ellers kommer projektet kun til at handle om teknik, og så er det rent held, hvis det bliver en succes.

Hvilken type virksomhed har du? Hvilket hierarki har din organisation? Hvilken kultur har den? Hvordan taler medarbejderne til hinanden?

“Hvad har det med sagen at gøre?” tænker du måske. Men det er vigtigt for at vurdere, om organisationen kan overskue og rumme de forandringer, den står over for.

Det er svært for en virksomhed at have et nøgternt blik på interne, politiske spil, kultur og uformelle organiseringer. Det er svært at se skoven for bare træer, og det er helt almindeligt og forståeligt. Det bliver først synligt, når en ekstern part kommer og peger det ud.

Vi synes, at det er en del af at være en god IT-leverandør, at vi forstår din virksomhed, ikke kun i processer men også i kultur.

Ledelsesengagement

En gevinstafdæknings-workshop sikrer, at du får taget ledelsen i ed. Ledelsesengagement er vigtigt i ethvert IT-projekt, og hvis alle er enige om målsætningerne og omfanget fra begyndelsen, så er der mere albuerum og forståelse fra ledelsen gennem hele projektet.

Dette albuerum og forståelse breder sig også til resten af din organisation.

Der er måske nogle IT-folk, som tænker: “Kan vi ikke bare begynde med at opgradere vores gamle ERP?”. Økonomifolkene synes det ville være smartere at se på noget Power BI i stedet for et ERP-projekt, og andre står måske ved kaffemaskinen og brokker sig over, at der bliver brugt så meget energi på ERP, når de synes, at en Field Service-løsning ville gøre en meget større forskel.

Alle har behov for at vide, hvilket formål et IT-projekt tjener.

Når det er kortlagt og dokumenteret i en gevinstafdækning, så forstår hele din organisation bedre, hvorfor projekterne er prioriteret som de er. Færre bliver utålmodige eller føler sig nedprioriteret.

Når alle har afstemt forventningerne, så er det nemt at forklare, hvorfor ét projekt ligger før et andet. Den slags fælles referenceramme er et vigtigt resultat af gevinstafdækningen.
Allerede fra gevinstafdækningen bemandes vores projekter med bestemte roller, som har veldefinerede ansvar i projektet.

Abakions hold

Fra Abakions side er der 3 hovedroller i projektet, og de har følgende ansvar:

  • Projektejeren er ledelsesrepræsentanten fra Abakion, der har det overordnede ansvar.
  • Hovedarkitekten står for det samlede løsningsdesign og har ansvaret for, at de forretningsmæssige og it-tekniske målsætninger fra gevinstafdækningen bliver opfyldt i projektet.
  • Projektlederen styrer fremdriften i projektet og har ansvaret for, at projektet overholder både tidsplan og ressourceforbrug.

Vi sammensætter naturligvis holdet med færre eller flere personer, afhængigt af det konkrete projekt, men de ovenstående roller skal altid besættes.

Abakions bemanding i projektmodellen

På samme vis bør du også have en projektejer i ledelsen og en projektleder, som forholder sig til tidsplan og ressourcer i det daglige arbejde.

Når vi nu kommer til 2. fase i projektet, som er gemba walk, så er det hovedarkitekten og projektlederen fra Abakion, som deltager:

Projektmodellen

1. Gevinstafdækning
Vi aftaler målsætningerne for projektet.

2. Gemba walk
Vi aftaler hvilke forretningsprocesser, projektet skal omfatte.

3. Workshops
Vi gennemgår/designer processerne og aftaler systemunderstøttelse.

4. Implementering
Vi opsætter, udvikler og implementerer.

5. Test
Løsningen skal testes op mod user stories for hver proces.

6. Go live og Gevinstopfølgning
Du tager løsningen i anvendelse, og vi evaluerer projektets målsætninger.


Se billede af Projektmodellen

Gemba Walk i Afklaringsfasen i Abakions projektmodel

2. Gemba walk

Gemba walk er et Lean-udtryk, og det betyder ganske enkelt, at man observerer arbejdet, dér hvor det bliver udført.

Det foregår i praksis ved, at Abakions hovedarkitekt og projektleder sammen med dig går gennem alle afdelingerne i din virksomhed.

I følger forsyningskæden, og hos hver afdeling observerer I, hvordan der arbejdes med IT-systemerne, og snakker med medarbejderne om, hvilke forretningsprocesser der er vigtige for dem.

Det er vigtigt for et IT-projekts succes, at vi kender din virksomhed bedst muligt fra begyndelsen. De personlige besøg i din virksomheds afdelinger giver så stor en forståelse for hvem din virksomhed er, og hvordan den fungerer, at det gør en stor forskel i projektet. Det kan ikke undervurderes, at vores konsulenter forstår din virksomhed.

Som optakt til gemba walk introducerer vi dig for en procesmodel, som spiller en afgørende rolle i vores projektmodel.

Procesmodellen i Abakions projektmodel

Procesmodellen

Procesmodellen er en bruttoliste i Excel over alle de forretningsområder og forretningsprocesser, som vi forestiller os kan være med i projektet.

Du kan betragte procesmodellen som en bruttoliste over processer, som din virksomhed måske indeholder, og i denne fase skal vi afklare, hvilke processer der skal inkluderes i projektet.

Procesmodellen skaber strukturen for alle de efterfølgende faser i vores projektmodel, og den bringer os hurtigere i mål, fordi vi har en masse materiale præfabrikeret til de processer, som er med i modellen.

Det er fundamentet for vores projektarbejde, og procesmodellen fungerer som den røde tråd gennem workshops, implementering, test og undervisning. Det er procesmodellen, som sikrer, at vi når succesfuldt i mål uden at have overset noget.

På besøg i din virksomhed

Med procesmodellen i baglommen tager vores konsulenter nu på gemba walk i din virksomhed. Vi går i praksis rundt i virksomheden og snakker med procesejerne i din virksomhed om hvert område. Du skal være vores vært og sørge for at træffe aftaler med alle relevante områdeeksperter, som vi bør tale med.

Vi opdager altid noget nyt på gemba walk, som giver os ekstra information. Alle de små undtagelser kommer nemmere til overfladen på en gemba walk, end hvis vi sætter os i et mødelokale og prøver at opremse fra hukommelsen, hvad der er vigtigt at understøtte med IT-systemet.

Når vi fx står ude på lageret og peger på en 6-pak, der er anbrudt, så er det meget nemmere at tale konkret om it-behov.

Så ja, vi skal ud og møde medarbejderne, hvor de udfører deres arbejde. Hvis en kunde foreslår at droppe gemba walk, så fortæller vi gerne om et projekt, hvor vi leverede en lager-løsning til en kunde uden at besøge deres lagerhal. Den morgen, hvor løsningen gik i drift, og der ankom 25 lastbiler fra morgenstunden – der gik det op for alle, at vi ikke havde talt om kapacitet. Løsningen virkede upåklageligt, men den var ikke beredt på at registrere modtagelse af så mange varer, så hurtigt. Den udfordring ville en gemba walk have fanget.

Man kan beskrive og genfortælle så meget man vil – men at se tingene med egne øjne er noget helt andet.

Ambassadører og kritikere

I løbet af en gemba walk vil vi gerne møde de personer, som er oplagte ambassadører og kritikere. Vi tager som regel emnet op allerede i gevinstafdækningen, fordi det er vigtigt.

Kig ud i din organisation. Hvem er meningsdannerne? Hvem er naturligt ambassadører, og hvem vil være kritisk indstillet over for projektet?

Vi skal have kritikerne til bordet fra begyndelsen af projektet, så vi kan finde ud af, hvad deres modstand skyldes. De fleste medarbejdere vil gerne virksomheden det bedste, så deres bekymring har som regel en konkret årsag, som vi kan inkludere i projektet og behandle, så vi kan skabe ambassadører ud af kritikerne. Det er effektiv forandringsledelse.

Vi skal benytte lejligheden i gemba walk til at møde både kritikere og ambassadører, der hvor de udfører deres arbejde, så vi kan forstå dem bedst muligt.

Vi udfylder procesmodellen

Som sagt er procesmodellen vores bruttoliste over processer, og i løbet af gemba walk afdækker vi, hvilke processer fra bruttolisten, der skal indgå i projektet – og om der måske mangler enkelte processer, som vi skal tilføje til listen.

Resultatet af gemba walk er en udfyldt udgave af procesmodellen.

Du får den udfyldte procesmodel til evaluering, og når du kan godkende, at vi har opfattet din virksomhed på den rette måde, så har vi et afstemt scope for projektet, som vi kan anvende som grundlag for resten af projektet.

Når vi anvender procesmodellen til at afstemme forventningerne, så undgår vi en masse overraskelser, uoverensstemmelser og forglemmelser, som præger traditionelle projekter.

Hvis man selv skal opremse sine behov, så er det nogle gange de mest åbenlyse ting, man glemmer at nævne. Det kan være, at du ikke lige får nævnt lagerpluk i opremsningen, fordi det er indlysende vigtigt, og så bliver vi senere usikre på, om det er med i projektet.

En gemba walk, der munder ud i en udfyldt procesmodel, vil altid fange den slags oversete ting. Du vil kigge på listen og opdage, at lagerpluk er fravalgt, og straks indse at vi mangler at tale om det.

Gemba walk udfylder procesmodellen i Abakions projektmodel

Det er vigtigt at have overblik over, hvad der er fravalgt i et projekt.

Når du pludselig ser, at udløbsdatostyring er fravalgt, så får det dig straks til at overveje, om du egentlig har nogen varer, hvor du skal styre udløbsdatoer.

Modellen er hele tiden agil. Vi må gerne erkende ting og blive klogere undervejs. Vi kan altid aftale rettelser i procesmodellen, men vi bliver aldrig uenige om, hvad det aktuelle scope er.

Typer af workshops i Abakions projektmodel

3. Workshops

Nu har vi et veldefineret scope for projektet, og vi er kommet til trin 3, hvor vi afholder workshops for at kortlægge den funktionalitet, som projektet skal indeholde.

Agendaen for workshop ligger helt klar, for vi følger naturligvis strukturen i procesmodellen. Det sikrer, at vi ikke behøver at starte en workshop med en tom notesblok, og at vi ikke støder på uforudsete områder, som konsulenten på workshoppen ikke har kompetencer inden for. Alt er afstemt på forhånd, og vi kommer bedre forberedt.

Vi kan tilbyde 2 typer af workshops, som har hvert sit formål:

  • Direkte demo er en best practice, skabelonbaseret og hurtig metode.
  • Procesworkshop er en fleksibel workshop hvor vi designer processer sammen.

Direkte demo

Den direkte demo er en best practice-tilgang for dig, der har en ambition om at ende så tæt på standardløsningen som muligt – og er villig til at bøje dine egne processer for at undgå ændringer i løsningen.

En direkte demo foregår således, at vi ankommer med vores skabeloner og demonstrerer, hvordan forretningsprocesser i procesmodellen bliver understøttet af IT-løsningen. Vi viser dig, hvordan standardløsningen fungerer.

Det giver dig mulighed for at evaluere, hvordan din virksomhed kan passe ind i løsningen. Vores forretningskonsulent vil rådgive dig om, hvordan du måske kan tilpasse dine arbejdsprocesser for at undgå at rette i løsningen, eller hvilken type opsætning eller ændring i løsningen, der kan bringe dig i mål.

Vi oplever ofte, at virksomheder ikke er klar til at træffe alle de valg i detaljer, som et IT-projekt kræver. Det virker uoverskueligt for de fleste. Mange spørger om, hvad andre lignende virksomheder gør. Og det er pointen med best practice.

Vi mener, at du bør fokusere på at få styr på hvad I vil med projektet, og hvordan I forbereder jer internt til forandring. Så skal vi nok bidrage med best practice, der hjælper med at træffe de rette valg i detaljerne i projektet.

Som dokumentation efter en direkte demo-workshop, så kan du se hvilke processer, du har fået gennemgået, og hvilke valg du har truffet undervejs.

På en del områder, hvor direkte demo som regel er relevant, har vi præfabrikeret dokumentation for processerne, og det fungerer som skabeloner, så vi kan dokumentere den direkte demo, uden at det bliver en omfattende opgave.

En direkte demo er et standardiseret produkt. Du får rigtig meget foræret ved at anvende skabeloner, men du får mindre mulighed for at opfinde dit eget. Hvis du forventer at skulle specialdesigne en masse processer, så er den anden type workshop mere passende.

Procesworkshop

Den anden workshop-type er en procesworkshop, som er den fleksible tilgang for dig, der har behov for at specialdesigne funktionalitet til at understøtte unikke forretningsprocesser.

I praksis tager vi et procesområde ad gangen. For hvert område i procesmodellen tegner vi processen på tavlen sammen, og hver proces demonstrerer vi efterfølgende i løsningen, så vi kan aftale, om der skal ændres på arbejdsgange, ændres i løsningen, eller om alt er godt som det er.

I den direkte demo kommer vi med præfabrikerede procestegninger, som vi demonstrerer i løsningen. I en procesworkshop tegner vi simpelthen procestegningerne på tavlen i fællesskab. Det giver os mulighed for at skræddersy alt til din virksomhed.

Bagefter demonstrerer vi i løsningen, hvordan de skræddersyede procestegninger kan understøttes, og så kan du evaluere, om løsningen eventuelt skal tilpasses.

Som dokumentation efter en procesworkshop, får du oversigtstegninger med de specialdesignede processer, inkl. deres sammenhæng til procesmodellen, og naturligvis en specifikation af, hvilke valg du har truffet om opsætning, tilretninger og udvikling.

Eksempel på procestegning i Abakions projektmodel

Intet starter fra bunden af

Selv en procesworkshop starter ikke med en blank notesblok. Tiden er løbet fra, at vi skal opfinde alt fra bunden af.

Vi har naturligvis best practice-processerne fra den direkte demo i baghånden. Hvis det på nogle områder viser sig, at dine processer er tæt på best practice, så genbruger vi naturligvis så meget som muligt, så vi kommer hurtigere i mål.

Fra skræddersyning til forandringsparathed

Førhen var der mindre funktionalitet i IT-systemerne. Vi kan kalde det gamle dage, men det er ikke en menneskealder siden. Mange virksomheder behøvede omfattende udvikling i systemet for at kunne understøtte sine processer. Det endte i specialudviklede monstre af IT-løsninger. I dag er løsningerne så modne, at tiden er kommet til at forlade monsteret, men det er faktisk vanskeligt.

“Kan vi ikke bare sammenligne monsteret med den nye løsning og overflytte differencen?” spørger kunden måske – men det er som regel en dårlig idé. Ingen har behov for alle de funktioner, der er udviklet over et årti.

Der skal ryddes ud eller startes forfra, og der har best practice sin berettigelse. Der vil være nogle områder, hvor du nemt kan klare dig med en standardløsning og best practice, og der vil være andre områder, hvor du er nødt til at designe løsningens processer.

Du skal tænke på, at dine brugere gennem årtier er opdraget til, at de bare kan bede om tilretninger, og så har de fået lov til at få dem. Det paradigme har ændret sig, og i dag handler det mere om forandringsparathed end om skræddersyning. Du skal være klar over, at det er en omstillingsproces for alle brugere, der deltager i et IT-projekt.

Den rejse er vi vant til at guide dig igennem. Vi ved, at mange af dine projektdeltagere føler, at de står over for noget uoverskueligt, og vi ved hvordan vi får dem til at være trygge på rejsen.

Workshop-hybrid

Derfor er det også en vigtig pointe, at du sagtens kan vælge at kombinere direkte demo og procesworkshops. Det er faktisk det mest almindelige.

Det kan fx være, at processer inden for finans er nemmest at håndtere med direkte demo, mens du måske har flere specielle behov på lageret, og så arrangerer vi procesworkshops for lagerstyringen. De to workshoptyper kan kombineres som du har lyst.

  • Procesworkshoppen er især relevant, når du har meget unikke processer, eller hvis projektet er en stor forandring for organisationen, eller du har behov for at ensrette processer på tværs af organisationen, hvor du ikke på forhånd har overblik over alle konsekvenser af forandringen.
  • Den direkte demo er især relevant, når du føler, at du nemt kan passe ind i en standardløsning, eller hvis forandringen eller indvirkningen på organisationen er lille, fx fordi der er tale om en versionsopgradering.

Vi skal visualisere din løsning

Formålet med workshop-fasen er at visualisere den løsning, som vi skal realisere i implementeringsfasen bagefter.

Hvis du hyrer en arkitekt til at tegne et nyt hus til dig, så vil han måske skabe en 3d-model, som du kan bevæge dig rundt i, så du kan mærke, om huset er perfekt til dig. Vi kan desværre ikke 3d-modellere et IT-system på samme måde, men vi vil gerne anskueliggøre bedst muligt, hvordan din kommende IT-løsning vil understøtte dine forretningsprocesser, så du kan se dig selv i løsningen, allerede i designfasen. Det gør vi med arkitekturtegninger og procesoversigter.

Traditionelt i IT-branchen bliver der skåret alt for mange nemme hjørner i designfasen. Vi synes, at der generelt bliver freestylet for meget, når løsningen designes. Det har den ærgerlige konsekvens, at man bliver afhængig af, at konsulenten kan overskue alt i hovedet. Det er bare ikke realistisk. Den type projekter ønsker vi ikke at være en del af, og det er årsagen til, at vi griber workshop-fasen meget struktureret an.

Procesmodellen er den røde tråd i Abakions projektmodel

4. Implementering

Nu kommer vi til den fase, hvor vi tilpasser og implementerer løsningen.

Vi er ganske agile og fleksible i implementeringsfasen. Vi sammensætter fasen ud fra resultatet af workshoppen, så der er naturligvis stor forskel fra projekt til projekt. Der er ikke to implementeringsprojekter, der ligner hinanden, men vi anvender de samme metoder og komponenter i alle projekter.

Vi er hjulpet af, at procesmodellen strukturerer vores arbejde, både i denne og efterfølgende faser. Allerede på dette tidspunkt har vi workshop-dokumentation, der også giver os user stories, som også kan bruges som test cases, og ud fra dette er det enkelt at danne opgavebeskrivelser til vores konsulenter, som skal udvikle og opsætte løsningen.

Opgavebeskrivelserne er detaljerede arbejdsopgaver, som vores medarbejdere internt i Abakion kan udføre. Det kan være 3 ting:

  • Der skal opsættes noget.
  • Der skal udvikles noget
  • Eller der skal implementeres en standardkomponent
Procesmodellen og dokumenterne i Abakions projektmodel

Alle opgaver kan direkte relateres til en forretningsproces i procesmodellen, og alle kan finde præcis de steder i dokumentationen, hvor pågældende forretningsproces er behandlet i gemba walk og i workshoppen, og se hvilke beslutninger der er truffet undervejs.
Der er rød tråd hele vejen igennem.

Vi har en værktøjskasse fyldt med skabeloner som fx arkitekturtegninger, systemlandskaber og integrationsmodeller, som vi kan trække på efter behov – og vi styrer fasen efter scrum-inspirerede sprint, som er tilpasset vores metode.

Vi opdeler udvikling og implementering i et antal sprint, som ligger i forlængelse af hinanden, men hvor du kan udføre test samtidig med at vi igangsætter næste sprint.

Hvert sprint begynder med et opstartsmøde, hvor vi gennemgår de processer i procesmodellen, som det aktuelle sprint omhandler. Vi bygger en del af løsningen, og i slutningen af sprintet demonstrerer vi resultatet for dig, så du kan evaluere.

Implementering i sprint i Abakions projektmodel

Den demonstration, du fik i workshop-fasen, var på standardløsningen, hvor vi anskueliggjorde hvordan den færdige løsning kunne blive. Den demo, du får her i sprintet, er den reelle færdige løsning.

Du evaluerer, om den viste løsning lever op til det, vi aftalte i workshop-fasen, og når du kan godkende, så er sprintet slut og den del af procesmodellen er færdig.

5. Test

Når implementeringsopgaverne er fuldført, så kan testarbejdet påbegyndes. Der er desværre alt for mange, der nedprioriterer test. Det kan skyldes stress før idriftsætning, eller at det kan være meget omfattende at udarbejde test cases.

Som regel er årsagen dog, at det er drønkedeligt at teste.

Lad os være helt ærlige: Der er ikke særlig mange mennesker i verden, der synes, at det er sjovt at teste. Der findes nogle få, som kan motivere sig selv til test-arbejde – men de fleste andre prøver at springe over, hvor gærdet er lavest, når det kommer til test.

Vi skal sørge for at finde de personer i din organisation, som kan teste. Det nytter desværre ikke noget at give opgaven til den procesansvarlige, hvis vedkommende ikke brænder for opgaven, for det betyder i sidste ende, at testen ikke bliver udført godt nok.

Det er ikke af ond vilje. Overspringshandlinger og dårlige undskyldninger trumfer altid gode intentioner og direkte ordrer. Den erkendelse skal du have fra begyndelsen – og vi vil meget gerne hjælpe dig med at finde de rette persontyper.

Sagen er nemlig, at uanset årsagen, så er det ikke en god idé at nedprioritere test.

Vi anvender user stories til at sikre, at aftestning får den rette opmærksomhed i denne fase af projektet.

Vi lægger op til, at der for hvert område i procesmodellen bliver skrevet en user story, og den skal indeholde de konkrete oplysninger om, hvad du skal kunne i pågældende forretningsproces, og den kan også indeholde en procestegning.

En user story er skrevet som prosa, men den er også testbar. Den fungerer kravspecificerende i implementeringsfasen, og den er grundlaget for test af det færdige resultat.

Eksempel på en User Story i Abakions projektmodel

Det er et stykke arbejde, som vi måske udfører sammen i løbet af procesworkshoppen, og i så fald er opgaven med at skrive test cases mindre til sidst. Det afhænger naturligvis af, hvordan vi har aftalt at fordele opgaverne.

Test kan også variere meget i omfang. Vil du kun teste den aftalte funktionalitet, eller vil du også teste varianter, fejlbetjening osv.?

Uanset hvad – hvis vi har fulgt metoden med gemba walk, procesmodel og workshops, så er test en mere overskuelig opgave.

Test kan både bygges ind i sprintet, men ofte udføres test også som en parallel eller afsluttende aktivitet. Vi hjælper dig med at planlægge, facilitere og følge op på testen, men selve udførelsen af testen varetages bedst af dine interne kolleger. Vi aftaler med dig i det konkrete tilfælde, hvad der fungerer bedst.

Test og idriftsætning i Abakions projektmodel

Dermed er vi også klar til, at du kan gå i gang med at anvende din nye løsning. I den forbindelse yder vi naturligvis support til dine brugere, både på stedet og via telefon og email. Så er du godt i gang.

6. Gevinstopfølgning

Til sidst udfører vi en opfølgning på gevinstafdækningen. Vi evaluerer sammen, om projektet opnåede de målsætninger, som vi opstillede i den indledende gevinstafdækning.