This technical information has been contributed by
Sauter Industrial Design
Click here to find suppliers
Software Doesn’t Solve Problems
You may have to reach out to the Internet or servers in other locations to complete your process correctly. Remember, if you miss something in describing and detailing your process, the software will miss it too. There are also security issues to consider. Illustration courtesy of Sauter Industrial Design.
By Ken Sauter
Despite what many people say, software doesn’t solve problems. Sometimes it causes more problems than it supposedly solves.
I have heard many engineers extol the virtues of PDM (product data management) software, assuming that implementing PDM software will allow proper revision control of 3D models. It can certainly help, but even if it does, that’s only part of what needs to be done. Software provides tools that can be used to solve problems. The software isn’t going to solve the problem. Only proper use of the software, as long as it is integrated into a well-understood and well-detailed existing system, will solve any problems. Even a good PDM system has to be customized for your particular application. And software is expensive.
Software exists for virtually any task that people do, be it on an individual basis, as part of a small, local company, or as part of a worldwide conglomerate. What you need to do is determine what software is appropriate for the processes you’re trying to automate, how well it does the job you need it to do, and just how you are going to integrate it into your existing system to make it work for you. It also needs to be scaled properly for your company. Small companies don’t need the depth and complexity of software that large corporations do, and they certainly don’t need to spend their hard-earned money on an inappropriate solution for their problem.
Automating an existing process in software without fully understanding your process will simply automate and amplify the problems you have with your existing process. And it might introduce new and bigger problems. You don’t want to find out the hard way the weaknesses inherent in your existing system.
With rare exceptions, whoever wrote the software didn’t work at your company, didn’t understand your particular process, and didn’t know the people at your company who implement your process or how they work. Only you know what your process is and how it fits into the overall scheme of how you receive parts, build them into a product, and ship them to customers such that you make a profit doing it.
Only you can sit down and detail exactly what the process is that is necessary to what your company does. There are people in your company who are key to your process and may be the only ones who really know how to get things done properly. Treat them well. You need them. It’s a big project, but you need to write down your process, from beginning to end, and fully understand the permutations of that process that regularly happen while you are buying parts and producing product. Only after you have done that, and fully understand your own company’s process, does it make sense to automate that process with software. At that point, you know what the software needs to do and have a basis for evaluating different software approaches to solving your problem.
If you were to sit down with a couple of key people and detail, step-by-step, each of the processes your company implements to buy and store parts, assemble them into a product, and then test, store, and ship your product, you’d get an in-depth education in how your company actually does things. You may find out that you are making a whole series of dangerous assumptions. You’re going to find out that there are certain people who know exactly what happens, what problems all too frequently crop up, and how to deal with them. And what they do is necessary to get the job done.
Your existing software may or may not help them do their job, but they will almost always manipulate critical information outside of your software system for the simple reason that the existing software system cripples their ability to get their job done. It may also provide critical information, but it’s highly unlikely that the software does everything those employees need it to do to optimize how they do their job. Spreadsheets will never go away.
Your company has a process for everything it does, whether it is a detailed, well-documented process or whether it is done by someone who just happens to know what they’re doing and knows how to get the job done. There are certain things that must be done, and done properly, for you to track and control all the things that must happen to get your product out the door at the correct revision and to make a profit doing it. That simple set of facts guarantees that you must first understand your own process, then figure out how you can use software to implement your process. And software is usually structured to address a particular part of a larger process.
I cannot emphasize enough that software is no more effective at solving problems than a hammer is at driving nails. The hammer has to be used properly to drive nails. Software has to be properly understood and implemented to effectively deal with your process issue. For that to happen, you first have to understand your own process. Most companies don’t fully understand their own processes. If people in your company are always downloading information from your software system into spreadsheets so they can do their job, it is obvious that your software doesn’t adequately address your process.
There are numerous CAD programs on the market, and all of them are capable products. When I see ads for designers, almost always there is a requirement that the candidate have X years of experience with that company’s particular CAD program. I find this really frustrating.
Spreadsheets will never go away, unless you can anticipate literally everything that will happen with your software and your business, and you program those processes into your software. Illustration courtesy of Sauter Industrial Design.
When AutoCAD came out in the 1980s, it quickly became the de facto CAD program for most companies. It was essentially an electronic drawing board that made all of your 2D drawings look really professional. While I understand there is a learning curve to developing proficiency with any CAD program, CAD software is a tool. Tools can be learned. And tools don’t make you competent, any more than knowing how to use a hammer makes you a carpenter.
Admittedly, there is a period of less productivity while learning a CAD program, but that is temporary. Do you want a competent designer or a really good CAD operator? A competent designer will learn whatever tools he or she needs to get their job done, be it a CAD program, finite element analysis (FEA) software, publishing software, or whatever. I have seen really nice-looking CAD drawings that were just as screwed up as a bad pencil drawing. A bad designer is going to create bad work no matter how nice it looks or how well he or she knows how to use a particular CAD program. Knowing how to use a CAD program does not make anyone a competent designer. A competent designer will learn whatever tools they need to learn to get their job done. CAD software is no big deal. You learn what you need to learn and move on.
A few years ago, I had a client that had been looking for someone who knew Solid Edge. They had a customer who was using that program and couldn’t find a CAD operator who knew how to use it. They hired me because I told them I could learn the program. I did. I was making parts in a day, was fairly proficient in a month or two, and by the time eight months had elapsed, I had designed two complete products in that software. Admittedly, I spent a lot of time on the phone with the help desk as I was learning the software, but isn’t that why you’re paying for support?
If you have a maintenance contract, use it. I now have Solid Edge on my resume. Learning CAD software is not a big deal. If you’re a competent designer, you’re going to figure out what you need to do and get it done, regardless of which CAD program you use or how familiar you are with it. It really frustrates me to see all these requirements for X years of experience with a particular CAD program. Do you want a competent designer or a CAD operator?
Back in the days of drawing boards, pencils, and electric erasers, designers were hired based on their knowledge of the product they were designing. Everyone was assumed to have reasonable competence in drafting. There were some requirements for nice lettering and good drawing quality, but knowledge of the subject you were designing was absolutely critical.
That has never changed. Designing a beautiful, well-constructed rocket that blows up on the launch pad is not what you want. You want someone who knows how to design rockets and will learn and use whatever tools are necessary to get the job done properly. When is knowing your subject going to become more important than proficiency in using a particular tool?
Historical Approaches to Solving Problems
Every company that has been around for a few years or longer has developed systems for dealing with whatever problems come up in the normal process of design and production. When you are writing down your processes, be sure you aren’t reinventing the wheel. I have worked at companies where there seemed to be some rather strange ways of documenting certain products, what with special numbering systems, types of drawings, and procedures. It turned out that those things were developed to deal with a problem that some of our current engineers had recognized and were developing a solution for. What those current engineers had failed to do was develop an understanding of the existing method of dealing with those problems. They simply recognized the problem, then started developing their own solution for it without understanding, or even trying to understand, the system that had already historically been used to deal with the problem.
If your company has been around a long time, there are lots of these historical procedures and systems that exist. You need to understand the problem they address, why and how the problem is addressed in your current system, then determine if you need to develop another way of dealing with it. You may simply need to document the existing method of dealing with the problem. There may be more intelligence incorporated into the existing system than you have any idea of.
If someone has previously developed a system or process for dealing with a recurring problem, there’s a good chance you’re dealing with that problem now. Don’t throw out the historical data related to that problem without first understanding what it dealt with and why. If there is an existing series of revisions or part numbers related to that problem, you want to understand the issue before trying to solve your problem with software.
For a larger company, it might be worthwhile to have a team of people investigate your existing processes in order to develop a detailed understanding of exactly how your processes work (and write it down), and how they should work to most efficiently and profitably produce your product. A smaller company, however, may have one or two people who develop that understanding.
In all cases, the system needs to be written down and fully understood before you can effectively implement a software solution.
How Should Software Be Specified?
What usually happens is that an executive is tasked with investigating software for an application, and then that executive has software solution providers come in and give demonstrations. The executive, or the executive’s team, will decide which software package to use based on their understanding of the problem the software is addressing. Then the software is purchased, and there is a months-long period of integration, when everyone in the company has to learn how to use the software.
It may take years to fully integrate the software into the company’s production process. What usually doesn’t happen is that the people who have to use the software are consulted ahead of time as to how they would use it or how effective the software would be in helping them do their job.
I worked at a large defense contractor for a long time, and at one point, we purchased a very expensive software package to manage a lot of things we did. I talked to a number of people who had to use the software, and not one of them was consulted before the software was purchased. They weren’t aware of anyone who had been consulted before buying the software. It was an executive decision all the way. They figured out how to use it and got their job done, because that was what they were being paid to do. But was that the most effective way to buy software? I don’t think so.
The low-level people who actually do the work understand how your system operates. They will always adjust to the software and procedures they are given to use. The real question is: Are you helping them do their job or just making it different or more complicated by purchasing software? If you were to first make a list of all the people who are going to use your software, then detail what each person does before buying the software, you’re going to develop a much better understanding of what the software needs to do and how it needs to do it.
Even better, have each of them write out how they do their job and what they need to do it, then bring everyone together in some kind of meeting to discuss how they can use the software you are contemplating to get their job done. You may learn some very interesting things about how your company does things. It will very likely have a profound effect on what software you buy and what you buy it for.
If you bring your lower-level people into your software specifying process, you might get total buy-in and their full support in implementing your very expensive purchase (and your yearly commitment to your maintenance contract). When the people who actually use the software have meaningful input into the original specification and purchase process, your implementation is going to be much more successful.
Peter Drucker talks about how the Japanese make decisions by consensus.1 I think it’s worthwhile to consider how we can improve our software specification practices. My concern is implementing software in a way that maximizes efficiency and profit while minimizing problems.
If your company were to float the idea among your employees that you were considering some software that would help you to deal with a problem, it would give your employees an opportunity to discuss how that software could most effectively help them do their jobs, as well as how they would use it to interface with other parts of your company. They might even suggest a completely different, and more effective, solution. It would be worth your while to discuss with your employees what you are trying to do, before investing huge amounts of money and time in new software. If everyone in your company understood which piece of software you intended to purchase, understood how it works, how they would use it, and how they would use it to interface with other parts of your company, you would likely get complete buy-in from your employees and have a minimum of problems in implementing your purchase. And your employees would already understand how to use the software.
The first requirement to buying software is understanding your own particular processes and knowing what problem you’re trying to solve by buying software. Be sure you include all of the historical methods your company has used to solve the problems you encounter. I think everyone understands the value of CAD software. Finite element analysis software is now widely understood as necessary for many applications.
There are hundreds, if not thousands, of applications available for just about every process that modern companies use in their design and production processes. Until, however, you can detail every step of your own current and historical processes, and fully understand what your processes do for you, and just how important they are to your own company’s success, investing in software is taking an expensive chance on solving your process problems.
About the Author
Ken Sauter is president of Sauter Industrial Design (www.sauterindustrialdesign.com), Garland Texas. An expert in designs involving optics and electronics, Ken has extensive experience in designing complex optical systems–including night vision equipment for the military–for manufacturability and reliability. His work includes projects ranging from a large-scale microwave oven for a hospital to an interior for a custom airplane; a flight simulator; plating equipment; sheet metal NEMA boxes; and truck bodies. Ken also has experience with sheet metal, weldments, molded parts, machined parts, and many other methods of manufacturing that are used to produce his clients’ designs.
|Home | About Us | Back To Technical Library | Contact Us|
Copyright © 1996-2010 JobShop.com. All Rights Reserved.
General or Technical Questions? E-mail support@JobShop.com