# Are Silos The Root of All Evil? | Bill Waddell thinks so

See on Scoop.itlean manufacturing
“Functional silos – the idea that all engineers have to work in an engineering department, all sales people have to work in a sales department and all procurement people have to work in a purchasing department – represent the over-arching deficiency in just about all companies.  They are at the root of enormous amounts of wasted time and money and they are at the root of most lousy cultures. ”

We all know bureaucratic horror stories associated with functional silos, like the manufacturing company where Sales, Engineering, Manufacturing and Accounting all had different product nomenclatures. Not only did they have multiple names for the same products, but they grouped them into families differently, so that it was impossible to get aggregate measures of anything.

In light of this, it is tempting to just dissolve these departments and reorganize along the lines of what Wickham Skinner called “focused factories,” Hammer and Champy “business processes,” and Womack “Value Streams.” The idea has been around a while.

1996 Ford Taurus

According to Mary Walton’s account of the development of the Taurus 1996 in Car, this is what Ford did at the time.  and it cut the development time down to 30 months. According to Sobek, Liker, and Ward, however, this is NOT what Toyota did, and it was developing cars in 24 months with functional departments exchanging memos!

1996 Toyota Camry

In addition, the Taurus 1996, while undeniably an artistically unique design,  did not set the market on fire and included body parts that were difficult to stamp out of sheet metal, Walton’s book suggests that the marketing and manufacturing members of the team, having completely transferred their allegiance to the team , failed to make it give due considerations to the needs of the groups they came from.

This suggests that, while often a good idea, collocating all the participants in a business endeavor and breaking all the functional departments is not a panacea.

Sometimes it is technically impossible, because, for example,  the functional department is operating a monumental machine that you don’t know how to break down into smaller units that could be distributed among different “value streams.”

Sometimes, you can’t do it for operational reasons. For example, you don’t distribute Shipping and Receiving among the different production lines in the same building, because it would require more docks and access roads, and it would make truck drivers deliver to different organizations at multiple points around the same building.

Sometimes, you end up having specialists report to managers who have no understanding of what they need to be effective, and can’t evaluate their requests for equipment, training, or permission to attend a conference.

Sometimes, you locate an engineer who needs a quiet space to concentrate on technical issues next to a boisterous sales rep who speaks on the phone all day…

Unfortunately, I don’t think all evil has just one root. It’s a bit more complicated.

See on www.idatix.com

# Where do “Value Stream Maps” come from?

I have been wondering where this tool actually comes from. In the introduction to Learning to See, Mike Rother describes it as a minor tool known within Toyota as “Material and Information Flow” mapping. I have many books about TPS in English and Japanese, of vintages ranging from 1978 to 2009. They contain all sorts of charts and flow maps, but nothing that resembles a VSM. I found the following in my library:

1. In Monden’s 1993 “Toyota Production System” book, there is a diagram on p. 59 about the circulation of supplier kanbans with symbols that resemble the VSM’s.
2. The 2005 Nikkan Kogyo book about the Nissan Production Way ( 日産生産方式キーワード２５) on pp. 20-21 has a material and information flow diagram of the entire car manufacturing process with numbered captions that point to sections of the book with details on each. It uses 3D pictograms specific to car making.
3. Mikiharu Aoki’s 2012 “All about car plants” (自動車工場のすべて) uses a similar approach to the Nissan book, with simpler graphics.
4. The June, 2007 issue of the Kojo Kanri magazine (工場管理. or Factory Management) has a series of articles on the application of TPS in process industries, and includes a material and information flow diagram on p. 24.
5. On the  Toyota Global website John Gore found an Illustration of the Toyota Production System that works as a road map to more detailed information, like the diagram in the Nissan book.

The pictures are in the following gallery (Please click to see them in full size):

None of these examples have the purpose, focus, or ambition of VSM. Their purpose is to explain, not to document a current state or design ideal and future states. They don’t use a standard graphic language, and are not bound by the strictures of VSM. For example, having a double timeline at the bottom constrains you to showing all operations as a sequence. People often struggle with this, because real material flows usually involve merging and branching, and it don’t fit above a single line.

