Peer Assist как инструмент для управления знаниями

Мы открываем цикл статей о best practices и полезных инструментах с экспертом Владимиром Бароновым* - автором ряда тренингов по управлению знаниями, за плечами которого многолетний опыт работы с такими компаниями как “ЛУКОЙЛ” и ConocoPhillips.

И первый выпуск посвящен Peer Assistance - теме, казалось бы не имеющей отношения к управлению знаниями, но на самом деле, являющейся важнейшим элементом Knowledge Management.

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

Владимир Баронов*: "Несколько лет назад наткнулся на заметку в блоге Ника Милтона (www.nickmilton.com), написанную им еще в 2009 году, о том, что является самым эффективным инструментом для сохранения знаний. Просто процитирую (выборочно) Ника":

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

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

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

На совещаниях-ликбезах участники не только еще раз проговаривают зоны ответственности, но и определяют их границы. Это дает возможность прочувствовать “красные линии” некоторых “особо чувствительных” руководителей направлений, не любящих, когда кто-то вторгается на “их территорию”. Кроме того, это отличная возможность еще раз обозначить цели проекта, метрики, с помощью которых достижение этих целей будет измеряться, и фактически сформировать для руководителя верхнеуровневый план проекта со всеми необходимыми параметрами.

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

Кирилл Кузнецов**:

“Эталоном Peer Assist я считаю собрания, проводимые А.В. Раковой (главой аппарата Правительства Москвы, заместителя мэра Москвы). Приведу два примера.

Первый – это запуск первого в РФ “Портала открытых данных” (www.data.mos.ru), за который отвечала моя команда. Нам нужно было собрать со всех органов власти Москвы сведения, которыми они располагали, превратить их в наборы дата-сетов для разработчиков IT-решений, среди которых, кстати, были гиганты, например, как Яндекс и Google, и собрать из них сервис городской нормативно-справочной информации (НСИ). Этот сервис затем стал единым поставщиком данных для всех информационных систем Москвы.

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

Были проведены десятки совещаний с министрами, вице-мэрами, на которых выясняли, кто в чем эксперт, кто способен “потянуть” ту или иную задачу, сразу назначались ответственные и точно в определенный срок все отчитывались по исполнению. И не было ни для кого зазорным, включая саму А.Ракову, признаться в некомпетентности в каком-то вопросе и найти эксперта.

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

Второй проект – официальный сайт мэра Москвы www.mos.ru. Тут ситуация почти повторилась, но были нюансы. Срок исполнения проекта был больше, чем в 2 раза, был сложнее и включал в себя огромное количество систем и сервисов.

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

Скорость реализации этих двух проектов была в разы выше, чем у тех, где Peer Assist не применялся”.

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

• Группа, перед которой стоит задача, объясняет суть, предысторию задачи и описывает проблему.
• Приглашенные коллеги изучают проблему и понимают ее природу.
• Затем они изучают возможные подходы к решению задачи и представляют их группе.
• Проектная команда с коллегами совместно обсуждают дальнейшие действия.

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

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

"Вот что написано в документе Aerospace knowledge management toolkit (подготовленном, к слову, при участии ведущих аэрокосмических предприятий мира) по поводу Peer Assist":

“Предлагаемые предварительные условия для использования Peer Assist:

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

Резюмируя, можно сказать, что собирать Peer Assist нужно тогда, когда вопросы определены, задачи понятны, но нужна экспертиза опытных коллег и взгляд со стороны перед принятием решения. При этом, важно, чтобы экономическая выгода от встречи, а значит, и решения, была выше, чем стоимость затраченного участниками времени и ресурсов.

Кстати, чтобы сократить время встречи и число ошибок, можно подготовить или использовать готовые шаблоны Peer Assist.

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

Вопрос в том, организован ли этот процесс в компании?

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

“К управлению знаниями при управлении проектами сейчас мало кто подходит системно, поэтому приведу таблицу про типы знаний в контексте проектов из статьи “Management of project knowledge at various maturity levels in PMO, a theoretical framework” Sokhanvar, S., Matthews, J. и Yarlagadda, P. K. D. V. аж от 2014 года":

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

Кстати, о таком подходе управлении знаниями на примере NASA мы поговорим в следующей публикации. Это интересный пример обеспечения сложнейших проектов самыми актуальными знаниями. NASA удалось выстроить эффективную систему “Обучение до – Обучение в процессе – Обучение после”, о которой написано в книге Криса Коллисона “Учитесь летать”.

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

Об авторах

* Владимир Баронов - генеральный директор и совладелец "КМ Эксперт", генеральный директор "Интеллектуальные сервисные решения".

Более 10 лет руководил подразделением, отвечающим за разработку и внедрение управления знаниями в нефтепереработке и добыче ЛУКОЙЛ.

С 2007 по 2010 работал совместно с Дэном Рантой (Dan Ranta) – Директором по обмену знаниями в ConocoPhillips – одной из ведущих нефтегазовых компаний в части управления знаниями в мире.

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

Является соавтором книг “Автоматизация управления предприятия” и “Информационные технологии и управление предприятием”.

** Кирилл Кузнецов - генеральный директор L2U. Компания является ведущим российским разработчиком программных решений по управлению знаниями для бизнеса и госсектора.

Более 15 лет руководит сложными инфраструктурными проектами по созданию информационных систем в таких областях, как: госуправление; экономика и финансы региона; управление имуществом, ЖКХ, торговлей; цифровой туризм, цифровая культура, цифровизация промышленности и многие другие.

Имеет десятки успешно реализованных IT проектов, награжденных престижными российскими и международными премиями:

• mos.ru;
• Облачная бухгалтерия - централизация учета всех госучреждений Москвы;
• data.mos.ru - первый российский портал открытых данных;
• um.mos.ru - Узнай Москву (навигатор по достопримечательностям Москвы);
• Создание ОЦО РЖД - централизованная бухгалтерия РЖД;
• Автоматизация инвестиционной деятельности РЖД и всех структурных подразделений РЖД.