SPC for the postal industry

Actually, I would use a run chart (for machine breakdowns, jams ) to see if the long term average is changing. Breakdowns aren't exactly under statistical control.

I would construct a pareto chart for types of breakdowns, breakdowns by machine, and breakdowns by shift. Also to document breakdown frequency after your remedial actions.

A cause and effect (fishbone diagram) will help you visualize the various causes that may be affecting the process's performance. MAn Method Machine,Material become the main ribs.

Personally I have had greatest success with IS/IS NOT analysis, to get the best description of the problem.

If your management is insisting on seeing a"chart" to make it official SPC, an np chart for machine jams per day would be an appropriate use of that tool.

Throughput is difficult because mail volume is not under your control, an X bar R chart for pieces sorted per hour would be a fair use of an Xbar/r chart, but more make work than helpful. Though it might identify differences between equipment operators and shifts, but since you are unlikely to use it for modifying crew behavior other than perhaps targeting training, or to condemn a piece of equipment beyond maintenance, I'm not sure it adds much to what you already know.

I would do pareto for breakdowns, is isnot for defining problems, and get to work, THen I'd add np chart for breakdowns.

If I could only have one new piece of paper, it would be acheck sheet for all routine and preventive maintenance for all equipment. That isn't spc, as much as it common sense.

good luck. milo

The chart should include where the mail comes from that jams the machine to see if there is an outside source for the problemds too.

Milo,

Thanks very much for all that info, much appreciated. I will take it all on board.

While talking to a lecturer I had in college I brought up the subject. He suggested the use of Cusum (Cumulative Sum) charts. Any opinions?

Thanks

Not for beginning spc. Cusum charts are best for detecting small changes in a process or a measurement system. They are more sensiitive than x bar r charts for process control. We haven't really identified a process that you have control of yet...
This is a sensitive technique for looking at changes in means. What data do you have???

Their interpretation (CuSum charts) is less than obvious in my opinion. But they are great for analyzing serial (sequential) data.

Every practictioner has a favorite tool, and your professor friend has chosen a very "fussy" tool.

I gave you an axe and a chain saw.

milo

Hello,

My recomendation is to used OEE.

"Overall Equipment Effectiveness (OEE) is different. OEE truly reduces complex production problems into simple, intuitive presentation of information. It helps you systematically improve your process with easy-to-obtain measurements." http://www.oee.com/

"OEE measurement is also commonly used as a key performance indicator (KPI) in conjunction with lean manufacturing efforts to provide an indicator of success.

OEE can be best illustrated by a brief discussion of the six metrics that comprise the system. The hierarchy consists of two top-level measures and four underlying measures."

http://en.wikipedia.org/wiki/Overall_equipment_effectiveness

We are using in our MFG plant and really is a good tool. The best company can archive OEE 80%.

Check formula on http://www.oee.com/calculating_oee.html

Once again thanks for your comments guys.

freeman....I must do more research in OEE...seems interesting.

Milo - my key concern is that we dont have a very 'controllable' process as such.

Lets take 'read rate' as an example. Read rate is the percentage of the input mail that the OCR successfully read its address and matched it to a destination in the database.

Read rate can vary about a mean by about +/- 10 % on a given shift. Is a run chart only suitable?

Basically all our KPIs vary significantly shift on shift. They are: read rate, throughput, machine jams, Barcode read errors, machine downtime and system rejects.

Currently the data is not analysed in any scientific/mathematical way. Its there in tables only, and assumptions are often made as to why a paticular machine performed so bady on a given shift.

All data is collected at the end of shift, and there are 4 shifts per day, therefore 4 data points per machine per day.

I like your previous suggestion of pareto and fishbone charts for the downtimes/jams. Will definately use that method to gather information for another project of reducing downtimes.

Can you take each KPI for me and suggest a SPC/chart method for analysing them? See below:

- Read Rate

- Throughput

- Barcode read errors

- Jams per machine

- Machine downtime

- System rejects (mail rejected due to it being too big, too stiff etc.)

I really appreciate your time and effort. This is my first job outta university so still a beginner.

Thanks again,

John.

i sympathize with you since it is your first job since university but, if you are working for apostal service forward sortation office one of the biggest problems you should consider you will meet is a theory that i wont let that happen onmy watch or a variant on those words which will come from both management and employees. i do feel sorry for you but this reads like an identical test and determine the best route to fix things so the plant works better which was set up by the canadian government postal plant operating managers about 30 years ago.

'da ber

Am traveling and will reply after giving this some careful thought;

CAn you help me understand which aspects of read rate are 'controllable?" vs which are not?

Personally I would try a controlled experiment where I captured "uncontrolled read rates" for some period for all machines individually and in aggregate, (say a week) then I would split my equipment up into a control and a test group and just run the control group as normal, treat the test group as follows: Clean optics every two hours, blow out dust before cleaning optics, And then capture read rate data and uptime/breakdowns data and pieces of mail throughput per machine for each separately.( and note the few minutes time down for the mtce cleaning so that you canjustify it based on your results.)

After a week or so I'd plot the data as runs, and also calculate average and std deviation by test vs normal, Historic Uncontrolled read rates before the trial (all Machines ) and then the test group. Comparison of means and std deviations by group should tell a lot! Also compare them by individual machines to themselves prior to treatment. Then pareto the breakdown reasons. for test and control group. look at differences. don't forget to identify operators and shifts so that you can later test for these interactions in your analysis.

The best way to do this would be a taguchi design of experiments , probably an L-8 design, Thats what I would do starting out. For me to correspond with you privately, you will need to register, then I can hit your user name as an email address.

