Developing a repository is synonym of creating a departmental document’s safekeeping. Putting aside proper taxonomy definition, organizational site structure is defined and respective department start throwing their documents inside it. It will help on promoting single source of truth by promoting multiple access by internal staffs, dealing with departmental documents.
Times goes on then suddenly there is another requirement of setting up another repository for non-departmental repository which of course not involving same department’s user. Hence a collaborative repository created and users start dumping relevant documents.
A question suddenly appears, is there any relation between departmental and collaboration’s repository?
When setting up a repository most of the architect will found issues on managing access level for user’s accessing the location. The repository created was mean for internal staffs but at the same time required to be accessible by external or cross departmental users. Granting access for specific documents is do able, but will it solve the issue or creating other issues? Let see some of the scenarios with pros and cons.
- Granting Access At File / Folder Level
Pros: The easiest way to do without concerning for the user accessing other contents. Find the user in existing database or create a new user directly assign to the specific files/folders. The access might be temporary and required to be revoke once access no longer required.
Cons: Once in a while still acceptable. But when dealing with multiple files and too many users it will cause issues on managing the repository. Cataloging on assignation will be massive and difficult to manage. Most of the cases repository administrator do not revoke granted access when the assignment completed. Housekeeping will occur once audit issues arose or blunders on.
- Copying Files at Another Repository
Pros: Created repository designated for collaborating and assigned for certain members. Assigned user can have roles as low as reader and as extensive as the owner.
Cons: Replication of documents caused inconsistency of creating single source of truth repository. Issues arose when trying to identify which repository holding updated version or meaningful information. Furthermore content owner were not properly defined. When it is resides in a collaborative repository it will be identified as a join venture ownership, not any organization or department’s specific.
- Downloading and Distributing Required Documents
Pros: No user access required to be created and be accessible to anybody.
Cons: Again not referring to the designated repository will promote multiple source of truth. Furthermore releasing the document outside controlled repository definitely exposing for information leakage.
- Managing Content Life Cycle Through Multiple Repository
Pros: Documents travels through out it’s content life cycle, jumping from one repository (ie: collaboration repository) to another, until ultimately it has been identified as record (ie: departmental repository). Even though it has been created as a record, it still capable to be re-initiate into another content life cycle.
Cons: A comprehensive workflows required to be identified before it can be applies.
- Metadata Consumption
Pros: Defined metadata mostly presenting to keys element that representing common usages. As example Project Name, Fraternity and many others. A collaborative repository as example Project XYZ can consume all XYZ related documents from various repository and assign access from within it’s own repository. The single source of truth still preserved with respective originated repository holding ownership of the document
Cons: Not much content repository products in the market can handle this requirement. Heavy customization is required.
From above listed scenarios shows pretty much of relations between departmental and collaboration repository. Departmental repository were keeping record, governance, reference or consolidation related content while collaborative repository are dealing with content in-progress or enhancement. The relation can up to one departmental repository linked to multiple collaborative repository.
Giving another example, a Project site is a collaboration repository. Most of the implementation document will be deposit in Project site will the governing documents can be access through departmental site (ideally to be feed to the Project site). Once Project’s related have been finalized, consolidated contents going to be archived in the departmental site.
As part of the information management group, you were assigned to develop a taxonomy for your organization. You will start wondering how to start and what is your base. As per written in my last article (What is Taxonomy?), most of people will start with the organizational structure, which is not wrong. At the same time few other aspects need to consider. Will your taxonomy support growth? Can your taxonomy be generalize and be replicate to other departments? How to manage focus group taxonomy? And most important will your taxonomy manageable and can be govern?
Looking from above questions there are few ways to do it. Let look it one by one.
1. Organizational Structure Taxonomy
Using this approach is achievable when you are residing in a small organization. Each department having focus group. There are no overlapping functions. Enough said you and your colleague only do what you are supposed to do.
2. Generic Taxonomy
Living in a big organization, there are often similar functions between departments. These departments will have their own admin staff, procurement, and so on. Their processes and activities were the same and govern from central unit. Thus, when developing the toxonomy all information from these groups need to capture and analyze. The output will be a generic template that can be apply to across departments.
3. Inherited Taxonomy
This taxonomy is an expansion of the above Generic Taxonomy. Let say there are a parent class named ”Administrative” developed for admin’s function. Then there is a need to expand this class for “Engineering Administrative” needs. What can be done is to inherit the main class to the new class with the parent class still governing the main class information.
4. Specific Focus Group Taxonomy
There are certain functions that are niche in a department. There are
little possibility for it to be have in other department. Thus for this class it can stands by it’s own without depending with other classes.
Above methods were not the ultimate approach for developing a taxonomy. Situational analysis is vital before deciding which approach that should be taken. It will be wasted if it is too methodological by leaving business needs behind.
“Taxonomy”. One word with multiple understanding. When I’m being introduced to this term I was made to understand it is a folder hierarchy to store documents. I sticks with that understanding until I realized, taxonomy is more than that.
“Corporate taxonomy is the hierarchical classification of entities of interest of an enterprise, organization or administration, used to classify documents, digital assets and other information. Taxonomies can cover virtually any type of physical or conceptual entities (products, processes, knowledge fields, human groups, etc.) at any level of granularity.” – Wikipedia
When developing taxonomy, a lot of things need to be consider. Most of the organization will use organizational structure as the basis. It is not wrong but it is not quite effective as there will be re-organize the structure and transformation may happened. When this happen then definitely the taxonomy required to change.
The best way to come out with taxonomy is to take account all information existed in the organization, not only restricted to documents. The outcome should be a multi-facet taxonomy which can consume from multiple angles. Last time NASA did shared their taxonomy to public which for me it is a good reference when developing multi-facet taxonomy.
Other things that need to be consider that the taxonomy should not be 100% structured. It can be balance maybe 70% structured and 30% unstructured. By having this your implementation can be easily fit with your business processes.