Right at the start of this Weblog I let out the great secret of how easy it is to run a project to choose your ideal electrical systems interconnect design software package. Obviously I’m pleased but not surprised when it turns out to be Capital which is the ideal choice, but that’s by the by for now. I want to re-introduce you to that simple model. It describes the things which regardless of organization size you need to focus on to realize the value in your business using tools like Capital - an off-the-shelf commercial software package. Whether you are in a large or a compact business unit, doing electrical design through to manufacturing for aircraft or spacecraft, a transportation OEM like a car or an off-road vehicle maker, or a harness supplier to this sector your needs map looks similar to the diagram below. Use this as a guideline and your evaluation will be swift, inexpensive and effective.
A: One quarter of your requirements cover the adequate modeling of your finished product and the design to workflow manufacture of that product. The parts, the assemblies, the quantities, the relationships and the characterizations - everything.
B: One quarter of your requirements comprise realization of the business benefits (for example doing more with the same or less human resource, fuelling market expansion). These requirements do not manifest in individual features of software functionality. The realization of business benefits is the goal, why you purchase in or software built.
C: One quarter of your requirements consist of the satisfying of your organization’s CAD output needs, like adhering to drawing standards, representing entities on printable documents which have been drafted flawlessly and efficiently.
D: One quarter of your requirements involve attaining a degree of interoperability and automation between your electrical interconnect systems design domain and the rest of the organization, for interfacing and integration with PLM, PDM, MCAD, commercial, inventory systems.
So approximately half of the needs address technical determinations (A and C) and the other half are located firmly in the organization’s business drivers (B and D). Some organizations are biased more towards their engineers’ interests and some organizations give primacy to the commercial imperatives, and so emphasize systems integration, time to market and reductions in quality failures. There is variation, but there is invariably common ground.
More home-grown or less?
In which of these 4 areas are you normally going to find more “home-grown” coding going on, and where are you likely to find less? It is in the area of interoperability where appearance of custom coding is most often seen.
Motivation to stray outside of your vendor’s offering, or never go there in the first place comes from three areas. Firstly to supervise and help users you can develop a business and systems overview which can lead you away from commercial solutions. Secondly, with a software suite, or a network of software point tools of sorts in place, managers and engineers are faced with flaws in coverage and choose to fill in the gaps themselves. Thirdly, there’s a desire to expand out from present known functionality, doing the same sort of thing better, adapting to a new reality in the business using similar solutions to what has worked in the past.
Let’s look at these in turn. The letters A,C,D refer to 3 of the requirements’ quadrants above.
- Imperfect vision = imperfect solution.
Planning, responsibility and support for electrical systems interconnect design is needed. If supervision of the information technology automation of the domain is patchy, and in the absence of comprehensive tool coverage, problems can result in localized solutions being applied at the areas of greatest pain. Point tools will result, some of them customized e.g. generalized office automation tools with added value like spreadsheets may be used, with Visual Basic, & standalone databases or similar. These can adequately fulfill user needs, solve problems. Over time these outposts of automation may be joined up. The interlacing of special custom-written solutions adds a further degree of difficulty dislodging the ad-hoc collection of utilities or more sophisticated suites of programs. This difficulty at such time as the organization wants to impose a more holistic approach to their business is going to cost money and time to resolve.
- Gap Filling.
A: Where an off-the-shelf system is unable to model say a particular widget that is used in the finished product.
C: Where an off-the-shelf system cannot automate to your complete satisfaction the graphical representations you want to see in your schematics and you choose to supplement the functionality.
D: Where an off-the-shelf system does not offer an interface to a corporate system and you elect to make your own arrangements to make software to interchange data.
A: New circumstances can arise in the workflow - for example willingness to adopt a new design approach, e.g. composite or modular complexity. Also functional additions may be desired because new physical aspects of the electrical systems interconnect are not catered for and your vendor cannot implement changes to the core tool at your request so you elect to construct the software yourself. This is unmet need which ideally your vendor or their consulting organization can also cater for. Sometimes a third party consulting effort can meet the need. Or you may look to internal resources. One simple example is that your business extends beyond a need for a single-user or federated pattern of usage into fully mediated client-server architecture.
C: CAD Outputs. Again a new design approach can have a radical impact on the appearance of drawing outputs and consideration may be given to different approaches to making this more efficient than relying on manual re-work of the graphics.
D: Interoperability. Changes in versions/capabilities of Mechanical CAD systems’ usage are typically what comes to mind in terms of extensions that Capital or a similar tool needs to be most often catering for. With a reputable vendor, one which is putting effort into maintaining and improving their offering you can expect a strategy to cover most, if not all of these needs.
What’s in it for the end user?
Using a vendor’s API has significant advantages in terms of enduring compatibility with the object model. The data definitions and the API will adapt to the change in the metadata better than an external resource calling in to the data structures, for example through ODBC.
Be aware of your finish line and decide where the “good enough” mark is, giving engineers what they need to do their designs and giving you access to your own data. It is a mistake to reach for the same solution to a customization need which worked last time (for example the spreadsheet macro) in a new context. Software vendors can fall into this trap too, but should be less prone to it. It can be like succeeding in fixing your heating system with a mallet and a screwdriver when it was faulty and then picking up the same implements to deal with a cracked pane of glass.
In part two, I will get to the discussion of the money aspect - give you some pointers as to how to decide whether to grow-your-own solutions is the most cost effective way.