fUTURE STATE PROCES FOR TE - campus.aams.dk

VELUX A/S SKJERN TASK EXECUTION

FUTURE STATE PROCES FOR TE Et forslag til en ny proces for Task Execution

Mathias Kjærgaard | Future state process for TE

1

Titelblad

Titel: Future state process for Task Execution

Forfatter: Mathias Kjærgaard, A12548

Projekttype: Bachelorprojekt

Uddannelse: Maskinmester, Professionsbachelor

Uddannelsesinstitution: Aarhus Maskinmesterskole, Inge Lehmanns Gade 10

8000 Århus C.

Bachelorvejleder: Henrik Kerstens

Antal normalsider: 17,5

Afleveringsdato: Mandag d. 14 december 2015


2

1 ABSTRACT

As of September 2015 the product organization in VELUX is, divided in Product Care and Product

Innovation. In this context, there is a need for clear and common procedure for how to optimize and

maintain products.

It was there for decided that the main purpose of this report was to provide the Task Execution

department in Skjern, with an idea for a new procedure.

The report is divided into two sections. Current State process and Future State Process. Each of them

contributes to creating an idea for a new procedure. Furthermore, the report investigates the

possibilities of applying PRINCE2 project management theories on the task process.

In the discussion section of the current state process, the report is enlightening some of the problems

regarding the current state of the process. On behalf of the part-conclusion, an idea for a new

procedure is created.

The second part of the report, Future state process, is showing the initiatives made for the new process.

The discussion in that section is highlighting the benefits of applying the new process.

The conclusion concludes that if applying this, or part, of the new process it should accommodate the

new requirements for the procedure:

Ensure fast and effective execution of prioritized cost out and quality tasks and ensure robust solutions

The report also concludes that some concepts from PRINCE2 can successfully be applied to the Task

process. However, the management of tasks does not make a PRINCE2 project.


3

2 INDHOLDSFORTEGNELSE

1 Abstract ................................................................................................................................................. 2

3 Forord .................................................................................................................................................... 5

4 Bilags oversigt ....................................................................................................................................... 6

5 Indledning ............................................................................................................................................. 7

5.1 Formål ........................................................................................................................................... 7

5.2 Baggrunds historie ........................................................................................................................ 7

5.3 Problemstilling .............................................................................................................................. 7

5.4 Problemformulering ...................................................................................................................... 8

5.5 Afgrænsning .................................................................................................................................. 8

6 Metode .................................................................................................................................................. 9

6.1 Dataindsamling ............................................................................................................................. 9

6.1.1 Log-bog beskrivelse ............................................................................................................... 9

6.1.2 Litteratur ............................................................................................................................. 10

6.1.3 Metodekritik ....................................................................................................................... 10

7 Læsevejledning ................................................................................................................................... 11

7.1.1 Rapportens opbygning ........................................................................................................ 11

7.1.2 Forkortelser/akronymer...................................................................................................... 11

7.1.3 Referencer ........................................................................................................................... 12

7.1.4 Definitioner ......................................................................................................................... 12

7.2 introduktion til task databasen ................................................................................................... 13

7.3 Introduktion til PCa / TE-A og TPM ............................................................................................. 14

7.4 Introduktion til PAM området .................................................................................................... 15

8 Current state analyse af task databasen ............................................................................................. 16

8.1 Formål ......................................................................................................................................... 16

8.2 Metode ........................................................................................................................................ 16

8.3 Analyse ........................................................................................................................................ 16

8.3.1 Input .................................................................................................................................... 17

8.3.2 Modtagelse, prioritering og afklaring ................................................................................. 18

8.3.3 Estimering/prioritering af task’en ....................................................................................... 19

8.3.4 Task model .......................................................................................................................... 20

8.4 Diskussion ................................................................................................................................... 21


4

8.5 Delkonklusionen .......................................................................................................................... 23

8.6 Opsummering ............................................................................................................................. 23

8.7 Perspektivering ........................................................................................................................... 23

8.8 Metodekritik ............................................................................................................................... 23

9 Future state proces ............................................................................................................................. 25

9.1 Formål ......................................................................................................................................... 25

9.2 Metode ........................................................................................................................................ 25

9.3 Ny proces .................................................................................................................................... 25

9.3.1 Task status New .................................................................................................................. 25

9.3.2 Task Status Accepted .......................................................................................................... 26

9.3.3 Task status Qualification ..................................................................................................... 27

............................................................................................................................................................ 28

9.3.4 Task status Development .................................................................................................... 28

................................................................................................................................................................ 29

9.3.5 Task status Implement ........................................................................................................ 29

9.3.6 Task status Archived ........................................................................................................... 29

9.4 Uddybning af den nye proces ..................................................................................................... 30

9.5 Redegørelse for den nye proces ................................................................................................. 32

10 Konklusion ....................................................................................................................................... 34

11 Perspektivering ............................................................................................................................... 35

12 Referencer ....................................................................................................................................... 36


5

3 FORORD

Uddannelsen som Maskinmester på Århus Maskinmesterskole skal afsluttes med et 50 dages

bachelorprojekt, og et 50 arbejdsdages praktikforløb. Mit projekt omhandler praktikforløbet.

På mit 8. Semester tog jeg projektledelse som valgfag, og det var også med henblik på dette, da jeg

søgte praktikplads. Det lykkedes mig at komme i praktik hos VELUX i Skjern. I den periode arbejdede jeg

sammen med ansatte i Product Care afdelingen i Skjern, som senere kommer til at blive kaldt Task

Execution. Denne rapport danner grundlag for den mundlige eksamination den. 11 januar 2016.

Hos VELUX har man ytret behov for en fælles proces, ved arbejde med Task Execution. Dette blev emnet

for mit bachelorprojekt.

I mit projekt vil jeg benytte af de værktøjer, jeg er blevet udstyret med på Maskinmester uddannelsen.

Dette gælder specielt forandringsledelse, kommunikation og projektledelse generelt.

Projektet henvender sig primært til læsere med teknisk viden og interesse for projekt- og

forandringsledelse. Rapporten er skrevet til læsere med faglighed på 8. semesters valgfags niveau på

maskinmesteruddannelsen.

Under praktikforløbet og udarbejdelse af rapporten har været mange involveret, som har været yderst

behjælpelige med data og viden af høj kvalitet. Tak til VELUX Skjern for dette praktikophold.


6

4 BILAGS OVERSIGT

Biliag 1: Log-bog Sider: 8

Bilag 2: ppt. Med information vedr. task databasen Sider: 17


7

5 INDLEDNING

5.1 FORMÅL

Dette bachelorprojekt har til formål at komme med forslag til, hvordan VELUX’s Task Execution afdeling

imødekommer målsætningen om ”fast & effective execution” og ”robust solutions”. Derudover

undersøges muligheden for, at anvende PRINCE2 projektledelses teori i forbindelse med behandlingen,

ændrings- og optimeringsopgaver i Task Execution. Projektet henvender sig primært til VELUX.

5.2 BAGGRUNDS HISTORIE

VELUX i Skjern består af en produktudviklingsafdeling, der samarbejder med Gåsdal Bygningsindustri

A/S.

Gåsdal Bygningsindustri A/S er lead factory og er sammen med produktudviklingsafdelingen ansvarlig

for, at indkøre produkterne, at fejl minimeres, og at der klargøres til overflytning til masseproduktion

hos tilbehørsfabrikkerne i henholdsvis Tjekkiet, Frankrig og Kina.

VELUX har per 04-09-2015 gennemgået en stor organisations ændring, fra top til bund.

Der er sket ændringer i produktion, salg, udvikling og produkt grupperne i VELUX.

Hovedoverskriften hedder: ”Mere fokus, bedre produkter, effektivisering, mere innovation”.

Det har betydet en anderledes struktur, der har medført en del rokeringer i arbejdspladser og

ansvarsområder i hele organisationen.

5.3 PROBLEMSTILLING

Produktudviklingsorganisationen i VELUX har hidtil været opdelt i hhv. W (Windows) og A (Accessories),

hvor hvert område har haft ansvar for såvel ny-udvikling som optimering/vedligehold af produkterne. Til

at styre processerne har der været brugt en grundig beskrevet Stage Gate model til udviklingsprojekter

og en løsere defineret task model til vedligeholdelsesopgaverne. Task modellen har været brugt

forskelligt i A og W.

Pr. September 2015 ændres produkt-organisationen til en opdeling i Product Innovation (for både W og

A) og Product Care & Cost (for både A og W). I den forbindelse er der behov for en klar fælles proces for,


8

hvordan man optimerer/vedligeholder produkter således, at målsætningen om ”fast & effective

execution” og ”robust solutions” opfyldes.

5.4 PROBLEMFORMULERING


Hvordan kan en fælles proces for gennemførelse af optimerings/ændringsopgaver i Task Execution se

ud?

Kan PRICE2 Projektledelses strategier implementeres i processen og task modellen?

Hvordan prioriteres og synliggøres task-output på PAM Business meetings?

Hvordan sikres der robuste løsninger i Task Execution?

5.5 AFGRÆNSNING

I henhold til ovenstående problemformulering, er det i dette afsnit hensigten at afgrænse de områder

og faktorer, der kan have indflydelse på gennemsigtigheden af rapporten. Dette gøres for at holde

rapporten og dermed bachelorprojektet inden for den afsatte tid.

Der vil i rapporten ikke blive redegjort for, hvorvidt den organisatoriske ændring kan have påvirket de

indsamlede data.

Rapporten forholder sig ikke til hvordan Task Execution afdelingen (TE-W) i Øst Birk bruger Task

databasen, samt hvilket syn de har på Task processen. Rapporten afgrænser sig til Task databasen, og vil

ikke beskæftige sig med produktændrings databasen (PM). Yderligere giver rapporten ikke en forslag til

hvordan, en eventuel implementering af en ny proces skal håndteres.


9

6 METODE

6.1 DATAINDSAMLING

Formålet med dette kapitel er at redegøre for de metodemæssige valg, der er blevet anvendt i projektet

for, at læseren kan opnå indsigt i, hvordan dokumentationen forbindes med konklusionen.

Afsnittet afdækker ligeledes hvordan metodevalget kommer til udtryk samt hvilken empiri, der har

været relevant for udarbejdelse af rapporten. Kritik af de faglige metoder og deres fremgangs måde vil

blive nærmere beskrevet i de respektive kapitler.

Formålet med rapporten er at give et udkast til hvordan en ny task behandlingsproces i Task Execution

afdelingen hos VELUX i Skjern.

Til undersøgelse af problematikken med den nuværende proces vil der blive anvendt en kvalitativ

undersøgelses metode. Denne undersøgelsesmetode viser sig som observationer ved relaterede Task

møder, samt dialog/interview med MFS og UJA.

Ved beskrivelsen af den nuværende proces hos VELUX er der blevet benyttet kvantitativt tilgængeligt

data fra VELUX’s intranet. Ved nærmere uddybelser er der benyttet data af kvalitativ karakter.

Ydermere vil der blive undersøgt mulighederne i at anvende elementer fra PRINCE2’s

projektledelsesstrategier. Denne undersøgelse udspiller sig ligeledes kvantitativ, ved brug af tilgængeligt

