What Are Challenges With Today’s PLM Support?

 

Challenges with PLM support

Several companies today have set up a PLM solution for their existing engineering processes. It is safe to say that the strategy followed by implementation across functions is well-planned, documented, and communicated to all.

But is much thought put into the post-implementation phase? How will your business maintain a PLM environment efficiently?  After such a planned set-up, isn't it necessary that the company has the infrastructure and team to provide top quality PLM support?       

Normally companies use an internal or an external support team to support their users. These support teams usually use a ticketing system, remote helpdesk, or an emailing system to answer and resolve user support issues. Most of the time support team is remote to minimize support costs. While the PLM software and digitization have provided better quality software and new functionalities, still the users are facing some traditional problems over and over again. Support teams seem to have stagnated with the problems mentioned below:

 

1. Delay in response due to inadequate priority:  It is frustrating if we raise a ticket for an issue but, the support team considers it less critical, allocating it a lower priority.

Imagine a situation where you face a PLM support bottleneck. You raise a ticket with your support service provider. The support team may be busy solving an ongoing issue and does not understand the criticality of your issue causing a delay in response. You have a deadline for project delivery today and even after completing the formalities of creating a support ticket, the response to your ticket is delayed. A lot of time is wasted, and you do not reach the deadline causing frustration.

Many service providers do use a priority ticketing system today and allocate priority depending on the criticality of the issue but still, a delayed response arises when there is a mismatch between the user priority and the support team priority. This mismatch causes a delay in issue resolution, resulting in a loss of time. Also, a queue in support tickets might be caused due to limited or inefficient support staff, causing the support team to struggle with issue resolution of all the existing tickets. Either way, you suffer due to loss of valuable time and unaccomplished project delivery. A radical change in approach is necessary to overcome these typical challenges.

 

2. Remote communication: If the support team is not in the same office as you, will it not be difficult to explain and replicate the problem to the support team located in a different place than you?

In the case of a remote team, you will find it difficult to explain the issue or the support team will find it difficult to understand your problem. Either way, time is lost in investigating the problem, replicating the issue, and finding the solution.  You may also face issues due to:

 

a) Noise Interference

Consider a situation where you are trying to explain a technical issue to your support team in an online meeting. An online meeting is convenient and cost-effective option, but it is affected by noise interference and, you may face issues like:

·      You or the support team cannot hear anything. Is either of you muted on the call?

·      You or the support team start hearing an echo owing to a bad internet connection.

·      You or the support team is hearing static, beeping, or clicking on the call.

·    The on-hold beeps or chimes, when attendees leave and rejoin, is quite annoying. 

It results in a high call drop rate, again causing the delayed response to the issues at hand.


b) Inadequate Network

Problems with hardware, servers, and other network issues inhibit the effectiveness of a remote support team.  The non-availability of a speeding network will also be one of the main reasons for delayed or no response. The first step would be to check the internet speed, followed by killing unneeded processes, eating your bandwidth that might be limited.


 3. Issue Replication

What if the support team asks you to replicate the issue that you are facing? Will you be able to replicate it the same way each time?

Consider a situation where you face an issue while working in the Teamcenter environment. You raise a ticket with the support team who connects with you for issue resolution. During the problem investigation, the support team requests you to replicate the problem in an online meeting.

·     You may not able to show how the error came the second time since you follow different steps this time.

·     The support team has fresh login and hence cannot view the error as shown for you.

·     You and the support teamwork in different environments causing difficulty in issue replication.

Hence, valuable time is lost in screen sharing and issue replication, resulting in a delayed response.

 

 4. Difference in Scope

Many a time, there can be a disagreement between you and the support team over the type of the problem. Once you raise a support ticket and the team examines the problem, they may think that the issue is CAD or related to other systems that are not under its purview. The team then sends back the unresolved ticket to you stating the same. You then contact the relevant support i.e CAD or others, who come back to you stating that it is a PLM problem. It can be quite frustrating, and a lot of valuable time is wasted in back-and-forth communication. Also, it leads to no resolution in the end.

 

5. Server downtime

What if the system is down since something is wrong with the server?

Consider a situation where the Teamcenter servers are down and not working properly. A first-morning user logs in to the system and realizes that Teamcenter is not working due to issues with the server. Service has not yet commenced since the support team has not yet looked into the same or, the process is still stuck midway. The first-morning user will report it to the support team post which resolution begins. A lot of time is wasted by the time the issue is resolved.

Server downtime can be quite a costly issue. If you multiply the downtime with the number of users, it is quite a costly downtime.

 

Bottom Line

A properly working PLM system is supposed to help the user in their daily tasks, improve quality, productivity, and collaborative effort. If you fail to provide the necessary support required for the smooth functioning of this system, it will too fail to provide the desired result.

So, are you facing similar problems in your existing PLM support? Would you like to find a better approach to deal with them? If so, contact us at info@plmnordic.com or visit the website https://www.plmnordic.com/

Comments

Popular posts from this blog

ATTRIBUTE MAPPING ON TEAMCENTER INTEGRATION WITH NX

NX Machinery Library Installation