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.

Skabelonbaseret: Unbox
Vi bruger skabeloner, når vi implementerer pakkeløsninger med en standardmetode. Unbox er konceptet inden for ERP.

Abakion Go
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 Gør-det-selv 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. I Scopefasen får vi styr på scope for projektet. Vi afholder en Gevinstafdækning, som kortlægger hvilke målsætninger og formål der har initieret projektet – og vi går på en Gembawalk gennem din virksomhed, hvilket afdækker scope for projektet på hvert forretningsområde og proces.
  2. Derefter følger Designfasen, hvor vi afholder en række workshops for at afklare scope på hvert område og aftaler de konkrete leverancer.
  3. I Implementeringsfasen udvikler vi i sprints, leverer selve systemet og sikrer at brugerne er parate til at anvende det.
  4. Til sidst kommer Go-live-fasen, hvor du tester systemet og tager det i anvendelse – og adfærdsændringerne står sin prøve i praksis.

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. Du kan nemt afmelde, når du vil.

Projektmodel i 3 spor

Hvorfor skal der være 3 spor i projektet? Det skyldes, at det er 3 aspekter, som er essentielle for at projektet bliver en succes.

Det er som regel System-sporet, som er årsagen til, at en virksomhed henvender sig til en IT-leverandør – for du går jo ikke til en IT-leverandør for at få sparring til en organisatorisk forandring eller en afdækning af uindfriet potentiale. Så ville du vælge et management-konsulentbureau.

Du går til en IT-leverandør, fordi du har behov for en IT-leverance. Men du skal være opmærksom på, at IT-leverancen kan give afledte behov for ændret adfærd, processer eller organisation for at give de ønskede gevinster.

Derfor er det virkelig effektivt at behandle gevinster, adfærd og systemer som 3 separate spor. Så risikerer du ikke, at projektet fortaber sig i teknik.

System-sporet

System-sporet er klassikeren. Det er her vi gennemgår og designer processerne og aftaler hvordan de skal systemunderstøttes. Vi opsætter, udvikler og implementerer – og bagefter tester du hver proces i løsningen og går i gang med at anvende løsningen.

Det er teknik og løsninger. Det er alt det, du er vant til, at et IT-projekt indeholder.

Gevinst-sporet

Men … det er naturligvis ikke teknikken, der er formålet i sig selv. Der er en grund til, at du ønsker at implementere et nyt IT-system. Du vil gerne opnå noget. Du vil gerne høste nogle gevinster.

Forventningerne til gevinsterne skal kortlægges allerede i scopefasen, og i resten af projektet skal realiseringen af gevinsterne have sit eget spor.

Gevinst-sporet er formålet med det hele.

Der er en årsag til, at gevinsterne skal have sit eget spor. Typisk begynder IT-projekter med masser af gode intentioner, og derefter fortaber projektet sig i teknik. I slutningen har alle glemt, hvad målsætningerne oprindeligt var – de vil bare gerne være færdige. Den situation undgår vi ved at isolere gevinstrealiseringen i sit eget spor.

Adfærds-sporet

Vi har også et tredje spor, som handler om adfærdsændringer. Det skyldes, at gevinsterne kun indfinder sig, hvis medarbejderne begynder at agere på en ny måde.

Det kan være, at der er arbejdsopgaver, de skal holde op med at udføre, eller udføre på en anden måde, eller at arbejdsopgaverne skal udføres af andre medarbejdere, eller at der kommer helt nye opgaver til.

Mange skal arbejde på en ny måde, og det er ikke nemt – især ikke når man i forvejen har travlt. Medarbejderne skal som regel deltage i IT-projektet samtidig med at de skal passe deres almindelige arbejde.

Nu siger vi det lige ud af posen:

Adfærdssporet vil fylde mindst lige så meget i din virksomhed, som Systemsporet vil fylde hos os som leverandør.

Og vi siger det så direkte, fordi Adfærdssporet som regel bliver undervurderet.

Det kan være svært at få øje på arbejdsbyrden fra begyndelsen, fordi mange aktiviteter og beslutninger i projektet handler om teknik og design af systemer, og de afledte adfærdsændringer springer ikke lige så meget i øjnene. De dukker op henad vejen, overrasker medarbejderne og presser dem i dagligdagen.

Ved at gøre Adfærd til et separat spor kan vi bringe adfærdsændringerne frem i lyset, så opgavens omfang kan overskues, planlægges på forhånd og tilrettelægges, så det skaber mindre pres på medarbejderne.

Scopefasen

Nu har du overblik over, hvordan Abakions Projektmodel forløber i 3 spor.

Nu kan vi gå i dybden med de enkelte aktiviteter, og vi begynder i Scopefasen, der består grundlæggende af 2 typer aktiviteter:

  1. Gevinstafdækning: Vi aftaler målsætningerne for projektet.
  2. Gemba walk: Vi aftaler hvilke forretningsprocesser, det skal omfatte (scope).

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

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.

Der skal være 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.

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

Bemanding

Allerede fra gevinstafdækningen bemandes vores projekter med bestemte roller, som har veldefinerede ansvar i projektet.

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.

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.

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

Gevinstafdækningen 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 der er 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, nå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.

Hvilket hierarki har din organisation? Hvilken kultur har den? Hvordan taler medarbejderne til hinanden? Hvor forandringsparate er medarbejderne?

”Hvad har det med sagen at gøre?” tænker du måske. Men det er vigtigt for at vurdere, om organisationen kan 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. 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.

Vurdering af udfordringernes omfang

Alle disse forhold strukturerer vi i overskuelig form, og det er grundlaget for aktiviteterne i Adfærds-sporet. Det handler nemlig om, hvordan vi får medarbejderne til at ændre adfærd.

Og nogle adfærdsændringer er nemme – andre er svære. Vi vil gerne allerede i gevinstafdækningen have deltagerne til at vurdere størrelsen af udfordringerne.

Det er altid en meget svær øvelse på dette tidlige tidspunkt, men det er vigtigt.

Økonomichefen tror måske, at adfærdsændringerne i Økonomiafdelingen bliver svære, mens det på lageret bliver ret nemt. Omvendt kan Lagerchefen slet ikke overskue adfærdsændringerne på lageret, mens han ikke kan se, hvad økonomifolkene skal gøre anderledes.

Vi har en tendens til at undervurdere udfordringer – og overvurdere vores egen kapacitet. Det er ganske menneskeligt. Men det skaber problemer i et projekt, hvis vi ikke adresserer det fra begyndelsen.

Til vurdering af adfærdsændringernes omfang anvender vi T-shirt størrelser. Det er dejlig banalt, og alle kan forholde sig til det. Ekstra-small (XS) er en lille udfordring, og Ekstra-large (XL) er en ret stor udfordring.

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.

Gevinstkortet og Gevinstejeren

Resultatet af gevinstafdæknings-workshoppen er konkret et gevinstkort. Det er oversigten over, hvilke gevinster projektet sigter efter, og hvad succeskriterierne er.

Gevinstkortet indeholder også overskrifterne på de procesområder, som projektet omfatter, samt din vurdering af, hvor stor en udfordring adfærdsændringerne vil være på hvert område.

Gevinstkortet i Abakions Projektmodel

Gevinstkortet fortsætter i gevinstsporet, og i den forbindelse er der en vigtig opgave på gevinstafdæknings-workshoppen:

Du skal udnævne en Gevinst-ejer (eller flere).

Det er faktisk en svær øvelse at udnævne Gevinstejere. Det er som regel svært nok at gøre gevinsterne konkrete nok til at de er målbare – og deltagerne i gevinstafdæknings-workshoppen kan godt føle sig ret blottede. Hvis de så bliver bedt om at være Gevinstejer, så kan det være svært at overskue, hvad man går ind til.

Vi vil naturligvis hjælpe så meget vi kan, men vi må være ærlige at sige, at succesen afhænger af, hvor bevidst din virksomhed reelt er om de ønskede gevinster, når I går ind i gevinstafdæknings-workshoppen.

Vi oplever ofte, at deltagerne tror, at vi kun skal snakke om tekniske løsninger. Men vi skal nok føre jer trygt igennem processen. Og du bør ikke igangsætte et projekt, der ikke har en Gevinstejer på alle vigtige områder.

Så er det sagt. Så vigtigt er det ganske enkelt.

Gemba Walk

Når vi nu kommer til næste aktivitet i projektet, som er gemba walk, så er det hovedarkitekten og projektlederen fra Abakion, som deltager.

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 værdikæ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.

En gemba walk afdækker hvilke processer, der skal indgå i projektet.

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

Procesmodellen er en bruttoliste 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.

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 skal føjes 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 overraskelser, uoverensstemmelser og forglemmelser, som ofte præger projekter.

Hvis man selv skal opremse sine behov, så er det nogle gange de mest åbenlyse ting, man glemmer at nævne. Måske får du ikke lige nævnt lagerpluk, 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.

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.

Opdatering af Gevinstkortet

Resultatet af en gemba walk er som sagt overblik over processerne, men den giver os også mulighed for at vurdere, om Gevinstkortet stadig er retvisende.

Der er måske områder, som nu virker som større eller mindre udfordringer end først antaget. Derfor afslutter vi Scopefasen med at opdatere Gevinstkortet – og tage ændringerne op med dine Gevinstejere.

Adfærdsaktiviteter

Vi har vi afsluttet Scopefasen og kommer til begyndelsen af Designfasen.

Vi har sammen skabt et retvisende overblik over de gevinster vi sigter efter, de tekniske leverancer og de områder, hvor det er nødvendigt med adfærdsændringer.

Nu kan vi gå i gang med den tekniske leverance, og i dette stadie er det vigtigt at holde fast i Adfærdssporet. Det er nemt at lade sig opsluge af teknikken, så vi skal sikre, at Systemsporet og Adfærdssporet hænger sammen.

Og vi vil gerne begynde Designfasen med at tale om Adfærdssporet.
Det er nemlig den første barriere, vi typisk støder på.

Lad os begynde med Adfærd

Lad os forestille os, at du skal indføre et lagersystem i produktionen. Lagerfolkene elsker projektet, fordi de får styr på alle beholdninger og lokationer – men produktionsfolkene er lidt tilbageholdende, fordi de skal til at registrere mange flere ting og ændre deres arbejdsgange.

Vi når ikke særlig langt hen i den første procesworkshop i Systemsporet, før vi bliver holdt tilbage af adfærdsbarrierer, og derfor skal vi tidligt i processen afholde en workshop om adfærdsforandringerne.

Forandringsworkshop

Vi har allerede i Scopefasen opdaget, at produktionsfolkene har en adfærdsændring, der er i størrelse XL, og den udfordring skal vi i gang med at løse i begyndelsen af Designfasen.

Det er procesejeren i din virksomhed, der har den praktiske og udførende rolle, men vi vil som leverandør støtte procesejerne i forløbet og hjælpe med at tilrettelægge deres aktiviteter – i det omfang de ønsker vores bidrag om forandringsledelse.

Vi sørger som minimum for at synliggøre udfordringerne via en Forandringsworkshop. Men du kan selv bestemme, hvor aktiv en rolle vi skal have i at tilrettelægge og støtte aktiviteterne i Adfærdssporet.

Vi støtter procesejerne i at tilrettelægge aktiviteter, der gør det attraktivt for medarbejderne at ændre adfærd.

