Roger W. Shaw The Wellcome Foundation Ltd. London, England



For financial planning to be of value, particularly when dealing with short term forecasts, data must be collected, processed, and presented rapidly. Since the end of 1978, The Wellcome Foundation Ltd., a British-owned research-based pharmaceutical company with an annual turnover of 380 million pounds, which operates in most parts of the world, has used direct Telex access to speed the collection and validation of data from approximately 30 countries in all continents. This paper outlines the systems used, describes in sufficient detail to serve as a practical guide the ways in which they were modified for Telex use, and assesses the success of the project and some implications of this approach in respect of reporting organisation and structure.


The economic climate of today presents a challenge, especially to international companies such as the Wellcome Foundation Ltd., a British-owned research-based pharmaceutical company operating via subsidiaries and agencies in most pans of the world. To meet this challenge many things are required, among them the provision of accurate and timely information relating both to current performance and future plans, and it is primarily in this area that the Group Corporate Planning Directorate has its activities.

Recognizing the importance of speed and accuracy in the planning process, Wellcome's Group Corporate Planning Directorate embarked on computerisation of its planning systems in 1974. Today the Directorate has several large computer-based systems for different areas of planning, all of them written in APL; it is with one of these systems, known as UNICORN, after the company logo, that this paper is concerned.

An Outline of the UNICORN System

UNICORN is the main planning system used by the Directorate, and was the first to be computerised. In 1974, a first version was implemented using the I.P. Sharp AIDS package, which provided a useful starting point and much experience when, after a year, it was decided to write a customised system specific to Wellcome. Further development has now led to a system which is powerful and sophisticated, yet flexible, comprising some 6000 lines of APL code.


Briefly explained, the UNICORN system enables the user to input financial data relating to various pre-defined time-periods, manipulate that data (in particular by running model programs which calculate and store derived data) and generate reports from it. Naturally there is much more to it than that, such as currency conversion, consolidation, "what-if" capability and so on, but this simple description will suffice for present purposes.


In its earliest form, the system was essentially a budgeting exercise, in which all the relevant entities (overseas subsidiary companies, etc.) completed a set of forms which were then returned to the Group Corporate Planning Directorate, where they were input to the computer. Once in the machine, it was validated, evaluated and used as the raw material for further exercises. Data was added in respect of intra-group transfers and other non-locally determined items, so that a complete picture of the Group's Financial plan over the specified period could be prepared for review by the Board of Directors.

At an early stage, it was realised that considerable benefits would be obtained by making available UNICORN to those overseas subsidiaries who had access to the Sharp network, and whose size would justify their use of it. Accordingly, by the end of 1976, the system was being used via terminals by users in Canada, USA, Belgium, The Netherlands, and Germany as a tool to develop and refine plans before submission. By this time, UNICORN had been extended, and was being used not only for the original annual exercise which looked ahead over 3 years with the budget year being by quarter, but also at quarterly intervals for "rolling forecasts" looking ahead over 18 months by quarter. These quarterly forecasts were basically a simplified version of the full Three Year Plan.


However, because of the volume of data to be processed (approximately 1500 possible lines, covering 8 or 10 time-periods, for each of about 80 Reporting Units), and the process of reconciliation and addition of non-local (i.e., UK-supplied) data, even for the quarterly forecasts it still required up to 6 weeks after the receipt of all overseas data before the final reports, including consolidation to Group level, were ready for presentation to the Board. Allowing for 2 weeks postal delay, this gives a total of around 2 months from the issuing of figures by Reporting Units, to their review. In other words, bearing in mind that the majority of the exercises performed were based on Quarterly Forecasts, it is clear that the better part of one planning period had elapsed by the time any decision resulting from the exercise could be implemented at Reporting Unit level.


In late 1976, with UNICORN well settled down, it was decided to look for ways to shorten this period. Major time-consuming areas which seemed susceptible to improvement were seen to be postal delays, the input of data by Corporate Planning, and the subsequent model running and "cleaning-up" of data (frequently requiring referral back to the Reporting Units), which was all-too-often necessary. None of these problems exist, of course, where the data is prepared on the system by an overseas terminal user — at least, those that do still exist are the responsibility of the overseas user himself, removing a considerable burden from Corporate Planning.


