Mistake Proofing Trading: Poke Yoke

L

Luto

When Edward Demming when to Japan introduce "continous Process Improvement" to the auto industry, a method came out of it called Poke Yoke. As the story goes on a manufacturing line they were assembling buttons on machines. The problem was , the assemblers were forgetting to put the spring behind the button, so when you pushed it, it would never snap back. To solve this problem (mistake), then used a cup, and placed the exact number of buttons and springs into to it. So it there were any left over parts, they knew a mistake had occured.

Other examples: I would go shopping during my lunch hour and pick up fresh fish. I placed it in the refrig at work, but would realize 1/2 way home that I had left my dinner at work!
Solution: Place my car keys in the bag in the refrig.

A friend loans out DVD's from his library, but often never get them back.
Solution: remove DVD from case and place it in a generic case, that way the borrow does not "add it to their collection" and my firend knows what is out on loan by seeing the empty cases.

I hope this illustrates the principle.

Seeing as trading a system can be frought with mistakes of all kinds does anyone have some clever POKE YOKE they would like to share?

Perhaps the best way to share is to state the mistake and you solution.

Cheers
 
In order to improve, it is fundamental to measure. No one can say they are improving unless they measure. The measurement can be different types depending, of course, on the ultimate goal.

It should go without saying the system is the benchmark. If one does not follow it, one can never get a good measure of it. And then to not measure it, makes it darn hard to improve it or the using of it.

To that end, I measure my mistakes. As I know my system is solid, but it appears my problem is in the management (entry, stops, and exit).

So for 20 trades, I have the worst case of making 60 managment errors. ( 3 errors per trade). Of course I could get into a finer granularity, but I don't think it buys me much to dwell obsesively on errors. I would rather create poke-yoke solution to avoid the error completely.

What I have found has pretty amazing. i.e. I found I was making very few flawless trades. Flawless here is defined as not following the system. So in a matter of a couple dozen trades, I have been making a steady improvement, i.e. less errors. Furthermore, I have elimated several classes of errors completely.

I wonder how many trades actually know much about their errors, their frequency and frequency trend.

Food for thought....

L
 
Very good thinking indeed!

It would be nice to learn more comments from you and/or others, as it seems Deming's practices could be possibly applied to several aspects of our trading execution process. :cool:
 
I agree of course since I often refer to Deming :)

Quote from Luto:

When Edward Demming when to Japan introduce "continous Process Improvement" to the auto industry, a method came out of it called Poke Yoke. As the story goes on a manufacturing line they were assembling buttons on machines. The problem was , the assemblers were forgetting to put the spring behind the button, so when you pushed it, it would never snap back. To solve this problem (mistake), then used a cup, and placed the exact number of buttons and springs into to it. So it there were any left over parts, they knew a mistake had occured.

Other examples: I would go shopping during my lunch hour and pick up fresh fish. I placed it in the refrig at work, but would realize 1/2 way home that I had left my dinner at work!
Solution: Place my car keys in the bag in the refrig.

A friend loans out DVD's from his library, but often never get them back.
Solution: remove DVD from case and place it in a generic case, that way the borrow does not "add it to their collection" and my firend knows what is out on loan by seeing the empty cases.

I hope this illustrates the principle.

Seeing as trading a system can be frought with mistakes of all kinds does anyone have some clever POKE YOKE they would like to share?

Perhaps the best way to share is to state the mistake and you solution.

Cheers
More...
 
Quote from harrytrader:

I agree of course since I often refer to Deming :)
More...

As usual other industries are "rediscovering" the principle dozens of years after :D. For example the software field has now been introducing the "design by contract" concept using preconditions and postconditions (basic requirements which protects the user of the pattern) I have already mentioned in a thread (design pattern approach ). This is indeed a very recent tren...tid=394142&highlight=preconditions#post394142):

http://archive.eiffel.com/doc/manuals/technology/contract/

"Imagine for example a model of a chemical plant, with classes such as TANK, PIPE, VALVE, CONTROL_ROOM. Each one of these classes describes a certain data abstraction -- a certain type of real-world objects, characterized by the applicable features (operations). For example, TANK may have the following features:

Yes/no queries: is_empty, is_full...

Other queries: in_valve, out_valve (both of type VALVE), gauge_reading, capacity...

Commands: fill, empty, ...

Then to characterize a command such as fill we may use a precondition and postcondition as above:

fill is
-- Fill tank with liquid
require
in_valve.open
out_valve.closed

deferred -- i.e., no implementation

ensure
in_valve.closed
out_valve.closed
is_full
end"
 
