Best Practice ERP: Cycle Counting

 

matherton's picture

Cycle counting is a topic that normally comes up during or shortly after the “up-and-running” phase of an implementation is complete. It is a technique that is easily implemented but almost always incorrectly. Why? Because the philosophy most firms adopt for cycle counting is often contrary to its intended purpose, so, even with flawless execution they get poor results.

What is the right philosophy you ask? Simple. Cycle counting is a means by which a firm validates that it's inventory management processes and procedures result in a target level for inventory accuracy. For those of you familiar with Statistical Quality Control, it is similar in concept to ensuring that a manufacturing process is in control.

To illustrate this and how it is different from how most firms approach cycle counting here is what it is not: “a periodic way to update inventory in the system so that it matches physical inventory.”

There is a striking difference between these two approaches and it has to do with what you do after comparing the count to the quantity on hand. Most firms, as I have already mentioned, simply update the system with the cycle count amount, sometimes after issuing a recount. A properly implemented cycle counting program seeks to identify the root cause for any discrepancies and fix them. Why? So that future cycle counts don't uncover the same mistakes over and over again.

So, how do you go about implementing a good cycle counting program? Try this:

  1. Adopt the philosophy. Highlight to everyone that cycle counting validates accuracy and is a means to identify problems for which the root cause will be fixed.

  2. Set goals. You'll need a target to shoot for. Make sure that everyone knows what it is. You'll have achieved your goal when all counts on a given cycle count meet or exceed your target.

  3. Determine what you will cycle count. The number of items you count per day will vary from firm to firm but the number 30 is a good place to start simply because a random sample of this size is statistically significant.

  4. Count a cross section of items. Many firms count their fast movers more often than slow movers but this might not be the best approach. Because you are trying to uncover the root causes for inventory inaccuracies, a cross section of items counted during each cycle is a better approach. Identify how items are handled differently and then count some from each of these handling groups during each cycle count.

  5. Execute your counts. This phase is no different than adopting cycle counting with the wrong philosophy.

  6. Identify root causes and fix them. For any count that is outside the tolerance you have set for inventory accuracy, determine why the inaccuracy occurred and fix it. Are your bills of material correct? Are there problems with shrinkage? Is the engineering or QA departments adhering to proper inventory processing procedures? Perhaps labeling is a factor. When the count in the system does not match the physical count there is a reason. Determine what it is and work to ensure that it does not happen again.

Your goal should be to be surprised when the count in a cycle count does not match the quantity on hand in the system. It won't happen overnight. It will take time because determining root cause is challenging and implementing changes that eliminate those causes is even more challenging. But, the rewards are great. With accuracy comes the potential for speed and responsiveness to customer demand with no inventory related mistakes and a lower investment in inventory. Oh, and did I mentioned that some firms that can demonstrate high levels of accuracy though cycle counting have even done away with full physical counts? Just remember, it all starts with the correct philosophy.

 
paladinlogic's picture
Offline
Joined: 06/09/2008
Getting started

In the Richart Distributors case study, you describe getting them launched on cycle counts. We'll implement cycle counts later; we only want to do overall counts at this point, but the rest of the process should be identical for count tags created either way.

We have a situation, however, where there are many inactive items in the system and there is no way to restrict the visibility to just active items. That is, Inventory->Physical Inventory->Create Count Tags->by Class Code ignores whether the Item/Item Site is inactive.

How did you make it work for Richart Distributors? Did they have no or only a few inactive items? In the case where there are many inactive Items/Item Sites, what do you recommend?

Thanks!

 
matherton's picture
Offline
Joined: 10/22/2002
Getting Started

In the case you mention there were almost no inactive items in the database so this was not an issue. Many inventory managers like the idea of generating tags for inactive items so they can ensure that they truly have no quantity on hand.

There are several ways in which to address the situation you describe if you prefer not to count inactive items. One would be to simply manually delete the count tags for inactive items. Another would be to modify the function createcounttag() so that count tags for inactive items are not created in the first place. Finally, you could run a simple SQL statement after the tags are generated to delete count tags for inactive items:

DELETE FROM invcnt
WHERE
invcnt_itemsite_id IN
(SELECT itemsite_id FROM item, itemsite WHERE itemsite_item_id = item_id AND item_active = 'f')
AND invcnt_posted = 'f';

NOTE.

I created this SQL specifically for this reply. It does work but it has not been fully tested. For one, it assumes that you do not use count slips or if you do that none have been entered. It did remove the count tag generated for an inactive item in my DB so it is worth a trying in a sandbox.

 
paladinlogic's picture
Offline
Joined: 06/09/2008
Getting re-started :-)

Thanks for the response! We will try that approach to trim out the inactive items.

Can you give me a pointer to any documentation that might exist that defines a physical inventory business process that is best supported by xTuple? Either a standard process definition or a more detailed case study of the Richart Distributors situation would be most helpful.

Thanks!