Сохранить и приумножить. Про базы знаний и связанные тонкости

Логотип компании
Сохранить и приумножить. Про базы знаний и связанные тонкости
Основа современного мира — скорость. Если компания хочет остаться на плаву или паче чаяния быть в лидерах — она вынуждена принимать вызов высокого темпа. В противном случае останется на заведомо проигрышных позициях.

Основа современного мира — скорость. Причем во всем. В бизнесе, в жизни, в информации. Иногда скорость ослепляет и завораживает. Иногда приводит к победе. При этом скорость требует особой подготовки. И если компания хочет остаться на плаву или паче чаяния быть в лидерах — она вынуждена принимать вызов высокого темпа. В противном случае останется на заведомо проигрышных позициях.

Про знания и навыки

Как известно, в любой компании есть активы материальные, а есть — нематериальные. В разных компаниях по-разному, но почти у всех есть то, что нужно сохранить любой ценой, а именно знания. Сразу же хочу уточнить: знания не равны инструкциям и регламентам. Знания — это то, что «в головах», и только так. Любая «оцифровка» знаний ведет к их деградации в определенной степени. Почему? Да потому, что в прикладном смысле знания не только «знать как», но и «уметь применять». То есть знание в контексте данной статьи — это теоретическая база, сформированный навык и четкое понимание взаимосвязей и последствий того или иного действия.

Как знания связаны со скоростью? Очень просто. Любая компания растет из прошлого, живет в настоящем и смотрит в будущее. Ведь без прошлого нет будущего. Знания о прошлом (будь то технологии, процессы, отношения) неизбежно оказывают влияние на настоящее и будущее. Таким образом, сохранение знаний и навыков их использования — в некоем смысле сверхзадача любой организации.

Приведу простой пример на «знания и навыки». Администратор информационной системы знает, как завести пользователя в систему. Это знание не равно навыку заведения. Возможно, что после заведения где-то в особой форме требуется активировать пользователя, или разблокировать, или выполнить некие иные действия. Возможно, в процессе заведения предъявляются особые требования, в частности, пароль должен быть введен только латинскими буквами или, например, фамилия должна содержать не менее двух символов и т. д. Когда администратор заводит первого пользователя, он почти наверняка «налетит» на одну из особенностей. Когда заведет сотого, то с большой вероятностью проблем не будет. Потому что, кроме знания «что делать» будет сформированный навык «как делать».

Таким образом, вполне закономерной представляется мысль о том, что для обеспечения нормальной преемственности передавать следует не только знания, но и навыки. Но закономерность мысли не означает простоту реализации! Передача навыков — дело, требующее затрат времени со стороны как того, кому передают, так и того, кто передает. А также усердной работы, «наработки на отказ», набора критической массы прецедентов, достаточной для формирования и фиксирования навыка в опыте.

Поэтому чаще всего применяются «облегченные варианты» — составление материалов, шпаргалок, минимальное обучение, инструктаж, регламентация. Об этом и пойдет речь.

Материалы: эффективно и весомо

Народная мудрость гласит, что лучше иметь что-нибудь, чем совсем ничего. Это в полной мере относится и к корпоративным знаниям: если что-то не записано, то с большой вероятностью спустя какое-то время будет забыто, потеряно либо искажено. Борьба с этим явлением приводит к тому, что начинает составляться документация, в которой описываются различные аспекты, связанные с деятельностью. Это, с одной стороны, правильный путь, а с другой — требующий достаточно вдумчивого подхода. Дело в том, что, приступая к описанию, следует, во-первых, четко определить, что именно мы будем описывать; во-вторых, обозначить приоритеты; в-третьих, установить порядок хранения результатов описания и работы с ними. Сложно? Да. Но если не решить эти вопросы на старте (хотя бы на старте описания, так как зачастую «писать» начинают совсем не тогда же, когда работать), то возникает достаточно высокий риск, что на финише будет получен совсем не тот результат, который планировался.

Рассмотрим синтетический пример. Предположим, есть некий отдел системного администрирования. В силу определенных обстоятельств было принято решение документировать деятельность отдела. Далее, возможно несколько сценариев.

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