Normalt ville du efter driftstart opdage, at dit nye lagersystem ikke er retvisende. Du konfronterer din IT-leverandør, som forklarer, at det skyldes produktionsfolkenes tilbageholdenhed. “Det har været et problem igennem hele processen, og det er også årsagen til, at projektet er blevet dyrere end budgetteret,” forklarer IT-leverandøren som regel. “Hvorfor har I ikke fortalt mig det undervejs,” tænker du. Og det er præcis årsagen til, at du skal have en Forandringsworkshop og et Adfærdsspor i din projektplan.

Vi skal synliggøre udfordringer med adfærdsændringer undervejs, så du kan gøre noget ved dem, så vi kan holde tidsplan og budget – og opnå de planlagte gevinster.

Forandringsaktiviteter

Du behøver ikke have planlagt en masse aktiviteter til adfærdsændringer fra begyndelsen. Alene synliggørelse af adfærdsudfordringer undervejs bringer dig et godt stykke tættere på målet. Det giver som regel sig selv, hvilken kommunikation og involvering, der er nødvendig undervejs. Men det forudsætter, at udfordringerne er synlige.

I praksis handler Forandringsaktiviteterne om at du skal imødegå de udfordringer med adfærdsændringer, som vi sammen har forudset i Scopefasen.

Det er egentlig ret lavpraktisk. Det handler om at lægge en kommunikationsplan, komme ud og tale med de berørte, involvere dem, finde konkrete barrierer osv.

Procesejerne skaber adfærdsændringer via aktiviteter med fokus på involvering, kommunikation og uddannelse.

Vores rolle og dit ansvar

Som leverandør kan vi hjælpe dig med at afklare og tilrettelægge Forandringsaktiviteterne, men vi kan ikke tage ansvaret for dem. Det er en vigtig pointe.

Vi kan godt tage hele ansvaret for Systemsporet, fordi vi selv skal udføre det, men adfærdsændringerne skal implementeres af medarbejderne i din virksomhed, hvis det skal virke optimalt. Dine medarbejdere skal tage ændringerne til sig og ændre sin adfærd, og det forudsætter forståelse for jeres organisation, processer og kultur – og det er svært at hyre eksterne personer til at udføre.

Derfor er det afgjort mest effektivt, hvis du og din virksomhed selv tager ansvaret for Forandringsaktiviteterne.

Det gælder for de fleste medarbejdere, at de lytter til Direktøren, når det handler om de strategiske linjer, og til den nærmeste chef, når det handler om, hvad der rammer i hverdagen.

Du kan ikke få en ekstern change management konsulent til at have den samme indflydelse og skabe adfærdsændringer.

Med den erkendelse støder du måske på en udfordring: Det er ikke sikkert, at den enkelte leder har erfaringer med et ERP-projekt og ved hvordan opgaven skal gribes an.

Derfor vil vi meget gerne hjælpe med at tilrettelægge de aktiviteter, der skal udføres for at skabe adfærdsændringer. Vi kan hjælpe rigtig meget og skabe værdi for din virksomhed, men det kommer kun til at flyve, hvis procesejerne i din virksomhed føler ansvar for opgaven.

Hvad er med i tilbuddet fra leverandøren?

Hvad kan du forvente fra din IT-leverandør? Kan de overhovedet finde ud af at rådgive dig om forandringsaktiviteter? Det bør du nok undersøge på forhånd, og hvis din leverandør udelukkende er teknik-leverandør, så bør du få hjælp til adfærdsændringerne fra en anden part.

Hold det i tankerne, når du skal sammenligne tilbud fra forskellige leverandører, for der er stor forskel på, hvad IT-leverandører inkluderer i deres tilbud. Er tilbuddet fra din IT-leverandør et 100% teknik-baseret tilbud? Eller rummer tilbuddet alle de elementer, der er nødvendige for at skabe et succesfuldt projekt?

Det er meget almindeligt, at et IT-tilbud indholder uddannelse og support, der hører til i Adfærdssporet. Men det er ikke nok til at skabe adfærdsændringer.

