cancel
Showing results for 
Search instead for 
Did you mean: 

Inconsistent naming within Service Plans and PM Plans areas

Inconsistent naming within Service Plans and PM Plans areas

Inconsistent naming within Service Plans and PM Plans areas

There are a couple of examples of this. It makes it difficult for users learning the system and inhibits training. This has been an issue for several years now and is agreed by all customers I have spoken to as a blocker to understanding and using this functionality.

1 - When creating a PM Plan template and adding a schedule the lookup field to 'Task Template' is named 'work order purpose'. This should be named with the object name.

2- Available Service. The object is called 'Available Services' but in a number of places it is referred to as 'Service". Example if you when looking at a view of all available services hit the 'new available service' button then the next screen is titled 'Create Service' instead of "Create Available Service'. Another example is when adding to a 'Service Plan' a 'pricing rule',

3 - 'Service Plan' object, this is essentially a template to be used to create contracts for customers. It would be logical for it to have template in the name. 'Service/Maintenance Template' for example.

4 - When adding 'labor pricing' to a 'service plan' there is an 'activity' field to populate which looks to be referring to the 'activity type' instead.

5- When adding a service offering to a service plan there is on each row added a field called 'Service Type', this is actually a lookup to 'Available Services' so it should be named as per the object.

VIP Customer Advanced Admin Discussion Group - Any other items you have seen during the training?

Daniel Goldston, Dana Levitt, Shannon Cunningham, Angie Hanning

Product Area?
Mobile Field Service Management Returns Management & Depot Repair Warranties & Contracts
What version of ServiceMax are you on?
Summer 16
4 Comments
Employee
Employee

Having worked with ServiceMax for nearly three years now, there are many instances of inconsistent naming conventions. One of my favorites: Installed Product, Component SN, Product, Product Name are all fields that are Lookup(Installed Product) field types on different objects. I agree that standard naming conventions should be implemented.

However, what makes this extremely difficult is backward compatibility. If you went to upgrade ServiceMax that had significantly different naming conventions, you would spend many man hours going through your configuration and customizations to make the required fixes. I suppose if ServiceMax did go that route, we would have to develop a conversion tool that did most of the work for you or help identify all the required changes. This would be a very costly endeavor and, as far as I know, simply isn't on the roadmap. Sorry, unfortunately, this is not a great answer. Hopefully, someone has a better one.

Staff Chef
Staff Chef

Hi Matt,

I would agree if the request was to change the API names. However most of this appears to be able to resolved by changes to labels in the package. I see this inconsistency as something that makes ServiceMax more difficult to understand and makes it appear less mature than it should be at this stage.

Regards, Richard

Product Team
Product Team
Status changed to: Under Consideration
 
Staff Chef
Staff Chef

Hi @lacy_cotton , maybe some of this can be achieved as part of the SFM designer development work? Thanks for the status update on it.

I did find these naming inconsistencies impeded my ability to understand the ServiceMax Product/Solution when I was doing training and development. Which of course is not something you want for your product.

Regards, Richard