The problem then, was to find some way of providing access to the system to more overseas users. The answer, it was thought, might be Telex. The next problem was that I.P. Sharp had at that time no Telex facility, but nonetheless there were other APL bureaux who had, and Wellcome's interest was so great that a study to determine the feasibility of this approach was initiated forthwith.


Potential Problem Areas

The problems associated with the introduction of Telex access to UNICORN could be broadly grouped into two categories: philosophical or general problems, and technical problems.


The philosophical problems were chiefly:


a) Which Reporting Units were to use the system?

b) Who, within those units, would the actual user (i.e., the person physically at the Telex machine) be?

c) What kind of user training would be required?

d) Could the system be sufficiently simplified and automated?

e) Would the whole exercise be cost-effective?

The technical problems could be summarised in the following list:

a) Would the availability of Telex lines be adequate?

b).Would Telex line quality suffice?


c) What computer service availability would there be? In particular, near 24 hour service would be required, and "Christian" public holidays would need to be covered.


d) Would the Telex line speed of (effectively) 6 c.p.s. be sufficient for the volumes of data envisaged?

e) Could we manage with the very limited Telex character set?

f) Could we manage with a page width of around 58 columns?

g) Could sufficient on-line help be provided?

h) Was the system sufficiently fool-proof — e.g., how might a user cope with the kinds of errors experienced in quad mode (bearing in mind that this was before Event Trapping was available)?

i) How could we reduce "think time" to an acceptable level, for at rates of up to $5 US per minute in Telex charges, this threatened to be the major cost item?


Clearly, some of these questions could only be answered by a realistic trial, and therefore, a somewhat simplified version of UNICORN was implemented on a bureau then offering Telex access in The Netherlands. Although simplified, this trial system had to offer the full range of facilities intended for eventual use if the system were finally implemented on I.P. Sharp. This also gave an opportunity to experiment with alternative ways of achieving some of the UNICORN facilities, such as combining the usual sequence of models into one single model in the hope of a gain in efficiency (in particular with regard to file accesses) as well as simplicity of operation. (In the event, incidentally, the existing modular approach to models was retained).


By March 1978, the trial system was operational, and tests were then conducted from two locations thought likely to be reasonably representative, namely Monaco and Colombia, South America. These tests required a brief visit from a member of Corporate Planning, who went through a complete exercise as it would eventually be run. The results of the tests were very encouraging; in particular Telex line availability and quality appeared quite acceptable. Discussions with I.P. Sharp revealed that their plans for Telex access were well in hand, and as the tests had indicated that the Telex approach should indeed be cost-effective, work on adapting UNICORN was begun immediately.

Modifications to the UNICORN System


The entire process of Forecast preparation had to be examined to look for areas where modifications might be needed. The starting point was to consider the data being collected: should or could this be changed? It was decided that the data items being collected were all essential, but not necessarily for all time-periods. It was decided initially to implement Telex use for the quarterly rolling forecasts, with a view to possibly extending it to the full annual Three Year Plan exercise if it seemed appropriate.


For the quarterly rolling forecasts, the Reporting Units were already divided into "major" and "minor", on the basis of Sales Volume, which broadly corresponds with the overall size of the operation and hence the local effort available. A "major" unit was required 10 submit a forecast over all time-periods, but a "minor" unit was required only to submit data for the first two, namely Actuals at the end of the last quarter, and Latest Estimates for the current quarter. The remaining time-periods were obtained by interpolation or simple extraction from the most recent Three Year Plan. Inevitably, the direct submission of only the first two columns by "minor" units would open the door to the possibility of problems in grafting the two sets of data together; it was decided that the resolution of any such problems would be the responsibility of the Corporate Planning Directorate after submission, the unit being required only to submit the first two columns in isolation.


The next question was that of forms design. The forms then in use had already evolved into dual purpose documents acceptable to an accountant as an appropriate way of presenting financial information yet capable of use as a punching document. It was felt, however, that an extra column should be added to contain a compulsory "checksum", which would be simply the sum of all the data in the row together with the row (or "ID") number. The fear here was not so much of possible loss or distortion of data over the Telex link, as of punching errors in data preparation by the operator.