Vi mener, at der er 3 vigtige aspekter, der skal dækkes af:

  • Kommunikationsplan
  • Involvering af medabejderne
  • Uddannelse af brugere

Et typisk IT-projekt indeholder kun det sidste punkt: uddannelse. Og det er ikke nok. Så får du blot veltrænede modvillige medarbejdere.

Kommunikationsplan

Kommunikationsplanen er et punkt, hvor du som kunde hos en IT-leverandør som regel er overladt helt til dig selv.

Men kommunikation er svært, og de fleste har behov for hjælp til at finde ud af, hvor der er størst behov for kommunikation, lægge en plan, og støtte eksekveringen af kommunikationen.

Det er ikke nok at fortælle om det nye system på et firmamøde en enkelt gang. Det er en vedvarende indsats på mange fronter.

”Jamen, vi har da fortalt jer om systemet,” siger du midt i medarbejdernes shitstorm. Men de kan ikke huske dit indlæg på firmamødet for 2 måneder siden.

Der er et paradigme inden for kommunikation, som du skal forstå:
Som afsender af budskaber bærer du hele ansvaret for forståelsen.

Det er dit problem, ikke deres, hvis medarbejderne ikke føler sig velinformerede eller ikke forstår formålet med projektet. Det er altid afsenderens ansvar – uanset hvor uretfærdigt det måtte føles.

Involvering

Det samme gælder involvering af medarbejderne. Føler alle relevante medarbejdere, at de er blevet taget med på råd i processen og har haft passende indflydelse?

Hvis du gennemfører procesworkshops med repræsentanter fra relevante dele af organisationen, så er du allerede godt i gang med at involvere folk.

Bemærk, at dette som regel skaber en prisforskel på workshops. Hvis du vælger en procesworkshop, så er der afsat rigtig meget tid til involvering, men hvis du vælger en valideringsworkshop, så er der kun afsat en lille smule tid. Det skaber naturligvis en prisforskel, men der er også stor forskel på effekten på Adfærdssporet.

Hvis du så sammenligner de to muligheder med et tredje tilbud på en workshop, som kun handler om teknik, så vil det tredje tilbud virke meget billigt, men til gengæld står du helt alene med adfærdsudfordringerne.

Og involveringen skal naturligvis ikke kun foregå i workshops, men fortsætte igennem hele projektet, og det gør den ikke af sig selv, hvis du ikke gør en aktiv indsats for det. Det skal planlægges og tilrettelægges.

Den afsluttende trumf i Adfærdssporet er test. Du bør naturligvis teste, at systemet fungerer som det skal, men i de fleste projekter bliver test nedprioriteret, fordi det tager lang tid, alle er ved at være trætte, og de fleste synes reelt at test er en kedelig opgave.

Det er en helt forkert indstilling.

Test er en fremragende mulighed for at involvere medarbejdere. De får ansvaret for at godkende løsningen. Al viden om løsningen bliver konsolideret hos medarbejderne, så de føler sig stærke og godt klædt på til driftsstarten. Det er ikke længere den eksterne konsulent, der ved mest om det nye system.

Involvering i test giver virkelig mange fordele.

Workshops

Lad os springe til Systemsporet og se nærmere på de aktiviteter, som er traditionelle i et IT-projekt, fordi de handler om at bygge og implementere selve IT-løsningen.

Fra Scopefasen har vi et veldefineret scope for projektet, og vi afholder nu workshops for at kortlægge den funktionalitet, som projektet skal indeholde.

Agendaen for workshops ligger helt klar, for vi følger naturligvis strukturen i procesmodellen. Det sikrer, at vi ikke behøver at begynde 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:

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

Valideringsworkshop

En valideringsworkshop 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.

Vi matcher dine arbejdsprocesser til løsningens standardfunktionalitet og best practice.