All the examples above make full use of the two dimensions of the page and don’t attempt to show a timeline. To look further, I googled “物と情報の流れ” (Materials and Information Flow)  for Japanese images, and found, again, all sorts of other charts, but also a couple of Japanese sites containing VSMs, such as ITmedia   and Monoist where they are called “Value Stream Maps” (バリューストリームマップ), and the references given are Japanese translations of American books, mostly from the Lean Enterprise Institute (LEI).

I found this puzzling. Were these charts a Toyota trade secret that Rother and Shook leaked, or were they actually invented in the US and attributed to Toyota? Assume a celebrity went from overweight to lean and athletic in 90 days, and an approach or product is being marketed as what this person used to do it. The truth of this claim matters if you consider buying it. VSM is marketed as a basic tool of Lean, and just about everybody assumes it means that it was developed within Toyota and is widely used in its operations.

This belief is essential to the credibility of VSM to many managers who may not even know how to read one. If it is not really from Toyota, it can still be a great tool, but you cannot invoke Toyota’s authority to promote it. It must stand on its own merits. To get to the bottom of this, I asked members of the TPS Principles and Practice discussion group on LinkedIn, and received many enlightening answers from Bryan CoatsErik StordahlFrederick Stimson HarrimanZane FerryJerry O’DwyerPeter Winton, Chet MarchwinskiBret BakensztosPaul ToddSalvador D. Sanchez, and Gary Stewart. In addition to their personal inputs, they also provided links to publications on this topic by Hajime Ohba, Mike Rother, and Art Smalley. I have organized their inputs as follows:

Comments are welcome on any point that I missed or did not present accurately and completely.

## Origin in Toyota’s Operations Management Consulting Division (OMCD)

The Toyota alumni confirmed that you rarely see a Materials and Information Flow diagram (VSM) within  Toyota, and explained that the tool was developed at Toyota’s Operations Management Consulting Division (OMCD), for selective use with suppliers — that is, wherever the main issue is with flows of materials and information related to these flows.

The OMCD, whose Japanese name actually means “Production Investigation Division” (生産調査部). As far as I know, this is a group of 55 to 65 high-level TPS experts supporting a company of >350,000 employees. The technique was brought to the US by the Toyota Supplier Support Center (TSSC). In parallel to TSSC, according to both Frederick Stimson Harriman and Zane Ferry  it was also introduced by consultants from Shingijutsu, who also used it selectively and never used the term “value stream.” The Lean Enterprise Institute‘s Chet Marchwinski added the following details and corrections:

“According to John Shook, Materials and Information flow diagrams were created by Toyota’s OMCD group. They were introduced to the U.S. by TSSC, not Shingijutsu, and ultimately made their way to the Lean Enterprise Institute. Here’s how.

Jim Womack and Dan Jones introduced the concept of “value stream” and in Lean Thinking told readers to map them. While the book had an example and descriptions, the process wasn’t laid out. At that time, Mike Rother had just become very interested in Toyota’s M&I flow mapping so John introduced him to Jim and Dan. He said Dan was especially interested in M&I mapping too.

Mike was the lead author (John is co-author) of the workbook Learning to See and developed the mapping workshop. Dan came up with the title Learning to See. Jim and Dan coined the term “value stream” and “value-stream mapping.” More importantly perhaps, the reason why there are little or no references to the tool in Toyota materials is that Toyota never taught it widely.

John said it was and still is used by the select group of TPS experts, mostly in the OMCD organization. (I think it is now Operations Management and Development Division.) So, the tool came to LEI in a roundabout way from TSSC, according to John.”

It is clear from Learning to See itself that the authors just thought of it as a useful tool and did not intend to oversell it. Their introduction says it all:

