Эволюционное изменение культуры при Kanban-трансформации

В 46 статье серии «Менеджмент цифрового мира» (оглавление) речь пойдет об эволюционном изменении культуры и ценностей в процессе внедрения Kanban, которое я буду рассматривать, опираясь на модель Спиральной динамики.

В закладки

Этим я продолжаю разговор про ценности и культуру Agile, после негативных сценариев предыдущей статьи «Столкновение корпоративной культуры с Agile», в которых «культура ест стратегию на завтрак» мы снова вернемся к позитиву: использование Kanban сейчас является одним из основных способов Agile-трансформации.

Kanban – это не только эволюционная трансформация процессов. У него есть большая ценностная составляющая, без которой эта эволюция работать не будет. На всякий случай, подчеркну, что речь идет про Kanban для IT, который является оригинальным методом, а не переносом Kanban-системы Тойоты. Я подробно обсуждал это в статье «Kanban и Lean — эволюция вместо революции». И именно Kanban из IT сейчас широко распространяется в компаниях и корпорациях, потому что он ориентирован на организацию умственного труда в управлении, разработке новых продуктов, маркетинге и других областях, а не на физическое производство. А потребность – именно в этом.

Я уже касался ценностей Kanban в статье «Изменение культуры в успешной Agile-трансформации», ссылаясь на статью Майка Барроуза, в которой эти ценности раскрыты, а не просто перечислены. Почему раскрытие важно? Потому что, как известно из модели Спиральной динамики, каждый уровень по-своему интерпретирует понятия, вкладывает в них новый смысл. Поэтому слова не могут быть надежным ориентиром.

И интерпретация ценностей, которая звучит и в этой статье, и в различных докладах практиков Kanban на конференциях отчетливо принадлежит желтому уровню культуры творчества в модели Спиральной динамики. Я не буду разбирать это подробно для всех девяти ценностей, но пару примеров приведу. Перед этим напомню схему из статьи «Культуры компаний в модели Спиральной динамики», чтобы она была перед глазами при чтении.

Культуры компаний с модели Спиральной динамики. Из моих презентаций

Ценности Kanban

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

И эта трактовка сильно отличается от узкого понимания порядка и правил, необходимого для их выполнения, свойственного синей культуре правил. Ведь бездумное применение правил ведет к карго-культу. Тут могут возразить, что в культуре правил тоже предполагается, что правила разумны и имеют основания. Да, предполагается. Но понимание оснований требуется лишь от тех, кто эти правила разрабатывает – технологов производства, или руководителей, а от исполнителей требуется всего лишь знать и исполнять правила.

И тем более понимание как осмысленность деятельности отличается от понимания в красной культуре силы – там подчиненный просто должен понять приказ своего начальника, чтобы точно его исполнить, и не его дело, почему босс этот приказ отдает. Заметим, что в оранжевой культуре успеха понимание задач, которые ставит менеджер тоже не требуется. Потому задача может быть частью предпринимательского замысла, который принято хранить в тайне: доверие к подчиненным «по умолчанию» отсутствует.

И тут уместно поговорить про прозрачность, которая тоже является ценностью Kanban. В красной культуре силы прозрачность тоже нужна – для начальника, чтобы он наказывал и награждал. В синей культуре правил прозрачность – это контроль исполнения планов и правил, который выполняют руководители и специальные службы. В оранжевой культуре успеха присутствуют обе составляющие, а еще добавляется контроль результата и связанный с этим KPI, и тоже обращена в сторону руководства.

А в Kanban прозрачность должна быть обращена во все стороны, работа команды должна быть прозрачна не только для руководства, но и для коллег, и не только для соревнования, но и для своевременной помощи и решение проблем – Kanban ставит на прямые горизонтальные связи, а не на взаимодействие через руководство. А команда руководителей тоже должна быть прозрачна для сотрудников. И это – интерпретация прозрачности зеленого уровней с акцентами желтого.

