Без управления знаниями больно: 5 основных последствий отсутствия системы

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Toyota — мировой лидер автомобилестроения, один из самых дорогих автомобильных брендов и синоним слова «качество». Toyota известна своей сложной производственной системой, благодаря которой она стала мировым лидером. На её описание потребовалось 10 лет и 20 версий, в итоге появился документ «Философия Toyota 2001». Часть принципов из этой книги — кайдзен и канбан — используются в IT. Но эти принципы лишь часть системы постоянного обучения и непрерывного совершенствования, которая плотно интегрирована во все процессы корпорации.



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

История Toyota — отличный пример управления знаниями. Но что будет, если знаниями не управлять, а систему не выстраивать? Велосипеды, сломанные конвейеры, автобусы, «сжигание» денег на онбординге и legacy — все это случается с компаниями, когда они не задумываются об управлении знаниями.

Знания — это взаимодействие


Сначала определимся с термином «знания». В IT-сообществе у него разные определения.

Знания = Confluence (JIRA, Notion или другая система)? Собирать знания важно, но это не равноценные понятия. Если знания это Confluence, то управление знаниями (УЗ) — это управление Confluence?

Знания = опыт? Опыт — то, что мы пропустили через себя, отрефлексировали и на его основе решаем текущие задачи. Но если знания это опыт, то управление знаниями — управление опытом?

Знания = документация: базы знаний, FTP с документами, Word или Google-документы? Нет, документы это часть управления знаниями: получили опыт, описали, добавили в документ. Сам по себе документ бесполезен, если лежит на сервере и его не используют.

Ни одно из этих определений неполно. Чтобы понять, что такое знание, придется забежать немного вперёд. Посмотрим, как схематически знания и управление ими представляют себе там, где его активно используют — во многих западных компаниях: McDonalds, NASA, Oracle, Ford, Microsoft Services.


Схема управления знаниями (dimensions of knowledge management).

Здесь ни документы, ни опыт, ни база знаний не выделены отдельно. Зато есть: управление изменениями, организационная эффективность, производительность, интеллектуальный капитал (за что мы получаем деньги). Если обобщить всё, что на схеме, то мы увидим мастерство и опыт сотрудников, которые используют и опыт, и базу знаний и все остальное. Отсюда вытекает определение «знаний».

Знание – это взаимодействие информации, мастерства и опыта экспертов.

Теперь рассмотрим, что такое «управление знаниями».

Управление знаниями — это процесс


Вы участвовали и участвуете в управлении знаниями каждый день.

  • На работе что-то рассказываете коллегам о новой статье по Kubernetes или узнаёте от них, как быстрее закрывать задачи.
  • Воспитываете детей, учите читать, писать, переходить на зелёный и уважать старших.
  • Занятия в школе и институте — передача знаний от преподавателя к ученикам.
  • Онбординг: знакомство новичков с традициями, планом эвакуации, правилами проведения митингов и рабочими задачами.

Всё это — естественные процессы управления, передачи и приёма знаний. Зафиксируем, что управление знаниями — это процессы.

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



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

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

Что бывает без управления знаниями 


Естественные процессы ни у кого не вызывают вопросы. Вопросы возникают, когда появляется задача систематизировать естественные процессы, чтобы они приносили компании пользу в деньгах. Как будто, в это время отключается какая-то социальная часть мозга и руководство пытается понять: «Зачем это всё?»

Чтобы понять «Зачем», рассмотрим, что мы теряем, если не внедряем. 

Ничего не успеваем


Компания Coding Sans провела исследование в европейских IT-компаниях. Сотрудникам задавали один вопрос: «Какой основной вызов в сфере разработки ПО вы для себя видите?» Пятая часть опрошенных разных должностей указали, что это обмен знаниями. Это второй результат после «capacity» — возможности решить больше задач за меньшее время.



Но интереснее сравнение голосов между теми, кто пишет код, и их менеджерами.


Первые три позиции: capacity, УЗ и найм новых талантов.

Синий столбик — менеджеры, жёлтый — разработчики. Разница между значениями почти треть в относительном выражении. Оказывается, что разработчикам важнее канал для управления знаниями.

Менеджерам важнее все успевать. Обычно, для этого они «закидывают» задачи людьми: обращаются к HR, нанимают больше разработчиков (см. третий столбик) и ждут, когда задачи будут закрываться вовремя.

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

Изобретаем велосипеды


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

Вернемся к автопроизводителям — представим сферическую компанию в вакууме, которая проектирует и производит автомобили. Например, несколько лет назад компания выпустила внедорожник и пришло время его обновлять — он морально устарел. Что будет дороже: начать проект заново, спроектировать, разработать и выпустить автомобиль с нуля, или разработать на основе уже созданной модели?