Next we turned to the computer system. Up till then, we had been dealing with relatively sophisticated users, and UNICORN acknowledged this by being designed as an "open" workspace, in which the user "rummages around", calling up whichever routines he wants. This is far too error-prone a method for the unsophisticated users we had in mind, and would make the system difficult to learn as well as potentially running up large bills for Telex charges while the user wondered what to do next. Accordingly, it was decided that each user should initially be provided with a CONTINUE workspace which would ensure self-starting (in fact, re-loading of the normal workspace unless suspended in execution of some other function). Routines were also provided, of course, to ensure that when the user ended his session he did so by means of a simulated )CONTINUE (i.e., WALKAWAY), thus making the process self-perpetuating. On loading the normal workspace, it was therefore necessary to detect whether a user is at a Telex or not: this is a problem which we have solved, though not to our complete satisfaction. One approach, of course, is to keep a list of account numbers of Telex users; this however, is inelegant and error-prone. Another is to identify the IPSA network node number, but this only works if the network is never reconfigured in such a way as to change the number. The most obvious way is to identify the terminal type specifically as a Telex, but unfortunately Sharp have at present no unique type for this, a Telex machine appearing as a bit-paired ASCII terminal. Luckily this type of terminal is actually quite rare, and so this is the mechanism on which we finally settled. It is only fair to admit that so far we have had no major problems as a result of this approach, but it would clearly be much more satisfactory to have a unique code.


User confidence is always important in this type of venture, so the first action the system takes is the printing of a short "reassurance" message, incorporating the name of the country concerned. From here the next step is the automatic selection of the appropriate data file, and of the set of data within that file — a blank set will be set up when the user first accesses the file. The selection of the file is automated by making only the appropriate file "visible" to the user by means of access matrices; at the appropriate point early in each exercise these are set up, and after submission the Telex users are removed, thus guarding against users accidentally (or otherwise) changing their submissions without reference to Corporate Planning. It is worth noting also that, as a consequence of the automatic selection of the set of data within the file, Telex users do not normally have the facility of preparing more than one version of their data. This is not felt to be a serious loss, as it was not anticipated that the system would be used in this way by Telex users, and this has been borne out by subsequent experience.


Having thus painlessly entered the system, the user must make his first decision, as the system asks whether he is submitting 2 columns or ALL, and on giving an answer he comes to the main "menu". This is a very limited set of available commands, in sharp contrast to our customary philosophy of allowing the user free range. In fact there are just 5 options: INPUT, COMPUTE, PRINT. SUBMIT, or OFF. Implementing each of these 5 options involved changing existing methods. Below, each option is discussed in turn, together with the problems posed and solutions provided.

Data Input

The terminal user would usually prepare his forecast "form-by-form", not moving on to the next form until he was happy with the last one. UNICORN therefore contained an independent model for each form. However, this method is relatively time-consuming and calls for a reasonable measure of skill in computer terms. In the interests of simplicity of operation, it was decided that this "piecemeal" approach to the preparation of a forecast would have to be replaced by a "monolithic" approach. Hence it was decided to require that all the data for the basic input lines on all the forms be input before any attempt at modelling can be made.


It was clear that the volumes of data necessitated an approach using paper tape or some other comparable medium. Even with the buffering used by the Sharp system it is inadvisable to attempt to process data as it is received; rather it must be read as rapidly as possible, using in the case of UNICORN direct quote-quad mode rather than an "ask" function, and simply stored until the tape is finished. In practice this means that each physical line of data must be searched for a logical data terminator (in the case of UNICORN the word END is used), and unless this is found the line is merely stored in character form in a buffer within the program and the next one scanned. It is also necessary to use logical line terminators (in this case an oblique "/") since the narrow width of the typical Telex carriage (about 55-60 characters) often prevents a full line of data being contained within a single physical line.


Only when the logical data terminator END has been encountered can the processing of data begin. Apart from any other considerations, there is no means of switching off the Telex machine's paper tape reader under program control (i.e., X-OFF), which means that no error messages can be generated until the tape has finished. At the time of the initial implementation of the Telex facility for UNICORN, Event Trapping did not exist, making exhaustive syntax checking a tedious but absolutely essential process. Once this has been done, and the checksums have been validated and any appropriate error messages have been printed, the remaining successfully read data can be written to file and the user returned to the main "menu". Corrections to faulty data are then effected either by means of another data tape or, if few in number, by directly typing in INPUT.

