Case Study The Dag-Br??cken ASRS Case Study This case formed part of JEWELS, T. 2003. The Dag-Br??cken ASRS Case Study. Journal of Information Systems Education: Special Issue on IS Teaching Cases, 14, 247-257. INTRODUCTION Logistics Overview Australian warehouse storage and retrieval of product is still predominantly a manual or semiautomatic process employing a variety of materials handling equipment such as conveyors, elevators and fork lift trucks.
The relatively low cost of land in Australia, compared to high density population centres in Asia, generally imits that countrys use of high rise storage facilities to special situations that might include hazardous storage conditions or where desired throughout cannot be maintained with a manual system. Dag-Br??cken ASRS Pty Ltd (DB) believed that a market could be developed in Asia providing high rise automated warehouse solutions at more competitive prices than that demanded by the major suppliers, using a variation to the normally used ASRS confguration that involved automated (robotic) ASRS cranes that were able to drive around corners.
Globally, most high rise warehouses use ASRS cranes that are only apable of travelling in a straight line (referred to as straight-aisle cranes). The limitation of a straight aisle crane is that one crane is required to service each storage aisle in a warehouse. As cranes are a major part of the cost of this type of warehouse solution, by reducing the numbers of cranes there are significant savings. As such, it was theoretically possible for a single aisle-changing crane to service a complete multi-aisled warehouse, rather than relying on separate cranes to service separate aisles.
DBASRS Background DB had a history of providing electrical control systems using programmable logic ontrollers (PLCs) for a number of process control applications. The entrepreneurial DB managing director (MD) was an electrical engineer who had developed knowledge of PLCI software and believed that the development of PC control software to be used with this new type of ASRS held few technical challenges. By 1996, the MD had secured a number of orders for their innovative and competitively priced aisle changing ASRS system.
In addition to SCT in Taiwan the contracts included a milk supplier in Thailand, and a beverage manufacturer and two archival warehouse facilities in Singapore. Contracts had specified that the completion dates were to be within 12 months. control electrical machinery DB Project Scope The SCT ASRS was designed to automatically move pallets of beverages from the end of multiple production lines for storage into a high rise warehouse; and when required for sale, to automatically move them to locations where they could be accessed for manual distribution.
DB Project Rationale For SCT a high-rise ASRS solution was selected because in order to minimise stock outs the amount of inventory required could not be stored in a traditional warehouse onfguration with the amount of surface area available for that purpose. Although expensive off-site storage was being used as a temporary measure this had resulted in an unacceptably high level of ‘out-of-date’ stock by not adequately allowing a first in first out (FIFO) stock usage policy.
With no personnel actually working inside the storage facility itself, the storage and retrieval system was designed to identify all pallets being stored, to optimise their storage locations and to retrieve the pallets in a FIFO pattern. Equipment Used The ASRS used two, twin fork, double sided, double reach cranes in a 5 aisle, 16 row arehouse confguration. The warehouse layout consisted of long aisles of up to 40 horizontal pallet locations and short aisles of up to 12 horizontal positions all of up to 10 pallets high, (Figure 1).
Figure 1: ASRS Racking Layout With their multiple reach configuration each crane was capable in any long aisle, of reaching up to 8 pallet locations at any one static position i. e. each set of forks to the right, single deep and double deep, and to the left, single deep and double deep, (Figure 2). The vertical range of 10 pallets high effectively allowed any crane to access 0 pallet positions from any static horizontal location. The principal advantage of the DB system was of course that the cranes could travel around corners and could access any pallet position of any aisle. 3 4 5 6 8 Figure 2: Multiple reach positions of each ASRS crane Operational Requirements The SCT ASRS was at the end of multiple production lines, that manufactured an assortment of beverages in P. E. T. bottles, tetrapak containers and aluminium cans and in-feed into the ASRS warehouse from the production lines took place on three levels. Level 1 used a palletiser to feed an automatic guided vehicle (AGV), (referred to s the shuttle car), filling 9 double gravity roller locations, used exclusively for P. E. T. ottles. Level 2 used 2 third party supplied robots to palletise stock that were then fed by another AGV into 7 double conveyor infeed locations used exclusively for tetrapak containers. Level 3 used a single robot palletising for a single, double deep conveyor in-feed location used exclusively for canned products. Empty pallets were required at each palletiser for product to be packed onto. Outfeed production was dependent on external demands for stock and requirements for these movements more difficult to estimate.
An hourly rate fgure equivalent to the number of pallets entering the ASRS was considered appropriate, i. e 50 in and 50 out. Outfeed locations were via 75 triple deep gravity roller locations situated in one of the long aisles. When any of the outfeed locations was emptied, sensors fitted to each crane were able to detect it and a Job created to fill this empty hole that needed to be filled. The crane was required to perform an aisle scan every 30 minutes. Normal production line speeds demanded that to avoid hold ups the ASRS had to be capable of consistently performing all the tasks detailed in Table 1 .
Table 1 : Performance Requirements for pallet movements Job Type Clear Level 1 prodn. Clear Level 2 prodn. Clear Level 3 prodn To Outfeed locations Scanning Outfeed aisle Empty pallet stacks (10) Total pallet movements Pallets per Hour 50 2 min 7. 5 mtn 5 min 1. 2 min 30 min 12 min 107 0. 56 mtn Pallet cycle time (minutes) The People The MD and principal owner of DB was the entrepreneurial force behind the organisation and responsible for the basic design of the mechanical and electrical components as well as the software design overview and the overall project concept.
He was described by one qualified graduate electrical engineer working on the project as a truly brilliant electrical engineering designer’, although he was never able to confirm whether the MD had ever actually graduated from his university studies. The MD had excellent PLC programming skills, and had ‘dabbled’ with some Visual Basic code for which he had produced his own simple GUI presentation unlinked to a database which he had used as a sales aid. The General Manager (6M) with an extensive background in civil engineering project management had no IT project management experience.
A further two project anagers were employed for eventual on-site commissioning. One was a qualified mechanical engineer with extensive experience with mobile cranes who acted as the mechanical engineering manager in the production stage. The other had no formal management qualifications but was experienced in contract management and had an understanding of small projects. Somewhat surprisingly, nobody on the management team had any experience of the type of IT development that was being attempted.
There was at the commencement of the development a tactical decision taken to segregate the required software components into an IT based area, ubsequently referred to as the ‘PC’ team and an electrical engineering based area that developed the ‘PLC’ software. The PC team was responsible for developing software components which included the GU’, database, communications package, traffic controller and product mover, and the PLC group provided code to operate the functions of the material handling equipment through electrical motors and sensors. separate offices 40 metres apart, within the industrial complex that was being leased by DB.
Prior to appointing anyone in the PC team, a management decision had been aken to use a Windows NT based operating system with a Visual FoxPro development package for the GUI and database and C++ for integration with the PLC code via the traffic control’ module. The PC team was initially staffed with only two systems analyst/programmers (SA/P), who were appointed at the same time. Only one SAIP had any commercial development experience having successfully operated his own IT warehouse management business for 10 years, although his development experience had been in a Unix environment with character based Foxbase+ application.
Although his extensive background in inventory and warehouse anagement systems and formal qualifications in business management provided a business perspective for the project he still had no experience of integrating technically advanced hardware communication features into software applications. His assigned role was to design a GU’, product mover and database that could be used with the DB ASRS system. The other SAIP had recently completed an undergraduate software engineering degree and had experience in hardware communication systems with a telecommunications provider.
His primary role was to design and write a communication system between the PLC and the PC and to design nd write the TC module. The PLC software design was to be carried out by the MD himself, two recently graduated electrical engineers and a more senior PLC electrical engineering programmer. These then, were the people that were initially involved in the early stages of the actual development (as distinct from the pre-planning) stage. The Contract The contracts established between DB and its four ASRS clients prior to the commencement of development all contained provisions for staged payments throughout the project life cycle.
Payments were to be made at confirmation of ompletion of milestones, with the actual payment amounts roughly equivalent to DB’s proportional outlay for that stage. One of the stage payments for SCT was to be made at completion of the design and development of the control software that was to be used with the system. In order to successfully market the innovative DB aisle changing cranes Dag-Br??cken ASRS Pty Ltd believed it necessary to offer a complete warehouse management solution to clients.
The various components included all materials handling equipment, storage racking, crane control software and a PC based control system. The open nature of the contract specifications reflected the fact that neither contract party clearly understood what a critical role the software component would ultimately play. Clients had entered into these contracts without involving their own relevant departments in any negotiation and it was not until after all contracts were signed that the SA/Ps first met with clients to produce the initial software specification.
These meetings were also the first instances of client personnel having direct contact with DB, although they had already been briefed by their own ompleted systems in terms of crane movements per hour and how these performance levels were to be measured, but the formula used was one used for measuring the cycle times of a straight aisle crane. Aisle changing performance, constituting the principal difference of the DB system was not included in the contract requirements.
Though the system involved the use of two cranes designed to carry two pallets at once, contract specifications only included performance fgures for the time to deliver a single pallet on a single crane to locations in the same aisle (Figure 3). End Rack Start Figure 3: Crane Performance Contract Requirements DB were offering a system that had yet to be completely designed, other than in broad conceptual terms, yet clients had entered into contracts that had guaranteed almost 80% of the total price before DB were required to deliver any working system.
Stage payments were all at verifiable stages of the design/production process yet actual performance requirements were restricted to performances of the crane that could only be measured in the final stages of the project. Performance requirements for the Working system’ were based on single crane, single pallet, single aisle easurement formulae and did not take into account SCTs production line demands detailed in table 1. At an operational level there was evidence of ‘implied’ performance levels, with SCT erecting a prominent sign suggesting performance figures of 384 pallets/hour.
The contract certainly did not offer this fictitious figure, yet this figure could have been calculated by extrapolating dual crane/fork fgures from a single fork performance in a test environment. Yet, as poorly worded and constructed as it was, the contract still remained the principal source of reference for system design and performance matters. Strict adherence to the letter of the contract by DB provided little real opportunities for clients to amend their contract terms and conditions, clearly biased towards the vendor, without accepting large price variations.
Compared to other types of ASRS the original contract price was very competitive, yet any variation, (however small), from the terms of the original contract was either rejected outright, or was priced at an exorbitant rate by DB. The absence of any operational performance requirements throughout the project life cycle resulted in not only the client being unable to valuate progress but DB themselves having no real performance goals to work towards.
Although a mature, experienced company may have been more successful in using a contract with this level of vagueness, by supplementing the contract terms with their own internal quality control procedures, DB had neither formal, nor informal quality control procedures in place. DB’s processes were typical of the Software Engineering Institutes (SEI), capability maturity model for software (CMM), ‘initial’ or ‘ad-hoc’ stage of development, (Paulk et al. , 1993). There may have been a ight have been that their clients did not demand it.
As Oskarsson and Glass, (1996) suggest, “ISO 9000 is a tool for customers buying software more than for developers building it”, (pxxi). The End is Nigh (Epilogue) Less than one week after DB had been awarded its export award it announced that for administrative reasons’ it was to be placed in the hands of administrators. Approximately 12 months after this took effect the company was wound up and its assets liquidated. The effect of this liquidation resulted in DB being unable to provide further assistance to SCT, as the result of which: ??? The SCT-ASRS was unable to perform at anywhere near the required operational speed.
The system was unreliable both mechanically and electrically. The software components still required substantial modification, debugging and tuning and did not have the expected functionality. SCT eventually replaced the whole system with a more conventional straight aisle ASRS model. Although many ASRS systems have been successfully completed since, none have ever used the same technology as attempted by DB. As well as all DB employees losing their Jobs, a number of client executives that were involved with the arious ASRS projects were also dismissed.
The administrators were ultimately only able to award DB creditors a few cents in the dollar, and legal action was undertaken against the administrators themselves. References OSKARSSON, O. & GLASS, R. L. 1996. An ISO 9000 Approach to Building Quality Software, New Jersey, Prentice Hall. PAULK, M. , CURTIS, B. , CHRISSIS, M. & WEBER, C. 1993. The capability Maturity Model for Software version 1. 1 . Pittsburgh: Software Engineering Institute. YIN, R. K. 1994. Case Study Research: Design and Methods 2nd edition, USA, Sage Publications.
