AUSTRALIAN ARMY MAINTENANCE MANAGEMENT SYSTEMS

SUMMARY

In 1980, Defence moved its software applications, largely databases, from Honeywell to UNIVAC mainframe computers.  One such database application was MODERNISE owned and operated by the Royal Australian Electrical and Mechanical Engineers (RAEME).  The aim of MODERNISE was to capture materiel maintenance data that could be analysed to provide statistical information useful for high level decision making.  MODERNISE obtained its data from forms that were filled out in workshops and input remotely by data key-punch operators.  Besides being badly conceived in the first instance because data critical to calculating Operation Availability and Productivity had been overlooked, MODERNISE was an impost on the workforce and so the data, provided under sufferance, was often incomplete and/or inaccurate. 

My assignment was to convert MODERNISE from the Honeywell to UNIVAC mainframe with no improvements or changes being allowed.  I refused to do it.  Instead I proposed a new system called EMEDATER; standing for Electrical and Mechanical Engineering Data on Equipment Repair.  EMEDATER built on the lessons learnt from the MODERNISE experience whereas migrating MODERNISE unchanged to UNIVAC would have simply repeated them!  As a part of this, I appreciated that, unless small, portable applications were provided to the workplace to help people perform their duties, the data being passed up to a central database would always be incomplete, inaccurate and, consequently of no use; indeed, it could be fatally misleading!  To satisfy this need, with the help of WO1 Warren Wilde, WO1 Spike Wiseman, Lt Stevan Vujovic and Lt Berge Zerbe, I conceived and specified a software application that would run on a Z80-Microprocessor based computer, running the CPM and MPM operating system, such as a TRS-80.  This concept was first christened EMEx which morphed into EMEFd and finally into EMEMic; standing for Electrical and Mechanical Engineering Microprocessor based application. 

EMEDATER was delivered by a Computing Services Division team, headed by Mr Steve Thier, under-budget and ahead of schedule for a total expenditure of less than $2 million.  EMEMic was developed by two staff at ACT Workshop Platoon over two years for less than $300,000.  Major Richard Fullford took over my position when I departed after two years for Command and Staff College.  Richard deserves a lot of credit for the successful implementation of this project.  EMEMic is regarded by all who have used it as being the best and most useful Defence system ever.  It achieved that success because it was effectively developed by Warrant Officers, Sergeants and indeed all of those people who had to perform "hands-on" maintenance work.  It was not developed to a rigid specification but instead was allowed to evolve as users saw the need.  This should be compared to the present Defence Maintenance Systems that have cost the Australalian Taxpayer well over a billion dollars yet have not materially added to the productivity nor capability of the Australian Defence Force.  Similar stories can be found in the US Defense Forces as well.  Large centralised systems consistently cost more than budgeted and do not perform to the expectations of the persons who actually have to do the work in the workplace.

DETAIL

The Background to MODERNISE

The Royal Australian Electrical and Mechanical Engineers(RAEME) were the first in the Australian Defence Force to obtain a mainframe computer system for the purposes of collecting statistical data they thought would be helpful in guiding management decision making.  This system was introduced in 1969 and was called MODERNISE.  It ran on a Honeywell Mainframe.  By 1980, the rest of the Defence Force had caught up.  New mainframes, in the form of UNIVAC, were being introduced into service and this necessitated the transfer of the MODERNISE system across to the new environment.  To save money, Computing Services Division insisted that there be no enhancements to any systems being transferred.

MODERNISE required management in workshops to fill in forms reporting on repair activity.  These forms were then dispatched to an EDP input centre where key-punch operators input the data.  Often mistakes were made and the forms were returned to the units for them to correct the errors.  Sometimes disciplinary action resulted.  All of this made MODERNISE very unpopular.  Soldiers soon learnt how to give the least possible information so as not to make a mistake and not to convey too much information to "them that might be watching us!".  As it was, the design of MODERNISE was flawed.  Information, essential for the calculation of operation availability, was not captured.  After operating for nearly 11 years, MODERNISE, in 1980 was of no practical use in terms of the information it contained.

Posting to DGEME

In 1980 I was promoted to Major and appointed to be the Staff Officer Grade 2 (SO2) in charge of EME Systems Development.  Prior to this posting, I had been in charge of a Workshop Platoon servicing all of the units in the Australian Capital Territory, a major dependent unit being the Royal Military College and the various Defence Headquarters.  I had come to the attention of the Directorate of Electrical and Mechanical Engineering because I had developed a Trade Repair Accounting system, written in FORTRAN 77, to run on a DEC 7 mini-computer at the Faculty of Military Studies, Duntroon.  This system facilitated management of the workshop's financial ledger and reporting all contract repair activities to the 2nd Military District. (Click here for more details)

The Personalities at DGEME

I reported to a Staff Officer Grade 1 (SO1), Lieutenant Colonel Mike Burgess.  Mike was a jovial person who knew little about computers.  His expertise was in super-hetrodyne radio receivers, a subject he had previously taught at the RAEME Training Centre Bandiana.  Because of this I was left pretty much alone to develop things as I saw fit with Mike supporting me wherever he could; particularly in the area of crafing staff papers.  Assisting me initially was Warrant Officer Class 1 Warren Wilde, an experienced and competent Warrant Officer who was also an extemely decent person.  After about a year Warren was replaced on posting by Warrant Officer Class 1 Spike Wiseman.  Though a different personality to Warren, Spike was an excellent and supportive assistant.  In my previous posting at ACT Workshop Platoon, I had come into contact with an exceptional soldier, Stevan Vujovic, an ex-apprentice who had gone on to do a degree in Physics in his own time.  I recommended Stevan for Officer training and, after graduating from the Officer Cadet School, Portsea, he spent time supporting me as a 2nd Lieutenant at EME Systems.  Stevan knew a great deal at the practical level about computing and communications, having previously been trained as a radio technician.  Stevan and I both shared the view that the future lay in small systems.

The Advent of Personal Computers - and the Vision of Small Systems

The vision concerning the need for small systems was simple.  Small systems had the potential to help people perform their duties in the workplace.  By providing this support, users would have a vested interest in ensuring the information being input was complete and accurate.  Not only would these systems materially benefit quality and productivity in the workplace, they would provide every possible detail required by any database system being used by senior management for high level decision making.  There would be other benefits as well.  Should communications be cut, these small systems would continue to provide useful service to the workforce.  Additionally, the detail of transactions in the workplace would not have to be sent back to a central database; only the summary information.  This would improve security and reduce the amount of data that had to be transmitted.

The Computing Services View regarding Small Systems

