applications

Computers in retailing

Point-of-demand stock control

bY SIMON LUCAS

ny retail chain considering com-

G puterization has the choice of

oing to a system which is driven from the point-of-sale (POS), the point-of-demand (POD), or the stockroom. Underwoods had this choice at the beginning of 1982. It was running a stock control system on a BCL computer, and accounting and payroll systems on IBM equipment. The stock control system was by then nearly five years old, and the system was working to capacity. This, and the need for better management in-

formation, prompted Underwoods to take its data processing a stage fur- ther. As we felt we were ready to move on from a stock-based system, that left POS or POD.

Point-of-sale systems are difficult to cost-justify, unless you can make good use of the large amounts of data they generate. There was little value in moving Underwoods from clerical data capture straight to point-of-sale, when the central services were not geared up to extract the benefits of all

Abstract: The article describes the functioning of a point-of-demand system for stock control. The system described is database-oriented and integrates planning, buying, stock control and distnbution and management information.

Keywords: data processing, stock control, point-of&mmtd systems.

Simon Lucas is a manager with Underwoods.

the information captured. So point- of-demand was chosen - collecting

data on stock required in the shops. At that time Underwoods had 23

branches stocking a very complex mix of merchandise - from combs to televisions - with a corresponding mix of stocking and ordering proce- dures. That mix, coupled with the fact that we wanted a fully integrated system to cover purchase ordering for our own warehouse through to stock- ing, distribution and accounting, meant that while we were not ready to take advantage of the most sophisti- cated online systems, many of our requirements could not be met by systems then available. Or, for that matter, currently available.

We were also keenly aware, that we would make increasing demands on the system with experience, so we wanted a system that could be exten- ded in the future, perhaps to accom- modate point of sale. Datasense Ltd, specialist supplier of consultancy and software for IBM business systems, had developed our original stock con- trol system, and was therefore the logical choice for this next stage. We decided to move to an IBM System 38 for the new system, designated the Retail Inventory and Management Accounting System (RIMAS).

System development

Once it was agreed that the concept of order entry in the shop was the

~0127 no 1 january/february 1985 0011-684x/85/010045-03$03.00 0 1985 Butterworth &Co (Publishers) Ltd. 45

sensible path to follow, we prepared a detailed functional specification com- pleted at the end of 1982. Work on developing the system started in April 1983 and was scheduled for 500 man days. That relatively short develop- ment time was due both to the time and effort which had gone into the specification, and to the architecture of the System 38 - a point I shall come back to.

RIMAS was first implemented for a new shop, which involved the neces- sary nightmare of maintaining an item catalogue of about 12000 lines on both old and new computers, up- dating in parallel.

The next stage was to bring the other shops onto RIMAS. The idea of transferring all data across from the old system was rejected as being cumbersome and time consuming. For high-price items, like televisions and audio equipment, the shops could easily let us know what they had in stock. For all other items, RIMAS calculated stocks on the basis of the first order. The system holds data on what the stock level should be, so we let it do the work of calculating the base information.

Point-of-demand

A computer-printed label is produced for each of the items stocked, apart from exceptions like high-cost items. This gives the maximum stock level to be held and the reorder level for that item in that shop.

The prescribed levels are revised in the light of the order history for a specific shop. All the Underwoods shops have unique profiles and it is very difficult indeed to find a pattern which suits every one. So a particular- ly important feature of RIMAS is that it allows us to respond individually to each shop.

Data on item throughput is held to two decimal places, which gives a highly accurate basis on which to calculate stock levels, and weightings can be adjusted within the formula for

factors which operate company-wide. Clearly, throughput cannot be the only factor in calculating levels. Some items may be very slow-moving, but need credible depth (enough of them on the shelf) for the customer to even see them.

The shops have an opportunity to feed into the revision process. Regular order level reports are edited ‘by exception’ and are returned for changes to be entered onto the sys- tem.

The point-of-demand concept means that control remains in the shop with the manager. RIMAS pro- vides the manager with the para- meters for sensible decision making. In fact, it has placed greater responsi- bility for decision making on the shops. Should a manager order stock over the prescribed maximum level, the system will not reject the request - but he/she is now accountable for the decision, and can be asked to justify it. We can also look at the reordering pattern, to see who has not ordered what from such and such a date.

RIMAS also enables managers to discriminate; they can simply look at the shelves to see which items are not at the right level, and they can then reorder for just those items.

Data collection

To collect the data, shop staff use a portable terminal. Bar code readers were rejected, partly on cost grounds - one wand per shop, plus a central printer - but mainly because of the physical difficulty of coping with an extra piece of equipment and cable at the top of a ladder.

Each terminal will hold details of up to 1500 items. Data is sent to the System 38 via an acoustic coupler, and a simple handshake confirms that transmission has been completed suc- cessfully. If there are problems with the line, the terminal will retransmit up to seven times automatically. The average time taken for one transmis-

sion is about 90 seconds. RIMAS reads the transmitted files

from back to front. If an item has been ordered more than once, it takes the order last entered (first read) as the correct one and ignores those entered earlier. Staff may be inter- rupted when ordering, or may have second thoughts about an item. Thus, they can always play safe by entering the item, knowing that if it is a duplicate no harm is done.

Turnround time

Shops order once a day (twice if necessary) and the average turnround has dropped from three, four or even five days to 24 hours. Incoming orders are stored on floppy discs, which RIMAS reads four times a day. They are consolidated into ‘picking’ files. If stocks are not available to meet de- mand, the system ‘remembers’ who will be disappointed. It holds a regu- larly updated grid reference of the warehouse so we can spot areas of slow, medium, and fast-moving items and can spot where work is stacking

up* We call off picking notes to be

printed, one note per warehouse loca- tion area per shop. RIMAS also pro- duces a summary to indicate which picker has what note - there is potential for looking at picker produc- tivity, if we want to.

The note incorporates the intended delivery date, but we can change it to reflect the actual date if pickers are very busy, or off sick. RIMAS prints a delivery note showing what can be delivered, plus details of the route and the shop. It also picks up the details of items that cannot be supplied, and includes a request to the shop to reorder.

We also have about 1000 high-cost lines which show a slow rate of sale - televisions, and so on. For these, we have developed a stock profile for each of six types of shop. The empha- sis is on stocking a credible range of items, not on the number of models of

46 data processing

applications

There are 32 branches of IJnderwoods, the chemist.

each item. Twice weekly, RIMAS compares the book stock against the model stock and produces a picking

note for the warehouse. Book stock for high-cost lines is kept up-to-date by entering sales from copy customer receipts listing the items. This sales data could be recorded at the point of sale, with remote POS equipment.

If a new line is introduced, we decide on a stock level for each of our six types of shop, and the system automatically works out the alloca- tions - instead of 31 decisions, we need make only six. The situation is made more complicated by the fact that some of these items carry com- mission, so we do have to ensure that stock levels are kept up for these items.

Buying decisions

The system produces buying sug- gested order reports, which the buy- ers can edit (again, on this system, by exception). These reports are printed

according to a schedule held on file, so that regular stock reviews by the buyers are not overlooked. It is the buyers who adjust order levels to take account of promotions and seasonal peaks, although it would be quite

feasible for RIMAS to adjust levels to take account of Christmas, for example. It is a question of where the effort is best applied - in fine tuning, or in exception editing.

4s an indication of the savings the system has made, our stock control

~0127 no 1 januarylfebruary 1985

department has been halved since the system was installed, while the num- ber of shops has increased by eight.

The System 38 itself requires no full- time staff, all the necessary work of maintaining the item and branch cata- logues, raising purchase orders, and recording the receipt of merchandise, is done by the relevant departments. Even the usual end-of-day, week or month consolidations do not require special handling by an operator. We enter a simple instruction before we

go home, and RIMAS produces all the reports we need ready for the next day.

Management information

RIMAS handles all the normal opera- tional report requirements; such as ‘price change notifications’ to our stores, etc. More importantly, it pro- vides highly comprehensive manage- ment information.

Stock, sales and margin reports are available at five levels of detail: com- pany, group (toiletries, audio, elec- trical goods, etc.) subgroup (40 of these), product group and item. This information can be further analysed by store, or stores within merchandise classification.

RIMAS retains up to two years of sales and gross profit statistics per product group and per store for each accounting period. In 1985 we will be able to compare our business perfor- mance against last year.

AI1 financial totals can be presented

at cost or at retail and if our merchan- dise range changes as our business expands, we have the facility to resort the product classifications without losing the benefit of comparing like with like, from one year to the next.

Analyses are available by buyer and by supplier. It is sometimes useful to be able to compare margins on sup- pliers within the same product area. We can also see how specific shops are performing in comparison with over- all company performance and we can budget for planned stocks and sales by subgroup.

The choice of hardware

I have left the question of hardware until last, but in fact the choice of the System 38 was critical for the develop- ment of RIMAS - and continues to be so. The advantage of the System 38 is first, that it is a database-oriented machine. That means that if the information is in the system, we know we will be able to get at it in virtually any form we require. Be defining a number of logical files which map onto the physical disc files, we can use different keys to get at the informa-

tion. Second, as our business grows, System 38 can be progressively up- graded, both in terms of additional disc storage and CPU processing per- formance .

RIMAS integrates the key func- tions necessary for good stock man- agement, namely, planning, buying, stock control, and distribution and management information. The Sys- tem 38 currently supports 20 screens in the relevant departments at Under- wood’s head office and in the ware- house. The database approach is clearly ideal for such a highly inte- grated system, because the integration starts at file level record-locking is inbuilt, and it is very straightforward for programmers to implement the protection mechanisms appropriate to this type of multiuser system. cl

Underwoods (Cash Chemist) Ltd, White City Industrial Pk, Wood Lane, London W12, UK.

47