Технологические карты, оптимизация цепочек и немного Голдратта

Недавно вспомнили про такую штуку аж в двух (несвязанных) местах. Надо набросать базы, она нам потом пригодится.

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

Технологическая карта

Технологическая карта, в производственном смысле — документ, который описывает 1) отдельно взятый технологический процесс, а также 2) его ресурсные потребности и результаты.

С точки зрения процесса (1) — это разновидность flow diagram или, для простоты, тупо инструкция. Что у нас в процессе происходит, как именно это должно происходить, какие есть шаги, этапы и так далее. Зарубежная терминология так и оперирует общим термином process flow diagram, с дальнейшими уточнениями не особо парится.

С точки зрения ресурсов (2) интереснее. Для ТК принято четко формализовывать, что у нас является потребностью (для выполнения процесса), в количественном и качественном смысле; и что мы на выходе получаем, когда наш процесс будет выполнен, по любому из описанных вариантов.

Наглядный пример, для вашего базового понимания — кулинарный рецепт приготовления черничного пирога.

• вот такие ингредиенты нам потребуется взять, по списку, с заданными характеристиками
• вот такие операции над ними провести, вот в таком порядке
• вложить туда вот такое количество ресурсов (человеко-время, энергия)
• применить вот такой инструментарий, по списку
• получить на выходе вот такой результат, вот в таком количестве

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

С точки зрения процесса, методика ТК (то есть flow) дает нам описание процесса. Основное полезное качество — повторяемость. Соедини вот так ресурсы и исполнителя, получишь выход вот таком обьеме. Запусти два описанных процесса в параллель, получишь вдвое больше. Измени кратно количественные показатели — и, если процесс допускает, получишь кратно увеличение выхода (но тут есть нюансики). Сам процесс описан, и фундаментально не изменится.

С точки зрения ресурсов, методика ТК дает нам функцию. Как из одного получить другое. Взял 3 яйца, применил 20 минут человеко-времени и 1 нагретую сковороду, получил 200 граммов яичницы. С точки зрения процесса, мы имеем функцию process([resources...])=>result[]. А это уже математический аппарат. С этим можно далее работать, оптимизировать, скейлить, строить цепочки и играть во всё остальное процессное лего.

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

• логистика(100 рублей денег, 1 час человека) = 10 яиц из магаза
• кухня(3 яйца, 20 минут человека, оборудование) = 200 гр яичницы
• выдача(200 гр яичницы, 5 минут человека, чистая тарелка) = 100 рублей в кассу
• клининг(тарелка, 5 минут человека) = чистая тарелка

превращается количественными методами в производственную цепочку:

• логистика (100р, 1:00) + (3*кухня (3я, 0:20)) + (3*выдача (200гр, 0:05, 1т)) + (3*клининг (1т, 0:05)) = [300 рублей, 1 лишнее яйцо]

или, сворачиваем:

• бизнес(100 рублей, (1:00+1:00+0:15+0:15 = 2:30 времени))
  = [300 рублей, 1 лишнее яйцо]

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

Формально, мы могли бы расписать полную технологическую карту всей свёртки, но это не является обязательным. Нам нормально и с четырьмя отдельными, и с ними даже лучше, потому что гранулярность процессов (по отделным технологическим картам) позволяет к ним применить больше полезных штук. То есть — количественные методы.

Количественные методы

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

Что тут у нас: во-первых, ограничения по flow и цепочке

В упомянутом тупом примере вы не сможете поставить этап выдачи прежде этапа кухни (производства), потому что вам тупо нечего готового отдать. Но если у вас есть показатели запаса, выдача может работать самостоятельно пока запас не кончится.

Во-вторых, количественный скейл, с его возможностями и выявляемыми ограничениями

Этап логистики можно скейлить до какого-то предела, например за 1:00 час времени притащить не 1 коробку (10я) ресурса, а 10 коробок — за бОльшие деньги, но за тот же час. Тогда мультипликаторы (3*) дальше по цепочке теоретически можно увеличить тоже в 10 раз. А практически — исходя из располагаемого времени.

