In this final part of my review of The New Economics of Semiconductor Manufacturing, an article that you can find at the IEEE Spectrum site, I mean to go over the capabilities of Fab PowerOps (FPO) and contrast it with the essence/framework that Toyota Production System (TPS) offers. In the earlier two parts, The New Economics of Semiconductor Manufacturing – Part 1: I looked at the core outline of the consulting experience that the researchers (Clayton M. Christensen, Steven King, Matt Verlinden, and Woodward Yang) and in The New Economics of Semiconductor Manufacturing – Part 2: I delved further into the essence of earlier research that identified a few rules distilled from TPS that those researchers (Spear and H. Kent Bowen) claimed describe essential parts of the system that is internalized within the organization primarily as an outcome of iterative growth over the last five decades.
A brief about FPO – What is FPO? FPO is a scheduler for a wafer fab (but it can be extended to other industries as well) – pure and simple. It is a first generation scheduler in its class – the class being (near-)real time optimization (MIP: Mixed Integer Programming) based scheduling. It is rapidly customizable (aren’t they all? No, Seriously!) – it is so customizable that you can swing from one extreme of weighing it down by the whims of those who don’t know any better to direct it to the other extreme of it being light and flexible for those who mean to get certain scheduling behaviors realized and every other point in between. Fast! Now, while some solutions can achieve this as well, for example: "Do activity A if condition B for tool-space C", there are two immediate problems with this approach:
It doesn’t scale very well – multiple statements and overlapping tool-spaces lead to conflicts that must be resolved and accounted for. Otherwise, you’d default to FIFO (First in, first out) or some other simple rule.
Is it the best solution available? Is it a really good solution, good solution, solution, workable solution, bad solution, very bad solution?
It is also highly extensible in the sense that while there is a product architecture, layered on top of it is an customizable interface that a client can write pretty much whatever he wants (i.e in Java) and since the bulk of the product is in Java, it is cross platform compatible as well.
For some of us who might be aware of an SAP or like system that plans out a day in advance, week in advance or maybe even a month in advance, FPO is a breath of fresh air, it generates schedules every five minutes. No, that is not a typo. Every five minutes, FPO accesses the state of the wafer fab (from an MES (Manufacturing Execution System) – it is flexible enough to be hooked up to several MES-es) and computes a schedule for all tools that it is in charge of scheduling. What type of tools? Batch tools, single chamber tools, multi-chamber tools, parallel chamber tools and so on. When things change on the floor within a five minute interval, it becomes a state change that figures into the next computation run or iteration (five minutes later) and the schedules update accordingly taking the event(s) into account – however many events there are. The last piece of this powerful scheduler is access to the data it uses in several transformational states and forms for monitoring, information, review, investigation and continuous improvement.
Now, back to the TPS story, the connection between the consultants and the earlier researchers (Spear and Kent) is that the four rules distilled by Spear and Kent informs some of the questions that are used in the exercise. From, the examples listed in the article: