The Australian Antarctic Division in 1990 began looking for a Financial and Materials Management system (FMIS/MMS) which, after a lengthy tendering and implementation phase, finally went into production in 1993. The FMIS/MMS system implemented was DBQ/CIS from BHA Computer Pty Ltd. Within the Division, the system became known as 'MIDAS'. Originally running on a DEC VAX 4100 (VMS), it was moved to a SUN Sparc 10 (UNIX) within six months due to performance problems. Access to this system is through telnet. There is a substantial learning curve in coming to grips with a range of function keys and numerous codes to learn to effectively use the system (see Figure 1).
As the system is a melding of two separately developed systems (financial and materials management) many screens exhibit inconsistent behaviour, which only serves to further confuse users. Casual users had constant difficulty, with some refusing to use the system. Many of those in this category were middle and senior managers who had a need for the information but could not effectively obtain it.
To successfully implement the MIDAS system, we needed a number of strategies to overcome user resistance.
To assist in system administration, we began to use automated email messages to notify us of a variety of system events.
Automatic notifications are also sent to users to inform them of the progress of their transactions so that they do not need to log into the system. The types of notification messages generated include:
A further strategy to shield casual users from directly interacting the MIDAS system came in the form of overnight reporting. A large number of reports are scheduled to run in the system overnight . Each user has their own set of customised reports amalgamated into a single document - a form of personalised electronic newspaper. We call it the MIDAS Morning Post (MMP). These MIDAS Morning Posts are delivered as email attachments daily, weekly, fortnightly or monthly as required (see Figure 2). The MMP's are encoded in RTF (Microsoft's Rich Text Format for document interchange) which, when viewed with a word processor, affords more attractive formatting than just text. Early on, when performance problems were a concern, these reports served two very important purposes - to minimise the number of users actually logging into the system; and to provide easier access to essential financial information.
MMPs have become a success story and continue to help managers keep track of their finances and stores as well as reducing their direct interaction with the MIDAS system. Most users are comfortable with the familiar notion of a 'newspaper' being delivered to them periodically. Of course, not everything can be delivered in this way. There remained a need to easily examine the detail of financial transactions and track the progress of purchase orders and requisitions.
Starting out with overnight report runs delivering static pages, we soon looked at increasing the level of interactivity through Common Gateway Interface (CGI) programs accessing the MIDAS database in real-time. As a distinct application, password protected, and separate from other internally served information, we named it 'Resource Navigator'. In naming it so, we wanted to disassociate it from the then unpopular MIDAS system and also not limit it to serving information solely generated from within MIDAS. By December 1995, we were confident enough to go 'live'. Resource Navigator was immediately met with overwhelming acceptance from all our MIDAS users and soon caught the attention of senior management (in a positive way one should add...). It wasn't until we were well into the development of Resource Navigator that we realised we had built was what the 'technosavvy' in the press were calling an 'Intranet'.
Using rapid prototyping, functionality was added incrementally with development cycles of some components measured in weeks or even days.
To build our intranet we found the Internet a ready source of freely available software such as the perl programming language and the NCSA HTTPd Web server.
The use of familiar constructs was the key to ease of use - the newspaper idea could only take us so far. We wanted to start exploring the possibilities of the Web. The Web, if it were to be used to provide financial and material management, needed structure - a familiar concept or model so that users would not get lost in a maze of hypertext links. In our case, it was the organisational structure.
Thus, when we started building Resource Navigator, we used the organisational structure of the Antarctic Division and its major materials management activity; that is, shipping as the main guiding influence upon Web structure.
To use Resource Navigator, all a user needs to know is where they are in terms of the organisation's structure.
Under the functional model, there usually exists one screen to carry out one function across the application. The user has to know how to get to, and how to use, each of the application's functions. This in turn requires foreknowledge of codes, accounts, charts of accounts etc. (see Figure 4).
The practice of 'screen scraping' is, in most cases, not enough ('screen scraping' is the copying of functionality from the original ASCII screens to the Web). We believe that this only serves to perpetuate the need for specialised knowledge and higher levels of training to effectively use the screens. In addition, differing applications require different skills, whereas the Web can unify modes of access and operations for all applications within the organisation.
Using the organisational structure for our Web pages, the user 'navigates' through the organisation. As the user moves through each level - branch, section and subsection contextual information is added to links that run CGI programs. Thus, at each page, representing a section, all reports, queries and data input screens are pre-determined (see Figure 5). The user does not need to know any charge codes or requisition prefixes, or other specialised knowledge whatsoever to view information relevant to the organisational component to which they belong. In other words, all you need to know is were you are! We believe this idea has been central to the success of the Resource Navigator.
|
|
Functional |
Organisational |
| Ease of use |
Low |
High |
| Contextual content |
Low |
High |
| Training required |
High | Low |
|
Intuitive |
Low |
High |
|
Entry of reference data |
High |
Not Required |
| Effectiveness of meeting user's information needs |
Low |
High |
Resource Navigator uses images to provide visual cues and simple graphs, as well as to reinforce the organisation's cultural icons such as Antarctic landscapes, wildlife and historic moments.
An example of an image cue is the shipping container thumbnail images used in the Shipping Module (see Figure 6). When creating container labels or drilling down on container searches, these images, at a glance, identify what type of container the user is dealing with.
Another visual device we are using is a graphical "thermometer" indicating the level of funds for a particular section of the organisation (see Figure 7). This becomes an easily understood cue - if the mercury is high, then expenditure is high and money is scarce!
A thumbnail image of a thermometer serves as a quick indicator linking to a larger, more detailed image. The thermometers are very popular with senior management, including our Director, as they can easily digest at a glance the financial position of their branch, their sections or even the whole organisation.
We have found that there was no need to create numerous graphical variants of the data as this would lead to confusion and detract from ease of use.
Something that can assist in the acceptance of a Web-based application is the use of images to reinforce organisational cultural icons. When first implemented, MIDAS was perceived to be unfriendly and alien to the Antarctic Division. As an 'off-the-shelf' package, it did not use familiar nomenclature and users had to often negotiate around screens with unused or redundant fields and functions.
On Resource Navigator, we have used Antarctic images on most pages to remind users of what the organisation stands for and to reinforce the idea that Resource Navigator is part of the organisation and not apart from it. The home page has an image map which is a montage of an icescape with expeditioners, traverse tractor train, and the theodolite that was used by Sir Douglas Mawson. The theodolite theme is carried throughout, as well as the Resource Navigator banner whose name is carved out of the blue Antarctic ice.
Criticality is no criterion. Many critical functions are performed by power users which are often large iterations of similar transactions - for example, the payment of accounts.
Whereas other functions, such as requisition entry (see Figure 9) are equally critical but performed by casual users, these functions are often characterised by low transaction levels.
Certainly, in deciding what functions to add to Resource Navigator, our main aim has been to ease the burden of the casual user.
Navigational aids are essential. Relying on traversing the cache to try and get back to a known point can lead to confusion, especially for a user who has previously bounced back and forth between a few pages. Within Resource Navigator, we have on most pages a navigational menu to help users get to any of several key pages. Many of the functions on the section level pages result in multiple CGI-generated pages. On the bottom of the generated pages are links to all the other generated pages as well as a pointer back to the original calling section page.
The Web interface has served to hide the substantial complexity of the Shipping module. Our early concerns about introducing such a complex system into an industrially sensitive area proved unwarranted - the stores staff have accepted it enthusiastically and demonstrate its operation to allcomers with pride.
Antarctica is only accessible for a limited period over summer by ship. Any delays or stores shortfalls can be costly. The new Shipping Module provides manifest information available instantly to both staff in Head Office and expeditioners in Antarctica via the Resource Navigator. Deficiencies can now be more easily detected and rectified prior to the departure of the ship.
Resource Navigator has a combination of network, operating system, Web server and database application security mechanisms to control access to its pages.
To really secure documents, it may be necessary to resort to encryption through SSL (Secure Sockets Layer) or other methods. We haven't yet felt the need to go that far.
Some of the benefits listed seem somewhat intangible or difficult to quantify, but it is often the 'intangibles' that make the difference between the success or failure of a system. Poor user acceptance, a perception that the system is difficult to use, and that relevant information is just not being delivered to those who need it most, can lead to the demise of even the most well-regarded systems.
As we embark on developing ever more complex Web-based applications, it seems inevitable that we will need to use Java and Javascript to increase the sophistication of browser interactivity. Only recently, more friendly development environments for Java have appeared commercially.
Our longer term aim is to reduce the amount of time users spend interacting with the system so that they can maximise their productivity. One way to do this is through simple software agents. Already, automated mail messages are generated upon the detection of certain events, advising users that a requisition is in need of approval or that a requisition entry has failed. The next step would be a customised agent controlled through a Web interface set up to act according to a set of rules 'watching' for certain events and advising their user of the event or perhaps even suggesting a course of action. We see this as an evolution toward an 'i-net', an intelligent intranet where agents conduct business with other agents and users can minimise the amount of time interacting with the system without compromising information delivery.
By mid 1996, we have doubled the number of people interacting with the system on a daily basis. The one Web interface is used by everyone, from a temporary employee in the Store, through to middle managers, right up to the Division's Director (Chief Executive Officer). We believe that, using the Web, we have succeeded in producing not only an Executive Information System (EIS) but also a Staff Information System (SIS) wrapped into one.
This paper has described not only the use of email and the Web to augment a traditional text-based, terminal mode, database application, but also explored the simple but powerful guiding principles that have made these alternative information delivery systems such a success at the Antarctic Division. These principles include: the use of familiar structures, such as organisational structure, to give context; delivering appropriate information to the user; and increasing usability by decreasing the amount of knowledge required to drive the system.
John Chrisoulakis BSc (Inf. Sci.), Grad. Dip. Mgt., MACS
Since graduating from the University of Tasmania in 1984, I have worked both in the Tasmanian state public service and in private industry, primarily in the role of analyst/programmer. I joined the Australian Antarctic Division, an agency of the Commonwealth Department of Environment Sport and Territories in 1990. For the majority of my career, I have mainly been involved with DEC VAXes and VMS, but for the last two and a half years my main focus has been with Unix with my role as support programmer for the Division's Financial and Materials Management software and the platform on which it runs.
Paul Hanson Assoc. Dip. Applied Science (Computing)
I have worked with a number of mainstream Commonwealth departments until commencing with the Australian Antarctic Division in 1983. I began my involvement with the MIDAS implementation in late 1991 as System Administrator. Prior to that, my career was a mix of Human Resources Management, overseeing the recruitment of Antarctic Expeditioners for six years. I then moved on to Financial management as System Administrator, Analyst and Programmer for the Division's staff planning and asset management systems. My main role now involves that of supervising the day-to-day system operations as well as that of 'business analyst' guiding the future of the Division's Resource Navigator intranet.
