{\rtf1\ansi \deff4\deflang1033{\fonttbl{\f4\froman\fcharset0\fprq2 Times New Roman;}{\f5\fswiss\fcharset0\fprq2 Arial;}}{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255;\red0\green255\blue0; \red255\green0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red128\green128\blue128; \red192\green192\blue192;}{\stylesheet{\widctlpar \f4\lang2057 \snext0 Normal;}{\s1\sb240\sa60\keepn\widctlpar \b\f5\fs28\lang2057\kerning28 \sbasedon0\snext0 heading 1;}{\s2\sb240\sa60\keepn\widctlpar \b\i\f5\lang2057 \sbasedon0\snext0 heading 2;}{ \s3\sb240\sa60\keepn\widctlpar \b\f4\lang2057 \sbasedon0\snext0 heading 3;}{\*\cs10 \additive Default Paragraph Font;}{\s15\widctlpar \f4\lang2057 \sbasedon0\snext15 ...;}{\s16\widctlpar\tqc\tx4153\tqr\tx8306 \f4\lang2057 \sbasedon0\snext16 header;}{\* \cs17 \additive\sbasedon10 page number;}{\s18\widctlpar\tqc\tx4153\tqr\tx8306 \f4\lang2057 \sbasedon0\snext18 footer;}}{\info{\title EROS : CASE STUDIES : Treasury : SAROS derived electronic office management system}{\author Public Record Office} {\operator David Bearman}{\creatim\yr1996\mo6\dy5\hr15\min41}{\revtim\yr1998\mo6\dy15\hr13\min17}{\version2}{\edmins0}{\nofpages5}{\nofwords1633}{\nofchars9311}{\*\company Archives & Museum Informatics}{\vern57431}} \paperw11909\paperh16834\margt1800\margb1138 \widowctrl\ftnbj\aenddoc\hyphcaps0\formshade \fet0\sectd \psz9\linex0\endnhere {\header \pard\plain \s16\ri360\widctlpar\tqc\tx4153\tqr\tx8306 \f4\lang2057 {\b Electronic Records Research 1997: Resource Materials \par }\pard\plain \s18\widctlpar\tqc\tx4153\tqr\tx8306 \f4\lang2057 {\fs20 Compilation Copyright, Archives & Museum Informatics 1998 \par Article Copyright, Author} \par }{\footer \pard\plain \s18\qr\widctlpar\tqc\tx4153\tqr\tx8306 \f4\lang2057 {\cs17 p. }{\field{\*\fldinst {\cs17 PAGE }}{\fldrslt {\cs17\lang1024 1}}}{\cs17 .} \par }{\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta )}}{\*\pnseclvl5 \pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang {\pntxtb (}{\pntxta )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain \qc\widctlpar \f4\lang2057 {\b\fs28 EROS CASE STUDY : HM TREASURY : ELECTRONIC DOCUMENT MANAGEMENT STRATEGY \par } \par {\i by Simon Judge, Mike Flynn, Richard Blake, Ian Macfarlane \par }\pard \qj\widctlpar \par \pard \widctlpar {\b 1. Introduction and Background \par }\pard \qj\li284\widctlpar {\b \par }The Treasury wished to understand what opportunities existed to make improvements within its internal operations to enhance its management of information. To facilitate this aim it commissioned a scoping study to address the following issues:- \par \pard \qj\widctlpar\tx709\tx993 \tab \par \tab a) To reduce the financial cost of transferring and storing information within \tab the Treasury \par \tab b) To increase the speed and accuracy with which staff throughout the \tab \tab Treasury can receive new or retrieved stored information \par \tab c) To increase the efficiency with which the Treasury can access information \tab available outside the department \par \tab d) To determine what could be done now and quickly \par \tab - Ministerial correspondence \par \tab - Parliamentary questions \par \tab - Filing \par \tab e) To identify opportunities for business process re-engineering \par \par \pard \qj\widctlpar This study identified a need to reform the main information storage and retrieval process as the department\rquote s vision was that information would be stored electronically and that paper versions would be exceptional. This was gi ven a further focus by the belief that both internal and external communications would be received and generated in an electronic format with E-mail being the predominant means of communication. Underpinning this vision was an assumption that within two y ears 100% of communications within Treasury would be electronic and that within two to five years 90% of information exchanges between Treasury and other government departments would be electronic as would 75% of the links with the financial industry and other public databases. Consequently an electronic document management system was seen as the logical solution. This would have to be integrated with the existing networked OASIS desktop and provide an electronic alternative to the paper filing system. \par \par \pard \qj\fi-284\widctlpar {\b 2. Aims of the System \par }\pard \qj\widctlpar \par It was determined that the existing approach to the management of records including the concept and structure of the paper file would be retained. However, the electronic filing system would provide an optional system for the OASIS d esktop. It was agreed that the new electronic filing system would mirror the paper filing system, enabling users to create electronic files, and to show links to any paper documents associated with those files. The overall objective would be department wi de storage and access to information; high level of security; intelligible file and folder names for the storage of electronic objects; and powerful search facilities which would search on the textual contents of a document, not just certain attributes. \par Alt hough the amount of paper received from external sources will reduce paper documentation and paper files will remain for some time. Nevertheless scanners would be required for the conversion of some of this paper to image, ASCII or word processed text whi ch could then be scanned and indexed into the Document Manager or the network as required. \par \par \pard \qj\fi-426\li142\widctlpar {\b 3. Major Requirements \par }\pard \qj\ri84\widctlpar \par There were three major requirements identified by the scoping study. these were:- \par \tab \par \pard \qj\fi-709\li709\ri509\widctlpar \tab a) A new process for handing ministerial corresponden ce. Ministerial post once read by the minister should be scanned and registered by the Private Office on a database. Thenceforward the letter would be sent by the network to both the relevant Treasury team head and team and, if \tab appropriate, transmitted to the Revenue Central Unit and/or the \tab Customs Parliamentary Unit as well. The affected teams and units would \tab research the matter and draft replies which would either be mailed \tab through the network to the Team Head or, in the case of the units direct \tab to the \tab Private Office for approval. After approval or amendment a paper \tab document would be printed for the minister\rquote s signature and despatch. \par \pard \qj\ri509\widctlpar \par \pard \qj\ri510\widctlpar \tab b) A new process for handling Parliamentary Questions (PQs). Here it \tab was envisaged that the Parliamentary Unit would send an electronic copy \tab to the relevant division and they in turn would send an electronic reply. \tab Following ministerial approval copies would despatched to Hansard and \tab the press gallery and the electronic copy would also be passed to \tab Hansards. \par \pard \qj\fi-142\li142\ri510\widctlpar \par \pard \qj\fi-142\li142\ri509\widctlpar \tab \tab c) An electronic filing system which would ensure documents entered the \par \tab \tab the registration system upon creation and allow for active management \tab of the files including access and version control. Documents would have \tab to be managed transparently throughout the network, while integrity, \tab security and a well-structured document production cycle was \tab maintained. \par \par \pard \qj\fi-284\widctlpar {\b 4. System Structure / Architecture \par }\pard \qj\widctlpar {\b \par }The selected document management system had to work with the OASIS desktop which is a networked software packa ge available to all users and provides a platform for word processing spreadsheets and other office based systems. SAROS Document Manager was selected to undertake this role due to its open architecture and ability to use window based applications. The Do cument Manager is itself rooted in the client server software SAROS Mezzanine and it uses this to manage the life-cycle of documents and their components. Its functions include network-wide searching, version control, access control, system backup and a w ide range of library facilities. \par The department currently relies on a system of locally based functionally controlled file servers dedicated to functional desktops which are themselves linked to a departmental wide network. SAROS Document Manager is a centrally based server linked to the desktop network to provide an administrative service for the whole department. The files are accessed locally but they must be routed via the document manager if they are to be saved on the system. \par Each document has a defina ble limit to the number of versions kept on-line. When that limit is exceeded designated versions are automatically archived to a pre-determined location. If access to an archived version is required a reclaim process can retrieve it from the designated a rchive area. \par Its open architecture and modular approach allows for expansion and development and new hardware, such as additional servers. and new software can be incorporated on the system with no effect on existing users \par \par \pard \qj\fi-284\widctlpar {\b 5. Controls, Rules and Standards \par }\pard \qj\widctlpar {\b \par } An administrative group has been set up for each directorate which will include super users. Within each directorate there are a number of super users who will be responsible for creating and maintaining the hierarchical folder structure. Their role is an alogous to that of filing clerks employed in the paper registry system. This is to enable them to set up and maintain the folder structure. A team\rquote s super user will be responsible for creating any sub-team, subject and file folders. Only the super user is authorised to do this \tab work and no one else may undertake this work. The system is designed with \tab folder defaults so that any corporate folder, will be visible and accessible to any user. However, super users will be able to overwrite the access permi ssions below directorate folder level although they will not own or have access to the contents of personal folders. By default, personal folders and the folders below them will only be visible to the person concerned and to the system administrator.{\b \par \par }\pard \qj\fi-284\widctlpar {\b 6. Information / Records Structure and Rules / Definitions \par }\pard \qj\widctlpar {\b \par } The SAROS Document Management System was chosen to provide the electronic filing facility. SAROS is organised into libraries and includes the facilities to enable users to create hierarchical folder structures within the libraries to help them manage thei r documents. Users were presented with three possible choices of folder structure. \par \par These were:- \par \par \tab a)Hierarchical folder structure that exactly mirrors the current paper based \tab \tab filing system of teams and sub teams, each with their own alpha (subject \tab \tab classification) list, and within each subject a series of individual folders \tab \tab exactly corresponding to the current files \par \tab b) A directorate wide structure by merging the current alpha lists \par \tab c) A \ldblquote big bucket\rdblquote approach using a very limited subject set and relying on the \tab search facilities available with SAROS{\b \par \par }Within the main library the Information System Team set up an initial hierarchical folder structure. This followed the organisa tional structure of Directorates and Teams. A folder was set up for each Directorate and within each of these a Directorate Management folder and Team folders. Directorate folders are controlled centrally. Users only have viewer access to these folders an d are not to be able to add documents or folders to them. Folders in this layer only contain other folders. They do not contain documents. \par \par \par \par \par \par The layers below the Directorate folders can be of variable thickness. Whether a Directorate retains its team folders for example, depends on the structure it has chosen to work with but it is likely to be one of the following: \par \par \tab \tab team then subject then file;\tab \par \par \pard \qj\ri84\widctlpar \tab \tab team then sub-team then subject then file; \par \par \tab \tab subject then file; \par \par \tab \tab subject and smart folders. \par \par A file folder corresponds to the existing paper folder; subjects are taken from an existing or revised alpha list, and teams and sub-teams have only been included if a Directorate\rquote s current filing system is defined in this way, and they wish to continue this practice. \par Individual users are free to add documents and folders to folders at the lowest level of their Directorate or Team structure \par \pard \qj\widctlpar In addition some teams may require a Team Management folder, and each user may also have a personal folder. All teams have been given a parent folder to hold all the personal folders for the whole team. Individual team members will be free to put whatever they like into their personal folder on the understanding that official papers are stored in the team\rquote s files within the hierarchical folder structure. \par Most users have chosen the first option for their hierarchical folder structure as it has the advantage of familiarity and the link to the paper based files is intuitive and easy to understand. The disadvantages are that the user has a much bigger folder population to choose from as a home for their documents, taking longer and making errors more likely. A further problem is that the user will also be limited in the use of \ldblquote smart\rdblquote folders as initially it will only be possible to search on the contents of the \ldblquote parent\rdblquote folder. This however should be rectified as the folder search facility becomes available. \par Users choosing the second and third options (see (b) and (c) above) would avoid the disadvantages of the hierarchical system but there would be a need to review \ldblquote alpha\rdblquote lists and current filing practices in order to develop a directorate structure, or a limited subject set, which would involve a grea t deal of work. Consequently the recommended option was the hierarchical system but directorates were permitted to choose. However, it was emphasised that directorate and teams should not simply replicate the existing paper system as the transition to an electronic filing system presents users with an opportunity to rationalise their paper structure and then align the electronic structure with the revised architecture of the paper system. \par \par October 1996 \par }