Как организовать управление знаниями?
Понятно, что на ваш вопрос нельзя ответить однозначно для всех. Срок хранения - пока технология применяется. Принципы актуализации - смотрите последнее видео, докладчик говорит как в Badoo актуализируют.
В целом, я думаю, эти 3 видео в комплексе выстроят у вас довольно чёткую картину:
Управление знаниями: какие документы нужны и что в них фиксировать
https://www.youtube.com/watch?v=Wt2mXVlRWQ8
Как организовать систему обучения в отделе технической поддержки
https://www.youtube.com/watch?v=E2XACp1B_yA
Добро пожаловать на борт: вводим новичков в строй
https://www.youtube.com/watch?v=GJZbzEME_og
Ребят, спасибо за ответы, подчерпнул много полезного, но вопрос, ИМХО, несколько шире... 
Да, конечно есть вопросы и в ИТ, например:
Вы разработали ТЗ(BRD/SRS/ЛюбуюДругуюБумагу) на какой то функционал, отдали в разработку, реализовали, через полгода нужно внести изменения, что вы делаете: вносите изменения в существующий документ -ТЗ? делаете новое ТЗ (касающееся только изменений)? просто завешиваете таск в соответствующей системе? Как потом это все увязываете вместе?
А может Вы вообще принципиально не пишите ТЗ, считая что достаточно сделать Vision/концепцию, согласовать его с бизнесом и пофиг на будущие поколения разработчиков - почитают Vision + залезут в код и разберутся. Это ведь тоже подход, т.к. у любых знаний есть цена: иногда дешевле/быстрее восстановить знания по коду чем прочесть и понять документ.  
А есть еще куча документов (или иных элементов знаний, типа wiki): схемы процессов, архитектурные артефакты для каждого из них свой порядок работы (что то регулярно обновляем, что то оставляем как есть на веки вечные) 
А некоторые знания возможно нет смысла сохранять в виде документа, а проще получить из какого то инструмента автоматизиции при необходимости, например: топология компьютерной сети, схема модели данных в БД и т.д.  Наверное порядок работы с такими знаниями тоже должен быть определен (или не должен?) и понятен тем кому эти данные могут понадобиться...
И так далее....
А теперь, если ко всему вышесказанному добавить вопросы иных подразделений компании:позиции по конкретным вопросам для юристов;правила расчетов чего-нибудь для бухгалетров;500 миллионов правильных ответов на вопросы для сотрудников клиентской службы/контактцентраи т.д.
Я себе это вижу как единую "номенклатуру дел" в которой определены все элементы знаний в организации в виде таких артефактов (намеренно не употребляю слово "докумнетов") как:Регламент процесса;Схема процесса;Тикет/заявка/ТЗ/BRD/SRS/ЛюбаяДругаяБумага на разработку;Топология сети;Диаграмма потоков данных между системами;Инструкция пользователя;Должностная инструкция;Позиция по юридическому вопросу;Перечень часто задаваемых вопросов для специалистов контакт центра;и т.п.
По каждому артефакту определена форма (в т.ч. в каких то случаях это может быть wiki, инф.система, файл или плакат на бумаге), порядок его создания, обновления, хранения, удаления, интересанты, связи с бизнес-процессами компании, связи с информационными системами и т.п.
А потом это как то увязано с реальной жизнью. Не остается на бумаге, а становится живым документом/процессом/порядком.
Понятно, что такие вопросы возникают обычно в процессе взросления компании... Если в компании несколько сотен человек возможно это все будет как "из пушки по воробьям", но для компаний с тысячами сотрудников это становится жизненно-необходимым. Хочу понять насколько мое видение утопично, встречался ли кто-нибудь с подобными проблемами? Как решали?
Есть даже ГОСТ на эту тему.
А вот любопытная работа из жизни (правда не знаю насколько можно доверять источнику)