Это важный момент: упираемся мы всегда в меньший constraint. Если у нас фура с ресурсами, а времени людей под процессы больше не стало — выход у вас все равно количественно упрётся в самое слабое звено, отдельной техкарты или функции по ней. Бутылочное горлышко.

В-третьих, параллельность и возможности внутри получившегося flow (сложного, собранного нами из отдельных простых ТК)

Может выдача работать в параллель с кухней, или с клинингом? Да, может, если вы можете распараллелить потребление ресурсов. Если у вас ровно одна бабушка Маша и на готовке, и на выдаче, и на мойке — то скорее всего нет. Если это разные люди — то да. А если людей меньше чем процессов, то мы можем поиграть во взаимозаменяемость: пока торговать нечем, кто-то бежит в магазин с выдачи, там все равно нечего делать.

В-четвертых, циклы. Переиспользование ресурсов с выхода на вход дает вам автономную систему. Если есть, где брать всё необходимое.

Вот мы на выходе получили 300 рублей, а на входе было 100. Давайте мы из них возьмем еще 100 и запустим цепочку по кругу. Цепочка потребляет у нас 2:30 человеко-времени, значит за рабочий день 8 часов можно уложить ее 3 раза без параллельностей. Это даст нам при 3*100=300 рублей затрат итоговые 900 рублей в кассе. Если за оставшиеся 600 рублей у нас исполнитель (как ресурс времени) готов 1 день несложно поработать, значит наше ресурсное планирование вчерную сходится.

Производственные ограничения, включая неявные

В варианте одного исполнителя всё линейно выполняется. Если я хочу параллелить кухню, то рано или поздно N человек в ней начнут друг другу мешать. Значит, нам надо исследовать и усложнять конкретную техкарту кухни, вводить туда наличие свободного оборудования.

Это новые constraints, в начальной задаче их не было, потому что нам было пофиг — а вот теперь появились.

Голдратт и балансировка

Вот теперь пора добавить чутка мат.статистики. У нас для каждой техкарты и процесса есть два типа ресурса по определению:

— показатели запаса, N единиц чего-то
— показатели потока, N единиц чего-то / на время

Затраченное время человека — это тоже показатель потока, единица работы / на время. Вы не сможете взять 0:20 минут одним куском, их надо потратить. Но вы можете их запасти в готовом продукте. Запасенное время и прочие показатели потока чаще всего создают добавленную стоимость, органически — потому что время можно потратить и запасти, но нельзя купить готовой кучкой.

Почему здесь Голдратт. Потому что основной практический смысл его «теории ограничений» сводится к тому, что вся конструкция и цепочка будет подчиняться тому единственному ограничению, которое определяет максимальную скорость потока (или расходования показателей потока, что одно и то же).

Давайте я из цепочки чисто математически вытащу элемент «логистики» (З показатели запаса, П потока):

логистика(3, П) = бизнес(З, П) — 3*кухня(З, П) — 3*выдача(3, П) — 3*клининг(П)

Но показатели потока, которые про время, нам придется сжечь в любом случае; время пройдет без нас. Значит, чтобы уравнение сошлось в ноль, «логистика» в левой части обязана точно так же нести всю разницу затрат потокового показателя. И то, что требуется для её процесса, и те побочные затраты, которые содержатся в «П» второй части уравнения.

логистика (3, П + побочные_затраты)

Сколько их? Зависит от гомогенности показателя (чьё там было время в показателях потока). Если показатель гомогенный, то мы украли у соседних процессов ровно тот же 1:00 час, пока они простаивали и ждали нашу логистику. Если они запараллелены все, то одну логистику ждали аж три показателя, каждый по часу — мы впустую сожгли 3:00 часа рабочего времени людей.