· Наиболее негативный сценарий состоит в том, что выдается задание каждому сотруднику описать то, «чем он занимается». И сотрудник честно описывает — каждый в меру своей фантазии. На выходе получается достаточно увлекательный набор сочинений на заданную тему, с минимальной полезной информацией и максимальной степенью «запутки».

Между обоими сценариями может лежать множество других, не менее любопытных вариантов, отличающихся по исполнению и конечному результату, что приводит нас к интересному вопросу: а что вообще отличает хорошую документацию от плохой? Как мне кажется, существенных отличий несколько: во-первых, полнота охвата. Во-вторых, каскадируемая глубина. В-третьих, структура, вытекающая из предыдущих пунктов. В-четвертых, «юзабельность», то есть удобство и понятность документации ее потребителю (для примера: сравните канцеляризмы и живую речь). Отдельно отмечу, что писать хорошую документацию порой бывает достаточно сложно — нужен соответствующий навык, который вырабатывается, конечно... но не сразу. (И время на выработку этого навыка, по хорошему, надо закладывать в общее время создания документов, если нет возможности обойти этот момент, скажем, используя труд команды технических писателей, где есть как «гуру», так и новички в этом нелегком деле.) Кроме того, хорошая документация должна быть нацелена на передачу знаний и по возможности формировать предпосылки к созданию навыков их использования.

Регламент: панацея или бюрократия?

Следующее, что надо упомянуть, говоря о документировании, — регламентация. Регламенты отличаются от обычной документации тем, что представляют собой по сути кросс-функциональную инструкцию, обязательную для исполнения при наступлении определенных условий. Регламент может описывать процесс в целом и устанавливать его метрики (а также зависимость премий от достигнутых значений метрик, например); в отличие от документации регламент фокусируется на сквозных процессах (документация же в основном сконцентрирована на описании всех возможных аспектов работы людей, процессов, технологий, систем). Регламент может (и должен) являться официальным документом, введенным в действие по приказу, который также устанавливает обязательность его исполнения. К тому же регламент, в случае его исполнения, дает гарантированный результат. То есть при составлении регламента, в него обычно закладывают эту полезную «фишку» — обеспечение связанности действий и результат. Регламент ради регламента, как правило, никого не интересует. Кроме того, регламент может ссылаться (а может и не ссылаться) на документацию или ее отдельные пункты для раскрытия сути того, что должно быть действительно выполнено. Например, есть документ «Руководство оператора системы АБВ»”, и есть «Регламент прохождения процесса согласования документов с использованием системы АБВ». В регламенте описывается, кто и что должен разместить в системе, кто согласовать и что будет, если согласование не получено или нарушен контрольный срок. В документации описывается, как можно выполнить то, что описывается в регламенте. Таким образом, регламент — это уровень процесса, а документация — уровень системы. (При всей очевидности данного утверждения, периодически сталкиваюсь с тем, что оно не совсем очевидно.)

Актуализация, или Кое-что про жизнь

Вернемся к начальному тезису: вызов современного мира — скорость. Скорость диктует определенные правила игры. Скорость заставляет изменяться мир. А изменения неизбежно сказываются на составляющих мир ячейках, в том числе на отдельных организациях. Для организации же изменение — это в первую очередь измениться внутри, перестроить процессы (что, естественно, влечет за собой и внешние перемены, иначе какой смысл меняться?). Что неизбежно приводит к изменению регламентов, как минимум (с точки зрения айтишника: системы могут оставаться прежними, а вот их использование — изменено). В максимальном же варианте изменяются и системы, как с точки зрения функциональности (никто не мешает изменить состав модулей или изменить функциональность модулей), так и с точки зрения состава (набор систем может измениться ввиду изменившихся требований). Как этот процесс отражается на потребителе, конечном пользователе? В хорошем случае — он становится участником процесса непрерывной адаптации и изменений. В частности, он формирует потребность: исходя из нее, формируется новая архитектура, проводится ее наполнение, архитектура реализуется — и вот уже инициатор получает работающий механизм. (Это очень верхнеуровневая схема, поскольку не учитывает множество важных вех, таких как анализ, согласование требований, формализация и т. д., но в рамках данной статьи важен именно процесс верхнего уровня). Для того чтобы эффективно работать с новой конфигурацией «система–процесс», конечному исполнителю нужны новые знания о том, как теперь работает процесс, как функционирует система и как они взаимодействуют. Это знание формируется и получается в процессе актуализации. Процесс актуализации — это процесс, который охватывает регламентирование, документирование и обучение. На входе процесс получает информацию об изменении — на выходе же представляет обученный персонал. В этом смысле сложно переоценить важность такого процесса: фактически он является «транспортом» по продвижению изменения с уровня принятия решения к пользователю. Следует отметить, что даже при формальном отсутствии процесса, он все равно будет существовать в неявном виде: работа в изменившихся обстоятельствах побудит пользователя получить информацию об изменениях. В противном случае может оказаться, что его работа в принципе бессмысленна или вредна.