En valideringsworkshop 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 kan tilpasse dine arbejdsprocesser for at undgå at ændre 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 valideringsworkshop, 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 en valideringsworkshop som regel er relevant, har vi præfabrikeret dokumentation for processerne, og det fungerer som skabeloner, så vi kan dokumentere valideringsworkshoppen, uden at det bliver en omfattende opgave.

En valideringsworkshop 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.

En procesworkshop er fleksibel og længerevarende, mens en valideringsworkshop er hurtig og standardiseret.

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.

Eksempel på procestegning i Abakions projektmodel

Vi kortlægger og designer dine arbejdsprocesser på tavlen og aftaler hvordan løsningen skal understøtte dem.

I en valideringsworkshop 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 ændres.

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.

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 valideringsworkshoppen 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 vores kunde 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 valideringsworkshops og procesworkshops i et projekt. Det er faktisk det mest almindelige.

Det kan fx være, at processer inden for finans er nemmest at håndtere med valideringsworkshops, 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.
  • Valideringsworkshoppen 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-aktiviteterne 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-aktiviteterne meget struktureret an.

Heatmap for Procesmodellen

Når vi afholder workshops, så giver det os mulighed for løbende at vurdere omfanget af udfordringen i adfærdsændring på de enkelte områder.
Med den viden kombinerer vi Gevinstkortet og Procesmodellen til et heatmap, hvor vi kan overskue alle processer og se deres t-shirt-størrelser. Så kan alle overskue, hvor store adfærdsændringer der ligger forude på hvert område.

Heatmappet er en meget dynamisk oversigt, som bliver bygget, efterhånden som vi kommer gennem workshops, og opdateres løbende i projektet.

Der vil være områder, som i løbet af projektet viser sig ikke at være en udfordring. Der vil også dukke nye udfordringer op. Og der vil være nogle processer, hvor vi justerer t-shirt-størrelsen op, fordi vi sammen erkender udfordringens omfang i løbet af en workshop.

Det giver os et altid aktuelt heatmap over de adfærdsmæssige udfordringer, og det giver mulighed for at prioritere den konkrete indsats bedst muligt.

Implementering

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

Vi er tilhængere af en agil tilgang til 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.

Opsætning, udvikling eller standardkomponent. Implementering efter opgavebeskrivelser for hver proces.

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

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 med en backlog efter fuld agil tilgang, som er tilpasset vores metode.

Vi opdeler udvikling og implementering i et antal sprint, som ligger i forlængelse af hinanden. Hvis du er under tidspres, så kan testen eventuelt overlappe det næste sprint, men vi har klart bedst erfaringer med at afholde sprints i forlængelse af hinanden.

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.

Opdeling i sprint i projektmodellen

Den demonstration, du fik i workshops, 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 workshoppen, og når du kan godkende, så er sprintet slut og den del af procesmodellen er færdig.

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.

Test af løsningen op mod user story for hver proces i procesmodellen. Intern konsolidering af viden.

Find de rette personer

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.

Aftestning af user stories

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.

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.

Konsolidering af viden

Der er en gevinst ved testarbejdet, som de fleste desværre overser. Test handler ikke kun om at kontrollere, at du får leveret det, du har betalt for.

Når dine medarbejdere bruger tid og energi på at sætte sig detaljeret ind i den nye løsning, så sker der en række vidunderlige ting.

De får en større forståelse for løsningen. De forstår i højere grad formålet med meningen med løsningen. De kan nemmere balancere fordele og ulemper i stedet for blot at give systemet skylden for alle ulyksaligheder. Mange af dem bliver til ambassadører.

Tænk lige på Adfærdssporet i denne projektmodel. Du får ikke bedre involvering af medarbejderne umiddelbart op til driftstart, end når de skal teste.

Samtidig får du også konsolideret al viden om løsningen internt i organisationen. Du kan tage kontrol over løsningen og frigøre dig fra de eksterne konsulenter.

Efter testarbejdet ved medarbejderne lige så meget om løsningen som de eksterne konsulenter, og så behøver du ikke betale for ekstern hjælp til alle mulige småting.

