This is not controversial. But it is surprisingly often neglected, or lost sight of when organizations are considering refreshing their capabilities for systems interconnect tool integrations. The IT professionals involved in evaluating the vendor offerings know what they are looking for, the electrical engineers, the harness designers and wiring specialists have a well polished technical appreciation of what they want. However around a quarter of the requirements should go to the heart of the business case for owning software.
It is all well and good if an application looks nice. If some of the things which happen are impressive, some functions execute in an attractive user interface that’s pleasant too. Unless the results of examining a new set of tools reassures you that your business will operate more effectively (higher efficiency and/or reduced costs) forget it. There is not a justification which can override this. This is the crux of the need, the rationale. The other three principles involved in the selection of an electrical interconnect design system are subordinate to this one - they answer the question ”will the job get done okay using a specific tool or set of tools?” This is tantamount to the question - what’s in it for me? An alternative angle to consider - what other resources or expenditure you are prepared to sacrifice in order to own the new system?
There are motive forces operating on a business which steer you towards adopting a new set of tools and methods and away from processes which used to work well, but are now insufficent in some way. Positive factors, like the drive to increase market share, expansion and ambition to diversify into a different market. In the current economic climate however, I’m seeing that the need to trim costs, to make engineering human capital spread already thin range even further, the absolute competitive need to do more with less is the type of driver sending organizations out looking for a software re-tooling and considering Capital. This is a push from the market, and most potential customers naturally find the challenging environment tough. It is unpleasant to face up to the reality that if you are not the best in class, you might not be in existence very much longer. But face up to this you must.
Why should you share details of your anticipated return on investment, the business objectives, the executive level initiatives, the plans to combat competitors strategies with a software supplier? That is private and confidential data. Yes. A non-disclosure agreement should be in place. Not telling your future business partner in unlocking improved performance, efficiency and savings is like asking a person on the street for directions to the park and when they say “which park?” you reply, “Well, I can’t tell you that, it is personal. All I can say is that it has some trees and some children’s play equipment, and other things I can’t mention. But if you give me directions and get me to the right park in this city, then I’m going to be very grateful.” You’d get a puzzled smile and sympathy at best. Worried about the ethical standards of a vendor company? Don’t deal with them at all.
Sometimes the requirements when you are thinking of evaluating a systems integration/electrical interconnect/cabling & harness design system can conceal the business value inside them like the kernel inside a nutshell. I encourage people in the market for a new way of working with tools to make the requirement explicit.
So, warning, explicit content as they say. Here are some examples or requirements statements.
We need some software can the support design development in half the time we can currently manage
Quotes should be turned around for our customers in maximum 3 days, currently the average is 10
We will restructure so that diagrams are authored and released by Engineers, not by a remote CAD drafting department
Quality issues and BOM mistakes cost us $837k/year per program on average and contributed to 2 project overruns last year.
We don’t know whether our suppliers of harnesses are quoting fairly for the work we award to them. All we know is costs are rising, and we must get control.
There’s just a few examples. Making a business case, calculating ROI, NPV etc. etc. is a fact of life for many people doing budget submissions. Procedures vary to getting your procurement project approved and understood by finance, purchasing. If you need help preparing the business case, if your last stint as a technical author and accountant combined in your career was “never” then a good vendor (clears throat …. like Mentor Graphics for example ….. ahem …) can help you with ideas and expertise. Normally this is something a potential user of Capital already has figured out.
Once you have figured this out, it is one fourth of the way through understanding the totality of what you need. But this is the really nice part - this is the quarter of the job of defining your requirements - where you get to learn what’s in it for you, what the payoff will be.