The first principle I set out in the previous post which was essential for a good decision : “Adequate model of product and process.”
“First” meaning it was one of four that happened to come first. My conclusion was that all are essential and if you are compiling an RFQ and then thinking of running an evaluation project for a cabling and harness design system. You should place about equal importance on all four.
Let’s break down the two aspects which I refer to in the summarized principle of modeling as “product and process.” I am making a distinction between how you use IT to construct a model of the designed and manufactured physical entity which result from your design and on the other hand you also operate with a model of the engineering workflow, the design and manufacturing processes, the data transitions, the systems abstractions and task controls. This is drawing a dividing line between the represtentation of the end result which you can touch and feel and the representation of the human activity, for example the release and change management steps.
If you listen to people talking about what they want from a system (a very important point that, you must bring your best listening skills along) – they give you verbal clues they are talking about accurate portrayal of their jobs being a fundamental concern to them. The keywords in these sample statements of requirement are italicized. Watch out for sentences like:
- When we’re using multi-conductors in cables, the system should be handling them so that jacketed cables within other jacket cables are understood.
- Composite attributes to deal with multiple equipment configurations are essential in the way we work now
- The BOM contents must be in a special format in order to be understood by the manufacturing source.
- Our people spend far too much time interpreting component data and cross-referencing it instead of designing – the library function needs to be better acheived.
What’s the big deal about having accuracy of modeling? Isn’t it the point of having CAD to aproximate, summarize and cut down on the time spent using mock-ups and prototypes? The big deal here about modeling your finished product, or refining your product model as it is being developed without the appropriate, adequate level of detail is that you run into difficulties. There may be legitimate debate about the level of detail necessary in a given area or at a stage of design. I think everyone can agree however that accuracy is paramount – for example – if the underlying simulation model for an electrical part is flawed, FMEA studies can become unreliable or invalid.
The difficulties are, for inaccurate/incomplete engineering models of the product that interpretative tasks remain un-automated. In practical terms this can mean for instance – a manual edit to a CAD drawing has to be done to communicate design intent – and that “exception” then becomes something which an engineer “just knows” to watch out for for the rest of the life cycle of the design. You buy IT tools for automation, and workarounds like this nibble away at the optimal efficiency of your engineering. Loss of time and money occurs. Select a system capable of representing the reality of your product closest to perfection. You might of course be nowhere close to perfection at the moment – would you be looking for new IT tools if you were?
An ability to model of the way you want to work is important too. If you are considering a new way of working, want to expand or re-formulate the work flow or are being obliged to do so by the pressure of business it would be a disappointment to have a software system which knows nicely the difference between Kevlar sock-weave and heat-stakes and IDC connectors but condemns users to shoe-horn their work flow, the collaboration steps and hand-offs and release safeguards into functions inadequate to represent the organization’s reality. There is another set of representations here to be adequately modeled – ones which could be overlooked during evaluation, but will not go unnoticed during deployment by disgruntled users as inefficiencies and compromises become apparent.
It has become commonplace over the last two years for Mentor Graphics to get involved in CHS pre-sales interaction using a simple yet revealing modeling technique derived from cross-functional flowcharts. This is increasingly a significant part of the “due diligence” which takes place prior to implementation. Consultants, sales technical specialists and account managers are well versed in how to apply the knowledge and methodologies of process analysis to individual customers’ needs.
These are the top-level aspects of being assured that your reality is going to adequately, comfortably, snugly fit in the new system. Detailed requirements can get quite numerous here on some occasions I have seen. I think a prospective adopter of a system like CHS could actually save themselves some time by resisting the temptation to list exhaustively everything at first cut. Save that for vendor evaluation if you like. The document at RFQ stage if you want to develop one should extract just some of the more fundamental reality-modeling concepts needed. At a push you might want to include some of the ones which are especially pertinent to your own domain or enterprise special circumstances too but subject them to validation first to make sure they really are essential to the way you work.
If your vendor exhibits the best practices, the best product offerings here, they are a quarter of the way to proving to you a case for doing business with them.