“John (Shook), has known about the “tool” for over ten years, but never thought of it as important in its own right. As john worked with Toyota, mapping was almost an afterthought — a simple means of communication used by individuals who learn their craft through hands-on experience. At Toyota, the method-called ‘Value Stream Mapping’ in this workbook isn’t used as a training method, or as a means to ‘Learn to See.’ It is used by Toyota Production System practitioners to depict current and future, or “ideal” states in the process of developing implementation plans to install lean systems. At Toyota, while the phrase ‘value stream’ is rarely heard, infinite attention is given to establishing flow, eliminating waste, and adding value.”

That Rother and Shook never intended to make VSM a standard tool that every Lean implementation team is mandated to use as a starting point is  further documented in interactions some discussion participants had with them. Bret Bakensztos, for example, reports explaining to Mike Rother how his team had abandoned certain concepts described in Learning to See in order to make the tool provide the information we needed.

Mike Rother’s response had been “Cool!” I am not surprised by this reaction. The people who develop or even introduce a tool are usually open to other people’s adaptations or enhancements. They understand their own tools too well to want to turn them into rigidly enforced, creativity stifling “standards,” as bureaucracies are wont to do.

## Materials and Information Flow Analysis at TSSC

TSSC still teaches Materiasl and Information Flow analysis. I found the following announcement on their website:

“Material & Information Flow: day in classroom designed to develop the skill to document the current condition and locate the process bottleneck. 1 day shop floor focused on grasping the current condition and finding the bottleneck in an actual shop floor setting.Length: 1.5 days”

The announcement does not paint it as a universal tool to be applied first in every plant as a means of identifying waste removal opportunities. According to Erik Stordahl:

“Materials and Information Flow diagramming was never, ever intended to be the first step in implementing TPS. In fact, in Toyota, I’ve always seen it as nearly a last step, well after tooling diagrams, machine design, standardized work, job instruction, and many, many other documents.”

That this tool is not universally applied even in supplier development is also documented in the Stanford Business School case study of Johnson Controls that Bret Bakensztos pointed out. Paul Todd provided a link to a presentation by the first leader of TSSC, Hajime Ohba at the 2002 AME Conference, in which he explicitly recommends against using VSM as a starting point.

Paraphrasing him in a different vocabulary, what he saying is that you should start at the micro level — machines, cells, workstations, tooling, fixtures, operator job design, etc. — not at the macro level — lines, departments, suppliers, customers, etc. His reasoning is that you need to develop skills before you can address macro level issues. And he is saying that you should not start with VSM because it is a macro level tool. What Ohba does not say in his presentation is how you find out where in the plant you should start at the micro level. To me, an appropriate pilot project must meet the following conditions:

1. It must provide an opportunity for tangible, short-term performance improvements.
2. Both management and the work force in charge of the target process must be willing and able.
3. The target process must have at least one more year of economic life.

To identify such opportunities, you need to observe operations directly, interact with operators, managers and engineers, and analyze data. VSM is one of the tools that are useful in doing this, but it is not the only one, and it is not always needed. NUMMI and TSSC alumnus Salvador D. Sanchez  recounts his personal experience with this tool as follows:

“The first time I saw MIFD (Materials and Information Flow Diagrams) was when I started working at NUMMI in 1990. I was working with a Toyota coordinator. who was a team leader. He was explaining to me as a team member how a truck was built. He couldn’t speak English and I couldn’t speak Japanese but we communicated using this tool. After that I did not see another one till 9 years later when I started a 3 year assignment at TSSC. I was working with Cindy and Ohba-san at the time and we were working with a supplier.

During my time there I used this tool many times but only when I needed to. During that time we were also training Toyota Managers by taking them to suppliers and did a hands-on activity which involved one week of process kaizen and one week of system kaizen. During that week we used MIFD. Later on they started using it more and more in the plants only when needed.”

## The “Value Stream Mapping” Label

“Materials and Information Flow” accurately describes what the technique is about, and is almost self-explanatory. I say “almost” because there are plenty of information flowing in  manufacturing operations that does not appear on a VSM, such as providing and updating work instructions, downloading process programs, uploading sensor readings and measurements, etc. The only information flows that appear on a VSM are for Production Control: orders, forecasts, schedules, kanbans, etc.

