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.
When a topic raised where should I share (which actually store) my document, few locations popped out. In a big organization there will be a lot of initiatives for storing and collaborating documents. As example corporate units were having a departmental portal displaying news, initiative updates, announcement and might host few documents such as circulations, memos, guidelines or perhaps news clips. Mean while knowledge department unit for sure will have knowledge portal to encourage knowledge sharing which for sure involving documents. When come out to internal audit unit (or IT), there will be ECM for storing department’s document. Doesn’t is sounds that all of this have similarities?
When implementing a collaboration platform, all of above aspects need to be consider and defined as business requirement. A proper architecture need to define who owns what, where to locate it, who is the consumer, who will be the creator, what is the linkages between repository and what is the access list. Drawing this information will assist promoting single source of truth.
Most of this scenario take place when an organization is using same technology for providing the solutions. As example MS SharePoint as the portal and document repository. Users will use “MS SharePoint” terms rather than the solutions itself. In order to arrange all the site let’s put it in two layers. The bottom layer will be the “Portal” and the top will be the “ECM”. Within the portal itself it will be arrange through it functional sites. Such as the organizational portal as the main site while other departments portal will be the sub sites. The departmental portal will be having specific information of each respective department. The nodes can be extends deeper until it unit’s site, depends on the business requirement. Beside of the departmental portals, the organization can have a collaborative portal for collaborating across department or with outside organization. The collaboration portal mostly fit when there is a project activity that require non-department access. Besides the collaboration portal can fit for requirement to have a place for community or fraternity to communicate.
In this model, Portal’s role is only on managing information, not document. All documents must reside in ECM. ECM itself might have multiple repository based on the business requirement. Thus all documents that required to be shared or collaborate through the portal must be a link that pointing to it’s original location in ECM. Thus the functions between this two site can be defined and manageable.
By following this model, there will be queries on how knowledge management team can come into the picture. Basically the corporate unit is the one who govern on the policies and guidelines while knowledge management unit will enforce on the operation, change, utilization and the content itself. As for the IT unit, they need to ensure that the platform is accessible and solve any arise issues.