Efficiency in product development – horses for courses

1096 0

A variety of tools are needed to drive efficiency in product development but while technology often gets in the way there are other hurdles to overcome before you can adopt the best tools
for the job, writes Rob Jamieson
To get our jobs done today we need to use several different software tools. There is very little software that does it all. I know that some designers spend most of their time doing a set job but if you need to visualise a project or add electrical to a mechanical design to get a peg board layout you have to use a different tool.

Once you have created your design data you can take it into an add-on package, but most of these are more expensive than the base design system. If you had a large design department with multiple copies you could get the floating license version but to install the add-on you need a license per workstation in a lot of cases. If you can get a floating license it often ends up being a race to log on first in the morning to take the licenses and companies generally end up requiring one add-on per seat, which bump ups the price.

Working with data

If you need a different tool or software from another provider you need to get the data from your current software into it. In some cases it’s quite easy, say taking data into a PDF to distribute, but if it’s taking NURBS surfaces or parametric data it’s generally not in the interest of the original software provider to help you get your data into a competitor’s package.

Once I was helping a potential customer who wanted to visualise aircraft assemblies for training purposes and was looking at purchasing 3ds Max. The design software supplier was there and we asked for IGES files, as all we needed was the geometry. Once imported the model was full of missing faces, so I went and sat next to the ISV (Independent Software Vendor) supplier’s onsite person to look at what he was exporting. It transpired he was using an older version of IGES, even though a later version was supported in his software. I asked if he could use that and he initially responded that he couldn’t, but after a bit of persuasion he exported this file and it imported into 3ds Max with no issues. The company then purchased 40 seats.

Horses for courses

The scenario where the best bit of software for a job might not come from the same provider is quite typical. Of course each ISV believes it has the best solution across the board but invariably some ISVs are better at certain design requirements than others. In some cases software will even be recommended to do a job that it’s not really fit for – the hammer manufacturer selling you its top end model to drive a screw, springs to mind.

Again a lot of visualisation software is used to win bids with 3ds Max for architectural projects but the 3D data can’t be taken into a CAD package with any accuracy.
The other problem with using multiple software vendors is learning the software itself. In addition to often having different workflows, each vendor uses its own menus and naming conventions. Microsoft implemented the ribbon menu and a lot of design software is now using this or planning to. Personally I’m still fighting the ribbon in Office but perhaps I’m just getting old.

In some cases software will even be recommended to do a job that it’s not really fit for – the hammer manufacturer selling you its top end model to drive a screw, springs to mind


A question of politics

What happens if the corporate standard is one type of software but another supplier fits your needs and cost structure better? I was at a recent ISV event where a large corporate customer wanted to switch to the software that was being showcased at the event. The issue was that the company policy was for a more expensive system with limited add-ons even though it didn’t particularly fit his needs and even the supplied hardware wasn’t up to the job for the types of models he created. While overcoming the politics was one challenge, he also needed to work out an efficient way to get his design data into the new system. It’s often hard for companies to cope with the down time and the potential cost/loss of data. For reasons like this, a lot of people stay with their current ISV and take what is offered. Each ISV also has a form of subscription, which ties you into using their software and if you stop paying you have to pay more in the future, should you upgrade outside of a subscription contract.

The power to change

Before the credit crunch I used to travel to other countries in Europe where there tends to be more analysis on the overall cost of ownership. In Germany, at the larger car manufacturers, each vendor must supply their hardware for tender and they choose the best value and performance. I’m not saying they swap software each year but they still have more control at a local level in the design dept and it certainly works for hardware. One of the reasons they have more control is to do with the value that is placed on engineers in Europe as opposed to the UK. Sadly, this is something that is not going to be fixed overnight.

If you are thinking of switching software, as well as asking yourself can it do the job as well or better, my recommendation is to do a complete cost analysis of swapping ISV providers and hardware, taking into account, subscription, translation, different support, and downtime costs. The intangible costs such as who will give you better support, links with your suppliers, improved quality of product and shorter lead times should also be assessed even if there are no hard numbers as it’s likely that you will have to live with your decisions for a good few years.

Choosing the best tools for the job is a complex process, which not only needs careful assessment, but a lot of manoeuvring. Just make sure you don’t get stuck with a hammer when all of your products are assembled with screws.

Rob Jamieson is marketing manager for workstation graphics at AMD. He once considered moving to Germany to command more respect as an engineer. That thought didn’t last long. The opinions expressed in this article are not those of AMD.

{encode=”robert.jamieson@amd.com” title=”robert.jamieson@amd.com”}

Rob Jamieson says use the right tools for the job

Leave a comment