В правой части есть слагаемое «бизнес», т.к мы математически его перекинули; и да, бизнес как цепочка тоже стоял и ждал 1:00, мы потратили не 3:00, а 4:00. Сначала звучит немного нелогично, но вспомните про недополученную прибыль, которую за час вся цепочка могла бы принести. Прибыли нет, а время цепочки потрачено.

Стоимость этого несчастного часа «логистики», когда все всех ждали, будет составлять (100 р ее затрат + 1:00 ее времени + 4:00 потерь) = 100р + (600/8*5) = 475 рублей. Это я еще время линейное посчитал, из прикидки выше. Неплохо так, еще ничего не сделали, пользы не принесли, а затрат = почти на весь день выручки.

Для нормализации можно считать поток по времени, можно считать деньги/время, можно считать ресурс/юнит (о, юнит-экономика приехала). Неважно, в чем считаете, лишь бы единообразно и одинаково.

Для балансировки цепочек по Голдратту есть три самых популярных направления: они есличо не самые оптимальные (обычно локальный оптимум), но самые наглядные.

• барабан (drum): согласно потреблению З и П в каждом процессе и каждой ТК, нормализуем выход по времени. Сколько нам нужно тратить всего, что нам требуется, в идеальной картине мира и полной загрузке. Поскольку время общее, нормализованное, мы можем посчитать поток и время в пересчете на любой его кусок — например, на час, или на день. Появляется оптимальный ритм работы цепочки и производства (поэтому «барабан»), в котором производительность максимальна. А дальше соотв пытаемся к нему прийти и устремиться.
• буфер (buffer): для каждого процесса и каждой ТК у нас есть запас ресурса, который мы запасти можем. То есть, показатели запаса. Тогда затраты показателей потока, в первую очередь время, у нас ограничены только течением времени. Таким образом, в конкретном отдельном процессе будет совершаться работа, пока есть ресурсный запас. Это прикольная модель, потому что 1) мониторинг запаса дает значительную гибкость и 2) есть расширенные варианты, типа цветного буфера, когда можно размазать потребности по запасам по скорости расходования. Базовая оптимизация — достичь ресурсного оптимума запасов (с учетом их стоимости) по отношению к дельте времени отдельных процессов и/ли простоев.
• веревка (rope): метод обратной оптимизации по выходу и затраченному (планируемому) времени: из примера выше, если мы хотим получить 1 готовое блюдо в час X, то нам надо начать чесаться за 2:30 раньше и обеспечить всё необходимое к (T-2:30) или ранее. Если хотим 900 рублей в кассе за день, то все необходимые ресурсы должны быть доступны/свободны на начало дня в нужном обьеме. Начиная с «логистики», поскольку требование по выходу «тянет» за собой последовательно все нужные ресурсы и результаты, и придёт в нее, как в стартовый процесс. Поэтому «веревка» (иногда «канат»), за который мы тянем.

Где подвох

Подвох в красивой и стройной модели «техкарты и цепочки» лежит там, где процессы и реальный мир в стройную картину не вписываются. Карта не_равна территории, теория не_равна практике. Что-то пошло не так, техкарта не выполнилась, цепочки не запараллелились, кто-то кого-то ждёт, всё встало раком и смотрит грустно.

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

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

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

Например: у нас есть процесс разруливания херни. Он по определению исследовательский и нетиповой: сколько той херни бывает в жизни. Но мы вполне можем описать под-процесс оценки херни: потратить суммарный час времени вот этих ключевых специалистов, и на выходе получить документ, внутри impact map, оценка рисков и 2-3 плана обработки. Потратить еще час, и выбрать + расписать один из планов, которые берем в работу.

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

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

Поймем как мерить, как улучшать, и как заинтегрить улучшенное — так и сделаем. Пока не сделали, работаем по старому, пофиг что неоптимально, spice must flow, механизм простаивать не имеет права.

Пока нечего даже мерить, управление (и улучшение) будет идти по принципу «кто громче орёт», или вообще тупым перебором, а нам такое не надо.

Пока хватит. Hope that helps.