Кейсы agile-трансформации, часть третья: производство

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

В прошлых статьях был рассказ про банки и про корпорации и госструктуры, в этой я рассказываю про производственные компании: издательство МИФ, медицина, fashion, литейный завод, Scrum в продажах, а следующей будет самая любопытная часть – Agile в школах.

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

Все написанное – моя собственная интерпретация, однако в статье много ссылок на видео докладов и мои конспекты, так что вы можете составить свое собственное мнение.

Свой рассказ про Agile-трансформации производственных компаний я начну с кейса издательства МИФ (Манн, Иванов, Фабер), о котором на IT Spring-2017 рассказывал Владимир Горшунов, а осенью на Agile Business-2017 у него был совместный доклад с Артемом Степановым «На пути к Business Agility. Трансформация издательства МИФ».

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

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

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

Заметим, что речь идет не об одной книге, а именно о серии, которая образует value stream: сначала запускается первая книга, но все готово к тому, чтобы при успехе можно было выпустить и другие, а при неудаче – наоборот, свернуть с ограниченными потерями. Отдельные проектные потоки (value stream) объединены в три крупных value stream по направлениям бизнеса: розничный, корпоративный и online, при этом за счет каскадирования каждый проект понимает свое место и значение в реализации стратегии в целом. И эта комплексная картина собирается и транслируется на компанию в целом.

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

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

Еще один интересный кейс, о котором я хочу рассказать – Agile-трансформация отдела продаж компании по производству строительной плитки. Марина Симонова (Marina Alex) рассказывала о нем на IT Spring-2017, и на AgileDays-2018 в докладе «Agile трансформация начинаем с продаж». Интересно, что применяется Scrum, хотя, казалось бы, в отделах продаж у нас есть поток задач, такты спринтов носят условный характер. Это, конечно, верно, но в Scrum-фреймворк достаточно жестко заложена командная работа, а для изменений в продажах это принципиально: менеджеры по продажам обычно работают индивидуально, на персональные бонусы, заложенные в KPI.

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

При трансформации директор по продажам стал Product Owner, он определяет стратегию и ставит задачи, а начальники отделов стали Scrum Master и их задача – чтобы команда совместно придумала идеи для выполнения плана, а потом их сделала. Scrum удерживает команду от возврата к старому управлению на переходном этапе.

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

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

А Марина развивает применение Agile в продажах, сейчас у нее разработан собственный SWAY-фреймворк для Agile в продажах (здесь по-русски), признанный на международном уровне.

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

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

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

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

Следующий кейс из fashion-индустрии. О нем рассказывали директор компании 12Storeez Иван Хохлов и Роман Короленко в докладе «Октябрьская революция или 12 коллекций женской одежды в год с помощью Agile» на Agile Business-2018 (мой конспект). Компания 12Storeez придумывает 12 коллекций женской одежды в год, аутсорсит производство, а затем – продает в своих магазинах, у нее 230 человек в команде и 12 магазинов в России. И выпускать эти 12 коллекций в регулярном режиме они не успевали. Основная причина - в том, что люди стремились отдать на следующий этап как можно раньше, даже если не было все готово для завершения фазы, надеялись доработать на ходу, не успевали, были непрерывные пожары и росла незавершенка. И все проблемы были на Иване, он становился узким местом.

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

Действия в теории понятны: визуализировать процесс, выявить узкие места, внедрить чеклисты перехода на следующую стадию, организовать команды в узких местах, в частности Scrum для конструкторов, которые отшивают первый экземпляр, отработать работу сервисных служб в нужном темпе. Доклад рассказывал, как это было сделано практически. А в результате time to market уменьшился с 6 месяцев до двух, и они перешли к регулярному выходу продуктов в запланированные сроки.

Еще один кейс «История о развитии Канбан в машиностроении на литейном заводе» рассказывал Нурмагомед Джафаров, заместитеть гендиретора Литмашдеталь. При этом он специально уточнил, что речь идет не о производственном Kanban Тойоты, а о разработке Андерсона для IT – потому что они включают в цикл непроизводственные подразделения, занимающиеся интеллектуальной деятельностью, а не физическим трудом, и основной эффект был достигнут в маркетинге и продажах. При этом японский Kanban – это жесткие правила и революция, обеспечивающая just in time, а Kanban Андерсена – это быстрая эволюция маленькими шагами.

А с производством у них и так все достаточно хорошо. Они его оптимизировали более 20 лет, развивали организационные принципы и в отдельных рабочих бригадах добились высочайшей эффективности. Недавно окунувшись в изучение Agile, они выяснили, что уровень взаимодействия литейщиков уже практически полностью соответствует business agility: на людях объединили 4 профессии в одну, так что достигли полной кроссфункциональности и взаимозаменяемости людей и способности оперативно обработать любой заказ.

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

Но тут помог чужой опыт: смежник, поставщик оснастки, внедрил Канбан у себя, и в результате в 1.5 раза взлетела пропускная способность и на 16% выручка, они наняли нового продажника, чтобы загрузить систему. Они пошли смотреть опыт – а там 29 человек и единая Kanban-доска для всех на 80% потока. И тогда они поняли, что недостаточно сделать Kanban на основные процессы. У них 150 человек и процесс больше, одной доски недостаточно – они начали выстраивать длинную последовательность досок end-to-end. В результате вскрыли узкие участки в маркетинге и продажах и начали делать отдельные доски там, чтобы изменить ситуацию. Вот такая история.

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

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

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

И в заключении – немного статистики про успешность Agile-методов. Тем более, что в комментариях к одной из моих статей про Scrum, как это часто бывает, появились люди, утверждающие что никаких данных и никакой статистики, подтверждающей эффективность Agile-методов даже в IT, нет и все это - чистая пропаганда. Я знаю, что статистика есть, я ее слышал в ряде докладов, в том числе - в докладе Сазерленда на SECR-2011, ссылку на который я и привел. Но такие люди обычно не хотят истины, они хотят лишь увериться в правильности своего мнения. Поэтому подобные ссылки быстро объявляют предвзятым мнением, а не разбираются. И, поскольку у всякой такой дискуссии есть читатели, то я сделал еще пару шагов, результаты которых тут публикую. Я довольно быстро вышел на статью Michael Sweeney Agile vs Waterfall: Which Method is More Successful? со статистикой и ссылками и на несколько отчетов. IT Project Success Rates Survey Results 2013, IT Project Success Rates Survey Results 2018 (на сайте есть и другие) и Standish Group 2015 Chaos Report.

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

Во всех этих отчетах Agile-методы рассматриваются без разделения. Но по ним есть отдельная статистика, которую ежегодно публикует Version One а пару лет назад ScrumTrek начал публиковать такую же по России (2018, 2019), на которую можно также опираться, и в полной версии, доступной по ссылкам, есть цифры о целях и достижениях, которые ставят при Agile-трансформации.

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