Introduction to Knowledge Sharing Systems

Copied from Casey Kochmer's website

This is a review on information sharing processes. The goal is help determine a valid knowledge sharing approach for an organization. This is a discussion to help those interested in building a collaboration network to gain an initial understanding of what is involved at a high level.


Cultural Considerations.

The first and foremost consideration for any collaboration project is not of a technical nature but rather one of human nature. Collaboration / Knowledge tools are based upon social networking so the culture of the participants must be considered and addressed first.

For example, often times when shopping for a Collaboration / Knowledge tool an organization will look to other similar organizations with a successful Collaboration / Knowledge bases. So in this a customer will find software products based upon currently successful implementations. With such a recommendation the assumption is made that the technical product can move smoothly across. However, what isn't seen are the years of education and maturity the users have had to grow into a system. What isn't seen are the many hours of administration work to gain the trust of the user base. What isn't seen are the personal interconnections which work to overcome the weaknesses of any software solution. These facts are almost always overlooked, as people have a habit of forgetting the more painful past experiences.

Many collaboration networks fail, not for technical reasons but due to social considerations and inadequate social/technical support. It's an easy mistake to make.

This means:

  1. The audience of the tool needs to be clearly defined.
  2. Collaboration / Knowledge bases are an interactive process requiring feedback mechanisms to assist the user base in maintaining the quality of information present.
  3. The nature of the tool must at a lowest common denominator in level of complexity for members using the tool.
  4. A simple base set of rules for social interactions should be established up front to manage expectations. However, at the same time rules need to be at a bare minimum to prevent the process of using the system from becoming unwieldy.
  5. Administrators to facilitate communication need to exist. No social network is 100% self maintaining. Active and polite administrators are often the first point of success or failure in a collaboration system.
  6. Over time collaboration projects grow from simple to more complicated. This means:
    • A collaborative system needs to start as simply as possible
    • Over time collaborative systems need to expand and grow to meet the needs of the membership as the level of sophistication of the users grows.
  7. People only use a system if it's easy and doesn't waste their time. This doesn't mean to use the system which is slickest; it means to pick a system which gives the most value in time management to the users.
  8. A willingness to commit to the users. Many organizations fail simple because they concentrate first upon the technical systems specifications relegating the users down to a secondary concern. The user community and commitment to the user community is always the first priority. This requires time and patience to work with many people, something which is never easy at first as the social interaction is very much an intangible in many respects in terms of determining time and funding to support such activities. Typically this means the first year of any new system requires the allocation of a staff member to act as human relations and help desk representative for the system involved.

Technical Considerations.

Collaboration / Knowledge solutions span across many different technical standards and feature sets. This can be confusing since people like to simplify terms. So one company might use a WIKI and another might use a Document Management Solution. In reality, each company's solution probably crosses over to implement many of the same feature sets. Across all of the software packages hundreds of feature sets exist to handle, manipulate and share information in many of these solutions. This is very confusing since at first customers will experience information overload as they search about systems containing forums, blogs, personal pages, email lists, Wiki pages, help ticket systems, event calendars, document version control and so much more. To make things more confusing: most solutions available are customizable with different versions of same type of tool to plug in and out of the overall system. As an example the web portal software solution XOOPS has 300 modules to choose from, and within that 8 distinctly different versions of forums to choose from. No easy method exists to weed out a valid system out of the countless commercial and freeware versions of software present in the marketplace. As an example I myself personally have reviewed over a hundred systems while working within Collaboration solutions.

Sementics - Primary Purpopse

  • Semantics
    The best way to look at this is to know you are implementing a Collaboration Portal: A web site which permits sharing and cross communication of information.
  • Primary Purpose of the System
    Collaboration systems are not broken out by if they are a Wiki or not, or by technical features. Instead they are broken out by the primary functional purpose of the collaboration involve. A few common functional breakups
    include:
    • Generalized Content Management
    • Time Management
    • Document Libraries
    • Document Creation
    • Process Management
    • Contact Management
    • Task Management
    • Quality Control Tracking
    • Knowledge Base
    • Real Time User Interaction (Social Network)
    • Status Reports and Company Information Pages

It's important to define what is needed up front. Solutions often are optimized relative to their primary functional purpose and then add feature sets with an eye towards that primary purpose. As a result sometimes a company will implement several solutions even though many features might over lap. As an example one company I work for currently implements at least four different tools: Microsoft SharePoint (For online project management as requested by customers), Google JotSpot (For project forums), AtTask (For task management) and XOOPS (For internal company status reports and document libraries). These four tools overlap quite a bit their functionality, real world considerations meant it was more optimal to use several solutions in tandem together to work efficiently in each of their respective sweet spots.

Do users need to edit content directly?

A good technical demarcation is if your users need to actively edit the content or not.

If the users need to edit content in real time, then a Wiki based solution is a good option to take. Wikis offer real time editing of the information present on the web site. The more advance Wikis such as TWiki or Jotspot permit the control of who edits each page with security roles.

One nice aspect of Wikis is having a larger population of resources (every user) to maintain and add content to the system. While trust issues can exist, generally these systems are more reliable and trustworthy than closed systems. As an example Wikipedia's content is constantly reviewed by not only the administrators but by the entire user community. Often spam attacks or blatantly false content is removed within a few minutes. It's a highly efficient self policing system. This type of self content management isn't always possible: yet when achievable this becomes the key to many of the most powerful collaborative systems in the market.

