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