По второму сценарию работает компания Reno. В компании есть универсальная платформа B0 — набор общих деталей из которого собирается автомобиль по типовым конструктивным решениям. На B0 Reno собирает Logan, Sandero, Duster и даже грузовые автомобили. Также её используют в Nissan и Lada. Платформа (набор деталей и типовых решений) позволяет экономить ресурсы, используя предыдущие наработки, а не «велосипедить» каждую новую модель с нуля.

Попадаем под автобусы


Также как в IT, в реальном секторе есть проблема с текучкой. Но не потому, что люди увольняются — они уходят на пенсию. Демографическая картина смещается в сторону пенсионеров: молодых меньше, пожилых больше. При этом у старшего поколения есть уникальный опыт, который компании теряют.



Для завода, который производит 13 млн стали в год, простой даже в один день это потери миллионов долларов.

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

Теряем деньги на онбординге


Новый сотрудник всегда стоит денег — от нескольких десятков до сотен тысяч рублей. Откуда такая цифра?

  • Для поиска подключают HR-отдел, реже — IT-рекрутеров на аутсорсе. Вознаграждение рекрутера обычно несколько зарплат нового сотрудника (если он прошел испытательный срок). HR тоже надо платить зарплату во время поиска, который может длиться неделями и месяцами.
  • Новичку платят оклад за первые месяцы, пока он не войдёт в рабочий режим.
  • В это время новый сотрудник не выполняет рабочие задачи на 100%, а это упущенная прибыль.

Все это суммарно складывается в ощутимые цифры. Поэтому новичка всегда стремятся выводить на производственные мощности максимально быстро. Но всё стремление разбивается о гранит онбординга. Как он обычно устроен?

В первый день человек получает документ на 200 страниц:

— Читай, тут всё описано. Если что-то непонятно, в соседнем кабинете сидит Олег, ты его узнаешь. Но только он работает три дня из пяти на удаленке.

«Кто такой Олег, где его найти, как это всё читать?» и много других мыслей возникает в нейронах новичка. Он испытывает стресс, не успевает понять проект, но главное, что у него складывается неприятное впечатление о вашей компании. Через пару месяцев вы будете онбордить нового человека.

Страдаем от legacy


Есть те, кто не работал с ним — вы счастливые люди. Тем, кто работал, жмём руки и сочувствуем. Legacy это больно.

Рассмотрим два типичных случая, связанных с legacy, которые заставляют страдать.

Мы пилили монолит. Лет 10 назад кто-то что-то написал, но его уже давно нет в компании. Зато есть задача разобраться с legacy-кодом, например, но это невозможно, потому что ничего не описано. Разработчики чувствуют, что скоро будет больно, а руководство — что это выйдет дороже, чем код стоил изначально.

Заказная разработка ПО. Часть кода писал сторонний подрядчик и через пять лет вам понадобилось всё это оптимизировать или интегрировать. Но компании-подрядчика уже нет. Проявился автобусный фактор, только в масштабе компании.

Без управления знаниями больно


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

Но если вы всё же хотите уменьшить уровень боли от legacy или работы «велосипедного комбината» в компании, попробуйте осознать проблемы и решить одну из них. При этом не обязательно строить такую же сложную структуру, как в Toyota, — достаточно простых решений. Подробно, с примерами, алгоритмами и инструкциями мы поговорим об этом на KnowledgeConf 2020: как провести аудит компании, найти все проблемы (не только те, что мы рассмотрели) связанные с отсутствием УЗ, и сделать первые шаги к их решению.

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

Источники: доклад Родиона Нагорнова «Управление знаниями в IT: при чем тут DevOps и привычки?»
Источник: https://habr.com/ru/company/oleg-bunin/blog/492478/


Интересные статьи

Интересные статьи

В 1992-м году проходил очередной конкурс по обфусцированному программированию на языке С. Один из представленных проектов был небольшой форт системой. Меня поразило, что виртуальная машин...
Попробую поделиться советом, как можно немного осознать свое состояние и выработать полезный навык. Все написанное основано только на личном опыте, желании им поделится и подчерпнуть из обратной ...
Вам приходилось сталкиваться с ситуацией, когда сайт или портал Битрикс24 недоступен, потому что на диске неожиданно закончилось место? Да, последний бэкап съел все место на диске в самый неподходящий...
4 июля мы проводили большой семинар по управлению уязвимостями. Сегодня мы публикуем расшифровку выступления Андрея Новикова из Qualys. Он расскажет, какие этапы нужно пройти, чтобы выстроить раб...
В этой части поговорим о программной составляющей, как оживлялась машинка. Какая ОС использовались, какой язык был выбран, с какими проблемами сталкивался. Читать дальше → ...