materiale fra PRINCE2 (AXELOS, 2009). Der vil være en redegørelse for brug, en analyse, en diskussion og

en konklusion på hvorvidt brugen vurderes mulig.

6.1.1 Log-bog beskrivelse

Under praktikopholdet er der ført logbog over de på daværende tidspunkt relevante ting for projektet.

Datoer og tidspunkter er listet for de aktuelle møder og aftaler. Uspecificerede tidspunkter betyder at

hændelsen ikke har været planlagt/ført til kalender.

Møder der er listet, vil typisk være med en indledende beskrivelse af, hvad mødet omhandler. Derefter

vil der være beskrevet hvad der drøftes, og hvilke observationer der er gjort. Ydermere vil der typisk

være en sektion, hvor der er listet nogle spørgsmål, eller tanker forfatter har haft på daværende

tidspunkt. Spørgsmålene stillet vil være besvaret umiddelbart efter og vil være på interviewform

(ordrette svar, med mindre forståelses redigeringer). Er respondentens navn ikke oplyst, antages det for

at være en generel VELUX fælles holdning/opfattelse.


10

Spørgsmål der ikke er besvaret, er typiske forståelses/tolknings spørgsmål, som på et senere tidspunkt

har givet svar.

Spørgsmål eller observationer der er markeret med understregning, er blevet undersøgt nærmere på et

senere tidspunkt.

6.1.2 Litteratur

Der vil hovedsageligt blive anvendt anerkendt faglitteratur, som findes i lærebøger. Det antages, at

anvendte metoder nævnt i faglitteraturen kan anses som valide. Al litteratur vedrørende task databasen

og processen er blevet gjort tilgængeligt via VELUX’s intranet.

Efter aftale med TE leder Ulla Jakobsen og Martin Svalgård fra TE holdet, er det besluttet at alle proces

illustrationer jeg skaber og viser i rapporten, skal være på engelsk. Dette gøres for at holde rapporten i

takt med VELUX’s egne proces diagrammer og illustrationer.

6.1.3 Metodekritik

Der er forsøgt at skabe så godt et grundlag for projektets validitet som muligt. Det er dog altid risikofyldt

at anvende så få kilder som primærdata, som er tilfældet, da det kan resultere i en grov generalisering.

Det vil være mest optimalt med flere primære datakilder samt en kvalitativ spørgeskema undersøgelse.


11

7 LÆSEVEJLEDNING

I dette afsnit vil der blive redegjort for, hvordan rapporten er opbygget og skal læses. Heraf hvordan

kilder og henvisninger er anvendt, samt hvilke forkortelser og definitioner der er gennemgående i

rapporten.

7.1.1 Rapportens opbygning

Kapitel 1: Abstract

Kapitel 5: Indledning

Kapitel 6: Metode

Kapitel 7: Læsevejledning

Kapitel 8: Current state analyse af task databasen

Kapitel 9: Future state proces

Kapitel 10: Konklusion

Kapitel 11: Perspektivering

7.1.2 Forkortelser/akronymer

Områder/dokumenter/afdelinger:

PUR = Indkøbsafdelingen

Q = Kvalitets afdelingen

TPS = Technical product service (Service hos leverandørerne, modtager af reklamationer osv.)

TPM = Technical product management

PAV = Product approval documentation

PAM = Product Area Management

PCa = Product Care

TE-A = Task Execution Accessories (Skjern)

PM = Product Modification

Navne:

MFS = Martin Frølund Svalgaard (task ansvarlig)

UJA = Ulla Jakobsen (leder TE-A)


12

7.1.3 Referencer

Kildehenvisninger igennem rapporten er udarbejdet efter ”Harvard-metoden”. Ved denne metode bliver

der henvist med parenteser (forfatter, evt. sidetal, år). Derudover findes alle referencerne på kilderne i

en samlet litteraturliste bagerst i rapporten. Figurer indeholder illustrationer, billeder og tabeller, der

gør det lettere for forståelsen i de respektive afsnit, hvor de forekommer. Figurerne har nummer efter

rækkefølgen i rapporten. Billedteksten under hver figur forklarer, hvad der ses på billedet, samt navnet

på kilden. Kilden til figuren vil kunde findes i bilaget under sammen navn.

7.1.4 Definitioner

I dette afsnit er der, for overskuelighedens skyld, redegjort for en række af de definitioner, der optræder

igennem rapporten. Ved at lave et sammendrag af de mest omtalte definitioner undgås der, at læseren

mistolker indholdet af projektet.

- Når der i rapporten refereres til et ”kapitel”, skal det forstås som en reference til et overordnet

afsnit i rapporten.

- Med reference til et ”afsnit” menes der underafsnit til kapitlerne.

- Task betyder i VELUX en produktændrings opgave

- Kunder skal forstås som internt i VELUX (Lead Factory, PUR, TEST, Q mm.)

- Screening skal forstås som en gennemgang af task indholdet


13

-

7.2 INTRODUKTION TIL TASK DATABASEN

VELUX har udviklet en Task database. Task databasen er et software program, der gør det muligt for

enhver kunde (internt) at, oprette en opgave. En Task (opgave) oprettes når der foreslås et ændrings

ønske på et produkt.

Task databasen giver et samlet overblik over alle produkt-relaterede opgaver og giver ét centralt sted,

hvor disse opgaver kan behandles.