According to  Gary Stewart, a 23-years Toyota veteran:

“The VSM process was known internally simply as “process mapping” – (or occasionally later as MIFD – but that was more specific to OMCD ) – it is only one of a suite of tools that should be used together to understand the process from high level to great detail. I think today the term VSM and the use by consultants of the term VSM is much more a response to creating a branding difference in both Marketing and Consulting. In Marketing “process mapping” does not sound very sexy – nor could you different yourself from every other consultant. But with Value Stream Mapping – you have a major brand differentiator.

I say this because I find that many Toyota techniques that internally have no “official” name – or a very simple name or descriptor – have mysteriously developed new “brand names” when they appear outside of the Toyota world. […] Today I use “process mapping” and VSM interchangeably – personally I have no problem with the rebranding of Toyota’s simple name words and descriptors into more recognisable “brand names”. In the end it is not what they are called – but how you use them that matters. The actual form is completely unimportant –  it is the use of the philosophy behind the format ( and the name) that is important.”

Unquestionably, Jim Womack is an outstanding marketer. “Process Mapping,” “Materials and Information Flow Analysis,” are all terms that, at best, appeal to engineers. Any phrase with “value” in it, on the other hand, resonates with executives and MBAs.

They readily latch on to a concept called “Value Stream Mapping,” even though their eyes would glaze over at the sight of an actual map. While this confusingly abstract vocabulary can be frustrating to engineers, it does serve the vital purpose of getting top management on board. The trick is to know when to use it — in the board room — and when not to — on the shop floor.

## Art Smalley’s perspective on VSM

With permission from Art Smalley, here is what he wrote about VSM in his 2005 article:

“Value stream mapping, for instance, is perhaps the most widely used tool in lean programs today. The prevailing assumption in virtually every plant is that a value stream map must be drawn for each product family, a value stream manager anointed, and that it will somehow magically reveal all of the plant’s problems. This practice has become a sort of litmus test for Lean.

If there is no value stream map and an associated tracking center, then the company is not pursuing true Lean manufacturing. But there were no value steam maps in the Toyota facility in West Virginia, nor are there value stream managers. And this is hardly because Toyota employees are so smart they all carry the value stream maps around in their heads.

The reason there are no value stream maps in most Toyota plants is very simple in hindsight. It was a tool developed primarily as an analytical aid to look at material and information flow problems in certain processes. In fact, the actual name of the tool at Toyota is “material and information flow analysis” – not value stream mapping.

A third dimension, human motion, is often added to the mix for consideration as well at Toyota. As TPS evolved internally and was rolled out to supplier companies externally a consistent problem was insufficient investigation into the details of material flow, information flow, and human motion in the process.

A typical layout drawing, for example, simply does not emphasize these aspects clearly enough to bring problems to the surface. Once production starts, it is too late or costly to fix some of these items. In response a creative countermeasure was developed that became a requirement for engineers and others in charge of manufacturing processes and line conversion work at suppliers.

The emphasis was to draw both detailed standardized work charts depicting operator motion, and flow charts depicting material storage locations, scheduling points, and operator work sequence before the start of production. In other cases, this tool was used externally to find ways to convert lines to more efficient ones.

The key point is that the tool was created to analyze and solve a specific category of problems Toyota faced in new production lines and in helping suppliers implement lean. From this fairly specific local origin in Toyota, the tool was slightly modified (the human motion emphasis was reduced) and popularized in the U.S. by my good friend and former Toyota colleague John Shook, and his co-author Mike Rother, in their insightful, best selling workbook “Learning to See”.

The title of the work I think is important. Originally the authors had considered titling the workbook Material and Information Flow Analysis for Lead Time Improvement and Work Place Kaizen. This name, which would have been truer to the original intent of the material, was changed for marketing reasons to “Learning To See”. The workbook went on to sell over 125,000 copies, and has affected the direction of lean efforts in the U.S. more than any single publication.

