Dr. Joel Orr
VP and Chief Visionary
Cyon Research Corporation
She begins her talk, and tells how most people are unaware of where their hands go and what they touch-and how frequently they touch their mouth, nose, eyes, and ears. She asks for a show of hands of people who think they never touch their facial orifices at all, or only rarely. Usually one-third to one-half the class raises their hands.
Then she describes the powder on her hands, turns off the room lights, and shines a bright ultraviolet light around the room. There is rarely anyone without bright finger marks all over their face.
Ask a senior manager of a manufacturing company to describe the concept-to-delivered product process in their organization, and they will typically describe or sketch a train of boxes: idea->requirements->conceptual design->prototype->approval->manufacturing plan->shipping->customer. In their mind, it's a linear flow.
But if you observe what actually goes on, the path is much more like a partly unrolled coil of wire, with multiple loops at each node-design; prototyping; and so on.
And if you discuss the benefits of automating various aspects of the engineering process with that same senior manager, you'll hear concerns like "time to market"; "overall profitability"; "reduced error rates"-the kinds of issues that affect the organization's business performance.
But if you interview project managers and team leaders, you'll learn that their concerns are almost entirely local: "How much training will this new tool require?" "Will it interface with my old document-management system?" "Does it run on Windows 2000? IT hasn't moved us to XP yet."
What's more, when it comes time to implement a new tool, the bottlenecks are not inter-system compatibility and general efficacy, which points are typically resolved in the sales process. Instead, it's things like, "Who has time to take the three-day training?" "I have to pick up my kids at 4:00 all week, so I can't stay." "My screen resolution only goes up to 1024 x 768, and the new app needs 1280 x 1024."
So the new software, bought because it will save the organization hundreds of thousands of dollars annually, is delayed a month for want of an $80 graphics card or some point of scheduling flexibility.
Like the students who don't know how frequently they touch their hands to their mouths, after having touched who-knows-what, manufacturing executives often do not understand what really goes on in their organizations. They have abstract ideas about the engineering process, that are often only pale reflections of reality.
We are in need of an analog of the invisible powder. We need to scatter it about our engineering and production areas, and learn what really touches what, for how long, and when.
We need a systems view of our organization.
That seems obvious. Why doesn't every organization have one?
Simple: Organizations tend to optimize locally, and pay only lip service to global optimization. The project manager is compensated for meeting project goals, not for increasing overall productivity. The plant manager is concerned about scrap rates, absenteeism, and safety. And so on, down the line.
Nobody is looking at the big picture at a level of detail that forces reconciliation of local and global considerations.
And everyone is comfortable doing just what they are doing. "Every system is perfectly designed to produce precisely the results it is producing," is a well-known systems theory observation. If the system is to change, it-or someone sufficiently authoritative within it-must want it to change.
Unfortunately, most engineers will not champion organizational change. "What's in it for me?" is the unspoken but almost-universal question they ask. The answer, all too frequently, is "risk-and little potential for reward."
So let me pose this as an engineering challenge: How can you frame the issues your organization is facing along these lines in such a way that your proposed approach to solving them will induce others to join you? Can you do this without losing your job, or respect?
Think about it. Do something about it. Then write and tell me what you did: email@example.com.
For more thoughts on organizational issues, read "Structure is Destiny: The Dandelion Paradox," www.structureisdestiny.com.
is an author, consultant, and public speaker. He consults to Fortune 500 companies, high-tech startups, and government agencies on CAE issues. He is the founder of the League for Engineering Automation Productivity (LEAP) and has been an Autodesk Distinguished Fellow and the Bentley Engineering Laureate. A long-time Computer-Aided Engineering columnist, in the CAD/CAM Monthly e-mail newsletter, Dr. Orr will continue with his reflections on all aspects of engineering. Contact him at firstname.lastname@example.org or visit his Web site: www.joelorr.com