Version and Revision Control.

The need for revision control is often the deal breaker for most Collaboration / Knowledge systems. This represents the ability to save documents and content over time and revert it as needed to earlier copies. Revision control is a difficult process and one which cannot be added to a solution after the fact. As a result many solutions in the market place do not offer good versioning options. Products which have document version control tend to be more expensive for this reason. However, Wikis break this rule. Wikis are based upon concurrent user input, so they require built in version and revision tracking at the get go. Consider a Wiki based solution first if version control is important for your Collaboration / Knowledge solution.

Ease of use of the software for users.

Ideally a software solution should be geared to be easy for a user. This is difficult to judge since hundreds of different user interfaces exist with different styles and benefits. Let's look at Wikis as an example. A Wiki allows users to edit the material in real time. However, most Wikis require a user to learn a special syntax in order to edit the content. This is done for simplicity sake and as a security feature to prevent HTML injection attacks. However, this means a user might have to learn a new syntax to edit web pages. As a result not every user is going to be comfortable using a Wiki with a specialize syntax. Also roughly a hundred different software implementations of Wikis currently exist, many with their own unique syntax. Now Wikis do exist which require no special syntax, they just let you type in text changes like a standard word processor. Ideally you want to choose a Wiki which has a simplified WYSIWYG data entry interface (WYSIWYG - What You See is What You Get) to allow the greatest number of users to easily use the system.

Currently Wikis have a slightly longer learning curve since they represent the latest of the technologies within the Collaboration / Knowledge solution marketplace. The more traditional portal solutions tend to be more familiar to most people and have a quicker uptake.

Location of Server

This translates into the question: Is your organization hosting the solution or are you buying a hosted solution.

Ideally, buying a hosted solution is the best value for your money and resources. Hosting your own independent system is very costly as it means keeping extra staff for the technical resources required to run and maintain the code base. This is something that is often only feasible for companies with a user count in the hundreds or at times in the thousands.

Some tools such as Microsoft SharePoint require an extremely skilled work force along with a large commitment of funding to purchase the software. Other products such as Jotspot give you the option to host on your own, or to cheaply purchase an outsourced hosting plan. Some products such as XOOPS are free but require staffing to setup and maintain over time.

If you are going to host your own solution, then it's critical to pick a solution that matches to your company's base coding language (ASP vs. PHP vs. JSP as an example). Implementing a Collaboration / Knowledge solution already requires learning a new way to do business and setting up of the processes. It's important to lessen the unknowns to help in the success of the tool. As a result picking a tool which matches your department's technical staff is important. This one factor will often limit the choice of tools down to handful options. This is another reason why it's a good choice to pick a solution which is hosted outside your own resources, to help limit problems down to a minimum while concentrating on your user community.

Searchable content.

An important feature of any system storing content, is being able to find that content again later. Most tools come with integrated search features across the web site. However, searching within stored documents is another feature which is much rarer and more expensive. If this is a critical feature then this needs to be stated up front.

Please note in many systems if you convert documents to an HTML page, it's then possible to both provide a web enabled page which is also easily searchable. A searchable attachment is often a feature which separates the inexpensive systems from the more expensive systems.

Time

Once the need for Collaboration / Knowledge solution is establish, you have to pick one based upon the previous considerations. It typically takes one to two months to review through all the options, narrow the choices down to a few choices and then get started to implement a new system.

Technical Summary

It should be apparent that this isn't as simple as choosing a listserv over a Wiki system. The real question is finding one or two integrated packages that come closest to your needs.

If you have infrastructure in place which can be leveraged: then use it. Using the Web means to be flexible in your approach. It's always possible to expand sideways. Even if a new solution were to be used, an older systems could still be part of the solution. Also if you desire to upgrade to a newer product, it's almost always possible to pass content across systems using various tricks.

The point being: this needs to be approached in a organic style where you reuse what you can while continuing to grow and evolve with the options available in the marketplace.

Many options do exist, and being flexible is the key to making such system work. At times this means using several systems that over time simplify down to a single system. At times this means taking an original system and adding new side systems to the mix. In many respects an organization can take a buffet approach to the solution needed for their enterprise. In the end it's not about the technology, it's about meeting business needs inexpensively and effectively. The web lets organizations merge multiple options, so take advantage of that fact when it's to your benefit. Likewise the web at times will let you consolidate solutions in newer packages at times. The market place currently has many decent integrated packages which should be examined to see if they would save you time, money and effort in your efforts.

Recommendations

Many options exist. No one tool is perfect, in fact no one tool will completely make an organization happy. I have yet to find a tool which smoothly integrates into a business without hassles. This is strange since with a thousand options you think a golden solution would be out there in the market place. However, since a thousand solutions (ok more likely 600 or so valid products) exist that just illustrates the complexities of Collaboration / Knowledge solutions. Personally, I like using Jotspot as it has many powerful features, offers revision and history control, user and role management, and full email integration, RSS feed capability and reasonable price overlays. The biggest problem with Jotspot is the interface is confusing at first to use. This is not a tool you can throw to new users and expect them to learn on their own. I have noticed since Google has purchase Jotspot, the tool is now evolving rapidly and the user interface is improving. Also long term it most likely means it will have additional features such as integration with Google online document and spreadsheet tools.

  • No labels