Innovatie scan

[Willem Super]

Stel je hebt een product en je wilt een nieuwe verbeterde versie gaan ontwerpen. Hoe bepaal je dan in een paar overzichtelijke stappen welke aspecten van het product verbeterd moeten worden. Gebruik van een QFD klinkt aannemelijk maar deze tool is eigenlijk te abstract om een handig hulpmiddel te zijn.

 

Voor mezelf heb ik een methode ontwikkeld, de innovatie scan, die de bestaande marketing en technische product know-how systematisch in kaart brengt. Het bestaande product wordt op verschillende manieren gescanned en beoordeeld waardoor veel beter duidelijk wordt op welke aspecten het product juist goed scoort en waar lacunes zitten in het ontwerp. Gebruik van bestaande inzicht, kennis en technieken geeft innovatie richting en focuspunten.

 

De innovatie scan kan worden toegepast op producten, processen en op bedrijven. Samen met geïnteresseerde bedrijven zou ik graag een aantal praktijk test-cases willen definiëren voor uiteenlopende producten of processen om mijn methode te optimaliseren. Is daar interesse voor?

[Nico Schouten]

Is dit een oproep of wil je over jouw methode discussieren op dit forum ?

 

Het klinkt trouwens als TRIZ, ook een methode om innovatie te kunnen genereren.

[Willem Super]

De innovatie scan bevat delen van TRIZ en DFSS. Zonder dat ik gelijk wil verklappen hoe de methode precies werkt wil ik wel graag discussiëren over de waarde van de tool, mogelijke toepassingen en misschien komen gebreken aan het licht.

[Nico Schouten]

Hoe wil je het praktisch aanpakken ?

We kunnen op het forum gaan discussieren over jouw tool maar dat lijk tme zinloos als we de tool zelf niet op een of andere manier kunnen evalueren. Misschien wil je een topje van de sluier oplichten door te vertellen waar jouw tool een methode als TRIZ verslaat. Of misschien aan de hand van een voorbeeld hoe je met jouw methode oplossingen vind die bij TRIZ uitblijven.

[Willem Super]

De scan is slechts de eerste stap en zeker geen vervanging van TRIZ. De eerste stap van TRIZ is dat je een probleem (of contradictie) zoekt die je wilt gaan oplossen. Een willekeurig probleem vinden en oplossen lijkt vrij eenvoudig. Het is echter maar de vraag of de innovatie kracht optimaal benut is. Sommige problemen zijn duidelijk herkenbaar, anderen zijn minder duidelijk zichtbaar maar wel degelijk bepalend voor het succes van een product. Ook kan het zo zijn dat bepaalde aspecten een probleem lijken (zoals een hoge kostprijs) maar dat het werkelijke probleem ergens anders ligt.

 

Ik vraag me af of mensen geïnteresseerd zijn in een scan die aangeeft waar het product verbeterd moet worden. Vooral als het product wat gecompliceerder wordt kun je tientallen kanten op. Moeilijkheid is dat je bepaalde aspecten niet mag vergeten. Moeilijkheid is dat iedere richting tijd en energie kost en dat je slecht kunt inschatten welke richting de juiste is, waardoor je soms een paar keer moet itereren.

 

Is dit een herkenbaar iets?

[DunneSloeber]

Ik vind dat je de termen aspect, quality op een manier gebruikt waarbij ik niet de indruk heb dat het effectief is. Waarom zou ik een probleem oplossen als ik eerst niet aan de hand van de structuur van mijn aspecten en gerelateerde qualiteiten weet wat de basis is van mijn object dat de function kan implementeren? Het probleem hoeft toch niet te passen in het meest efficiënte pad der oplossing. Iets is om te beginnen efficiënt als het effectief is. Hoe efficiënt is vraag twee. En wat is het doel?

 

Als wij geen inzicht hebben in de objecten en subjecten van hetgeen je voorstelt blijft het toch een beetje hangen in de dunne sloeber van de intellectuele twilight zone . Daar geef ik Nico gelijk in.

[Willem Super]

Waarom zou ik een probleem oplossen als ik eerst niet aan de hand van de structuur van mijn aspecten en gerelateerde qualiteiten weet wat de basis is van mijn object dat de function kan implementeren?

 

Als je begint met het implementeren van functies dan heb je al een aantal stappen overgeslagen (jump to the conclusions). Een deel van de structuur gaat verloren waardoor je veel meer overgeleverd bent op intuïtie en ervaring van de ontwerper. Niets mis met intuïtie overigens, maar het lijkt mij juist wel handig dat je aan de hand van een heldere methode kunt uitleggen waarom gekozen is voor een bepaalde oplossing. Vooral als je designed for six sigma dan wil je je keuzes graag van te voren inzichtelijk maken, checken en funderen en dan wil je niet overgeleverd zijn aan intuïtie ergens in het proces.

[DunneSloeber]

Er staat nergens geschreven in mijn berichten waarin ik suggereer te beginnen met het implementeren van functies. Waar ik wel op doel is dat ik het doel mis. Als het doel bekend is dan kan helder worden welke hindernissen er genomen zullen worden. Sommige problemen zijn minder relevant ... dat staat ook in het door jou gerefereerde QFD. Sommige problemen zijn helemaal niet relevant, omdat de oplossing niet bedraagt aan de stappen om dichter bij het doel te komen.

Ik geef aan dat er toch zicht op objecten moet zijn, en zicht op de onderwerpen, subjecten die de objecten gaan behartigen. Als niet duidelijk is wat het object behelst, niet duidelijk is wat het doel is, kan je nooit effectief een bepaling doen van de aspecten, en dus ook niet van de relevante qualiteiten. En waarschijnlijk is in zo'n situatie dat er altijd problemen bijkomen ...

 

Hoe je het ook wendt of keert, bepaald zal worden wat de functie uitvoert. Dat betekent niet dat de functies meteen in gebruik genomen moeten worden. Dat betekent dat er gekozen wordt.

 

sig sigma heeft volgens mij niet zo veel van doen met innovatie.

[Willem Super]

Innovatie en DFSS gaan hand in hand. Vooral als je leuke features probeert te ontwerpen loop je de kans dat je iets heel erg leuks en vernuftigs ontwerpt waar niemand behoefte aan heeft. Dan kun je er natuurlijk een flinke advertentiecampagne tegenaan gooien om de markt te veranderen maar gemakkelijk is dat niet. Design for six sigma is er heel erg op gefocused dat je juist dat ontwerpt wat de klant wil op de best mogelijke manier.

 

Er bestaat ook een gevaar: namelijk dat innovatie geblokkeerd raakt door de strakke DFSS design structuur. Je kunt gemakkelijk verzanden in oeverloos vergaderen als je niet uitkijkt. Maar dit terzijde.

 

De innovatie scan geeft juist aan waar je moet innoveren en waar je bestaande oplossingen moet koesteren om de klant zo goed mogelijk te helpen, voordat je uberhaupt gaat denken functionele eisen.

[Nico Schouten]

Ik heb je een aantal keren gevraagd dit even ragmatisch op te pakken en ons aan te geven hoe we jouw methode zouden kunnen evalueren. Omdat je daar naar mijn mening geen antwoord op geef doe ik een slotje op dit topic.

 

Mocht je vinden dat dit topic wel zinvol is dan mag je mij een PM sturen en mij met een duidelijk voorbeeld proberen te overtuigen.