Lynne Pegler, Quality Manager, NRSC
John Glasscock, Operations Director, NRSC
The National Remote Sensing Centre Ltd's business is the interpretation and distribution of imagery, (an example of which can be seen in Figure 1), acquired by either satellite or airborne sensors, to a very diverse set of market sectors including Local Authorities, Oil, Gas & Mineral Exploration companies, Environmental Agencies, UK and European Commission Agricultural Departments and many more. NRSC has its roots in what was the Royal Aerospace Establishment in Farnborough (now the Defence Evaluation and Research Agency (DERA)), which is part of the MoD. Its Quality System was originally inspired by that culture which is by its very nature, bureaucratic. In keeping with the Government's commercialisation philosophy born in the late '80's, it was decided that NRSC should be assisted to become a commercial entity before the mid 90's and ISO 9001 certification was sought based on the procedures originally developed for compliance with AQAP standards.
Figure 1: Sample of Satellite Imagery: Landsat TM Image of Iran
Time moved on, and NRSC Ltd, now a commercial organisation with 120 staff and a turnover of £7 Million, was increasingly being asked to respond to its clients in a much more commercially responsive manner, not in keeping with the bureaucratic controls being imposed by its procedures. The company reorganised several times, the procedures (ten volumes of them), were embedded with organisational references, maintenance from the quality point of view was a nightmare and the backlog was building. The information update turn around time increased, staff were also starting to express doubts about the usability and general "user-friendliness" of the procedures and the cost of maintaining the quality system as a result, was increasing.
It is difficult to assess the true cost of 'Quality' as there is no precise definition of what should be included within this area. For the purposes of this paper, quality costs are divided into three areas: firstly the cost of prevention which includes training, procedure maintenance, technical and commercial reviews of proposals and more generally any activity which is undertaken to minimise the chances of getting things wrong; secondly the cost associated with the running of a quality system i.e. the monitoring and management of the quality system to ensure that practice in the organisation is compliant with the system; and thirdly the cost of failure, which could result from an internal failure to the organisation or arise due to failure detected by fee paying clients.
The aim of any initiative associated with the quality system must be to reduce the sum of these three costs. In general, and certainly at NRSC, the costs associated with failures can be substantial. The measurable part of this cost is the effort required to redo unsatisfactory work but there is a potentially larger element which relates to the loss of future work. The model we used to drive NRSC's new quality system is shown in Figure 2. The key features of this model are that by an investment in prevention (through amending the procedures and providing the necessary training in their use), the cost of running the system and the cost of failure should be reduced, yielding an overall saving in the total cost of quality.
Figure 2: Cost of Quality
It became clear to us, as we examined the NRSC's procedures, that the excellent work done several years ago to reform and systematise the company's practices to gain ISO 9001 certification was in need of review. The procedures were admirably comprehensive, detailing everything from the minutiae of software testing up to the management of projects and subcontracts.
We therefore began with a fundamental decision: to separate the functional and organisational aspects of the procedures. The organisation would naturally take the form of a tree, while the functions could be analysed and drawn as a network of communicating processes. A process in the functional layer, such as maintaining the purchase ledger, would be linked to the appropriate branch of the organisation tree, such as the finance directorate. The finance Director's name would be shown only on the organisational layer. In effect, the organisation becomes an overlay on the functional analysis (Figure 3).
Figure 3: Functional Quality Procedures with Organisation as an Overlay
This separation enables the company to change without necessitating a complete rework of the quality system. Indeed, assuming that the functions - management, finance, personnel, quality - stay in place, only the organisation chart need be updated whatever the nature of the reorganisation in future.
How could this be achieved? Clearly, the first task was to focus on the pure functions of the company, ignoring (for the moment) who did what. For example, it was not an essential function of the company that, as it happened, the personnel department seconded some administrative staff to assist finance with the preparation of the payroll. The function was not "provide admin staff to assist..." or even "assist with payroll", it was simply "pay the staff", which was evidently a financial task.
This kind of thinking creates a network of inter-related functions, with information flows between them. We therefore decided to apply a dataflow diagramming method, selecting Yourdon Structured Analysis [4] as the simplest and most familiar. As we principally wanted to achieve clarity of functional analysis, we decided to group the information flows wherever possible, so as to minimise the number of interfaces between functions. We therefore chose to show only one information flow arrow between any pair of process bubbles; a finer structure of information flows (analysing the single arrow) is shown on the lower-level diagrams which analyse those processes [1]. One of our modified-Yourdon diagrams is shown in Figure 4.
Figure 4: A Modified-Yourdon Diagram Analysis of Quality Procedures
Our initial idea was simply to prepare a hierarchy of Yourdon dataflow diagrams, stopping when a process bubble had been created for every function that we considered important enough to have its own company procedure or work instruction. A table would then cross-reference that function to the appropriate pages in the existing manuals, to satisfy the ISO auditor. At this stage, therefore, the proposed quality system architecture was as shown in Figure 5.
Figure 5: First Architecture of Quality System
The diagrams would be printed, one per page, each describing a function, with references to the procedures and the responsibilities for executing it. We therefore interviewed senior staff within the company and identified with them the functions which they or their departments performed. Several times we were unable to relate these functions, only to discover that the problem was an artefact of the current organisation: in each case, the apparently unrelated functions belonged elsewhere.
Perhaps the clearest case was in the commercial review of operations such as bidding and the preparation of contracts. These functions, although critical to the existence of the company, and performed by the most senior staff in the commercial directorate, logically belong with the operations themselves. In fact the commercial functions form part of the simple sequence bid-win-sign-work-deliver which makes up the top-level function "work for clients". There is no separate function called "perform commercial operations", but there are three vital commercial steps within the cycle of working for a client: deciding whether to bid, pricing the bid, and negotiating the contract.
As we proceeded with this analysis, it became clear that the steps we were identifying were the natural places for the various forms which were used to support company procedures. For example, bids must be registered before bid preparation may commence. It seemed an ideal opportunity to attach references to the forms also: the diagrams could lead not only to the procedures and the responsibilities for each function, but to the latest forms. The quality manager had already collected and revised many of the forms into a directory; we could encourage compliance with procedures by pointing to the officially approved forms. The quality system therefore acquired the architecture shown in Figure 6.
Figure 6: Quality System Architecture with Forms
This was beginning to look like a hypertext. Since the forms were available on-line, but were little-known to company staff in this form, we saw that we could dispel the feelings that the procedures were remote and bureaucratic. We could introduce a simple set of Intranet pages (written in HTML, for access by a browser such as Microsoft's Internet Explorer or Netscape's Navigator), with direct links to the forms.
In fact, links could be made to any other chunks of information, whether documents, spreadsheets, images, presentations, or other Intranet pages. Since we had started out to achieve clarity and simplicity by factoring out form from function, we considered carefully what we needed to express if we were to automate the quality system.
We already had:
Other tables could include
Some assistance with navigating the system was needed, so we specified
Finally we added the idea of
Suddenly we had a fully-fledged architecture for a hypertext-based quality system (Figure 7).
Figure 7: Quality System as a Hypertext Architecture
The Overview of Procedures can be seen to be the hub of the system. The Overview pages were each to consist of a simplified Yourdon diagram, with references, now to be implemented as hypertext links, to the Mappings table and hence to the old procedures, to the relevant forms, authorization levels, and the organizational hierarchy.
The higher-level Overview pages were to give access also to the lower-level functions represented as bubbles in their Yourdon diagrams. This seemed a tedious chore: we would have to construct a list of references from the database for each page, make an image which could be browsed by Internet tools (using the Graphical Image Format, GIF), and map each area representing a bubble as a hypertext link in the HyperText Markup Language, HTML.
The hand-mapped prototype with three or four diagrams worked perfectly (Figure 8). The illustration shows how, as the cursor passes over a process bubble, the browser displays the filename of the Web page that would be reached by clicking on that bubble. This particular browser also changes the shape of the cursor to a hand to indicate that there is something to click on.
As people came through the Quality Manager's office for an authorization, they spent a few minutes trying out the prototype and it quickly became obvious that the route we had chosen was proving very acceptable to the previously procedure-resistant staff.
With this encouragement, but with heavy hearts at the thought of the amount of HTML we would have to write, we programmed a short script to make the database output the co-ordinates of the required image maps and the name of the associated function. As this came up on screen, it dawned on us that not only was this exactly what we needed for the image maps, but that an only slightly more elaborate script could create the entire structure in HTML automatically.
Figure 8: Browsing a Quality Procedure on the Company Intranet
What we needed was to walk the tree of functions recursively from the top, generating a Web page for the Intranet (a file of HTML) for each function. For every function which contained other functions, we would generate an image map with links to each of the "child" pages; this would be based on the database's knowledge of the Yourdon diagrams. The basic recursive function is a five-line script; a simple function creates a file for each Web page, and a few small functions format the diagrams' Dewey numbers (like 1.3.2.2) into filenames (such as p_1322.htm for the Web page, and d_1322.gif for the image of the diagram). The job was done in two pages of code.
To map the bubbles on each diagram as clickable areas, the program calculates a rectangle based on the centre of each bubble and its known width and height. Such an area is calculated for each bubble on each diagram, creating a list such as the one shown in Figure 8, identifying the HTML file to load if the user clicks the pointing device within that area.
Surrounding the mapped image, we needed the various components which we had factored out of the old procedures, namely:
These proved simple to implement: we treated them all the same, storing them in database attributes and copying them into hypertext links automatically (Figure 9). In fact the mechanism gives the person revising the procedures a choice: enter the text (such as a pre-condition) directly into the database attribute, or enter the name of the file where the information can be found.
Decide whether to bid Single Procedure or Work Instruction Parent Page: Bid Precondition: Opportunity or RFQ. No decision on bidding. Action: Decide to bid or not using commercial judgement. Postcondition: Decision to bid or not has been made. Forms: Bidding/ Risk.doc Role / Responsibility: Authorization: Authorizations for Bids.doc Mapping to Old Procedures: 2036 No Bid Report |
Figure 9: Example of a Procedure as an Intranet Page
It is more efficient, given that the procedures are accessed over a network, to put the information into compact HTML files rather than using (say) Word documents which are typically twice as large, take twice as long to fetch, and require a copy of Word to be present on the user's machine. In addition, external application programs such as Word must be started if they are not already running.
Another consideration is that documents requiring personal computer software such as Word, Excel, and PowerPoint will probably be inaccessible to users of UNIX and other platforms. HTML is therefore preferred, but it remains convenient for the quality system that references to other types of document are permitted, allowing easy maintenance and providing continuity with existing quality forms. Fortunately, many types of document can now be translated more or less automatically using tools such as HoTMetaL Pro [3].
The reason for the complexity of the old procedures was now clear: all these very diverse kinds of information were conflated in a single text for each procedure. The procedure writer had been forced to take into account all aspects of each task simultaneously: this had undoubtedly been difficult, and it had been handled skilfully. Unfortunately, the task needed to be repeated (with equal skill) each time the company structures changed, and the required effort was not available.
The new structure can be regenerated in a few seconds, so we have not even attempted to enable regeneration of single pages. As it happens, it is possible to regenerate any subtree (such as Finance) should local changes have been made there. But in general it is easier and safer to rebuild the entire structure, an operation that used to take well over a year, when any change is made to the database.
An important aspect of the automation of the quality system has been the need to preserve ISO 9001 quality certification. The ISO auditor must be satisfied that the new representation of the procedures preserves the audited mechanisms.
The mappings table (Figure 10) is the heart of the solution to this challenge. It too is generated automatically from the database (by a script similar to the one which writes the procedures: but it writes only a single page). Where a section of the old procedures applies to a whole subtree of the new system, the references can be inherited by all functions within that subtree. Inserting any specific references within a function causes the automatic inheritance to be overridden. The mappings table is bidirectional, also pointing back to the new procedure page which points to it: clicking on the name of any function causes the relevant page of the Overview to be displayed.
1322 Engineer the System
0001 Writing and Drawing Practices
4000 System Engineering Codes of Practice
4024 Design and Development Control
4025 Design Reviews
4026 System Engineering Project LifeCycle
|
Figure 10: Fragment of the Mappings Table
Ultimately, the purely-functional Actions will be extracted from the old text and inserted into the Action section of each page (directly if short, as references to separate pages if long). At that stage, the decision may be taken to retire the mappings table, and to have the quality system re-audited as a new system in its own right. Once the transition of the information to the new QA System is complete then the mappings will fade away.
The final test of the new QA System was when the auditor came for the 6-monthly surveillance visit. In preparation for the visit, we had loaded browsers on to the NRSC staff's PCs, provided some training on the new tool and also created a Quality Manager's ISO 9001 Mappings Tool., This allowed us to make sure that the paragraphs of the standard were still satisfied by our procedures. It also showed us that from the Auditor's point of view, there was full visibility of the QA System's compliance with the standard.
The auditor was satisfied that the QA System had not changed the information content of the procedures: it was just a different way of presenting the information. The auditor did have some questions with regard to the way in which changes to the QA System between audit visits were to be presented and viewed. The main problem was not lack of information, but excess of it. The DOORS database has the facility to record every single change made, in its History log, but this would not make it easy to review the changes in a meaningful way. A 'low tech' solution is to print the pages and compare them with the ones printed for the previous visit. In addition, a baseline of the database was created for the audit and another will be prepared for the next one. Some software tools have also been created to support auditing: one displays any desired baseline of a single procedure on screen, for detailed comparisons; another enables the Quality Manager to label changes with comments on their importance in the database, and to export these comments to the Latest Changes page on the Intranet.
Driven by the desire to become more efficient and reduce 'quality' costs, radical changes to the implementation of the quality system can be made. Changes not only offer reductions in the cost of quality but also make the system more 'user friendly'.
From a user perspective, using the QA System will be a matter of personal requirement. The novice user will need to become familiar with the process diagrams and will need to read all of the instructions and understand the diagrams. The more experienced user will know which form to use and will be able to circumvent the functional information to get the required form directly. There is a changes page to alert staff to any changes which have occurred and when; staff can then review the changes either in isolation or within the context of the whole system. Staff will be able to pick and choose the information as they require it, in other words the procedures become an on-line reference tool rather than a turgid reference document.
Now, when changes are made to the organisation, the procedures will keep pace with them because they are easy to maintain, and the staff will have confidence that the procedures are a true reflection of the current operational practices. In turn, this will encourage staff to use the system, and therefore to minimise potentially expensive failures.
[1] Ian Alexander, Dataflow Diagram Tool (for use with DOORS), 1997
[2] DOORS Reference Manual, www.telelogic.com
[3] HoTMetaL Pro 3.0 User Manual, SoftQuad Inc. 1997
[4] Ed Yourdon, Modern Structured Analysis, Prentice-Hall, 1989
[5] Ian Alexander, Example Quality System for an Imaginary Company, 1996
Revised for Web 1 September 1997