Nov 11 2011
Nov 11 2011
Professionals know that their productivity drops when they take on too many concurrent projects. An engineer whose attention is split across 15 projects doesn’t contribute effectively to any. But it happens because supervisors keep piling on assignments without regard to this phenomenon. Over the years, cures have been proposed under different names, all aiming to cap work in process.
About 1982, a colleague showed me the system he used to manage what he was working on. It was called the Scancard System, and it used the hardware in Figure 1. The cards were square, with 3 1/4-in sides and borders of different colors. They came with letter-size card pocket plastic boards that you could insert into 3-ring binders, keep on your desk or pin to a wall.
He used it with one column for his backlog of things to do, one column for work in process, and one column for completed items. It was a paper-based system but, at the time, so was almost everything we did. It gave you visibility, it capped the number of items you were working on at one time, and moving cards from one column to the next was an effective metaphor for the flow of your work. The ads showed smartly dressed managers using their scancard systems in meetings. I went for it and used it for years, until I had a project with a company that used another system and switched to fit in.
Fast forward to 2011. Scancard Systems is out of business, and I hear of a system called “Personal Kanban,” that is focused on providing visibility and limiting work in process, using a white board and Post-Its as in Figure 2:
I put quotes around the name because I find it to be little more than a feat of vocabulary engineering, leveraging the buzz around a feature of Toyota’s production control system to repackage ideas that have little to do with it, are very simple and have been around for a long time. A software developer visiting a factory may see a similarity with Toyota’s Kanbans, but it escapes me.
Of course, if, as in Figure 2, it is on a white board, you can’t carry it with you to a meeting or share it in your network. The Personal Kanban website advertizes an iPhone app called iKan, that I can’t find on Apple’s App Store. On the other hand, Leankit Kanban offers a web-based application with an iPhone version that looks very much like a team to-do list management system. It looks most useful if your work can be perceived as a collection of independent activities, which happens if each Post-It is for a whole project or for a prospect in a sales cycle. But it would not fit if each Post-It were for a task within a project, with precedence constraints or iterations between tasks.
Another limitation of such a status board is that is only shows current status, as compared, for example, with the Ybry chart of Figure 3, which shows the complete history of each project by using a line for each project rather than a card. Like the status board, it assumes that all project go through the same sequence of phases.
Figure 3. Ybry chart for projects going through the same sequence of phases
Ybry charts were invented by Charles Ybry in 1846 for railroad scheduling, and are still used for that purpose. See Edward Tufte’s Envisioning Information, pp. 107-110. The work-combination charts used in Lean operator job design are a variation on this method, as explained in Working with Machines, pp. 133-154.
Nov 10 2011
Via Scoop.it – lean manufacturing
TOYOTA City, Japan — Even Steve Jobs, the management maverick and incurable tyrant knew that the best and time-tested strategy is none other than regularly securing the best possible ideas from workers than follow the dictates of a corporate…
Nov 8 2011
Whatever that might mean, Washington state prisons are “going Lean.” According to this article, it mostly means standardizing menus and meal times across the state.
Apr 24 2011
Some companies subject job applicants to hands-on tests of the skills required for a position. This says that they appear more interested in filling a capacity gap for a skill set than in recruiting people for careers. The most extreme cases are the “coding interviews” given at Silicon Valley software companies, during which candidates are asked to solve programming problems. This has spawned a whole sub-industry of coaches and books to help cram for such interviews. The problems are typically the kind of textbook exercises given in college that experienced programmers have long forgotten and are irrelevant to their actual work. College students, for example, learn various ways of sorting records, while professional application programmers just use built-in Sort functions. Software developers with, say, 20 years of experience with databases perceive these interviews as silly and demeaning, raising the question of whether they are intended to bias the hiring process in favor of recent college graduates.
This is the opposite of the Lean approach. During a career at a company, a person would have to acquire many technical and managerial skills. With that in mind, the willingness and ability to learn are more important than what the person knows walking in. When Honda set up its Marysville facility, they deliberately hired people with no prior experience in car manufacturing, to train them from scratch in the Honda way. As an employee, the background knowledge you need is supposed to have been provided at school. Whether in the US or Japan, however, schools never work perfectly, and companies end up providing remedial training they feel they shouldn’t have to. However, if all you need today is a technical skill set, you are probably better off hiring a contractor than an employee.
Apr 22 2010
“I see so many internal Lean “experts” using “Lean” as a means to increase efficiencies and productivity, and therefore, reduce costs. They still do not see the connection to quality. They see quality and the reduction of variation in significant product characteristics as something that is outside of the Lean scope and something that should be handled by the quality folks independently of the lean effort. What a shame! If you agree with this observation, why does this exist and what can we do to change this perception?”
Following is my response:
Quality not central to Lean? Says who? Lean is about simultaneously improving all dimensions of performance, including quality. Quality professionals frequently miss this, because what they learned primarily addresses process capability issues that are central only in high technology, where, if your process is mature, your product is obsolete. This is the context where statistical approaches like Six Sigma make a difference.
Modern machine tools, on the other hand, can easily hold required tolerances, and most quality problems are not due to lack of process capability. They are instead due to discrete failure of the equipment or human error. The main issue with discrete equipment failures is to detect them quickly so that they affect few parts and can be diagnosed before their trail is cold. With one-piece flow, defects are detected immediately instead of being buried in WIP, and this is why conversion from batch production to one-piece flow typically yields large improvements in quality.
The next step, which Dennis alluded to, is having machines stop as soon as they start producing defectives, but this still leaves human error, and that is addressed by mistake-proofing. Beyond these approaches, there is also management to prevent the deterioration over time, and plan responses to potential new problems.
This is a hierarchy of approaches. Actual numbers vary, but, in orders of magnitude, statistical tools will get you from 30% defectives to 3%, one-piece flow to 0.3%, mistake-proofing to 15ppm, and I know of one case of a Toyota supplier achieving <1ppm on some parts.