My challenges supporting simulation engineers 2

[ParabolicTet]

I was recently laid off after 17 years as an FEA support person for a large automotive OEM. The company had several hundred simulation analysts performing FEA ( structural, fatigue, CFD etc). My role was to help the analysts use the structural simulation software as well as manage the High performance computing environment . Last I was also involved with software development and assisted developers with writing their custom code to execute on our high performance computing environment.

The role was more a support role. Looking back I faced many challenges trying to gain respect from the large group of users. There would always be a group of users who were not satisfied with my support and would complain to my manager. Typically they wanted someone with deeper expertise in FEA. It is impossible to expect me to be an expert in FEA since it encompasses so many complex disciplines. My background was a MS in Structural Engineering. So I had no PhD. Even with PhD, no one person can be a master in all areas of FEA. Unfortunately, I had a very hard time explaining this to my bosses. They just saw the complaint and would assume it was due to my incompetence.

Another group of users expected lots of hand-holding due to their inexperience with FEA. Unfortunately, I simply did not have the time to do that. With hundreds of users to support I can not spent my whole day teaching someone how to do FEA. I would be very honest with these users and tell them they have to learn on their own by reading the documentation. Again, this created some unhappy users who would complain to my boss.

Last, there was another type of user who would use overly aggressive tactics to get immediate support to their issue. They would CC managers about any minor issue and expect me to "send the army" to fix their issue. They take full advantage of the fact that in corporate culture "the squeaky wheel gets the oil". Unfortunately my personality is such that I do not respond to this type of nagging. In fact I sometimes would drag my feet so they get the message that is not the way to communicate issues to me. They have to be respectful of my time and not expect me just to drop everything I am doing. So some of these folks would complain to my boss.

While most of the users I supported were happy, it was those tiny few who caused me a lot of issues. What should I have done to improve how I handled those folks?

 

[TheTick]

You forget who you work for. Your employer really should have some means of tracking how your energy is being expended.

You had the convenience of simply not instituting basic record-keeping infrastructure. Your employer should have made it happen. However, you failed to fill an obvious gap in the system. Many have experienced pain for it, including yourself.

 

[IRstuff]

"To me it was not "value-added" to expect a user to spend ten minutes opening a ticket that I could resolve in less time it took for them to open the ticket!"

Then, that's a BAD ticketing system. Our's takes a minute. In your case, while you were on the phone for 10 minutes talking to person A, other people would have been left dangling, with no idea when you'd get to them, if ever, and no means of getting your attention, other than voicemail.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[FreddyNurk]

Ticketing also gives an automated justification of just how busy you might be, and how many support requests come in.

It does have the potential to be used as a performance metric, where the opposite occurs due to silly targets (such as opening the ticket, setting it to user pending or something similar, in order to meet a performance quota like all tickets shall be responded to in 2 minutes...) but implemented well, it provides a means to plan workload, and allocate responses based on urgency. Priority cannot be assigned, and user requirements cannot be managed when everything has the same priority (i.e. phone call, NOW!), as opposed to being able to review open tickets for urgency at any time.

It also gives an opportunity to negate all the 'cc boss in on problems' workers, if they don't lodge a ticket, they don't get service, and no amount of jumping up and down at management will matter...

 

[IRstuff]

"It also gives an opportunity to negate all the 'cc boss in on problems' workers, if they don't lodge a ticket, they don't get service, and no amount of jumping up and down at management will matter..."

And, if they did grab a ticket, they'll know their place in line, and if they want something different, their complaints to the boss will force the boss to choose wisely, and make it known to those that got bumped who's been throwing their weight around.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[SomptingGuy]

Without a ticket system, you are juggling. You are also leaving no searchable records. Records might seem boring, but they are invaluable with time, especially if your customers have the means to search them too.

Most IT ticket records will be dull: "Please upgrade node XYZ to OS abc", "Node XYZ is hanging on a bad NFS mount", etc. Not a lot of engineering value in them. Good for resource planning though.

On the other hand, application support tickets should record useful information: "Version X of tool Y crashes when I attempt operation Z.", "Where can I find valve lift profiles for build X of engine Y?", "I'm building a model of engine X and need some help correlating it.". This information shouldn't be held in one person's head or in unorganised records. The same questions get asked by each new herd of noobs. They also get asked by oldies who forgot the answer first time the problem came up.

Of course there are always some people in organisations who like to make themselves indispensable. The only person who can solve a problem. Management don't like relying on these people. They prefer redundancy.

Steve