Stage, wat voor methodiek kan ik gebruiken bij mijn project

[gangstahh]

Beste mede Tweakers,

Onlangs ben ik begonnen aan een stage, mijn opdracht is om een afdeling volledig te analyseren (wat gaat er precies fout, waarom etc.…). Je kan wel zeggen een zeer uitdagende opdracht alleen zit ik momenteel vast op de methodiek die ik wil toepassen. Ik ben zelf gewend om met Scrum of Waterval te werken maar dit past naar mijn idee niet helemaal binnen dit project. Het is niet een implementatie van software maar puur informeren, analyseren en het schrijven van een passend advies.

Uiteraard heb ik ook het een en ander gegoogeld maar ben er niet wijzer van geworden. Wellicht heeft iemand van jullie ervaring met een soortgelijk project en mij kan helpen met deze kwestie.

Met vriendelijke groet,
Patryk

[Señor Sjon]

Is het niet de clue van een stage om daar zelf achter te komen?

[MsG]

Het lijkt me dat je bij een onderzoek een onderzoeksmethodiek gebruikt en geen projectmanagementsmethodiek. Heb je vanuit de opleiding niet een bepaalde methodiek die wordt gebruikt?

[JDillinger]

gangstahh schreef op woensdag 07 september 2016 @ 12:14:
mijn opdracht is om een afdeling volledig te analyseren (wat gaat er precies fout, waarom etc.…).

Ben bang dat we met deze gedetailleerde beschrijving van je stage niet heel veel kunnen..
Wat is nou exact het doel en wat je ga je onderzoeken? Welke opleiding doe je?
En is je naam serieus Patryk met een y? Nooit gehoord, nice .

[gangstahh]

@Snor Sjon Ben ik het deels mee eens, alleen zoals ik al zei is de waterval of scrum methode een no-go en ik ben redelijk gewend om met die methodiek te werken.

@MsG Van uit de opleiding hebben we heel veel waterval gebruikt, maar heb zelf eens een cursus scrum gehad. Verder hebben we wel wat technieken gehad maar irrelevant voor deze opdracht.

[mkroes]

Lean / Six Sigma?

[FreezeXJ]

Scrum en waterval etc zijn manieren om problemen te voorkomen, als ze eenmaal optreden zul je ze toch pe geval moeten afhandelen. Wat je kunt doen is kijken hoe een techniek wordt toegepast, en waar ze daarmee steken laten vallen. Bijvoorbeeld : gebruiken ze scrum maar gaan ze elke keer massive over de deadline, dan heb je daar iets te pakken.

Verder eens met MsG, dit gaat niet over de management-techniek maar over de manier van analyseren. Wellicht eens een babbeltje met je begeleider maken?

[kwakke01]

gangstahh schreef op woensdag 07 september 2016 @ 12:14:
Beste mede Tweakers,

Onlangs ben ik begonnen aan een stage, mijn opdracht is om een afdeling volledig te analyseren (wat gaat er precies fout, waarom etc.…). Je kan wel zeggen een zeer uitdagende opdracht alleen zit ik momenteel vast op de methodiek die ik wil toepassen. Ik ben zelf gewend om met Scrum of Waterval te werken maar dit past naar mijn idee niet helemaal binnen dit project. Het is niet een implementatie van software maar puur informeren, analyseren en het schrijven van een passend advies.

Uiteraard heb ik ook het een en ander gegoogeld maar ben er niet wijzer van geworden. Wellicht heeft iemand van jullie ervaring met een soortgelijk project en mij kan helpen met deze kwestie.

Met vriendelijke groet,
Patryk

Waarom begin je niet gewoon de opdracht uit te voeren; het analyseren van de afdeling. Je hebt je onderwerp (afdeling) je doel (wat gaat er mis), je vraag spitst zich eigenlijk alleen toe op het "hoe"
SCrum en waterval zijn niet de enige analyse aanpakken die er zijn. Begin gewoon klein; afdeling in kaart brengen, wat doen ze, wat zijn de sterke punten en wat de zwakke. ga eens praten met de manager van de afdeling en loop langs bij de controller van het bedrijf en vraag naar zijn inzichten. Voor je het weet heb je een berg aan info die je meer dan genoeg haakjes geven om je analyse te voedden. Succes!

[gangstahh]

WWAS schreef op woensdag 07 september 2016 @ 12:28:
[...]


Ben bang dat we met deze gedetailleerde beschrijving van je stage niet heel veel kunnen..
Wat is nou exact het doel en wat je ga je onderzoeken? Welke opleiding doe je?
En is je naam serieus Patryk met een y? Nooit gehoord, nice .

Ik studeer Business IT & Managemet.

Het doel van mijn stage is om uiteindelijk met een passend advies te komen waardoor zij efficiënter kunnen gaan werken, waardoor er dus minder tijd verloren gaat aan kleine foutjes en waardoor er dus meer verdiend gaat worden. Mijn taak is dus een volledige analyse van het bedrijf (35 man).

En ja het met een Y, thanks

[gangstahh]

kwakke01 schreef op woensdag 07 september 2016 @ 12:37:
[...]


Waarom begin je niet gewoon de opdracht uit te voeren; het analyseren van de afdeling. Je hebt je onderwerp (afdeling) je doel (wat gaat er mis), je vraag spitst zich eigenlijk alleen toe op het "hoe"
SCrum en waterval zijn niet de enige analyse aanpakken die er zijn. Begin gewoon klein; afdeling in kaart brengen, wat doen ze, wat zijn de sterke punten en wat de zwakke. ga eens praten met de manager van de afdeling en loop langs bij de controller van het bedrijf en vraag naar zijn inzichten. Voor je het weet heb je een berg aan info die je meer dan genoeg haakjes geven om je analyse te voedden. Succes!

