Automated and Simplified Tray Stores Ordering System
By Kevin Loughrey
1988-1989 In late 1987, I was seconded as an exchange officer to serve in the British Army. My posting was to 27 District Workshop, located at Warminster, in the South West of England. The workshop's location was most probably, to some extent the result of the British Army's School of Infantry being located at Warminster and the Salisbury Range training area being close by(as also was the famous Stone Henge). I occupied the Production Manager's position and was also the second in charge of the workshop; the workshop being commanded by a Colonel (Colonel John Skinner) and my rank being Lieutenant Colonel. 27 District Workshop was the largest workshop in the British Army. It not only supported local equipment but also performed 3rd and 4th line program rebuilds of fleet equipment operated throughout the British Forces.
Having Colonel Skinner as my Commanding Officer was a happy coincidence because when I was the Officer Commanding of ACT Workshop Platoon, at Duntroon
, in 1979, then Lieutenant Colonel Skinner was the Staff Officer Grade 1 (EME) at 2 EME Gp, HQ 2nd Military District, located in Sydney. ACT Workshop Platoon was under the command of HQ 2 EME Gp and Lieutenant Colonel Skinner was effectively my Commanding Officer.
When I arrived at 27 District Workshop the state of the workshop floor was very untidy. It was a dark and gloomy place because of inadequate lighting; something the unions were constantly (and rightly) railing against. The lights were an orange argon type and this colour gave a depressing feeling to the workplace. Staff were under considerable pressure because of the reforms, aimed at sheeting home financial accountability, introduced by the Thatcher Government. In general, the staff at the workshop were highly motivated, well trained and of high quality in terms of their honesty, work-ethic and diligence. The stress of coping with sudden change though had had an adverse effect on things such as workshop tidiness and basic organisation.
27 District Workshop was the largest of all the district workshops in the UK Ministry of Defence. It undertook some overflow programme repair and so verged on being a Base Workshop. 27 District Workshop tended to be loaded with equipment which the other Base Workshops did not wish to handle for a variety of reasons. In some cases, the equipment was obsolete, the parts were always difficult to obtain and the equipment was often in a state of advanced decay. 27 District Workshops was smaller than most Base Workshops but larger than all the other District Workshops. It was therefore a good testbed. It it worked at 27 District, it would most likely be effective in all the other Base and District Workshops.
The Problem with Tray-stores
One aspect of workshop operations that was causing considerable disruption to efficient production was the matter of repair parts supply and, in particular, the supply of "ready-to-hand" parts positioned in trays on the production lines and work areas. Normally, within a workshop, there is a sub-organisation responsible for repair parts supply. When repairing an equipment, one normally attempts to perform an inspection in order to determine the parts that will be necessary to perform the repair. It is often not possible to predict all of the parts that will be required. Certain equipments also do not lend themselves to pre-inspection. With these equipments, it is necessary instead to inspect and repair at the same time. It is also not cost effective to have a totally centralised repair parts holding from which the parts are fetched every time there is an unexpected requirement. For all of these reasons, it is normal practice in a workshop to have on hand, in trays, a variety of fast moving and generally inexpensive parts for the immediate use tradesmen. These trays, for convenience of management, are generally located in groups, associated with workshop cost-centres, and spread throughout the workplace. They are referred to as "Tray-stores".
At 27 District Workshop, there were 177 tray-stores located throughout the workshop. Each tray-store consisted of as many as 500 trays with a number of parts or an assemblies being held in each tray. The average was around 50 trays per store; the total number of trays being held on the shop floor was at one time counted as being 8924 trays. In all, at that time, there were 5,598 "line-items" being held on the floor with an estimated value of £132,000.00 Sterling.
Tray-stores were a major source of production disruption. The problems with their managment and upkeep being:
- parts shortages generally, ie, parts not being on hand when needed;
- improper provisioning (this resulted in either no stock or too much stock);
- stock number changes leading to incorrect ordering;
- clerical mistakes leading to incorrect ordering; and
- the amount of labour that was being consumed trying to provision and generally manage the situation
A computer system, called ARROW and developed by the Royal Electrical and Mechanical Engineers (REME) Data Centre, was used to manage the stores and the production control in 27 District Workshop. ARROW ran on an ITL mini computer. It had a text and menu interface and, for its day, it was quite advanced. ARROW connected to a large number of dumb terminals throughout the workshop using RS-232, an asynchronous serial system of communications.
The Good Fortune of Having Bob Willcox and Doug Bonner on My Team
The computers were administered by a small staff headed by Mr Bob Willcox. Bob had two assistants, one of them being Doug Bonner who played a significant role in this and another project. Bob and his team were excellent. They were the powerhouse of the computer administration in 27 District Workshop, if not the entire REME. Them being there was an incredible coincidence of good fortune for me as will become evident later in this story.
My Background Prepared Me Well
CO of 1 Base Workshop, Bulimba, Brisbane.
Prior to coming to 27 District Workshop, from 1986 to 1987, I had been the Commanding Officer of 1 Base Workshop Battalion at Bulimba, a suburb of Brisbane the capital of the State of Queensland in Australia. The Australian Army had a computer system similar to ARROW in its Base Workshops. This was called MAWD, standing for Machine Assisted Workshop Documentation. MAWD purpose was twofold. Firstly it provided the means by which workshops could record the process of repairing equipment, including the ordering, consumption and control of repair parts. Secondly, it gathered data that was then inserted into a central database system called MODERNISE.
In 1980 and 1981, I was put in charge of EME Systems development in the Australian Army. In that capacity, I conceived and developed a new family of computer systems, EMEDATER and EMEMic, the emphasis of which was that of helping people perform their work in the workplace; the logic being that if the systems achieved that aim then the data that would be a by-product of this would be accurate and complete; something that the data in MODERNISE was not. I saw microprocessors as they were called in those days as being the future. I wanted the Australian Defence Force to adopt a microprocessor called the Onyx. It ran a Motorola 48000 chip with a 64 bit Math Coprocessor and came equipped with a revolutionary storage device called a Winchester Drive, capable of storing a massive 40 Megabytes of data. The Onyx could support up to 4 megabytes of dynamic RAM and ran the UNIX operating system. The C programming language was commonly used to write applications on this computer but high level compilers for FORTRAN and COBOL were either available or under development. The Onyx cost $4,000.00, imported from the US. I drove to Sydney to see one just to make sure it was not a figment of a sales-executive's imagination. Instead of buying the Onyx, Computing Services Division, then the centre of the Defence Computing Bureaucracy chose to purchase the newly arrived IBM PC. It too cost around $4,000.00 (a friend of mine bought one of the first ones to come to Canberra!) but it was only a shadow of the Onyx. Besides not having a true 16 bit architecture, unlike the Motorola chip, the IBM 8088 could not handle data and graphics at the same time. The PC could only support 256 kilobytes of dynamic RAM and did not have a hard drive. Importantly, even though IBM claimed the PC could be networked using RS-232, a bug in the BIOS meant that every time the PC wrote to the screen, the Programmable Interrupt Controller that handled the Universal Asynchronous Receiver Transmitter, essential for RS-232 communications, was disabled; thereby effectively preventing reliable RS-232 communications.
Linking PCs to Mini-computers. In EME Systems Development, my objective was to develop mobile systems that would help people in the workplace. This meant using PCs. For their own reasons, Computing Services Division and the Defence computing bureaucracy in general, did everything possible to slow down the introduction of these machines in the workplace. As a part of this process, I wanted to interface PCs with the Defence Standard Mini-computer, then Perkin Elmers. Like the IBM PC, the choice of the Perkin Elmer mini-computers by the Defence bureaucracy was a terrible one. All programs in the Defence Computing Environment had to be written in Common Assembly Language. This was because the cost of having sufficient magnetic core memory in a Perkin Elmer to allow programming in a high level language such as FORTRAN or even BASIC was prohibitive. I saw PCs as a means of bridging the gap. The PCs could be easily programmed in a new language called "Turbo Pascal" to do detailed tasks and the mini-computers could be relegated to being large storage devices and the means by which data was passed to central databases. Over a period of time, the mini-computers could be phased out altogether. I was told by CSD that it was impossible to interface an IBM PC with a Perkin Elmer mini-computer.
The Start of Terminal Emulation Software. When I became CO of 1 Base Workshop Battalion, with the approval of the Chief of Staff of the First Military District, Colonel Ford, I used local purchase funds to purchase an Amstrad 512 PC for a little over $1,000. This was at a time when dumb terminals for Perkin Elmer Mini-computers cost around $4,000.00! With the help of a friend Lieutenant Stevan
Vujovic, I learnt how to program in Turbo Pascal and Steve obtained for me a library of routines written by Blaise Computing in the US that enabled an IBM PC to communicate using RS-232. With the help of my Electronics Instruments and Radio Platoon, I constructed a switchbox that allowed me to "listen" to all of the characters passing between a Perkin Elmer terminal and the Perkin Elmer mini-computer and it was not long before I had written the code necessary to allow an IBM PC to imitate a Perkin Elmer terminal; something CSD had claimed was impossible to do. Using this facility, I quickly wrote an application that allowed me to raise jobs on the MAWD mini-computer for the purposes of achieving a comprehensive system of Time Accounting within 1 Base Workshop; something that had never been achieved anywhere in the Australian Army (and this remains so to this day!). A life-long friend of mine, Graham Smith, was the CO of 3 Base Workshop Battalion in Broadmeadows, Melbourne, Victoria. I shared my work with Graham and he installed the same system into 3 Base Workshop.
So when I came to 27 District Workshop, I brought all of this knowledge, my code and my switchbox. When I saw the problems with repair parts I saw how it would be possible to largely automate the resupply of tray-stores in 27 District Workshop using barcodes as the means of facilitating accurate data capture.
The Management System Used for Tray-stores
The ARROW computer system had a special transaction for the purpose of ordering tray-stores. It was an abbreviated indenting procedure, designed to save on the number keystrokes necessary to place an order. As a part of this procedure the amount that could be ordered at any one time was fixed as was the total amount that can be ordered during any monthly period.
At the time of my arrival, 3 Ordnance storemen use to patrol the workshop on a continual basis, taking note of which trays required replenishment. They would then make their way to an ARROW terminal and, part by part, input an order to replenish each tray-store. Besides being very time consuming there were a number of problems with this system of replenishment:
Identification of Parts. The storeman was reliant on the label on the label on the front of the tray to identify the part. As NSNs changed the storeman had to constantly amend the labels which was very time consuming. This change of NSN was often only detected when an order
was placed. Changes therefore involved considerable disruption to the storemen's ordering process.
Locating the Trays. When parts did arrive as a result of the
order being placed they came with no location on the parts bag. The
storeman knew from the documentation the Cost Centre Number and the
Tray List Number but not the exact location. This meant that the
storeman would find the right tray by trying to match up the bag of
parts that he held with items in the tray and by the NSN on the tray
label. This was an error-prone and time consuming process.
Stock Levels. Because the time between orders could be quite
lengthy, stock levels in trays were quite high to counter the vagaries
of supply. High usage trays on which there was sporadic, rather than
constant use, often were empty; causing much frustration to tradesmen
and disruption to production.
Terminal Emulation Software.
As mentioned, over the previous 4 years, I had been developing software for the purposes of allowing IBM Compatible Personal
Computers to emulate various brands of minicomputer terminal. I had already demonstrated this in 27 District Workshop and written a paper on the subject but it had attracted little interest from REME Data Centre who possibly resented my uninvited intrusion into their business. I submitted another Staff Suggestion explaining how the emulation is achieved and pointed to the benefits that could be accrued from doing this. The tray-store application was an object example of how this capability could be exploited with potent results in terms of reduction in labour and improvements in quality and productivity.
The Barcoding of Tray-stores
Hardware. The hardware used in this project was as follows:
Software. The software that was used in this project was as follows:
PSION Organiser. The PSION Organiser coupled with a Hewlett Packard barcode wand
provided a practical and inexpensive method of reading barcodes. The cost
of this system was about 3 times less than purpose built special
readers sold commercially. The PSION appeared to be robust enough to
survive workshop duty. (This was subsequently proven to be correct.)
The total cost of 3 sets with wands and serial interfaces, charging
units and memory packs plus all software came to only £1,600.00.
Soon after the initial purchase there was an enhanced barcode wand
marketed by PSION. The wands that were purchased misread approximately one label
per 100 but this figure improved with increased expertise on the
part of the users. The newer type of wand was found to be considerably
better in terms of its reading accuracy. Not only did it read the label with the first sweep most
of the time it appeared not to have the same error problems of its
predecessor. (Of interest, during the project we obtained a laser printer and this dramatically improved the readability of the barcode labels. Before then, thebarcodes were printed using a 24 pin dot matrix printer.)
IBM PC. An IBM compatible 286 20MHz PC with 1 Mb of RAM, VGA colour screen,
1.44 Mb 3.5" & 1.2 Mb 5.25" floppy disk drives, 40 Mb hard drive, 2xSerial Ports (one for the serial mouse and one for ARROW) and 1xParallel Port for the printer. The cost of this machine was £1,800.00 from a firm called Atomstyle Computers in Tottenham.
Laser Printer. The printer had to be capable of printing, on stiff flat sheets of
paper, high quality barcodes. As an interim measure we used a 24 pin printer. The results were workable but some difficulty was
experienced in the production of the labels and the barcode wands had difficulty, at times, in reading the codes. The dot matrix printer
was also slow and cumbersome.
Outline of the Procedure Used. The procedure used was as follows:
ARROW Reporter. This was written by Mr R. Willcox the 27 District
Worksh.op ARROW Manager. It extracts from ARROW's database information
relating to tray-stores and places this information in a special format such that it is immediately digestible, once locations have been
entered, by the barcode printing software .
to Annex 8.)
Barcode Reading Software. PSION provided with their hardware the
necessary software and programming language such that anyone, with only the
most basic of computing skills, could write a program to record barcodes
using the wand and the PSION organiser. The barcode wand supported all
commercially popular barcode formats at that time; including those being considered for general use by the UK MOD. For this project I decided to use "3 of 9". I decided in this format because 3 of 9 was capable of representing Alpha as well as Numeric characters. REME Data Centre at that time was vacillating over which barcode format should be the standard and it seemed for a time they would settle on a numeric only barcode being used in Supermarkets. This project made the decision for them and demonstrated the benefits of being able to depict both numeric and alpha characters. It was because of the success of this project that the UK MOD settled on 3 of 9 as their standard.
PSION to PC Communications Software. PSION provided a serial~interface plus
the necessary software modules to download a file from the PSION into a PC.
Barcode Printing Software. Initially we tried to use a program called "Super Labeller" to print the barcodes. This proved to be totally unreliable and a great deal of trouble to use. I therefore wrote my own software to print barcodes. I obtained assistance in this through the fledgling Internet from an engineering Canada.
PSION Order Software. This was written by Doug Bonner. It causes the PSION to 'read barcodes and stores the results in a text file within the PSION for later downloading to a PC using the PSION communications software
Barcode Data Processing and Automatic Tray-store Ordering Software. I wrote this package. Its purpose was to provide the following facilities:
Downloading of Tray-store data from ARROW into a PC to allow the addition of location data and the printing of the tray-store labels.
Pre-processing of the data downloaded from the FSION prior to transmission to ARROW.
Effect the tray-order transaction on ARROW using the processed data. (This also included trapping and making sense of any error messages ARROW returned. These were passed to the Stores Officer and resulted in the NSNs and other matters being, over a period of time, systematically rectified.)
- Initial Setting Up.
Download Tray-store Data from ARROW. The ARROW computer held all of the data on tray-stores. Bob Willcox, the ARROW manager, wrote a program using the ITL report generator, provided with ARROW, to extract the necessary data and store it in a file, in the correct format. Using the terminal emulation program I had written, this file was obtained by sending it, as if to a printer, to a PC running my program. As the characters came down, over the RS-232 connection, my program parsed the results and stored the data in an appropriate format on the PC so that we could then print the results out for Ordnance Storemen to initially note the locations of stores. This was a standard method we used for extracting data out of ARROW and another system called CAMIS without the need to seek the cooperation of the REME Data Centre (which we knew would not be forthcoming.).
Recording Tray Locations. Because ARROW does not have any record of the individual locations of tray-stores, it was necessary for these to be entered manually by Ordnance Storemen. This printout of the Tray-store Data File was taken by Ordnance Storemen out onto the workshop floor and the locations of the individual trays were entered in the blank columns on the printout. This was a once-only task. For the purposes of barcoding and for eventual replenishment, tray-stores were from that point onwards now identified by:
Cost Centre Number. (for example 0500)
Tray Store Identifier (within that Cost Centre). (for example 01) (Range was 01 to 99)
Location. (for example AZ ) (Trays ran horizontally from A to Z and vertically from A to Z allowing for up to 676 locations for one tray-store and about 65,000 items per cost centre.)
The above example was concatenated to make an unique identifier string of 0500/01/AZ. ARROW held the Cost Centre Number and the Tray-store List Number. The "Grid-Reference" within a particular Tray-store (AZ in this example) had to entered manually into the PC for each tray in order to initially set up this system. These grid references were entered into the PC from the hand completed lists using a simple 'macro' within the word processing package I used to use called Word Perfect 5.
Printing Barcodes. The file was downloaded from ARROW and prepared by the software I had written such that it had all the necessary special characters for the barcode printing software to be able to immediately print the barcodes. Once the
locations had been entered it was a simple matter to execute the barcode printing program to produce pages of barcodes. The
barcodes were printed out initially using a dot matrix 24 pin printer but later we used a laser printer. Not only was the quality of printout vastly improved but also the time to produce barcode labels was significantly shortened. When using a dotmatrix printer it was also necessary to take the printed pages to a photocopier and photocopy them onto stiffer paper. The laser printer with sheet loader could handle this
stiff paper sheet thereby eliminating this step.
Installing the Barcodes on the Trays. The sheets of barcodes were covered a clear heat seal polyester film on both sides so as to make them impervious to grease and robust. Double sided sticky tape was then stuck to the rear of the treated sheets and the sheets then guillotined to label size; complete with sticky tape on the rear. By removing the wax paper backing on the sticky tape, the labels could be placed in any convenient position on a tray.
An Order Cycle.
Recording an Order. A storeman travelled the workshop on a periodic basis once a fortnight and inspected the trays. If the level was down below a prescribed point he wiped the wand over the label to record an order. An order is
half the maximum quantity that may be ordered during an ordering period. If the stored wished to order a full quantity he wiped the barcode twice. If he wished to delete an order, he wipes the barcode over the 'delete' barcode on the case of the PSION and then over the barcode he wished to delete. In this whole process the cover of the PSION is kept shut and there is absolutely no requirement to type in quantities or numbers of any kind on the PSION's keypad. Even turning∑the machine off is achieved by wiping a barcode on the case of the PSION.
Transferring an Order into a PC. The text file of orders on the PSION is transferred to a PC using the PSION communications software and the PSION RS-232 interface cable .
Preprocessing the Order. Because the PSION order file simply consisted of lines of numbers and letters, describing the location of tray, (eg, 050001AZ), this had to be converted into a form that ARROW would understand. To do this, we processed the PSION Order Lines using the tray-store ordering package I wrote. This package accessed the barcode label producing file and extracted from it the NSN of the item and the order quantity acceptable to ARROW . If the barcode has been incorrectly read by the PSION, and no NSN record can be found, the PSION Order line was written to the file called "TRAY_NO.NSN". This file could be printed at the conclusion of the processing session and an investigation could then be conducted into the cause of the problem. Invariably, the only problems experienced in this were caused by the barcode wand mis-reading a barcode.
Sending the Order to ARROW. Having processed the PSION text file, the package then performed the tray-store order transaction on ARROW in an automated fashion. The PC DID this by executing a command file that defined the dialogue between it and the ARROW computer. The command file directed the PC to take a line of data from the processed data file and send it to ARROW. It also
instructed the PC to send certain characters that are normally the response a person would make when performing a tray order. During this process a number of error conditions could occur. The major cause of error was asking for a certain quantity of stock when there is insufficient to satisfy the demand. The second most common cause of error was asking for an NSN that was no longer current or stocked by the warehouse. This often happened when Ordnance personnel mistakenly "outscaled" an item that was still in use in the tray-stores. In both instances of error the results are sent to a file called TRAY.MSG. This file was printed out at the end of the session and an investigation by the stores officer and subsequent manual intervention used to overcome the problem. The time taken to execute a batch of tray orders depended on how heavily loaded ARROW was at the time of placing the order. Tests indicated that orders could be placed at the rate of 320 per hour (about 10 times faster than humans were capable of achieving!). During quiet hours, rates of 600 per hour were achievable. If run during normal working hours the process so taxed ARROW that it affected the service experienced by other computer users. It would also delay background processing tasks by more than half an hour.
General. The system performed beyond expectations. A summary of the benefits is as follows:
Timesaving. Using this system it was possible for one storeman to order a11 of the tray-stores for the entire workshop in one day whereas before it took several man-weeks per month. The cash savings achieved from this are provided in greater detail below .
Organisation and Availability of Stores. The introduction of this system forced us to properly organise our tray-store listings and the physical layout of the stores. This proved to be of considerable benefit in reducing the time taken to effect the ordering and in ensuring that stores were always available for tradesman to use. In the past it used to require 3 men working almost continually to keep the tray-stores stocked. Despite their best efforts, there were continual complaints about the state of tray-stores from tradesmen. These complaints centred around not only non-availability but also the fact that critical trays often had the wrong stores or mixed stores held therein. With this system, those situations were a rarity.
Eliminated the Problem of Supersessions. Because only the location on the tray was in the ordering system, this location being linked to an NSN on the PC just before the order transaction was effected, there was no pressing requirement to amend NSNs on labels on the shop floor. Instead, the file on the PC was continuously updated by downloads from the ARROW computer. Before this system was introduced, NSNs on tray-stores were a major cause of error in ordering. The upkeep of NSNs and the problems caused by erroneous transcription or supersession were eliminated.
Stock Minimisation. The new system allowed management to be sure of reording at least once per month and, if thought desirable, at a frequency of once per fortnight. This will allowed better control of the stocking levels of tray-stores which, in turn, reduced the amount of stock 'tied' up in trays∑
Improved Availability. The stores, being better organised and
more regularly checked, were reliably available to the tradesmen. This resulted in higher productivity and shorter turnaround times for
repairs. The savings that resulted from this were difficult to assess but most probably ran into several millions of pounds in "freed" investment a year.
To set up the system took about 12 man-weeks of work. Much of this involved the reorganization of existing tray-stores so that they complied with a newly introduced standard called "AQAP 4". These reforms would have been necessary even if we had not decided to introduce the barcode system. Reordering using barcodes required about 3 mandays per month of labour. This figure takes into account not only the physical act of ordering stores but also the need to maintain the database of tray-store data that is used for generating the barcodes on the PC. The saving is therefore, conservatively, in the order of 2 storeman-years per year. On present capitation rates this equates to approximately £22,000.00 per year. Once introduced into the 10 REME Base workshops a total saving of about £220,000.00 pa was achievable. The initial hardware and software costs for the ten workshops was estimated to be about £30,000. This money was easily within the Delegated Financial Powers budget allocated to each of these units. From experience we knew that the maintenance costs of similar systems were about £60.00 per year per installation. On the basis of an annual investment loss of 10% and add the maintenance costs, the total savings achieved by the system, in the 10 workshops, was estimated to be:
£200,000 - £3,000 - £600 = £196,400 pa. (Note this does not in any way take into consideration the value of better productivity on the workshop floor nor better equipment availability in the fleets being maintained.)
Initial Setup Costs.
Initial setup costs were £30,000 in hardware and £25,000 in labour for the the 10 workshops.
The system was developed entirely in-house and largely in the private time of the persons involved. It was intended to demonstrate and prove the benefits that could be achieved when PCs are interfaced to larger systems such as a mini-computer network and automated data capture devices are employed in combination with these PCs. I believed then, and am even more convinced now, that the future rests with small, distributed systems capable of securely exchanging data on an opportunistic basis as communications allow. What was, to some extent, an experiment, developed into a working, reliable and low-cost package that could be utilised to great effect in any workshop; even those without a mini-computer system like ARROW.
Most importantly, this project, and a subsequent one related to Calibration Management
, demonstrated how a small team of people, embedded in a workshop as part of the management team, could develop highly effective systems in a fraction of the time and at a fraction of the cost that would be incurred when a more conventional development approach, involving IT professionals and bureaucrats, is taken. The Australian Defence Force, for example, has expended tens of millions of dollars over a period of greater than 8 years trying to harness barcodes to some productive advantage. In this effort, they have employed large teams of consultants from firms like KPMG and utilised the highly structured, innovation-stifling procedures required by the Defence Materiel Organisation and the Chief Information Officer's Group. All to no avail.