05.06.20 17:28

Статьи

Автор:

Баронов Владимир

Что должен знать спонсор проекта об управлении знаниями?

Компетенции:
D.10. Управление контентом и знаниями
E.02. Управление проектами и портфелем проектов

 Про управление знаниями в компании вспоминают достаточно редко. Про управление знаниями в проектах компании вспоминают еще реже. А зря, так как грамотное управление знаниями может нанести...

Про управление знаниями в компании вспоминают достаточно редко. Про управление знаниями в проектах компании вспоминают еще реже. А зря, так как грамотное управление знаниями может нанести неоценимую пользу как самому проекту, так и отдельным направлениям деятельности внутри компании. Так как же "продать" идею управления знаниями спонсору проекта?

 


На сайте PMI случайно наткнулся на статью о том, как продавать идею управления знаниями «заинтересованным лицам» в проекте.

Всю пересказывать не буду, только ответ на вопрос «Что должен знать спонсор проекта об управлении знаниями?», — а имено пять принципов управления знаниями. Вот они:

1. Знания в проектах в основном неявные, особенно когда проекты ориентированы на людей. Возможно, полезно отметить, что "многие исследователи, а также многие опытные руководители согласны с тем, что около 80 процентов того, что знает организация, хранится в головах людей, а не является явным. Неявные знания трудно распознать, уловить и, таким образом, эффективно применить. Будьте осторожными, чтобы не податься искушению работать только с явными 20 процентами того, что организация знает только потому, что видит это и оно задокументировано".

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

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

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

5. Эффективные знания нуждаются в собственной Ба. "Ба — японский термин, основное значение которого – общее пространство взаимодействия. Что касается знаний, то Ба – это правильный контекст для создания знаний и поощрение отношений между отдельными лицами, внутри групп, а также внутри и между организациями. Ба может быть физическим (например, офис), виртуальным (например, групповым) и психологическим (например, менталитет)" В проектной среде все происходит не случайно, особенно создание новых знаний. Например, процесс PMBOK® "создать WBS" нуждается в интерактивном Ба, то есть в совместном пространстве для коллективного обсуждения, где команда управления проектами может превратить собственные неявные знания в явные знания проекта за счет диалога, обсуждения коллег, и образного языка, без обязательств срочно выдать рациональный результат (т.е. реальную WBS, документированную в соответствии с принятыми требованиями по управления проектами).

 

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

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

Третий принцип, — он про ценность. Мой учитель по жизни «вбил» в мою голову простую мысль: исправление ошибки, выявленной на этапе проектирования, обходится на порядок дешевле ошибки, выявленной на этапе программирования, и на два порядка дешевле ошибки, выявленной на этапе эксплуатации. Но одно дело, когда об этом забывают программисты, — цена шибок там может быть большой, но не критичной. И совсем другое дело, когда мы забываем об том «на стройке». Мы экономим 5 копеек, режа косты на старте проекта, закупая оборудование на 10 рублей дешевле, т.к. тендер, — и теряем тысячи и миллионы на эксплуатации. В принципе, не наше дело, — за эксплуатацию в компании главный инженер отвечает, а не тендерный комитет.

Извлеченные уроки – вообще непонятное что-то. Многие, если не все их «собирают», но часто дальше «просмотреть файл Excel на старте нового проекта и обсудить подходящие уроки» дело не доходит. И предложение «а давайте мы ключевые уроки будем анализировать в профессиональных сообществах или профильных подразделениях и готовить рекомендации для работы» разбивается об «уроки – только для группы нового проекта, т.к. это секретная информация»…

Ну, и с местом для общения тоже никто спорить не будет. Не зря же мы видим массу предложений по «нетворкингу» как одному из преимуществ разных мероприятий. При этом почему-то вне компании – это нормально. Внутри – будет мешать работе.

И как один из аргументов "необходимости" использования инструментов управления знаниями в проекте, приведу свою собственную мысль: "Плохое управление хорошо проработанным на старте проектом позволяет добиться лучшего результата, чем великолепное управление плохо проработанным проектом".