KB process question.

[Berto]

Hi everyone!
I'm developing a Knowledge Base Creation and Maintenance process from scratch, I just identify some key points like Acquisition/Creation, Management, Reuse, Publishing/Reporting, Maintenance, etc., etc.
I got to this point but I'm stuck now. Could somebody give me a guide or recommendation?

Thanks in advance!!!!

Diego

[Guerino1]

Hello Diego,

What kind of things are you categorizing as knowledge?

- Related FAQs?
- Related Notes?
- Related Documents?
- Related Glossary Terms?
- Related Content?
- Related Incidents?
- Related Problems?
- Related Changes?
- Related Risks?
- Related Projects?
- Related Tasks?
- Related Phone Calls?
- Related Products?
- Related Releases?
- Related Services?
- Etc.

Technically, your KB should have a great deal of highly categorized and easy to find information that covers many different things. Is there something specific you're trying to accomplish?

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[Berto]

Frank,
I'm trying to create a process related to Problem Management. in a future stage this process should be used by the Problem Administrator, Coordinators, etc.

This should be a guide....

Thanks !!

Diego

[Guerino1]

Hello Diego,

One thing to keep in mind is that you want to capture any and all data associated with a Problem, throughout its entire lifecycle (from its inception to the day it's closed). This will build a tremendous amount of knowledge around the given Problem, itself.

Another thing is to ensure that you do the same, consistently, for all other Problems. This will allow you to build up metrics around key attributes and data associated with your Problem inventory.

Another thing is to ensure that all Problem related data is in one place/system, so that you can look across all Problem knowledge.

A solid way to build out your KB is to simply ensure a solid process that fills in all key data points for each and every Problem ticket that is entered. Over time, you will find that there will be a great deal of useful information that you will capture. Your KB content will build up, organically.

However, you will also need to capture data/information that is not directly associated with attributes on the Problem ticket, itself, such as Documentation, FAQs, Content, Product Information, Release Information, Change Information, Configuration Item Information, Project Information, and much, much more. The only way you will be able to accomplish this, successfully, is through couplings/integrations to and from other systems or by having a single system that collapses all such information into one database, where all relationships between such data are automatically maintained. The former is expensive and time consuming. The latter will change how your enterprise works together.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[Berto]

Frank, thank you for your answers.
Maybe i should be focused in a basic workflow. From A to B, from B to C or D, etc.. There are so many approaches to do it.

Thank you!

Diego.

[Guerino1]

Hi Berto,

You're right, there are many different approaches. I personally like the "lifecycle" approach. The more details you capture about a trackable entity's lifecycle, the better knowledge you will built, about that item, over time. For example, I can track details about "one specific Problem", from the time it is logged until the time it is deleted from the tracking system (you may never delete it to keep history for knowledge retention).

The more consistent your processes are about tracking the same details on every "like" trackable item, the more knowledge you will build on the entire repository of that trackable item type. For example, the more consistent you are about how you track details about "every Problem", the more powerful your knowledge base will become, across all records of that specific type (Problems in this case).

Anyhow, I'm glad I could be of assistance.

Best of luck in your efforts.

Frank Guerino, CEO
TraverseIT
On-Demand ITIL