Model Running

Model running is achieved by selecting the COMPUTE option from the main "menu". As one might expect from the above, the effect is to run all the individual models in the correct sequence. One problem which can arise from this is the generation of excessive quantities of error messages, all resulting from a single error in data early in the sequence. The decision must therefore be taken as to whether any of the possible errors which may occur should be treated as "fatal", causing an abort from the sequence of models and a consequent return to the main "menu". After some discussion we decided against this, on the grounds that most data errors would not cause more than one or two messages, and aborting implies losing the possibility of locating other unrelated errors on the same pass.


In many cases, the error messages which could be generated by the models required modification. The two chief causes were that they sometimes used characters outside the Telex set within the text part of the message (e.g., the minus sign in "ERROR 1.3: - NEGATIVE SALES VALUE"), and that the figures causing the error were normally formatted in a manner unsuited to the restricted width of a Telex carriage. Both of these problems were fairly simple to solve, although the latter entailed the sacrifice of aesthetics, for whereas an error message on a terminal giving, say, eight columns of figures would allocate 10 print columns to each numeric column allowing conventional decorations such as commas, parentheses for negatives, etc., on a Telex the decorations are not practicable, and the printed format must have the columns as close as possible to each other. Alignment within columns is preserved as being essential for legibility, but columns are not all necessarily of the same width. Fortunately all model errors in UNICORN are handled by a standard validity-checking routine, which greatly reduced the problems.


In general, some errors are to be expected on the first pass through the data; for brevity and economy the messages are kept reasonably short, but all errors are fully described and explained in the user's documentation. Probably, on receiving an error message, the user will inspect the values of a few IDs using the PRINT option described below, and will then return to INPUT to make corrections before re-running COMPUTE. It may well be that, because of "think" time, this process of correction takes place over several Telex sessions, as it is rarely sensible to work out where the errors lie while still on-line. Eventually, however, the data should be clean, and the user can move on to printing selected lines.




The user at a conventional terminal generally inspects his data in one of two ways:

he either examines selected IDs (perhaps specifying only certain time-periods) or he generates a complete report. There are many standard reports available, the simplest and most often used being "facsimiles" of the original forms. However, because of speed, character set, and page width constraints, the generation of full reports is impractical for a Telex user, so a modified version of the method of inspecting selected lines of data was implemented.


The PRINT option from the main "menu" enables the user to print the values of IDs selectively. The user is requested, on selecting PRINT, to specify a list of IDs; simple means are provided to meet such common requirements as "all the IDs on a particular form", as well as the ability to specify a range of IDs or a straight-forward list. One further, very important, option is the reply CHECK. This results in the printing of a list of about 10 "key" IDs, such as Total Sales, Trading Profit, Overdrafts, etc. The particular significance of this option is discussed in the section on submission below.


Overall, it is not usually the case that users perform all their calculation only on the system. The reason for this is mainly cost, as the time taken to print all the calculated IDs would be prohibitive. Instead, the practice is to inspect selected calculated lines. and compare them with those calculated by other means, thus checking the calculation. This essentially is a characteristic of UNICORN, rather than Telex systems in general.


Submission of a Completed Forecast


Selection of the SUBMIT option from the main "menu" causes a message to be sent to the UNICORN steward, advising him of the fact that this user has run SUBMIT. This is achieved through a standard Wellcome internal mailbox system.


Two vital safeguards are built into SUBMIT. The first of these is a method of ensuring that the user has not input changes to the data since last running COMPUTE, and is achieved by flag setting and unsetting in the two routines respectively. If the flag is found to be set, SUBMIT generates an appropriate error message to the user, and refuses the submission. The second safeguard is to ensure that the key IDs have been listed by the user, so that Corporate Planning can be certain that the user is aware of the results of the calculations upon his data. This is the purpose of the CHECK option in PRINT; again a system of flag-setting is used so that the submission is rejected with an appropriate error message if CHECK has not been selected within PRINT since the last COMPUTE.