Вообще, сложно переоценить важность данного процесса, поскольку вне его контура рассинхронизация может оказаться весьма значительной, особенно в ситуации ступенчатых изменений. Например, может возникнуть ситуация, при которой сотрудник работает с версией процесса N, в то время как актуальной является версия процесса N+3 и готовится — N+4. Если не принять специальных мер, то вместо ожидаемого эффекта от изменения можно налететь на обратный результат, при котором каждый из сотрудников живет в своей версии процесса, и они с трудом сходятся в одной точке.

Минимальные меры противодействия такому явлению и приводят к обсуждаемой теме: заранее подготовленная документация, регламент и своевременное оповещение при всей внешней простоте способны существенно снизить риски рассинхронизации.

Про порталы, базы и сообщества

Все сказанное выше, безусловно, важно. Но для того, чтобы «все взлетело» не хватает одного важного компонента — некой общедоступной системы, в которой бы хранились документы и регламенты. С точки зрения организации это может быть все, что угодно, — от файлового хранилища до специализированных систем и сайтов на порталах. Довольно распространенным явлением является использование wiki-подобных движков: «дешево и сердито». Реже можно встретить промышленные решения, которые реализуют не только задачу хранения знаний, но и управления знаниями (поддержка многоуровневой модели доступа, обеспечение версионности, распределение знаний по сообществам и т. д.). Причем аппетит приходит о время еды, и чем дальше, тем больше требований предъявляется к системе — от просто хранения документов до мощной системы с ролями, доступом, журналированием, средствами коммуникации и т. д.

Кстати, про средства коммуникации. Система управления знаниями наверное по-настоящему начинает жить тогда, когда она не просто хранит в себе документы, регламенты и прочие артефакты, а когда все хранимые артефакты активно обсуждаются, улучшаются, когда выстроена система преемственности — именно с точки зрения передачи навыков, когда можно задать вопрос и получить оперативный и неформальный ответ, не только от кураторов, но и от коллег, глубоко погруженных в процесс. Отдельный вопрос: как достичь такого взаимодействия? Как обеспечить постоянную вовлеченность участников? Ответ кроется в нескольких аспектах: полезности и актуальности размещенных материалов, заинтересованности вовлеченности сотрудников в процесс их генерации и обсуждения (имеется в виду реальное влияние, например, путем внесения и учета предложений, их реализации, не исключая и материальную стимуляцию). Если эти условия выполнены, то можно сказать, что основа для широкого использования системы управления знаниями заложена. Если же они не выполнены, то, скорее всего, система управления знаниями превратится в очередною «подсуконную» систему. В том смысле, что будет она лежать под сукном, не используемая практически никем, кроме, может быть, тех, кому это будет вменено в обязанность по приказу. Фактически речь идет о том, чтобы выстроить «на выходе» не просто базу знаний, а некое профессиональное экспертное сообщество, причем с точки зрения не инструмента, а организации и самоорганизации сотрудников. Прямо скажу: задача непростая, но почетная, так как, возможно, в процессе построения придется менять очень многое, вплоть до корпоративной культуры...

Но это уже совсем другая история.

Опубликовано 29.07.2016