Комментарии 7
Цимус :)
Какая-то смесь из: Доска со стикерами в офисе, vTeams, TechTalks, Notion, Confluence, ReadMe, JIRA, глоссарий и т.п. Это все и есть «базы знаний»? Скорее «болото знаний».
Видимо корпоративная база знаний – это все же одна ИТ-система, где лежит «все», хотя бы частично в виде ссылок туда, где указаны подробности.
И это не какая-то wiki, т.к. там поиск и анализ информации недостаточен: технологии wiki – как и любой другой «базы данных» (не путать с «базой знаний») – работают с данными, а не знаниями.
База знаний компании – это как минимум корпоративная semantic wiki (linked data, triple store, knowledge graph и т.п.).
У команды в голове нет целостной картинки, но уже не просто бизнес-процессов, а целого IT-ландшафта — и нет доверия к базе знаний.
Где (и как) у Вас хранятся знания о процессах и о «целом ИТ-ландшафте» и как формируется целостная картинка, где такая картинка фиксируется?
Ваше мнение понятно, но я знаю успешные компании, которые ведут все звои знания в Notion. На мой взгляд, все зависит от компании: масштаба, культуры и ценностей. База знаний - это про процессы, а не только про конкретные инструменты. И более того в компаниях - это более одного инструмента.
Безусловно semantic wiki - это хорошо, но какая стоимость внедрения и поджержки такой базы? И для каких именно целей ее применяете?
На данный момент все знания хранятся в Confluence. Не самый лучший и удобнвй инструмент. Сейчас ведем работы, чтобы многое было автоматизированно. Но об этом расскажем тогда, когда будут конкретные результаты.
На данный момент все знания хранятся в Confluence.
Может быть тогда так и говорить, что храним данные о процессах и таких-то еще артефактах в простой (классической) wiki с названием Confluence, а не в системе с громким названием "база знаний"?
Можете хотя бы рассказать как представлена информация о процессах в компании? Есть ли дерево процессов, паспортизация процессов, верхнеуровневые схемы процессов, RACI и т.п.?
Скриншотик бы, можно обезличенный, т.е. "пахнет" ли BPMом, раз речь у Вас про процессы? А то, конкретики на эту тему не нашел в Вашем повествовании.
И более того в компаниях - это более одного инструмента.
Вы про "зоопарк" несвязанных систем?
Безусловно semantic wiki - это хорошо, ... И для каких именно целей ее применяете?
Как настоящую и единую (централизованную) "базу знаний" компании. В прямом (истинном) понимании этого термина. Тут конечно можно затеять философский спор "данные-информация-знания", но вроде как "linked data, triple store, knowledge graph и т.п." дают конкретику - практику работы именно со знаниями, а не с чем-то выдаваемом за "знания".
Введение в семантическое моделирование процессов см. Semantic BPM. Онтологическое моделирование верхнеуровневых процессов. VAD
Про "семантический сахар" в BPM (в концепции настоящей базы знаний о процессах, как это например реализовано в ARIS).
Статья не про то, как организовано хранение знаний в компании, а в целом про проблематику того, как отсутствие процессов передачи знаний и их хранение в каком-то виде влияет на организационные процессы. И тут собран не только опыт нашей компании: я задавала сообществу тимлидов вопрос, с какими проблемами они сталкивались и к чему это приводило. Тут собирательный образ.
Можете хотя бы рассказать как представлена информация о процессах в компании? Есть ли дерево процессов, паспортизация процессов, верхнеуровневые схемы процессов, RACI и т.п.?
Скриншотик бы, можно обезличенный, т.е. "пахнет" ли BPMом, раз речь у Вас про процессы? А то, конкретики на эту тему не нашел в Вашем повествовании.
Этот вопрос не относится к данной статье. Рассказ про организацию хранения знаний - это отдельная статья, а не просто комментарий. Но я вижу интерес к этой теме, поэтому подумаем о продолжении.
Как настоящую и единую (централизованную) "базу знаний" компании. В прямом (истинном) понимании этого термина. Тут конечно можно затеять философский спор "данные-информация-знания", но вроде как "linked data, triple store, knowledge graph и т.п." дают конкретику - практику работы именно со знаниями, а не с чем-то выдаваемом за "знания".
Спасибо за ссылки. А как вы храните знания о продуктах, метриках, системах, архитектуре, организационных процессах, проектах, их статусах, командах и т.д.? Много ли пользователей вашей базой знаний? Как часто ее используют? Какой объем такой настоящей базы знаний и как вы его считаете? Как дорого обходится поддержка и актуализация этих знаний, как устроен процесс?
Было бы очень интересно узнать ответы на эти вопросы в виде конкретного практического применения, а не теоретической статьи.
А как вы храните знания о продуктах, метриках, системах, архитектуре, организационных процессах,
По инструментам. Более мощной системы управления знаниями по указанным объектам чем ARIS (BPMS №1), - я не встречал. Конечно инструмент должен грамотно применяться. Для следующего шага "semantic BPM" - время похоже еще не настало.
По концепции. Есть много пробелов в самой концепции BPM, например, в части актуализации данных по процессам: не успеваешь нарисовать, как это уже устарело, т.е. ровно как:
В таком случае Confluence или другую подобную базу будут воспринимать как мусорку. Вы тратите время, чтобы разобраться в этом потоке, но это напрасно.
В этой части хорошо то, что архитектура систем и верхнеуровневые процессы меняются не часто и такие схемы более - менее статичны.
В общем, проблем больше, чем их решений. Только я не нашел в статье конкретики в части подходов к решению. То, что "все плохо" - это и так понятно, но вот конкретно "Что делать?"
Выход тут один: добиваться единого источника информации, чтобы вся команда смотрела в одни статьи, в одни документы.
... нужно обеспечивать сохранность всех документов в случае ухода сотрудника.
это и т.п. не про конкретно "Что делать?", а общие слова - обертки "здравого смысла", т.е. "всегда правильные" фразы капитана Очевидность.
Саша привет! Проблемы похожи на статью «Вам кажется, что с вашей документацией что‑то не так? Вам не кажется», но с другой точки зрения.
База знаний — это не просто документация, а устоявшиеся процессы по передаче знаний друг другу через любые каналы связи.
Отличие между БЗ и документацией видится в том, что первое - это структурированный набор статей с кучей ссылок друг на друга, а второе - просто набор "вордовских" файлов. Если все раскидано по разным каналам, то это точно не БЗ. Задача БЗ как раз наоборот - систематизировать знания из разных источников и кто-то должен этим заниматься.
Как менять — это тема абсолютно другой статьи.
Тоже есть такая мысль, надо собирать материал...
Ставим диагноз по базе знаний: ваш чек-лист по проблемам в процессах