How to Implement Knowledge Base 2.0 in Harmony: Story of Easy Software

What is Knowledge Base 2.0

It's the perfect way to access a company's knowledge, integrated into Easy Redmine and delivers a powerful toolset to organize and scale documentation, manuals, processes, quality management and other needs to maintain knowledge within an organization.

Read more

How we created it

• What was the challenge: At Easy Software, the amount of internal knowledge to share became too complex for the previous solution. Just a regular set of articles in categories did not cut it anymore.
• What we needed: We were looking for a specialized application, tied as closely to Easy Redmine as possible. It definitely must be open-source because we support it and Easy Redmine itself is open-source software.
• Which solution we selected: BlueSpice fits the definition perfectly. It is an open-source solution, a specialized wiki tool, with complex adaptability and integration with Easy Redmine.

How the migration took place

We already had existing data in our previous Knowledge Base. We wanted to transfer much of it into the new solution. See which seven steps we have taken:

1. Clean up data in the original Knowledge Base – start before the migration. We recommend sorting all articles from „last updated“ date and go from oldest.

• You will find that many articles from the top can simply be deleted
• Others you put into a specific category called “for review” – you will update them later
• Some can be updated immediately
• The rest can stay as is

Two more tips:

• If more people are going to be reviewing the articles, it may be a good idea to somehow tag them or set a custom field – for example, “Reviewed”.
• Check also the titles of the articles. If they contain problematic symbols, they may cause issues during the migration. Here are some tips on mediawiki.org about page titles and Legal Title Chars.

Read more

2. Install Knowledge Base 2.0 – technical delivery of the feature. Since we are running on Easy Cloud, it was done almost automatically

3. Do some test migrations – we were not sure about the outcome, so we did a testing migration

• We checked page titles, content formatting (headers, paragraphs, links, and images) and categories
• We checked how long it would take (we had 900+ articles to migrate)
• We made necessary changes in the content of the original Knowledge Base based on our findings from the test migration
• We “refreshed” the Knowledge Base 2.0 application – removed all data

4. Information to our users

• We informed them about the date of production migration = after this time, the primary knowledge source is Knowledge Base 2.0. After this time, users will have only read-only access to the original articles (just for reference and comparison) how they look now and before
• We held a few rounds of user training and admin skill-ups

5. Production import

• The day came when we would click the button and the migration was run
• After our initial check, we lowered the permissions for all roles in the original Knowledge Base – to read-only mode

See migration process

6. Internal support

• We designated some colleagues and a channel in Microsoft Teams where our users could ask any questions about the functioning of Knowledge Base 2.0
• Some issues after migration have been found in production. Since we still had the original one active, we were able to solve each issue accordingly

7. Disable original Knowledge Base

• After about 6 weeks, the internal support requests faded away
• We disabled original Knowledge Base from our Easy Redmine application
• We do recommend making a backup before uninstalling the plugin

How the company accepted a change

Every change in an organization takes some time to be fully accepted. The beginnings are the hardest, which is why we have to keep reminding our users the benefits of the new system.

In the case of Knowledge Base 2.0 and the obvious one is if you don't know something, try searching first (lightbulb in the sidebar). You will see results not only in the form of the title of the article (as in the original Knowledge Base), but also in the actual content of the pages on first glance => there is a good chance that you will receive an answer without having to go anywhere else.

When user simply and quickly finds desired knowledge from others, they are more inclined to share their knowledge to those others, to return the favour and feeling.

How the implementation proceeded

Categories

They were imported from the original Knowledge Base, which is great. But the structure (categories and subcategories) could not technically be imported. The first thing we did was to review the categories, into which the pages are organized

We started with 3 main “dimensions” of categories:

• Audience – for whom is the page most useful – multiple options are allowed like
• Sales
• Development
• Marketing
• Everyone
• Document type – what kind of knowledge is shared. Eventually, every type will have its own template, so they will all look standardized. Best practice dictates that each page should only have one document type.
• Policy
• How-to
• Process
• Training notes and recordings
• Subject – what is the page about. This structure may go deeper, since there are lots of topics in the company. Adding page into a Subject category is voluntary – not required, if there no suitable category exists.
• Product
• The core features
• Resource management
• Help Desk
• Agile board
• Infrastructure
• Cloud
• Server
• Hybrid solution
• Internal IT
• Teams
• Outlook
• Hardware
• Shared HW
• Individual HW

Since every editor can create new categories, we make monthly revisions so that too many unclear of single use categories were not created, a sort of tidying up the structure so it doesn't go wild.

Navigation pages

It is critical that users can navigate the new application well. A natural item for navigation is the main menu, which is partly customizable. A useful additional option is the homepage, which welcomes the readers, links to the article about best practices for Knowledge Base 2.0 and links to pages dedicated to departments in our company.

By clicking e.g., on Marketing, the user will be directed to the index of Marketing pages to browse through. It also contains additional information that is relevant purely to that department.

We are considering using navigation pages for other sorting criteria (such as Product info or General Company policies).

One step at a time

Once you set your categories and your navigation pages, users are already able to work in it. It may seem a bit messy from the start, which why we have a few designated administrators, who oversee that some order is kept.

We have been using Knowledge Base 2.0 for a couple of months now, and we are still only starting. We realize that we are far from an ideal state of perfectly organized and standardized wiki that all users (regardless of experience) know by heart.

We believe that growing the Knowledge base gradually, organically, by your engaged users ultimately to better adoption, than if we would spend months preparing a system, that our users would have to study hard to understand.

Our recommendation is to closely observe how users are using it and make small incremental steps toward implementing more precise organizational configurations such as page templates, rules of typography, etc. Every step that even slightly complicates the use of Knowledge Base for the greater good of your organization should be accompanied by an explanation of how it benefits everyone concerned.

Conclusion

We at Easy Software finished the migration and implementation process and now it's your turn. By following these tips above and taking inspiration, any company can implement a new Knowledge Base 2.0 that meets their unique needs and keep their know-know safe.

Try it free