Involvering og kontrol.

Det er to stærke fordele, som alt for ofte bliver overset.

Idriftsætning

Inden du kan slippe brugerne løs i den nye løsning, så skal de naturligvis have den rette introduktion til, hvordan de skal betjene løsningen.

Her er det vigtigt at pointere, at vi underviser ud fra Procesmodellen.

Den optimale metode er, at de enkelte processer er visualiseret i procesdiagrammer, hvor processerne er brudt ned i instruktioner, som svarer til de forskellige procestrin i processerne.

Instruktionerne er letforståelige ark, der viser hvordan man betjener løsningen trin-for-trin. Dermed får vi koblet procesdiagrammerne, som nogle brugere synes er lidt for akademiske, sammen med instruktions-arkene, som er lige til at gå til for enhver, der sidder foran tastaturet.

At have fingrene i systemet er den bedste metode til at huske ny viden.

For at sikre at deltagerne får fuldt udbytte af uddannelsen, sørger vi for at de får meget hands-on erfaring.

Målet er, at de bliver fortrolige med systemet, så de kan betjene det effektivt og struktureret.

Først forklarer vi et emne på tavlen. Derefter bliver deltagerne stillet en konkret opgave, som de skal løse i systemet. Og så får de udleveret instruktions-sedler, som forklarer fremgangsmåde – og på den måde bliver det nemt for deltagerne at huske efter endt uddannelse, hvordan de skal betjene systemet, fordi de kan støtte sig til instruktionerne.

Vi lægger stor vægt på denne undervisningsmetode, da erfaring har vist os, at det at have fingrene i systemet er den bedste metode til at huske ny viden. Deltagerne bliver selvhjulpne og slipper for at gennemgå tykke manualer med alt for mange detaljer, som ikke er vigtige for deres arbejde.

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.

Gevinstopfølgning

Nu skal vi ikke glemme, hvad formålet med alt dette arbejde egentlig er.

Svævende over alle aktiviteterne i projektet ligger din Gevinstejer, som hele tiden holder øje med, om de planlagte gevinster stadig er realistiske at opnå.

Evaluering af projektets målsætninger og gevinstrealiseringer.

Gevinstejeren har Gevinstkortet at støtte sig til. Der står de konkrete målsætninger.

Hver gang, der træffes en beslutning i projektet, som har indflydelse på Gevinstkortet, så skal disse beslutninger vendes med Gevinstejeren. Det kan føre til, at Gevinstkortet bliver opdateret, men ofte vil det også føre til, at der træffes en anden beslutning.

Bemærk lige, hvad dette betyder i praksis.

  • Hvis du ikke har et Gevinstspor i projektet, så vil der ske følgende: Der er behov for en teknisk afklaring af, om du vil have mulighed A eller B på et bestemt område. A koster lidt mere end B, men B er lidt besværligere at betjene. Det er jo et nemt valg. Du tager B.
  • Men hvis du har et Gevinstspor i projektet, så sker der derimod følgende: Valget mellem A og B tages op med Gevinstejeren. Mulighed B betyder, at en af målsætningerne om tidsbesparelse kun kan realiseres 50%. Derfor vælger du A.

Det lyder banalt, men du vil blive overrasket over hvor mange beslutninger, der træffes i projekter, som desværre modarbejder projektets overordnede målsætninger.

Projektdeltagerne har simpelthen ikke øje på gevinsterne, når de er overdænget med praktikaliteter – og det er helt naturligt – og det er derfor, du har behov for Gevinstejeren.

Gevinstejeren følger naturligvis løbende op på, om alt går den rette vej – så vi sammen kan korrigere afvigelser fra målsætningerne.

Det sikrer, at du opnår de ønskede gevinster.

Nu har du læst om Abakions Projektmodel.

Hvis du gerne vil vide mere, så er du meget velkommen til at ringe til os og få en snak.
Vi håber, at vi tales ved.

70 23 23 16