Unlike a ‘floater’, a waterspider is assigned specific tasks, such as replenishing raw material inventories (via milk run), common area clean-up, communicate status, maintain visual metrics, etc… Waterspider duties usually don’t include tasks which take them away from the production area, or [...]]]> The term Waterspider or water beetle (mizusumashi in Japanese) comes from the behavior of the insect known in the States as a whirligig, an aquatic animal that skitters around on the top of a pond quickly changing direction as it goes.  For a lean enterprise the role of material handlers, expediters, and support staff changes. In the Toyota Production System this is the common name for a person assigned to support a production operation, so that others may focus exclusively on value-added work. The waterspider delivers parts to the other associates in the cell or on the line so that they don’t need to stop to replenish their work stations.

Unlike a ‘floater’, a waterspider is assigned specific tasks, such as replenishing raw material inventories (via milk run), common area clean-up, communicate status, maintain visual metrics, etc… Waterspider duties usually don’t include tasks which take them away from the production area, or detract from their specific, assigned duties (the waterspider is not the ’5S’ person or a ‘fill in’). Think of the waterspider as the ‘race car pit crew’ for the production team, without which it would be impossible to win or even run the race.

Waterspiders quickly become experts in the withdrawal and production kanban system. They can ‘see’ more of the up and down stream flow in real time than most others, and because of this often making it possible to identify and eliminate errors. From recent experience the waterspiders often have a better grip on reality than their managers, planners, and engineers.

Non manufacturing examples abound in restaurants, hospitals, insurance claims processing; serving the folks that add the value isn’t just for manufacturing. In product and software development the role of the program manager is sometimes something like that of the waterspider, except bringing knowledge to the various development team members instead of parts.

Here are a few references:
Single piece flow at ConMed Linvatec
Improving Workflow With Water Spiders at University of Michigan Health System
Inventory management in electronics manufacturing: The Move To Lean
Lean in the Oil Fields

Have any examples you’d like to share?

Number of kanban = (Daily Demand * (Replenishment Time + Safety Margin))/Standard Container Quantity

Many engineers and black belts will immediately jump on a computer and start picking icons and naming data elements perhaps out of habit, maybe confusing quantitative tools with qualitative. VSM is good for describing what we are going to do to affect the numbers we collect. Building databases, multiple future state scenarios, or heaven forbid monthly performance metrics perhaps misses the point of being able to visualize the “what”. All too often folks will get so mesmerized by the technology they loses sight of the group dynamic of discussing the process they are meant to be studying.

Don’t waste your time and money fiddling with a new software application. Just get the right people together physically or virtually, and with some paper, pencils, markers, and sticky notes start sketching and talking. Save the computer for later.

Taylor, Frederick Winslow (1856-1915), American industrial engineer, who originated scientific management in business. He was born in Germantown (now part of Philadelphia), Pennsylvania. In 1878, he began working at the Midvale Steel Company. He became foreman of the steel plant and applied himself to studies in the measurement of industrial productivity. Taylor developed detailed systems intended to gain maximum efficiency from both workers and machines in the factory. These systems relied on time and motion studies, which help determine the best methods for performing a task in the least amount of time. In 1898 he became joint discoverer of the Taylor-White process, a method of tempering steel. Taylor served as consulting engineer for several companies. His management methods were published in The Principles of Scientific Management.

A standard approach for creating a new production facility layout for either a green field or an existing facility is as follows:

PQ (Product Quantity Pareto ABC Analysis) and Product Process (find common routings in a mixed model business) are defined elsewhere. For many practitioners Block Layout seems be be either a bit of artistry or is mired in software complexities.  Here are a few thoughts on how to approach this step in the facility design process.

First a few considerations:

In a green field we know the product and process and want to determine the size of the building we need and it’s layout.  For a brown field we’re trying to make the best use of the use of the four walls we already have.  In both scenarios there are [...]]]>

A standard approach for creating a new production facility layout for either a green field or an existing facility is as follows:

1. Perform PQ Analysis
2. Preparing a Product Process Routing Matrix
3. Develop Block Layout alternatives
4. Optimize the size, shape, placement of the blocks.
5. Nimawashi

PQ (Product Quantity Pareto ABC Analysis) and Product Process (find common routings in a mixed model business) are defined elsewhere. For many practitioners Block Layout seems be be either a bit of artistry or is mired in software complexities.  Here are a few thoughts on how to approach this step in the facility design process.

First a few considerations:

In a green field we know the product and process and want to determine the size of the building we need and it’s layout.  For a brown field we’re trying to make the best use of the use of the four walls we already have.  In both scenarios there are trade offs to make.  Having a decision making at the beginning of the project can save a lot of time and money.  Some will take a mathematical approach, others organic consensus.  Either way agree on the design process methodology up front.

