Sign In
Forgot Password?
Sign In | | Create Account

Choose wisely and once - Part 2: A model & it is looking good.

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.


Effective capture of customer processes and design flows

Effective capture of customer processes and design flows

 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.

RFQ, Evaluation, CHS, Harness Modeling

More Blog Posts

About Paul Johnston

Paul JohnstonI help Mentor Graphics customers to be successful, accomplish a more rapid return on investment. My professonal focus is on the Capital product line. Customers need a good technical and commercial understanding when making software system purchasing and adopting decisions and in addressing issues through to best resolution. I am one of the team of experts Mentor employs to support the Capital worldwide. I was born just outside of Manchester England, am now resident in the metro Detroit area of Michigan USA. I have worked for Mentor Graphics for more than 15 years. Visit Paul Johnston's Blog

More Posts by Paul Johnston


No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat