How to organize knowledge management?

Question

Knowledge base

The question was inspired by this post ...
Colleagues, has anyone developed an understandable transparent knowledge management methodology? Moreover, they are not interested in the technical features of the organization (jira, redmine, Directum, Bitrix, ECM, etc.), but in methodological ones:

• what documents are stored in the knowledge base and in what case?
  
• What is the procedure for their preparation and approval?
  
• what are the status models of each document?
  
• what are the storage periods?
  
• what are the principles of updating?
  
• etc.
  

For example, in MSDN or in Oracle metalink/OTN there are heaps of all sorts of documents and one gets the feeling that this heap of knowledge is somehow orderly: there are such documents as Wait Paper, Bug Report, .... etc. When you do a search through their knowledge base, you can see all the variety of types of documents: user questions, error reports, technical documentation, user documentation, etc.
How to store it (in what system)? - this is a simple question, but how to methodically organize it, within what processes to manage it - for me personally, the question is difficult. I want to ask: how do you deal with this? It is especially interesting to listen to those who know how it is organized in large companies (several tens to hundreds of thousands of employees).

Answer 1

It is clear that your question cannot be answered unambiguously for everyone. Shelf life - as long as the technology is applied. Principles of updating - watch the last video, the speaker talks about how they update in Badoo.
In general, I think these 3 videos together will build a fairly clear picture for you:
Knowledge management: what documents are needed and what should be recorded in them
https://www.youtube.com/watch?v=Wt2mXVlRWQ8
How to organize a training system in a department technical support
https://www.youtube.com/watch?v=E2XACp1B_yA
Welcome aboard: getting newbies up and running
https://www.youtube.com/watch?v=GJZbzEME_og

Answer 2

Documentation - usually a WIKI with a workflow for reviewing and approving new and accepting edits for already created documentation pages.
1. Someone adds a new wiki page (or makes changes) to the documentation for a specific feature (project, library, etc.).
2. The one who draws up (exactly this!) Documentation sends the document for verification to his manager.
3. If everything is OK, then he sends it to all the heads of departments working with this part of the documentation (or immediately to the final developers, if this is his own area of ​​responsibility). If these are managers, they read and if everything is ok, they send it to their employees, who understand in more detail.
4. After the approval of the additions and changes by all team members and their leaders (this is a few cycles, starting from step 1), the finished document with all the edits and additions is placed in the database as the current one with version switching. The previous one (replaced by the new one) is placed in the archive.
5. A notification is sent to all participants (who work with this documentation) that: "the document was updated from version such and such to version such and such, changes are such and such, proposed edits / created by [employee's full name], the document was reviewed: [ Full name, list of those who participated in the review], approved: [Name of the list of those who agreed with the final / published version of the document].
Each document is its own area / field of knowledge and area of ​​responsibility.
Each field / field of knowledge has its own unit .
For each area of ​​responsibility - certain people (and their leaders) are assigned.
During the workflow/cycle, the access of employees/divisions to each document can change and, during this process, the branch with this document either appears in the documentation of a specific employee, or is removed (when access is removed).
Those. for each employee - a unique set of documentation according to his position and workflow at a given time.

Answer 3

Guys, thanks for the answers, I learned a lot of useful things, but the question, IMHO, is somewhat wider ...
Yes, of course there are questions in IT, for example:
You developed a technical specification (BRD / SRS / Any Other Paper) for some kind of functionality, sent it to development, implemented, in six months you need to make changes, what are you doing: make changes to the existing document - TK? making a new TOR (only changes)? just hang up the task in the corresponding system? How do you tie it all together then?
Or maybe you don’t write technical specifications at all, considering that it’s enough to make a Vision / concept, coordinate it with the business and don’t care about future generations of developers - they read Vision + get into the code and figure it out. This is also an approach, because any knowledge has a price: sometimes it is cheaper/faster to recover knowledge from the code than to read and understand the document.
And there are also a bunch of documents (or other elements of knowledge, such as a wiki): process diagrams, architectural artifacts for each of them have their own work order (we update something regularly, we leave something as it is forever)
And it may not make sense to save some knowledge in the form of a document, but it is easier to get it from some kind of automation tool if necessary, for example: computer network topology, data model diagram in a database, etc. Probably, the procedure for working with such knowledge should also be defined (or should it not?) and understandable to those who may need this data ...
And so on ....
And now, if we add questions from other departments of the company to all of the above:
I see this for myself as a single "nomenclature of cases" in which all elements of knowledge in the organization are defined in the form of such artifacts (I deliberately do not use the word "documents") as:
For each artifact, a form is defined (including in some cases it can be a wiki, an information system, a file or a poster on paper), the order of its creation, updating, storage, deletion, interested parties, connections with the company's business processes, communications with information systems, etc.
And then it kind of connects with real life. It does not remain on paper, but becomes a living document/process/order.
It is clear that such questions usually arise in the process of a company's maturation... If a company has several hundred people, it will probably all be like a cannonball, but for companies with thousands of employees, this becomes vital.
There is even GOST on this topic.
And here is a curious work from life (although I don’t know how much you can trust the source)