Базовая онтология работ
Мы можем наконец перейти к описанию базовой онтологии работ. Базовой она будет потому, что мы выделим наиболее общие объекты внимания и наборы понятий, описывающих эти объекты. Вы найдете такие объекты в любой прикладной онтологии работ, например, в онтологии работ TameFlow. В прикладных онтологиях работ вы найдете и дополнительные объекты, которые на данном уровне моделирования не выделяются. Но сейчас нас волнуют наиболее важные объекты, которые нельзя упустить (=на которых нужно удержать внимание), когда вы управляете работами или моделируете их.
Самый базовый объект внимания – это **рабочая станция/**workstation **или производственная линия/line/**routing, то есть, создатели в терминологии операционного менеджмента, которые выполняют работы по методу и выдают некоторый результат/производят некоторый объект, связанный с вещью. Рабочая станция или производственная линия – это физический объект. Можно даже говорить, что это функциональный физический объект, ведь он выполняет работы по какому-то выделенному методу. Нам важно, что объект не ментальный, а физический, мы должны иметь возможность найти индивида, соответствующего рабочей станции или производственной линии в физическом мире. Не можете показать на физический объект, который выполняет работы по методу, а показываете на описания – у вас проблемы.
Как уже раньше говорили, рабочую станцию или производственную линию можем выделить на любом уровне организации. Можем сразу описывать целую компанию или группу компаний как рабочие станции или производственные линии; можем описывать подразделение; можем описывать команду; можем описывать сотрудника. На каком уровне организации остановиться? Обычная рекомендация – обратить внимание, на каком уровне вы работаете и на каком у вас есть полномочия проводить оргизменения, и моделировать потоки работ на вашем уровне +/-1 уровень. Если вы управляете командой, то ваш базовый уровень – уровень команды. В таком случае вам надо в первую очередь описать команду как рабочую станцию, являющуюся частью какой-то более крупной производственной линии и производящую некоторый объект, связанный с вещью. Например, вы управляете контентной командой, которая производит контент – статьи с описанием ситуаций, с которыми сталкивается ваш клиент, и методами разрешения этих ситуаций. Вещью компании является мастерство, которое появляется у клиентов, работающих в описанных вашей командой ситуациях описанными вашей командой методами. Вы можете замерять, как идёт (или не идёт) прирост мастерства у клиентов после изучения ваших статей и применения описанных в них методов.
Контентная команда как рабочая станция выдаёт статьи, благодаря которым идёт приращение мастерства. Однако сама эта команда:: рабочая станция:: создатель является частью более крупной производственной линии:: создателя. В компании может быть несколько контентных команд, то есть, сразу несколько рабочих станций выдают статьи для приращения мастерства. Причём темы, которые берут разные команды для статей, могут пересекаться. Это означает, что у вас появляются коллизии, которые надо обсуждать и разрешать: нужно выработать единообразие в методах разрешения ситуаций одного класса. Не должно быть так, что одна контентная команда пишет клиентам одно, а другая – другое. Далее, нужно понимать, как контентная команда или даже набор контентных команд встроены в граф создателей мастерства. Какие еще есть рабочие станции, кроме станции класса «контентная команда», которые создают мастерство? Можем ли мы проследить, как создается мастерство отдельно взятого клиента (индивид)? Вот такое описание нужно получить в первую очередь, если вы хотите оптимизировать работу вашей команды. Оптимизация работы всегда проводится как минимум с уровня на один выше вашего! Приоритеты задаются с уровней выше!
Во вторую очередь нужно будет получить описание на уровень ниже этого, то есть, описание контентной команды как производственной линии. Теперь вы понимаете, как выглядит более крупная производственная линия/цепочка/line/routing, частью которой является ваша команда, понимаете, как она встроена в эту цепочку/граф и какой результат должна давать. Теперь можно организовать команду на выполнение работ так, чтобы она, собственно, дала нужный результат в нужные сроки. Для этого нужно описание команды как производственной линии, включающей в себя различные рабочие станции, работающие разными методами, например, автора статей (эксперта), который пишет статьи, редактора, который их редактирует, корректора, который правит ошибки, публикатора, который публикует, возможно, контентщика, который подбирает темы для статей и отслеживает, что происходит с мастерством клиентов после публикации статьи. Вы можете составить модель команды как производственной линии, если заземлитесь: выберете какой-то конкретный кусочек мастерства, который отращиваете конкретному клиенту(ам), выпуская конкретную статью или серию/набор/поток статей.
Важное замечание: когда моделируете, вы можете обнаружить, что реальная производственная линия, через которую путешествует объект, как-то связанный с вещью, включает в себя рабочие станции, которые физически находятся вне вашей компании. Например, есть юридическая компания, которая занимается банкротствами, то есть, утилизирует обязательства в сделке:: вещь. Через её производственную линию проходит судебный кейс, в рамках которого утилизируются обязательства в сделке. При моделировании выяснилось, что в состав производственной линии входит рабочая станция «арбитражный управляющий», которая выполняет работы по методам утилизации обязательств[1]. Но физически арбитражный управляющий находится вне юридической компании, не подчиняется её руководству. И оказалось, что арбитражный управляющий, с которым работает эта компания, имеет несколько помощников, между которыми перераспределяет работу. Сотрудники постоянно перекидываются с одних кейсов на другие, работают не только с этой юридической компанией, но и с другими. В результате они недостаточно погружены в судебные кейсы компании и делают ошибки, приводящие к переделкам/rework и растягиванию сроков выполнения работ на полгода и являются самой медленной рабочей станцией (кроме суда, на который повлиять на данный момент невозможно[2]). В итоге руководители договорились с арбитражным управляющим, что он выделяет им одного сотрудника, который не переключается на кейсы других компаний и полностью погружен в контекст, а они, со своей стороны, обязуются обеспечивать загрузку этого сотрудника. В итоге юридической компании удалось уменьшить число переделок из-за невнимательности арбитражного управляющего, благодаря чему сроки рассмотрения кейса уменьшились на 6 месяцев! И это удалось обнаружить благодаря моделированию потоков работ.
После того, как вы определились с базовым уровнем для моделирования, а также уровнем +1 и -1, выделили рабочие станции и производственные линии, можно описать поведение/действия этих рабочих станций или производственных линий, или работы по методу. Объект (рабочая станция или производственная линия) демонстрирует поведение (работы по методу) для преобразования/transformation путешествующих через предприятие объектов. Для начала надо будет назвать, какие методы/функции выполняются, а затем указать среднее потоковое время выполнения класса работ по методу/average Flow Time[3], чтобы было понимание, сколько выполняются типовые работы по методу[4]. Например, автор пишет статью в среднем 30 часов от события «начала статьи» (было касание/touch статьи, например, начал составлять структуру статьи по выбранной теме) до события «завершения статьи» (статья передана следующей рабочей станции – редактору, и редактор не дал автору никаких правок для внесения в статью[5]).
Методы как паттерны выполнения работ более-менее устойчивы. Но реальные работы обычно демонстрируют **изменчивость/**variability по специальным/special cause или типовым/common cause причинам. Изменчивость – это свойство работ меняться. Каждый экземпляр работы по методу в физическом мире хоть немного, но отличается от другого экземпляра/акта работы. Некоторые из этих отличий мы считаем несущественными, ниже «порога реагирования». Например, если в один день вы подписывали акт приемки-передачи 5 минут, а в другой день это заняло 10 минут, то такие различия мы игнорируем: просто выделяем на работы по подписанию документов (всех, а не только акта для конкретного клиента), например, полчаса в день, и укладываемся в это время со всеми флуктуациями. Однако некоторые отклонения в ходе выполнения работ оказываются существенными. Например, инструмент, которым вы пользуетесь для выполнения работ, сломан или недоступен, из-за чего начатая работа не может быть завершена в обычное время. Или выясняется, что задача, над которой вы работали, сложнее, чем вы думали перед началом работы (во время предварительной подготовки). Потоковое время рабочей станции увеличивается, соответственно, время до доставки объекта покупателю тоже увеличивается.
Изменчивость характерна не только для работ создателя (рабочей станции или производственной линии), но и для спроса. Спрос на выполнение работ по созданию объекта, связанного с вещью, меняется в зависимости от рыночных трендов, сезона и так далее. Эту изменчивость предлагается измерять и учитывать при планировании работ, для чего есть специальная литература[6].
Причины изменчивости делятся на типовые и специальные, они вызывают, соответственно, отклонения по типовым или специальным причинам. Отклонения по специальным причинам обычно нельзя предусмотреть заранее, это «серые» или «чёрные» лебеди по Талебу. Отклонения по типовым причинам (например, наличие брака, переделок/rework, уменьшение производственной способности/capacity из-за ухода сотрудника в отпуск или увольнения) предусмотреть можно, и можно сделать так, чтобы выпуск не уменьшался значительно каждый раз, когда происходит какое-то ожидаемое изменение. Для этого операционный менеджер использует буферы. В самом простом варианте вы учитываете, что у вас или ваших сотрудников какой-то процент доступного рабочего времени (рабочей мощности), например, 30% от 5 часов продуктивного времени будет уходить на решение стихийных задач. Соответственно, вы закладываете буфер в 0,3 * 5 = 1,5 ч, и наиболее важные задачи планируете на 3,5 ч оставшегося продуктивного времени – то есть, закладываете буфер времени.
Всегда ли изменчивость – это плохо? Нет, конечно. Если ваши маркетологи и продажники улучшили методы маркетинга и продаж и стали выполнять больше работ, то у компании увеличится число клиентов, а следовательно, и спрос на работы. Это положительное изменение. Также чем больше у вас продуктов, тем больше у вас изменчивость/variability в создании каждого из таких продуктов – вы обмениваете возможность заработать больше на продуктах на увеличение изменчивости. Поэтому не всегда оптимально пытаться уменьшать изменчивость: расходы на уменьшение могут превысить выгоду. Как определить, когда остановиться, когда мы пытаемся управлять текущими работами? Если вы честно выполнили задания в начале руководства, то вы уже вычислили скрытые задачи, проекты, которые следует отложить и прочее, что замедляло выпуск и увеличивало слишком сильно изменчивость ваших работ и работ ваших сотрудников. Основные причины изменчивости теперь, вероятно, связаны с изменениями в методах проведения работ, а также с особенностями применяемых методов. Например, вы с командой пробуете описать гипотезы по улучшению продукта – и внезапно обнаруживаете, что работы в этот раз дались вам легче, а в следующий раз – сложнее. И вы не можете заранее точно сказать, когда вам будет сложно, а когда – легко. Такова особенность знаниевых работ/knowledge work, которые выполняются методами поиска и формулирования гипотез (т.е. «когнитивноёмкие» методы). При применении новых методов выполнения работ время выполнения работ тоже будет меняться не очень предсказуемо поначалу, пока не стабилизируется в каком-то диапазоне.
По итогам выполнения работ должны появляться предметы работ/workitems, которые мы также можем называть рабочие продукты. Предметом работы может выступать и вещь, и часть вещи, и описание вещи, и описание создателя, и так далее. Вы уже определяли ваши рабочие продукты, которые передаются другим; теперь вы можете определить, какие именно рабочие продукты/предметы работ/work items и каких типов передаются между рабочими станциями в вашей производственной линии.
Мы можем говорить как о передаче отдельных рабочих продуктов, так и набора/set рабочих продуктов, например, набора описаний, составляющих конструкторскую документацию, набора фичей, составляющих релиз. Эти предметы работ считаем в штуках; и эти штуки и есть ваша «незавершёнка» или Work-in-Progress, WIP. По закону Литтла (о нем далее) WIP связан с потоковым временем/Flow Time и выпуском/Throughput Rate следующим взаимоотношением:
средний WIP = среднее FlowTime/CycleTime * средний ThroughputRate, то есть,
среднее число незавершенных предметов работ = среднее время работы над объектом до завершения * средний выпуск.
Это фактически уравнение движения объекта, с которым вы знакомы из физики: путь = время * скорость. «Путь» тут – это очередь из «незавершенки», время – время выполнения работ с события «начала работы» до события «завершения работы», скорость – это скорость выпуска (выпуск считается в единицах измерения (например, штуках) за единицу времени и представляет собой первую производную пути по времени).
Также в онтологии работ нам будет важно выделить и назвать такой объект, как «запасы». О запасах обычно имеет смысл говорить, когда через предприятие путешествует физический объект, а не описание. Например, если завод изготавливает испытательные стенды для испытания опытных образцов топливной системы самолёта или супермаркет продаёт продукты. В случае если вы работаете с описаниями, у вас могут быть «заготовки», подготовленные в ходе предварительной подготовки, но это не запасы/stocks, ими обычно не управляют. Запасы физических объектов, например, товаров, создаются для компенсации неблагоприятной изменчивости. Создатели производят больше товаров, чем нужно для продажи, излишки отправляют в «буфер запасов»/inventory buffer, из которого товары потребляются по мере необходимости. Тема управления запасами достаточно сложная, существуют отдельные учебники, которые описывают, как управлять запасами лучше[7].
Для создания объектов на предприятии используются ресурсы. Ресурсами считаем такие объекты, которые используются для создания других, но не становятся частью создаваемых объектов. Например, терминал оплаты на кассе магазина используется для обмена товаров на деньги (вещь типа «сделка»), но ни в какой момент не становится частью продаваемых товаров. Сырье и материалы физически становятся частью объекта, например, металл становится частью трубы, а вот сварочное оборудование – нет.
К ресурсам можем отнести инструменты, которые используются для выполнения работ (включая экзокортекс), а также часы, потраченные создателем на выполнение работ (причем помним о том, что их меньше, чем вы думаете), мастерство сотрудников, и так далее. Кроме того, еще одним ресурсом можно считать **производственную мощность/**capacity рабочей станции или производственной линии.
Производственная мощность считается как предельный выпуск рабочей станции, или максимальный потенциальный выпуск рабочей станции за единицу времени за исключением типовых потерь выпуска. То есть, сначала мы считаем, сколько предметов работ/work items можно выпустить в идеальных условиях: при отсутствии переделок/rework, брака, настроек оборудования, отключений электроэнергии и Интернета, внезапных отгулов сотрудников, при наличии минимально необходимого количества незавершёнки/WIP и так далее. Например, автор в контентной команде может написать статью:: предмет работы/work item за 30 часов работы, это чистое потоковое время/Flow Time без учета переделок/rework. Если его продуктивное время составляет 5 часов в день, то для создания статьи и передачи её следующей рабочей станции – редактору – требуется 6 рабочих дней. Одна статья за 6 рабочих дней или 8 календарных (с учётом выходных), или ~0,83 статьи в неделю[8] – это идеальная производственная способность автора.
Однако в реальности она недостижима. Примерно 30% времени уходит на ответы по прошлым выпущенным статьям, обсуждения, какие темы для статей выбрать, на переделку, и так далее (типовые «потери» выпуска, которые нельзя устранить полностью). Соответственно, на статьи остается 5*(1 – 0,3), или 3,5 часов в день. Тогда одна статья может быть выпущена за 30/3,5, или 8,6 рабочих дней или почти 9 календарных дней. Одна статья за почти 9 дней – это реальная производственная способность. Дополнительно можно учесть внезапные смены тем для статей, из-за которых приходится откладывать заготовки одних статей в сторону и писать новые, отпуска, болезни и так далее. Производственная способность может оказаться равной 1 статье за 10 рабочих дней или 2 недели, или 2 статьи в месяц. Мы предлагаем замерить вам производственную способность/мощность/capacity ваших рабочих станций за выбранный период времени (в минуту, час, день, неделю, месяц – какой период имеет для вас смысл[9]). Может оказаться, что имеющаяся у станции производственная мощность меньше, чем вы думали, и рабочая станция физически не может увеличить выпуск без каких-то изменений (например, изменений в методах работы).
Но и эта реальная производственная способность в реальности практически недостижима. **Производственная способность/производственная мощность/**capacity численно представляет собой предел/ограничение «сверху» на выпуск. Операционный менеджер стремится к тому, чтобы реальный выпуск предприятия (в учебниках операционного менеджмента называют обычно Throughput или output) стремился к его производственной способности/capacity. Но в реальности он не достигается устойчиво/стабильно на хоть сколько-нибудь длительном промежутке времени. В реальности выпуск меньше производственной мощности, это один из базовых/основных принципов физики предприятия/Factory Physics.
Почему так происходит? Потому что в реальности 100% (и тем более более чем 100%-ной) загрузки производственной мощности/capacityutilization****не бывает. «Кто-то (или что-то) всегда ждёт»: покупатели ждут рабочие продукты/результаты работ/предметы работ/work items, предметы работ/рабочие продукты ждут, что рабочие станции освободятся и смогут начать работы над ними; запасы ждут покупателей, которые предъявят спрос на них. Если вы рассчитали загрузку производственной мощности/capacity utilization и она оказалась выше 100%, то вы используете дополнительные ресурсы, благодаря которым вы получили дополнительный выпуск**, но не учли это в расчетах**. Такое может происходить в краткосрочном периоде. Например, у вас сезонный всплеск спроса на товары (вещь) перед Новым годом. Чтобы справиться с повышенным спросом, вы привлекли дополнительных сотрудников, арендовали на время дополнительную машину для перевозки товаров, и так далее. У вас появились дополнительные ресурсы, которые обеспечили вам дополнительный выпуск. Рассчитанная ранее долгосрочная производственная мощность/способность/сapacity для «обычного» времени не пересчитывалась, потому что этими дополнительными ресурсами вы пользуетесь временно, в краткосрочном периоде; как только спрос спадёт, вы вернётесь к «нормальным» условиям работы. В таком случае допускается считать, что ваша долгосрочная производственная мощность не увеличилась, и в краткосрочном периоде показывать загрузку производственной мощности больше 100%. Но лучше вместо этого рассчитать расширенную производственную мощность/extendedcapacity, которая включает в себя обычную производственную мощность плюс дополнительную, которая появилась благодаря докупленным дополнительным ресурсам.
В случае если на вашем предприятии работники систематически перерабатывают и обеспечивают за счёт переработок дополнительный выпуск, то вам требуется рассчитать расширенную долгосрочную пр****оизводственную мощность/extendedcapacity, потому что де-факто вы «купили» (платно или бесплатно) дополнительную мощность, благодаря чему у вас есть прирост выпуска. Нужно оценить, сколько производственной мощности/capacity докупило предприятие, а также – какой дополнительный выпуск (прирост выпуска) был обеспечен этим. Тогда вы сможете оценить, насколько выгодно/рационально решение докупать мощность. Если ваши сотрудники занимаются интенсивным интеллектуальным трудом, который принципиально нельзя автоматизировать при помощи ИИ или довести до состояния «полумеханического применения по чеклистам»[10], то возможностей «докупить» у тех же самых сотрудников дополнительную производственную мощность очень мало. Интенсивно думать каждый день по 8 часов стабильно в долгосрочном периоде для человека невозможно. Соответственно, если продуктивное время сотрудника уже составляет 5-6 часов в день, за которые он решает 2-3 важные задачи, то взять и «докупить» решение дополнительной задачи за 3 дополнительных часа на постоянной основе невозможно. Действие «докупить ресурс» не поможет, нужно будет менять методы работ, например, подключать нейросети, как это делают наши стажеры[11].
Ещё один вариант – ваше предприятие не находится в стабильном состоянии, то есть, работа не налажена, происходят очень серьёзные изменения, переворачивающие предприятие вверх дном; постоянно и очень резко меняется производственная мощность. В таком случае расчёты не будут надёжными. Требуется навести порядок: в работах (создаём очередь задач на выполнение, берём задачи в работу из очереди; не планируем задач больше, чем можем выполнить в день, те применяем ресурсное планирование и не превышаем нашу производственную мощность; выбираем важное – то есть делаем то, о чем говорили в течение первых недель стажировки), разобраться с методами выполнения работ (отмоделировать методы, начать применять). Затем – стабилизировать работу предприятия. Лишь после можно двигаться дальше.
После расчётов загрузки производственной мощности/сapacity для рабочих станций мы сможем увидеть, какая из них является ограничением/самым узким местом. Обычно это станции с самой высокой загрузкой. Сроки выполнения работ мы считаем с учетом потокового времени самой загруженной станции.
При выполнении работ через компанию движется не один поток, а несколько:
- Поток денег/финансовый поток/FinancialFlow;
- Поток работ или поток предметов работ/workitems**,** он же Operational****Flow;
- Поток информации/информационный поток/InformationalFlow;
- Когнитивный поток (известен разработчикам как «состояние потока» или «ощущение потока»), он же Cognitive****Flow.
Поток денег интересен на уровне обособленного экономического агента (предприятие в целом). Нужно знать, сколько зарабатывает компания на каждой производственной линии по выпуску объектов, связанных с вещью. Для оценки потока денег в TameFlow предлагается применять метрику финансового выпуска/финансового прохода/Financial Throughput Rate: вычитаем из полученной за выбранный период выручки полностью переменные расходы, понесенные на создание и поставку дополнительного экземпляра объекта, проходящего через предприятие (дополнительного предмета работ). Например, вычитаем стоимость сырья и материалов, потраченных на производство единицы мороженого. Подробнее об этом можно узнать в книге Throughput Accounting. Метрика финансового выпуска компании позволяет показать финансовый результат компании в целом; усилия менеджеров должны быть направлены на увеличение финансового выпуска (вслед за ним увеличится и возврат на активы / возврат на инвестиции).
Поток работ/поток предметов работ/Operational Flow интересен на уровне отдельной производственной линии по выпуску вещи. Для его оценки используют метрику операционный выпуск, или количество незавершёнки/незавершённых предметов работ/WIP за выбранный период времени. Обычно незавершенки много, поэтому большинству имеет смысл в принципе уменьшить количество незавершёнки в компании. Уменьшайте, пока не обнаружите, что выпуск падает: это означает, что вы слишком много всего убрали, и ваши рабочие станции можно подгрузить ещё немного.
Информационный поток позволяет обеспечивать быстрое прохождение координационных актов. Для оценки информационного потока используют метрику скорости получения обратной связи, или метрику задержки обратной связи, или лаг между событием «выполнена работа по методу (и передан рабочий продукт/результат работ/предмет работ/work item)» и событием «получена обратная связь». Чем больше компания, тем больше внимания следует уделять информационному потоку и прохождению координационных работ; они начинают ограничивать выпуск компании. Также уместно подключить методолога и оргпроектировщика для проектирования петель обратной связи в явном виде.
Наконец, последний поток – это когнитивный поток отдельно взятого сотрудника. Внимание ограничено, работа индивида легче всего выполняется в «состоянии потока»: когда сотрудник (или несколько сотрудников, как в случае парного программирования) имеет возможность поработать несколько часов в фокусе, не отвлекаясь на координационные акты, и при этом решать достаточно сложную проблему. Частые переключения и отвлечения не позволят достичь этого состояния; ресурс времени, который можно использовать для выполнения сложных работ, следует по возможности защищать. Для этого требуется коллективно выяснить, какие проекты и задачи являются приоритетными, ограничить их число и работать над небольшим количеством, но важных задач и проектов. Кроме того, нужно выяснить, в какие периоды в течение дня у вас (или вашего сотрудника) максимальная работоспособность, и стараться сложные работы поставить на это время. Если вы выполнили задание по аудиту времени из раздела «Различать модели и физический мир», то вы знаете, когда вам легче сосредоточиться; если вы выполнили задания из разделов «Различать метод и работу» и «Концентрироваться на важном», то вы уже договорились по поводу важного. Теперь можно отслеживать наличие у вас (или ваших сотрудников) слишком легких или, наоборот, слишком сложных задач. Если накопилось n-ное количество легких задач, то вы, скорее всего, давно ничего не делегировали и пора бы этим заняться; если есть задачи, решение которых сильно затягивается, то, вероятно, сложность соответствующей задачи слишком велика. Нужно попросить помощи у команды, пойти подучиться или сменить предмет работ на более легкий: например, сначала сделать лишь отдалённо похожий MVP и постепенно менять его, приближая к запланированному изначально.
Наконец, операционный менеджер должен удерживать внимание на буферах как ресурсах для компенсации изменчивости, или разрывов в спросе и предложении/преобразовании/создании. Операционный менеджер активно управляет буферами, чтобы не допустить уменьшения или замедления выпуска/Throughput. О том, как он это делает, поговорим далее.
https://www.sravni.ru/bankrotstvo/info/arbitrazhniy-upravlyayuschiy-po-bankrotstvu-kto-eto-i-zachem-nuzhen/ ↩︎
Когда компания станет достаточно крупной, ей нужно будет пробовать проводить проекты выгодных ей изменений на уровнях выше уровня компании. Например, достаточно крупная юридическая компания может пролоббировать запуск пилотного проекта по применению ИИ для помощи судьям в решении типовых дел. Подобные судебные ИИ уже вовсю используются в Китае. ↩︎
Среднее время – не лучшая метрика, но когда у вас вообще нет никаких описаний времени выполнения работ, начните с него. ↩︎
Считать, конечно же, нужно по реальным данным ↩︎
Как уже говорили, как определять «событие начала процесса» и «событие завершения процесса», зависит от вас. Мы рекомендуем «событием начала» считать первое касание предмета работ/будущего рабочего продукта/work item, а «событием завершения» считать событие не-получения дальнейших правок предмета работ/рабочего продукта/work item, поскольку получение правок означает необходимость переделывать/re-work рабочий продукт и невозможность передавать его последующим рабочим станциям. ↩︎
Factory Physics for Managers, Factory Physics ↩︎
Foundations of Inventory Management – Paul H. Zipkin ↩︎
5 ч/день * 5 дней – это 25 ч, осталось доработать 5/30 часов, чтобы была целая статья, соответственно, есть 1 – 5/30, или примерно 0,83 статьи на конец недели. ↩︎
Обычно это минимальный временной период, за который проводятся какие-то значимые изменения (работы по преобразованию объектов и получению предметов работ). Например, для станков может иметь смысл период в 1 минуту, для терминалов оплаты – 30 секунд – 1 минута. Для ИТ-разработчиков, готовящих релизы, обычно имеет смысл брать период в 1-2 недели, хотя в топовых компаниях микро-релизы могут проходить несколько раз в неделю. ↩︎
Возможностей автоматизировать выполнение работ по методам обычно больше, чем об этом думают. Посмотрите воркшоп нашего мастера, который сейчас автоматизирует работу тестировщиков в команде, которая разрабатывает софт для платёжных терминалов: https://www.youtube.com/watch?v=SOw0X8cl3fg ↩︎
https://systemsworld.club/t/kak-ya-osvoil-novyj-metod-raboty-analiz-tablichnyh-dannyh-s-programmirovaniem-na-russkom/22223 ↩︎