This may be more of a style question than a technical question.
We have a business process that could take a month to complete. We are replacing parts on equipment, and we request that the customer return the broken part for repair or refurbishment.
The process to ship the part generally occurs in the same day, but the trigger for the second half of the process doesn't happen until the customer returns the item. This is normally 1 to 4 weeks.
If I implement it as a single business process, it would be running for weeks on end. Is this a problem?
Any advice on the best practice would be helpful.
Like
Dear Bob,
There are several out-of-the-box processes that also have a big run time. Each time you'll trigger your process it will create a record in the process log and the process will be waiting for the next step. Theoretically it shouldn't affect performance of the system and it is ok. But we can think on how can we manage the process in another way.
Your product is servicing of broken parts and your "opportunity" or "case" ("service request") is a broken part. As you wrote it in the topic of the question, it is a very good idea to use "Case" section to manage your business. For example some part is broken and you register the incident. You have the number of the incident, you have the information on the client (you can call or email him and provide with all necessary information and get information from customer and write it down in feed or update some fields and the customer will also no the number of the incident and he can get up-to-date information any time) and also on the part that is under processing (the process of part repairing can be also managed with the help of incidents and you can bind the incident with the part repairing to the general request from customer). You can set up case statuses as "New" -> "Part not received" (if the customer still has the broken part) -> "Part received" (if you the customer gave you the part) -> "Part repairing" -> "Part repaired" (if the part is repaired but yet not received by customer) -> "Part is on the way"(when the part is on the way to the customer) -> "Resolved" (part received by customer).
It will be much more easier for you to track down the status of the incident: where is the part, who is the client, when it needs to be done, who is assigned for repairing. I think that cases will become the ideal choice for you.
Oscar
Oscar,
Thanks for your input. The business process that I'm working through is actually the different phases of a case. The way we do things is that the service technician is assigned the case, and during each step of the process an activity is created for our accounting team, shipping/receiving team, inventory control team, and production team. I am using the business process to create activities within the case and assign them to the appropriate individuals.
The actual case which handles the RMA is a child of the case where the service technician is working out the problem. In general, the parent case will be closed before the child case is, primarily due to the fact that our production team will do root cause analysis on the returned part on a separate schedule than the initial case.
Thanks for your input.
Bob
Bob Walters,
Then you can create a separate process which will be triggered by some changes you or the employees made in the system. Will this work for you?