At that time, small, semi-portable "Microprocessors" as they were then called were beginning to make an impact.  These later came to be called "Personal Computers" or PCs by IBM.  Computing Services Division considered them to be play-things, distractions from the "main-game".  In 1979, I was in charge of a workshop platoon at the Royal Military College and I tried to obtain a Hewlett Packard Microprocessor with a "massive" 64 kilobytes of Random Access Memory.  I remember Richard Fullford (an officer who later took over from me at Systems Development, DGEME) telling me this was excessive.  (I'm sure Richard would cringe if he remembers that for he went on to do an excellent job in System Development!)  I intended to use this desktop computer to run a program that would help my staff manage contract repair accounting.  Even then, I saw the need for graphics and appreciated the demand these would make on computer memory.  Despite writing countless submissions, there was no way CSD would agree to my obtaining a desktop Microprocessor based computer! When I arrived in DGEME, I encountered the same prejudice by CSD towards Microprocessor based systems.  They believed these systems would never compete with mainframe and minicomputers in the near term.  In order for small systems to be effective there had to be a means by which they could exchange data with other systems and, if necessary, be connected by cable to these systems.  I saw possibilities in using small systems to pretend they were the computer terminals of mini-computers such as those used by MAWD in base workshops or SCUBA in Supply Battalions.  In doing this, it would be possible for the small system to appear to these mini-computers as if it were a person operating the terminal and be able to input through the transactions that existed on the mini-computer any amount of data the small system had collected.  Using the existing transactions on the mini-computer had a number of advantages:

• There would be no need to change the code on the mini-computer.
• Because the small system was using the mini-computer's transaction system, there was little chance of it causing any sort of damage to the mini-computer's data.  With direct access to the data-base of the mini-computer this could not be assured.
• Using the existing transaction system meant it would not require the cooperation of another group of programmers or seeking approvals which, invariably, would be denied.
It would be possible to gather data by some other means, such as a bar code reader, store the information into a text file and then hand this file over to a small system, acting as a mini-computer terminal, to input the data into the mini-computer without clerical effort and the possibility of keystroke error.

CSD maintained that it was not possible to interface Microprocessors, or later, the PC with Defence mini-computers.  In 1986/97, whilst I was the CO of 1 Base Workshop Battalion, I proved them very wrong (For more details click here.).

Small Systems - The Trading Post Experience

In early 1981, Stevan and I visited the newly formed "Trading Post".  This was a paper that specialised in selling second hand articles.  It cost nothing to place an advertisement in the Trading Post but sellers were expected, on successful completion of the sale, to pass a percentage of the proceeds back to the Trading Post.  The Trading Post was founded by an ex-Navy officer called John McAllery.  The idea of not charging for the advertisement was novel but the novelty of this operation did not end there.  It was the first newspaper in Australia (and possibly even in the world!) to be completely computerised from the time the telephonists took the details of the product to be sold from their customers to the printing of the paper.  Everything was done using Z80 based microprocessors running the MPM operating system; the various programs that helped were written in BASIC.  So much for Microprocessors being "play-things"!

The Ineptitude of Senior Defence Computing Management

It was interesting to me as a comparatively junior officer to note that the people working within CSD at the lower levels were eager to please, talented, frustrated with senior management and, above all, hardworking.  The problems with CSD resided with the senior officers running the organisation.  In a number of instances, these officers were in CSD because they saw it as a means of pre-discharge training.  Their scheme was to make the necessary contacts in the EDP industry to find a well-paying job on "civvie-street".  Others, having not done well in their chosen profession of arms, sought promotion by insinuating their way into CSD.  Whatever the reason, CSD seemed constantly incapable of making a correct decision at the strategic level.  At a time when mini-computers were being produced with compilers that would allow programming in high level languages such as FORTRAN, COBOL or BASIC, they purchased Perkin Elmer computers that could only be programmed in a language called "Common Assembly Language" (CAL).  The consequences of this meant that programs took much longer to write, had a very poor user interface and were much more expensive to produce.  It is possible that CAL was very efficient in its execution but high level languages of that period generally supported compiler instructions which allowed the execution of "inline" assembly code wherever there was a need for extreme speed.  The choice of Perkin Elmer over other similar mini-computers, such as DataGeneral, that did support high level languages, put computing in Defence back around 10 years until Army insisted on obtaining PRIME mini-computers and operating them within its own organisation.

It was similar issue with CSD's choice of Microprocessor.  In 1980, there was a Microprocessor, made in the US, called the Onyx.  It featured:

• a Motorola 68000 microprocessor (a chip that capable of handling graphics and data at the same time),
• a 64 bit mathematical co-processor,
• a revolutionary 40 Megabyte Winchester hard disk drive,
• the ability to be networked using RS-232, and
• a "massive" (for that day!) 512 kilobytes of RAM.

All this for $4,000 US.  More interesting still, the Onxy ran a cut down version of UNIX which was written in C; a language slightly better than Assembly.  By virtue of the fact it ran UNIX, Onyx had the potential to run high level programming languages such as FORTRAN, COBOL, BASIC, Pascal and ADA.  At around the same time, IBM came out with its PC priced at about the same amount as the Onyx.  The first IBM PC was a pathetic piece of equipment.  It came with:

• a Intel 8088 (this was a chip with a 16 bit register but only an 8 bit data bus),
• no mathematical co-processor,
• no hard drive,
• a 256kB floppy disk drive,
• no readily available means of networking though IBM "promised" it would be in a future model, and
• 64 kilobytes of RAM. 

Like the Onyx, it too cost around $4,000.  Working on the adage that no one ever got fired buying IBM, CSD chose the IBM PC as the Defence standard.

Interfacing with Supply Systems

Over the two years, I worked closely with a team of Ordnance officers involved in the development of a new family of Supply Systems; our working relationship becoming very close as we fed off each others efforts.  Like me, they encountered nothing but stubborn resistance and a complete lack of cooperation from the senior management within Computing Services Division.  I had found that the provisioning formula in the Ordnance Supply Manual, called "PAM 4", was mathematically incorrect so I rewrote it, much to the delight of LTCOL David McLachlan (later Major General McLachlan) who commented I should have been a supply officer.  The Supply Systems people, like myself, saw the future in small, portable hardware running stand-alone applications, focused on serving the needs of the workplace.  At the time, they were working on a microprocessor based system called DICVAS, standing for Divisional Inventory Control, Visibility and Accounting System.  In took until 1996, 12 years after EMEMic was commissioned, for EMEMic to be interfaced with DICVAS such that parts requests filled out on EMEMic could be sent electronically to DICVAS.  The reason for it taking so long for these two systems to be able to exchange data may be found in self-interest, internal politics and a senior leadership devoid of imagination and technical competence.

The Supply Systems Redevelopment Project (SSRP) epitomised all that was defective about Defence Supply Management, particularly at the senior leadership level.  During my two years at DGEME I acted as EME liaison on this project.  I found the experience extremely frustrating.  As a RAEME officer who had served in every type of workshop within the Army and all of these organisations having a comprehensive stores systems covering Cat A(accommodation stores), B1 (tools and special equipment), and B2 (repair parts).  In the development of EMEDATER, it was necessary for me to write all of the stores instructions for the processing of repair parts transactions and design all of the forms.  The SSRP was a project run by conventional thinkers with very little actual "hands-on" knowledge of storehouse operations and almost no common sense. It is little wonder with this incompetent leadership, the SSRP flopped about for around 10 years without anything of any substance coming out of it. 

The Birth of AutoQ

In the bottom of G-Block, there was a Wang 2200 MVP mini-computer operated by an Infantry Officer called Captain David Barclay.  The purpose of this machine was to hold all of the Army's establishment data.  One essential aspect of military administration is to be able to create what is called a "Capital Equipment Discrepancy List", a CEDL.  The structure of any unit both in terms of its manning and its equipment (materiel) is determined by a document called the Establishment.  The Establishment Document is called an "Entitlement" document,ie, it lists everything a unit is entitled to hold.  The CEDL is created by comparing that which a unit is entitled to hold against that which it is actually holding.  I impressed on the SSRP that if Defence provided its Q Stores with a microprocessor that assisted staff manage the stores, then this application would list all of the items that were presently being held.  In a similar vein, if the unit orderly room had a microprocessor-based application that helped them account for personnel, this would provide a listing of all of the personnel positions, those that were presently filled and the qualifications of the personnel filling them.  I called the Q system AutoQ and the personnel system AutoPers.  By these two systems periodically passing up their data and this data being compared to the establishment data held on David Barclay's Wang, it would be possible to automate the production of the CEDL.  AutoQ became a reality.  AutoPers never saw the light of day and even today, personnel management within the Army is very poorly handled at unit level.  Units have no computer systems help to do something as basic as mark the daily roll for example.

What happened?!!

By the time I left DGEME, the specification of EMEDATER was complete and a CSD team was well underway developing the database schema and writing the code.  Also well on its way was the development of EMEMic.  This project was to be executed at ACT Wksp Platoon by a team of two programmers working in close cooperation with the workshop staff.  All up it cost around $300,000.  EMEDATER came on line in 1982.  It cost less than $2 million to produce.  AutoQ was introduced into the Army sometime after 1982 and DICVAS became a reality thanks to the efforts of my friends and colleagues in Supply. 

CSD was disgraced and suffered significant reductions in its manpower but rose again to become an even more pernicious force in the mid 1990's.  In the early 1990's a decision was made to introduce three major Enterprise Planning Systems as they were euphemistically called.  These consisted of:

• SDSS. The Standard Defence Supply System was purchased from Mincom.  With it came a maintenance module that was also introduced into Defence.
• PMKeyS. The Personnel Management Key System was purchased from People Soft.  It was so ill-suited for the military that it was necessary the Regimental Number system that had served the military since the 1st World War had to be dropped.  Even today, Army has to deal with the PMKeyS number and the old Regimental Number.
• ROMAN. Resource and Output Management and Accounting Network is a SAP based accounting product used by the Department of Defence.  Its name alone gives some indication of how badly conceived it is.  When the person who was heading the project was asked when would it finally be delivered, he replied in frustration.."When the Romans come!"  That then created another problem... how to end up with an acronym that might make some sense from ROMAN!

These ERPs have cost well over a billion dollars each.  They replaced systems that were operating satisfactorily and could have been migrated to more modern machines for a fraction of the cost of the ERPs.  If, in migrating those systems, there had been an effort (requiring vision and imagination of which there has always been little!) to devise a common format for the user interface; one that was easy to learn and required little clerical effort to operate, then all of the disparate systems could have taken on the same appearance and so created the perception they all belonged to the same overall system of administration.  Not only would this have been a much cheaper solution, training costs would have been minimised and clerical productivity improved.  If management had then organised that all of the various systems, extant at that time, were capable of exchanging data as necessary, Defence would have ended up with a far superior solution for a fraction of the cost and disruption to its day to day operations.  Instead, the taxpayer has had to pay billions of dollars for systems that have great difficulty exchanging data and are a blight on the productivity of military units.  One need only look to the ever growing computing bureaucracy that is CIOG to see the base reason why the big central systems have been so warmly embraced by senior management.  Since 1995 to the present day, these systems and their attendant communications networks have cost the taxpayer more than 15 billion dollars but, in the sober light of reality, Australian Defence Force administration is no better than it was in 1985.