Всім привіт. Після минуло вже півроку, за цей час я встиг виступити ще на двох конференціях та провести лекції на тему управління знаннями у двох великих ІТ-компаніях. Спілкуючись із колегами, я зрозумів, що в ІТ поки що можна говорити про управління знаннями на рівні «новачок», а точніше, просто усвідомити, що управління знаннями потрібне будь-якому підрозділу будь-якої компанії. Сьогодні буде мінімум мого власного досвіду – я хотів би розглянути існуючі міжнародні стандарти в галузі менеджменту знань.
Почнемо, напевно, з найпопулярнішого бренду в галузі стандартизації – ISO. Уявіть собі, існує окремий стандарт, присвячений системам управління знаннями (ISO 30401:2018). Але сьогодні я на ньому б зупинятися не став. Перш ніж розбиратися «як» має виглядати та працювати система управління знаннями, треба домовитися, що вона, у принципі, потрібна.
Візьмемо, наприклад, ISO 9001: 2015 (Quality management systems). Як випливає з назви, це стандарт, присвячений системі управління якістю. Щоб сертифікуватися за цим стандартом, організація повинна забезпечувати прозорість та безперебійність робочих процесів та вироблених продуктів та/або послуг. Іншими словами, сертифікат означає, що у вашій компанії все працює чітко, злагоджено, ви розумієте, які ризики несе поточна організація процесів, знаєте, як контролювати ці ризики, і прагнете їх мінімізувати.
До чого тут управління знаннями? А ось до чого:
7.1.6 Знання організації
Організація повинна визначити знання, необхідні для функціонування її процесів та для досягнення відповідності продукції та послуг.
Знання повинні підтримуватися та бути доступними у необхідному обсязі.
При розгляді змін і тенденцій, що змінюються, організація повинна брати до уваги наявні в неї знання і визначати, яким чином отримати або забезпечити доступ до додаткових знань та їх актуалізації.
ПРИМІТКА 1. Знання організації - це знання, специфічні для організації; в основному отримані на основі досвіду.
Знання – це інформація, яка використовується та якої обмінюються для досягнення цілей організації.
ПРИМІТКА 2. Основою знань організації може бути:
a) внутрішні джерела (наприклад, інтелектуальна власність; знання, отримані з досвіду; висновки, витягнуті з невдалих чи успішних проектів; збирання та обмін недокументованими знаннями та досвідом; результати покращень процесів, продукції та послуг);
b) зовнішні джерела (наприклад, стандарти, наукова спільнота, конференції, знання, отримані від споживачів та зовнішніх постачальників).
І нижче, у додатках:
Вимоги, що стосуються знань організації, були запроваджені з метою:
a) захисту організації від втрати знань, наприклад, через:
- плинності кадрів;
- неможливості отримання та обміну інформацією;
b) стимулювання організації до набуття знань, наприклад, на основі:
- навчання на власному досвіді;
- наставництва;
- бенчмаркінгу.
Отже, стандарт ISO у сфері менеджменту якості стверджує, що з забезпечення якості своєї діяльності підприємство має займатися менеджментом знань. Саме так, безальтернативно «повинно». Інакше немаєконформності, і до побачення. Вже один цей факт хіба що натякає, що це факультативний аспект організації, як до управління знаннями в ІТ часто ставляться, а обов'язкова складова бізнес-процесів.
Понад те, стандарт розповідає, які ризики менеджмент знань покликаний усувати. Насправді вони цілком очевидні.
Давайте уявимо… ні не так – згадайте, будь ласка, ситуацію зі своєї кар'єри, коли вам дуже потрібна була по роботі якась інформація, а її єдиний носій був у цей момент у відпустці/відрядженні, взагалі звільнився з компанії чи просто хворів. Згадали? Я думаю, практично будь-кому з нас доводилося з цим стикатися. Що ви відчували в цей момент?
Якщо через якийсь час керівництво підрозділу розбиратиме зрив термінів проекту, він, звичайно ж, знайде винного і на цьому заспокоїться. Але вам особисто в той момент, коли знання були потрібні, ніяк не допомогло розуміння, що «винний РМ, який поїхав на Балі та не залишив жодних інструкцій на випадок запитань». Безперечно, він винен. Але ваше завдання це вирішити не допоможе.
Якщо знання задокументовані в системі, доступній людям, яким вони можуть знадобитися, то описана «курортна» історія стає практично неможливою. Таким чином, забезпечується безперервність бізнес-процесів, а отже, відпустки, відходи співробітників і той самий горезвісний bus factor підприємству не страшні - якість продукту/сервісу залишиться на своєму звичайному рівні.
Якщо у компанії є майданчик для обміну та зберігання інформації та досвіду, а також сформована культура (звичка) користування цим майданчиком, то співробітникам не доводиться чекати по кілька днів відповіді від колеги (або взагалі кілька днів шукати цього колегу) та ставити через це на hold свої завдання.
Чому говорю про звичку? Тому що мало зробити базу знань, щоби їй почали користуватися. Ми всі звикли шукати відповіді на свої запитання у кути, а інтранет найчастіше у нас асоціюється із заявами на відпустку та дошкою оголошень. У нас немає звички «пошукати інформацію про фреймворки Agile» (наприклад) на інтранеті. Тому навіть якщо в нас в одну секунду з'явиться крута база знань, користуватися нею на наступну секунду (і навіть на наступний місяць) ніхто не почне – немає звички. Міняти свої звички боляче та довго. Не всі готові до цього. Особливо якщо 15 років «і так само працювали». Але без цього ініціативу роботи зі знаннями в компанії чекає провал. Саме тому майстри області УЗ нерозривно пов'язують управління знаннями з управлінням змінами (change management).
p align="justify"> Ще варто звернути увагу на те, що "При розгляді змінюються потреб і тенденцій організація повинна брати до уваги наявні у неї знання ...", тобто. виробити культуру звернення до попереднього досвіду при прийнятті рішень в умовах світу, що змінюється. І зауважте, знову «повинна».
До речі, в цьому невеликому пункті стандарту багато говориться про досвід. Зазвичай, коли йдеться про управління знаннями, стереотипи починають підсовувати картинку бази знань із сотнями документів, розміщених у вигляді файлів (регламентів, вимог). Але ISO говорить про досвід. Знання, отримані на основі минулого досвіду компанії та кожного її співробітника, і є те, що дозволяє уникнути ризику повторного вчинення помилок, відразу приймати більш вигідні рішення і навіть створювати новий продукт. У найбільш зрілих у сфері управління знань компаніях (у тому числі й російських, до речі), управління знаннями розглядається як підвищення капіталізації компанії, створення нових продуктів, розробки нових ідей і оптимізації процесів. Це не є база знань, це механізм для інновацій. Розібратися в цьому детальніше нам допомагає Керівництво PMBOK організації PMI.
ПМБОК – це посібник зведення знань з управління проектами, настільна книга PMа. У шостому виданні (2016) цього керівництва з'явився розділ, присвячений управлінню інтеграцією проекту, до якого у свою чергу включено підрозділ про управління знаннями проекту. Цей пункт було створено «з урахуванням коментарів користувачів керівництва», тобто. став продуктом досвіду використання попередніх версій гайда в реальних умовах. І реальність вимагала управління знаннями!
Основним виходом нового пункту є «Реєстр викладених уроків» (в описаному вище стандарті ISO, до речі, він також згадується). Причому, згідно з керівництвом, складання цього реєстру має проводитися протягом усього реалізації проекту, а не після його завершення, коли приходить час аналізувати результат. На мій погляд, це дуже перегукується з ретроспективами в agile, але про це я напишу окрему посаду. Дослівно текст у PMBOK звучить так:
Управління знаннями проекту – це процес використання існуючих знань та створення нових знань для досягнення цілей проекту та сприяння навчанню в організації
Область знань «управління інтеграцією проекту» вимагає об'єднання результатів, здобутих у всіх інших галузях знань.
Тенденції, що розвиваються, в процесах інтеграції включають, серед іншого:
...
• Управління знаннями проекту
Все більш мобільний і змінюваний характер робочої сили потребує і суворішого процесу визначення знань протягом усього життєвого циклу проекту та їх передачі цільовим аудиторіям те щоб виключити втрату знань
***
Ключові вигоди цього процесу полягають у тому, що раніше набуті знання організації використовуються з метою отримання чи поліпшення результатів проекту, а знання, отримані під час реалізації поточного проекту, залишаються доступними задля забезпечення операційної діяльності організації та майбутніх проектів чи його фаз. Цей процес здійснюється протягом усього проекту.
Не копіпаститиму сюди весь великий розділ керівництва. З ним можна ознайомитися самостійно та зробити відповідні висновки. Представлених вище цитат, як на мене, цілком достатньо. Мені здається, наявність подібної деталізації завдання РМ з управління знаннями проекту вже говорить про важливість цього аспекту при роботі над проектами. До речі, часто чую тезу: «Кому потрібні наші знання в інших відділах?» Тобто, кому потрібні ці уроки?
Насправді часто можна бачити, що підрозділ розглядає себе як «юніт у вакуумі». Ось є ми з нашою бібліотечкою, а ось є вся інша компанія, і знання про нашу бібліотечку їй ніяк не знадобляться. Про бібліотечку – можливо. А про супутні процеси?
Банальний приклад: під час роботи над проектом відбувалася взаємодія з підрядником. Наприклад, із дизайнером. Підрядник виявився таким собі, зривав терміни, відмовлявся доопрацьовувати без додаткової оплати. РМ зафіксував у реєстрі викладених уроків, що не варто працювати з цим ненадійним підрядником. В цей же час десь у маркетингу теж шукали дизайнера і натрапили на того ж підрядника. І в цей момент є два варіанти:
а) якщо в компанії добре налагоджена культура перевикористання досвіду, колега з маркетингу шукає в реєстрі викладених уроків, чи хтось уже зв'язувався з цим підрядником, побачить негативний фідбек від нашого РМА і не втратить часу і грошей, спілкуючись з цим ненадійним підрядником.
б) якщо в компанії немає такої культури, маркетолог звернеться до того ж ненадійного підрядника, втратить гроші компанії, час і може зірвати важливу та термінову промокампанію, наприклад.
Який варіант здається успішнішим? І зауважте, корисною виявилася не інформація про продукт, що розробляється, а про супутні розробки процесах. І корисною вона виявилася не іншому РМу, а співробітнику зовсім іншого напряму. Звідси висновок: не можна розглядати розробку окремо від продажу, техпідтримку від бізнес-аналітики, а ІТ від АХУ. Всі в компанії мають досвід роботи, який виявиться корисним комусь ще в компанії. І не обов'язково це будуть представники суміжних напрямів.
Втім, і технічна сторона проекту може стати в нагоді. Спробуйте провести аудит проектів у вашій компанії протягом останніх кількох років. Ви здивуєтеся, скільки велосипедів було винайдено під час вирішення подібних завдань. Чому? Тому що не налагоджено процесів обміну знаннями.
Отже, управління знаннями, згідно з керівництвом PMI, це одне із завдань РМа. Як бачимо, дві відомі організації, які проводять платні сертифікації за своїми стандартами, включають менеджмент знань до списків мастхев інструментів контролю якості та роботи над проектами. Чому ж менеджери в ІТ-компаніях досі вважають, що керування знаннями – це документування? Чому центрами обміну знаннями залишаються кулер та курилка? Вся справа у розумінні та звичках. Сподіваюся, поступово розуміння сфери управління знаннями і у айтішних менеджерів ставатиме дедалі більше, і усна традиція перестане служити інструментом збереження знань у компанії. Вивчайте стандарти своєї роботи – у них багато чого цікавого!
Джерело: habr.com