Requests for Quotation, Requests for Information come the way of the sales force in Mentor Graphics frequently. Prospective customers ask for testimonials, competence, references and proof of functionality.
Following on from my last posting here is what I found. My experience, my analysis of the data.
These requirements in total over all documents I reviewed show a very even split. Hundreds of individual expressions of … the software should be … we are looking for … it is essential that … and so forth.
A: a quarter pertain to the need to model reality of the cabling harness product adequately, accurately. The technical complexity and variation in the engineering, if not catered for will result in workarounds and compromises. If the model is deficient, eventually the deficiencies bring down the efficacy of the whole system. Likewise if the process of engineering change or the workflow of design cannot be wholly encompassed by the functionality the software is not usable.
B: a quarter indicate the desire of the potential owner of the software suite to derive business benefits from owning the software. Let’s express that simply. More for less. Eliminate waste, maximize efficiency. And other things like that.
C: a quarter of the expressed wishes related to the fact of professional life electrical interconnect systems are understood by reference to Computer Aided Design artifacts – blueprint outputs, drawings, schematics and the like which have standards to which organizations choose to adhere. The CAD is vital and the CAD outputs style are constrained by convention, compulsion and custom.
D: a quarter of the “must haves” or “criticals” or “key” or “really important” requirements reflected the need for interoperability in the Enterprise. Downstream, sometimes upstream, out to MRP/ERP, to manufacturing, to simulators, test equipment, across geographies and time zones everything is interdependent. Integration of systems could be a huge hidden cost. Everything has to play nice together. No interoperability no gain.
A – Adequate model of product and process
B – Business Benefit to be derived from ownership of the system
C – CAD outputs to meet the customer/internal needs
D – Definitely Interoperable
A bit of a linguistic squeeze but a reasonable A-B-C-D isolation of 4 critical categories into which individual requirements can be slotted.
The rough parity was interesting, and it suprised me. I wasn’t expecting it.
In the analysis I did there was roughly a quarter for each of these principles. The lowest under 25% was B – and this makes sense because you tend not to tell your potential suppliers of software tools we would spend a million to solve this problem because we are losing five million a year – because you fear that you are encouraging the vendor to set the price to $999,999.50 and argue you are getting a great deal. The highest over 25% was C – reflecting the prevalent worry that if the appearance of CAD outputs in every last detail is not correct then the difficulty in changing history, practice, plotting devices, customer willingness to modify their deliverables etc. is scary. Change often is, and learning a new system, a new way of designing, new paradigms, new workflows – then who wants the bother of having to tear up all the drawing standards and start over?
Balance is a good sign. Imbalance can be a problem across these categories. A & C are tactical to a CHS user’s business, B and D are more strategically aligned to that business’s top level goals and initiatives. So where I see a skew to A&C combining to a lot more than 50% I know that this orgnization is devolving a lot of responsibility to engineers, empowering them and I have learned to ask questions about the extent of executive level backing in the organization because if those elements are missing the implementation project will quickly run into problems. The reverse is true, if I see an RFQ biased towards the need to interface to an enterprise’s mechanical CAD solution, the Product Lifecycle Management solution and to provide feeds to the Management Information System I know there is somwthing missing. I suspect if an RFQ refers to VP level quality initiatives or uses buzzwords e.g. “alignment harmonization” which need some digging to find out what the substance is behind them – I suspect that the adoption phase of CHS may well run into user level resistance – where is the balancing set of requirements that the circuit list table headings really really must be in a particular column order or else? Also there is a difference in emphasis in individual cases – a build to print supplier of harnesses for medical equipment has different needs and expresses them differently than an organization designing the electrical interconnect for satellites and missiles. Over the cable/wiring harness design and manufacturing sector as a whole the similarities become more pronounced the closer towards a macro view you are getting reviewing the requests.
Ok. So here’s an important point. I don’t know as well as you do what you want. Only you know that. But I have seen a lot of what other people in similar situations have said about what they want. So I do have a pretty good chance of understanding you when I listen.
Are A-B-C-D all necessary and sufficent?
Desirable future by category for electrical interconnect systems definition IT tools
If you don’t have B – why bother? Upper Management will kill the project stone dead as soon as the proposal is elevated to them. If the software, the system is falling short on A & C – then things become very difficult as the small things add up to a large problem in the end. But there’s a certain amount of slack here, a learning curve, configuration and usage to learn, plug-ins and add-ons to trial. If a vendor is hopeless at or can’t do D – the systems interoperability a sophisticated enterprise needs – but the rest of the package looks brilliant, then you might decide to purchase and build a D solution yourself. But this of course impacts the B – the business benefit, the Return on investment looks worse than it might.
The value when evaluating vendors is that you have four quadrants in which you can assess whether your chosen solution is a technical good fit and is with a suitable business partner. Both are vital. You are looking for a vendor who has both the technical domain expertise and the committment to you as a customer which will help you acheive your organizational goals (for example reduced cycle time, improved quality etc.) as a trusted partner over the next decade or more.
I believe it is efficient to eliminate the following (just for now – not for all time): Requirements that your vendor has a support or training offering of a certain type. Requirements about operating system platforms or specialist IT considerations (must use EJAX with Pineapple Sauce) – toss that to one side and come back to it. Stick to A-B-C-D. That’s the first priority group of questions to be answered.
Once you select a software supplier based on these criteria – special IT needs (additions to cost of ownership) have a context where the benefit of owning the application is understood – the benefits of ownership, the value and return for investment is clear. As for Training and Support, on site consulting, professional services, applications engineering – well if the commercial off-the-shelf offering is best of breed ( wins A-B-C-D test) then you would probably expect that vendor to back their product with good staff. It usually does work that way.
Lastly – is there budget? Sometimes funding is secured in parallell to the technical feasibility studies, the RFQ and vendor selection, sometimes it is done prior. And sometimes the plug is pulled half-way through the process because Credit Default Swap Derivatives this or housing market collapse that or company X is aquired by company Y. Ignore that too for the present (as much as you can) and dance like no accountant is watching you.
Test the competence of potential vendors in categories A, B, C and D. Then proceed to detailed system evaluation with the vendor that comes out on top.
Congratulations you have saved a pile of time and money.