Прозрачность должна обращена быть во все стороны: работа команды должна быть прозрачна для руководства и для коллег, и работа руководства должна быть прозрачна для сотрудников

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

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

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

Kanban же предполагает открытое взаимодействие, партнерство в совместном движении к цели по согласованным правилам, как говорит ценность соглашения. И эти правила включают заявленные заранее способы закрытия обязательств и выхода при изменении ситуации. А также максимизацию потока создание ценности в целом, в том числе для клиента, о чем говорит отдельная ценность «ориентирование на клиента» и стирание границ между командами и людьми, когда вы обсуждаете препятствия на пути этого потока.

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

И, что интересно, у практикующих тренеров ценности находятся на хорошем уровне осознанного понимания: при работе с компаниями они встречаются с иными культурами и паттернами поведения, и не просто зафиксировать различия, а оценить уместность конкретных паттернов в ситуации конкретной компании и там, где это важно - аргументировано показать различия и работать над трансформацией. Это хорошо видно из выступлений на конференциях и воркшопах, в частности на недавно прошедшей Kanban Eurasia (мой отчет). При чем на воркшопах тренеры разбирают кейсы от участников, поэтому все это хорошо видно в логике рассуждений, это не теория из книг.

Kanban Maturity Model

А я перейду к не менее интересному вопросу – Kanban Maturity Model (KMM). В ней, наряду с процессной, есть большая ценностная составляющая, и прошедшая конференция дала мне возможность достаточно плотного знакомства с моделью – и в докладах и в сфокусированном обсуждении с экспертами. Конечно, это не дает такого понимания, как тренинг, многие из собеседников подчеркивали, что сами они поняли схему во всей полноте, лишь пройдя его. Зато получился хороший взгляд со стороны, через восприятие разных людей.

О модели и векторах ее развития можно получить представление из статьи, посвященной версии новостям 1.1, там же на сайте можно запросить пакет материалов по модели. В статье приведена большая схема с акцентом на процессы, хотя культуре и ценности тоже присутствуют в левой колонке. Но разобрать я хочу другую схему, посвященная ценностям. На рисунке – русский перевод, сделанный Kanban-сообществом. Схему в виде отдельного документа можно найти здесь, а здесь – английский оригинал.

Канбан модель зрелости. Перевод Kanban-сообщества с английского оригинала

На этой схеме – семь уровней последовательного расширения масштаба деятельности и связанное с этим расширение поля вопросов. И она дает представления о порядке в эволюционном пути развития.

  • На нулевом уровне индивидуумы сфокусированы на себе и личной работе.
  • Первый уровень – фокус на команду, достижение сотрудничества и прозрачности в сочетании с инициативностью.
  • Второй – фокус на клиенте команды и его потребностях и измерении удовлетворенности. Тут надо отметить, что Kanban ориентирован на перестройку организации в сервисной модели, когда у каждой команды есть потребители, которым она оказывает сервис.
  • Третий – сегментация потребителей по потребностям и выравнивание целей, стратегия и направления развития – ты начинаешь думать о развитии своего сервиса и о соответствии предназначению.
  • Четвертый уровень – фокус на экономическую оправданность деятельности для каждой команды: создаваемая ценность должна превосходить затраты. А также на хеджирование рисков, связанных с неопределенностью ситуации. Фактически, все команды учатся предпринимательскому отношению к развитию своего сервиса.
  • Пятый уровень – лидер рынка, компания, которая не просто развивается сама, а развивает свой сегмент рынка и служит ориентиром.
  • Шестой уровень – диверсифицированный многосегментный бизнес.

Если мы посмотрим на развитие масштаба по уровням схемы, то увидим, что оно хорошо перекликается с жизненным циклом корпорации Адизеса.

Жизненный цикл корпорации по Адизесу. Источник - adizes.ru

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

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

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

Бесполезно ориентироваться на потребителя, сегментировать его и развивать отдельные рынки, если в компании нет команд, которые способны самостоятельно это делать

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

