Upstream and Downstream
Василий Савунов | https://t.me/data_driven_management
🔖Корни разделения на Upstream и Downstream лежат в реальном производстве и сопутствующем ему процессе Supply Chain Management - процессе поставки сырья для производства.
Патрик Стюарт в своей книге Upstream Kanban лишь использует устоявшуюся в производстве терминологию.
❓Почему же так получилось? Причём здесь река и течения?
🤷 Если вспомнить физический смысл этих слов и наложить их на любой поток поставки ценности, то все быстро встает на свои места.
🚰Физический смысл слов “upstream” и “downstream” означает разные части течения реки. “Upstream“ означает поток выше по течению - то есть река течет К нам, а “downstream” - это поток ниже по течению, то есть река течет ОТ нас.
Если перенести это на язык Канбан-метода, то относительно точки начала производства у нас есть поток ценности выше по течению - до начала производства, и ниже по течению - когда продукт уже пошел в производство.
Что это за два потока ценности? Давайте разберемся.
1️⃣ Прежде чем начать что-то производить, нам надо сперва получить сырье, материалы, детали из которых мы будем производить продукт.
Что мы для этого делаем?
Планируем объемы производства относительно наших бизнес-планов, понимаем, какое сырье, материалы и детали нам нужны и в каком количестве. Затем отправляем поставщикам заказ на поставку нужных объемов. И спустя какое-то время поставщики все это привозят К нам на склад.
Значит, есть поток ценности от наших поставщиков К нам. Это и есть Upstream - то что находится “выше по течению” и приносит нам все необходимое для начала производства.
2️⃣ Затем мы берем со склада необходимое для производства сырье, материалы, детали и пускаем это в производство продукта. Этот процесс производства продукта течет ОТ нас к конечному клиенту, унося с собой сырье, материалы и детали и постепенно превращая все это в конечный продукт. Это и есть Downstream - то что находится ниже по течению.
👉 Давайте рассмотрим на конкретном примере производства автомобилей:
⬆️ Upstream: это поток поставки деталей и узлов от наших поставщиков К нам на склад. Все они “текут” к нам, собираясь в нужном количестве на складе.
⬇️ Downstream: это поток производства и поставки автомобилей ОТ нас к нашим покупателям. По мере того, как продукт движется по конвееру, он все дальше “уплывает” от нас в сторону потребителя.
❓ Как это все работает в интеллектуальном труде?
В интеллектуальном труде, организацией которого и занимается Канбан-метод, все происходит точно так же, только вместо физических сырья, материалов и деталей, по Upstream "течет" поток ответов на вопросы и необходимые артефакты.
👉Upstream Kanban
Прежде чем программист начнет делать какой-то программный продукт, бизнесу, аналитикам и архитекторам надо ответить для себя на ряд вопросов:
- Какой у нас бизнес-план?
- Что нужно произвести, чтобы этот бизнес-план выполнить?
- Каково соотношение затрат и потенциальной выгоды от этого программного продукта?
- Какие системы потребуются, чтобы создать этот программный продукт?
- Каковы желательные сроки выпуска этого продукта?
- и так далее
И на основе ответов на эти вопросы, нужно будет подготовить необходимые артефакты: ТЗ, архитектурную концепцию, UML-диграмму и т.п. - все то, что поясняет программисту, что именно ему надо сделать
Процесс ответов на эти вопросы и подготовки этих артефакты и будет составлять Upstream Kanban.
☠️Во многих компаниях, процесc Upstream функционирует стихийно - кто как умеет, тот так и делает. В результате, у руководителей часто нет возможности получить быстрый ответ на вопрос: “сколько инициатив у нас сейчас находятся на стадии проработки?”. Потому что нет какого-то одного места, куда можно было бы посмотреть и увидеть весь тот вал планов и подготовительной работы, которым в данный момент заняты сотрудники.
🤷А как управлять тем, что не видно?
🔍Поэтому процесс подготовки инициатив к производству нужно проявлять и опрозрачивать в виде Канбан-доски, так же как мы это делаем с процессом производства на этапе Downstream.
👉 Downstream Kanban
Процесс производства, как правило, контролируется гораздо лучше чем Upstream, потому что здесь уже идет реальная работа и программисты пообещали заказчикам, что сделают все к какому-то сроку. Поэтому бизнес-заказчики заинтересованы в контроле процесса, чтобы не дай бог ничего не потерять и все успеть.
❗️❗️Но необходимо равновесие!
И Upstream и Downstream работают на одну цель: выполнение бизнес-плана, и в конечном итоге - успех бизнеса.
Upstream задает направление, и подготавливает все необходимое для производства, а Downstream уже обеспечивает реализацию запланированного.
Эти два процесса должны быть в балансе по отношению друг к другу и к потребностям бизнеса. Если этого не обеспечить - пострадает весь бизнес.
Если Downstream не обеcпечивает нужного качества производства, то покупатели не будут покупать продукт, и бизнес пострадает.
👉 Эта мысль лежит на поверхности, и поэтому, как правило, основные усилия менеджмента направлены именно на Downstream
Но вот о чем многие забывают, так это о том, что если Upstream поставляет на вход Downstream плохие продуктовые идеи, которые не соответствуют потребностям рынка, то как бы Downstream не старался сделать максимально качественный продукт, но на выходе из Downstream будет плохой продукт, который не нужен покупателям. И бизнес, может быть, пострадает еще больше.
🤷А так как, зачастую, процессом Upstream никто не управляет, то каждый заказчик действует лишь в своих интересах, и растит свой KPI, поэтому все действуют исходя из принципа: “главное запихнуть в производство, а дальше уже не наша зона ответственности”. В этом случае, Downstream из-за перегрузки будет работать совершенно не предсказуемо, и никакой бизнес-план не сойдется с реальностью.
❓Что делать?
На тренинге “Масштабирование Канбан-систем” мы с ребятами разбираем кейс одной крупной российской компании в области fashion-индустрии, с которой я работал. Там как раз наблюдался дисбаланс Upstream и Downstream (IT-департамент), что приводило к срыву планов бизнеса и постоянным конфликтам между бизнесом и IT.
В процессе работы я провел исследование того, как устроен в компании процесс Upstream и Downstream, собрал необходимые процессные метрики, которые иллюстрируют происходящее, и стало ясно, что основная причина в том, что если IT-департамент управлял своим рабочим процессом и выстроил довольно прозрачный и измеримый Downstream , то вот процесс Upstream не был выстроен вообще никак и им никто не управлял. Это был хаотичный поток “хотелок” от множества внутренних заказчиков, которые назависимо друг от друга “пихали” свои заказы в общий пул заказов IT, будучи уверены, что больше от них ничего не требуется.
Заказчики не общались между собой, и каждый из них считал, что его заказ - самый важный и нужный для компании. При этом они надеялись, что IT как-то само внутри себя разберется, как правильно составить план выполнения заказов и все будет хорошо.
И когда Downstream не оправдывал их ожиданий по срокам, заказчики жаловались генеральному директору, что IT опять не выдержал сроки, и вообще его работа представляет собой хаос, и поэтому вообще ничего нельзя планировать.
Налицо был перекос, который надо было устранять.
Благодаря исследованию, удалось подсветить руководству компании, что источник хаоса находится ДО Downstream, и именно в этом причина всех бед. Собранные метрики убедительно показали, что Downstream способен выдавать результат с достаточной предсказуемостью, но Upstream совершенно не учитывал производственные возможности Downstream, и отправлял в него совершенно неподготовленный и несогласованный поток заказов, что приводило к потерям и переработкам.
В условиях ограниченности ресурса, на вход в Downstream нужно подавать только самое нужные и важные задачи. Однако все заказчики действовали независимо друг от друга, и как правило в борьбе за ресурс IT побеждали те заказчики, которые громче кричали.
Совместно со стратегическим отделом компании была проделана большая работа по инвентаризации всех планов бизнеса, находящихся в Upstream, и визуализации всего этого на Upstream Канбан-доске. В результате стала видно вся потенциальная загрузка которую заказчики хотели "запихнуть" в Downstream.
Затем мы организовали стратегическую сессию с заказчиками и генеральным директором, на которой сделали ревью всех планов, и оставили только то, что соответствовало стратегии и годовым планам компании. По итогу, из общего списка выбросили почти половину планов, потому что они оказались устаревшими или не соответствовали годовым целям компании. На той же сессии договорились о правилах скоринга задач и квотах для каждого заказчика.
Все это позволило выровнять Upstream и Downstream и получить предсказуемость поставки на всем протяжении бизнес-процесса. После этого проявились ранее скрытые узкие места, которые замедляли поток работы. Но это уже совсем другая история 🙂, которую я расскажу в другой раз
P.S. Помните что от баланса двух этих процессов зависит успех всего бизнеса. Это как две ноги у человека. Хромает одна - и человек уже с трудом может придти к своей цели.
Берегите ноги :)) Обе. И изучайте Канбан-метод
Успехов!
Вопросы автору можно задать ему в личку или в телеграм-канале: "Данные в дейSTвии"
Перепечатка этой статьи или ее части возможно только с согласия автора