Think about what i have just described, and then sketch out how to do it on just a small scale to work out how you would get the data to execute this, may be do a quicky on just two machines to prove the concept. Then do the full blown test on all equipment.

I will need your email to send you the L-8 Taguchi DOE info as a pdf.

milo

"Read rate is the percentage of the input mail that the OCR successfully read its address and matched it to a destination in the database."

So how can you tell if the reason for "not read' is up to your system? Thats why I suggested optical/cleaning. You can't do "Statistical Process control" if you don't control the process. Using Pareto to try todetermine the root cause- Colored pale inks, sharpie marker too fat characters, this sort of analysis can help you formulate failure modes so that you could either reengineer future equipment or create a presorter that detects these input conditions and shunts them to a human first is one approach. What the heck would a run chart tell you that you could use, that all the mail from tuesday afternoon was more readable than say thursday's? so what?

Throughput: if you insist on charting this it should be as a rate, as volume of mail is out of your control. Pieces per hour for each machine is a valid approach. x bar and r chart would be acceptable approach. Must document reasons for out of control points, and pay especial attention to the range as that reflects the variability of the process.

barcode read errors: either p chart, or np chart. The Np control chart is used to determine if the rate of nonconforming product is stable, and will detect when a deviation from stability has occurred. an Np chart is used when the size of the subgroup (N) is constant, and a P chart is used when it is NOT constant.

Jams per machine: same as read errors, but again I would urge pareto analysis of root causes with a means to track each machine by the minute, recording setup times, maintenance and run time. create multilevel Pareto charts to help determine how many non-value-added minutes are spent on various activities such as fixing electrical problems or making adjustments.

Downtime: pareto charts first, xbar control charts second. determine the most significant factors influencing non-value-added time. analysis may show that a significant amount of down time is for adjusting of machines. if looked at with x bar and r charts for whatever variables can be tracked, you might find out that there is much time being wasted by overadjustment. If machine downtime is also caused by violations ( mail oversize but not culled out first) then you can use data from this to dollarize the consequences of not doing a responsible presort or putting in a poka yoke ahead of the machine to divert violating mail.

I would actually post a run chart of machine uptime, not downtime.

System rejects: You have no control, you will only get frequency and who cares as its variablility is out of your hands. Pareto to record types of violations and then suggest new equipment or new presort equipment parameters or >>>>???

SPC is worth doing ONLY IF YOU CAN TAKE SOME POSITIVE ACTION TO ELIMINATE ROOT CAUSES of nonconformances. Otherwise, doing the spc itself becomes a waste.

Keep it simple, pareto first, identify a small doable project, collect data and then develop root cause corrective actions.

I am sure that there are other approaches and other ideas; also, I have never even seen your process or equipment, so much of this is based on my conjecture of what your equipment must function like. however, i think that you will find my info to be actionable. Do let us know how your progressing. I will hit you privately to provide the DOE info when I get to my normal email.

milo

Barfnagler - youre exactly right.

Milo - you have private message.

Another very helpful post - thanks.

I was consulting my professor today and you and him have the same ideas. OK ill discuss each performance measure in the order you have them....

Read rate - "What the heck would a run chart tell you that you could use, that all the mail from tuesday afternoon was more readable than say thursday's? so what?"

Exactly what my lecturer said. Read rate success depends on the factors you mentioned - font, handwriting etc and also on whether our address database is accurate. But in a nut shell your correct - it is not within our control. In saying that, plotting it on a run chart should highlight a trend of any poor read rates, which would indicate a technical fault - i.e. controllable. So I think thats as far as I can take analysing that indicator.

With regards reader/software design, I nor my company design such equipment. It is outsourced. All we do is explain the nature of our country's addressing system and they work from there.

Throughput - we currently measure in items per hour as you suggested. And I will take your advice to use x bar and r charts to highlight instances for investigation.

Barcode read errors - again I will use your suggestions. Not a variable that needs immeadiate focus as only <0.5 % of mail results in an error. A very small proportion of our current delays.

Jams per machine - this needs immeadiate action. In some cases, albeit rare, jams have resulted in a downtime/total time ratio of 30%......very poor in any process. Pareto charts will be the first steps, including multi level ones.

An important and simple point my lecturer made after looking at jam data - huge variation in the data (albeit normally distributed) mean that the process is very unstable. Therefore, a full investigation into jams is necessary before I get 'fussy' with SPC methods.

Machine downtime - yes your assumptions are correct....the downtime (usually jams) is a result of mail violations, and there are cullers that detect these violations in the early process steps and cull bad mail. However, the methods for deflecting bad mail are poor, and the mechanisms/deflectors often cause jams themselves. Poor design from the supplier and is being looked at.

System rejects - your correct, no conclusions can be drawn from this data. Based on probabilities.

All in all I will take the advice given by you (and echoed by my professor) - pareto the problems and reduce/eliminate them, then take a SPC approach where applicable.

I have a lot to get my head around. A lot of changes to be made.

Thanks for your help and guidance. Has been invaluable.

Well there you are.

HAVing now "pareto'd" All your KIV's you now have identified where to focus: Culling, culling methodology, and machinery to deflect violating mail.

NOw, I would offer the following, Pareto the jams by downtime to see which "classes of violation" cause the most /longest downtime 9Big manila envelopes, Hard cardboard mailers, Thick CD mailers, etc etc. so that you can then solve causes by class based on the most severe pain (downtime) caused.

milo

Good root cause analysis guys, this place never ceases to amaze and teach me.

Do keep us updated to your issues, it may be snail mail but it must go on.

Brad