Hey folks: When servicing more than one product with a single service call, how do you organize your workflow and why:
1 - As a standard work order, with each product presented as a related record (line item)
2 - As parent/child work orders, with each product getting its own work order and the event associated with the parent work order
3 - As multiple work orders - one product per work order and a separate event for each work order
We're looking to improve the multi-product experience in our mobile apps and we'd love to hear your feedback on this. We'd especially like to know how your multi-product configuration reflects your business workflow: Are you able to configure the ServiceMax app the way you need it, or is there another way you'd like to see the app organized to support multiple products?
It depends on the warranty terms for the different products.
If the warranty is the same, then we use option 2.
If the warranty is different for the different products, then we are forced to use option 3. (because we have real time integration w our ERP).
Would love to make our process better!
Number 1 for us, each product to be worked on is added as a line item, as a Product Serviced record type, and then any T&M lines are added as Usage/Consumption lines, and are related to both the parent WO and the Product Serviced line representing the installed product. We also have to add some lines that are not related to a installed product (Product Serviced record), just to the parent WO, for items such as travel, breaks and training.
For the users this can be confusing, knowing at what level you are entering data, against the WO or the installed product, especially when they are only entering data sporadically during a visit; we differentiate between the 2 using page layouts etc, but if we could control the screen colours it would help. Also, the field engineers are expected to add all of times for each action on site, and by the end of the visit, all of the line should be in the correct chronological order, with no gaps or overlaps (some warning mechanism for this would be great), and with the current restriction on number of columns on page it makes it difficult to check all of time data on one page.
There are some other well document issues with using option 1, which we have mentioned a few times , as there is no serial number at the WO level, we can't use automatching rules for despatch etc., reporting is a lot more difficult, and our single biggest issue, up to now, we could not do any auto entitlement checks on a WO, though this limitation has apparently been addressed in the later version of Sm, and is something we are hoping to utilise soon, though it will be a big change in our current processes.
We are currently using Parent/Child work orders(#2).
We are a recent implementation and are having significant difficulty with our gathering of work details and completing the work orders.
And so we are beginning a redesign or our processes related to gathering work details the invoicing customer and paying 3rd party service providers.
In our redesign we are likely to move to #1 where there is a single work order with multiple service product.
We are in the design phase of these changes.
One of my concerns with #1 is that the implementation utilizes the same object for product service and work details.
These are very different in grain and purpose. I suspect this will cause some trouble with related lists, page views, report, etc. Doug mentions some of these in his post just before mine.
Maybe a little late now but I think it would have been better to put the product service in an object separate from work details(labor, travel, etc).
With our current solution it takes several minutes of work to capture the work details.
This problem primary exists with our use of 3rd party service agents where we not only gather the typical detail but also additional details for paying the agent and billing the customer.
We do not know all of the causes of slowness and need for different saves as various points of the process that are causing such difficulty.
We have a lot of validation rules, a lot off apex code that is updating data from a child work order to a parent work order, a lot of formula fields,etc.
We are in a project to rectify these issues. To rectify we are changing some business processes to simpler models, we are changing to Option 1 above of using 'product serviced' records, so that we can remove some to the code that ties related work orders together.
We are using 3 and are in the process of moving to 1 (Still in POC stage). We have a huge volume of WOs with the current process which is why we are looking to change. I would like to hear more about how this impacts reporting. If anyone has examples please share.
This is a very relevant thread for me as well. We have implemented a pilot solution with one work order and are now considering switching to multiple work orders. The problem with one work order is that as Jeff mentioned the work details list becomes pretty much unreadable since there are so many line items and users can't see which line is related to what. Also, you can track the service history better when you have one work order to match with one Installed Product. In a nut shell:
One WO with Product serviced as line items
+/- T&M are tracked on one work order only, simpler to input
+ Potentially less data input
+ Less scrolling between WOs
+ Less WOs
- Must dispatch whole work order
- SLA tracking
Multiple WOs (parent+ child work orders)
+/- T&M can be tracked per child WO, more detailed data but more work for Technician
+ One IP = one WO -> easier reporting
+ One IP = one WO -> child work orders can be seen as related records on IP, easier to view service history
+ Ability to dispatch in a more granular way
+ SLA tracking per IP and WO
Please let me know your thoughts
We went from Option 2 to Option 1, our field techs will often work on +20 IP on a visit, and so the helpdesk guys would have to create the same number of WO's, and even though they had a clone function, the process was slow and often WO's were not create if for instance they were interrupted during this process. Also, often a tech would tun up on site to find one of the IP's he was due to work on was not available, so this would mean a phone call back to the HD, who would create a new WO, and then all would have to resynced. There were also plenty of issues we had overcome, like creating a single service report from all of the WO's, consolidating the data, to create a single invoice etc.
Not that moving to a single WO has not had problems, like the loss of auto entitlement per IP (a biggy for us), but i have to say using a single table (the WO lines) has not been to much of an issue, with in the app you can split the data entry for say travel, or time spent on an IP by using the SFM criteria's etc, and in the browser we just use sorts to list the data in a logical way.
This is just a brief outline of what we went through, to get something that works for us, but there is still a lot of room for improvement!
I want to thank everyone here for their replies and interest. I'm thinking of holding a Webinar to explore the topic further and present some ideas we have for enhancing the product. Please let me know if you'd be interested in this. The Webinar would likely be held in Early October.
I would be interested. We were directed by SMAX PS to do option 2 (likely because of our ERP integration requirements) but we cannot get 1 service report with all the work details from the parent and children WO. This is a huge pain point for us and was promised in our initial discussions with SMAX PS but never delivered. We need a way to capture one customer signature for all the products serviced in the visit.
I would also be interested in this topic.
We currently use #1, a single WO with numerous Installed Products