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).
Здесь ни документы, ни опыт, ни база знаний не выделены отдельно. Зато есть: управление изменениями, организационная эффективность, производительность, интеллектуальный капитал (за что мы получаем деньги). Если обобщить всё, что на схеме, то мы увидим мастерство и опыт сотрудников, которые используют и опыт, и базу знаний и все остальное. Отсюда вытекает определение «знаний».
Теперь рассмотрим, что такое «управление знаниями».
Вы участвовали и участвуете в управлении знаниями каждый день.
Всё это — естественные процессы управления, передачи и приёма знаний. Зафиксируем, что управление знаниями — это процессы.
Естественные процессы работают, но нестабильно, потому что не систематизированы и случайны. Результат от случайных процессов также случаен и непредсказуем. Процессы начинают давать стабильный результат, когда в компании понимают, что с помощью информации, знаний и опыта внутренних экспертов можно решать задачи эффективнее.
Эффективные решения помогают создавать новые продукты, улучшать старые и повышать удовлетворенность клиентов. Когда служба поддержки быстрее и точнее отвечает на вопросы, решает проблемы пользователей, недовольных клиентов меньше. Это уменьшает отток пользователей, что повышает финансовые показатели.
Естественные процессы ни у кого не вызывают вопросы. Вопросы возникают, когда появляется задача систематизировать естественные процессы, чтобы они приносили компании пользу в деньгах. Как будто, в это время отключается какая-то социальная часть мозга и руководство пытается понять: «Зачем это всё?»
Чтобы понять «Зачем», рассмотрим, что мы теряем, если не внедряем.
Компания Coding Sans провела исследование в европейских IT-компаниях. Сотрудникам задавали один вопрос: «Какой основной вызов в сфере разработки ПО вы для себя видите?» Пятая часть опрошенных разных должностей указали, что это обмен знаниями. Это второй результат после «capacity» — возможности решить больше задач за меньшее время.
Но интереснее сравнение голосов между теми, кто пишет код, и их менеджерами.
Первые три позиции: capacity, УЗ и найм новых талантов.
Синий столбик — менеджеры, жёлтый — разработчики. Разница между значениями почти треть в относительном выражении. Оказывается, что разработчикам важнее канал для управления знаниями.
Менеджерам важнее все успевать. Обычно, для этого они «закидывают» задачи людьми: обращаются к HR, нанимают больше разработчиков (см. третий столбик) и ждут, когда задачи будут закрываться вовремя.
Даже если рекрутер соберет все сливки рынка, то проблема никуда не денется. У разработчиков нет способа оперативно получать информацию, чтобы быстро закрывать задачи, поэтому проблема возникнет снова, но в большем масштабе. Это бесконечный цикл сансары, из которого менеджер сам не выйдет.
Попробуйте провести в компании аудит последних 20 проектов. Скорее всего, вы увидите, что большинство маленьких задач решены одинаково. Но на все решения затрачено время: на исследования, эксперименты и переизобретение велосипедов.
Вернемся к автопроизводителям — представим сферическую компанию в вакууме, которая проектирует и производит автомобили. Например, несколько лет назад компания выпустила внедорожник и пришло время его обновлять — он морально устарел. Что будет дороже: начать проект заново, спроектировать, разработать и выпустить автомобиль с нуля, или разработать на основе уже созданной модели?
По второму сценарию работает компания Reno. В компании есть универсальная платформа B0 — набор общих деталей из которого собирается автомобиль по типовым конструктивным решениям. На B0 Reno собирает Logan, Sandero, Duster и даже грузовые автомобили. Также её используют в Nissan и Lada. Платформа (набор деталей и типовых решений) позволяет экономить ресурсы, используя предыдущие наработки, а не «велосипедить» каждую новую модель с нуля.
Также как в IT, в реальном секторе есть проблема с текучкой. Но не потому, что люди увольняются — они уходят на пенсию. Демографическая картина смещается в сторону пенсионеров: молодых меньше, пожилых больше. При этом у старшего поколения есть уникальный опыт, который компании теряют.
Для завода, который производит 13 млн стали в год, простой даже в один день это потери миллионов долларов.
В IT ситуация аналогична, несмотря на технологичность: сотрудники уходят, их знания не сохраняются, а компании несут убытки, которые даже трудно подсчитать.
Новый сотрудник всегда стоит денег — от нескольких десятков до сотен тысяч рублей. Откуда такая цифра?
Все это суммарно складывается в ощутимые цифры. Поэтому новичка всегда стремятся выводить на производственные мощности максимально быстро. Но всё стремление разбивается о гранит онбординга. Как он обычно устроен?
В первый день человек получает документ на 200 страниц:
— Читай, тут всё описано. Если что-то непонятно, в соседнем кабинете сидит Олег, ты его узнаешь. Но только он работает три дня из пяти на удаленке.
«Кто такой Олег, где его найти, как это всё читать?» и много других мыслей возникает в нейронах новичка. Он испытывает стресс, не успевает понять проект, но главное, что у него складывается неприятное впечатление о вашей компании. Через пару месяцев вы будете онбордить нового человека.
Есть те, кто не работал с ним — вы счастливые люди. Тем, кто работал, жмём руки и сочувствуем. Legacy это больно.
Рассмотрим два типичных случая, связанных с legacy, которые заставляют страдать.
Мы пилили монолит. Лет 10 назад кто-то что-то написал, но его уже давно нет в компании. Зато есть задача разобраться с legacy-кодом, например, но это невозможно, потому что ничего не описано. Разработчики чувствуют, что скоро будет больно, а руководство — что это выйдет дороже, чем код стоил изначально.
Заказная разработка ПО. Часть кода писал сторонний подрядчик и через пять лет вам понадобилось всё это оптимизировать или интегрировать. Но компании-подрядчика уже нет. Проявился автобусный фактор, только в масштабе компании.
Мы всё время обмениваемся знаниями, но не задумываемся об этом — это случайные процессы. Когда заходит речь о системном подходе, сразу находится тысяча аргументов, чтобы ничего не делать. При этом, чем ниже должность, тем больше потребность в каналах обмена знаниями, а становясь менеджером — все проблемы с получением информации будто исчезают, а всё решается наймом. На самом деле нет, просто так проще.
Источники: доклад Родиона Нагорнова «Управление знаниями в IT: при чем тут DevOps и привычки?»
В системе обучения много разных принципов и техник. Например, перед разработкой новой модели инженеры 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 и привычки?»