A further possible action which was considered for SUBMIT was the automatic shutting-off of file access to the user, to prevent subsequent alteration. However, the frequency of last-minute revisions experienced in practice meant this idea was rejected.


Telex users are not required to forward a hard copy confirmation of their data, the invocation of SUBMIT is all that is required. A number of users have requested that Corporate Planning return to them a set of facsimile reports after receipt of the data, which of course presents no difficulty,


Logging Off

The OFF option, as described earlier, logs the user off by calling WALKAWAY and returning with naked right-arrow to immediate execution. An appropriate latent expression is set for the CONTINUE workspace, thus making the system self-perpetuating, and a mechanism of "System Version Numbers" ensures that Telex users always get the most recent version of the UNICORN "pseudo-workspace" when they next log on, even though it may be 3 months or a year later [Mathieson Shaw and White 1980].

Additional System Developments


One of the potentially most baffling events which a Telex user might experience would be a "break-in", causing suspension of execution. Guarding against this was unfortunately impossible in the first release of Telex UNICORN, but became possible with the introduction of Event Trapping. A Telex user can generate an interrupt by striking any key or keys rapidly while the Telex machine is printing. The action taken on a user interrupt is simply to return to the main "menu"; since it is very unlikely that an interrupt will occur other than by a user deliberately aborting during printing, this action is generally appropriate.


UNICORN provides a standard HELP facility; if a terminal user types HELP at any stage, whether in response to a prompt or not, he receives a brief one-line help message, from which he may if he wishes then go on to request a fuller explanation. It was obviously essential to ensure that if a Telex user invoked HELP he would receive clear, concise instructions telling him exactly where he was and what he should do next. Accordingly, the action of the HELP function had to be modified for the case of a Telex user. In addition, as data input from paper tape is performed by direct quote-quad mode, the INPUT routine must scan each line as it is received for the word HELP before storing it in the internal buffer, printing an appropriate message if necessary.


As a check on the difficulties experienced by Telex users, the HELP routine also, unknown to them, sends a message via our internal mail system to the UNICORN stewards, notifying them of the error message returned to the user and the state of his )SI stack.


Further ways in which the progress of users is monitored by the UNICORN stewards are, firstly, the automatic generation of internal mail messages whenever a Telex user logs on or off (the latter only when he does so voluntarily via the OFF option, line drops not being trapped), and secondly a copy of any serious error messages he receives from the system. In this way a user in trouble can quickly be identified, and corrective action taken.


A problem which can occur in systems of this kind is that of language. In the case of UNICORN, this did not arise, as English is the "working language" of Wellcome, and one can be confident that users will be proficient in it. In the general case, however, thought may need to be given to the provision of message files in other languages.

User Documentation & Training


A user manual had to be written specifically for Telex users, as although very comprehensive documentation already existed for terminal users, it was felt that a simplified guide would be easier to follow. The Telex User's Manual contains approximately 30 pages, with sections on every possible stage of using the system, from the completion of the forms to Error Recovery.


Experience has shown that user training takes approximately 2 days, and to be effective must be performed at the user's location. Although not always the case, the Telex is usually operated by a senior secretary, generally that of the General Manager or Finance Manager of the company in question. The responsibility for the preparation of the figures would generally lie with the Finance Manager. This means that two people need to be trained in different aspects of the system, with the additional complication of needing to identify the point at which the advice of the other should be sought. This is in marked contrast to the UNICORN terminal users, who are all of them senior financial executives operating the system themselves. It is probable that this is a result of the traditional function of the Telex machine in the office environment, but whatever the cause, it is a fact of life and must be accommodated.

Other Systems Using Telex


Once the UNICORN system had been successfully adapted for Telex use as described above, the Corporate Planning Directorate became involved with a related application. This is a system for collecting preliminary estimates of key performance figures from all overseas subsidiaries immediately following the end of each quarter, enabling the Board of Directors to obtain a rough guide to Group results some 4 weeks or so before true "Actuals" become available.


Technically this system, known as the Flash System, is extremely simple, as it consists of merely collecting approximately 20 numbers and a check total from each unit, with no calculation or validity checks. The benefit of this simplicity is found in the fact that it was possible to bring the system into operation merely by sending to all units a two page set of instructions, with no training visit; the success rate on the first attempt was well over 90 percent, with the remaining problems virtually all being concerned with availability of Telex machines or lines.

