File Organisation

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.
Table 1: Non-recommended file structures

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

© 2016 PASR Technologies Pte Ltd

Terms & ConditionsPrivacy Policy

Support

Support Hotlines

Email: support@pasr.net

Skype: pasrsupport

  • Singapore

    +65 6340 1018

  • India

    000 800 443 0046

  • Philippines

    1800 1651 0800