Figur 1 Forsiden på Task database (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

Det overordnet formål med task databasen og den tilhørende behandlingsproces er, at sikre:

- Hjælp til styring af opgaverne

- Ejerskab og struktur ved løsningen af opgaver


14

- Forventningsafstemning om mål/leverancer/del leverancer

- Reduceret gennemløbstid, samt ensartet beslutningsoplæg

7.3 INTRODUKTION TIL PCA / TE-A OG TPM

Product Care er bindeleddet mellem supply og markedet. Product Care har det overordnet produkt

tekniske ansvar og dermed også det overordnet blik for de produkter som er introduceret på markedet.

PCa er efter organisationsændringen blevet opdelt i TPM og TE.

PCa er opdelt i tre produktansvarsområder.

Indvendigt tilbehør: DSP

Udvendigt tilbehør: S

Elektrisk tilbehør: E

TPM afdelingen står for det overordnet produktansvar. Dvs. at TPM skal sikre, at de produkter som er på

markedet, performer i henhold til de krav, der er specificeret til produktet, fra markedet som såvel

forretningen.

TE-A modtager enten tasken (opgaven) direkte fra kunden (opretteren), eller fra TPM. TE-A arbejder kun

med tasks der indeholder investerings- (cost out) eller kvalitets opgaver.

TE-A igangsætter tasks med care og cost initiativer efter hvilken prioritering de har fået på PAM Business

meeting.

PCa overtager produktansvaret fra udviklingsafdelingen efter Gate 6, i VELUX’ Stage Gate model.

Primære PCa opgaver

- Sikrer løbende optimering af omkostninger på det enkelte produkt inden for produktkravende.

- Prioriterer og iværksætter kvalitetsforbedringer af produkter på baggrund af information fra

kvalitet og marked.

- Leder, driver og faciliterer beslutninger omkring TMA godkendelse i forhold til produkt kravene.

- Sikrer at ændringer af produktet gennemføres og dokumenteres når produktet afviger fra

produktspecifikationen, eller ved udfordringer der påvirker arbejdsmiljøet.

- Giver input til udvikling af nye produkter og løbende optimering af eksisterende produkter samt

nødvendigheden for teknisk dokumentation.


15

7.4 INTRODUKTION TIL PAM OMRÅDET

PAM området er et initiativ tilføjet efter organisationsændringen. PAM’s formål er, at i samarbejde med

TE er at opnå en cost reduktion på 4%. PAM’s formål er, at sikre udbredelsen af produktionsområdets

strategi og forretningsmæssige mål for, at koordinere og tilpasse aktiviteter på tværs af supply-områder,

for at sikre en fælles retning. Samt at planlægge, prioritere, drive og sikre udførelse af

omkostningsoptimering og kvalitetsforbedring inden for accessories/VELUX Skjern’s produktionsområde

For at opnå 4% cost reduktion vil PAM og TE beslutte på månedlige møder hvilken prioritering de

forskellige task får.


16

8 CURRENT STATE ANALYSE AF TASK DATABASEN

8.1 FORMÅL

Formålet med dette afsnit er, at analysere den nuværende proces ved brug af task databasen. Dette er

data fra start af praktik perioden, dvs. at de ændringer af processen og selve task databasen, der er lavet

under praktikopholdet ikke er behandlet. I dette afsnit vil der være illustrationer og diagrammer på

engelsk. Ordene vil ikke blive oversat til dansk. Selve analysen vil være på dansk.

8.2 METODE

I dette afsnit vil sekundær data gjort tilgængeligt af VELUX blive brugt som forklaringsgrundlag. Primære

data, indsamlet kvalitativt fra møder og dialoger, primært med MFS fra PCa gruppen, vil blive brugt som

fortolkninger og analyser på de sekundære data. Indsamlingsmetoden er undersøgende (eksplorative) af

interview typen, med en løs spørgeramme. Dette gøres for at skabe overblik og udforske

problemstillinger. MFS vil være påsat som kilde, i de afsnit hvor data kommer fra en dialog med MFS.

Der vil blive draget en konklusion af de sekundære data, på bagrund af de primære data.

8.3 ANALYSE

Task databasen skal give et overblik over alle tasks, i ét system. Fordelene ved dette er, at give kunde og

task ansvarlig et centralt sted at kommunikerer. Det giver kunden mulighed for, at få svar om tasken

bliver bearbejdet eller ej, eller at følge den løbende status af tasken, hvis accepteret. I Task databasen

kan det ses hvilken prioritering tasken har. Al kommunikation vedr. tasken, bliver gemt i task databasen

og kan altid hentes frem. Alt kommunikation, information og tilhørende dokumenter vedr. task’en bliver

lagt i de tilhørende faner i Task databasen og i selve proces modellen.

På figur 2 herunder vises proces flowet for task’s. Det vil ud fra proces flowet blive beskrevet proces

tilgangen til tasks.


17

Figur 2 Task flow (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

8.3.1 Input

Tasken har status af ”Task status New”. En indledende beskrivelse af tasken/opgaven, udarbejdet af

kunden/opgavestilleren. Ydermere har kunden inddelt tasken i produktområdet (GGL/Vindue,

DSP/Tilbehør).

Kunderne er et begreb VELUX bruger til, at betegne de dele af organisationen, der foreslår

produktændringer f.eks produktionen, kvalitets systemet, eller medarbejder i supportsystemerne mv.

Kategoriseringstræet for produktudviklings opgaver er illustreret herunder.


18

Figur 3 Kategoriseringstræ (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

Kategoriseringstræet illustrerer hvilke kriterier der skal forestå, for at kunne kalde et projekt/opgave en

task.

For at opgaver kan lægges i task databasen skal de overholde disse kriterier:

- Kostbesparelses og kvalitets opgaver på aktivt produkt program, der defineres som ”tasks” – jf.

kategoriseringstræet

- Produkt programs opgaver, som ikke er store nok til at følge Stage gate, f.eks. nye størrelser,

varianter

- Ændrings forespørgsler til produkter og konstruktionsgrundlag

8.3.2 Modtagelse, prioritering og afklaring

Efter modtagelse af en Task gennemløber den en screenings fase, udført af PCa. Screeningen har til

formål at kategorisere og sortere task’s ud til den rigtige afdeling: TPM eller TE.


19

TPM:

2D tegningsændringer på produkter

”Små Task’s”

TE:

Konstruktions ændringer på produkter

Test vedr. produkter

PAV godkendelser mm.

Denne screening bliver foretaget TPM/TE. Den task ansvarlige har derefter ansvaret for task’ens

efterfølgende behandling. Screeningen har til formål, at uddelegere task’s til de rigtige afdelinger. TE

arbejder med task’s af større kompleksitet, i forhold til TPM.

8.3.3 Estimering/prioritering af task’en

I denne fase har task’en modtaget en task ansvarlig i et af ansvarsområderne for PCa. Den taskansvarlige

agere nu projektleder/tovholder på tasken, og følger den indtil arkivering.

Den task ansvarliges opgave er nu, at lave en analyse af tasken. Analysen danner grundlag for at task’en

kan gennemføres. Den totale gennemløbstid for tasken estimeres. Dette gøres ved, at den task

ansvarlige kontakter de personer der skal involveres i forbindelse med udarbejdelse af task’en. De giver

hver især et estimat på, hvor meget tid de skal bruge på den. Den samlede tid føres ind i task’en.

Den samlede tid for task’en er et erfarings estimat fra tidl. Task’s. Den tilbageværende tid til task’en er

løst skal løbende opdateres.

Ydermere definere den task ansvarlige af hvilken type og natur tasken er. Der findes fire typer at vælge i

mellem. Product program, cost optimisation, quality eller other, og om det er af typen technical eller

commercial.

En task er teknisk når den vedr. ændringer af tegningsmateriale, TMA godkendelse, PM’er, osv. En task

er kommerciel når den ikke påvirker produktet, andet end ændring af pris, leveringsbetingelser mv.

Denne kategori har til formål, at blive brugt af PUR i forbindelse med costinitiativer, i forhold til

prisforhandling mellem VELUX og en leverandør og lign.

Prioriteringen har til formål at kategorisere tasken, kategoriseringen har direkte indflydelse på

ressourcetildeling i forhold til tidsplanen. Dvs. task kategori 1 tildeling betyder at den er vigtig/kritisk.

Der er flere forskellige ting der kan gøre den vigtig/kritisk. Der kan f.eks. være større økonomiske


20

konsekvenser samt produkt ændringer der har direkte indflydelse på markedet mm. Kategorisering går

fra 1-4, ét værende højest prioritet.

8.3.4 Task model

Følgende har til formål at oplyse læseren og analysere VELUX’s nuværende task model. Task modellen

findes i to former, en reguler og en light version af den. Light versionen vil ikke blive behandlet i

rapporten, da den benyttes af TPM til mindre tasks.

Task modellen benyttes af den task ansvarlige, og er en hjælpeskabelon til at skabe struktur ved

løsningen af task’s. Faserne for task modellen ses herunder.

Figur 4 Analysis delen af current state modellen (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

Som det fremgår af modellen gennemgår en task tre faser. Analysis, development og implement.

Analyse delen i processen har til formål, at kortlægge omfanget af den modtaget task. Den task

ansvarlige benytter sig af de ressourcer/kollegaer der er nødvendige - et opstartsmøde bliver afholdt

med de nødvendige parter for, at beslutte hvilken løsning tasken kræver. På mødet bliver der diskuteret

hvilke risici og omkostninger der vil være. Resultater, beslutningsoplæg, tidsplan og møderapporter fra

hver fase rapporteres til produktgruppen. Rapportering sker via. en powerpoint præsentation lavet af

task ansvarlig, der præsenteres på et ugentligt task møde.


21

Figur 5 Development delen i current state (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

I development fasen påbegyndes arbejdet med taskløsningen. Alt efter hvilken natur tasken har,

vurderes det af task ansvarlige, hvad der skal foretages i dette afsnit. Dvs. hvorvidt alle nødvendige

områder er dækket for, at overgå til næste fase.

Figur 6 Implement delen i current state (ppt. Taskhåndtering, taskdatabase og tidsregistering-24.02.14)

Implementerings fasen har til formål at afslutte tasken. Her udsendes PM’en (et produkt modifikations

dokument), og kortlægger status for 0-serie produktion. En evaluering af task behandlingsprocessen

udarbejdes af taskansvarlig, og arkiveres i tasken. Task’en får status ”Closed” og forsvinder fra listen

over aktive task’s i databasen. Task ansvarlig informerer TPM afdelingen omkring task status og andet

relevant information.

8.4 DISKUSSION

Det følgende har til formål, at sætte task modellen og den tilhørende proces i perspektiv og skabe en

overordnet objektivitet. Her vil der blive benyttet primære data indsamlet kvalitativt fra interviews,

dialog og møder samt observationer gjort i PCa under praktikopholdet.


22

En dialog med MFS påpeger en uens tilgang til brugen af task modellen i TE-A. Det betyder at de task

ansvarlige hver især, arbejder med modellen forskelligt. Der kan være flere forskellige årsager til dette.

En af dem, påpeget af MFS er, at task modellen er udviklet i VELUX’s vindue afdeling i Øst Birk. Det

betyder at de task ansvarlige i Skjern, ikke har haft indflydelse på hvordan processen ser ud. MFS/TE-A

mener at grundet forskelligheden af task’s i TE-A og TE-W, vanskeliggøres det at anvende task modellen

til task’s modtaget i TE-A. Pga. af dette har de task ansvarlige haft forskellige tilgange til, hvordan de

nedskrevne procestrin udnyttes og hvordan task databasen generelt skal behandles. (Svalgaard, 2015)

I praksis betyder dette, at dokumentationer, mødereferater, kommunikation, analyser, beslutninger mv.

Ikke befinder sig i det tilsigtede område i task’en databasen, eller i værste tilfælde, være manglende.

Et eks. kunne være, at den task ansvarlige ikke anvender fanen ”Process” i task databasen og bruger

fanen ”Description” som samlingspunkt for al dokumentation vedr. task’en.

Dette giver en individuel præget task, der kan besværligøre det for en anden taskansvarlig, eller andre

eksterne interessenter, at trække information ud af task’en.

En teori iflg. MFS er, at de som task ansvarlige, ikke har været instrueret tilstrækkeligt i hvordan Task

databasen udnyttes bedst muligt. Dette kan have betydet, at de forskellige task ansvarlige har udviklet

deres egen metoder/protokoller i udarbejdelsen af en task.

Som påpeget tidligere kan det besværligøre udtrækningen af data, men dette kan også betyde at

elementer af den beskrevet proces undlades, fordi den task ansvarlige ikke føler der har været behov for

at kunne løse task’en.

Problematikken med dette er, at task databasen bliver erfaringsbaseret og potentielt vigtig information

kan være manglende/glemt.

En konsekvens af dette kan blive, at en task er udført og arkiveret, men efterfølgende opdages der f.eks.

at et bestemt materiale benyttes, som ikke overholder VELUX’s materiale standard, hvor man igennem

taskmodellen, hvis fulgt efter hensigten, kunne have opdaget og undgået dette.

Et andet eksempel kan være, at den task ansvarlige har undladt at evaluere på task processen. Det kan

betyde, at problematikker/erfaringer fra gennemarbejdelsen ikke bliver dokumenteret, således disse

problematikker kan undgås til fremtidige task’s.

Under task relaterede møder, hvor der har opstået dialog omkring udfyldning af

information/dokumentation vedr. task’s, er der blevet observeret, hos nogle, en klar

utilfredshed/frustration med/over hvordan task modellen beskriver, hvordan de task ansvarlige skal


23

bruge processen, og det generelle layout af task databasen. Mere specifikt kan det siges, at flere af de

task ansvarlige har svært ved, at se formålet med flere af task procestrinene, og finder modellen for

rigid.

Yderlig bekymringer er det blevet ytret, over selve grundlaget for at task’en skal gennemføres. Med

dette skal forstås, at værdien for at en task gennemføres ikke har været synliggjort. Det betyder at der

kan opleves færdiggjorte task’s uden synlig værdi for virksomheden (Kost eller kvalitet). Et eksempel

kunne være, at en task ansvarlig har modtaget en task, hvor der i beskrivelsen står, at produktionen har

bedt om en teknisk ændring på et produkt. Hvor det mangler af beskrivelsen, til hvilket formål dette har.

Med andre ord, om det har betydning for kvalitet, produktion eller omkostninger.

I en dialog med MFS fremhæver han, at: ”der er en tendens til for mange task’s uden/uklart grundlag for

gennemførelse”.

8.5 DELKONKLUSIONEN

Af dette kan det konkluderes, at de task ansvarlige har søgt en mere dynamisk model, og en bedre

synlighed værdi for gennemførelse. En proces der bedre kan tilpasses de respektive task afhængig af

opgavens størrelse/kompleksitet.

8.6 OPSUMMERING

I det forgående afsnit er der blevet analyseret, diskuteret og konkluderet hvordan VELUX’s proces model

for TE og TPM fungerer, samt hvordan task modellen ser ud, og anvendes.

8.7 PERSPEKTIVERING

Under indsamlingen af de data benyttet for, at kunne skabe en konklusion, kunne man med fordel have

benyttet sig af John P. Kotter’s teorier omkring forandringsledelse. Brugen af Kotter’s teorier kunne have

belyst, hvorvidt VELUX’s organisations ændring, kan have haft indflydelse på de primære data benyttet i

rapporten.

8.8 METODEKRITIK

I udarbejdelsen af dette afsnit har der været brugt kvalitativ data i form af observationer fra task møder,

samt interview/dialog med MFS og UJA, som har været den generelle metodik igennem hele rapporten.


24

Der er udarbejdet en analyse af task databasen og proces modellen. Dette har skabt en diskussion, og ud

fra denne diskussion er der blevet udarbejdet et forslag til en ny task proces.

Ved brug af denne form for data, kan helhedsbilledet af task databasen og processen være præget af

MFS, UJA og forfatteren. Dermed kunne man med fordel, have anvendt en kvantitativ interviewform,

med et fastlagt spørgeskema til at benytte på samtlige task ansvarlige. Dette vil betyde, at

problematikker omkring task databasen endeligt kan fastslås.


25

9 FUTURE STATE PROCES

9.1 FORMÅL

Dette afsnit har til formål at give VELUX et udkast til hvad en fremtidig Task Proces kan indeholde. Dette

gøres for at besvare problemformuleringen og den tilhørende tese:

”Ensure fast and effective execution of prioritized cost out and quality tasks and ensure robust solutions”

Ydermere undersøger denne del af rapporten muligheden for, at anvende PRINCE2’s

projektledelsesprincipper på VELUX’s Task Model.

Den nuværende proces vil blive brugt som skabelon, hvor den fremtidige vil være en opdateret version,

bedre passende til TE-a’s struktur. På baggrund af analysearbejdet og konklusionen på den nuværende

proces.

9.2 METODE

I udarbejdelsen af følgende afsnit er der blevet brugt sekundær data, gjort tilgængeligt af VELUX. På

baggrund af den primære data indsamlet, er der blevet udarbejdet forslag til ændringer af processen i

forhold til problemformuleringen.

9.3 NY PROCES

9.3.1 Task status New

Når task’en skal oprettes hos kunden skal beskrivelsen indeholde:

- Detaljer omkring task’en.

- En beskrivelse af hvad denne task har af værdiskabende effekt for VELUX*

- En beskrivelse af hvilke risici positive/negative kan der forekomme ved denne task*

På bagrund af dette besluttes der i TE-A hvorvidt task’en kan gå videre til næste fase.

Task status New

Task status

Accepted

Task status Qualification

Task status Development

Task status Implement


26

9.3.2 Task Status Accepted

I status Accept er task’en blevet godkendt TE-A. Følgende tjekliste skal være udfyldt for, at kunne overgå

til næste fase.

- Evaluering af task beskrivelsen

- Estimering af nødvendige ressourcer

- Erfaringslog oprettes*

- Erfaringslog for tidligere task’s gennemgås*

- Udarbejdelse af business case*

- Projekt plan

- Projekt FMEA

Evalueringen må ikke overskride mere end 5% af det samlede timeantal påskrevet task’en

Task status New

Task status

Accepted





27

9.3.3 Task status Qualification

I kvalifikationsfasen bliver der udarbejdet en analyse af task’en. Følgende tjekliste skal være udfyldt for,

at kunne overgå til næste fase.

- Diverse krav

- Test plan

- Detaljeret mødeplan

- Tidsplan

- Risiko vurdering

- FMEA start

- Evaluering

- PM opstart

- Erfaringsloggen opdateres*

- Business casen opdateres og godkendes af taskansvarlig*

Task status New

Task status

Accepted





28

-

9.3.4 Task status Development

I developmentfasen udarbejdes en udviklings løsning for task’en. Følgende tjekliste skal være udfyldt af

TE-A for, at kunne overgå til næste fase.

- Test af løsningen

- Produktions udstyr

- SAP materiale

- Tidsplan

- Produkt FMEA



Task status New

Task status

Accepted





29

9.3.5 Task status Implement

I implementeringsfasen implementeres den valgte løsning for task’en. Følgende tjekliste skal være

udfyldt af TE-A for, at kunne overgå til næste fase.

- PM’en frigives

- Task opfølgning



9.3.6 Task status Archived

I arkiveringsfasen er task’en løst og klar til at blive arkiveret. Følgende tjekliste skal være udfyldt af TE-A

for, at kunne overgå til næste fase.

- TE-A taskansvarlig sikre at TPM ansvarlig er relevant informeret (FMEA, Test resultater, task

rapport, PM no., økonomi, oplæring osv.)

- TE-A taskansvarlig sikre at alt relevant/vigtigt data er rapporteret i task’en



- Task’en lukkes

Task status New

Task status

Accepted




Task status New

Task status

Accepted





30

9.4 UDDYBNING AF DEN NYE PROCES

I det forgående afsnit ses et forslag til, hvordan en ny proces hos Task Execution kan se ud. Processen

tager udgangspunkt i VELUX’s tidligere proces. Formålet med analysen af den nye proces er, at give

læseren et generelt indblik i processen og de nye tiltag. Stjernemarkerede punkter i tjeklisten vil være

bearbejdet herunder. Punkter der i tjeklisten ikke er stjernemarkerede, vil ikke blive behandlet. Dettes

gøres ikke, fordi punkterne allerede er kendt af VELUX, og ikke behøver yderlig bearbejdning.

I afsnit 8.3.1. er der tilføjet to nye tiltag til opretningen af en task.

- En beskrivelse af hvad denne task har af værdiskabende effekt for VELUX

- En beskrivelse af hvilke risici positive/negative der kan forekomme ved denne task

Punkterne er tilføjet med det formål, at danne et bedre grundlag for udarbejdelse af business casen.

Ved at stille spørgsmål til task opretteren/kunden, ønskes mere indsigt og bedre forståelse af, hvorfor

denne task skal gennemføres. Ydermere har dette til formål, at drøfte spørgsmålet omkring hvorvidt og i

hvilken grad task’en danner en værdiforøgelse. Med værdiforøgelse skal forstås cost/benefit, sikkerhed,

kvalitet, innovation og produktionsmæssige forbedringer.

Derudover undersøges der med spørgsmålet om hvilke risici der kan være ved task’en. Dette gøres for,

at anvende task opretteren til hjælp med, at identificerer mulige risici. Dette har også til formål at

fremme udarbejdelsen af business casen.

Afsnit 8.3.2. er der tilføjet tre nye tiltag til fasen accepted.

- Erfaringslog oprettes*

- Erfaringslog for tidligere task’s gennemgås*

- Udarbejdelse af business case*

Erfaringsloggen skal oprettes for, at give task ansvarlig et værktøj til fremadrettet task’s.

Erfaringsloggen oprettes for at skabe logbogs rapporter, med erfaringer i forbindelse med

bearbejdningen af task’en. Erfaringerne kan bestå af mange forskellige ting, bl.a. sikkerhed, økonomi,

tidsestimering mm.

Erfaringslogs fra tidligere lignende task’s gennemgås for, at skabe overblik over de erfaringer der gjort

vedr. styrker og svagheder i forbindelse med teknikker og procedure ved bearbejdningen af tidligere

task’s.


31

Yderligere skal der udarbejdes en business case. Business casen skal være let præsenter bar, således der

på PAM mødet kan foretages en beslutning, om af hvilken prioritering de respektive task’s skal have.

Afsnit 8.3.3. er der tilføjet to nye tiltag til fasen qualification.

- Erfaringsloggen opdateres

- Business casen opdateres og godkendes af taskansvarlig

Erfaringsloggen opdateres med nye erfaringer fra fasen.

Business casen opdateres ligeledes. Er der sket afvigelser i forhold til sidste fase, skal business casen

godkendes på PAM mødet, før task’en kan skifte fase.

Afsnit 8.3.4. er der tilføjet to nye tiltag til fasen development



Som tidligere:




Afsnit 8.3.5. er der tilføjet to nye tiltag til fasen implement



Som tidligere:





32

Afsnit 8.3.6. er der tilføjet to nye tiltag til fasen archeived



Som tidligere:




9.5 REDEGØRELSE FOR DEN NYE PROCES

Følgende afsnit har til formål at diskuterer valgene fortaget mht. tiltagene i den ny proces. Valgende

afspejler den diskussion og konklusion foretaget i afsnittet 7.4 og 7.5.

Afsnit 8.3.1.

På baggrund af 7.5 DELKONKLUSION foreslår rapporten følgende:

I oprettelsesfasen af en task, ønskes det fra kunden/taskopretteren at der er gjort tanker til

værdiforøgelse af produktet, og hvilke eventuelle risici gennemførelsen kan føre med sig. I praksis

betyder dette, at kunden skal udfylde, i task’en, en beskrivelse af dette.

Formålet med dette er, at bidrage med information til selve grundlaget for task’en ved, at der er gjort

yderligere tanker. I forhold til tidligere, skal dette afhjælpe problematikken omkring for mange task’s

med for dårligt grundlag. Med baggrund i ovenstående, kan dette potentielt medføre yderligere fokus

på cost og kvalitets forbedringer.

En erfaringslog oprettes for, at skabe et værktøj den task ansvarlige løbende kan benytte sig af.

Erfaringsloggen er et uformelt opbevaringssted for dokumentation af erfaringer med relevans for denne,

eller fremtidig task’s. Princippet for erfaringsloggen er, at TE-A tager ved lære af erfaringer. Dvs. at

erfaringer opsøges, opsamles og udnyttes i hele task processen. Et eksempel kunne være hvis der

opstod et problem med tidsestimering på en task. Hvis denne problematik er blevet erfaret tidligere, vil

den taskansvarlige kunne referer logbogen for en potentiel løsning. (AXELOS, 2009)

En business case bør oprettes i målet om, at skabe et forsat grundlag for task udarbejdelsen. Business

casen skal benyttes og vedligeholdes i hele task processen. Business casen skal fremlægges på PAM

mødet. Business casen driver alle beslutningsprocesser, idet den skal sikre, at task’en forbliver


33

velbegrundet, og at de ønskede forretningsmål og udbyttet fortsat kan opnås. I praksis betyder dette, at

den taskansvarlige skal afgøre efter hver fase om omkostninger, tidshorisont, risici eller udbytte skal

opdateres. (AXELOS, 2009)


34

10 KONKLUSION

Problemformuleringen rapporten ønsker at besvare:

Hvordan kan en fælles proces for gennemførelse af optimerings/ændringsopgaver i Task Execution se

ud?

Det fremgår af rapporten at der har været en holdning til, at processen i Task Execution ikke har været

passende til de nye krav som er stillet til Task Execution;


Igennem analyse og diskussion af den nuværende Task proces, fremgår det tydeligt, at modellen ikke har

været benyttet efter hensigten og dette har genereret manglende struktur ved udarbejdelse af task’s.

De taskansvarlige benytter sig af egne metoder til udarbejdelse og rapporteringen i task’en. Dette

resultere i en problematik, at task databasen bliver for erfaringsbaseret. Erfaringsbaseret i den forstand,

at erfaringen viser sig i de individer der udarbejder task’en og ikke i selve task databasen.

Rapporten giver et udkast til hvordan disse problematikker løses vha. af nye tiltag i task processen.

I task oprettelsen spørgers kunden i den nye proces til, hvilken værdiskabelse kan den pågældende task

have for VELUX. Samtidig skal kunden vurdere hvilke risici der kan forekomme i forbindelse med

gennemførelsen af den pågældende task.

Rapporten giver ligeledes et udkast til opbygning af en erfaringsopsamling, samt en forslag til brugen af

en business case for hver igangsat task.

Der kan konkluderes at dele af PRINCE2’s projektledelsesprincipper kan bruges som inspiration på task

modellen. Med det skal forstås, at elementer fra PRINCE2 kan benyttes. En task kan ikke sammenlignes

med et PRINCE2 projekt. Derfor kan taskprocessen ikke blive kaldt et PRINCE2 projekt forløb.


35

11 PERSPEKTIVERING

Dette afsnit har til formål at give et indblik i hvilke perspektiveringer forfatteren har haft under

udarbejdelsen af rapporten.

Rapporten har til formål at give VELUX et udkast til hvordan en fremtidig task proces i Task Execution

kunne se ud.

- Rapporten kunne med fordel have behandlet hvilke implementeringsmæssige udfordringer og

løsninger der kunne opstå i forbindelse med ibrugtagningen af en ny proces.

- Rapporten behandler ikke hvordan de organisatoriske ændringer kan have påvirket de primære

data


36

12 REFERENCER

AXELOS. (2009). PRINCE2 - Projektledelse med succes. London: TSO (The Stationery Office).

Jacobsen, U. (2015). Leder, Task Execution - Accessories. (forfatter, Interviewer)

Svalgaard, M. (2015). Task ansvarlig, Task Execution - Accessories. (Forfatter, Interviewer)

VELUX A/S. (2015). VELUX intranet. Skjern, Danmark.

Documents

fUTURE STATE PROCES FOR TE - campus.aams.dk