Living in a large organization required medium for circulating first hand information to all staffs. If looking back at old days, notice board will be the main medium while in bits and bytes age, intranet portal is the preference. Intranet portal existed since intranet being introduced in the organization, focusing on internal information and federated from outside internet. So, since those days, have it delivered it purpose?

Common features of intranet is the news update, announcement, photo gallery, quick facts and sub sites for the respective organization’s department which having the same feature as it’s parent site. Looking at from the illustrated concept, it shows that each portal site have their own governance and content administration. Having said, content submission required to be vet through before it can be publish to the portal’s page. Filtering process might drop several contents that relevant to niche group but less important to the organization. Thus what will left in the portal consist of common knowledge which equivalent with high level knowledge. By having this situation it lead to less consumption by majority of staffs but will pleased the top management. But wait! Why I am emphasizing “knowledge” not information? Well it is due to the information contributed is meaningless to most of other staffs but valuable and knowledgeable to the focus group.

Other issue that arose was relevancy when the information (not knowledge) were outdated when the time it published to the portal site. Process of vetting from internal review until to corporate review make it worsen. It is understandable when it purposed for internet publishing but not for internal.

Having each department owning their own intranet portal make information scattered and deviates staff from accessing the information. They do know the portal existence but will not favour accessing to the site.

As most of staffs focusing on their KPls’, when they could not get information from the intranet, they will start frustrated and won’t bother to come again.

So now come the questions how to overcome this issues and bring out the best from it. Let tackle it item by item.

Let Everybody Contribute
Looking at the current practices, limiting the content contribution will not make any good. Give all staffs to contribute their findings, opinions and articles with they themselves taking ownership for their published contents. Along with permitting this privilege there should be some guidelines to impose in order for ensuring they are not abusing given privilege. Accomodate this feature should reduce or eliminate any vetting process.

Eliminate Departmental Portal
Let everybody utilize main intranet portal rather than providing another departmental portal. By performing this it can promote single source of “location” and accomodate all staffs to consume available information within organization. There are going to be massive contents in the single portal however by applying specific attributes will facilitate on managing information digging and classification.

Apply “New Web Trends”
Past few years “webthusiastic” started with Web 2.0 concept. It involves sleek user experiences, tagging, content driven, less graphics, no animation, semantic approach and many more. By applying above recommendations, this concept definitely can be easily suit in.

Dashboard Reporting
Common contents can be divide into two segment, which the first segment is the text based content and the second segment is the graphical presentation. Graphical presentation mostly came from analytical process and business intelligent end result. There are needs for organization to get first glimpse on certain production or utilization. By implementing this, it do help staffs having staf informed with real time trending.

Information Security & Classification
There should be content filtering based on staff’s role and position. Applying right attributes on the content itself can help determining content’s filtering. The filtering inclusive of write-ups and dashboard thus staff’s profile match up can be apply.

Linking to Corporate Master Data
Each of portal’s content definitely have it’s own attributes (metadata). Rather than trying to solve portal’s data integrity, it should leveraging corporate master data as any content creation can be tag to business process’ application. As an example the dashboard should feed from certain application and it’s view be controlled be the staff’s profile match-up.

Document Storing/Linking to ECM
Referred back to my previous article, it shows the demarcation of portal and ECM. It is two different thing but need to complement each other. Portal is the presentation layer while ECM will be the core layer. Thus when there is a need to share documents in portal, it will provide a link to documents which reside in ECM.

Content Socializing
Published content should not be limited to just content viewing, it should be extend to content socializing. Posted content might lead to queries thus enabling comments is recommended. Besides this approach should replacing common forums or bulletin boards. At the same time, other features such as post recommendation, rating, sharing through notification/social media, bookmarking should be available. Doing this it will promoting the content information into a knowledge sharing.

Mobile Enabled“All web content must be mobile enabled!”. Now days most of human beings do have mobile device closed to them. Mobile device is the main medium for consuming information in the internet. If they can use it for internet, why not intranet? As when they can access the intranet portal through their mobile devices, having the portal itself was not mobile friendly, it will deviate staffs from utilizing the portal. They need to wait until they get back to their workstation and start using either desktop or laptop just for accessing the portal.

All item above do improvise the portal itself but do not going to increase the portal utilization. Proper change management should be available to ensure all staffs properly on-board and understands the rational of having above items implemented.

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.

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.

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 LevelPros: 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 RepositoryPros: 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 DocumentsPros: 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 RepositoryPros: 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 ConsumptionPros: 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 documentCons: 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.

The owner of madfozi.net will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.