@ Supply Chain Management

This is an interview with Pierre Haren, CEO of ILOG prior to its acquisition by IBM on what decision management is and how it came to be used in various situations. A look back (and forward) at 20 years of Decision Management.

This is also my particular field of expertise and Pierre alludes to the case of the product that I work with gaining acceptance in IBM’s wafer fabrication facility in East Fishkill, NY.

We had a great moment when we were able to successfully deploy a complex mix of ILOG and IBM tools at IBM Fishkill, in what was considered the most modern and fastest changing semi-conductor plant in the world. At that time, before our acquisition by IBM, IBM was a reluctant customer. I visited the head of the plant and promised that we would install the complete system for free. He would only pay if he kept the system in operation for more than a month.

Understandably, he was skeptical that a small decision management company could improve on the work of hundreds of excellent engineers who continuously tuned the $4B plant. We deployed a system which every five minutes re-computes the optimal plan for the whole plant for the next eight hours. It combines real-time data from the MES system to rules-based processes, an optimization-based scheduler, and advanced graphics to enable the plant operators to "see the current future" for the next eight hours.

The first day’s objective was low: do no harm. Within a month, all the operators where convinced and we were paid. More important, we changed forever the balance of what computers do and what operators do in that plant.

What’s important about this confluence of components i.e. Rules Management, Optimization using CPLEX and Visualization as it used in that fab (and since then in other fabs in the world) is how such a system can be used for execution. Not planning, Not strategy. But execution on a near real time basis – that means that actual tools on the fab floor act on the recommendations produced by the decision management system which in turn sees the action of the tools and then uses that as an input in further decisions. When operators and managers assert manual control in the operation of the tools or fab in general, the system accepts that and continues without issue. So the system takes into account the dynamic nature of the fab, recomputes and proceeds. I’ve blogged about this system : FabPowerOps in earlier blog postings – take a look.

Now I’m hoping to take this to the next level, deploying a federated system of such applications that not only interact with the fab floor as well as human operators, engineers and managers but with other apps taking their inputs and working on that.

Great stuff, I assure you!!

Supply Chain Design is an oft overlooked field of specialty because of the “math” involved. While several providers have come up with nice interfaces to hide that math – the truth of the matter is that without the math, you’re slipping constants into GIGO (Garbage In Garbage Out) mode.

Supply Chain Management Review and Logistics Management have made this free webcast available on this topic : Winning through Better Supply Chain Design.

This article by SC Digest: Supply Chain Network Design – By the Book is about a new kid on the block (a book: Supply Chain Network Design: Applying Optimization and Analytics to the Global Supply Chain) as far as Supply Chain Modeling and Optimization goes.

As you might be aware I’m not really that keen on the adoption of optimization in businesses even though I’m sold on the absolute necessity of it. I’ve outlined several reasons over several posts on this blog : Coming off a tough tough project (for starters).

Some of the ideas in the article are tried and tested – as in I was employing them in Supply Chain Consulting way back in 2004-06 timeframe.

For the last four months, I’ve been part of a tough project – tough on multiple dimensions, beset by every sort of calamity that one can dream up (every day was an example of Murphy’s law in action). That’s a nice way of saying – don’t give me grief on a lack of updates for that reason. Well, not really -  blogging is therapeutic mostly.

But the point of this post is not to really go into the inanities of a project – it’s to place on the table the only free lunch in the world. So take from it what you will… Here’s what I learnt.

1. An unhappy client is not your fault, not the project’s fault.

Bang!! Front and center. Chances are that an unhappy client was unhappy long before you ever got there. In fact, unhappiness (both micro and macro) takes constant effort. It takes a whole lot of time and energy to be and remain unhappy. I’m not talking about the depressives or the manic-depressives but that class of people and organizations that are intent on getting there. An unhappy client is symptomatic of an unhappy culture or sub-culture of the firm and deeply unhappy ones are caught in a vortex – there is very little that one can do be it in through the project or as an individual to break the vortex. No measure of competency, delivery or solution can ever break the vortex – it has a life of its own. Like a demon. Such vortices don’t have technological solutions, project solutions or in some cases managerial solutions.

In nature, vortices dissipate because they encounter an environment capacitated to absorb the energy of the vortex. Vortices of sub-cultures ought to be dissipated by the larger culture of the firm. A vortex of culture within the firm cannot be dissipated inside the firm – these firms are dangerous to every thing around them and themselves. It is dissipated by the industry through the process of competition. And so on… Only competition, I believe, can break the vortex and this gets tricky at the team level but I see no other way to break the cycle. It’s something similar to what you might see on the Dog Whisperer where the energy of the pack is channeled into calming the dog that is freaking out.

2. Optimization is a mistake.

I love optimization. To me, it represents a curious blending of the platonic mathematical world and the real world – the world of the idea of the numeric colliding into the real where nothing of the sort exists. However, optimization (as is often sold to the business world) is first and foremost a terrible mistake. In a subset of these mistakes that businesses and firms make, it is the most important mistake that you need to make. Not in the sense that now that the firm has made it, walk away. No, once you’ve made the mistake of optimization, you’re ready to make the leap to the higher world of bigger mistakes. Such mistakes subside as you learn how to wield it properly.

However, most firms cannot deal with optimization. They (and by they I mean the people in the firm) are not able to deal with the intersection of the math and the real. They’re very content with their take on the real or other iterations on the real no matter how they’re being placed at a competitive disadvantage by those firms that not only invest in mastering optimization as a discipline but also as a way of approaching the business problem. Iterations on the real are reconceived processes, new technologies and the like. So most firms that take on the mistake of optimization treat it as a black box that keeps chugging away in the background telling them the “optimal” way to do things which passes through a gut-check filter and so it goes on… This is like buying a katana and using it for chopping vegetables.

Part of the issue with optimization is while there is an active movement to make supply chain a “C” level responsibility or at least have it on their radar – optimization (like statistics) is a nice to have. While the supply chain is an integrative activity of processes both inside and outside the firm, optimization is a quant backed way of executing the business (pun intended).

3. Plan – Do – Check – Act (PDCA)

While PDCA is quite important as far as continuous improvement goes and this simple concept underlies most of the continuous improvement methodologies out there, it has some relevance to the world of project delivery. For me, there has always been a question of which task do you start with: Is it Plan? Is it Check? or Does it even matter where you start? I now think that the right step to start with as far as project delivery / consulting projects go is to start with Check. The simple reason for that is that when you’re an external consultant, you’re essentially going by what you’re told. Often times, I find that there is a delta between what the client knows and what is actually present. The Check step is best visualized and not tabulated/reported. And its better to make it real-time in some way. Some people refer to this as analytics and that in my opinion is where any such project ought to start because it gives visibility of the changes that are going to happen or happening in execution. This has the added benefit of putting the client in the driver’s seat as you work on the engine while in motion.