9 IMPLEMENTERING Dette kapitel beskriver faser og problemstillinger i forbindelse med en implementering af en handelsportal i den danske byggebranche, som er en del af projektgruppens løsningskoncept. Der foretages en barriereanalyse og en analyse af hvilke elementer der indgår i en forandringsproces, og på baggrund af disse opstilles en implementeringsplan. Dette kapitel tager udgangspunkt i tre hovedområder: Barriereanalyse. Skabelse af forandringer. Implementeringsplan. I barriereanalysen bliver barriererne ved en implementering af handelsportalen diskuteret, og i skabelse af forandringer bliver det med udgangspunkt i Kotters -trins model belyst hvilke områder der kræver særlig opmærksomhed i forbindelse med en implementering, hvorefter en egentlig implementeringsplan vil blive opstillet. 9.1 Barriereanalyse med Leavitts systemmodel I dette afsnit beskrives de barrierer der kan opstå i forbindelse med en implementering af handelsportalen. I forbindelse med dette vil der blive redegjort for projektgruppens holdning til relevante fokusområder. Ved implementering af handelsportalen vil der være barrierer og udfordringer der skal tages hensyn til. For at klarlægge disse barrierer benyttes Leavitts åbne systemmodel, som kan anvendes til at beskrive de konsekvenser og barrierer en forandring af et system kan have. Leavittmodellen, som er skitseret på figur 5, deler en organisation op i fire delelementer; struktur, opgave, teknologi og aktører ud fra et helhedssynspunkt, hvor sammenhængen mellem de enkelte delsystemer beskrives. Der tages udgangspunkt i, at der i enhver organisation er en synergieffekt mellem de enkelte delsystemer, så en forandring ét sted ofte har en indvirkning et andet sted. Det er derfor nødvendigt at betragte hele organisationen, frem for et eller flere delsystemer, da der ellers ville være en risiko for at der sker en sub-optimering. Det er ikke blot delsystemerne i leavitt-modellen der er vigtige, men i lige stor udstrækning relationerne imellem de enkelte delsystemer, for yderligere beskrivelse af Leavitts åbne systemmodel se Bilag: Metode. Leavitts åbne systemmodel Side 9
figur 5. Leavitts åbne systemmodel. I det følgende vil delsystemerne blive beskrevet med udgangspunkt i implementering af handelsportalen i den danske byggebranche. Opgaven ved brug af handelsportalen er en optimering af leverancekæden med hensyn til effektivitet, pris og kvalitet. Det er et vigtigt element i forhold til implementeringen af en handelsportal, at de enkelte parter fokuserer på leverancekæden og projektet som en helhed, hvorved en suboptimering skal undgås. Strukturen ved handelsportalen indeholder selve strukturen for hvordan handlen med varer skal ske over handelsportalen. Udgangspunktet for handelsportalen har været at sætte fokus på hvordan handlen mellem de enkelte parter har været, og hvordan dette kan forbedres via en handelsportal. Strukturen indeholder også integrationen mellem handelsportalen og de tilknyttede virksomheders økonomisystemer. Aktørerne i denne sammenhæng er de personer, der repræsenterer de enkelte virksomheder, der benytter handelsportalen. Teknologisystemet er i denne sammenhæng selve portalen, og de standarder, databaser mv. der er knyttet til handelsportalen. I det følgende redegøres for relationerne og sammenhængene mellem de enkelte delsystemer, og der redegøres i den forbindelse for eventuelle barrierer i forhold til en implementering af handelsportalen både i den danske byggebranche generelt, men også internt i de enkelte virksomheder. 9.1.1 Barrierer imellem delsystemerne i den danske byggebranche I dette afsnit beskrives de barrierer der eventuelt vil være ved en implementering af en handelsportal i den danske byggebranche. Opgave-strukturrelation Opgave Struktur Aktører Teknologi Ved opbygning af en handelsportal til brug for samhandel indenfor byggeriets brancher, er det forsøgt at sikre et mere gennemsigtigt marked, hvor bygherren har større indflydelse på valg af materialer, og på sigt billigere og bedre produkter. Ved implementering af en handelsportal er det vigtigt at der ikke fokuseres på de enkelte opgaver i et projekt og derved suboptimerer byggeriet. Side 90
For at sikre der ikke sker en suboptimering af materiale købet i leverancekæden, vil det være hensigtsmæssigt at opdele udbudet i to dele arbejdsløn og materiale køb, derved vil det være muligt for bygherren at overskue hvad der betales for. Todelt udbud En barriere er, at det måske ikke vil være muligt at udbyde materialer og arbejdsløn separat, og derved at gennemsigtigheden på markedet ikke forbedres Det er vigtigt, at der internt i virksomhederne bliver udarbejdet nogle procedurer for anvendelse af handelsportalen og for brugen af handelsportalen. Risikoen i denne forbindelse ligger i at de enkelte personer ikke vil bruge handelsportalen, og derved at handelen vil foregå som den plejer. Der ligger yderligere en udfordring i, at få integreret portalens dokumentstyring, så den kan fungere med de tilknyttede virksomheders økonomisystemer effektivt, så en optimering på dokumenthåndteringen kan give en tids- og økonomiskgevinst. Integrering af økonomisystem Opgave-teknologirelation Opgave Struktur Aktører Teknologi Integrationen af en handelsportal i den danske byggebranche er teknisk mulig. Der er eksempler fra andre brancher hvor lignende portaler succesfuldt er blevet implementeret. Det skal sikres at den teknologi der benyttes til opbyggelse af handelsportalen kan bruges til dette formål. Internt i de enkelte virksomheder er det nødvendigt at der er en politik for hvordan produktkatalogerne opdateres og holdes ved lige i overensstemmelse med handelsportalens forskrifter. Opdatering Det er vigtigt i en integrering af IT-værktøjer, at der fokuseres på, at værktøjet skal understøtte opgaven, og ikke opgaven der skal understøtte IT-anvendelsen. Projektgruppen har indtryk af, at der generelt ofte når der arbejdes med IT-integrering i forskellige erhverv fokuseres på hvordan IT kan benyttes, og ikke i hvordan IT kan afhjælpe givne problemstillinger. Det er derfor en udfordring når der arbejdes med en IT-integrering ikke at fokusere på IT-værktøjer som løsninger, men som hjælpe- og støtteværktøjer i forbindelse med en løsning. IT ikke løsning i sig selv Opgave-aktørrelation Struktur Opgave Teknologi Aktører Handelsportalen ligger op til en ny handelsform, og derfor en alternativ adfærd i forbindelse med en byggeproces, og da byggebranchen er et traditionelt og stolt erhverv, er der derved en stor udfordring i at få indført en ny handelsmetode. Dette kræver store holdningsændringer i branchen, både ved brug af e-handel samt den nye måde at udbyde materialer og arbejdsløn på. Det er vigtigt at det er muligt for de enkelte parter at se hvilke muligheder der i forbindelse med en handelsportal, f.eks. er produktkatalogerne Side 91
placeret centralt, således handelsportalen bliver en integreret del af virksomhedernes dagligdag. Motivation Motivationen er her et nøgleord, kan de enkelte parter ikke se fordelene ved benyttelse af et sådant koncept, vil det aldrig blive succesfuldt integreret. Motivationen skal bl.a. opfyldes ved at portalen skal være billigere end andre alternativer. Udfordringen består heri at sikre en benyttelse af handelsportalen i de enkelte virksomheder Struktur-teknologirelation Det er vigtigt at det sammenspil, der er mellem Struktur teknologien og handlesportalen fungerer gnidningsfrit både med hensyn til opdatering af Opgave Teknologi data samt handelsfunktionerne. Aktører Det skal sikres at selve IT-anvendelsen ikke bliver det styrende element i forhold til optimering af leverancekæden. Udfordringen i denne relation består i at det er nødvendigt for den teknologi der anvendes ikke hindre en gnidningsfri handel over handelsportalen, og at teknologien understøtter de nødvendige funktioner. Vilje til omstilling Struktur-aktørrelation Opgave Struktur Teknologi For at kunne sikre en effektiv samhandel over handelsportalen, vil det være nødvendigt med en stor vilje til omstilling hos de enkelte aktører, idet der er tale om en ny form for samhandel. Aktører Der ligger en udfordring i at få nedbrudt de barrierer, der ligger i forhold til en holdningsændring fra at de enkelte parter isoleret set fokuserer på vinding på virksomhedsniveau til at fokusere på vinding på projektet som helhed, som gerne skulle resultere en større gevinst for alle involverede. Det er vigtigt, at parterne er åbne og modtagelige for et samarbejde, som skal bygge på tillid og respekt. Aktør-teknologirelation Ved implementering af ny teknologi vil det ofte give Struktur anledning til barrierer både i forhold til de enkelte virksomheder og til at indse gevinsterne ved at Opgave Teknologi anvende den nye teknologi. Aktører Det ligger en stor udfordring for de enkelte virksomheder i at få nedbrudt de barrierer, der ligger i forhold til en større anvendelse af informationsteknologi. Det er vigtigt for virksomheden at de enkelte medarbejdere bliver uddannet i anvendelsen af de nye IT-systemer. Der kan opstå barrierer i forhold til aktørernes kompetence i brugen af ITredskaber, men det er projektgruppens indtryk, at denne barriere er forsvindende, da der i det private er en stigende IT-anvendelse, og de Side 92
forskellige medarbejdere derfor med tiden får den fornødne erfaring i enkel anvendelse af IT generelt, og derfor hurtigt kan sætte sig ind i at benytte nye enkle IT-systemer. Dette forudsætter derfor en brugervenlig logisk opbygning af brugerfladen. 9.2 Skabelse af forandringer Ved implementering af en handelsportal i den danske byggebranche skal der ske en forandring af selve byggeprocessen, både i hele byggebranchen, men også internt i de enkelte virksomheder. Til implementeringen tages der udgangspunkt i Kotters -trinsmodel, der bl.a. kan bruges som inspiration til at skabe større forandringer, jf. figur 59 [Forandringer]. Etablering af en oplevelse af nødvendighed Kotters -trinsmodel Oprettelse af den styrende koalition Udvikling af en vision og en strategi Formidling af forandringsvisionen Styrkelse af medarbejdernes kompetence Generering af kortsigtede gevinster Konsolidering af resultater og produktion af mere forandring Forankring af nye arbejdsmåder i kulturen figur 59. Kotters -trinsmodel til at skabe større forandringer. Med udgangspunkt i figur 59 gennemgås de faser til at skabe større forandringer. 9.2.1 Etablering af en oplevelse af nødvendighed For at sikre et solidt udgangspunkt i implementeringen af en handelsportal i leverancekæden, er det nødvendigt for de enkelte parter at de indser et behov for en ændring af de nuværende forretningsgange. Der er udkommet en ny udbudslov hvor samarbejdet mellem de enkelte parter i byggeriet ønskes forbedret, så der er etableret en oplevelse af nødvendighed hos myndighederne [udbud]. Denne holdning skal overføres til de enkelte parter i byggeriet, for at få etableret en af oplevelse af nødvendighed til brug af en handelsportal til forbedring af leverancekæden. Ny udbudslov Side 93
Der kan være flere grunde til at virksomheder ikke føler, at det er nødvendig at foretage de nødvendige forandringer, se figur 60. Kilder til selvtilfredshed For megen ubekymret snak fra overordnede leder Fravær af en større og synlig krise For mange synlige ressourcer Menneskets evne til at fornægte, især i pressede eller stressede situationer Selvtilfredshed Lave præstationsnormer En kultur, der er preget af dræbbudbringeren-af-dårlige-nyheder, mangel på åbenhed og undgåelse af konfrontationer Organisationsstrukturer, der får de ansatte til at fokusere på snævre, funktionelle mål En mangel på tilstrækkeligt præstationsfeedback fra eksterne kilder Interne vurderingssystemer, som fokuserer på forkerte præstationskriterier figur 60. Kilder til selvtilfredshed [forandringer]. Fokusere på hele værdikæden Det er nødvendigt for de enkelte parter ikke at blive for selvtilfredse med deres egne værdier, men derimod fokusere på hele værdikæden, for at optimere hele leverancekæden og ikke kun fokusere egne forrentninger. Udgangspunktet for en implementering af en handelsportal er, at det er muligt at forbedre leverancekæden for derigennem at forbedre kvaliteten af det færdige byggeri, samt forbedre de enkelte parters muligheder for indtjening. Der er foretaget nogle enkelte tiltag for at prøve at skabe en elektronisk handel i byggebranchen, f.eks. www.billigvvs.dk, men der er ringe opbakning til disse tiltag. Det er derfor nødvendigt at der sker tiltag mod en oplevelse af nødvendighed i byggebranchen. Dette kunne ske ved at det offentlige begynder at udbyde sine projekter digitalt, og stiller krav til handlen med varer, for derved at vise overfor byggebranchen at det er muligt at innovere den danske byggebranche. Internt i virksomhederne skal det sikres, at der ikke er barrierer mod en etablering af nødvendighed ved at være for selvtilfredse med deres position, men tænke på hvordan dette kan forbedre virksomhedens position og indtjeningsmuligheder. 9.2.2 Oprettelse af den styrende koalition Opgaven på dette trin af forandringsprocessen er, at få oprettet en tværgående koalition, der skal varetage den opgave, det er at få implementeret en handelsportal i byggebranchen. Styregruppen skal have det nødvendige kendskab og interesse for et tværfagligt samarbejde, og samtidig have evnen til at implementere og holde processen under kontrol. Stillingsindflydelse: Det er vigtigt for koalitionen at der er tilstrækkelig mange nøglepersoner, så der ikke bliver blokeret for forandringsprocessen. Ekspertise: Det skal sikres at der er den nødvendige ekspertise i koalitionen, så der træffes velbegrundede og fornuftige beslutninger. Troværdighed: Koalitionen skal have tilstrækkelige medlemmer med godt ry i branchen, så udtalelser vil blive taget alvorligt. Lederskab: Det skal sikres at der er erfarne ledere i gruppen for at kunne gennemføre forandringsprocessen. Side 9
Ved implementering internt i de enkelte virksomheder vil det også være nødvendigt at oprette en koalition, som skal besidde de samme kvalifikationer, og som kan sikre en fornuftig brug af handelsportalen. 9.2.3 Udvikling af en vision og en strategi Den styrende koalition har til opgave på dette trin at udarbejde en vision og en strategi for forandringsprocessen. En god vision har til formål at: At forklare hvad kursen mod forandringen fører til. At motivere medarbejderne. At medvirke til en koordinering mellem de forskellige parters handlinger. Karakteristika ved en effektiv vision er følgende [Forandring, s. 9]: Tænkelig. Ønskelig. Gennemførlig. Fokuseret. Fleksibel. Kan kommunikeres. Karakteristika ved en effektiv vision En vision beskriver hvordan en aktivitet eller en organisation vil se ud i fremtiden. Strategien for forandringen skal derfor planlægges så den implementerer visionen på fornuftig vis. Det skal sikres, at der sker en effektiv udvikling af en vision, som kan ske ved følgende steps [Forandringer, s. 101]. Første udkast: Processen starter ofte med en foreløbig erklæring fra et enkelt individ, der afspejler både pågældendes drømme og de reelle markedsbehov. Rollen for den styrende koalition: Det første udkast bliver altid ændret med tiden af den styrende koalition eller af endnu større grupper af medarbejdere. Samarbejdets betydning: En velfungerende gruppeproces forudsætter et mindstemål af effektiv teamwork. Hjernens og hjertes rolle: Både analytisk tækning og en masse drømme er væsentlige elementer gennem hele processen. Processens uregerlighed: Udvikling af visioner er som regel en proces med to skridt frem et tilbage, bevægelse til højre og så til venstre. Tidsramme: En vision bliver aldrig skabt på et enkelt møde. Aktiviteten tager måneder, undertiden år. Slutprodukt: Processen resulterer i en kurs for fremtiden, som er ønskelig, gennemførlig, fokuseret, fleksibel og kan kommunikeres på 5 minutter eller mindre. Udvikling af vision Det skal sikres internt i de enkelte virksomheder at der bliver udviklet en effektiv vision, der sikrer at implementeringen af handelsportalen bliver muliggjort. 9.2. Formidling af forandringsvisionen På dette trin skal visionen kommunikeres ud til hele organisationen, det er vigtig for den styrende koalition at visionen kommunikeres ud ved direkte og Side 95
enkel kommunikation, samtidig med at det skal holdes for øje at forandringsprocessen ikke går i stå. Nøgleelementer i en effektiv kommunikation er følgende [Forandringer, s. 111]. Effektiv kommunikation Enkelhed. Metafor, analogi og eksempel. Mange forskellige fora. Gentagelse. Eksemplets magt. Forklaring af tilsyneladende inkonsekvens. Interaktion. De er vigtigt at få kommunikeret visionen ud på alle niveauer, og den accepteres af organisationen, så det i de næste to trin er muligt et fortsætte forandringsprocessen. Det er også vigtig at acceptere de ændringer der eventuelt måtte komme til visionen, da det er bedre at bevæge sig ad en retning alle mener, er den korrekte, og ikke kun koalitionen. Det er vigtigt i denne forbindelse at det sikres at vision bliver kommunikeret ud til både branchen total set, men også internt i de enkelte virksomheder. 9.2.5 Styrkelse af medarbejdernes kompetence På dette trin er det nødvendigt for koalitionen, at fjerne så mange barrierer for forandringen, som det er muligt, hvilket vil sige at medarbejdernes kompetence skal udvikles. På figur 61 ses de største barrierer for kompetenceudvikling [Forandring, s. 126.]. Barrierer for kompetenceudvikling Formelle strukturer gør det svært at handle Chefer søger at hindre handlinger, der er rettet imod at implementere den nye vision Medarbejderne forstår visionen og vil gerne gære den til en realitet med er låst fast En mangel på nødvendige færdigheder underminerer handling Personale- og informationssystemer gør det svært at handle figur 61. Barrierer for kompetence udvikling. De fire hindringer beskrives i forhold til handelsportalen: Hindringer i forhold til løsning Det er nødvendigt at sikre, at den formelle struktur ikke forhindrer forandringsprocessen, da der i involveret flere parter. Det skal sikres at de involverede parter har de rette færdigheder indenfor e-business, og at medarbejderne der skal bruge handelsportalen har færdighederne til dette. Ved en implementering af en handelsportal, skal det samtidig sikres at virksomhedernes egne systemer er konvertible med det format handelsportalen gør brug af. Ledelsen i de enkelte virksomheder skal overbevises om, at det vil være en nødvendighed at gøre brug af en handelsportal, og derved at denne forandringsproces er nødvendig. Igennem ledelsen kan medarbejderne motiveres i de enkelte virksomheder, hvis ledelsen er motiveret til forandringen. Side 96
9.2.6 Generering af kortsigtede gevinster For at en virksomhed skal have nogle incitamenter til at forsætte med forandringsprocessen er det vigtigt, at der genereres kortsigtede gevinster, og desto flere kortsigtede gevinster der fremkommer jo mere er virksomheden interesseret i at fortsætte forandringsprocesserne, hvilket er illustreret på figur 62. figur 62. Kortsigtede gevinsters indflydelse på en virksomheds forandring [Forandringer, s. 1]. Formålet med at generere kortsigtede gevinster er følgende [Forandringer, s. 152]: Giver bevis på, at ofre ikke er forgæves. Belønner forandringsformidlerne med et klap på skulderen. Hjælper til at finindstille vision og strategier. Underminerer kynisme og egoistiske modstandere. Opretholder motivationen hos ledelsen. Giver fremdrift. Generere kortsigtede gevinster Det er således nødvendigt at der bliver overvejet hvilke kortsigtede gevinster der skal satses på ved denne fordringsproces, både i hele byggebranchen, men også i de enkelte virksomheder. Der er nødvendigt at overveje gevinsterne, og synliggøre dem både over for branchen, men også internt i de enkelte virksomheder. Gennem forsøgsprojekterne kan det synliggøres hvilke gevinster, det vil være på kort- og langsigt 9.2.7 Konsolidering af resultater og produktion af mere forandring Det skal sikres, at de kortsigtede gevinster ikke bliver brugt som hvis forandringsprocessen er slut. De skal i stedet bruges til at tænke på de langsigtede gevinster, så de involverede parter ikke får den overbevisning, at forandringsprocessen er slut. De opnåede kortsigtede gevinster skal være den motiverende faktor, der skal resultere i at resultaterne bliver integreret i virksomhederne, så de nye arbejdsgange bliver brugt. På denne måde kan de opnåede resultater blive konsolideret både i branchen men også i virksomhederne, og resulterer i nye forandringer. Side 97
Implementeringen en af handelsportal i byggebranchen kan medføre at de forskellige systemer i en virksomhed skal ændres, for at sikre en konsolidering af handelsportalen, samt til at medvirke til at forandringsprocessen kan fortsætte. 9.2. Forankring af nye arbejdsmåder i kulturen Det skal sikres at de succesfulde forandringer forankres i organisationen for at undgå at den vender tilbage til gamle normer og værdier. Dette kan undgås hvis forandringen er tilstrækkeligt forankret i kulturen. Gennem implementeringen af handelsportalen, skal det sikres at fremgangsmåder og arbejdsgange forankres i organisationerne, og derved blive en part af kulturen. Det er hensigtsmæssigt for aktørerne i byggebranchen at overveje følgende punkter: Det er nødvendigt at sikre at kompetencen indenfor de pågældende områder bevares i organisationerne, også selvom nogle af aktørerne i organisationerne forsvinder. Der er tale om at det er nødvendigt at nedskrive erfaringerne i nogle procedurer. Sikre at det vil være muligt for nye/udenlandske virksomheder at koble sig på portalen i fremtiden, og derved sikre en udvidelse af handelsmulighederne. 9.3 Implementeringsplan I det følgende beskrives projektgruppens holdning til hvordan en implementeringsplan af handelsportalen ville kunne realiseres. Der tages udgangspunkt i et antal aktiviteter projektgruppen mener, skal realiseres før en implementering vil kunne kaldes succesfuldt fuldendt. I opstillingen af aktiviteterne forsøges det, at tage højde for de problemstillinger, udfordringer og barrierer der tidligere er beskrevet i Leavitts-barriereanalyse og Kotters -trins implementeringsmodel. Projektgruppen mener, at byggeriet er i en speciel situation i forhold til mange andre erhverv, idet der i en stor del af alle større byggerier i Danmark indgår offentlige penge, og den offentlige sektor derfor har mulighed for stor indflydelse på erhvervet. Initiativ fra det offentlige Projektgruppen mener derfor, at det er oplagt at en implementering af løsningsforslaget bør ske med initiativ fra det offentlige for at sikre en fornuftig implementering, hvor alle involverede parter arbejder i samme retning mod fælles mål. Alternativt kunne det forestilles, at de enkelte relevante virksomheder, ville skabe en IT-struktur og kultur, som langsomt ville brede sig op gennem systemet, og til sidst omfatte hele byggebranchen. Projektgruppen mener i den forbindelse, at der ville være for stor fare for, at et samarbejde mellem forskellige virksomheder og brancher ville have svært ved at oprette det konstruktive samarbejde projektgruppen mener, der er behov for. Den efterfølgende implementeringsplan tager derfor udgangspunkt i et initiativ og ansvar fra den offentlige sektor. Der tages desuden udgangspunkt i, at implementeringsprocesserne starter efter fastlæggelse af en overordnet målsætning fra det offentliges side. Side 9
I alle udviklingsfaserne skal der lægges stor vægt på, at brugerfladen bliver så brugervenlig som muligt. Brugervenlig brugerflade Aktiviteterne i implementeringsplanen er opbygget, således de enkelte aktiviteter er delt op i nogle overordnede faser, som overlapper hinanden, jf. figur 63. figur 63. Overordnet opbygning af implementeringsplanen. Når implementering påbegyndes skal der ske et udbud fra det offentlige, udbuddet kan udformes som et konkurrenceforslag hvor det er specificeret hvad der skal opnås i dette projekt, og hvilke milepæle der skal overholdes. Dette projekt skal teste mulighederne for e-handel i et byggeri. I de følgende afsnit vil de enkelte aktiviteter blive diskuteret, der efter projektgruppens mening er hensigtsmæssige for en implementering af en handelsportal. Det vil blive estimeret hvor store implementeringsomkostningerne ville blive. I den forbindelse vil det først blive estimeret hvor langt tid de enkelte parter ville skulle bruge i de enkelte faser. 9.3.1 Målsætningsfase I målsætningsfasen skal visionerne og funktionskravene opstilles til det videre forløb. Aktiviteterne i målsætningsfasen er som følger: Udbud I udbudsfasen skal der udvælges nogle parter til at indgå i et forsøgsprojekt omhandlende brug af handelsportal til køb af materialer i et byggeri. De parter der skal indgå i forsøgsbyggeriet er de typiske parter, som arkitekt, entreprenør, ingeniør mv. Udover disse vil det være nødvendigt med en part der har kompetence indenfor opbygning af handelsportaler, eksempelvis Gatetrade.net. En anden vital del er, at der bliver udvalgt nogle producenter som leverer nogle af de materialer de skal handles over handelsportalen. Udbuddet skal sikre at parterne der skal involveres i dette projekt er engagerede, tror på at dette kan lade sig gøre og har den nødvendige kompetence. For at sikre villige parter i forsøgsprojektet er det nødvendigt at de parter der deltager i projektet får noget ud af det, eksempelvis kan det være nødvendigt at give software udvikleren rettighederne til at drive portalen i eksempelvis 5 år. Side 99
Projektgruppen har i det følgende forudsat følgende parter med i en implementeringsgruppe. Bygherre. Arkitekt. Ingeniør. Entreprenør. Leverandør: Der forudsættes fem forskellige leverandører med. Softwareudvikler: Det forudsættes, at denne bliver garanteret en rammekontrakt på et antal år om at drive portalen efter implementeringen. Vision Det er nødvendigt for de involverede parter, at udarbejde en vision om hvordan handelsportalen kan anvendes engang i fremtiden. Dette er nødvendigt for at sikre den kontinuerlige udvikling af portalen, og således de enkelte parter er enige om hvad der arbejdes mod. Funktionskrav I den indledende fase skal funktionskravene til handelsportalen specificeres, både med hensyn til egenskaber, men også hvilke formater der skal anvendes, f.eks. UNSPSC og RUS til brug i produktkatalogerne. Det skal sikres at funktionskravene er i overensstemmelse med visionen, så det bliver muligt at opnå visionen. Funktionskravene skal også sikre, at handelsportalen kan integreres med de enkelte virksomheders IT-systemer, samtidig med den skal kunne benyttes af virksomhedernes medarbejdere. Gevinster For at sikre en benyttelse af handelsportalen skal der i den indledende fase diskuteres og fastsættes hvilke gevinster der ved anvendelse af handelsportalen kan opnås både på kort og lang sigt. Succeskriterier Der skal opstilles nogle succeskriterier for implementeringen af handelsportalen gennem hele forløbet, det være sig hvad skal være opfyldt efter første forsøgsprojekt og så fremdeles. Der skal udarbejdes nogle definitioner af hvad implementeringsgruppen mener med kvalitet, effektivitet mv., og hvordan disse skal måles. Implementeringsplan I målsætningsfasen skal der udarbejdes en implementeringsplan for at give de involverede parter et overblik over hvor stor tidsomfanget af denne opgave er. Successiv kontrahering I denne aktivitet skriver parterne en kontrakt der løbende kan forhandles/ændres, hvis der er problemer med samarbejdet mellem de enkelte parter. Denne kontrakt skal så forhandles gennem hele projektforløbet på baggrund af nogle fastsatte milepæle, hvor det vil være muligt for de enkelte parter at trække sig ud af projektet hvis det ønskes. Denne aktivitet skal sikre at motivationen og viljen til gennemførelse hos parterne er til stede, og vælger en part at trække sig skal denne honoreres efter hvilke udgifter aktøren har haft, og derfor ingen fortjeneste. I tabel 17 har projektgruppen estimeret tidsforbruget ved de enkelte aktiviteter. Side 100
Målsætningsfasen Tidsforbrug Begrundelse Udbud 12t/3uger Det vurderes at denne aktivitet indebærer et forbrug på 12 timer i mødeaktiviteter selve aktiviteten strækker sig over tre uger. Vision 12t/3uger Udvikling af visionen for dette projekt vurderes til 3 møder fordelt på 3 uger. Funktionskrav t/2uger Opstilling af funktionskrav vurderes til at tage 2 møder af fem timer fordelt på 2 uger. Gevinster t/2uger Til opstilling af mulige gevinster vurderes det nødvendigt med 2 møder af timer fordelt på 2 uger. Til diskussion og drøftelse af succeskriterier og ens opfattelse deraf, vurderes det at være Succeskriterier 12t/3uger nødvendigt med 3 møder fordelt på tre uger, samt forberedelse af hvad de enkelte parter mener med forskellige begreber. Implementeringsplan tager et møde. Det er vurderet at denne aktivitet t/1 uge Denne aktivitet vurderes at tage 2 møder af fire timer, hvor der i det Successiv første møde diskuteres milepæle, t/2 uger kontrahering mens der i det andet gives accept på kontrakt, og eventuelle ændringer diskuteres. tabel 17. Tidsforbrug i målsætningsfasen. På figur 6 ses de enkelte aktiviteter placeret på en tidslinie, de uger hvor der er afsat 2 møder er det vurderet at de enkelte parter har 1 timers forberedelse, og til selve mødet er der afsat timer Side 101
figur 6. Aktiviteter og tidsforbrug der skal anvendes i målsætningsfasen. Det forudsættes, at alle parter kommer til de planlagte møder, og at alle forud for møderne har en times Dette betyder, at timeforbruget for de enkelte parter i målsætningsfasen er som i tabel 17. Beskrivelse Udregning I alt Bygherre 6 timers mødeaktivitet fordelt på 16 6+16 0 møder, og derfor også 16 timers Arkitekt 6 timers mødeaktivitet fordelt på 16 6+16 0 møder, og derfor også 16 timers Ingeniør 6 timers mødeaktivitet fordelt på 16 6+16 0 møder, og derfor også 16 timers Entreprenør 6 timers mødeaktivitet fordelt på 16 6+16 0 møder, og derfor også 16 timers Leverandør 6 timers mødeaktivitet fordelt på 16 (6+16) 5 00 møder, og derfor også 16 timers forberedelse, der forudsættes fem leverandører med Softwareudvikler. 6 timers mødeaktivitet fordelt på 16 6+16 0 møder, og derfor også 16 timers I alt 00 tabel 1. Samlet tidsforbrug i Målsætningsfasen. Side 102
9.3.2 Opbygning af demoversion I denne fase skal den første udgave af handelsportalen udvikles på baggrund af de opstillede funktionskrav mv. Aktiviteterne i denne fase er som følger: Opbygning af database I denne aktivitet skal databasen struktureres, hvor de enkelte data skal gemmes, det er vigtigt at de enkelte parter er enige om, hvad der er nødvendigt at gemme i databasen, således det bliver muligt at søge på f.eks. samme produkt men fra forskellige parter. Databasen skal opbygges således, det er muligt at foretage træk af priser mv. fra de enkelte producenter. Opbygning af portal Det er i denne aktivitet vigtigt at de enkelte brugere af portalen bliver taget med på råd i selve opbygningen af brugerfladen, og derved sikre at portalen gnidningsfrit kan benyttes. Det er vigtigt at få på plads hvordan de enkelte parter kan koble op på portalen om det er køber eller sælger, og hvilke rettigheder der haves herved. Opbygning af producenternes produktkataloger Producenterne, der er tilknyttet i denne fase, skal digitalisere deres produktkataloger, det er i denne forbindelse vigtigt at de bliver udviklet i overensstemmelse med specifikationerne fra databaseopbygningen, så det bliver muligt automatisk at trække oplysningerne fra producenternes egne databaser. Sammensætning af handelsportal I denne aktivitet skal de enkelte dele af portalen samles til én, og placeres på Internettet. Det skal i den forbindelse sikres at sikkerheden på hjemmesiden er tilstrækkelig. I tabel 19 har projektgruppen estimeret tidsforbruget ved de enkelte aktiviteter. Opbygning af prototype Opbygning af database Opbygning af portal Tidsforbrug 1 mdr. 1 mdr. Begrundelse Det vurderes at det vil tage 1 mdr. at strukturere og opbygge en database til brug for handelsportalen i f.eks. Oracle for softwarefirmaet. Det kan være nødvendigt at der holdes 2-3 møder vedrørende opbygningen af databasen. Opbygningen af handelsportalen og integrationen med databasen vurderes at tage 1 mdr. hvor det vil være nødvendigt med feedback fra de enkelte virksomheder der skal benytte handelsportalen. Side 103
Opbygning af producenternes produktkataloger 2 mdr. I denne aktivitet skal leverandørerne opbygge deres produktkataloger i henhold til de retningslinier der er udviklet sammen med databasen, og produktkataloger skal publiceres over handelsportalen, denne aktivitet vurderes at tage 2 mdr. Sammensætning af handelsportal 2 uger Integrationen af de enkelte dele og publiceringen på nettet vurderes til at tage 2 uger. tabel 19. Tidsforbrug til brug for opbygningen af prototypen. På figur 65 ses de enkelte aktiviteter placeret på en tidslinie, hvor leverandøren og softwareudvikleren er afsat som hele uger. Det er op til den enkelte virksomhed at vurdere hvor mange mand det er nødvendigt at afsætte for at nå tidsfristen. figur 65. Aktiviteter og tidsforbrug der skal anvendes i opbygning af prototype fasen. Det forudsættes, at alle parter kommer til de planlagte møder, og at alle forud for møderne har en times Dette betyder, at timeforbruget for de enkelte parter ved opbygning af demoversionen er som i tabel 20. Beskrivelse Udregning I alt Bygherre 20 timers mødeaktivitet fordelt på 5 20+5 25 møder, og derfor også 5 timers Arkitekt 20 timers mødeaktivitet fordelt på 5 møder, og derfor også 5 timers 20+5 25 Side 10
Ingeniør 20 timers mødeaktivitet fordelt på 5 20+5 25 møder, og derfor også 5 timers Entreprenør 20 timers mødeaktivitet fordelt på 5 20+5 25 møder, og derfor også 5 timers Leverandør timers mødeaktivitet fordelt på 2 (20 +10) 5 50 møder, og derfor også 2 timers Derudover er der en aktivitet i forbindelse med opbygningen af produktkataloger som vurderes til 20 timer om ugen i uger inkl. møder. Der er 5 leverandører med Softwareudvikler. Denne vurderes at benytte 37 timer 37 1 51 om ugen i 1 uger inkl. mødeaktivitet I alt 16 tabel 20. Samlet tidsforbrug i prototypefasen. 9.3.3 Dokumentationsfase I denne fase skal det dokumenters at det giver en målbar forbedring af et byggeri ved brug af portalen i et mindre omfang. Det skal være muligt at benytte alle funktionerne på portalen, men ikke med at fuldt udvalg af materialer. Dette forsøgsprojekt kan benyttes til at måle om succeskriterierne der blev opstillet i målsætningsfasen kan opnås. Mindre forsøgsprojekt I denne aktivitet skal der gennemføres et forsøgsprojekt hvor nogle af materialerne skal indkøbes over handelsportalen, for at kunne dokumentere om portalen har den ønskede effekt. Det er derfor nødvendigt at de enkelte muligheder på portalen testes. Der skal ske en instruktion af medarbejderne der skal benytte handelsportalen. Gennem projektforløbet kan det være nødvendigt at foretage visse justeringer af handelsportalen, således det er muligt at foretage handlerne over portalen på en hensigtsmæssig måde. Det er også i denne aktivitet det undersøges om designet af portalen ikke er for langsomt, hvilket kan betyde at de enkelte brugere kommer til at vente for meget, og derved skabe en negativ holdning for benyttelsen af handelsportalen. Evaluering Ved forsøgsprojektets afslutning skal der afholdes en evaluering af selve projektforløbet, hvor det skal diskuteres om, der er opnået en forbedring i henhold til de målsætninger, der er blevet opstillet, og hvis ikke så hvorfor. Det kan være nødvendigt, at de oprindelige målsætninger skal korrigeres. Brugen af portalen skal evalueres om designet var hensigtsmæssigt, og om det var muligt at benytte de enkelte funktioner. Successiv kontrahering I denne aktivitet skal de enkelte parter tage stilling til om de er tilfredse med samarbejdet, og om samarbejdet skal fortsætte. I tabel 21 har projektgruppen estimeret tidsforbruget ved de enkelte aktiviteter. Side 105
Dokumenteringsfase Mindre forsøgsprojekt Evaluering Successiv kontrahering Tidsforbrug 1½ år 2t / 3 uger t / 1uge Begrundelse Første forsøgsprojekt vurderes til at tage 1½ år, hvor der gennem projektperioden arbejdes med at udvikle handelsportalen. Til evalueringen af projektet vurderes det nødvendigt med 3 møder samt forberedelse dertil. Opfølgning på kontrakten vurderes at tage t. tabel 21. Tidsforbrug i dokumentationsfasen. På figur 66 ses de enkelte aktiviteter placeret på en tidslinie, mens selve byggesagen forløber er tiden afsat som hele uger, og det er op til den enkelte virksomhed at vurdere hvor mange mand det er nødvendigt at afsætte for at nå tidsfristen. I byggeperioden skal der afholdes et møde hver uge, hvor der diskuteres eventuelle ændringer/forbedringer af handelsportalen. Forsøgsprojekt Noter: Stiplet boks betyder møde, hvor parterne skal være samlet. Evaluering 21 22 93 9 95 96 97 9 99 100 101 102 Successiv kontrahering Uger (Kalenderdage) Bygherre i alt : 7 arbejdsuger, samt 2 timer fordelt over arbejdsdage Arkitekt i alt : 7 arbejdsuger, samt 2 timer fordelt over arbejdsdage Ingeniør i alt : 7 arbejdsuger, samt 2 timer fordelt over arbejdsdage Entreprenør i alt : 7 arbejdsuger, samt 2 timer fordelt over arbejdsdage Leverandør i alt : 7 arbejdsuger, samt 2 timer fordelt over arbejdsdage Software udvikler i alt : 2 arbejdsuger figur 66. Aktiviteter og tidsforbrug der skal anvendes i dokumentationsfasen. Det forudsættes, at alle parter kommer til de planlagte møder, og at alle forud for møderne har en times De egentlige byggeaktiviteter for de traditionelle parter regnes ikke med i implementeringsudgifterne. Dette betyder, at timeforbruget for de enkelte parter i dokumentationsfasen er som i tabel 22. Beskrivelse Udregning I alt Bygherre 2 timers mødeaktivitet fordelt på 2+ 32 møder, og derfor også timers Side 106
Arkitekt 2 timers mødeaktivitet fordelt på 2+ 32 møder, og derfor også timers Ingeniør 2 timers mødeaktivitet fordelt på 2+ 32 møder, og derfor også timers Entreprenør 2 timers mødeaktivitet fordelt på 2+ 32 møder, og derfor også timers Leverandør 2 timers mødeaktivitet fordelt på (2+) 5 160 møder, og derfor også timers Der er 5 leverandører med. Softwareudvikler. Denne vurderes at benytte timer om 2 656 ugen i 2 uger inkl. mødeaktivitet. I alt 9 tabel 22. Samlet tidsforbrug i dokumentationsfasen. 9.3. Udvikling af prototype I denne fase skal der udvikles en prototype af handelsportalen, som kan sikre at alle leverandører kan kobles op på portalen, og derved gøre det et attraktivt sted at gøre sine indkøb. Funktionskrav På baggrund af evalueringen af forsøgsprojektet kan der være visse funktionskrav, der skal ændres, nye kommet til eller visse andre der skal fjernes. Det skal samtidig sikres at portalen opfylder funktionskravene på dette tidspunkt. Redigering af prototype Det skal sikres at de eventuelle problemer, der opstod i dokumenteringsfasen bliver afhjulpet, at der sker en optimering af portalen, således det er muligt at den kan håndtere flere brugere. Implementering I denne aktivitet skal der gives mulighed for at flere leverandører kan koble sig på handelsportalen, for at sikre en mere attraktiv handelsplads, samtidig med der ydes hjælp til udvikling af de enkelte leverandørers produktkataloger. I tabel 23 har projektgruppen estimeret tidsforbruget ved de enkelte aktiviteter. Udviklingsfase Tidsforbrug Begrundelse Diskussion og redigering af funktionskrav på baggrund af Funktionskrav t/ 2 uger evaluering af forsøgsprojektet Redigering af prototype Implementering 1 mdr. 1 mdr. vurderes til 2 møder over 2 uger. Redigering af handelsportalen vurderes at tage 1 mdr., hvor en tilpasning af funktionskrav og gevinster også skal redigeres. Implementering af flere leverandører vurderes at tage 1 mdr. nu hvor retningslinier og metoder er standardiseret. tabel 23. Tidsforbrug i udviklingsfasen. Side 107
På figur 67 ses de enkelte aktiviteter placeret på en tidslinie, hvor leverandøren og softwareudvikleren er afsat som hele uger, er det op til den enkelte virksomhed at vurdere hvor mange mand det er nødvendigt at afsætte for at nå tidsfristen. Funktionskrav Noter: Stiplet boks betyder møde, hvor parterne skal være samlet. Implementering Redigering af prototype 103 10 105 106 107 10 109 110 Uger (Kalenderdage) Bygherre i alt : 2 timer fordelt over 6 arbejdsdage Arkitekt i alt : 2 timer fordelt over 6 arbejdsdage Ingeniør i alt : 2 timer fordelt over 6 arbejdsdage Entreprenør i alt : 2 timer fordelt over 6 arbejdsdage Leverandør i alt : 12 timer fordelt over 3 arbejdsdage, samt arbejdsuger Software udvikler i alt : arbejdsuger figur 67. Aktiviteter og tidsforbrug der skal anvendes i udviklingsfasen. Det forudsættes, at alle parter kommer til de planlagte møder, og at alle forud for møderne har en times Det vurderes, at der i implementeringsaktiviteten kommer 20 nye leverandører med, som dog ikke er med til de forskellige møder. Dette betyder, at timeforbruget for de enkelte parter ved opbygningen af prototypen er som i tabel 2. Beskrivelse Udregning I alt Bygherre 2 timers mødeaktivitet fordelt på 6 2+6 30 møder, og derfor også 6 timers Arkitekt 2 timers mødeaktivitet fordelt på 6 2+6 30 møder, og derfor også 6 timers Ingeniør 2 timers mødeaktivitet fordelt på 6 2+6 30 møder, og derfor også 6 timers Entreprenør 2 timers mødeaktivitet fordelt på 6 2+6 30 møder, og derfor også 6 timers Leverandør 2 timers mødeaktivitet fordelt på 6 møder, og derfor også 6 timers forberedelse for de oprindelige 5 leverandører. Derudover vurderes de 20 nye at bruge 15 timer om ugen i uger. (2+6) 5+ 20 15 1350 Side 10