Just because you know what is right does not mean you will do what is right.
"Well begun is half done." A clear statement of any problem often reveals one or more solutions.
Early in my consulting career, I observed that one of the key benefits of an automation project is that it requires study and understanding of existing processes and systems.
In business, it is common for workflows to evolve. Things are done a certain way, then the process is changed as the need arises. The problem is that such changes are usually made on the basis of a narrow view; they optimize locally, without consideration for "the big picture."
An older gentleman was rejected for front-line service in World War II. He restlessly wandered around the Pentagon, seeking ways to support the war effort. He came upon a room in which a film depicted a five-man team operating a large field piece, a howitzer, was being projected, and found a chair.
Though silent, the film was well made and engrossing. The team would receive instruction from the artillery officer, adjust the elevation accordingly, and load and fire the weapon. One man would open the breech, another would insert a shell, and so on. The men moved very smoothly and efficiently.
"Why are you watching this?" our man quietly asked the fellow next to him. "We're efficiency experts," the man explained. "Do you see how after the shell is inserted, one man retreats a few feet and stands at attention until a few seconds after the piece is fired? What's he doing? Might we reduce this to a four-man team?"
At that, the visitor burst out laughing. Someone flicked off the projector, while someone else turned on the lights. "All right, wise guy, what's so funny?" asked an annoyed voice.
With a smile, the visitor answered, "That 'extra' man is holding the horses!"
Large guns used to be pulled by horses. Horses do not respond well to the report of a howitzer. So before firing the weapon, the team would have one man hold the horses, to calm them and keep them from bolting.
The horses had been replaced by mechanized vehicles decades earlier, but the workflow hadn't changed.
How many processes in your organization have someone holding non-existent "horses"?
Such superfluities often get uncovered in the course of an automation project—which is why they often fail! Management decides it's time for a new cost-accounting system. But before it can be implemented, the existing system must be documented.
It doesn't take long to find out that what is being done bears little resemblance to what is in the company's policy and procedure manual—and that, in fact, obtaining the many benefits promised by the software vendor will necessitate major changes.
That's the point at which such top-down-dictated projects often get sandbagged. The middle managers who will be responsible for the implementation see only grief for themselves, and few benefits. For them, it is far easier to explain to top management why the new system "is wrong for us" than to make the changes required to make the system work.
So regardless of how well the proposed system has worked elsewhere, its failure is documented, often, as having been the fault of the vendor.
Companies are not monolithic. What is obviously good for the company—for profitability, shareholder value, and so on—is often a pain the neck for some of the employees. And since the link between the health of the firm and their own benefit is often unclear, employees often "drag their feet" when it comes to new systems.
As Machiavelli pointed out in The Prince, anyone wanting to introduce a change into the existing order of things will have a difficult time: They will encounter the fierce resistance of those who think they stand to lose by the change, and only the lukewarm support of those who stand to gain the most by it.
So implementation of new systems—CAD, CAE, PLM, or whatever the automation horn-of-plenty has just spit out—must be undertaken carefully. Any such project must include the following points:
- Situation appraisal. You have to have a clear idea of how things work now, who is involved, how long everything takes—and the strengths and weaknesses of the current way of doing things.
- Envisioning the future. How will things work when the new software is in place, if everyone is doing what they are supposed to? What changes are required to get from how things are to the way they ought to be?
- Executable plan. In most situations that require a transition from no automation to automation, the required changes are too radical to undertake all at once. What intermediate steps can be reasonably achieved, so that the company can continue operating during the transition?
- Decomposition. How do these changes translate into new requirements for all the people involved? On the micro level, which of these changes will require special attention—perhaps because they entail what appears to be a downgrading of a person's role, or a move?
- Evaluation. Once the true cost of the transition has been estimated, taking into account all the required changes, do the projected benefits still make the project appear worthwhile?
You don't have to be a fortuneteller to see how things will work out. You just have to look at things at the right scale, with the eye of experience.
If you know when the horse is thirsty, you can be sure he'll drink when you lead him to water.
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