November 1996 € Volume 6 € Number 11
November 1996 € Volume 6 € Number 11
To ensure integration with materials handling equipment when selecting MRP II software, the primary question to ask is: Does this software support open systems interconnection (OSI), and/or manufacturing automation protocol (MAP v. 2.1 or 3.0) for integrating with data collection devices and manufacturing automation equipment?
That simple answer doesn't make much of a magazine article, so let's try to help the poor souls who need to physically account for the whereabouts of all this material that is being moved faster and faster. What software features can make physical inventories and cycle counts easier?
The messiest area for counting is always work in process (WIP).
Things get issued into the "black box" and come back as something
else. What happens in between is usually difficult to track.
Work in process
If you're lucky enough to have short production cycle times, you
might be able to get by without counting work in process more than
once a year for tax audit purposes. If there's any way to reduce your
cycle times, this is a major incentive. Do it! If you already have
short cycle times and you're still trying to count work in progress,
give yourself a break. It's not worth it.
If you feel that you do need to regularly count your WIP, be prepared to choose software wisely. Some software packages don't include WIP as an inventory stocking location. When you issue from stores to WIP, the inventory no longer shows up on any inventory reports. The general ledger still accounts for the dollar value of WIP, but you have lost all visibility within inventory reports until something emerges from the "black box" as an "end item." If you are not trying to count items in WIP, this is livable. If you are trying to count items in WIP, you have just encountered your second-worst nightmare. Your worst nightmare is when you try to explain all of this to the top executives in your company, and their eyes glaze over before finally pounding their gavels and shouting, "We don't care about your problems, just get us that report!"
When selecting software, it is so easy to get hoodwinked regarding
WIP visibility because there are frequently differences between the
way the same software package tracks WIP for standard items, jobs,
and custom or configured products. The same software might have two,
three or even four different ways of tracking WIP, and if you are not
persistent in demanding to explore all of them, you may find out six
months into your implementation that your software provides work in
progress visibility for make-to-stock items, but not for projects or
custom configured items.
Bar codes
If your question is "Does this software support bar codes," the
answer is always "yes." Why? Because there are bar code readers that
simply emulate a keyboard. You use the keyboard to get to a data
entry field, and then you can use a bar code reader to fill in the
field, just as if you had used the keyboard.
But is that what you want to do? Probably not. You were probably
envisioning taking a hand-held bar code scanner out onto the floor,
rather than moving all of your merchandise past the computer to be
scanned. Maybe you were envisioning scanning work in process items as
they crossed key production control points. You were probably
envisioning the software automatically printing bar code labels on
things like product labels, case labels, pallet labels, work orders
and picking tickets. Each of these are specific questions that are
not encompassed within the question "Does this software support bar
codes?"
ABC codes
If you ask "Does this software calculate ABC codes," you are likely
to get burned. The correct question is "How does this software
calculate ABC codes?" One package might only consider unit value,
another historical usage, while a third considers projected usage,
average on-hand value, lead time, and user-defined criteria. The
resulting "suggested ABC codes" will be remarkably different.
Once the software has suggested ABC codes, can you override them for factors that your software didn't consider? Can you mark your overrides as temporary or to be retained the next time ABC codes are auto-calculated?
Do you need codes beyond C? D is frequently used for obsolete or
inactive items. I have one client that has ABC codes all the way to
J.
Cycle count selection criteria and triggers
This is where great software is differentiated from the also-rans. At
a minimum, cycle counts should be suggested based on a predefined
number of A's, B's, and C's per cycle period. Better software will
take into consideration when each item was last counted, including
recognition of transfers.
Do you want to do cycle counts for all locations for a given part, or for selected warehouses, stocking locations, bins or work centers? Many software programs do it one way or the other. Good packages give you the choice. Some packages will also allow cycle counts by project, job or work order.
What is the primary purpose of cycle counting? To make sure the quantities in the computer match the actual quantities on the floor? No. That is just a side benefit. The primary purpose is to identify leaks and holes within your systems so that you can plug them up. Keeping this in mind, it makes sense to do the cycle count as quickly as possible once a discrepancy is identified.
What events will cause your software to trigger a suggested cycle count? Some packages trigger a suggested cycle count whenever there is a negative inventory balance. (A prerequisite question is whether the software even permits you to define where and when negative balances will and will not be allowed.) Some packages trigger a cycle count whenever there is a transfer discrepancy or an inaccurate pick. If an item is adjusted during one physical inventory or cycle count, some packages will flag that item to be counted in the next cycle, just to make sure that the adjustment didn't miraculously reverse itself as it so often does.
When is it easiest to do cycle counts? When there is the least
amount of inventory. That's why it is nice if your software suggests
that you do a cycle count whenever an item changes to a zero balance.
Go out and make sure there really aren't any. Really good software
will also trigger you to do a cycle count of the few items remaining
on hand right before an enormous shipment is expected to arrive.
Freezes
Things keep happening between the time that a cycle count starts and
hours or days later when the final reconciliation is posted. How do
you stop transactions from happening during the cycle count? How do
you allow transactions to keep happening during the cycle count so
that production can continue? How do you do a recount? These are
questions addressed by "freeze" features.
Freeze scenario one: Don't allow any transactions that would affect the inventory being counted. Allow resumption of activity after the physical count is complete but before all adjustments have been made.
Freeze scenario two: Allow physical transactions to continue, but hold all related transactions from posting until the physical count is complete.
If software has freeze features at all, they will be one way or
the other. Which freeze scenario fits the way you want to run your
business?
The basics
One thing I've learned from helping more than 100 companies select
software is never to "assume" anything. Here are a few basic features
that every cycle counting package should have, but many don't.
Many packages will generate either count tags or checklists, not a choice of either. Some packages are unable to print tags or checklists by stock location and bin number.
A package should provide book to actual variance reporting and should do automatic adjustment posting to both inventory and the general ledger. It should put an item on hold pending a re-count if outside of user-defined tolerances. It should provide an accuracy summary report. It should maintain a historical audit trail of cycle counts and physical counts with the ability to view just the history of a selected part. You would be amazed at how many very expensive packages are missing one or more of these basic features.
One of my clients spent six digits to modify their physical and cycle counting software before finally throwing up their hands and replacing the entire MRP II system. If your software specification simply asks, "Can this software do cycle counting?," be prepared to live with poor inventory accuracy, stammering answers to your bosses' questions, and hundreds of hours for frustrating shortcomings that a better software package could have handled in a nanosecond.
For more information about this
article, input the number 3 in the appropriate
place on the
November
Reader Service Form