It seems like I've been talking about this issue for a long time: how do we organize information? I now have a stock pile of opinions and key set pieces that I use to describe my thoughts and beliefs. But are those beliefs accurate? Have I spent so much time pontificating that I've lost the track of the real issues and approaches?
Resetting
Let's start with one of the most basic issues in information organization: setting up a filing system.
Wess Jolley of Dartmouth College provides some succinct guidance on building a file plan (http://www.dartmouth.edu/~library/recmgmt/forms/FilePlanSlides.pdf). A file plan guides the creation, access, and disposal of records. Creating a file plan typically involves identifying "functions", "activities", and "classifications". Ultimately, the file plan has to be simple, consistent, and flexible.
Function -- a high level group of activities or major areas of responsibilities. Ideally, there are 10 or fewer functions (i.e., 7 +/- 2).
Activity -- work processes or flows within the higher level function. Again, there should be 10 or fewer activities per function but there can be as many as necessary.
Classification -- could include tasks, transactions, or sub-activities. Note that retention and disposition policies typically happen at this lower level. Again, an Activity should have 10 or fewer classifications.
Step 1: Gather Information. Jolley provides a valuable list of existing information sources: directory structures, file lists, retention schedules, organizational documents (mandate, mission, services, program areas, reporting relationships, annual reports, organizational charts, strategic plans), and interviews.
Step 2. Identify Functions. They often feature in mission statements or objects. They could be related to either administration or mission. Common administrative functions include: HR, finance, IT, facilities, PR, etc. Mission policies are related to the purpose of the department or organization (e.g., Department of Health -- Hospital Administration, Hospital Services, etc.; Police Force -- Crime Prevention, Crime Investigation, etc.).
Step 3. Identify Activities. Interviews are often important for identifying activities (e.g., Human Resources function -- Recruitment, Training, Review and promotion).
Step 4. Identify Classifications. These are tasks to support Activities. They are not subjects or record types or document types. They could be transactions or tasks. For example, Human Resources -- Recruitment could have Classifications like Advertising, Receiving Applications, or Conducting Interviews.
Step 5. Document the file plan. A file plan will typically identify Functions, Activities, Classifications, Samples of the record or document types, the appropriate record series, and the relevant retention period. Note that a particular Classification generally relates to a particular Record Series and inherits the relevant retention period. Each Function and Activity should have a scope note that specifically identify what each does and does not do. The file plan could be applied to servers, workstations, content management systems, physical files, or e-mail.
Step 6. Implementation and Migration. Remove the transitory information (i.e., anything with no value). Get rid of records that you no longer have to keep. You have a few migration options. You can move everything, current year + 1, or on a go-forward basis with historical information migrated on-demand.
Step 7. Maintenance. Designate a File Plan Administrator. Create procedures (and authority) to prevent ad-hoc modification and support standards enforcement.
There are a few things that Jolley didn't mention but that I noticed. The names of the Functions, Activities, and Classifications all conformed to the standard conventions for thesauri construction so that's nice. Jolley also references some other interesting resources that probably bear some consideration.
DIRKS, for example, is an Australian operationalization of ISO 15489 (http://www.records.nsw.gov.au/documents/recordkeeping-dirks/DIRKS%20Manual.pdf). It specifically articulates an eight step process for developing a records managemetn system: preliminary investigation, anlysis of business activity, identification of recordkeeping requirements, assessment of existing systems, identification of strategies for recordkeeping, design of a recordkeeping system, implementation of a recordkeeping system, and post-implementation review.
Overall, DIRKS provides a great framework for -- and worked examples of -- deploying records management programs in different types of organizations. It does, however, have a few gaps. My primary concern is with Section B (Analysis of Business Activity). It is relatively weak at articulating how this should be done. Admittedely, most standards are!
One could, for example, expoit the APQC Process Classification Framework as a starting point. It articulates a combination of five different "operating processes" and seven "management and support processes". The operating processes include:
- Develop vision and strategy
- Develop and manage products and services
- Market and sell products and services
- Deliver products and services
- Manage customer service
The manage and support processes are:
- Develop and manage human capital
- Manage information technology
- Manage financial resources
- Acquire, construct, and manage assets
- Manage risk, compliance, remdiation, and resiliency
- Manage external relationships
- Develop and manage business capabilities
Unfortuntely, using the APQC PCF for determining Functions leads to more than ten categories. The naming convention is also a bit goofy and really not ANSI/NISO Z39.19-2005 compliant (commas! the horror... the horror...). APQC's underlying sub-processes are, however, generally inline with our filing plan guidelines.
Actually creating business process maps in a different issue. We see the concept in various quality management standards and approaches yet we don't get the same degree of standardization in approach despite the introduction of things like BPMN, Rational, SIPOC, etc. (NOTE: SIPOC might be particularly relevant because of the inherent differentiation. For example, a federal Finance Ministry will use different reports internally from those that it creates for external consumption. The "Suppliers" and "Customers" are different even if the inputs, processes, and outputs are very similar).
Jolley also references the BCS Toolkit produced by The National Archives of the UK (http://www.nationalarchives.gov.uk/documents/information-management/bcs_toolkit.pdf). It notes that there are four different ways of creating business classification scheme. It repeats Jolley's guidance, describing it as a "Functional" strategy (although it describes Functions, Activities, and Transactions -- not classifications). It notes that the functional approach is generally unloved by users but adored by records managers and that it does a poor job of support dynamic organizations or case filings.
The second approach is based on subjects or themes. Of course, we see this structure quite commonly in document management and intranet deployments. Unfortunately, it generally maps poorly to retention schedules. I imaging there is some room for a hybrid approach where records and templates could be organized functionally while documents and library information are organized by subject. Another approach could be to use a functional classification at the folder (or aggregation) layer and use controlled vocabulary for subjects or themes. This approach is likely most effective for personal information management (e.g., Evernote). Dynamic Access Control presents an interesting complication because one could use controlled vocabulary for both functional and thematic organization. In this case, an information manager would have to create separate schedules for subjects and functions.
The third approach is Organizational. I suspect that most intranets use an Organizational approach... unfortunately, organizations are often far more volatile than business processes.
The final option is Hybrid. It provides the example of a Functional strategy at the broad level with subject based sub-classes. This approach makes a lot of sense when we apply it at the work group or individual level. For example, how should someone organize their email? We could make the argument that they should create functionally-based folders for the application of retention tags but use underling subject folders. Of course, there might be issues of orthogonality in the classification so that there is a breakdown in user behaviour. Here's a thought: could the default email folders be provisioned according to the tasks/responsibilities articulated in the job description?
The toolkit notes that a BCS is a crucial part of ISO 15489 compliance but reiterates that the BCS isn't the only information retrieval tool within an enterprise. There will always be a role for keyword searching, browsing, etc.
The BCS really comes into play when a user "declares" a record. There still, however, has to be some guidance on how to manage information of lower value and/or risk. One option may be to exploit a post-coordinated strategy where the user populates a subject field from a standard thesaurus in addition to a functional field.
An interesting quote: "For all the processes defined in the generic functional requirements, possibly conducted in different physical locations and at different stages in the record life-cycle, the BCS provides the central strand and point of reference. Classification schemes 'document the structure of a records management system and the relationships between record[s] and the activities that generate them. They provide an essential basis for the intellectual control of records and faciliate their management and use over time."
Another good one about users: "In the past a discrete specialism in the Registry kept 'bibles', indexes and docket books to enable the specialists to maintain intellectual control and coherence in the records system. Today that specialism must become part of the everyday skills of all mbmebers of the public sector workforce. Such a move will be aided by classification systems that are straightfoward and comprehensible."
The guide notes that a BCS requries guidance on document creation, and rules for filing and capture. It also needs disposal schedules without automated and auditable destruction, migration, or archival transfer.
It does eventually get to a statement about the main purposes of a BCS:
- "providing links between records that originate from the same activity or from related activities
- "determining where a record should be placed in a larger aggregation of records
- "assisting users in retrieving records
- "assisting users in interpreting records
- "assigning and controlling retention periods
- "possibly also, assigning and controlling access rights and security markings."
Another interesting reference is an ARMA article that details the efforts of the Ontario Public Service Ministry of Municipal Affairs and Housing (MMAH) to deal with file classification plans. It created a BCS based on a functional process but included guidance on read access, modify access, and security levels. It also included a fourth level of classification that could be created at the user's discretion for greater granularity (e.g., branch administration -- awards and recognitions -- by calendar year -- by award).
The article notes that because "team members still have to perform their regular duties, it normally takes three to six months to design and finalize the file plan." It also provides a number of metrics that can be used to measure the popularity and usage of the system: number of folders, number of files/records, volume in GB, number of access groups, records to folder ratio. But the most important metric is user satisfaction.
Well, that's a first salvo at this problem. These principles strike me as being very top down heavy and that user's might have a different reaction. There's also the issue of how these particular approaches evolved. I wonder what old text books o