Unfortunately the object of what the workbook urges the reader to see is not as clearly communicated in the catchier title – and here is where the law of unintended consequences kicks in. The book is about learning to see what is primarily a material and information flow problem, or essentially elements of the JIT pillar of Toyota’s production system (flow, takt time, level, and pull production).

By design it doesn’t even attempt to address the topic of Jidoka for example which Toyota considers an equally if not more important support pillar than JIT or equipment stability. The technique used in the workbook simply measures the overall manufacturing lead-time versus production value add time. Everything non-value adding (i.e. the waste) is to be eliminated and answering seven specific questions outlined in the workbook will help you accomplish some of this goal.

Overall, however, when the 4M’s of manufacturing (man, machine, material, and method) are considered you’ll realize that this tool mainly considers the material (and information) flow component. The other 3M’s are much less emphasized and one other important M – metrics – is expressed chiefly in terms of lead-time and value-add time.

This is fine for Toyota. Internally they well know the limits of the tool and understood that the it was never intended as the best way to see and analyze every waste or every problem related to quality, downtime, personnel development, cross training related issues, capacity bottlenecks, or anything to do with profits, safety, metrics or morale, etc.

No one tool can do all of that. For surfacing these issues other tools are much more widely and effectively used. Unfortunately, the average user of the workbook tends to copy the pattern expressed in value stream mapping regardless of the nature of their manufacturing problems.

The unintended consequence of the success of the method has been to convince many people that it is a universal tool for identifying all problems in manufacturing operations. Marketing hype helps reinforce this notion. “Just draw a value stream map and it will show you all your problems to work on” is a popular refrain that I hear quoted in companies attempting lean.

This guidance however biases companies with major quality, downtime, or factor productivity problems to deemphasize them since those items are not surfaced well using the method and questions outlined in value stream mapping. The tool just does not frame these problems well by design. Couple this effect with the fact that most lean efforts already have a disproportionate bias towards the concept of “flow”, and there is a recipe for inherent danger.

For example instead of learning to see what is truly broken in their processes companies wind up typically focusing on a particular subset of operational problems chiefly that of flow and lead-time related issues.”

## Materials and Information Flow Mapping in My Own Work

The idea of Manufacturing as a three-layered flow system of materials, information, and money occurred to me when I was writing my first book, Manufacturing Systems Analysis,  in the late 1980s, and I thought it important enough to put the following diagram on the cover:

What VSM does is show the production control part of the bottom two layers on the same diagram, which I only did in cases where the two are tightly coupled, for example  in the dual-card Kanban system. The following is on pp. 312 and 314:

I used a simpler and more abstract graphic notation than VSM, and complemented the flow diagram with a state-transition diagram focused on what happens to a Kanban through the cycle. Working at the time on software development for Manufacturing Execution Systems (MES), I had found a formal similarity between the ASME symbols for process mapping and Tom DeMarco’s for data flow diagramming.

Materials and information, however, do not flow the same way. For example, once you retrieve materials from a warehouse, they are no longer there, and the inventory needs to be updated accordingly; on the other hand, no matter how many times the same data is read from a database, it is still there. When showing both types of flows on the same chart, it is therefore vital to use symbols that let the reader tell them apart, and VSMs do.

## An Example from 1918

A few year ago, Bryan Lund pointed out to me a 1918 book by Charles E. Knoeppel entitled Installing Efficiency Methods, and I managed to buy a used copy from the Iowa State University Library that had last been returned on August 5, 1939. In the chapter on Diagnosis, I found the two following charts, respectively showing flows of materials and information in a factory. These are the earliest examples I know.

By Michel Baudin Posted in Tools

# Deming’s Point 9 of 14 – Break down barriers between departments

(Featured image from the  Bureaucracy game, by Douglas Adams)

Deming’s complete statement of Point 9 is as follows:

“Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems in production and in use that may be encountered with the product or service.”

Within a large organization, it is common for departments to work at cross purposes. Each department is a functional silo, working towards goals that may be inconsistent with the interests of the whole. Deming gives many examples of disasters that occur as a consequence, and exhorts his readers to break down the barriers to keep them from happening. As with his other points, he makes no recommendation on how to accomplish this.

