Posted on 2013-08-12 08:00:00
Tags: KCS, Rant, Riverbed
Riverbed Support has redesigned its Knowledge Base system to confirm to the Knowledge Centered Support methodology (KCS). Was the earlier system mostly crap, the current implementation isn't really my style neither...
There are several issues which need to be looked at with regarding to this KCS system:
The old system was based on the Salesforce based Solutions software. It had a HTML-only capable editor, didn't have revision support or a built-in lifecycle enforcement. It didn't differentiate between various sections in the KB article (issue, error, solution, notes) and metadata was not available. And the data was available via the Salesforce SQL interface.
The successful workflow was as follows: A TAC engineer enters a KB article, it gets approved by staff-engineering for technical review, it gets published and announced. Sounds simple, but often took a long time: staff-engineering was the bottleneck, and the system didn't allow other people to help out. So, a lot of good data stayed hidden and unavailable.
Come spring 2011 (Late 2011, considering I'm on the Southern hemisphere) and I get a call from the current publishing team asking for what I see to be needed in a good KB system. I explained them about the system features and the workflow:
The system needs to support revisions, needs to presentation-layer independent editor (like a Wiki), differentiation between the KB article section, needs to have proper metadata like tags, validity-dates, support a lifecycle enforcement. And there should be an API to the data for enable further development (announcements, RSS feeds, off-line access etc).
Besides the normal stages (new, working, ready, reviewed, published, announcement), the workflow should not be linked to the position within Riverbed Support.
After months of silence later, we are introduced to the new KCS system. It is based on InQuira and has nearly all the workflow features (was missing the announcement features) but oh boy, does it suck with regarding to the editor...
The editor of the InQuira system, is HTML based, which means that the various copy+pastes from other sources import a large amount of HTML code with styles not supported or not desired in the article. Also no abstraction is possible, meaning that the location of images, links to other KB articles and so on are done in the HTML code and making it impossible to make a change to the greater system because it would mean the editing of hundreds of KB articles. Revisioning is based on the HTML code only and not on the meta-data. The API implemented in the InQuira system is suitable for searching, but not for data extraction. The user interface only supports the manipulation of a single KB article, if you open multiple articles all changes will be done to the one opened last. And two people editing the same article, one in the metadata and one in the text, gives a very interesting result.
In the workflow the technical review has been removed, articles can go directly into the published state. Fixing issues like markup, style and content) will need to be done afterwards. However, there are no announcements neither, so you will not know if there is anything new added. Or anything duplicate. Or anything incorrect...
So, is it an improvement? Yes. No. Half. It is better than what it was. But there is still a lot to be improved before I would call it a success.