TRIZ (pronounced /ˈtriːz/) Russian: Теория решения изобретательских задач (Teoriya Resheniya Izobretatelskikh Zadatch), often translated as "Theory of creative problem solving", is a method developed by Soviet engineer and researcher Genrich Altshuller and his colleagues, beginning in 1946.
Genrich researched numerous patents and found that many or all inventions followed 40 principles to overcome contradictions.
For contradictions, he recognized Technical Contradictions and Physical Contradictions.
He formulated a Matrix of Contradictions and 40 inventive principles.
The Laws of technical system evolution describe how technical systems evolve over time.
Substance-field analysis is a technique used by inventors to overcome Contradictions, replace one field or substance by another.
ARIZ (Russian acronym of Алгоритм решения изобретательских задач - АРИЗ) - Algorithm of Inventive Problems Solving - is a list of about 85 step-by-step procedures to solve complicated invention problems.
The latter have been the base of several more comprehensive methods.
Useful links:
* http://www.youtube.com/watch?v=wxDDFnT5qTQ&feature=related - 12 short videos about triz.
* http://www.triz-journal.com/archives/year/ - triz journal.
* http://www.triz-journal.com/archives/1997/07/b/index.html - 40 inventive principles
* http://www.triz-journal.com/archives/2005/11/09.pdf - Explanation of Ariz.
donderdag 18 november 2010
donderdag 11 november 2010
Kano Model - explained
Let's have a look at the Kanomodel mentioned in the previous post. One thing we must have straight from the beginning is that the kanomodel is about quality, not about innovation.
Professor Kano defined the model in the 1960's in Japan. He dimensioned quality vs customer satisfaction by setting customer satisfaction vertically and quality horizontally.
He found that basically there are three types of product features. The same goes for services, by the way.
The first kind of feature is what customers take for granted. They wont mention it in a survey, but they will certainly complain or even be upset of it ain't there. For a car, you would be upset and even enraged if it had no brakes. If they are there, no one will mention it to their friend.
Another excellent example, as mentioned by dr Karandikar, is that a customer expects a car to be scratch free. If you find scratches on your new car, you are dissatisfied and not accept it. Quality improvement will help here, but only to a certain extent. If they are not visible to the naked eye, the customer is satisfied. Any further quality improvement, such as scratch free under a looking glass or a microscope, will not add further to customer satisfaction.
For custom made software, it might be one of the Must (From MoSCoW) requirements.
In the diagram above, the line would look something like:
The shape is usually drawn more smoothly, as a kind of hyperbole, but i think this shape reflects the truth more accurate for many product features, especially whehj it's a "have or have-not", such as tires on the wheels of a car.
A second group of requirements is formed by those where more is better. These are the attributes everybody is competing on.
For example, for cars this might be fuel consumption. You will be dissatisfied in Europe with a car that runs 10 km on 1 liter. You may be average satisfied with a car that runs nearly 20 km on 1 liter. You would probably be delighted with a car that runs 30 km on 1 liter.
In software, this might be the number of bugs per function point. Your customer might be very dissatisfied when he found 10 bugs per function point. He might be very satisfied when he found only 1 bug per 100 function points. And there are various levels in between.
In the diagram we would display it as :
And then there are the features which make your customer really satisfied. These are the things he would not have missed when they had not been there, but which delight him if they are present.
For cars, in the past these were for example auto-speed, seats which can be set to personal preferences, and so on. For the future, these might be a special warning system if the driver is falling asleep while driving, and you can probably come up with your own ideas.
For software, it might be some parametrization which makes things much more flexible for the customer, or the unexpected support of the new product he's designing for his customers.
In the diagram it would look something like:
Now there is a trend with features. What is a competition feature today, eventually degrades to a must have tomorrow. A coffee cup holder was an innovation a few decades ago, became a competition issue and might be taken for granted. Halogen spotlights were one of the things that made some sports cars special, are becoming competition features and may very well be taken for granted in a few years.
To be more complete, we must mention to other groups of features.
It is possible to overload features. A customer wanting to take some quick and easy snaps at a party, will not want all the features available in professional cameras. Those features get in his way. At best he ignores them. In software it might an host of features, which so fill up the menus that the user has to look for things like inserting a page break, foot note or table of contents.
A fifth group are those features which the designer thought great, but which the user does not care about. In software an example might be an entire new way of making menu options available. And though opinions may differ on it, i think the way automatic chapter numbering in ms office is a nice example of it. MS Office straight out of the box supports automatic chapter numbering, but it is pretty hard to have 2 level chapter numbers, like 1, 1.1, 1.2, 2, 2.1, 2.2, 2.3, and so on, which is pretty standard in Europe, but takes an amount of figuring out to get it right in ms office.
Links:
* Wikipedia article
* Excellent video by dr Karandikar
Professor Kano defined the model in the 1960's in Japan. He dimensioned quality vs customer satisfaction by setting customer satisfaction vertically and quality horizontally.
He found that basically there are three types of product features. The same goes for services, by the way.
The first kind of feature is what customers take for granted. They wont mention it in a survey, but they will certainly complain or even be upset of it ain't there. For a car, you would be upset and even enraged if it had no brakes. If they are there, no one will mention it to their friend.
Another excellent example, as mentioned by dr Karandikar, is that a customer expects a car to be scratch free. If you find scratches on your new car, you are dissatisfied and not accept it. Quality improvement will help here, but only to a certain extent. If they are not visible to the naked eye, the customer is satisfied. Any further quality improvement, such as scratch free under a looking glass or a microscope, will not add further to customer satisfaction.
For custom made software, it might be one of the Must (From MoSCoW) requirements.
In the diagram above, the line would look something like:
The shape is usually drawn more smoothly, as a kind of hyperbole, but i think this shape reflects the truth more accurate for many product features, especially whehj it's a "have or have-not", such as tires on the wheels of a car.
A second group of requirements is formed by those where more is better. These are the attributes everybody is competing on.
For example, for cars this might be fuel consumption. You will be dissatisfied in Europe with a car that runs 10 km on 1 liter. You may be average satisfied with a car that runs nearly 20 km on 1 liter. You would probably be delighted with a car that runs 30 km on 1 liter.
In software, this might be the number of bugs per function point. Your customer might be very dissatisfied when he found 10 bugs per function point. He might be very satisfied when he found only 1 bug per 100 function points. And there are various levels in between.
In the diagram we would display it as :
And then there are the features which make your customer really satisfied. These are the things he would not have missed when they had not been there, but which delight him if they are present.
For cars, in the past these were for example auto-speed, seats which can be set to personal preferences, and so on. For the future, these might be a special warning system if the driver is falling asleep while driving, and you can probably come up with your own ideas.
For software, it might be some parametrization which makes things much more flexible for the customer, or the unexpected support of the new product he's designing for his customers.
In the diagram it would look something like:
Now there is a trend with features. What is a competition feature today, eventually degrades to a must have tomorrow. A coffee cup holder was an innovation a few decades ago, became a competition issue and might be taken for granted. Halogen spotlights were one of the things that made some sports cars special, are becoming competition features and may very well be taken for granted in a few years.
To be more complete, we must mention to other groups of features.
It is possible to overload features. A customer wanting to take some quick and easy snaps at a party, will not want all the features available in professional cameras. Those features get in his way. At best he ignores them. In software it might an host of features, which so fill up the menus that the user has to look for things like inserting a page break, foot note or table of contents.
A fifth group are those features which the designer thought great, but which the user does not care about. In software an example might be an entire new way of making menu options available. And though opinions may differ on it, i think the way automatic chapter numbering in ms office is a nice example of it. MS Office straight out of the box supports automatic chapter numbering, but it is pretty hard to have 2 level chapter numbers, like 1, 1.1, 1.2, 2, 2.1, 2.2, 2.3, and so on, which is pretty standard in Europe, but takes an amount of figuring out to get it right in ms office.
Links:
* Wikipedia article
* Excellent video by dr Karandikar
donderdag 14 oktober 2010
Kano model
The KANO model is, according to the english language wikipedia, a theory of product development and customer satisfaction developed by Professor Noriaki Kano in the 1980's.
According to www.kanomodel.com, it is a process for systematic innovation.
To start with the latter, the process has 8 steps:
The name process is a better name than model: A model takes aspects of the real world and depicts them in a simplified setting, and describes the mutual relations between these aspects.
The kanomdel website does depict the steps graphically, but imho this is not enough to call it a model.
Another criticism on the kano model is that in step 4 the user has to use one of a series of tools. Now that sounds OK, but the strange thing is that one of these tools is TRIZ, which is in itself a process or method.
The description on wikipedia highlights the following categroies of product (or service) satisfaction:
Graphically their effect is:
These aspects also play an import role in the afore mentioned TRIZ. More on this later.
According to www.kanomodel.com, it is a process for systematic innovation.
To start with the latter, the process has 8 steps:
- identify customer needs
- explore VoC
- beyond VoC
- translate key problems into standard problems
- select appropriate si tool for each problem (function modeling, root cause analysis, common sense, etc)
- generate ideas and concepts with appropriate si tools (si tool selection matrix)
- evaluate, synthesize, and select final concept
- detailed product / process / service design
- Communicate value to the customer
- Deliver product to customer
The name process is a better name than model: A model takes aspects of the real world and depicts them in a simplified setting, and describes the mutual relations between these aspects.
The kanomdel website does depict the steps graphically, but imho this is not enough to call it a model.
Another criticism on the kano model is that in step 4 the user has to use one of a series of tools. Now that sounds OK, but the strange thing is that one of these tools is TRIZ, which is in itself a process or method.
The description on wikipedia highlights the following categroies of product (or service) satisfaction:
- Attractive Quality These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.
- One-dimensional Quality These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken of and ones which companies compete for. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.
- Must-be Quality These attributes are taken for granted when fulfilled but result in dissatisfaction when not fulfilled. An example of this would be package of milk that leaks. Customers are dissatisfied when the package leaks, but when it does not leak the result is not increased customer satisfaction. Since customers expect these attributes and view them as basic, then it is unlikely that they are going to tell the company about them when asked about quality attributes.
- Indifferent Quality These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction.
- Reverse Quality These attributes refer to a high degree of achievement resulting in dissatisfaction and to the fact that not all customers are alike. For example, some customers prefer high-tech products, while others prefer the basic model of a product and will be dissatisfied if a product has too many extra features
Graphically their effect is:
These aspects also play an import role in the afore mentioned TRIZ. More on this later.
woensdag 6 oktober 2010
Nesma newsletter
This morning the nesma newsletter artived.
Exin has planned 1 more FPA examination, on nov. 23. When i looked earlier this week, they had not yet updated their calender, but nesma seems to know the exin dates better than exin itself.
There are also a couple of new downloads,
* Begroten (Estimate)
* Exploitatielasten (exploitation costs)
* Softwaremetrieken (software metrics)
* FPA in het Voortraject (FPA in the early stages of a project)
* Measure! Knowledge! Action!
* FPA in Early Phases
* Productiviteitsattributen (productivity attributes)
* Functional Sizing Reference Model
Where the pdfs are in dutch, i have added the english translation between brackets. Interesting reading stuff.
Exin has planned 1 more FPA examination, on nov. 23. When i looked earlier this week, they had not yet updated their calender, but nesma seems to know the exin dates better than exin itself.
There are also a couple of new downloads,
* Begroten (Estimate)
* Exploitatielasten (exploitation costs)
* Softwaremetrieken (software metrics)
* FPA in het Voortraject (FPA in the early stages of a project)
* Measure! Knowledge! Action!
* FPA in Early Phases
* Productiviteitsattributen (productivity attributes)
* Functional Sizing Reference Model
Where the pdfs are in dutch, i have added the english translation between brackets. Interesting reading stuff.
woensdag 29 september 2010
Kano model, RUP, Volere method
RUP is often being regarded as THE process for developing software, with UML as the workhorse for requirements notation.
RUP also brings its own ideas about requirements gathering and modelling, but the Volere method is a method for requirements gathering and organizing, as well as the Kano model.
http://www.blogger.com/img/blank.gifhttp://www.blogger.com/img/blank.gif
It is interesting to compare the number of hits on google and bing, showing the relative publicity about these methods:
As I already used elements of the Volere method in my current requirements assignment, I certainly want to have a look at Kano soon.
RUP also brings its own ideas about requirements gathering and modelling, but the Volere method is a method for requirements gathering and organizing, as well as the Kano model.
http://www.blogger.com/img/blank.gifhttp://www.blogger.com/img/blank.gif
It is interesting to compare the number of hits on google and bing, showing the relative publicity about these methods:
As I already used elements of the Volere method in my current requirements assignment, I certainly want to have a look at Kano soon.
vrijdag 10 september 2010
Intuition and IT
IT is one of the most hardcore techs. One might easily think that in areas like these there is no room for, let alone need for intuition.
But this week intuition served me very well. The customer had reported a problem with a report, in which the number of predicted new employees was thrice the number that was actually being enrolled.
I have no access to the production databases, though i do have the privilege of being able to run the reports in production. Maintenance of this application has been “rightshored” to India, so after some inspection I forwarded the problem to the India team.
The next day they came up with a solution: they had found a view in which a clause was missing in one of a long list of UNIONED select statements. I checked and the result seemed indeed correct. Still I felt a huge amount of doubt. Intuition.
Yes, intuition is usually based on arguments or observations which have not yet reached consciousness. I closed the chat, got myself a cup of tea and forced myself to think. And indeed a couple of questions came up: why had no one noticed this problem before? This report has been in production for nearly two years. True, it was a problem report. Several issues had turned up with the numbers in this report over the past 2 years. But those had mostly been about 1 or 2 employees. Why did this problem crop up now? I asked the India guy, a capable guy by all indications, what was special in these data. He started searching, but could not come up with much.
I walked in on the customer representative, both for an occasional chat and a question on another topic which I needed to ask her. While discussing things, she volunteered some extra information: the 30 employees were not really new, but the result of a take over. They were also depicted in the wrong area of the report.
Back on the chat with India, the problem was quickly solved: the india guy quickly found that a crucial date was missing in the data our application imported.
Further reading:
Making Management Decisions: the Role of Intuition and Emotion, byHerbert A. Simon, Camegie- M ellon U niversity
IT consultants must learn to trust their intuitions, blog by Chip Camden
But this week intuition served me very well. The customer had reported a problem with a report, in which the number of predicted new employees was thrice the number that was actually being enrolled.
I have no access to the production databases, though i do have the privilege of being able to run the reports in production. Maintenance of this application has been “rightshored” to India, so after some inspection I forwarded the problem to the India team.
The next day they came up with a solution: they had found a view in which a clause was missing in one of a long list of UNIONED select statements. I checked and the result seemed indeed correct. Still I felt a huge amount of doubt. Intuition.
Yes, intuition is usually based on arguments or observations which have not yet reached consciousness. I closed the chat, got myself a cup of tea and forced myself to think. And indeed a couple of questions came up: why had no one noticed this problem before? This report has been in production for nearly two years. True, it was a problem report. Several issues had turned up with the numbers in this report over the past 2 years. But those had mostly been about 1 or 2 employees. Why did this problem crop up now? I asked the India guy, a capable guy by all indications, what was special in these data. He started searching, but could not come up with much.
I walked in on the customer representative, both for an occasional chat and a question on another topic which I needed to ask her. While discussing things, she volunteered some extra information: the 30 employees were not really new, but the result of a take over. They were also depicted in the wrong area of the report.
Back on the chat with India, the problem was quickly solved: the india guy quickly found that a crucial date was missing in the data our application imported.
Further reading:
Making Management Decisions: the Role of Intuition and Emotion, byHerbert A. Simon, Camegie- M ellon U niversity
IT consultants must learn to trust their intuitions, blog by Chip Camden
dinsdag 31 augustus 2010
FPA and SOA
Yesterday evening I had the privilige to attend a session about the new counting guidelines for Service Oriented Architecture. Martin Jacobs, chairman of the nesma sig on soa, presented it. Unfortunately the session was under non - disclosure.
The good news is that review session 2 is now under way, after which the nesma board still has to approve it. They hope to have the book printed by the fall conference of the nesma, and i suggested that it if the printers cant have the book ready, but the board has approved the document, it would be distributed as a pdf.
The result of the document is not very intuitive, but it is very logical and well thought out. It alligns neatly with the existing 2.2 counting guidelines.
The good news is that review session 2 is now under way, after which the nesma board still has to approve it. They hope to have the book printed by the fall conference of the nesma, and i suggested that it if the printers cant have the book ready, but the board has approved the document, it would be distributed as a pdf.
The result of the document is not very intuitive, but it is very logical and well thought out. It alligns neatly with the existing 2.2 counting guidelines.
donderdag 26 augustus 2010
Even the best may err...
The newspapers paid a lot of attention to Gmails new phonecall function. And that Google recalled it for all foreign users, granting it only to its US and Canada customers. I checked yesterday, and seemed to have missed it.
Great was my surprise this morning, when I found that I DO have gmails phone call function, see screenshot. The function now seems to be available for everyone, but free calls can only be made to fixed numbers in the US and Canada. A very nice solution, as it allows free calls from Europe to the US and Canada. I am not sure if everyone got the function, or that it only shows up because my interface language is set to US English. If the latter is the cause, you might wish to change your setting. Every gamil user also got a calling credit of 0.10 dollarcent to try it.
Even the best may err...
And the very best will use it to come up with something even better.
Great was my surprise this morning, when I found that I DO have gmails phone call function, see screenshot. The function now seems to be available for everyone, but free calls can only be made to fixed numbers in the US and Canada. A very nice solution, as it allows free calls from Europe to the US and Canada. I am not sure if everyone got the function, or that it only shows up because my interface language is set to US English. If the latter is the cause, you might wish to change your setting. Every gamil user also got a calling credit of 0.10 dollarcent to try it.Even the best may err...
And the very best will use it to come up with something even better.
dinsdag 24 augustus 2010
Firefox 4
Though a new browser version doesnt have to do much with it maintenance, it such a long time ago that i wrote something on this blog that something is betetr than nothing.
I just downloaded firefox 4, which was originally codenamed firefox sync but which was according to one source renamed to firefox panorama. That statement seems not true: the title of one mozilla page says: Firefox 4 Beta Updated with Sync and Panorama.
Sync allows a user to synchronize his bookmarks, form-data and cookies across multiple computers. For this, your data is stored on a firefox server. They promise that the data will not be linked to your travels thorugh the web. Still I see some privacy issues lurking here. Maybe it is a real issue, or maybe it is Much Ado About Nothing. No doubt others will comment on that further.
The first thing that strikes me as nice is the interface: neat! Less spacy bars, more space for the page itself. Good!
Also a pleasant surprise was the speed with which it started: imho considerably faster than the previous version.
Firefox panorama is all about tabs. Usually I have some 8-10 tabs open, something firefox could handle easily. Usually they are about several topics: a set of tabs about css, some on one of the work related topics i research, such as now this beta, one for gmail, and some on the online games i play. When i grouped them, FF allows me to show only those that are in the group. I short video shows hwo to do them, very well done.
And as you can see in the picture, I'm writing this blog with the beta. No compatibility issues detected till now. I look forward to some page development, which with FF plugins has always been a strong point of FF.
I just downloaded firefox 4, which was originally codenamed firefox sync but which was according to one source renamed to firefox panorama. That statement seems not true: the title of one mozilla page says: Firefox 4 Beta Updated with Sync and Panorama.
Sync allows a user to synchronize his bookmarks, form-data and cookies across multiple computers. For this, your data is stored on a firefox server. They promise that the data will not be linked to your travels thorugh the web. Still I see some privacy issues lurking here. Maybe it is a real issue, or maybe it is Much Ado About Nothing. No doubt others will comment on that further.
The first thing that strikes me as nice is the interface: neat! Less spacy bars, more space for the page itself. Good!
Also a pleasant surprise was the speed with which it started: imho considerably faster than the previous version.
Firefox panorama is all about tabs. Usually I have some 8-10 tabs open, something firefox could handle easily. Usually they are about several topics: a set of tabs about css, some on one of the work related topics i research, such as now this beta, one for gmail, and some on the online games i play. When i grouped them, FF allows me to show only those that are in the group. I short video shows hwo to do them, very well done.
And as you can see in the picture, I'm writing this blog with the beta. No compatibility issues detected till now. I look forward to some page development, which with FF plugins has always been a strong point of FF.
Abonneren op:
Posts (Atom)