I am working to introduce the same kind of concept in Trading as I said already in my thread "Design Pattern approach - vs classical pattern approach - context and prune rules" but since it will seem too abstract for most people I give up exposing it. "Prune rules" are indeed the poke and yoke principle : prune rules intend to prevent people to take actions if prune rules conditions are fired.

Quote from harrytrader:

As usual other industries are "rediscovering" the principle dozens of years after :D. For example the software field has now been introducing the "design by contract" concept using preconditions and postconditions (basic requirements which protects the user of the pattern) I have already mentioned in a thread (design pattern approach ). This is indeed a very recent tren...tid=394142&highlight=preconditions#post394142):

http://archive.eiffel.com/doc/manuals/technology/contract/

"Imagine for example a model of a chemical plant, with classes such as TANK, PIPE, VALVE, CONTROL_ROOM. Each one of these classes describes a certain data abstraction -- a certain type of real-world objects, characterized by the applicable features (operations). For example, TANK may have the following features:

Yes/no queries: is_empty, is_full...

Other queries: in_valve, out_valve (both of type VALVE), gauge_reading, capacity...

Commands: fill, empty, ...

Then to characterize a command such as fill we may use a precondition and postcondition as above:

fill is
-- Fill tank with liquid
require
in_valve.open
out_valve.closed

deferred -- i.e., no implementation

ensure
in_valve.closed
out_valve.closed
is_full
end"
More...
 
Quote from Luto:

In order to improve, it is fundamental to measure. No one can say they are improving unless they measure. The measurement can be different types depending, of course, on the ultimate goal.

It should go without saying the system is the benchmark. If one does not follow it, one can never get a good measure of it. And then to not measure it, makes it darn hard to improve it or the using of it.

To that end, I measure my mistakes. As I know my system is solid, but it appears my problem is in the management (entry, stops, and exit).

So for 20 trades, I have the worst case of making 60 managment errors. ( 3 errors per trade). Of course I could get into a finer granularity, but I don't think it buys me much to dwell obsesively on errors. I would rather create poke-yoke solution to avoid the error completely.

What I have found has pretty amazing. i.e. I found I was making very few flawless trades. Flawless here is defined as not following the system. So in a matter of a couple dozen trades, I have been making a steady improvement, i.e. less errors. Furthermore, I have elimated several classes of errors completely.

I wonder how many trades actually know much about their errors, their frequency and frequency trend.

Food for thought....

L
More...

You are addressing a fundamental and pervasive building block of making money by trading or investing.

The market and the person are a diad. What could be more effecitve for the person half than to be assessing the relative proficiency and/or efficiency.

The loop that occurs from personal input to personal output has many stations along the way to assess. ET is one of the most fruitful places for monitoring the loop with the given sample size of people available. Subsets abound as well. You are focussed on an effort an individual could make for himself. It would also be neat to come up with a list of the 18 most common screw ups people do here. THE WJO example in HTMMIS, Chapter 20 is a great example of such results.

OT

In a similar way, the market provides not one loop but two loops to examine. The usual one is it's efficiency to deliver capital to sucessful traders. You could view the market delivery system from a Demming viewpoint to assess it's contemporary dynamic efficiency. The set of points for signal generating capacity is a terrific gross measure of what particular human strategy represents (fits the market) the most effective operation at the moment (NOW).

The other loop the market presents for measurement is as yet not handled in a widespread way. It is the basic substitute for the prevalent modus now called "predicting". The best descriptor for it's benefit and value is "What to watch out for that the market could do the interrupts delivering capital profits to the trader".

QED.

Having all this stuff downpat is a definite asset for making money.
 
Mistake: Forget to put in stop and target when entering a trade.
Poke Yoke: Use a OCA order so that when the trade is entered, the stop and targer MUST be entered also.

Simple Obvious, but most importantly mistake proof.

Although not mistake proof, this also has an advantage prompting the trader to select a target and a stop. i.e. you have one but it might not be the right one... Which is a different problem.
 
Quote from harrytrader:

I am working to introduce the same kind of concept in Trading as I said already in my thread "Design Pattern approach - vs classical pattern approach - context and prune rules" but since it will seem too abstract for most people I give up exposing it. "Prune rules" are indeed the poke and yoke principle : prune rules intend to prevent people to take actions if prune rules conditions are fired.
More...

It works. An object (or a market) has state. In fact, the market is really just a factory object. Its instantiations are permutations of its properties such as trend, volatility, and other metrics. For each market instance, only certain methods are applicable, e.g., breakout and pullback strategy but not fade strategy. It's all in the framework.

PTR
 
You must log in or register to reply here.
Back
Top