You may already be aware of the dichotomy between Agile Manufacturing (AM) and Concurrent Engineering (CE) that I will attempt to describe here. However, I'm in a good position to notice and care about what I'm seeing. Thus, the motivation for this note.
AM vs. CE
AM has a relentless (and correct) push toward pragmatism: how much of the "virtual enterprise" can we achieve with today's technologies? Even stronger, how much can we achieve with the technologies of those organizations that are willing to come together today and attempt to build something? This is the way to make something good and new happen.
CE is more concerned, than AM, with the design aspect of distributed work. Further, the CE work that emphasizes computer coordination of distributed design is generally being done as research projects at universities or institutes. This is because the technology to coordinate designs, rather than just share information among designers, is still a developing science. So because it is more restricted in its focus and is less available, CE technology seems to be split off from AM.
But AM needs CE. First, design is ubiquitous. Whether one is planning a marketing strategy or a manufacturing process, one is designing. Second, the coordination of distributed processes is central to AM. This is something more than just matching up tasks and capabilities. It is something more than management reports. It is different from conventional process control. It is about peer-to-peer communications and the reduction of the need for hierarchical control of distributed design and interacting actions. It includes rationales and the facilitation of negotiation and, especially, revision. The more complex the process and artifact(s) being produced, the more important coordination is.
Finally, in a full virtual company scenario, heterogeneous systems (not just people) must understand and react to each other. The system coordination needed in AM has also been a concern addressed by some CE research.
And Not Just CE
CE is a good place to start with coordination. CE does not assume that all implications have been thought through and it does allow dynamic propagation of change. But there is also much research on coordination per se that is broader in scope and possibly more dynamic. This broader research should be brought to bear on the problem of coordinating virtual enterprises, even in the guise of CE.
Conflicts and Opportunities
Whatever the technology, two important aspects of coordination that are the key to productivity are conflicts and opportunities. Consider a virtual automobile manufacturer (VAM) that farms out the design, finds suppliers, has someone else do final assembly, and then contracts for marketing and distribution. The VAM needs to detect that the assembly plan, the choice of engine block supplier, and the design of the motor mounts together are the primary cause for the car being too heavy. Perhaps the marketing campaign being developed is for a sportier car than is being dictated by design constraints. And the VAM needs to be able to detect the opportunity for improving the assembly process by changing a design decision, or asking the marketing people about the possible benefit of a feature change.
Management of change is fundamental to handling conflicts and opportunities. What are the ramifications, and possibilities, if a part is out of stock? If prices change, does this affect decision rationales? Is it worthwhile trying to do better?
These situations have been at least addressed by CIM, though not totally solved. It is much worse with distributed processes. Not only is it more difficult to detect conflicts and opportunities, they are more difficult to handle. There must be support for negotiation and satisfying multiple objectives. Each of the participants may be an independent company, not necessarily willing to sacrifice local objectives for a common global optimum. The VAM is just another player, without the power to dictate to subordinates, as in an hierarchically-controlled company. To the extent that we have not solved coordination problems with CIM, we will exacerbate them with virtual companies.
The problem is not so much that we can't specify the coordination interactions for a particular scenario. We can analyze the possible transactions, all of the possibilities for conflict and revision, and how change would propagate to which of the participants. But we need general tools and technologies so that we don't have to do all of this analysis (and coding) for each new virtual enterprise before it can happen.
Pilots and Coordination
If AM pilots emphasize high bandwidth WANs (Wide Area Networks) without process coordination mechanisms, they will at least fail to achieve the full potential of virtual companies. Doing AM by focusing on standards, data access, and moving bits faster is like looking under the lamp post for the lost keys because that's where the light is, rather than where they were dropped.
That may seem overstated. Clearly it helps if organizations can simply find out about each other's capabilities and needs via a matching mechanism that is far short of coordination. But without coordination, the process that follows the matching will be even more unwieldy and inefficient than current processes within organizations. That is contrary to the goals of AM.
Current CE research is addressing various aspects of the coordination problems above. But, for the most part, the technology is not ready to go. So, what to do? One obvious recommendation is to pilot virtual enterprises with simple, perhaps "low-tech", products and processes with more existing standards, fewer opportunities for conflicts, and less need for control in general.
A general recommendation is that any pilot proposal should at least examine the conflict/opportunity dimension of the process, determine the need for (or benefit of) additional technology, and evaluate near-term CE (or coordination) technologies that may be applicable. Perhaps some of the CIM work can be adapted.
At least one suitable AM pilot should carefully examine the coordination problem. Perhaps the way to start is to assign people the necessary coordination tasks and then engineer systems to take over these tasks (in the same way that the PACT experiment led to SHADE [in ICEIMT proceedings*]). We need a place to experiment with the different coordination approaches and move some of this research out into field experiments.
cp
* Send any message to "iceimt-info@einet.net" for automated information on this book.