View
1
Download
0
Category
Preview:
Citation preview
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
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
6
4 BILAGS OVERSIGT
Biliag 1: Log-bog Sider: 8
Bilag 2: ppt. Med information vedr. task databasen Sider: 17
Mathias Kjærgaard | Future state process for TE
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,
Mathias Kjærgaard | Future state process for TE
8
hvordan man optimerer/vedligeholder produkter således, at målsætningen om ”fast & effective
execution” og ”robust solutions” opfyldes.
5.4 PROBLEMFORMULERING
Ensure fast and effective execution of prioritized cost out and quality tasks and ensure robust solutions
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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)
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for 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
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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
Task status Qualification
Task status Development
Task status Implement
Mathias Kjærgaard | Future state process for TE
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
Task status Qualification
Task status Development
Task status Implement
Mathias Kjærgaard | Future state process for TE
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
- Erfaringsloggen opdateres*
- Business casen opdateres og godkendes af taskansvarlig*
Task status New
Task status
Accepted
Task status Qualification
Task status Development
Task status Implement
Mathias Kjærgaard | Future state process for TE
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
- Erfaringsloggen opdateres*
- Business casen opdateres og godkendes af taskansvarlig*
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
- Erfaringsloggen opdateres*
- Business casen opdateres og godkendes af taskansvarlig*
- Task’en lukkes
Task status New
Task status
Accepted
Task status Qualification
Task status Development
Task status Implement
Task status New
Task status
Accepted
Task status Qualification
Task status Development
Task status Implement
Mathias Kjærgaard | Future state process for TE
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.
Mathias Kjærgaard | Future state process for TE
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
- Erfaringsloggen opdateres
- Business casen opdateres og godkendes af taskansvarlig
Som tidligere:
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.5. er der tilføjet to nye tiltag til fasen implement
- Erfaringsloggen opdateres
- Business casen opdateres og godkendes af taskansvarlig
Som tidligere:
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.
Mathias Kjærgaard | Future state process for TE
32
Afsnit 8.3.6. er der tilføjet to nye tiltag til fasen archeived
- Erfaringsloggen opdateres
- Business casen opdateres og godkendes af taskansvarlig
Som tidligere:
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.
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
Mathias Kjærgaard | Future state process for TE
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)
Mathias Kjærgaard | Future state process for TE
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;
Ensure fast and effective execution of prioritized cost out and quality tasks and ensure robust solutions
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.
Mathias Kjærgaard | Future state process for TE
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
Mathias Kjærgaard | Future state process for TE
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.
Recommended