Bedankt voor je advies, maar vanuit mijn studie moet ik wel gestructureerd te werk gaan. Eigenlijk niet alleen voor mijn studie maar ook voor mezelf, ik wil namelijk duidelijk hebben hoe ik het ga doen(ik kan echt heel chaotisch zijn). Als ik voor mijzelf enige leidraad heb, heb ik een houvast en kan ik deadlines voor stellen, vandaar dat ik een compleet plan van aanpak wil hebben voor dat ik daadwerkelijk begin aan mijn onderzoek.

[lonkhuijzen]

Kijk eens naar bedrijfsarchitectuur. Met behulp van togaf kan je in kaart brengen welke functies e.d er bestaan. Hoe deze worden gerealiseerd door apllicatiefuncties.

Met behulp van de motivation extensions kan je via dialoog met de business in kaart brengen wat er speelt en wat er misgaat. Die zou je dan kunnen plotten op de bedrijfsarchitectuur waar je dan veranderingen/projecten kan voorstellen

[kwakke01]

gangstahh schreef op woensdag 07 september 2016 @ 12:41:
[...]


Bedankt voor je advies, maar vanuit mijn studie moet ik wel gestructureerd te werk gaan. Eigenlijk niet alleen voor mijn studie maar ook voor mezelf, ik wil namelijk duidelijk hebben hoe ik het ga doen(ik kan echt heel chaotisch zijn). Als ik voor mijzelf enige leidraad heb, heb ik een houvast en kan ik deadlines voor stellen, vandaar dat ik een compleet plan van aanpak wil hebben voor dat ik daadwerkelijk begin aan mijn onderzoek.

In dat geval zou ik het benaderen als een scriptie; er zijn genoeg richtlijnen voor te vinden voor het schrijven van een scriptie, en met name het 'hoe begin je' deel is vaak uitvoerig beschreven omdat daar bijna iedereen moeite mee heeft. als je googled op 'onderzoeksverslag' dan kan dat je wellicht al aardig op weg helpen

[Stephanvr]

Een scrum/agile methode wordt vaak toegepast op softwareontwikkeling om een project op te splitsen in kleine activiteiten (incrementen) en feedback op basis van iteraties (prototypes). Op deze manier kun je veranderingen in je requirements borgen. Hier heb jij dus vrijwel niets mee te maken? Toets gewoon wekelijks de voortgang bij je begeleider en houdt hem op de hoogte van verdere ontwikkelingen.

Het is overigens maar net wat je zoekt? Ben je op zoek naar een projectmatige aanpak (bijvoorbeeld prince2) of zoek je een inhoudelijke werkwijze (welke methoden kan ik toepassen om de vraag te beantwoorden?).

[Xanaroth]

Dit lijkt me typisch iets voor het begin van je stageverslag - de informatieverzameling. Dat gaat niet alleen om de gevens verzamelen, huidige status inventariseren, etc. Ook manieren waarop je je werk gaat doen of kunt uitvoeren uitzetten.

Daaronder valt dus ook het uitzoeken van verschillende methodieken. Zet ze vervolgens tegen elkaar uit, en haal daar 1 uit op baiss van pros/cons, wat telt zwaarder, waarom, welke ga je dus gebruiken, eventueel ook in overleg met je begeleider(s). Daar ga je vervolgens in je mee aan de gang, om toe te passen om de rest van de vergaarde informatie.

Daar kan dan iets uikomen van 'yay, conclusie'. Komt er niets uit, dan kun je aangeven toch andere methode te gaan gebruiken of anders bij tijdsgebrek aangeven 'resultaat onduidelijk, hier/daarom, adviseer nogmaals onderzoek te doen maar dan toch methode x te gebruiken om deze/deze reden'.
Een goed onderzoek opzetten betekend immers niet dat je het gewenste resultaat bereikt. Als alles goed aan te tonen en onderbouwt is, is dat geen enkel probleem in principe.


Niet knullig bedoeld, alleen dit is zegmaar HBO jaar 1 niveau, hoe doe je een onderzoek en maak je een verslag. Brainstormen, helikopterblik en dergelijke startpunten voor als je een analyses gaat doen. Zou je toch bekend mee moeten zijn als je aanbeland bent bij stageopdrachten (jaar 3?).
Dus wat ook best mogelijk is, is jezelf af te vragen of deze stage(opdracht) wel bij de studie cq jezelf past, of dat je iets anders moet zoeken.

[ Voor 45% gewijzigd door Xanaroth op 07-09-2016 13:19 ]

[Bossie]

Prima vraag voor je stagebegeleider, plan een afspraak met hem in en presenteer de opties met jouw feedback en ga dan de discussie met hem aan om de vervolgstappen te vast te zetten.

Pak je ook meteen deze stakeholder mee.

[Anoniem: 11193]

Iedereen stuurt je richting je stagebegeleider en je kunt daar natuurlijk niet met lege handen / zonder enkele voorstellen komen.

Zelf zou ik starten met het maken van een 'issue tree'. Omdat de vraag nog breed is zou ik als eerste niveau in je tree de 7S-en gebruiken.

Dit geeft je iets van structuur in je analyse. Zodra je beter zicht hebt op de problemen kun je altijd nog thema's schrappen.

Bij het bouwen van de tree is het concept MECE iets om in je achterhoofd te houden.

[ Voor 16% gewijzigd door Anoniem: 11193 op 07-09-2016 13:20 ]

[gangstahh]

Xanaroth schreef op woensdag 07 september 2016 @ 13:06:
Niet knullig bedoeld, alleen dit is zegmaar HBO jaar 1 niveau, hoe doe je een onderzoek en maak je een verslag. Zou je toch bekend mee moeten zijn als je aanbeland bent bij stageopdrachten. Zo niet, dan moet je je afvragen of deze stage(opdracht) wel je studie past, en als dat het geval is of dat dan wel bij jou past.

Deze stage is voor mij een nieuwe uitdaging, nml doen we soortgelijke opdrachten in project verband (meerdere mensen) met een casus (veel al klein). Ik weet prima hoe je een verslag/rapport opstelt, alleen zoals eerder gezegd zou ik graag wat advies willen op de benaderingswijze/methodiek.