В целом именно на оздоровлении уровней команд и ориентации на потребителей связан позитив Kanban-трансформации крупных корпораций, которые уже пошли по нисходящей ветви жизненного цикла корпораций Адизеса. Сотрудничество и инициатива уровня команд вновь приносят энергию в корпорацию, оживляют ее и при успехе – разворачивают деградацию в обратном направлении.

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

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

Таким образом, Kanban-трансформация начинается с оценки ситуации компании по KMM. И отдельным фокусом тут является соответствие между собой процессов и культуры, потому что перекосы ведут к неэффективной деятельности. Процессы и практики, которые дают наблюдаемое поведение на схеме слева, а культура в виде ценностей, фокус-вопросов и способов лидерства – справа.

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

На уже упомянутой конференции Kanban Eurasia о соответствии процессов и ценностей на основе применения KMM в реальных кейсов рассказывала Сюзанна Бартел (видео, презентация, мой конспект). В докладе были конкретные несоответствия, которые дала диагностика и принятые меры по их устранению.

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

И, завершая рассмотрение ценностей Kanban через призму спиральной динамики, я хочу обратить внимание на еще один вопрос. Где в модели ценности зеленого уровня, касающиеся не сотрудничества и уважения внутри компании, а принесения пользы человечеству в целом, социальной ответственности, отсутствия вреда экологии и другие, ассоциирующиеся с зеленым уровнем? В явном виде их тут действительно нет, они – за рамками модели. Потому что это относятся к общему уровню ценностей и осознанности общества, в котором работает компания.

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

Собственно, в этом – большие риски любой Agile-трансформации: поднимая осознанность сотрудников, компания в некоторый момент получает вопрос о пользе, которую она приносит миру и смысле ее существования. И если сотрудники не получают обоснованного ответа, то они уходят наносить пользу миру в другие компании.

И тут не обойдешься пропагандой и созданием внешнего имиджа, сотрудники видят команду изнутри. И хороших зарплат в современном мире тоже недостаточно. Я тут хочу привести пример, который не относится непосредственно к Agile, зато хорошо иллюстрирует этот тезис. Летом 2019 я был на STEPIR, где слушал доклад про проблемы корпоративной культуры КазМунайГаза – национальной нефтегазовой компании Казахстана. Один из проблемных вопросов – показать экологичность добычи и производств компании. Не просто создать образ в СМИ, а именно обосновать перед сотрудниками. Оказывается, без этого возникают существенные трудности при привлечении молодых, перспективных и талантливых на работу, и высокие зарплаты нефтегазовой отрасли не помогают.

На этом я завершу эту статью. В завершении предыдущей статьи я обещал рассказ не только про Kanban. Но тема оказалась слишком большая, и будет иметь продолжение: рассказ про адаптацию Disciplined Agile для культуры больших корпораций и про сопряжение Agile-культура с харизматичным лидерством, и заключительную схему, включающая не только развитие Agile в модели спиральной динамики, но и адаптации разных уровней. Полное оглавление серии – на моем сайте http://mtsepkov.org/NewMngSeries. Продолжение следует…

{ "author_name": "Максим Цепков", "author_type": "self", "tags": [], "comments": 6, "likes": 0, "favorites": 21, "is_advertisement": false, "subsite_label": "hr", "id": 126003, "is_wide": false, "is_ugc": true, "date": "Sat, 09 May 2020 17:39:32 +0300", "is_special": false }
Объявление на vc.ru
0
6 комментариев
Популярные
По порядку
Написать комментарий...
0

Смотрите, визуализация была придумана задолго до 2004-2007, первое упоминание я встречал в книге Вумека и Джонса "Бережливое производство" 1996 года, но использовалась она гораздо раньше. И продуктовые команды, и ориентация на клиента, вытягивание -это все было описано еще тогда. Неявно между строк прослеживается и гибкость, т.е радикальное снижение затрат на доработку продукта, разработку новой модификации, и т.п. И это все инструменты для улучшений, сокращения потерь, повышения качества. 

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

