Posted by: David Scott
when relevant content is
added and updated.
Creation: Staff creates new content, perhaps a new word-processing document. This new content may be generated as entirely new material, or it could be content that is being repurposed and built upon (edited and added to) from existing content.
Filing (Storing): The new content is filed, as a file’s creator would normally generate and store documents (File, Save, or Save As…, etc.). The Repository will take action based on the file’s destination folder; based on the creator’s choice of folder according to subject matter, and the content’s relation to other like-content.
Categorizing (Taxonomy): Storage is also the means by which content is categorized; by virtue of the folder in which content is stored by the creator. Folders within the Repository will be dedicated to specific categories of content. Depending on your desire, the content management system can also suggest storage and categorization based on its inspection of the document’s contents at the time of its creation, and subsequent comparison of key content to an organizational taxonomy table.
Metadata (Tagging): The content’s location and categorization also lead to the assignment of key metadata. The document’s metadata is assigned by virtue of a metadata template that is associated to each content area (folder). This way, each template’s information is leveraged for the tagging of all like-content in a specific folder. The system can also extract keywords from documents for inclusion to the metadata, and can generate an abstract or summary.
Delivering/Sharing: Content is now delivered when users query for various categories of content, on keywords, and concepts. Collection and reference of data is now as comprehensive as possible. You can even have your content/records manager query on content that has specific areas of metadata that are unpopulated (unfilled) – for purpose of generating a report concerning these documents. The report(s) can then be delivered to various content authorities for completing the assignment of metadata to this content.
Re-using and Repurposing: Now that content is locatable, identifiable, accessible and readily understood, it is easily employed for reuse. With proper authority and access, departments can glean knowledge, formatting, and process from other department’s content. Further, content can be repurposed: it can be modified and incorporated to new content.
Review and Reporting: Content now is available for review by any appropriate authority. Reports can be run to review all documentation generated in a given day for a specific client, for example. You can view who produced the most effort – who is doing the bulk of the real work?
This is also where you take action on content in accordance with a retention plan. Disposition dates of documents provide the yield for a monthly report. The report can indicate all documents subject to archive, and subject to destruction (pending review by the appropriate authority, of course). This report can also expose those documents that must have their disposition date adjusted – this can be due to reasons of regenerated business, inquiry, subpoena, discovery, etc.
Action: Once content ages to the point where it is no longer being accessed (easily determined by reports), and is unlikely to provide further, or timely, business value, it can be archived or destroyed.
– Archiving: Archiving the information means that you remove it from your active business environment, and store it somewhere else – perhaps with a vendor who maintains your offsite backups, or in an offsite warehouse where your organization makes other storage of items. Archived material can be compressed and stored on high-density (high capacity) storage media, such as DVDs and CD-ROMs.
This material is cataloged, and can always be referenced if the organization needs to go back to it. It can even be reintroduced to your active business environment if the need arises – nothing is “lost.” The purpose in archiving is to prevent the active business environment from becoming overrun with useless data. Taken to its logical extreme, if you don’t manage the removal of relatively useless data, it will eventually outweigh your useful data.
– Destruction: Business material that becomes completely obsolete, as determined by Business, and technical documentation as determined by IT, should be destroyed. Anything that serves no further purpose to the organization should be destroyed.
A Practical Example: Let’s provide a quick practical example in the life of a document: let’s say that the organization has a current project; Project LMN, and associated content. The project’s scope or domain could be anything: a marketing initiative, it could be legal representation of a client, it could be a new software solution and its implementation.
Project LMN documents reside in a specific Project LMN Folder – that folder would have an associated metadata-template for the management of this project’s content. Also, the main folder would have attendant subfolders, such as an LMN Budget folder for specific budget info and docs regarding the project. Of course, specific subfolders to the main project folder would have their own metadata templates too. Subfolder-templates can inherit the main folders metadata if you like. However, many subfolders will require at least some unique metadata information. For example, it’s likely that budget material associated with the project has a specific authority for access and edit; so, a budget subfolder within the main project folder would have a metadata template that differs, and it will tag budget information with different metadata. Of course, authorized content creators and users within any folder can edit and tweak metadata to reflect the desire for control and disposition of that particular content.
Creation of new LMN content, such as a document, would bring up a dialog box requiring a destination folder – once identified, that folder’s default metadata would fill this new document’s specific metadata template. This would tag the document based on its content, and its match to taxonomies used in the organization. Thus, when we create and file content in a specific folder, it gets tagged with appropriate metadata based on the folder’s template. In this manner, controlling elements that are common to all Project LMN material are applied to content: Such things as the document’s title, its category (Project LMN), its life, its disposition instructions at the end of that life, its securities and permissions, among other things.
In addition, other specific tags relevant to the document itself are made. The contents can be surveyed by the system in order to automatically generate very specific metadata that is relevant only to that individual document – extracting keywords such as author, names, places, dates and other key information. The system extracts these things based on built-in pattern recognition. These keywords can be gleaned based on a predetermined list provided by the vendor’s application, and by your own internal table of keywords – you can build your own custom pattern recognitions.
This document could also inhabit multiple categories: for example, its metadata could indicate that it is a general budget document, and contains specific Project LMN budget components. The document would have a disposition date for archive or destruction, in accordance with the project’s standing in your retention plan, and as necessary, within compliance for any of the other categories.
The creating user would either accept the metadata, or edit it – as authorized. All new content that is generated and saved within the Project LMN area of the Repository will automatically assume the appropriate metadata for the management of that content. Now the document is enriched according to attributes and keywords associated with that document – things your users can identify and use when searching for LMN content. This way, authorized users can search, browse, and aggregate critical content regardless where the content is stored.
Let’s say a creator generates a document regarding the project, but chooses to store that document in their User folder. This is ok, since the document’s overall subject matter (Project LMN) will still allow appropriate categorization, and subsequent associated default metadata. The system will still review the document’s content in order to generate the other specific metadata. In fact, a likely scenario would be one whereby an authority would arrange for a Project LMN subfolder within all User folders for those staff associated with the project – using the same default metadata template for the main Project LMN Folder. Therefore as you go along, all Project LMN documents will be traceable, retrievable, and actionable no matter where they reside – in user folders, central project folders, or even e-mail, if desired, and no matter what the form of the document: wordprocessing, spreadsheet, presentation, or e-mail.
We’ve now enabled a powerful way to identify the Project LMN files, and anyone associated with the project can search for them, and if authorized, access and use them. When we capture content, we can: develop; manage; review; approve; archive; check-in/check-out; maintain version control; perform full-text and metadata search; optimize team communication; automate routing requirements; and deliver notification of status changes and new documents. We can provide specific information and the surrounding context needed to optimize work within the project team. We add value by exposing such related material as additional documents, tasks, calendar items, and team e-mail. Our intellectual capital is in a secure, centralized repository. All project matter is centralized and accessible.
This material can also be copied and repurposed within other projects and initiatives when it has relevant content. Too, when Project LMN is long completed and done, and its material no longer of any practical use in the active environment, this content can be fully identified and acted upon for ultimate disposition.