Let us examine several approaches that have been tried, and the issues that organizations encountered when they did:

### Eliminating silos in the organization

This is not a problem for small companies. As long as the entire management team fits within a small conference room, there are few opportunities to erect barriers. In a large company where it is a problem, the most obvious solution is to organize by what is variously called business teams, business processes, value streams, or focused factories.

You dissolve the functional departments and organize multifunction teams that bring all the required talent to bear on the core activities. In a manufacturing company, for example, all the resources needed to make a family of products from start to finish — including engineers, maintenance and quality technicians, schedulers, etc. — report to one “value stream manager,” and there cannot be barriers between silos because there are no silos.

It’s like the Mission Impossible TV series, with the disguise specialist and the explosives expert working together towards a common goal, as opposed to being in separate facilities and exchanging service requests in triplicate. This is a popular picture in the US and the approach is often used in a variety of contexts, such as emergency response, as in Apollo 13, or product development, for Data General’s MV-8000 computer in 1980 in Tracy Kidder’s The Soul of a New Machine, or the 1996 Taurus at Ford in Mary Walton’s Car.

The movie Apollo 13 shows a seemingly too-good-to-be-true team that is thrown together to find a way to fit the square connector of the command module air scrubber to the round hole used on the lunar module, using nothing but the odds and ends available to the astronauts on the crippled spacecraft. But the story is true, and we have a picture of the actual device the astronauts built.

This was the philosophy of Business Process Reengineering (BPR). Each business was to be broken down into processes turning some input into an externally visible output. Manufacturing, in BPR, did not qualify as a process. Instead, it was subsumed into the order-fulfillment process.

### Making functional departments work

But it is not a panacea. The development of the 1996 Taurus took 30 months, and it was a major improvement over previous products at Ford, but still not down to the 24 months used at Toyota for the Rav4, and Toyota uses a traditional structure with functional departments communicating through memos.

In addition, according to Mary Walton, Ford’s integrated, collocated team made design decisions that made manufacturing more difficult. She explains in particular that the sculptured shape of the side panels made them more difficult to stamp, and this happened even though manufacturing was represented in the team. As a work of art, the 1996 Taurus was stunning. As a commercial product, however, it was lackluster, losing the previous versions’ bestseller status in the US market to the more “boring” Honda Accord and Toyota Camry in 1997.

The reality is that organization structure does not determine outcomes. The caliber of the individuals, their motivations for the roles they are playing, and their interaction protocols are at least as important. In their July, 1998 Harvard Business Review article , D.K.Sobek, J. Liker, and A.C. Ward listed the following practices as key to Toyota’s performance in product development:

1. Written communication with single-sheet A3 reports in standard formats.
2. Engineering supervision by practicing, hands-on engineers.
3. A chief engineer (shusa, or 主査) for each project who is an experienced designer with a proven ability to integrate different technologies into a product. The shusa has a team of 5 to 15 members coordinating the work of hundreds who remain in functional departments.
4. Engineers who develop their skills through on-the-job training, mentoring, and rotation within their functional department, with senior managers rotating between departments.
5. High-level project plans with a small number of milestones, giving each department flexibility on detailed tasks.
6. Checklists of design standards embodying the lessons learned in previous projects.

### Obstacles to organization by process or value stream

The Toyota example is about product development. But what about other activities like operations? When you attempt to organize everything by business process, or by value stream, in most cases you encounter some functional departments that you technically cannot or should not break up.

Most machine shops have a central heat treatment facility. Induction hardening can, for some work, distribute heat treatment among different production lines and break down the “heat treat silo,” but a given shop may make products to which it is not applicable, its customers may not approve the process, or it may not have the skills or resources to implement it. Electroplating and painting commonly are similar challenges. As a result, the plant ends up with a few common services organized as functional departments along with lines that take a family of products through a sequence of operations.

