Tag Archive for taxonomy

Multifacet Taxonomy

June 18, 2013 Information Management No comments

Never ending, that is the term for developing taxonomy. As time goes by, new setup take in place which lead to new requirement or reorganizing the taxonomy. It is unavoidable and understandable. But what if because of other department or other fraternity understands it differently, you required to change your taxonomy setup? Definitely NO!

Taxonomy definition during development usually takes consideration of consumer and creator of related contents and properly apply relevant metadata on top of it. Applied metadata might consist of, department names, discipline names, phases, project name, processes, and any other key attributes. Give an example from main taxonomy it do have finance related content in multiple nodes. From finance department point of view they were only interested to finance related contents, thus by constructing another facet from main taxonomy’s metadata, department type taxonomy can be display.

Multifacet Taxonomy Sample - NizShop

 

Another example is some of the taxonomy nodes can be re-grouping on another facet. Development and operation’s activity can be group under technical’s view. Same goes to managed services should fall under support were taken out to be the parent of support. It is something similar of reversing the arrangement.

By constructing taxonomy through multifacet taxonomy definitely will help when dealing with predefined work breakdown structures. The most important part is to properly manages and assigns metadata to it relevant contents.

Departmental vs Collaboration Repository

June 18, 2013 Information Management No comments

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.

ECM Life Cycle

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Content Life Cycle from Multiple 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.

Project vs Department Repository

Developing a Taxonomy

May 31, 2013 Information Management No comments

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.

Organization Chart Taxonomy

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.

Generic Taxonomy

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.

Inherited Taxonomy

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.

Specific Taxonomy

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.

What is Taxonomy?

May 24, 2013 Information Management One comment

“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.

Taxonomy Creation

“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.

Organization Chart Taxonomy

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.

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.

Structured vs Unstructured

Enterprise Content Management (ECM): Do you know what you deploy?

May 24, 2013 Information Management No comments

The big organization started worrying on organizing their documents. Audit reports passing by highlighting documents that are not in place. 5 years back instruction memo could not being found. Location to deposits document were debatable. Everything seems so wrong when the word “DOCUMENT” raised in the management meeting. Yes, something need to be done to solve all of this issues.

As usual, IT departments were summoned to be responsible for all of this miserable cause. Taking the offends without much to excuse, solutions by solutions being analyzed. Looking to the best practices, getting inputs from Gartner, started navigating AIIM website, ECM suddenly popped out as the solutions. Leaders of the ECM technology provider presented to the management for procurement process. Once identified, the selected product procured and started to implement in the organization.

Basically above scenario is the common situation happened in organizations.

The questions that should be roast is, will it solve all said issues? Do the IT department thought of:

  • Do you implementing ECM or DMS (document management system)?
  • Do the solutions fit your nature of business?
  • Can user adapt to this change?
  • Can the document be found by having this system?
  • and many other why, can, how, who, etc questions

–

ECM Life Cycle

In order to implement ECM technology, lot of things need to put as consideration and preparation. Internal situational assessment need to be in place in order to understand what is the main pain point, business gaps that contribute to the pain points, business chain that can be benefits from the implementation, existing applications that create and consume documents, technical application that handling proprietary document format, records guideline/policy and any other that applicable.

Once the situational assessment completed, the foundation of ECM need to be develop. Underlining Information Architecture as the base, taxonomy and metadata need to be develop. There are a lot of approach on implementing taxonomy as long it is multifacet. As the metadata, all vocabularies need to be identified and controlled. It won’t be a few days activities. It can take weeks, months or perhaps years depend on the organization size and prioritizing strategy. When any workshops conducted for this activities, please bear in mind that the participants might came from support staffs and engineers/technical. Thus the approach need to apply is based on the cultural and local society. As examples Asian/South East will not be approachable if western style being used. Record’s management and policy need to be define and include in the Information Architecture.

Once the Information Architecture is there (70-100% completion) other identified issues during situational assessment will be incorporated on top of the Information Architecture. It will presented as example accessibility, integration with existing application, business process workflow, technical documents, integration with document related creator and consumer and so on.

ECM Blue Print

Once everything is in place as the ECM Architecture Blueprint, then it will be the best time to evaluate available ECM technology which can fit in with the prepared requirement. Sometime the ECM technology leaders might not suite but it is okay not to proceed with the leaders as the business needs must be on top of the technology offerings. In other hand, the ECM technology might not offers solution to cater the business requirement, it’s 3rd party solution might help to fulfil what the technology lacks off. As example SharePoint, Documentum, OpenText, FileNet will be the foundation as document repository and other 3rd party solutions will be it’s flavour to make it as a perfect cake.

Once the technology implemented, adoption activities need to be conduct. Defined taxonomy should be tag with business process. Most of user reluctant to use the system as to them it is too hassle on uploading multiple documents and applying sets of metadata. By having automated workflow will definitely assist users by automatically place the document in the right taxonomy and applying metadata set. The business process can be as simple as prepare, verify and approve or multi-conditional and routing processes.

Prepare Verify Approve

Implementing ECM will not have an end date. ECM itself is a journey. From time to time a lot of things need to be improvise. From governance office it need to be properly manage with policies and guidelines.