Determine “best” layout type based on customer demand, product and processing characteristics, and business strategy.  Common layout types include:

1. process functional – group common machines or processes together
2. product – line up equipment in sequence of operation
3. fixed position – for large projects where you can’t move the product
4. hybrid – mixed model, shared monument, group technology cells

In brown field facilities the main layout consideration is often in fact moving from one layout type to another as business conditions and strategies evolve.

Determine the activity and proximity relationships between the various blocks.  A great approach for understanding relationships is the Simplified Systematic Layout Planning method by Muther and Wheeler.

The Product Process Routing Matrix noted above determines the quantity and type of equipment needed.  One complication is that very expensive or large machines may need to be shared, so compromises may need to be made.  I like the table top trial and error Paper Doll approach.  Once we’ve gathered data on the importance of proximity and activity relationships between blocks, equipment footprints, maintenance and material handling access and clearance requirements, utilities, building codes, facility constraints, etc. and then we determine the gross footprint size. Now through trial and error we arrange the equipment in the block in a logical flow or sequence manner.  We then have a beauty contest and subject each alternative to a decision selection matrix where we score and rank various design factors such as compactness, adjacency (relationship closeness), least travel distance (material handling cost and speed), etc.

The number of permutations can be huge, so either use group intuition for the block details or investing in one of the current software packages such as Pro Planner, PlanOpt, Flow Planner.

When asked recently to recommend reference books on Kanban here’s what I came up with…

Kanban for the Shopfloor is a straightforward implementation instruction manual.  The language is plain and simple.  The implementation checklist is complete.  Kanban Just-In-Time at Toyota is a translation of a book published by the Japanese Management Association in 1986 and is based on the seminars given by Taiichi Ohno to Toyota suppliers.  The language is a bit rough in places, but the concepts are presented in logical manner.  The philosophical parts may not play well with factory workers, the prior book would be a better choice.  Custom Kanban by Ray Louis comprehensive, detailed, and well written.  The methodical approach offers some 20 design options for adapting the kanban tools to a variety of situations.  This work is invaluable for implementers.  All three works can be found at Amazon and Productivity Press.

First listed various formulations of calculating kanban quantities in July 2006.  Here are a few more …

9.  wmarhel at Elsmar Cove writes …

The formula for calculating the number of kanban cards in a system for a particular product is:

(Daily Demand x (Run Frequency + Lead Time + Safety Time)) / Container Capacity

Where:

Daily Demand = Customer Consumption expressed as # of units Run Frequency = Frequency which you decide to set-up and produce that item. This is expressed as a unit of time. For a five day work week, running the product every day would equal (1), every third day would equal (3), etc. Lead Time = Manufacturing lead time (processing time + Set-up time + queue time) + lead time for kanban retrieval expressed as a unit of time. Safety Time = Allowance for variations in demand and supply, also expressed as a unit of time. Keep as low as possible. Container Capacity = Number of units [...]]]>

First listed various formulations of calculating kanban quantities in July 2006.  Here are a few more …

9.  wmarhel at Elsmar Cove writes …

The formula for calculating the number of kanban cards in a system for a particular product is:

(Daily Demand x (Run Frequency + Lead Time + Safety Time)) / Container Capacity

Where:

Daily Demand = Customer Consumption expressed as # of units
Run Frequency = Frequency which you decide to set-up and produce that item. This is expressed as a unit of time. For a five day work week, running the product every day would equal (1), every third day would equal (3), etc.
Lead Time = Manufacturing lead time (processing time + Set-up time + queue time) + lead time for kanban retrieval expressed as a unit of time.
Safety Time = Allowance for variations in demand and supply, also expressed as a unit of time. Keep as low as possible.
Container Capacity = Number of units per container (# of units in a container is always the same number).

10.  World Class Manufacturing has an on-line Kanban Size Calculator that uses the following formula:

Total Required Inventory (TRI) = Weekly Part Usage * Lead-time * Number of locations for stock
# Kanban = TRI / Container Capacity

11.  Oracle uses

By default, the standard calculation is:

(C – 1) * S = D * L

where:

• C is the number of kanban cards
• S is the kanban size
• D is the average daily demand
• L is the lead time (in days) to replenish one kanban

12.  SAP says …

K = ((RT * AC)/CONT) * (SF + C)

where

• K          numbers of Kanban
• CONT  contents per Kanban
• RT        replenishment lead time per Kanban
• AC        average consumption per time
• SF        safety factor
• C          constant (default 1)

Had dinner last night with Richard Zuber, Lean Six Sigma Master Black Belt at Honeywell.  He was a student of mine some years ago at AlliedSignal before the Honeywell merger.  Richard posed a question as to why so many organizations that have mastered demand smoothing and flow eventually revert back to month end madness, chaos and noise.  He’s seen good applications of heijunka and demand segmentation fail.  Why?