Among support functions, the picture is also mixed. Production scheduling at the detailed level, for example, works better when the schedulers work directly for the manager of a production line than in a central department, because local scheduling is a simpler problem and the relevant specifics of machine behaviors are more accessible. On the other hand, breaking down a maintenance department and making the technicians report to production managers may not enhance their responsiveness when, for example, the group assigned to a line is short of the critical mass needed to have at least one technician standing by for the next emergency.

Other departments remain organized centrally because of the information they have access to, like Human Resources, Accounting, or Technical Data Management; others, because of external entities they deal with, like Shipping and Receiving.

### Skills maintenance, continuing education and career planning

When breaking down a functional department and reassigning its members to teams organized around processes, we also need to consider how it affects the people to whom we do it. Professionals like medical doctors or lawyers work for clients who have little or no knowledge of their specialties, but it is then up to them to decide how much of their revenue to spend or maintaining their skills. They choose which magazines tp subscribe to and which conferences to attend, without asking anybody’s permission.

An engineer reporting to a production manager also works for one “client” who does not have the same expertise, but as an employee. If this engineer wants to attend a conference, the first step is to get approval for the time and money it will consume, from a manager with no knowledge of whether it is a good idea.

In the long term, what career does this engineer have to look forward to? The manager needs the engineer’s skills here and now but is ill equipped to provide guidance, compared to an engineering manager whose background and experience are in the same field.

For this reason, some companies have adopted matrix organizations, in which specialists report “solid-line” to a process owner who needs their skills in operations or on projects, and “dotted-line” to a functional manager for skills maintenance and career development. In a diagram, as follows, this structure looks simple and attractive:In reality, of course, it is a more complex form of organization than a simple hierarchy, and conducive to all sorts of tensions regarding authority and responsibility.

### Project transitions

Project work — like product development, new product introduction, or new plant setup — differs from operations in that it ends when a goal is reached, which may be a working prototype, a target takt time in production for the new product, or for the new plant. At that point, the teams are disbanded and their members move on.

This is a particularly sensitive transition to manage when you collocate a multifunction project team in one big room, because its members bond both with the project and with each other, and receive the ending like a psychological blow on the scale of the loss of a family member. This is another reason why they need to retain a connection with their functional peers.

### Conclusions

Breaking down barriers between departments for the greater good of the organization as a whole is a worthy goal, that high-level managers have been pursuing since, at least, the Roman empire. There is no simple recipe. The approaches followed by successful organizations have been subtle, nuanced, and fitted to their purposes.

# Video on Lean at ACT Trailers

This morning, I received the following email from a manufacturer of trailers in Indiana, with a link to a Youtube video they produced for their dealers. It is a good case of organizing production around the demand structure. At the end of the video, they acknowledge Bill Waddell for his help. Here is the full message:

From: “Lucas Landis” <LucasL@aluminumtrailer.com>
To: “Michel Baudin” <michel.baudin@takttimes.com>
Cc:
Subject: RE: Context of your video
Date: Wed, 26 Sep 2012 08:08:09 -0700

We are a 13 year old company that manufactures specialty trailers in
Nappanee, IN. As with a lot of manufacturing plants during the end of
the last decade, our company went through a terrible austerity period –
employees were laid off, the CEO was replaced, and a myriad of other
radical decisions were made as a result of the downward economy. Out of
the ashes of that, the founding CEO of the company had been doing a lot
of research on LEAN manufacturing. Because we were more or less
starting over, Steve Brenneman (CEO) decided to implement the LEAN
philosophy to maintain a more sustainable company that could avoid
future pitfalls and offer a more superior product. We are now into our
3rd year of our LEAN Journey and this video
process. We created this video to help our Dealers understand our
business philosophy and system. Following a previous Kaizen event, we
are in the process of taking LEAN to the front end of our business,
which means getting our distributors in-line with our process. The
video should explain the rest.

Hope that helps.

Lucas Landis
ATC TrailersMarketing
Phone: 574-773-8341
Fax: 574-773-7769
mailto:LucasL@aluminumtrailer.com
http://AluminumTrailer.com