donderdag 18 november 2010

TRIZ

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 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