Electronic File Organisation
Unfortunately, the organising of electronic files tends to be a haphazard process, and compounded by the facilities offered by workstation operating systems and applications. This is quite a contrast from the days before workstation computing became commonplace – hard-copy files were generally stored in a well-defined hierarchy of filing cabinets, drawers and folders. Now, My Computer by default offers to store all documents in the user’s My Documents folder, which unlike a filing cabinet, is essentially unlimited in the number of files (or documents) it can hold. This process is complicated further in a networked environment, where multiple users may contribute new files to the overall storage facility.
General Principles
The purpose of a structured file system is to enable all users, both individual and organisation-wide, to locate and retrieve saved documents, plus also contribute new documents to the file system in a controlled and structured manner.
The old filing cabinet metaphor is probably the best way to start thinking about an organised hierarchy with the following modifications:
- The fixed three-level cabinet hierarchy (Cabinet, Drawer, Folder) may be extended to as many levels as necessary (think about adding Room, Floor, Building) to the hard-copy model, for example.
- A container at any level has a maximum mount of storage available. In an electronic store, this translates to approximately 20-35 items. This translates to about a screen’s worth of display to the user. Above this, the container should be split or subdivided.
- Document names should adequately identify the content of the document, without the user having to open the document. Gone are the days when we were limited to cryptic 8-letter names for documents. For example,“MrTanLtr” is not a good idea, but “Mr Tan Letter Re Costing Proposal” is far more descriptive and useful.
Choosing a Top-Level Structure
There are many theories and methods to developing a suitable hierarchical structure, however the final decision is generally unique to each organisation. Some possible alternatives, to be used as starting points are discussed below. Note that the final structure will most likely employ a combination of the various architectures discussed.
Chronological Structure
The chronological structure is defined by periods in time. Although this may suit some subsection of the file hierarchy, we do not recommend this from for an overall approach. Although it becomes almost automatic when saving a new document, the main disadvantage is that the user must know when a document was created to be able to find it again, and a decision must be made as to whether to base location on creation time, or last update time.
Functional Structure
The functional structure is probably the most useful for a large organisation with multiple departments and functions. Typically, this contains major classifications for departments at the top-level, and is then broken down depending on the needs of each department.
Role-Based Structure
The role-based structure is closely aligned with functional roles and positions within the organisation. Although very similar to the user-based structure, this format does not suffer as employees come and go over the course of time.
Relationship-based Structure
This structure is based on dealings with other organisations and parties. Typically, this involves top-level categories based on flow of services (ie: Vendors, Clients, Associates, etc), and drilling down into individual folders for each relationship, w ith further subdivisions depending on the nature of the relationship and services involved.
Non-recommended Structures
The following are included for completeness’ sake, but are not recommended to be used in the current environment.
| Document-Type Structure | Based on the application used to open the particular, this is no longer relevant, as most applications today will present the user with a view of only appropriate documents, and most applications are capable of opening multiple document types. | |
| User-Based Structure | User-Based Structure Users change over time. Each time this happens, documents may need to be re-filed, and may be deleted inadvertently if the user leaves. | |
| Project-Based Structure | Although useful as a substructure, as new projects continue indefinitely, the number of containers in the top-level increases to a quantity that may soon become unmanageable. |
Structure Additions
Once an overall structure has been designed, there are certain additions that should be incorporated at the top-level to all electronic hierarchical file systems. Each of these is described below.
Software
Software in it’s various forms is a requirement to operate. New components should be added here to facilitate rolling out to networked workstations. This substructure should contain such things as software patches and updates, printer drivers, utility software, internally developed or custom routines, and more. A sub-structure should be established along the above lines.
Users
Each user should have their own private container under a separate Users top-level container. These containers should be private and confidential to the individual user. No organisational information should be stored in these containers, and the substructure design should be relegated to the individual user. It is expected that an individual user container would be deleted should the user no longer be employed within the organisation.
Templates
Every organisation maintains standard documents – such as forms, letter/memo/fax layouts, boilerplate texts, and others. These should be stored in a separate area, accessible to all users. A sub-hierarchy should be established if the number of such items exceeds the recommended container storage limits.
