company_banner

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

    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 проектов. Скорее всего, вы увидите, что большинство маленьких задач решены одинаково. Но на все решения затрачено время: на исследования, эксперименты и переизобретение велосипедов.

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

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

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


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



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

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

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


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

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

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

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

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

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

    Страдаем от legacy


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

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

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

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

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


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

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

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

    Источники: доклад Родиона Нагорнова «Управление знаниями в IT: при чем тут DevOps и привычки?»
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 12

      +2
      Пример Тойота хороший, наблюдая за компаниями изнутри я вижу подобное. Training matrix не была упомянута, потому о ней напишу, т.к. всё чаще и чаще с ней пересекаюсь.

      Это таблица, на которой по строкам (например) находятся имена сотрудников, в по столбцам — то, в чём они получили тренинг. Сразу видно где провал в обучении сотрудников и где и что нужно улучшить. Показывает кто главный носитель определённого навыка (который потом его передаёт другим), а кто просто рядовой пользователь. Она же помогает в самостоятельном тренинге, т.к. видно что нужно подтянуть чтобы начать делать определённую работу и там же находятся ссылки на обучающий материал. Вот этот обучающий материал — база знаний, которую сотрудники накапливали годами. Чтобы последущее поколение не делало ошибки предыдущего и знания не пропадали.

      Работает так: приходит новый сотрудник и ему говорят что нужно изучить из этой матрицы. После изучения он ставит отметку «изучил тогда-то» (это может только он, т.к. работает там защита паролем). Если чувствует, что нужно подучить ещё что-то, то он сам идёт и читает. Если подзабыл и надо препроверить, то точно так же в любой момент может это сделать. Запускается новое оборудование — автор пишет всю документацию, админы матрицы проверяют её как рецензенты, и если готова, то она становится частью матрицы.
        0
        Спасибо! В следующих публикациях об управлении знаниями постараемся рассказать об этом инструменте)
          0
          Интересная история. У меня вот только есть два вопроса: а как шарятся знания, полученные на этих тренингах, внутри компании? Т.е. можно просто понять из матрицы, что изучали до тебя люди на твоей должности, и пойти изучить, потратить деньги компании на тот же курс и т.д. А можно одному обучиться, а потом пошарить полученный опыт внутри компании так, что новичкам не потребуется идти на платный тренинг — достаточно будет обратиться к уже обучившемуся.
          И второй вопрос: кто и насколько подробно должен описать материал, лежащий по ссылкам на обучающие материалы? Нужна ли оценка самого обучавшегося, его впечатление? Ссылки сами по себе мало что могут сказать. Непонятно, что там внутри, насколько полезны материалы?
          Есть где почитать подробнее?
            +2
            я эти матрицы видел в инженерной среде, где люди работают с оборудованием. С этой позиции и напишу ответ.

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

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

            Вот где прочитать не знаю. У меня это всё из своего опыта. Может быть riskov об этом позже напишет подробней. Наверняка у IT кампаний есть нечто подобное, но как там работает мне сложно сказать.
              0
              Вот это здорово, это крайне полезная информация)) Матрицы пишут (писали) инженеры, как я понимаю? Это был приказ сверху или инициатива снизу? Матрица была в электронном виде или в бумажном?
                +1
                Почитал сегодня ещё прежде чем писать ответ, т.к. ранее об этих матрицах ранее специально не читал и не разбирался.

                В Британии есть законные акты и т.п., которые обязывают работодателя предоставлять информацию о рисках работы и работодатель так же должен позаботится о безопасности сотрудника (а это уже тренинг). С другой стороны, сегодня же читал что сотрудник со своей стороны должен следовать инструкциям работодателя (что опять же тренинг). Это так же регулируется актом или законом. Если всё это собрать в некий документ, то получится вот такая матрица, в которой отмечены тренинги по пожаробезопасности, знакомленность сотрудника с рисками, инструкциями по использованию оборудования и т.п. Т.е. это точно подстёгнуто законом. Подозреваю, не обошлось без профсоюзов в прошлом, т.к. защита сотрудников — их область. В случае чего и работодатель может прикрытья от суда если работник поступит вопреки тому, чему его учили и это записали в матрице. Он просто может показать матрицу в суде и сказать «смотрите, его же предупредили и выучили чтобы беды не случилось».

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

                Да, матрицы и документы пишут главные инженеры предприятия, инженеры, которые запускают новое оборудование, работают с новым материалом. Среди них есть и директоры, т.к. и они были на инженерных работах в прошлом. Документы, такие как инструкции по разговору с террористом, похоже, без юристов не писались. И всё, вроде бы полезно. я понятия не имел что делать если такой террорист позвонит мне по телефону и скажет «у вас в здании бомба», пока их не прочитал.
                  0
                  Спасибо!))
          0
          А почему ведение базы знаний вы повесили на поддержку? Им заняться нечем? Или они самые квалифицированные, чтобы вести такой документ?
            +1
            Им это оказалось настолько жизненно важно, что они стали этим системно заниматься. То есть, именно в поддержке поняли, что издержки от отсутствия базы выше, чем если ее вести. А дальше просто люди, которые ее вели, прокачались в этом настолько, что вполне смогли заниматься этим и в масштабированном варианте.
            Почему поддержке так была нужна база знаний? Это тоже тема для целого доклада — можно вот тут послушать www.youtube.com/watch?v=7-wstE0l8bQ.
            А кто, по-вашему, должен этим заниматься?
              0
              Мне в принципе все равно кто, скорее определяет тот, чей продукт (owner) либо аналитики, либо разработчик в момент завершения работ над функционалом, либо приемка. В любом случае поддержка базы знаний это большая и постоянная работа чтобы просто так повесить ее на поддержку. Но я уверен, что это просто вменилось поддержке как новая обязанность, это же проще и дешевле.
            0
            Это бесконечный цикл сансары, из которого менеджер сам не выйдет.
            не царское это дело — знаниями управлять.
              0
              Да-да-да. «Незаменимых у нас нет».

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

              Самое читаемое