STRATEGIES FOR INFORMATION MANAGEMENT Gerald Quirchmayr 1. Introduction Managing information s ystems today comprises the areas of application development, primarily process modelin g and data modeling, as well as system introduction, training, maintenance, and the task of coping with innovation, meaning the responsibility of keeping the technological basis up to date. Developin g and running specialised systems, general information systems and open and integrate d systems leads to deal ing with application domain issues, system security, relevant legal problems and envisaging the use of the system. The scope of the system and the information provided by it will of course be largely determined b y whether it is an internal system, limited access agency system, or an open system, such as the Internet . 2. The Scope of Information Management The organisation of the project team and the realistic analysi s of the effect on the operational environment and on higher levels are prerequisites for successful system development and system introduction. The efficient organis ation of accompanying measures, especially training, (i.e., training of management, user training an d system operation and maintenance training) are also necessary c omponents. The maintainability of the system does to a large extent depend on the available documentation. Procedures for trouble shooting, error correction an d permanent adaptation, i.e. classical system maintenance must also be taken into account. Coping with innovation today means dealing with ever-shorter hardware life cycles, frequent software updates, conceptua l changes and even organisational changes. Information systems management must therefore be viewed as a pe rmanently ongoing management activity comprising design, development, implementation and maintenance of computer supported information systems. For building models of processes that can serve as basis for computer supported solutions, functions, data and organisational modules serve as basis. A classification of applications is frequently made according to th e following principles: C Disposition systems for short term, well str uctured planning support: system for deployment planning for law enforcement forces; C administrative systems: fast calculators, number crunchers; C dispo sition systems for short term, well-structured planning support: system for deployment for la w enforcement forces; C generation of executive information: prison management systems; C auditing su pport systems for dealing with long term strategies issues: strategic systems on senio r management level P u rely administratively oriented operative information systems are closely connected to the service itself and output -oriented; tactical and strategic information systems are related to bookkeeping, auditing, financia l analysis and are value-oriented. The increasing linkage of these two worlds leads to a need for integrate d information systems, called vertical integration . Functional decomposition was predominant in classical information technology, which focused on th e isolated support of services/production, logistics, distribution b ookkeeping and auditing. This resulted in functional islands. Integra ted information systems follow a process-oriented view of functions and aim at comprehensive , vertical, and horizontal integration. A transparent connection between output and value, an integrated database and process or object-oriented design are the main characteristics of this approach. Some reaso ns why traditional information system development can go wrong are based in classica l enterprise theory: a strong split in meaningless sub -tasks, strict hierarchical structures and information technology not being viewed as a potential for innovation. Traditional hierarchical structures are too inflexible; integration and control i n this approach needs an enormous size middle management. Customers, in the case of publi c a d ministration citizens, have higher expectations, are characterised by a more aggressive behaviour, and expect personalised service and high flexibility. Products and services must be customised to meet the growing demand for persona lised service. This revolution, spurred by information technology, leads to new technology, mor e flexible tools, and office automation re placing human routine work. The most important change, however, is that the e nvironment in which public administration is operating today is increasingly unstable and permanentl y changing. The consequences are a need for flexible reaction and a high adaptability of processes. 3. Essentials of System Development The essential issues system development has to deal with can be grouped as follows: C planning and preparation for computerization; C project management; C system implementation 4. Planning and Preparing for Computerisation 4.1 Responsibility for Planning and Decision-making The benefits of computerisation are achie ved more through careful and methodical planning than through the purchase of innovative and expensive computer hardware and software. For that reason, it is important that the dec ision to computerise, the formulation of policy on computerisation, the planning and management o f comp uterisation, and the coordination of computerisation with other organisational changes are all seen as th e responsibility of senior management rather than computer specialists or vendors. The leve l of management which is most appropriate will depend on the nature and scale of th e computeris ation. In a well-ordered approach, management should take an active role in computerisation for the following reasons: C To decide on the overall approach to computerisation; C To decide about the scope and nature of computerisation projects; C To assure the continued researching of the computerisation projects over a number of years in the face o f changing and competing priorities and circumstances; C To monito r overall progress and ensure timely, successful completion of projects while remaining within the scope of available resources. Often, policy makers wish to leave the responsibility for computerisation t o computer professionals. Management must take the responsibility directly, however. 4.2 Need for Planning The b enefits to be gained from computerisation are significant. In fact, those who currently usin g computer systems to support their work find it difficult or impossible to operate effectively without them. However, the bene fits are achieved only if the computerisation process is carefully planned, with the full commitment o f management. The need for a clear plan to guide the development of computerisation exists regardless of the size an d complexity of the computer systems proposed; often, significant benefits from computerisation can be achieved with relati vely modest investments: a small computer in a busy police office, another to assist with cour t administration in a busy court, and another to collate statistics at the central statistics office, for example. However, unless these individual developments are properly planned in the first instance, the individual systems may not achieve the benefits expected of them. Further, unless these are properly coordinated, the information collected at the police office may not be compatible with the court information or with the statistics system. As a result, future plans to make operational improvements by automating the transfer of information between agencies (or even between offices of the same agency ) may prove impossible or unnecessarily expensive. Furthermore, systems introduced in this way may not provide the requir ed scope for later expansion, as new and additional functions are required to be computerised. It fo llows that benefits from computerisation can be achieved only through realistic and methodica l planning an d not through the purchase of innovative or expensive computer equipment or software. In any case, the purchase of computer systems must follow the planning stages. For that reason, it is important to focus due attention on the planning and preparation for computerisation. It is also the case that the larger the system, the more careful the planning that is required. Also, the more the proposed computer systems are designed to integrate the work of more than one criminal justice agency, the more complex are the issues which require to b e incorporated in the planning stages. On the negative side, there are numerous examples to show what can go seriously wrong if th e development of computerisation is not carefully planned: C The ab sence of an overall plan to guide the development of individual computer systems often results i n pi ecemeal developments which are incompatible, information which cannot readily be transferred betwee n systems or combined with information held on other systems, and little or no scope for expansion an d development; C Inadequate analysis of the requirements for the computer systems, can lead to systems which do not address the real needs of the criminal justice agency, or which do not tackle the underlying objectives of the agency; this may also gi ve rise to systems which do not sit comfortably with the methods or constraints of working in the agency; C Inadequate attention to the need to involve users in the planning of the computer systems, can lead both t o antipathy on the part of those who are i ntended to use the system, and to systems which fail to address the real needs of users and the manner in which they work; C Inadequate analysis of the methods of working of the agency, and of the underlying objectives and options for alternative working, often leads to computer systems which perpetuate manual methods in situations wher e different methods of working, combined with new computer systems, would produce more efficient or more effective results; C Inadequat e analysis of the costs and benefits of developing and implementing the computer systems can lead to decisions to proceed with systems which are too costly in relation t o the benefits they generate; in some cases, this can result in development being abandoned befor e the system is completed, because of escalating costs and little evidence of benefits being generated; C Inadequate analysis of the costs of running and maintaining the computer systems, can lead to systems which are too costly to operate and which can as a result fall into disuse; C Inadequate attention to the training needs of staff and users at all levels can lead to inefficient or ineffective use of the system and a failure to meet its design objectives; C Inadequate attention to the clerical and administr ative procedures associated with running the system, can lead to incomplete, inaccurate or out-of-date information, which in extre me cases can lead to users losing confidence in the usefulness of the system, and the system falling into disuse; C Inadequate at tention to the security and confidentiality of the information, can in extreme cases lead t o compromises of the justice system and to infringements of privacy; C Inadequ ate staff preparation for the implementation of the computer system and its associated changes i n procedures can lead to staff antipathy, and in extreme cases, refusal to use the system; C Attempting to develop systems which are too large and complicated to be managed properly, can lead to slipped deadlines, loss of development staff morale and loss of interest on the part of users. Properly appl ied, planning of computerisation will mean that any computer systems that are introduced wi ll generate real benefits, at a cost which can be justified, that they will have scope for future expansion an d integration, and that the systems will work according to expectation. 4.3 Planning for Computerisation Planning for computerisation is similar to that involved in building a new town or estate; work cannot begin on building individual parts until the overall plan has been p repared and agreed. The overall plan determines how big the overall development will be, where the infrast ructural components (which, in the town analogy, would be roads, drainage etc., but in compute r terms would be the computer processors, communications links, etc.) will be placed and the number and type of individual buildings to be built. Th e plan usually also sets a time scale, which shows construction plans and a time line. In computing terms, the overall plan is called a strategy ; it examines the objectives of the criminal justice system or agency and identifies those aspects of the work which could usefully be c omputerised. A strategy also sets out the infrastructure necessary to achieve the proposed computerisation - the rel ative sizes of computer systems required, the communications facilities needed, the number of user s requiring access and the relative volumes of work to be undertaken by each. Plan ning for computerisation consists of a large number of individual stages or components, as in th e town building analogy described above. As with buildi ng a new development, the first problem is to find a suitable sit e, and develop an overall plan for the scale and nature of the development--whether to build a residentia l housing area or an indu strial park, for example. In technical terms, this stage is known as defining the strategy-- establis hing a plan which sets out what objectives are to be met, the extent to which computerisation will b e applied, and the broad time scale in which the development will take place. Once the strategy is defined, th e remainder o f the planning process focuses mainly on building and implementing the component parts of th e strategy - buying the right computer hardware, developing or buying appropriate computer software, training the users how to use the system, etc. At fi rst sight, the list of tasks involved in planning a computer system can be daunting. In reality, b y breaking down the overall task into specific components , it can be seen that each individual part is straightforward and manageable. It follows that since the individual stages are manageable, so is the overall task. As a guide to the components involved in planning for comp uterisation, one can identify the following typical stages as a guide to what is normally included: C Setting the scope and direction of computerisation; C Designing and implementing each individual system; C Ensuring the security, integrity and satisfactory operation of the computerisation project. 4.3.1 Stages Associated with Setting the Scope and Direction of Computerisation I. Deciding responsibility for managing the strategy study and for setting the policy on the scale and scope o f computerisation; I. Und ertaking an analysis of the needs of the organisation(s) and preparing a detailed overall plan fo r computerisation which tackle the needs; I. Within the overall plan, deciding what to computerise, and how to tackle each project; I. Deciding priorities between competing systems for development or implementation; 4.3.2 Within the overall plan stages involved in designing and implementing each individual system I. Setting up a project management structure, to take responsibili ty for ensuring that the proposed computerisation project is completed on time, within b udget, and achieves the objectives set for it, and to provide a mechanism for users to influence and guide the development of the computerisation; I. Involving the users in developing the plans for computerisation; I. Confirming the feasibility of the project; I. Analysing the requirements, to find out precisely what the computer system has to do, what information i t requires to hold, and what screen and report layouts are required; I. Setting data standards; I. Breaking down the project into manageable stages, and analysing for each stage the time required to complete it and the resources needed for it; I. Deciding how best to implement the proposed system - whether to utilise an existing system from anothe r agency, for example, or to develop a new system from scratch; I. Deciding what computer hardware (if any) needs to purchased, and planning and implementing th e procurement procedures as necessary; I. Develop ing the system, where necessary, or modifying an existing system to meet the specific needs of th e organisation; I. Piloting the system as necessary to check that it works satisfactorily and to enable users to familiaris e themselves with the system and to refine their requirements; I. Testing the system, both to ensure that it works correctly under all test conditions and that the users satisf y themselves that it operates correctly under normal operational conditions; I. Implementing the system, by installing it on the computer hardware, planning the changeover from manual to automated working, and ensuring that the automated system works reliably enough to replace the manual methods; I. Training the users in the use of the system; I. Preparing and issuing documentation to assist users in the use of the system, as well as to provide technical guidance to the computer staff who will maintain and support the system, and training materials to the staff who will train users in its use; I. Planni ng and implementing the transfer of data from existing manual (or automated) records to the ne w system; I. Evaluating the extent to which the completed system meets its design objectives, and subsequently monitoring its continued achievement of them. 4.3.3 Stages Involved in Ensuring the Secur ity, Integrity and Satisfactory Operation of the Computerisation Project I. Preparing procedures for checking in formation quality, and for ensuring that quality standards are held within pre-defined limits; I. Planning for the physical security of the computer system and the information held on it; I. Planning for the eventuality of major disasters affecting the computer system (i.e., fire, flood or maliciou s action); I. Planning and preparing procedures to ensure that all requirements of data protection are met; I. Planning the on-going support and development of the system; I. Setting and maintaining standards to define the layout and interpretation of all items of information held in the computer system. The exact content of the components in the above list may change slightly from one situation to another but wi ll rarely deviate markedly from the overall pattern. Further, it should be noted that many of the task s involved in planning and implementing computer systems run concurrently and that the list as presented does not therefore represent a strict chronological sequence. For many of these stages, there are purpose-designed formal methodologies to assist with their completion; many of which are the product of commercial companies and can be relatively expensive, due to user-fees. There are however, several public-domain methodologies which are available fo r free use: In some cases, the development of a number of public-domain methodologies has been funded by national government to encourage the use o f professional approaches to computer development in the public and private sectors. The methodologies developed as a result of such initiatives are of high quality, and because of the ir widespread and increasing use, manufacturers and sy stems designers in the computer industry become well acquainted with their application, and are working to univers alize standards and definitions. Furthermore, there are many automated aids to assist with their use : computer based systems which handle much of the administration and monitoring of computer syste m development, as well as of the analysis and design of computer systems. It is not the purpose of this section t o provide detailed guidance on how to tackle each of the stages listed above. Rather, a brief descr iption of what is involved in each stage is given in order to provide a broad indication of t he resources required and of the importance of each stage to the overall computerisation initiative. In som e cases, alterna tive ways of tackling each stage are identified, with some guidance on how to decide between these options in practice. 5. Detailed Implementation of Computerisation 5.1 Setting up a Project Management Structure Each computerisation project identified in the computer isation strategy requires the formation of a project management group to take re sponsibility for its management and completion. The membership of this group will vary, depending on the importance and scale of the computerisation project - the most senior managers of th e org anisation for the most significant projects, and local or junior managers for small-scale or less significan t projects. In each case, however, the manageme nt group comprises managers, not technicians or computer experts; their remit is to make decisions abou t the requirements for the project, commission the development work, ensure the work proceeds according to plan, and to ensure that the final system meets the requirements which were set for it. In this context, the resp onsibilities of the project management group are the same as if the project had been to plan and implemen t a new organisational structure, or to plan a move of the agency to new offices; the project is essentially one whic h affects the operation of the agency, and the fact that it involves computers is a secondary issue. It should be noted that the project management group does not develop the computer system itself, nor is i t required to know anything about how computers work or how they can be programmed. For these technical aspects of the project, the pro ject management group will appoint a project leader, to take technical responsibility for designing and implemen ting the proposed system to meet the requirements of the project management group. The project leader will normally be allocated staff and other resources, for the management of which he will have delegated authority. The project leader will report to the project management board - to account for his use o f resources, and to provide reports to show the progress made on the project. To be eff ective, the project management group involved in managing projects should be small - usually no more than six people and preferably three or four. It should be chaired by a senior manager either from the user department or agency, or from another part of the organisation which is not directly involved in the project itself. The argumen t for the latter option is that the chairman should be neutral, but should have a clear grasp of th e overall business objectives of the criminal justice system (or of the agency, if it is an agency system), and of the overall computerisation strategy. If the chairman is drawn from the user department directly, there is some risk that he or she wil l be less impartial between the views of the users’ representative on the project group and those of the technical representative. In addition to the project management group and the technical team of staff engaged in the project work itself, there may also be one or more ad-hoc quality revi ew teams. These teams, often consisting of just one person, are required because it is an important feature of project management methods that all stages of a project ar e independently reviewed by appropriate speciali sts to ensure consistent quality standards. The quality review teams must therefore be drawn from other staff, not engaged in the project team, or may sometimes be consultant staff from external sources. They may be drawn, for example, from a team of users to check the quality of the screen layouts and r eport formats, or an independent communications adviser to review the proposals for th e communications aspects of the system. Formal met hodologies exist for managing computer projects, and some of these are public-domai n products which can be used without payment of royalties. These methodolog ies are documented in numerous books, and consultancy and training services in their use are readily available. Too often, however, project management is seen only in very limited terms, such as the preparation of critical path di agrams to show how the different stages of a project are inter-related and need to be scheduled, or charts to show the allocation of resources throughout each stage of a project. Project managers can fall into the trap of thinking that the purchase and use of project management software (of which there are many, largel y inex pensive, examples on the market) will suffice. Although these are important tools in the process of projec t management, in the same way as a hammer is an important to ol in house building, it is important to recognise that they do not themselves constitute project management any more than a h ammer can be regarded as a house builder. Project management is what the senior managers on the Project Management Group do to ensure that the project is completed on time, within b udget, and that the resulting system does what it is required to do. A project management methodology is a formal set of procedures which the project management group can (and should) use to assist with the task of project management. It should include quali ty control functions to ensure that at all stages, the pr oducts generated by the project meet the appropriate standards as defined by the users' requirements, th e business ob jectives of the organisation and the professional and technical standards defined for the technica l development staff. A project ma nagement methodology is relatively complex, though it is essentially no more than a set of measures to ensure that the project is completed sati sfactorily. The precise mix of tools and procedures varies from one project management methodology to another. Annex G provides an outline of the steps involved in a typical system. It should be recognised that no project management methodology can satisfactorily be taken directly out of a textbook or from a set of instructions. Effort does need to be committed to training project managers, as well as the staff on the project who will be managed by the methodology. 5.2 Involving Staff in the Development Any p roject to introduce computerisation to an organisation, regardless of the scale of the undertaking, has a profound effect on the st aff of the organisation and on the way in which the organisation functions. Equally important, if the computerisation is to have a beneficial effect, the value of involving staff in the decision-making process should be recognised. Staf f will be affected by the changes to the organisation which the computerisation will generate, and they are able to contribute to decisions about the design and use of the proposed compute r systems. Overlooki ng these elements can have serious repercussions, and could jeopardise the success of th e computerisati on project itself. Failure to keep staff abreast of what is happening in the organisation can result in sta ff apprehension, fear about job security, confusion as to the nature of the work, and eventual resistance to the implementation of the new system. Staff members are often the most fruitful source of knowledge of how the organisation functions on a daily level, and a failure to recognise the potential for staff to develop an enthusiasm to embrace new, more efficient systems in the workplace. Planners of computerisation should therefore: C Keep staff informed of what is happening, prepare t hem for the changes which computerisation will bring, and train the staff to use the computer systems to best effect; C Involve the staf f to make best use of their knowledge and skills, to assist with the design and implementation of the computer systems, and to develop the operational procedures within which the computers will be used. 5.3 Feasibility of Projects The first stage of any project is to determine whether or not the costs of the proposed computer system can be justified, and to identify and evaluate the options for comp leting it. This takes the form of a feasibility study, the outcome of which is a detailed report setting out the overall requirements of the system, the options available for meeting th ese requirements, the costs of implementing each option, and the anticipated benefits arising from it. The purpose of the feasibility study is to answer three basic questions: I. Can a computer system meet the needs as identified? II. If so, how should the computer system be designed and configured? III. Do the benefits arising from the implementation of the system outweigh the costs? At the end of a feasibility study, there should be a clear indication as to whether the project should proceed or not, and the approximate costs of implementing the sy stem should be known. This study provides the broad cost estimates for budgetary purposes, particularly in criminal justice agenc ies where budgets have to be planned at least one year in advance, and often more than three years. Feasibility studies should not be lengthy, nor should they require extensive resources, considering that the project will already be part of the strategy defi nition. The actual resources required will depend on the size and complexi ty of the proposed system - not only because a complex system will require closer examination in order to identify the extent of the complexity, but also because it is clearly worth spending more time and resources on ensuring the correct decision with systems which are likely to be expensive. As a general guideline, the cost of a feasibility study should not exceed 5-10% of the total cost of the proposed system for which the study i s undertaken. In many governmental organisations, budget a uthorities may require the production of a feasibility study showin g a positive rate of return on investment before funding for the system is approved. If it appears tha t implementation costs outweigh the benefit s, the system design should be modified and reanalysed. It is important to note that the benefits of computer systems, particularly of those in criminal justice, cannot always be measured in monetary terms. The benefits of criminal history systems, for example, arise partly through savings in staff time (by making information available more rapi dly), partly through improvements in productivity (by enabling higher perc entage clear-up rates on criminal investigations), but also by the system’s effect on public attitudes to crime and law enforce ment (many citizens would place high value on removing criminals from the street). In suc h cases, the quantifiable benefits should be identified and calculated, and the remaining subjective benefits should then be identified and compared with the balance of the system costs; a decision to proceed with the system can then be made. In the particular context of criminal justice, it should als o be kept in mind that because of the independent funding of different crimin al justice agencies, it may not always be possible to transfer savings between agencies. Th us it may not be possible to justify a computer system for the courts on the basis of savings made by the la w enforcement agency, unless a broad view is taken of the funding of the overall criminal justice system. 5.4 Defining the Project Stages Every proj ect should be broken down into a number of manageable stages. Because there are n o milestones along th e way by which to judge the progress being made, projects can be difficult to manage without them. The size and defini tion of each stage will depend on the project itself, though as a general rule, each stage should: I. Be of less than six-months duration; I. Have well -defined resources allocated to it (covering specialist technical resources, resources provided by the user, and other resources, such as trainers, which may be necessary); I. Have clearly defined objectives and specific end-produc ts (e.g. completed programs, training manuals, numbers of people trained); I. Have specific roles for each participant in the stage - (e.g . that the office manager will prepare the user manuals for the office staff); I. Have a cle arly nominated stage manager for each stage, who is given authority by the management group for the project to use the resources allocated to the stage to complete the work defined within it; I. Have clearly defined rules which define the limits of the stage manager's authority. For example, if at any point it becomes clear that the cost of the stage will be more than 5% above the agreed level, the stage manager must report back to the management group; I. Have meetings at designated stages in development. An initial project plan should show the overall co sts, timescale and end products expected from the entire project, broken down into individual stages. Each stage can then be managed individually, and any over- or under- use of resources in any stage can be examined in relation to its impact on the overall project. 5.5 Analysing Requirements If the decision is made to proceed with the project, the first stage is to analyse the requirements in detail and to document these clearly. There are three purposes in this: I. To ensu re that the requirements for the system are fully understood by the technical staff undertaking th e analysis and the user staff alike, and that any inconsistencies or deficiencies in the definitions of requirements are identified and clarified; I. To provide clear feedback to the users who have requested the system, to ensure that they fully understand the requirements that have been stated and fully agree with the analysts' interpretation of them; I. To enable users to contribute to the design of the computer system. There are numerous methodologies fo r analysing and documenting the requirements, each of which uses one or more analysis or diagraming techniques. It is important, however, to ensure that the methodology in use incorporates at least two , and preferably three separate techniques. The reason for this is best seen by drawing an analo gy with the plans for a house: An architect will normally prepare three sets of drawings for a house - plan, side eleva tion and front elevation. Together, these show the detail of what the architect has interpreted as hi s client's requirements. They enable a three-dimensional model of the house to be built. The three diagrams also assist by ident ifying and eliminating any inconsistencies - for example, that the floor levels are correct or tha t stairw ays are in the correct place, since the three sets of diagrams must match in every detail. So it is in th e analysis of computer systems. Different diagram techniques give different views of the system, but no matter which techniques are used, they must all be consistent with each other. If they are not, there are errors in the underlying analysis or in the interpretation of requirements. If only one or two methods are used, inconsistencies cannot be readily identified, and this can lead to expensive mistakes later on, when the system is being constructed. A publi c domain systems analysis methodology embodies three separate diagramming techniques: one to show the manner in which different items of information are related to each other (for example, that one item of information, the case record, may refer to more than one defendant). Second, to show the flow of information between users, and third, to show the events which surround each pie ce of information in the system. The diagrams produced by these techniques serve much the same purpose as architectural plans - they are relatively simple to follow, and because they use strict conventions for representing different information, they leave little scope for ambiguity or misunderstanding. The diagrams do, however, take a considerable amount of work to prepare , particularly if they are subject to frequent alterations. Computer-aided systems are available to assist with implementing these m ethods, and particularly to assist with checking the internal consis tency of the information models and producing the diagrams. Numerous courses and computer-based training packages are also available. The proce ss of analysing the requirements for a computer system will almost invariably require a considerable de gree of interaction with the staff of the organisation. The purpose of the analysis is to understand and document, for those processes which the computer system will tackle: I. What information is involved in the proce sses, where it comes from, how it is stored, who uses it, and for what purposes; I. How different pieces of information are inter-related; I. What actions are taken as a result of the information being available. The techniques used by computer analysts to determine these details are based largely on interviewing the sta ff most directly involved in the current processes which the computer system is to replace, as well as with the senior managers who m ay wish to recommend changes to the current procedures and methods of working. It is therefore important that during the analysis stage the computer analysts meet with staff and senior managers to accomplish the following: I. Briefing of analysts by senior managers, to specify the scope and boundaries of the proposed system; I. Interviews of relevant staff by the computer analysts; I. Diagrams showing the structure of the information currently in use and proposed for the computer syste m (sometimes called data navigation diagrams), how the information relates to actions and procedures in th e offi ce (sometimes called data flow diagrams), and how the information is used or affected (sometimes called entity life history diagrams); I. R eview meetings with the staff and senior managers, to check out the detail of the diagrams produced by the analyst. The end result of the design phase is a clear and unambiguous specification of what the computer system is re quired to do, how, in logical terms, it is required to do it, the information which the system will be required to handle, and the manner in which the different information items are interlinked. 5.6 Data Standards In mos t computer systems, it is beneficial to establish and maintain standards for all the items o f information that are held in the system - what each item of information means, for example, and the format i n whi ch particular types of information are to be stored. In criminal justice, because of the complexity of th e organisational structure, the tra ditional differences in definitions of terms between agencies, and the considerable volumes of inf ormation passing between agencies, it is vital to devote significant effort to establishing an d maintaining data standards for the whole computerisation system. This means that each component of the information to be held in the computer system should be carefully tabulated, with details of its definition recorded. To take a simple example, most criminal justice computer systems will recor d the names of individuals (whether these are persons arrested, suspects, accused, etc.). Befor e embarking on th e design of a computer system, it is essential to establish a common basis for recording suc h names, and for interpreting them. The task of defining and recording the definitions of each data element can be facilitated by the use of auto mated data dictionaries which are designed to assist with the task of setting data standards, and for keeping track o f what each data item in a system means and how it is used. Many of the newer tools for designing an d building computer systems embody a data dictionary, which is necessary for the design and development of the system, and this can serve a more general role of assisting with the task of data administration. A databa se administrator should be nominated to take overall responsibility for maintaining the dat a dictionary as well as for maintaining the database itself. 5.7 System Implementation Once a computer program has been develo ped and tested, and the computer equipment to run it has been purchased, implementation of the system involves both installing the computer together with its communications lines and terminals, installing the computer program on the machine, and changing over from manual working to using the computer system. Although it perhaps sounds straightforward, and in some systems can be, careful planning is r equired if the process is to go smoothly. Considerable discussion with the potential users will b e necessary to ensure that all staff concerned with the introduction of the computer system are aware of the proposed tim etable for implementation, and what will be involved in the changeover. It is advisable to prepare a detailed timetable, showi ng what is expected to happen when, both as a means of keeping staff informed, and as a means of monitoring the implementation itself. An impo rtant component of the implementation of any new computer system is parallel running - i n which the computer system is run in p arallel to the existing manual (or computerised) methods, to ensure that the new system works correctly, that the staff are able to operate it satisfactorily, and that the information produced by the sys tem is correct and accurate. In the event of any difficulties being experienced with the new system, the manual system, running in para llel, enables the organisation to function as normal. Parallel running does require extra staffing resources - since much of the work of the organisation required to be done twice - and as a result, should be kept to a minimum, con sistent with adequately ensuring that the new system works sufficiently reliably for the organisation to rely on it. Parallel running should continue for at least a month (to ensure that any end-of- month procedures are completed satisfactorily), and for similar reaso ns may best be scheduled to include an end-of- year as well. It is during the implementation of computer systems that t he first effects of the system on the organisation start to become apparent. Norma lly, these effects should be planned for, and steps taken to prepare staff for them, and normally, too, the effects are positive in their nature and are part of the reason for introducing computerisation in the first place. As a guide to the types of positive effects expected from computerisation in criminal justice. 5.8 Training Another significant component of implementing a new system is the pr ovision of training to the users who will use it. Training is required at a number of levels: I. For the users of the system, who wi ll use the computer keyboards to enter or retrieve information, or to initiate actions on the computer; I. For the st aff who may not directly operate the computer system, but who will be required to work with th e information produced by the computer, or to prepare information for it (the affected staff); I. For line managers, whose staff may be required to operate the computer system or to work with it; I. For senior managers responsible for the sections of the organisation in which the computerisation will have an impact; I. For the specialist s taff who are responsible for managing the computer system itself (the computer operators); I. For an y additional specialist staff who may be responsible for supporting the computer programs whic h constitute the system. The form of training required for each is different; senior managers, for example, will require a broad overview of the functions and purpose of the computer system and the impact it will have on the sections of the organisation for which they are responsible. For the staff who will use t he computer on a day-to-day basis, however, cons iderably more detailed training is required, to ensure that the staff know how to use the computer system in all releva nt aspects. Most detailed of all, the person in charge of the day-to-day running of the computer system, its security and continued operation (often referred to as the system manager) will require a detailed knowledge of both the computer hardware and its operating systems, together with the computer programs which constitute the system. Trainin g can be provided in a number of ways. Tutor-based (traditional instructor-student) trainin g courses are often t he easiest to arrange, though these can be expensive and difficult to provide, particularly if the staff requiring training are widely scattered over a large area. It can also be difficult to provide training courses to large numbers of staff. 5.9 Documentation Documentation refers to a ny written or recorded instructions or on-line help facilities on how to use and maintain the computer system. The instructions are intended to serve a number of purposes: I. As an introduction to the system for new staff or those who have not previously used it (though specific training should be provided to all such staff); I. For re ference by all staff who need to use the system, to check on the detail of how to use the system, th e constraints imposed on it, etc. The preparation of documentation for the system is an esse ntial part of the project, since without adequate documentation, a syst em may not be used to its full potential and the support and maintenance of the system will prove difficult. Documentation is needed for five separate groups of people, each of whose requirements differ: I. Day-to-day users will require an easy reference guide to the system to find out how to cope with th e circumstances which may arise in the normal use of the system; such documentation has to address the needs o f the casual user who may not be very familiar with the system, and of the experienced user who knows the system well but requires guidance on how to deal with an unusual circumstance; I. The m anager of the system (usually called the system administrator ) should know details of the computer' s operatio nal environment in which the system requires to work, how to deal with system administration tasks (such as taking backup copies of the data, purging old data, etc.), and how to deal with system faults; I. Technical staff who wi ll be required to support and maintain the system itself; if the computer programs were prepared in-house, or were modified from systems supplied externally, these staff will require detaile d descriptions of the structure of the computer prog rams (using the same diagrams as served to define the system at the design stage), together with the source code of the program (the program instructions which specify what the computer must do), and any test routines which have been prepared; I. The system operators; I. Senior managers of the agency in which the system operates; they will require broad information about th e system's obj ectives and purpose, its resource requirements, and broad measures of performance which can be used to monitor the system. The purpose of this documentation is to e nsure that senior managers are fully aware of the resource re quirements of the system, and can take an overall management responsibility for the system as an integral part of their organisation; I. For the trainers who will provide training in the use of the system; they will require a detailed training pack, with worked examples of the use of the system, and sufficient detail of the technical aspects of the system to understand how it works and what it does. Documentation should preferably be prepared by members of staff who use the system, or by specialist technical aut hors (though these are expensive), rather than by the technical staff who designed and built th e sys tem. Users will tend to write documentation in terms that their fellow colleagues will understand, and do not indulge themselves in unnecessary technical descriptions. It is useful to set up an informal editorial panel to vet the quality of draft documentation before issue, and it is essential to establish a mechanism for ensuring tha t documentation is kept up to date in line with amendments to the system. 5.10 Data Conversion Another m ajor part of system implementation is the transfer of information from manual records to the computer system. A criminal history system, for example, will rarely be of practical value unless at least some of the existing re cords (perhaps held on a card index) are transferred to the computer system. For most types o f record, the on ly feasible way of transferring the information will be to key it in on a keyboard, because th e information itself may re quire some degree of interpretation, may require reference to other files to correct errors or fill in omi ssions, or may not be held in a format which is consistent for all the records. If, however, th e information is already held in a computer system , or if the information is held in typed documents which are well- structured, it may be possible to use computer-based methods to assist with the transfer. Data held on computer syste ms can usually be converted to the format suitable for another system, and typed documents can sometimes be read and interpreted by document scanners (though they can be prone to errors, depending on the quality of the source documents). Data conversion can be a lengthy and resource-intensive process; in some cases it has been known for data take-on for criminal justice systems to l ast a year, before the system could be regarded as fully functional. In other cases, it can be completed in d ays or weeks. Care should be taken in planning data take-on to ensure that the task is completed relatively quickly - a year is us ually too long. While the computer system lacks the necessary data for it to oper ate effectively, users of the system will see relatively little benefit, and may even become accustomed to the inform ation in the system being incomplete or out of date, and as a result may lose faith in the system. If the data is to be entered by hand, thought can be giv en to using temporary clerical staff to assist, though the feasibility of this will depend on the quality of the source information, and the extent that it requires interpretation b y experienced staff members. The task can sometimes be broken down by prioritising information - for example , loading the most important information first. Three ways of tackling the conversio n of information include selective conversion, total conversion, and phased conversion. For s ome applications it may be sufficient to convert only some of the available information, such as the most current records. This approach is beneficial in that the costs of conversion are limited and the computer system itself is not burdened with old data which may be of relatively little value. Whether this is feasible will depend on the extent to which the old data is still required - it is unlikely to be an appropriate approach for a criminal record system, for example, but may be appropriate for a probation client index. In cases where most, of the information is to be converted, it can be done at once or phased in over a period of time. One approach appropria te to criminal history systems, for example, is to put new records onto the co mputer system as they arise, and to transfer old records to the computer whenever the old records have to b e accessed for any reason. This approach ensure s that the records which are being used are converted quickly, while the unused are left for last. Other phased approaches are possible, of course - for example, selecting case records alphabetically by surname, and working methodically through the alphabet. Howeve r the conversion is tackled, it is preferable to operate to a strict sequence, to avoid uncertainties about where the information lies - whether on the old manual system or the computer system. Data conversion can also be regarded as a useful training stage for the staff who will ultimately use the system. It provides the opportunity for staff to enter information of the same type as in normal use, but unde r closely control led conditions, and in circumstances in which it is relatively easy to include elements of forma l training in the use o f the system. It can provide a useful practical training in the system. Data conversion can be good exp erience, particularly if staff from outside offices assist with the data entry. This will help to gai n consistent standards between staff of diff erent offices, ensuring that the quality and accuracy of the converted data are high. 5.11 Maintaining Information Quality Control The quality of any computer system is only as good as the quality of the information in it. Unfortunately, it h as been a feature of criminal justice computer systems that the information has often been inaccurate , incomplete or out-of-date. Given the gravity of the decisions which can be based on information held in suc h computer systems, the quality of the information is of paramount importance. It is therefore im portant to establish adequate procedures to ensure that information is entered promptly and accurately, and that outdated information is purged from the system. These procedures will be primarily of a clerical nature - clear office procedures which must be followed. In deed, the quality of some operational computer systems has been greatly enhanced by the simple expedient of producing and circulating an office procedure s manual. The procedures will normally be clerical in nature, but may require some aspects to be programmed into the system itself; for example, the computer system may be programmed to produce checklists of the information which h as been keyed into it. This can be useful, for example, when entering batches of arrest records, since the computer can generate a checklist of arrest notifications which can then be checked against the source documents to ensure that none have been omitted. It is helpfu l to give specific quality control duties to staff in the organisation - for example, to the office manager to take samples of records on a regular basis and to check the computer records against the manual files. Regular audit checks should be carried out to monitor and record the accu racy of the information held in the system - the number of incorrect records, the time delay between information coming into the organisation and it being recorded on computer, etc. A major pa rt of quality control, however, lies in the design of the forms which are used to captur e information for entry to the computer. The use of simple mechanisms , such as bar-coding, pre-printing of reference numbers, ch eck-digits on reference numbers (to ensure that numbers are keyed in accurately), carbon-copy o f reference numbers on multi-part forms, for dealing with multiple stages of a process (for example, from arres t through to court appearance and conviction) all help to reduce the likelihood of errors, and it is well worth th e effort to examine the mechanisms involved in capturing and transferring data to the computer. Another important factor is the extent to which the computer system itself checks the data which is keyed into it. Most criminal justice programs are designed to check the information very carefully, because of th e potential con sequences of errors. These checks can be programmed into the systems themselves, so that th e computer can reject information which is obviously incorrect - for example, a court case management system could detect that sentencing a 35-year old to a young offenders institution must be a faulty sentencing record and reject it. The checks built into computer programs to validate the informat ion being keyed in are called validation checks, or edits. Care should be taken when carrying out system audits, however, with measures of accuracy in relation to infor mation systems. A 1% error rate can appear very satisfactory, but it is meaningless without a referenc e point. A 1% error rate applied to records can indeed be satisfactory, if it means that out of every 100 people on whom a criminal history check is run, only 1 record contains any error. On the other hand, if it means that 1 in every 100 items of information is incorrect, this may mean the informat ion can not be used for its required purpose. If a criminal histor y record on an individual contains 100 items of information, then a 1% error rate implies that nearly all the records in the system will have at least one error in them. Computeris ation planning should include detailed consideration of the steps necessary not only t o maintain acceptable standards of data quality but also to monitor the accuracy of the information in the system on a regular basis. Regular audit checks, to monitor the accuracy of the information should be carried out - usually based on a sample of the records, to keep the numbers of records for checking to an acceptable level - and an y instances of error rates climbing higher than agreed maxi mum levels should be rigorously followed up to trace and rectify the cause. 5.12 Security Planning Computer systems, if they are effective, are vital to the operation of an organisation they. It follows that the computer equipment, its associated programs, and the information held on it, are of considerable value to th e agency - in the sense that in the event of a total loss of the c omputer system and information, and without any steps being taken to reduce the effects of these losses, the organisation might well cease to operate for weeks or months. The security of computer systems is ther efore of considerable importance, both to ensure that the systems are protected from risk as far as possible, and to ensure that in the event of any failure of the system, the system can be restored to full operation as quickly as possible. The risk of system failure can be reduced by the following means: I. Keeping the system fully maintained, on a regular basis; I. Preventing physical access to the computer system by unauthorised staff who may maliciously, or otherwise, switch off or damage the computer system; I. Designing redundancy into the computer system - for example, by using two smaller computers, connecte d together, instead of a single larger com puter; this enables the system to continue to operate, albeit at a reduced power, in the event of the failure of one computer; I. Introducing physical protection measures, designed to tackle incidents before they seriously affect the computer system - automatic fire alarm systems, automatic halon gas extinguishers, uninterrupted power supplies for the main computer processors, are all examples; I. Ensuri ng that regular backup copies of all the data and programs held on the computer system so that, in the event of a failure for any reason, the system can be re-loaded from the backup copies; it also helps if there is an autom atic roll-back mechanism, which effectively means that all transactions on the computer system are recorded twice - once on the mai n computer program, and again on a separate disk or tape; in the event of the failure of a computer disk, the system can then be restored up to the point at which the failure occurred. 5.13 Support and Maintenance of the System A computer system, like a house, requires maintenance once it has bee n implemented. This applies to both the compute r hardware and the programs which run on it. The need for maintenance is different in each case , however. Computer hardware requires maintenance to function and is usually provided in the form of a maintenance contract by the computer sup plier, wherein the supplier agrees to respond to equipment faults within a specified time period, and to guarantee specified availability standards for the equipment (for example, that the equipment will be fully operational for at least 98% of the working hours in any three-month period). Without such an agreement, individual computer faults will require to be repaired on a time and materials basis, and the response to s uch calls is almost invariably worse than those on a specific contract. In circumstances where maintenanc e cannot reasonably be provided quickly (for example, at sites remote from repair engineers) it may be necessary to install a backup computer, to keep the system operating in t he event of a failure. The availability of backup support can be a significant issue in selecting a computer system, and the requirement for specific standards of support (for exampl e, the times taken to respond to failures) should be written in to the Operational Requirement at the time of purchasing the computer equipment or programs. Computer programs require to be maintained and supported for different reasons; first, compute r programs do not degrade like computer equipment. If the program wor ks today, then under the same circumstances it will also work at any time in the future. But c omputer programs almost invariably contain faults, which may not beco me apparent until particular circumstances arise. When these faults do make themselves known, the results can be a to tal system failure. Support must therefore be provided to ensure that any such faults are noted an d corrected as rapidly as possible. Just as important, the users' views of what t he program should do can change as time passes and with the gaining of experien ce of the system. More significantly, legislation can change, requiring significant changes to be made to the compu ter programs used by the criminal justice agencies. Support must be provided to respond to these changin g requirements by agreeing and implementing revisions and extensions to the computer programs. Further, th e computer programs require support for the benefit of the user; if the user encounter s difficulty, support is required to provide assistance. This final type of support is often provided in the form of a central inquiry point which users can contact for advice, called a help desk. For all these forms of program maintenance and support, there requires to be a continuing technica l resource avail able for the programs; indeed, it is a feature of computerisation plans that at the start of a compute risation strategy, almost all the project staff are allocated to system development, while towards the end of the strategy, the majority of staff are allocated to supporting the parts of the system which have bee n implemented. 5.14 Data Administration Data administration i s a task which continues throughout the life of a complex system. The task itself is not complex, but it is of vital importance and does require a careful and methodical approach. Data administration consists of maintaining up to date reco rds of the data content of the computer system, together with the m eanings and interpretations of each data item. The starting point for the data administrator is the design documentation prepared for the system itself - the specifications of all the data items, for example, and their inter- relationships. From that point on, the task of the data administrator is to act as a coordinator between the different criminal justice agencies which may require to use the system, to advise on the meaning an d interpretation of the da ta, and more importantly, to impose constraints on the further design and enhancement of the system by ensuring that the data standards are adhered to, and that any changes in the data content of th e system are properly documented and circulated to users. The person appointed to the task of data administrator (which is not usually a full-time job) is often a researcher or information officer, rather than a computer specialist, since the role is more oriented towards th e meaning and use of the information held in the co mputer system than towards the technicalities of how it is stored or manipulated. The data administrator may also be given t he responsibility of ensuring that data quality standards are monitored and enforce. 5.15 System Evaluation One of the very first steps in planning a computer system is to set out the requirements. One of the final steps is to check the ex tent to which the requirements have been met, and to examine critically any discrepancies bet ween the planned and actual functioning of the system. Admittedly, system evaluation is rarely done, though there is wid espread agreement in its value. As a result, although many millions of dollars were spent on th e co mputerisation of criminal justice in the 1970s, very little was learned from it because of the lack of forma l evaluation in the industry. System ev aluation should be undertaken by staff who have been unconnected with any aspect of th e system's planning or developmen t. Often, staff in the Management Services Department, if there is one, are used, since they are independent of both the d evelopers of the system and the users. Evaluation should also be based on objective criteria, drawn from the original specification of requirements for the system. The reasons for a system fa iling to function to the required standards or not to meet its design objectives are not always connected with the s ystem itself. Often human error will prevent the full benefits being achieved - staff who do not adapt their methods of working, for example. It is one of the goals of the system evaluation to identify such causes so that remedial action can be taken. A system evaluation need not be a leng thy or expensive exercise, but will focus on the original objectives for the computer system and w ill involve measurement as is necessary to ascertain whether these goals have been achieved. It is never sufficient to ask users their views of the system; users may often be perfectly satisfied with a system that achieves no benefit. Rather, an evaluation will usually involve specific measurements - of the time taken to perform certain tasks with the computer system, compared to the time taken previously under a manual system, for example. It may also involve statistics produced by the computer itself - the output of cases, fo r example, or the utilisation percentage of court room facilities. 6. Conclusion: A New Paradigm Enterprise (re)engineering and business engineering are the new paradig ms being followed by consultants, res ulting in organisation by business processes instead of hierarchical structures. Essential components o f reengineering include permanent re- and forward-engineering as well as bu siness improvement focused on business proces ses. Experience shows that without a good formal model 50-60% of reengineering projects go awry . Organisational know-how has to be provided by the domain expert, while methods of business engineering ar e within the responsibility of information system eng ineers. Tools should be operated mainly by information system engineer s and computer scientists. Organisational know-how in combination with technological knowledg e becomes decisive. As far as the methodological aspect is concerned, object oriented modeling and process modeling, i n combination with proven software and data engineering concepts should ideally lead to a data model of the whole organisat ion and a comprehensive organisational and process model. Tools can be grouped in the followin g categories: I. T ools for business process engineering: extended ent ity-relationship modeling, object oriented modeling and process modeling; I. Integrated tools for supporting the whole modeling phase: process weaver, objectory; I. I nformation syst em implementation tools: computer assisted software engineering tools, management information systems, executive information systems and decision support systems.