Что еще в IT-Канбане есть, чего не было в Бережливом производстве? Лично я существенных вещей вроде и не вижу.

Ответить
0

"Что есть в IT-Kanban, чего не было в бережливом производстве" - вопрос ставить неправильно. IT-Kanban по-другому собран. Он был разработан под IT-процесс, и там много практик, которые ориентированы именно на задачи IT-разработки. При сборке использовались как практики IT, так и практики других отраслей, не только Lean. Аналогично Lean в IT.

Есть верхний слой идей и концептов Lean, он общий. Но дальше начинается конкретика, вот команда производственного Lean приходит, например, на производство SuperJet и начинает его оптимизировать, у них - конкретные фокусы внимания, я слушал такой доклад на одной из конференций. Если мы сравним это с фокусами внимания профессионала в IT LeanKanban, которые приходят работать с реальным IT-производством - то они совершенно другие. И лишь с большой натяжкой можно говорить о том, что лишние погружения в контекст задачи при переключениях - это аналог транспортных накладных расходов на лишнюю транспортировку, хотя в некотором смысле это так.

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

Как пример. Если мы смотрим диаграммы исполнения процесса, и видим неравномерность и задержки, то в физическом производстве это часто свидетельство узкого горла, которое срабатывает волатильно из-за неоднородной нагрузки и перед которым полезно сделать буфер и вообще следить за запуском в производство с его учетом (мы знаем, какие операции обработки потребуются!). А в IT это может быть скрытая сложность, не видная на входе, в результате которой в один класс обслуживания попадают задачи разной сложности, и предсказуемость нарушается, и если это выявлено - стоит подумать о том, можно ли эту скрытую сложность проявить на ранних этапах (мы НЕ знаем, какие операции обработки потребует решение задачи). 

Ответить
1

"Два подхода основаны на общих верхнеуровневых концептах" - я это понимаю так, что они в основе своей идентичны, а различаются лишь в деталях. Очевидно, что организация производства, например, строительных материалов и кораблей очень существенно различаются. И использоваться Kanban на этих производствах тоже будет совершенно различным способом именно потому, что там фокусы на совершенно разных вещах. Сравним теперь условно различия между применением Kanban к двум разным производствам и различия между Kanban  в производстве и IT. Не будет ли там примерно такая же разница?

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

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

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

Ответить
0

Да, в целом все так, подходы взаимно обогащаются и дополняются, потому что производство перестает принципиально отличаться от IT. И корни общие.

Ответить
0

Это очень похоже на идеи Бережливого производства, если не воспринимать его поверхностно, как просто "устранение потерь". Скорее всего, историческая связь между ними есть.

Ответить
0

Логика развития была такой. Дэвид Андерсон придумал Kanban (2004-2007), при этом была идея визуализации работы на доске и серия других идей из разных источников. И да, постоянные улучшения, поиск потерь и синхронизация. В его книге (2010) хорошо описано. Параллельно Мэри и Том Поппендики работали над переносом Lean в IT-разработку, первая книга Lean Software Development была ими написана в 2003. Концепты - те же, устранение лишней работы, просто для умственного труда в целом и IT-разработке в частности характер потерь и ущерб от них совсем другой в силу особенностей продукта. Например, почти бесплатна логистика или малое исправление ошибок, по-другому играет погружение в сложный контекст и скорость переключений, другой характер синхронизаций разных цепочек. В целом поэтому Lean для IT сильно отличается.

Ну и дальше это объединялось в единое движение, еще недавно Kanban University сообщества назывался Lean Kanban Insitute (и его сайт leankanban.com сейчас перенаправляется на новый kanban.university). И сейчас они внимательно следят за производственным Lean, а местами с ним соревнуются.

Ответить

Прямой эфир