Портал №1 по управлению цифровыми
и информационными технологиями

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

начало ЭКЗ_origТот факт, что наша компания является компанией полного производственного цикла, позволяет на собственном, личном примере наглядно продемонстрировать всю пользу от процесса управления знаниями.

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

Для успешной работы в качестве разработчика/технического эксперта на настоящем этапе мне требуется следующая информация:

  1. Проектная документация:
  • Актуальный проектный план, для понимания охвата и вех;
  • Список текущих проектных задач, для оперативного планирования и координации работ;
  • Список открытых вопросов, для планирования коммуникаций и мероприятий по их разрешению;
  • Список контактных лиц.
  1. Процессная и техническая документация
  • Процессное описание решения, для понимание задач в контексте "user story";
  • Технические требования к решению, интефейсам, логике, для корректного технического проектирования и разработки;
  • Описания внешних источников данных и информация об их владельцах, для разработки интеграций и согласования форматов и способа обмена.
  1. Стандарты:
  • Шаблоны документов, инструкций;
  • Стандарт разработчика: логи, правила оформления кода и описания объектов, для обеспечения качества разработки и поддержки решения;
  • Вендорская документация для разработчика;
  • Внутренний стандарт оформления технических и процессных документов.
  1. Опыт коллег:
  • Известные ошибки, обнаруженные при эксплуатации установенной версии платформы и при её обновлении до более свeжих версий;
  • Шаблоны технических решений и база know-how от наших разработчиков,
  • Результаты разработки и запуска решений с множественными интеграциями. 

Результатами моего труда, как разработчика и консультанта в этом проекте будут:

  • Пользовательская документация;
  • Обучающие материалы и презентации;
  • Документация по внедрению и мероприятиям в ходе опытно-промышленной эксплуатации;
  • Технический проект и описание технического решения;
  • Описание интеграционных механизмов, процедур их эксплуатации и поддержки;
  • Эксплуатационная документация для коллег из поддержки и известные ошибки по результатам внедрения;
  • Прототип/конфигурация технического решения.

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

Мы, как потребители, должны:

  1. знать, что нужная нам информация есть (её бережно хранят и поддерживают её актуальность); 
  2. иметь возможность быстро найти нужное;
  3. своевременно использовать найденное, что в действительности самое важное. 

Закончу эту иллюстрацию провокативным тезисом:

В принципе, это все что вам нужно знать про пользу от управления знаниями.

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

Какой вариант реализации информационой архитектуры вам кажется более удобным в вашей работе: Wiki, "бездонный" поиск ala Google, теги, соцсети, Twitter 🙂 ? 

Комментариев: 2

  • Александр Васильев

    У меня есть мнение – что управление знаниями не так уж зависит от интерфейса, а гораздо больше от того какая мотивация заполнять знания – знаниями.

     

    Внимание вопрос – как оценить экономическую пользу от внедрения управления знаниями. Процедура достаточно затратная, а эффект будет в длительной перспективе и плохо считаемый. 

    • Общаясь со специалистами очень часто можно наблюдать артефакты которые они создают для того, чтобы сделать свою работу легче, а иногда эти объекты создаются для коллег из смежных подразделений. По этому, на основании наблюдений не могу сказать, что с созданием знаний есть какая-то фундаментальная сложность. А вот публикация и распространение этих знаний иногда требует дополнительных интерфейсов или легкого мотивирования.

      Управление знаниями, как и любой другой поддерживающий процесс не работает через “push”. Заставлять “создавать знания” бессмысленно. Но, в тот момент, когда появляется спрос на знания, “pull”, тогда процесс и начинает свое движение.

      Экономическую пользу, на ОЧЕНЬ грубом уровне, могут помочь рассчитать менеджеры по персоналу, т.к. этим инструментом мы по большому счету поддерживаем компетентность сотрудиков и обеспечиваем способность наиболее рациональным образом выполнять свои обязанности в нашей организации, с нашей инфраструктурой и нашими процессами, что важно. Сколько стоит найти специалиста, сколько будет длиться и стоить его интеграция в процессы компании, до момента, когда он будет приносить действительную пользу/прибыль – можно посчитать. 

      Если говорить об индивидуальных результатах этого процесса управления знаниями, то не надо забывать, что отдельные мероприятия по налаживанию информационного обмена чаще всего направлены на уменьшение временных затрат, ускорение рутинных процедур, экономию времени специалистов. А это вполне измеримые вещи, если если есть статистика фактов потребления информации, её повторного использования. Важно видеть этот “pull”, запрос на информацию у заинтересованных сторон и способствовать его удовлетворению – именно этим и нужно заниматься в первую очередь.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM