Как организовать управление знаниями?

Question

[ponaehal]

Вопрос навеян этим постом...
Коллеги, а кто нибудь выработал понятную прозрачную методологию управления знаниями? Причем интересуют не технические особенности организации (jira, redmine, Directum, Bitrix, ECM и т.п.), а именно методологические:

• какие документы хранятся в базе знаний и в каком случае?
  
• каков порядок их подготовки и утверждения?
  
• каковы статусные модели каждого документа?
  
• каковы сроки хранения?
  
• каковы принципы актуализации?
  
• и т.д.
  

Например, в MSDN или в Oracle metalink/OTN есть кучи всяких документов и складывается ощущение того что этот ворох знаний как то упорядочнен: есть такие документы как Wait Paper, Bug Report, .... etc. Когда делаешь поиск по их базе знаний становятся видно все многообразие типов документов: вопросы пользователей, отчеты об ошибках, техническая документация, пользовательская документация и т.п.

Как это хранить (в какой системе) ? - это простой вопрос, а вот как методически организовать, в рамках каких процессов этим управлять - для меня лично вопрос сложный. Хочу спросить: а как у вас с этим обстоят дела? Особенно интересно послушать тех кто знает как это организовано в больших компаниях (несколько десятков-сотен тысяч сотрудников).

Answer 1

[Дмитрий Дарт]

Понятно, что на ваш вопрос нельзя ответить однозначно для всех. Срок хранения - пока технология применяется. Принципы актуализации - смотрите последнее видео, докладчик говорит как в 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

Answer 2

[xmoonlight]

Документация - обычно это WIKI с workflow по рецензированию и утверждению новых и принятию правок для уже созданных страниц документации.

1. Кто-то добавляет новую вики-страницу (или вносит правку) в документацию по конкретному функционалу (проекту, библиотеке и т.д.).
2. Тот, кто составляет (именно эту!) документацию, отправляет документ на проверку своему руководителю.
3. Если всё ок, то он отправляет всем руководителям подразделений, работающих с этой частью документации (или сразу конечным разработчикам, если это его же зона ответственности). Если это руководители - они читают и если всё ок, отправляют своим сотрудникам, которые понимают более детально.
4. После утверждения добавлений и изменений всеми участниками команды и их руководителями (это несколько циклов, начиная с п.1), готовый документ со всеми правками и дополнениями помещается в базу как текущий с переключением версии. Предыдущий (заменённый новым) - помещается в архив.
5. Рассылается всем участникам (кто работает с этой документаций ) оповещение, что: "документ был обновлён с версии такой-то на версию такую-то, изменения - такие-то, предложенные правки/создал [ФИО сотрудника], документ рецензировали: [ФИО перечень тех, кто участвовал в рецензировании], утвердили: [ФИО перечень тех, кто согласился с конечной/опубликованной версией документа].

Каждый документ - это своя сфера/область знаний и зона ответственности.
За каждой сферой/областью знаний - закреплено своё подразделение.
За каждой зоной ответственности - закреплены определённые люди (и их руководители).

На протяжении рабочего процесса/цикла к каждому документу может изменяться доступ сотрудников/подразделений и, при этом процессе, ветка с этим документом либо появляется в документации у конкретного сотрудника, либо убирается (при снятии доступа).

Т.е. для каждого сотрудника - уникальный набор документации согласно его должности и рабочему процессу на данный момент времени.

Answer 3

[ponaehal]

Ребят, спасибо за ответы, подчерпнул много полезного, но вопрос, ИМХО, несколько шире...
Да, конечно есть вопросы и в ИТ, например:
Вы разработали ТЗ(BRD/SRS/ЛюбуюДругуюБумагу) на какой то функционал, отдали в разработку, реализовали, через полгода нужно внести изменения, что вы делаете: вносите изменения в существующий документ -ТЗ? делаете новое ТЗ (касающееся только изменений)? просто завешиваете таск в соответствующей системе? Как потом это все увязываете вместе?
А может Вы вообще принципиально не пишите ТЗ, считая что достаточно сделать Vision/концепцию, согласовать его с бизнесом и пофиг на будущие поколения разработчиков - почитают Vision + залезут в код и разберутся. Это ведь тоже подход, т.к. у любых знаний есть цена: иногда дешевле/быстрее восстановить знания по коду чем прочесть и понять документ.
А есть еще куча документов (или иных элементов знаний, типа wiki): схемы процессов, архитектурные артефакты для каждого из них свой порядок работы (что то регулярно обновляем, что то оставляем как есть на веки вечные)
А некоторые знания возможно нет смысла сохранять в виде документа, а проще получить из какого то инструмента автоматизиции при необходимости, например: топология компьютерной сети, схема модели данных в БД и т.д. Наверное порядок работы с такими знаниями тоже должен быть определен (или не должен?) и понятен тем кому эти данные могут понадобиться...
И так далее....

А теперь, если ко всему вышесказанному добавить вопросы иных подразделений компании:

• позиции по конкретным вопросам для юристов;
  
• правила расчетов чего-нибудь для бухгалетров;
  
• 500 миллионов правильных ответов на вопросы для сотрудников клиентской службы/контактцентра
  
• и т.д.
  

Я себе это вижу как единую "номенклатуру дел" в которой определены все элементы знаний в организации в виде таких артефактов (намеренно не употребляю слово "докумнетов") как:

• Регламент процесса;
  
• Схема процесса;
  
• Тикет/заявка/ТЗ/BRD/SRS/ЛюбаяДругаяБумага на разработку;
  
• Топология сети;
  
• Диаграмма потоков данных между системами;
  
• Инструкция пользователя;
  
• Должностная инструкция;
  
• Позиция по юридическому вопросу;
  
• Перечень часто задаваемых вопросов для специалистов контакт центра;
  
• и т.п.
  

По каждому артефакту определена форма (в т.ч. в каких то случаях это может быть wiki, инф.система, файл или плакат на бумаге), порядок его создания, обновления, хранения, удаления, интересанты, связи с бизнес-процессами компании, связи с информационными системами и т.п.
А потом это как то увязано с реальной жизнью. Не остается на бумаге, а становится живым документом/процессом/порядком.

Понятно, что такие вопросы возникают обычно в процессе взросления компании... Если в компании несколько сотен человек возможно это все будет как "из пушки по воробьям", но для компаний с тысячами сотрудников это становится жизненно-необходимым.

Хочу понять насколько мое видение утопично, встречался ли кто-нибудь с подобными проблемами? Как решали?

Есть даже ГОСТ на эту тему.
А вот любопытная работа из жизни (правда не знаю насколько можно доверять источнику)

Comments

[xmoonlight]

Вы свалили всё в кучу!
Каждый документ - это своя сфера/область знаний и зона ответственности.
За каждой сферой/областью знаний - закреплено своё подразделение.
За каждой зоной ответственности - закреплены определённые люди (и их руководители).

На протяжении рабочего процесса/цикла к каждому документу может изменяться доступ сотрудников/подразделений и, при этом процессе, ветка с этим документом либо появляется в документации у конкретного сотрудника, либо убирается (при снятии доступа).

Т.е. для каждого сотрудника - уникальный набор документации согласно его должности и рабочему процессу на данный момент времени.

[ponaehal]

Полностью с Вами согласен... А какую мысль Вы хотели донести?