[Xanaroth]

gangstahh schreef op woensdag 07 september 2016 @ 13:19:
[...]


Deze stage is voor mij een nieuwe uitdaging, nml doen we soortgelijke opdrachten in project verband (meerdere mensen) met een casus (veel al klein). Ik weet prima hoe je een verslag/rapport opstelt, alleen zoals eerder gezegd zou ik graag wat advies willen op de benaderingswijze/methodiek.

Als je de gebruikelijke benadering volgt, kom je vanzelf bij onderzoeksmethodes uit. Dus dan ga je vooronderzoek doen naar zaken die je al kent (scrum, waterval) en onbekende die je met google op pagina 1 gelijk al vindt (https://www.google.nl/web...ethodes+verbeteren+proces). Zo kom je dan binnen 2-3 minuten al uit op 6 verschillende invalshoeken en bijbehorende methodes

Dan kom je dus gelijk aan bij dat keuze en combinatie van methode en invalshoek waarop je die toepast onder andere afhangt van je focuspunt - snelheid, kwaliteit, productiviteit (=kosten). Daarmee kom je dan ook bij de befaamde 3-hoeksverhouding van prijs/kwaliteit/snelheid als er geen externe invloeden zijn.
Daarmee kun je checken of een verbetering ook echt beter is, of dat slechts het probleem verplaatst.


Dus uit je vooronderzoek rond het (1) bedrijf, (2) de afdeling, (3) bedrijfsprocessen, (4) interviews en de opdrachtomschrijving op de stage zal dus naar voren moeten komen op welk punt ze willen dat jij een analyse en verbetervoorstel maakt. Deze (5) methodieken en (6) invalshoeken combineer je vervolgens tot je eigen plan om hoe je de opdracht gaat tackelen. Dit kunnen dus ook meerdere stappen zijn - je hoeft niet per se 'maar' 1 methode en invalshoek te hebben, je kan prima 1 methode op meerdere manieren toepassen of combinaties/permutaties maken die volgens de analyse het meeste geschikt zijn.

Vergeet ook niet dat prestatie indicatoren ook onderdeel zijn van 1-3, zoals balance score cards, kpi's, of andere kwaliteitssystemen. Want oorzaak/gevolg is daar nogal een grijs gebied - soms wordt het werk zelf daardoor juist negatief beïnvloed 'want groen managen'. Datzelfde geld bijvoorbeeld voor de stakeholders/eindverantwoordelijken, die een andere agenda kunnen hebben dan de afdeling zelf.


Dat was de eerste brainstomsessie voor het initiele raamwerk rond hoofdstuk 1 van je verslag, secties 1-6. Zonder enige kennis en 2 minuten googlen. Initiele raamwerk en brainstormen voor hoofdstuk 2/3/4 mag je zelf opzetten en dan zelf het detail onderzoek doen

[ Voor 47% gewijzigd door Xanaroth op 07-09-2016 13:51 ]

[Brambulance2]

Vergeet niet dat je onderzoeksmethodiek ook afhankelijk kan zijn van de informatie die je in eerste instantie verzameld en je misschien zelfs verschillende moet gebruiken voor verschillende problemen. Ik zou je aanraden om in ieder geval eerst een compleet overzicht van het bedrijf te maken in flow chart van begin tot einde. Dit geeft je ook zelf inzicht in hoe het bedrijf werkt en waar geld wordt verdiend (en waar niet).

[gangstahh]

Anoniem: 11193 schreef op woensdag 07 september 2016 @ 13:19:
Iedereen stuurt je richting je stagebegeleider en je kunt daar natuurlijk niet met lege handen / zonder enkele voorstellen komen.

Zelf zou ik starten met het maken van een 'issue tree'. Omdat de vraag nog breed is zou ik als eerste niveau in je tree de 7S-en gebruiken.

Dit geeft je iets van structuur in je analyse. Zodra je beter zicht hebt op de problemen kun je altijd nog thema's schrappen.

Bij het bouwen van de tree is het concept MECE iets om in je achterhoofd te houden.

Bedankt voor deze tip, het 7S-model kende ik nog niet, heb het snel doorgenomen en is zeker relevant!

[Wicked-Game]

Iedereen roept hier nogal veel over methodieken, maar uit ervaring in PM kan ik je zeggen dat geen enkele methodiek volledig heilig is.

Als eerste zal er onderzoek gedaan moet worden naar het soort bedrijf waarin jij je begeeft. Wie zijn de stakeholders, decision makers, uitvoerders etc. Hier kan een organogram je eventueel helpen om dit te bepalen. Toch blijkt in de praktijk dat er stakeholders zijn, die niet in het organogram kunnen voorkomen.

Wanneer je dit duidelijk hebt ga je met de stakeholders en/of decisionmakers om de tafel zitten om de processen te analyseren zoals deze er nu liggen. (Lean Six Sigma variant kan een vorm zijn die je kan volgen) Hier kom je in de volgende stappen terecht:

- Define
- Measure
- Analyze
- Improve
- Controle

Maar er zijn legio andere methodieken op procesverbeteringen die je kan volgen (al hier genoemd). Elk stap kan je weer methodieken voor gebruiken. 7-S model is hierboven al benoemd voor analyse doeleinden.

[gangstahh]

Xanaroth schreef op woensdag 07 september 2016 @ 13:27:
[...]


Als je de gebruikelijke benadering volgt, kom je vanzelf bij onderzoeksmethodes uit. Dus dan ga je vooronderzoek doen naar zaken die je al kent (scrum, waterval) en onbekende die je met google op pagina 1 gelijk al vindt (https://www.google.nl/web...ethodes+verbeteren+proces). Zo kom je dan binnen 2-3 minuten al uit op 6 verschillende invalshoeken en bijbehorende methodes

Dan kom je dus gelijk aan bij dat keuze voor methode (zoals lean, six sigma, TPM) en manier waarop je die toepost onder andere afhangt van je focuspunt snelheid, kwaliteit, productiviteit (=kosten). En daarmee bij de befaamde 3-hoeksverhouding van prijs/kwaliteit/snelheid.


Dus uit je vooronderzoek rond het (1) bedrijf, (2) de afdeling, (3) bedrijfsprocessen, (4) interviews en de opdrachtomschrijving op de stage zal dus naar voren moeten komen op welk punt ze willen dat jij een analyse en verbetervoorstel maakt. Deze (5) methodieken en (6) invalshoeken combineer je vervolgens tot je eigen plan om hoe je de opdracht gaat tackelen. Dit kunnen dus ook meerdere stappen zijn - je hoeft niet per se 'maar' 1 methode en invalshoek te hebben, je kan prima 1 methode op meerdere manieren toepassen of combinaties/permutaties maken die volgens de analyse het meeste geschikt zijn.

Vergeet ook niet dat prestatie indicatoren ook onderdeel zijn van 1-3, zoals balance score cards, kpi's, of andere kwaliteitssystemen. Want oorzaak/gevolg is daar nogal een grijs gebied - soms wordt het werk zelf daardoor juist negatief beïnvloed 'want groen managen'.


Dat was de eerste brainstomsessie voor het initiele raamwerk rond hoofdstuk 1 van je verslag, secties 1-6. Zonder enige kennis en 2 minuten googlen. Initiele raamwerk en brainstormen voor hoofdstuk 2/3/4 mag je zelf opzetten en dan zelf het detail onderzoek doen

Ik vraag ook alleen maar om advies, wat hier de kijk is op deze kwestie. In het verleden heb ik soortgelijke projecten gehad alleen had dit veel al met software te maken (implementatie van nieuwe functionaliteit). Dit project is nieuw voor mij, dit is volledig gericht op onderzoek dus zonder enige implementatie (alleen een advies, de implementatie is niet aan mij). De vestigingsleider zegt ook dat het bij de medewerkers ligt, de handelingen die ze uitvoeren. Het zijn steekjes die ze loslaten, maar waar is onduidelijk. Dat is aan mij

[gangstahh]

Wicked-Game schreef op woensdag 07 september 2016 @ 13:38:
Iedereen roept hier nogal veel over methodieken, maar uit ervaring in PM kan ik je zeggen dat geen enkele methodiek volledig heilig is.

Als eerste zal er onderzoek gedaan moet worden naar het soort bedrijf waarin jij je begeeft. Wie zijn de stakeholders, decision makers, uitvoerders etc. Hier kan een organogram je eventueel helpen om dit te bepalen. Toch blijkt in de praktijk dat er stakeholders zijn, die niet in het organogram kunnen voorkomen.

Wanneer je dit duidelijk hebt ga je met de stakeholders en/of decisionmakers om de tafel zitten om de processen te analyseren zoals deze er nu liggen. (Lean Six Sigma variant kan een vorm zijn die je kan volgen) Hier kom je in de volgende stappen terecht:

- Define
- Measure
- Analyze
- Improve
- Controle

Maar er zijn legio andere methodieken op procesverbeteringen die je kan volgen (al hier genoemd). Elk stap kan je weer methodieken voor gebruiken. 7-S model is hierboven al benoemd voor analyse doeleinden.

Bedankt

[Xanaroth]

gangstahh schreef op woensdag 07 september 2016 @ 13:49:
[...]


Ik vraag ook alleen maar om advies, wat hier de kijk is op deze kwestie. In het verleden heb ik soortgelijke projecten gehad alleen had dit veel al met software te maken (implementatie van nieuwe functionaliteit). Dit project is nieuw voor mij, dit is volledig gericht op onderzoek dus zonder enige implementatie (alleen een advies, de implementatie is niet aan mij). De vestigingsleider zegt ook dat het bij de medewerkers ligt, de handelingen die ze uitvoeren. Het zijn steekjes die ze loslaten, maar waar is onduidelijk. Dat is aan mij

Wat je doet of deed is geheel irrelevant!
Of je nou iets implementeert, ontwikkeld, analyseert, verbeterd - je zult altijd in een onderzoek dezelfde stappen doorlopen.

Het verzamelen van informatie, methodes bekijken om je probleem aan te pakken, combineren tot een overwogen 1e keuze en dan gaan. Als je tegen iets aanloopt in negatieve zin ga je terug naar je plan en kijk je wat er anders moet op basis van je nieuwe gegevens (andere methodiek, invalshoek, wat dan ook) en doe je het opnieuw. Als je tegen iets aanloopt in positieve zin doe je een check/test om je gegevens te bevestigen en ga je met dat resultaat aan de slag om vertaling naar de praktijk op te zetten.
Er is een reden dat je meestal begint met een pre-verslag, een plan van aanpak, waarin je eigenlijk de methode opzet om je project aan te sturen (het project, waarin je vervolgens een methodiek kiest gericht op de opdracht cq onderzoeksvraag).

Dat kun je toepassen op de ontwikkeling/verbetering van software, het bouwen van machines, processtromen op een afdeling of zelfs je eigen huishoudboekje thuis. Inventariseren, analyseren, combineren, verwerken, conclusie. Elke keer weer.
Pak 'software programma' als dataverwerker en verander dat naar 'afdeling' als dataverwerker, verander vervolgens de input 'bestand x' (of informatie x) naar stakeholder 'persoon x' (of beslissing x).
Pak 'boodschappen' als kosten en verandert dat naar 'product' als kosten, waarbij afhankelijkheid en variabele post 'seizoensgroentes' verandert wordt in afhankelijkheid en variabele post 'metaal'. Context is binnen methodieken slechts een woordje om een status te verhelderen, maar dat verandert de manier hoe je een status ziet of verwerkt niet.

Op het meest basis niveau, is er geen verschil in processtromen. Die zien geen verschil tussen in welke sector je werkt of wat je doet. Zoals jij denkt in context ben je eigenlijk al bezig met verwerken (hoe doe ik dit) en sla je de eerste cruciale stappen over.


Mooi voorbeeld stip je gelijk aan, namelijk de input dat het bij de medewerkers ligt die steekjes laten vallen. Alsof, terug naar jouw software context, iemand je zegt dat je niet naar een bestand x hoeft te kijken bij het zoeken naar een probleem, want daar ligt het zowiezo niet aan. In die context krijg je waarschijnlijk gelijk kriebels, en staat dat bestand gelijk bovenaan je lijst van degene die het probleem veroorzaakt.

Is er dan al onderzoek geweest om management(-keuzes) uit te sluiten? Of inrichting van het bedrijf(sproces)? Of aan gebrek aan tijd (mankracht)? Of personeelsbeleid (aanname personeel, vergoedingen..)?
Allemaal zaken die bij de baas liggen, niet de werknemers zelf waar de vinger nu zo snel naar wijst.

Het lijkt een kleine opmerking, maar als je het uitrolt eentje waarmee ineens een significant deel per direct wordt uitgesloten. Je begint dan namelijk met het uitsluiten van enkele enorme factoren zonder onderbouwing. Natuurlijk kun je in een stage er niet zo diep op in gaan, nogmaals, punt wat ik vooral erin probeer te hameren is dat je beter even een paar stappen terug kunt doen. Begin eens met dat vooronderzoek te doen.

[ Voor 66% gewijzigd door Xanaroth op 07-09-2016 14:37 ]

[Krisp]

Sowieso zul je hier iteratief moeten werken (versies van je analyse, oplossingsvoorstellen, etc). Scrum is een vorm van iteratief werken voor teams. Aangezien je deze opdracht alleen doet, is een lichtgewicht versie van Scrum, waarbij je het meer gebruikt als planning voor tussenproducten over het algemeen prettig. Verder wil je in dit soort projecten technieken als root cause analysis toepassen.

[gangstahh]

Xanaroth schreef op woensdag 07 september 2016 @ 13:56:
[...]


Wat je doet of deed is geheel irrelevant!
Of je nou iets implementeert, ontwikkeld, analyseert, verbeterd - je zult altijd in een onderzoek dezelfde stappen doorlopen.

Het verzamelen van informatie, methodes bekijken om je probleem aan te pakken, combineren tot een overwogen 1e keuze en dan gaan. Als je tegen iets aanloopt in negatieve zin ga je terug naar je plan en kijk je wat er anders moet op basis van je nieuwe gegevens (andere methodiek, invalshoek, wat dan ook) en doe je het opnieuw. Als je tegen iets aanloopt in positieve zin doe je een check/test om je gegevens te bevestigen en ga je met dat resultaat aan de slag om vertaling naar de praktijk op te zetten.
Er is een reden dat je meestal begint met een pre-verslag, een plan van aanpak, waarin je eigenlijk de methode opzet om je project aan te sturen (het project, waarin je vervolgens een methodiek kiest gericht op de opdracht cq onderzoeksvraag).

Dat kun je toepassen op de ontwikkeling/verbetering van software, het bouwen van machines, processtromen op een afdeling of zelfs je eigen huishoudboekje thuis. Inventariseren, analyseren, combineren, verwerken, conclusie. Elke keer weer.
Pak 'software programma' als dataverwerker en verander dat naar 'afdeling' als dataverwerker, verander vervolgens de input 'bestand x' (of informatie x) naar stakeholder 'persoon x' (of beslissing x).
Pak 'boodschappen' als kosten en verandert dat naar 'product' als kosten, waarbij afhankelijkheid en variabele post 'seizoensgroentes' verandert wordt in afhankelijkheid en variabele post 'metaal'. Context is binnen methodieken slechts een woordje om een status te verhelderen, maar dat verandert de manier hoe je een status ziet of verwerkt niet.

Op het meest basis niveau, is er geen verschil in processtromen. Die zien geen verschil tussen in welke sector je werkt of wat je doet. Zoals jij denkt in context ben je eigenlijk al bezig met verwerken (hoe doe ik dit) en sla je de eerste cruciale stappen over.


Mooi voorbeeld stip je gelijk aan, namelijk de input dat het bij de medewerkers ligt die steekjes laten vallen. Alsof, terug naar jouw software context, iemand je zegt dat je niet naar een bestand x hoeft te kijken bij het zoeken naar een probleem, want daar ligt het zowiezo niet aan. In die context krijg je waarschijnlijk gelijk kriebels, en staat dat bestand gelijk bovenaan je lijst van degene die het probleem veroorzaakt.

Is er dan al onderzoek geweest om management(-keuzes) uit te sluiten? Of inrichting van het bedrijf(sproces)? Of aan gebrek aan tijd (mankracht)? Of personeelsbeleid (aanname personeel, vergoedingen..)?
Allemaal zaken die bij de baas liggen, niet de werknemers zelf waar de vinger nu zo snel naar wijst.

Het lijkt een kleine opmerking, maar als je het uitrolt eentje waarmee ineens een significant deel per direct wordt uitgesloten. Je begint dan namelijk met het uitsluiten van enkele enorme factoren zonder onderbouwing. Natuurlijk kun je in een stage er niet zo diep op in gaan, nogmaals, punt wat ik vooral erin probeer te hameren is dat je beter even een paar stappen terug kunt doen. Begin eens met dat vooronderzoek te doen.

Heel erg bedankt voor je uitgebreide onderbouwing, ik snap nu pas wat je bedoelt. De structuur van het bedrijf heb ik al aardig in kaart (organogram), ik moet inderdaad nog wel uitzoeken welk proces waar zit etc...

Opzich is het een hele klus voor een stage van 10 week, ondanks dat probeer ik het wel zo goed en volledig mogelijk te doen.

Ik kom hier immers om te leren en hier (deze kwestie) leer ik ook weer van, thanks!

[Xanaroth]

gangstahh schreef op woensdag 07 september 2016 @ 15:31:
[...]


Heel erg bedankt voor je uitgebreide onderbouwing, ik snap nu pas wat je bedoelt. De structuur van het bedrijf heb ik al aardig in kaart (organogram), ik moet inderdaad nog wel uitzoeken welk proces waar zit etc...

Opzich is het een hele klus voor een stage van 10 week, ondanks dat probeer ik het wel zo goed en volledig mogelijk te doen.

Ik kom hier immers om te leren en hier (deze kwestie) leer ik ook weer van, thanks!

Onthoud dat conclusies en gewenst resultaat 2 verschillende dingen zijn.

Resultaat van je eerste scan (plan van aanpak) rond het project kan prima zijn, dat het project te groot is geacht wordt voor de periode van 10 weken. Immers 1-2 weken vooronderzoek/brainstorm/plan van aanpak en onderzoeksopzet, dan aan de slag voor 6 weken volgens je plan (i.e. stap 1, organogram opstellen) en vervolgens nog 1-2 weken verslag maken en presenteren.
Gevolg kan dan zijn dat je, in overleg natuurlijk, bijvoorbeeld in week 2 met je plan van aanpak overeenstemming bereikt enkel het raamwerk op zet. Dus inventarisatie stap + aanbeveling op welke methode(s) het bedrijf doorgelicht moet worden.
Zodoende volgt dan een conclusie/aanbeveling wederom dat het een zeer omvattend project is, en je adviseert om met andere stagiares het project voort te zetten en op basis van jouw gegevens verder kunnen gaan. Jouw project wordt zodoende weer hun plan van aanpak.

De volgende stagiare krijgt dan jouw plan van aanpak te lezen en je uiteindelijke rapport, met onderzoeksopdracht 'ga afdeling x doorspitten volgens de aanbevolen methode'. Die heeft dan natuurlijk als plan van aanpak om onder andere je verslag te bekijken of alles actueel is en ze achter dezelfde aanbevolen methodiek staan, en dan vervolgens de draad verder oppakken.


Alternatief kan ook zijn dat, als het project te groot is, na je plan van aanpak er overleg is en besloten wordt plan van aanpak te herzien en dan bewust de scope extreem in te perken tot 1 specifiek proces van 1 specifieke afdeling. Wederom kun je dan mooi aanbevelen dat er vervolg wordt ingezet om andere afdelingen/processen door te laten lichten door volgende stagiares.

[ Voor 25% gewijzigd door Xanaroth op 07-09-2016 15:46 ]

[Navi]

Hoop theoretisch geneuzel allemaal hier, even een andere aanpak, werk gewoon 9 weken mee op die afdeling en schijf in week 10 op wat er beter kan

Ja ik ben een man van de praktijk > theorie

PS: In je sig staat "Buisness IT and Management", bewust of een typo?

[xtaix]

Moet je het met theorie onderbouwen? Een theoretisch kader bijvoorbeeld?

Ik zou een audit uitvoeren en eerst eens analyseren hoe de organisatie/afdeling in elkaar zit met 7s model van McKinsey.

Vervolgens bepalen wat een goed goed framework/model is om toe te passen voor je onderzoek? Is het INK-model geen optie?

[Pizza_Boom]

Even een tipje van mij, wellicht overvloedig en niet geheel ter zaken doende in dit topic, maar doe al je communicatie zwart op wit. Zorg ervoor dat je alle toestemmingen/adviezen vanuit je schoolbegeleider per email krijgt. Heb je wat besproken, notuleren en mailen en vragen om akkoord. Regelmatig (iedere paar weken) voortgang tonen. Ook goed contact houden met je bedrijfsbegeleider, vragen hoe en wat en die input waar mogelijk verwerken.

Het is heel kinderachtig ja, maar mijn ervaring is dat het nodig is. Bij mijn eerste afstudeerstage: dag 1 op school, om de opdracht goed te laten keuren: "Bedrijf wil naar oplossing in de richting x, want budget, bruikbaarheid, uitwisselbaarheid, etc, maar daar heb ik nog geen ervaring mee." Antwoord schoolbegeleider: "Dan is het zaak aan jou die programmeertaal te leren." Concept bespreken: "Alles ziet er goed uit, goede diepgang, goed onderzoek, goede onderbouwing, lekker breed, veel belovend." Paar puntjes over onderzoeksvragen die niet in dezelfde volgorde opgesomd waren als dat ze behandeld werden, blabla, maar wel een go om te gaan verdedigen. Afstudeerverdediging: "Ja, we vinden oplossing x teveel naar hobby neigen, dat wordt niet gebruikt in een professionele omgeving. Verder vinden we het onderzoek niet goed."

Ik had niet veel zwart op wit, want ja, goed vertrouwen, als je schoolbegeleider zegt dat het er goed uit ziet, met wat kleine puntjes komt en je daadwerkelijk toestemming geeft te gaan verdedigen, dan zal het wel goed zijn toch?

Na de verbeterperiode kwam men weer met hele andere zaken en kwam het er dus op neer dat ik op dat moment dus inmiddels een driekwart jaar bezig was geweest voor de kat zijn viool. En uiteraard, ik zal zelf ook fouten gemaakt hebben, ik ben ook niet perfect, maar als begeleiding aan geeft dat het voldoende is tijdens het traject, dan vaar ik daar min of meer blind op. Jammer dat ik daar geen bewijzen van had.

[ Voor 12% gewijzigd door Pizza_Boom op 10-09-2016 21:40 ]

[Skimovic]

gangstahh schreef op woensdag 07 september 2016 @ 12:14:
Beste mede Tweakers,

Onlangs ben ik begonnen aan een stage, mijn opdracht is om een afdeling volledig te analyseren (wat gaat er precies fout, waarom etc.…). Je kan wel zeggen een zeer uitdagende opdracht alleen zit ik momenteel vast op de methodiek die ik wil toepassen. Ik ben zelf gewend om met Scrum of Waterval te werken maar dit past naar mijn idee niet helemaal binnen dit project. Het is niet een implementatie van software maar puur informeren, analyseren en het schrijven van een passend advies.

Uiteraard heb ik ook het een en ander gegoogeld maar ben er niet wijzer van geworden. Wellicht heeft iemand van jullie ervaring met een soortgelijk project en mij kan helpen met deze kwestie.

Met vriendelijke groet,
Patryk

Niet om lullig te doen maar is het hele idee van een stage niet dat je je opgedane kennis toepast en zo aan kan tonen dit in de praktijk zelfstandig toe te kunnen passen?

Dat je nu niet weet hoe je dit aan moet pakken betekend eigenlijk dat je misschien op voorhand al een onvoldoende zou moeten krijgen. Als ik het topic zo lees kan je de opdracht eigenlijk gewoon niet aan.

Hoe wil je een serieus advies geven als je zelf niet weet hoe je dit aan moet pakken en van google niet wijzer kan worden? Hoop dat ze dat advies niet al te serieus nemen dan..

Toevallig Avans HBO? die hebben hier nogal een handje van.. Komt er nu nogal bot uit maar kan me hier enorm aan ergeren.

Constructief: begin met een leeg blad en loop eerst eens 2 weken gewoon mee, constateer welke problemen er in praktijk zijn en begin dan pas een je methodiek. Durf dat ook gewoon zo te stellen tov je begeleider.

Er is een heel groot verschil tussen school en praktijk.

[ Voor 21% gewijzigd door Skimovic op 10-09-2016 23:12 ]

[donleone83]

Okee wacht. Nog een stapje terug. Je wordt gevraagd om een onderzoek te doen naar wat er beter kan op een hele afdeling van 35 man in een HBO stage van 10 weken waarbij de bedrijfsleider al zegt dat het bij de medewerkers ligt?

Dat is hoe dan ook recipe for disaster. Je moet 'onderzoek' doen maar er is geen afgekaderde onderzoeksvraag. Er wordt een advies verwacht over waar het fout gaat terwijl je amper kans hebt het bedrijf goed te leren kennen en zo te lezen kom je ook nog in een politiek moeilijke situatie terecht. Heeft het bedrijf bijvoorbeeld een productieproces? Zo ja: dan kan je in 10 weken nooit opleveren.

Mijn advies zou zijn om focus aan te brengen in de opdracht, bijvoorveeld door te onderzoeken hoe het bedrijf slim kan besparen door IT als enabler neer te zetten, of hoe je samen met de supply chain een bepaald proces beter kan laten verlopen.

Ze verwachten een strategy consulting advies van een niet afgestudeerde HBO-er. Volstrekt onrealistisch met een veel te vage opdracht. Waarbij de manager al zegt dat het aan kleine foutjes van mensen ligt (echt al mijn alarmbellen gaan af hier). Klinkt misschien spannend (en zo te lezen ben je hartstikke trots op je gave opdracht) maar denk 100x na voordat je hier zomaar aan begint zonder duidelijke focus. Anders krijgen we hier over een paar maanden topic nummer zoveel over een conflict met de school/stageklant en niet mogen afstuderen.

[St@m]

gangstahh schreef op woensdag 07 september 2016 @ 12:37:
[...]

Ik studeer Business IT & Managemet.

Het doel van mijn stage is om uiteindelijk met een passend advies te komen waardoor zij efficiënter kunnen gaan werken, waardoor er dus minder tijd verloren gaat aan kleine foutjes en waardoor er dus meer verdiend gaat worden. Mijn taak is dus een volledige analyse van het bedrijf (35 man).

En ja het met een Y, thanks

Lean Six Sigma dus (in ieder geval een gedeelte), begin maar eens met een brown paper en ga het proces analyseren samen met de betrokkenen.
Zorg ervoor dat je uiteindelijk niet zelf verbeteringen gaat bedenken, maar laat de mensen die werken met het proces de verbeteringen zelf bedenken. Zo creëer je een groter draagvlak en gaan ze er waarschijnlijk zelf nog iets aan hebben ook.

Op het moment dat je de input hebt van de brown paper weet je precies hoe het proces loopt, waar dingen fout gaan en kun je daarop gaan sturen.

http://www.lean-improvers.nl/diensten/brown-paper/

Super leuk om te doen, vrij simpel ook.
Zodra het proces in kaart is ga je alle geeltjes langs. Stel de medewerkers de vraag hoe vaak een processtap goed gaat (in procenten). Een stap kan bijvoorbeeld zijn dat er iets ingevoerd moet worden in het systeem.
Stel de vraag: Hoe vaak gaat dat goed?
Als het antwoord is 50% van de tijd, dan weet je dat je daar al een huge probleem te pakken hebt.
Ga doorvragen, 5x waarom.
https://qualitybs.wordpre.../03/waarom-5-keer-waarom/

De manager kan wel zeggen dat het aan de medewerkers ligt die steekjes laten vallen, maar waarom is dat?
Waarom wordt de informatie niet goed in het systeem gezet?
- Omdat het systeem onduidelijk is
Waarom is het systeem onduidelijk?
- Omdat het niet aansluit bij wat we precies doen en we sommige dingen anders in moeten vullen dan het systeem zegt
Waarom sluit het systeem niet aan?
- Omdat we hetzelfde systeem als vroeger gebruikten, maar onze diensten zijn heel anders tegenwoordig

(en daar heb je wellicht je oorzaak)

Even zo uit de losse pols

Doe dit bij iedere processtap, laat medewerkers zelf bedenken hoe dingen beter kunnen. Werk dit uit in een rapport, ga hiermee naar je begeleider. Hoogstwaarschijnlijk heb je dan al je voldoende te pakken
Rest van je tijd kun je bezig gaan met het implementeren van eventuele verbeteringen.

Zo zijn er natuurlijk wel meer methodieken die je kunt toepassen. Hierboven ook al wel genoemd. Voordeel van hierboven is dat het redelijk recht toe recht aan is. Je kunt het niet fout doen, de input komt namelijk van de medewerkers op een heel directe manier. Let wel, als je verschillende medewerkers gaat vragen "waarom" heb je best kans dat er meerdere antwoorden uitkomen. Je moet goed kijken welke antwoorden daadwerkelijk relevant zijn.

En mocht je ook nog budget hebben kun je ook eens kijken naar een serious business game die gericht is op het verbeteren van processen, zoals bijvoorbeeld CarWorks:
http://happycustomers.nl/carworks/

[ Voor 60% gewijzigd door St@m op 11-09-2016 08:57 ]

[GoldenSample]

Navi schreef op woensdag 07 september 2016 @ 17:42:
Hoop theoretisch geneuzel allemaal hier, even een andere aanpak, werk gewoon 9 weken mee op die afdeling en schijf in week 10 op wat er beter kan

Ja ik ben een man van de praktijk > theorie

PS: In je sig staat "Buisness IT and Management", bewust of een typo?

Tja als je op een bepaald moment eenniets andere functie wilt hebben dan 'meewerkend voorman' dan is dit de manier om te zorgen dat je daar pas over een jaar of 100 komt. Nofi maar dan werk je op een ander niveau.

Geld voor TS ook trouwens, als je 1.5 bekende project organisatie (waarvan scrum eigenlijk heel eenzijdig op het uitvoerende zit) methodieken niet op een onderzoek, analyse en advies project toepasbaar blijken gaan roepen naar hulp zonder andere methodes zrlf bestudeerd, gezocht etc. Te hebben... Tja dan zie ik het somber voor je in. Dus TS, op eigen onderzoek uit, Pro actief zoeken en pas vragen als je zelf onderzoek naar methoden gedaan hebt.

Van z'n houding bij een 3e jaars HBO-er schik ik dan een beetje en gaat het potlood al aardig richting het vakje 'ongeschrikt'. Zie ik wel vaker overigens (zeker in de IT), veel zwart wit denken en wat stuurloos als het grijs blijkt. Ook met project management methoden, denk dat de liefde voor scrum ook voortkomt uit het feit dat het zo voorschrijvend is (doe dit doe dat doe zus doe zo), lijkt lekker weinig grijs te hebben. Iets wat gelijk de 1-na grootste zwakte van scrum is imho.

en ja z'n methode (zeker de betere niet voorschrijvende methodes) is een handvat geen alles zeggende tool die je altijd 1 op 1 volgen kan.

[ Voor 16% gewijzigd door GoldenSample op 11-09-2016 12:47 ]

[gangstahh]

Skimovic schreef op zaterdag 10 september 2016 @ 22:51:
[...]


Niet om lullig te doen maar is het hele idee van een stage niet dat je je opgedane kennis toepast en zo aan kan tonen dit in de praktijk zelfstandig toe te kunnen passen?

Dat je nu niet weet hoe je dit aan moet pakken betekend eigenlijk dat je misschien op voorhand al een onvoldoende zou moeten krijgen. Als ik het topic zo lees kan je de opdracht eigenlijk gewoon niet aan.

Hoe wil je een serieus advies geven als je zelf niet weet hoe je dit aan moet pakken en van google niet wijzer kan worden? Hoop dat ze dat advies niet al te serieus nemen dan..

Toevallig Avans HBO? die hebben hier nogal een handje van.. Komt er nu nogal bot uit maar kan me hier enorm aan ergeren.

Constructief: begin met een leeg blad en loop eerst eens 2 weken gewoon mee, constateer welke problemen er in praktijk zijn en begin dan pas een je methodiek. Durf dat ook gewoon zo te stellen tov je begeleider.

Er is een heel groot verschil tussen school en praktijk.

Ik heb vanuit de opleiding soortgelijke opdrachten uitgevoerd, alleen was dit veelal implementatie van software of het oplossen van bepaalde bug's. Nu is het de bedoeling dat ik zelf achter de problemen kom door het winnen van informatie, nml krijgen wij een casus voorgeschoteld waar je alles uit haalt.

Heb het er met mn opdrachtgever overgehad en het advies moet Lean zijn. Maar de methodiek rondom de analyse moet kwalitatief zijn. Dit was ook min of meer het antwoord waar ik naar op zoek was.

Tevens is het zo dat ik maar 1 afdeling ondermijn hoede neem, afdeling waar 7 medewerkers werkzaam zijn. Het gaat mij er vooral om dat ik er wat van opsteek, uiteraard wil ik een passend advies geven maar het is belangrijk dat ook ik zelf zie waar ik zoal tegen aan loop en wat ik in de toekomst zelf beter kan doen bij een soortgelijke opdracht. (bijvoorbeeld nu al; het doen van meer research)

[ Voor 11% gewijzigd door gangstahh op 12-09-2016 10:15 ]

[heintjeput]

Het klinkt mij alsof er nog helemaal geen registratie is van de zaken die er fout gaan. Wil je iets van een kwalitatief advies kunnen geven is dit het eerste wat je op moet gaan zetten.

Afhankelijk van het type mensen waar je mee werkt zou je bijv. een excellijst op kunnen stellen met een aantal categorieën wat er fout gaat, hoeveel tijd dit kost etc. Het zal niet direct perfect, maar hoe eerder je begint hoe meer data je kunt verzamelen en des te sneller je conclusies kunt trekken.

Probeer de afdelingen wel mee te nemen in het hoe en waarom dat je dat gaat doen. Er zullen sowieso mensen zijn die er meer / minder aan mee willen doen, maar mensen tegen je hebben is helemaal verkeerd.

Als je wat meer bekend bent met Lean zou je ook bijvoorbeeld Kaizen toe kunnen passen om de 'overduidelijke' dingen die 'altijd' fout gaan aan te proberen pakken. Ik denk dat op een avondje Lean for dummies of Lean Six Sigma for dummies niet verkeerd is voor zo'n probleem.