Can (Software X) do (complex operation) Like (Software Y)?

I’ve done a fair bit of tech support, training and process consulting. And yes, I’ve done a bit of answering questions on online forums. See if you recognize this scenario. Someone who seems a little bit angry asks a group of users of Software X if they can do some operation that sounds very technical and complex “like Software Y does it.” You’ve done this, I know you have. Just fess up to it. C’mon.

After I’m done rolling my eyes, I can start deconstructing what this person really wants. You see, typically, this person is angry about being forced to use some other software than the favorite. And if they can prove that the new software can’t do something as well as (meaning “exactly like”) the old software, well, then we can dispense with this “evaluation” very easily, can’t we?

The real question is often not what this person is asking at all, but they are carving out a very detailed situation completely out of context, and asking you to get exactly the same result with different tools without understanding anything about the larger issue. Of course you are expected to do your part and fail.

The first thing you have to do is to understand the situation you are stepping into by attempting a good faith effort to solve the problem. This requires you to get the person who brings the problem to back up a couple of steps. See the whole situation, or at least the model. Ask what the real requirements are. See an example of what they are trying to accomplish.

Sometimes the person bringing the problem is a knowledgeable and sophisticated CAD user. But often this isn’t the case. Still, you don’t want to insult someone, so part of what you’re doing here as a support tech is to evaluate the skill level of the user. This is a place where professional tech support often falls down. There are situations where users who have actual problems and call tech support and the user is actually more skilled than the support person. Support people have this tendency towards self-righteousness. I’ve been on both sides of this, so I know. Many support techs assume that the process of support is actually a game where they are the goalie, and the customer is trying to get one past them. So no matter what the user says, they are wrong. But for the moment, let’s assume that the support person is doing what they need to be doing.

Let’s take an example. The customer is trying to do an evaluation of X to examine replacing Y. They are trying to put a fillet over the top of a rib in a shelled out plastic part. The fillet keeps failing. They assume that software X just sucks because it can’t create this fillet that software Y does so easily. So the question is about the fillet.

Maybe it turns out that the rib feature caused a modeling error, and the fillet works fine, but there is a problem with the model they’re trying to put the fillet on.

There are a couple of points here:

A) The complaint is often not the root of the problem. Even when you find the cause, that may still not be the root of the problem.

B) The root of the problem is often workflow. The user is trying to use the workflow of the old software in the new software. For example, you can use Solidworks the way you use Pro/E, but you can’t use Pro/E the way you use Solidworks.

The first CAD system I ever used was CADkey. The second system I used was AutoCAD. The order of button pushes for those two programs was exactly reversed. Even if you knew all of the commands in both programs, you had to think about the commands in reverse order.

When you switch between 3D systems, you sometimes run into similar issues. Even though Solidworks and Solid Edge are very similar programs, the workflow through the interface can be very different between them. If you try to use one software the same way that you use the other, you’re going to be frustrated all the time, and incorrectly come to the conclusion that either software “just sucks” mainly because it doesn’t work like the other software .

As a user of multiple tools, you have to understand that each tool has a certain flow of commands – an order in which the software expects to see things. Getting mad at the tool doesn’t do you any good. You have to have some imagination, and be able to conceive of a different way of doing things. Be flexible, less rigid. Learn to speak to the software.

Also, don’t allow someone who is angry or bitter or has some axe to grind do a critical evaluation. You have to be less emotional. You have to be willing to try, and willing to learn something new.

The fact is that even software with a lot in common do things differently. To do a real evaluation, you have to be willing to learn something new, and see things from a different point of view. It’s hard to be objective when you have a lot invested in software that for various business reasons, you might have to dump. And it’s probably ridiculous to say Software X can’t do what Software Y does. It probably can, it just does it differently. You figured out how to do what you did in X, it is likely someone else has figured out how to do it in Y.

Being closed minded and angry doesn’t prove anything that you want it to prove.