3.1 benefits of inventory management
Post on 28-Jan-2022
10 Views
Preview:
TRANSCRIPT
3.1 BENEFITS OF INVENTORY MANAGEMENT
"he main reasons for inventory to bn kept ore to:
- Improve delivery to customers.
Protect against variations in delivery by suppliers.
- Enable the use of lot sizing.
The above points can be achieved with any inventory control system, like
manual cardex systems, but not necossarlly in the most efficient manner.
Typical manual cardex systems usually have numerous problems associated
with thum. The following points represent some of the probloms which
existed at Sulzer before the proper Introduction of the Inventory Man
agement module.
- Cardex cards registers were too slow and cuirbersome for invento
ries with large numbers of parts in stock (15 000 different part
numbers in our case).
- Cardex stock card soon became unreliable.
- Production Control and Sales resorted to physical checks.
- Stock chasers were needed to locate the goods.
- Extra buffer stock wan needed.
Planning became increasingly difficult.
Physical staging for customer orders was aone too soon, so that
real shortages could be identified.
The Inventory Management Module12
- Stockroom w a s not closed and unauthorised withdrawals took place
(to replace scrapped items).
- Inventory accuracy was below 50V
- Expediting was constant, allowing no time for proper planning and
special projects to improve stock control.
- Annual shutdowns were needed to recount stock. This was usually
done by inexperienced people and always resulted in lost pro
duction and large error<i because of Incorrect item identifica
tion.
- " -gh Materials Manager turnover, due to the difficulty of ob
taining control and to the constant pressure exerted on them to
solve all of the above-mentioned problems (five managers in the
period of two years).
After the proper implementation of Inventory Management and its
spin-offs, like SLALOM and Cycl» Counting, *’ * v'ints mentioned above
have completely disappeared.
The main difference between the failure of the manual and the success of
the fully computerised system, is the level of stock accuracy. One of
the many reasons for a high accuracy to be so difficult to achieve, is
due to the high volume of paper and goods flow that passes through the
warehouse. All purchases and manufacturing orders placed by Sulzer's
Planning department are handled at some stags by the warehouse personnel.
The opportunities for errors are great and are not always confined to the
warehouse. As shown in figure 3.3, there are many departments Interfacing
with the Inventory Management module and errors originating there are
often carried through to stock, sitting there until they are picked up
in the next cycle count.
The Invontory Management Module 13
nxx)R
Scrap
PURCHASING ORDER
RELEASE
Released
Shop Orr*er
data & quant it)
Purchase
order data
and quantity Material*
Requisition*
allocations]
JShop order \
Date & Quant ityl
( INVENTOHY
L MANAGEMENT,
RECEIVING &
INSPECTION
Inventory
adjuetments
Unschedu l«.a
Returned
unused issue
Flnished
Product
requirements
ORDER ENTRY
& FORECAST
(MASTER SCHEDULE)
Issued
component
requisition*
^Shipments
customer*
('Receipts to
stores
STOCKROOM
FIGURE 3.3: The Inventory Recording System, (8).
The Inventory Managemnnt Module
The proper interface between Stores and each of the other department* is
very Important for the purpose of accuracy. For example, tlO\ of all stock
transactions between Shop Floor, Inspection, Receiving and Purchasing
must be of the pre-authorised kind, (8). This means a transaction that
has b«en planned for.
Independent transactions such as miscellaneous issues and receipts,
should he kept to a minimum, as this is a cause of trouble for everyone
from Buying to Accounting.
3.2 INVENTORY MANAGEMENT OVERVIEW
Apart from control of inventory transactions. Inventory Management also
serves other purposes *s shown in figure 3.4.
"fita m onotns
to ruftCMAsiNG iiura
' A I N T A I NImvI m v on v
ACC 'JAACY
INtI*h
moats
IN v l« *TO *V
TRANSACTIONS
) M A I N T A I Nom>i n siAtws
FIGURE 3.4: Function of Inventory Management Module,(8 ).
The Inventory Management ModuleIS
i.
The proper interface between Stores and each of the other departments is
very important for the purpose of accuracy. For exariplc,, 80*. of all stock
transactions between Shop Floor, Inspection, Receiving and Purchasing
must be of the pre-authorised kind, (8). This means a transaction that
has been planned for.
Independent transactions -juch as miscellaneous Issues and receipts,
should be kept to a minimum, as this is a cause of trouble for everyone
from Buying to Accounting.
3.2 INVENTORY MANAGEMENT OVERVIEW
Apart from control of inventory transactions. Inventory Management also
serves other purposes as shown in figure 3.4.
i n t i n k 'm r v ■ ? J
T0*V
ACTIONS
MAtUt AIU
INVtMTACC'jti
MAINTAINonot* STATUS
FIGURE 3.4: Function ot Inventory Management Module, (8)
The Inventory Manft*emont Module IS
The functions of releafing Manufacturing and Purchase orders, creating
Shop Papers and maintaining Order Status and Management Reports are well
addressed by the system. These are routine procedures which have little
impact on stock accuracy. This Order Cycle, as shown below, is quite
simple and can be managed by anyone.
FIGURE 3.5: Order Cycle,(8 ).
As mentioned before, Inventory Management handles the order processing
cycle in a very acceptable manner, but unfortunately the way it handled
The Inventory Management Module 16
inventory transactions was not as efficient. Inventory Management's
shortcomings were:
- It allowed balances-on-hand to be negative.
- ?nly one part number could he packed per location, resulting in
inflexibility and poor space utilisation.
- No separate facility for quality control.
Management and the project implementation group then decided to introduce
another module available in the market, which excels in precisely those
areas in which Inventory Management is inadequate. This module is called
SLALOM and its basic functions are explained in the next chapter.
......... //.........
The Inventory Management Module
4.0 SLALOM - THE VITAL ADD-ON SYSTEM TO INVENTORY
MANAGEMENT
SI»AU)N Is basically <ui ADD-ON package to the Inventory Management module.
It controls and records all types of inventory transactions and then
passes this information to Inventory Management twice a day in batch form
(see figure 4.1).
FIGURE 4.1: SLALOM Interfacing with Invantory Management, (8 ).
SLALOM - The Vital Add-on System to Inventory Management 18
SLALOM keeps a complete transaction history per item number, which is most
beneficial for cycle count error reconciliation, thus contributing to the
improvement of stock accuracy and to determining of the causes of errors.
Ona of the added advantages of SLALOM over Inventory Management is the
facility which allows the storeman to pack goods in any randomly chosen
location. This means that there is a greater storage flexibility, al-
though more discipline is needed in accur^trly recording the storage lo
cations used. This worker discipline also contributes to a greater stock
accuracy.
With SLALOM, the packer can accommodate more than one part number in the
same location, which unlike Inventory M&nagement, results in much higher
space utilisation. In fact, if management were to continue with Inventory
Management, without SLALOM, the warehouse would soon run out of ^.pace,
although many pallets would only be a quarter full. This was one of the
major factors contributing to the purchase of this add-on systea.
Besides the points already mentioned, SLALOM also has Lhe capability of
controlling the "shelf-life" of a component through cycle checking. This
is an optional function and c*n be tailored according to the user's needs.
Another optional function, often used by pharmaceutical industries, is
"Batch or Lot" control. With Batch or Lot control, a specific lot can
be tracked from receipt through quality control to stores and finally to
the order.
SLALOM is a comprehensive and user oriented package, with menu-driven
screens for each type of transaction, making it particularly suitable for
semi‘skilled terminal operators. The main menu, with the most immediate
options is show/* in figure U.2, and the detailed explanation of the var
ious transaction codes is given in Appendix A
SLALOM - The Vitel Add-on System to Inventory Management 19
FIGURE 4.2: SLALOM Menu, (8 ).
Another boost to the higher stock accuracies is the existence of a special
option for Quality Control (s«e figure 4.2). The transaction types
available tc this option permit a much greater control of data accuracy,
since they act as filters for Incoming stock originating from Goods Re
ceiving oi Production Workshop (see Appendix,A). Only when stock is
cleared by inspection, can it be transferred into stores and be made
avallable.
Another advantage over Inventory Management, is that no SLALOM trans
action code allows for the stock balance-on-hand to become negative. This
is done by aborting the transaction which would produce the negative
balance.
Before the Materials Handling Departmert could benefit from the sophis
tication of the S1.AL0M system, a number of things had to b" accomplished,
ramnly:
1. The suitability of the S1.AL0M package had to be analyses an'i tested,
so that customised modifications could take place.
j
SLALOM - The Vital Add-on System to Inventory Management 20
2. A total stocktake had to be done, so as to feed SLALOM with correct
and up-to-date stock information.
3. The training of all personnel had to be completely done before the
day of "switching on" to SLALOM.
The approaches taken to implement the above requirements are the subject
of the following chapter.
SLALOM - The Vital Add-on System to Inventory Management 21
5.0 SLALOM IMPLEMENTATION - THE PROJECT MANAGEMENT APPROACH
This chapter's aim Is to show the reader more than Just the implementation
techniques for a system which is instrumental in the increase of inventory
accuracy and departmental productivity. The nor* refers to the potential
pitfalls that managers and project leaders have to be aware of, when im
plementing any type of computer system.
The analysis given stems out of the author's own experience, although much
of it can be considered as true general problems met when one is dealing
with the difficult subject of Project Hansgttmrnt (10).
5.1 THE MRP-II PROGRAMME
Top management has committed itself to introduce the full MRP-II programme
in the space of two years. For the purpose of control and monitoring,
it was considered to express the entire programme through a CPM (Critical
Path Method) network, as shjwn in figure 5.1.
Note that some of the modules, like PDM and IN, have to be installed prior
to the installation of the other modules. Unfortunately, these are also
the two activities with the longest lead tim«>, so any delay at these
points would eventually delay the entire programme. Since all activity
times are static, which is a typical feature of the CPM network, there
are great pressures if delays occur.
SLALOM Implementation - The Project Mandgem^nt Approach
ACTIVITY DESCRIPTION TIME (Months)
A: Inventory Management (IM) 11
B: Product Data Management (PDM) 11
C: Purchase Order Control 2
D: SLALOM 2
E: OMAS 2
F: Order Entry and Invoicing 2
G: Marketing Management System 2
H: Materials Requirements Planning 3
I: Production Control and Costing 3
(Cost ing)
J: Production Cortiol and Costing 3
(Shop Floor)
K: Capacity Requirements planning 2
L: Accounts Payable 2
M: Accounts Receivable 2
N: General Ledger 2
0: Wages 2
The critical path takes 24 months to complete.
FIGURE 5.1: MRP-II *>rogram Natwork
SLALOM Implementation - The Project Management Apprcach 23
As might have bean expected, this delay had to happen and the time taken
for activities A and B took 20 months Instead of the predicted 11 months.
This is because PDM and IM are the most difficult modules to carry out
and since they are basic to all future modules they cannot be rushed.
Product Data Management consists of the following lengthy tasks: the
creation of all itwm records in a central data base for all stocked items;
the structuring of the bill of materials for all standard and non-standard
products;the creation of work routings for each manufactured item through
the various machining centres. Different points of view between the En
gineering and the Manufactu*ing divisions concerning the above issues
further delayed the implementation of P.D.M.. The unf*mi1iarity with
computer based systems and the lack of local expert support was also a
major contributing factor to this delay.
K-essure for the next projects started to mount, specially for SLALOM
which lies on the critical path and therefore has an enormous Influence
on the success of all future packages, including MRP. Time meant money
and the "opportunity costs" figures of R2000.U0 for each day’s delay ware
being quoted. Thic figure was based on interest alone, which would be
generated from profits arising 'rom a successful MRP-II programme These
profits can be attributed to the 25% reduction in work in progress, a 25%
reduction in stock and a 10% increase in production (7),(8).
5.2 THE MATRIX STRUCTURE AND ITS PROBLEMS
Another more serious pressure was being exerted on the success of SLALOM.
The business was incurring great losses because the prolonged stock in
accuracy, resulting in low customer service levels and deadlines not being
met.
SLALOM Implementation - The Project Managumc-'t Approach 24
Therefore, a matrix structure, as shown In figure 5.2, was put together,
where a project manager could be nominated from Any of the functional
departments. In SLAI^OM's case, the Information Systems Department Han-
ager was chosen as project leader.
PUNT MANAGER/
PROGRAM MANAGER
Functional Manager* SALES ENGINFERING
IMATERIALS
COVTROL .
oject managers
__ >w
AF
f *f ^
FIGURE 5.2: Matrix Structura for Project* Management
The project was now ready to be started and everyone invclvod knew that
those two months, within which this task had to be comploted, were too
short. The Information Systems department held a meeting with the Mate
rials Control department to determine the most important points required
to achieve the desired accuracy level in the shortest possible time.
SLALOM Implementation - The Project Management Approach2S
The following f. _>ints formed part of the agenda:
1. Bring in external consultants to analyse and improve the present
paperfiow system in the store* -nd other directly related areas, such
as Goods Receiving and Inspec
2. Have the anrval stocktake shutdown done immediately, for a period of
6 days, so that the "take-on" balances for SLALOM become 100\ correct.
3. Install a security system for the warehouse.
4. Consider the imminent purchase and implementation of the SLALOM
add-on package, because of its advantages and disadvantages to the
company's present stock condition.
5. Educate all stores personnel by means of in-depth training, focusing
on the new system about to be introduced.
The first point tackled was to call the SLALOM agents and to test this
package under the conditions existing in the company's old stock control
system. The tusting resulted in clashes between the Information Systems
and the Materials Control managers, which seriously disrupted the effec
tiveness of the project team.
According to the Materials manager, the package was not suitable for
Sulzer's particular environment, since it had been initially dosigned for
the pharmaceutical industry, which is vastly different from a manufac
turing and Jobbing environment.
The major difference is the very strict movement control for every batch
of raw materials or finished products in the pharmaceutical Industry.
Each batch can never be mixed with another of the same kind even if it
comes as part of a split order. This is an industry regulation for all
health related products. In the case of Seller's manufacturing envlron-
SLALOM Implementation - The Project Management Approach 26
ment, this strictness cadi SLALOM too inflexible as a stock control sys
tem, unless it was modified.
The Materials Manager wanted more time for retesting and for modifications
to be done, before SLALOM was implemented. But the project leader disa
greed, saying that the SLALOM agents would Se reluctant to change anything
in their package.
Following thia, one manager was always trying to stall the project while
the other constantly counteracted the other's attempts. Another serious
problem was the shutdown count, which having been scheduled too soon, did
not allow enough time for the proper training of stores personnel and for
a complete pre-stocktake item identification.
By the scheduled oate for the stocktake, none of the above problems had
been proparly addressed. Meanwhile, SLALOM got installed absorbing all
the "take-on" balances and was also left running 01 lte own without the
old stock control system running in parallel.
Problems continued to appaar for a long time after its implementation ind
the project team was kept occupied in solving a multitude of problems,
such as:
People still needing extensive training on SLALOM.
- SLALOM was eventually being modified in-house to suit the working
condit ions.
Working procedures wore also being changed, to comply with the
naw system's demands.
- Errors were being constantly introduced, because of human inex
perience end partial module incompatibility between SLALOM and
Inventory Management.
SLALOM Implementation • The Project Management Approach 27
5.3 POINTS TO OBSERVE WHEN IMPLEMENTING COMPUTER SYSTEMS ON A PROJECT BASIS
About th* Project Team
a. Matrix structures may be well chosen in theorv, but in practice
it brings about a certain degree of conflict (10).
b. The choice of the project leader must be done cautiously. It
works best at times to have a3 a leader, the person who is going
be responsible for the system in the future. In the above case,
the best choice could have been t' /^nerials manager.
c. The Information Systems depart.«nt will most likely react
defensively to any potc, *1 problems that might threaten the
introduction of a new co. iter system of their liking.
d. Be cautious when faced with the decision of having a
"job-wel1-done" or a "job-done-in-tlme" type of project. Look
at all the long term consequences.
About the Systems
a. This type of project is more of a PERT (Program Evaluation and
Review Technique) network nature than CPM, where activity timos
are fixed, because of the uncertainty in the time estimated to
complete an activity. This seoms to be a characteristic of most
projects involving computer technology.
b. There could be a general tendency for many managers to underes
timate the implementation of a computer system.
SLALOM Implementation - The Project Management Approach 28
c. Like most projects, the obstacles encountered are about 5% tech
nical and 95* people originated problems (10).
d. Generally, computer sales agents do not know enough about a
company's environment or the software they are selling. As so
appropriately put by Prof. Woolsey during a Production and in
ventory Management lecture: "most computer packages are not de
livered to your doorstep, they are abandoned there".
Before buying a new system, get the agents to sign an agreement
that includes a clause about post-implementation programme mod
ifications and maintenance. Otherwise, the project costs can be
lignificantAy altered.
SLALOM Implementation - The Project Management Approach 29
With SLALOM now properly installed, debugged and customised to the oper
ations' specific needs, the errors caused by computer failures or faulty
logic in its software program are so few as to be n e g l i g i b l e . The next
step in Improving stock accuracy was to create an effective cycle counting
programme. This chapter will focus on the objectives and advantages of
using the cycle counting technique.
6.1 CYCLE COUNTING VERSUS ANNUAL PHYSICAL INVENTORY
Today's management is perceiving greater advantages resulting from a
continuous cycle counting programme as opposed to the traditional annual
stocktake. Plossl(l) describes the situation as follows: "There is no
longer any doubt that the Annua] Physical Inventory is an expensive farce
which should be eliminated. Only as a means for validating the total
investment in inventory is it acceptable as a device for finding and
fixing errors in individual item records it is not only useless, it will
generate more errors than it will eliminate".
From the literature survey such as Plossl(l), (2), Cantwell(3) and IBM's
MRP and Cycle Counting course(S), and having experienced both types of
counting techniques, the author can best compare these two types by means
of table 6.1.
Cycle Counting 30
TABLE 6.1: Annual Physical varsus Cycla Counting
Annual Physical* Stopped and lost production.
* Week-end work at premium cost.
* Counted by inexperienced pers
onnel without adequate product
knowledge thus leading to:
i. Items overlooked
ii. Items counted twice
iii. Errors in counting
iv. Identification Errors
* Inability to trace causes of
error. Errors could be ona year
old, i.e. introduced since the
last annual count.
* Large number of errors since
last count.
* Time constraint and haste
* Second counts are needed to
to verify first person's count.
* Does not assist in the contin
uous monitoring of accuracy.
Cycla Counting* Eliminates the loss of productive
t ime.
* Done during aormal working hours
by one person at low costs.
* Development of specialists who become
efficient in obtaining good counts and
good product knowledge.
* Timely detection and correction of
conditions causing errors. Host errors
are at most 2 to 3 months old, i.e.
since they were last cycle counted.
* Few errors which allow for
focusing on problem areas.
* Counting is done according to a pre-scheduled programme, where time
is not a constraint.
* No second count is needed.
* High level of inventory accuracy with
continuous monitoring of accuracy.
Cycle Counting 31
Author De Freitas P J F Name of thesis Achieving and maintaining inventory accuracy in South African MRP-11 environment 1986
PUBLISHER: University of the Witwatersrand, Johannesburg
©2013
LEGAL NOTICES:
Copyright Notice: All materials on the Un i ve r s i t y o f the Wi twa te r s rand , Johannesbu rg L ib ra ry website are protected by South African copyright law and may not be distributed, transmitted, displayed, or otherwise published in any format, without the prior written permission of the copyright owner.
Disclaimer and Terms of Use: Provided that you maintain all copyright and other notices contained therein, you may download material (one machine readable copy and one print copy per page) for your personal and/or educational non-commercial use only.
The University of the Witwatersrand, Johannesburg, is not responsible for any errors or omissions and excludes any and all liability for any errors in or omissions from the information on the Library website.
top related