Tracking and Traceability of Finished Goods

Hi All,
Could someone provide me with examples of systems that are commonly used to guarantee that the customers receive the lot number of products that we say we sent them?

I ask because I was recently auditing our finished goods tracing system and found some errors. For example, we make batches of 3000 units within a single lot number, and then package those 3000 units into boxes of 20, for a total of 150 boxes of finished goods. We send those 150 boxes to customers. We record the lot numbers of the 150 boxes directly on invoices and packing slips via our CRM. But I did an audit of various lot numbers to make sure 150 units went out, and found variation that I am not happy with. I am guessing the problem is that the employees are failing to change the lot numbers properly when a new batch is ready for sale, because there is often a correspondence between one batch having too few units and the next batch having too many.

So I want to error proof this system of lot changes (or at least put in a method to record variation when it happens). Any ideas?

And, i know it doesnt need to be said, but this is important for vigilance reporting. how do i conduct a recall properly if I have records that 150 units were produced by only 149 were sold? where is that last unit?

Thanks

Hi,

Don't guess; find out.

What you describe is a NC and needs to be formally handled under your NCP SOP. Further, if the severity and/or frequency warrant that, it should be elevated to CAPA, and again - treated according to your applicable SOPs.

First, define what exactly the problem is (or problems are). As necessary, investigate to identify the true and significant root causes. Finally, decide how to act to effectively and efficiently eliminate them, and as necessary apply change control. Perhaps also follow up in 6 or 12 months time to ascertain that the problems are gone.

Cheers,
Ronen.

I am guessing the problem is that the employees are failing to change the lot numbers properly when a new batch is ready for sale, because there is often a correspondence between one batch having too few units and the next batch having too many.

Click to expand...

I am reading this many times, and try to understand what you wish to say. Perhaps you can detail more. I hope that the lot numbers on the products are intact. It is your sales document that is not capturing same effectively. Quantity in a batch is no hindrance for lot numbering.
The idea here is identification. Traceability and identification go hand in hand. When a sales lot of 100 have two or three lots, they need to be identified accordingly and captured into your sales documents (Invoice etc.) This will help in an event you want to call back.
In your example when the above is well processed, a review of your invoice will be able to say where the last unit has gone OR is still in your warehouse controls.

Are you running continuous production where every 3000 units is given a different batch number?

As these 3000 units corresponds to 150 boxes, does this equate to one pallet or to a predetermined number of layers on a pallet(s)? If it does, then when the predetermined pallet(s) or layers have been achieved, create some form of signal (light / card / buzzer) to remind operator to change the batch number.

Another way is to have an in-line counter that stops the packing line when 3000 units / 150 boxes are achieved. This is a trigger to change the batch number.

These are just ideas not definite solution to your problem. I hope it helps.

Google "poka yoke" for more ideas. Hope you find a solution to your problem.

Loke

Hi
Several suggestions below for your consideration

Set a MOQ as 1 box to forbid split saling.
Specific design grid array in box as 150 for visible detection.
Weighting sealed box to double confirm quantity of finished goods in it.
Generate Box ID traceability in system which can align with lot number.

Eric

Hi All,
Thanks for all your replies.

Just to be clear, this is being handled through the CAPA system. It becomes difficult because I don't know how to solve it without implementing something drastic. I know our process is error prone, but the only alternatives that I can think of involve a level of automation that we have not achieved yet.

for example, how do you make sure that the bar code for each lot is properly changed when the lot number changes? what actually stops the same bar code from being used? I assume your software notifies you, but does it prevent you from proceeding? it is clear our issues are error related, not intentional.

or, what happens when someone clicks the button twice and accidentally records two units sold, rather than 1? or the opposite, when someone puts two units of finished goods in a delivery box but forgets to scan both, so the system only thinks one if leaving the building? sometimes this is caught but it can also slip through...

I dont know how to stop problems like this. there is an inevitable level of human error and I just dont know how to eliminate it. I can say it is training, or have two people sign off on simple processes or something like that, but it just becomes too burdensome at some point and people want to cheat to make their lives easier, or it gets overly complicated and people get confused...

Hi,

My :

a) Don't try to solve all problems at once. Identify each problem on it's own, assess and rank by criticality (you could use severity of consequences and frequency as measures), and prioritise. Not all problems warrant mitigation, and certainly not all at the same time / priority.

b) For each problem identify AND DOCUMENT what the root cause is. Dig as deep as necessary and try to find the root causes that have significant leverage (big impact for little investment). Don't go any further (i.e. don't implement anything) until you have thoroughly done this.

c) Assess and rank alternative solutions (=ways to eliminate the root cause), then pick the best and implement one at a time. Focus. Don't go to the next option until you are sure that the implementation was effective but the solution wasn't. Allow enough time for proper re-assessment.

Cheers,
Ronen.