One aspect of this system in which it differs significantly from the Telex version of UNICORN is that all input is expected to be typed from the Telex keyboard, and not input from paper tape. This is in order to be able to include users whose machines have no tape facility, as well as keeping the operation of the system by the user extremely simple.


Again, once the data is in the machine, it is examined, additions are made in respect of non-local items, and reports are produced. Currency conversion and consolidation are carried out, and Group level reports are produced and presented for Board review within about a week of submission. Even a week might seem in some ways excessive here, but it should be explained that the principal cause of delay is the need to add non-local data dependent on the submission, and often considerable time has to be spent in consultation for this.

Although technically somewhat dull when compared with UNICORN, the implications of the Flash system are in some ways vastly more exciting. The successful operation of the system is evidence that it is possible to collect data on-line from anywhere in the world where there is a Telex machine, provided that the systems used do not make excessive demands on the users. The data can, in a properly designed system, be rapidly processed and evaluated, giving the potential for much swifter action and more effective


decision-making by corporate management. At the same time, in the case of systems which provide some kind of feedback, another tool is provided for local management, so that benefits can be realised throughout an organisation.


An Assessment of the Success of the Telex Systems

Overall there can be no doubt that the Telex systems implemented by the Corporate Planning Directorate have proved highly successful. Operational problems have been very few, being confined generally to shortage of Telex lines and occasional line failures in some of the more remote parts of the world. Problems of line noise have, somewhat to our surprise, turned out to be virtually nil. The user reaction has been generally favourable, and in some instances very enthusiastic; this is no doubt partly due to the fact that Corporate Planning share the time saved with the Reporting Units, relieving them of a little of the end-of-period pressure they inevitably experience. This time-saving has worked out at about 2 weeks, of which perhaps 2 days are given to the Reporting Units; the saving is as much as was aimed for, and is of real value in enabling earlier Board review, and if necessary action than was formerly possible.

The accountants within the Corporate Planning Directorate have found that the technical quality of the plans and forecasts has been maintained and in some cases improved with the introduction of Telex access. Occasionally, however, there are still problems where items arise whose treatment is not adequately covered by the standard forms. Such problems usually need resolution by consultation with the Reporting Unit; the reason why they are perceived as problems is that the Telex systems are designed with a strong bias towards simplicity, so that although UNICORN can handle such exceptional problems as, for example, converting a Branch Office to a Subsidiary Company, the method of doing so is not covered by the standard documentation. In practice, such problems are very rare, but when they do occur, the course followed is for the Reporting Unit to submit the basic data, and any esoteric adjustments are made afterwards by Corporate Planning.


The costs of using Telex access have also turned out to be approximately as expected. Currently 10 Reporting Units submit forecasts regularly by this method; an analysis of the total connect times for these units in the most recent exercise shows a mean of 40 minutes with a standard deviation of 12.5 minutes. The mean number of total lines of local data in each of these forecasts was 272, of which 110 were basic input lines and the rest were derived. Each line contained 8 data items. For the most recent Flash exercise, in which 30 Reporting Units submit via Telex, the mean connect time was 8 minutes with a standard deviation of 5.25 minutes. The connect times for the Flash are perhaps a little higher than one might expect, but this is probably an inevitable consequence of the decision not to use paper tape input for this system.



We have shown that the use of Telex direct access for the transmission of reasonable quantities of data and manipulation of that data by interactive computing is a practical possibility. Careful attention to systems design, especially in the areas of reliability and simplicity, is even more important than usual, and the cost-effectiveness of the system as well as the desirability of the re-distribution of workload can only be determined by the management of an organisation proposing to use this approach. Used sensibly, however, such systems undoubtedly have the potential for improving monitoring and control of widely dispersed business operations, and from discussions with I.P. Sharp as well as other computer users it is clear that this method of access, which effectively gives a network across the entire world, is certain to grow.


D.G.I. Mathieson, R.W. Shaw and J. White, "Civilising APL: An Approach To Integrated APL Systems", APL-80 Conference Proceedings, June 1980.