*Really* suspend the process

[Steve Giller]

I'm sure I've seen this at least discussed elsewhere, but I can't find the thread if that's true:

One of the first things we do is Suspend/Wait for Priority. Son after that, we Suspend/Wait for Owner.
Unless I'm missing something (which is hopefully the case) there's actually nothing but "doing it properly" to stop the Owner being assigned before the Priority has, which is causing problems with our calls flowing across our boards - not to mention having calls being closed having never been assigned a priority.

Is there a way to totally block the process with a Suspend node? Or do I have to resort to beating the culprits with a stick.
Either of those would be fine, I just want to make sure I'm using the right method

[Steve Giller]

On an apparently similar note: I also have calls being closed without an owner - I have a feeling there's a setting for that, but I've not got properly familiar with those in Service Manager yet.

[edit]
Ignore this bit - I'm pretty sure  app.request.allowResolveCloseWithoutAnalyst was the one ...
[/edit]

[Victor]

@DeadMeatGF loop the BP until (all) your criteria is met? (just a thought)
If you want to resort to the "stick beating" option, we could also suggest using sarcasm... because apparently using sticks is illegal/frowned upon... 

[Kelvin]

14 minutes ago, DeadMeatGF said:

One of the first things we do is Suspend/Wait for Priority. Son after that, we Suspend/Wait for Owner.
Unless I'm missing something (which is hopefully the case) there's actually nothing but "doing it properly" to stop the Owner being assigned before the Priority has, which is causing problems with our calls flowing across our boards - not to mention having calls being closed having never been assigned a priority.

Not 100% sure but could you use a parallel process so that it doesn't matter which one is completed first as long as they are both done.

Edited February 6, 2017 by Kelvin
added image

[Victor]

@Kelvin not a bad idea  ... forgot about parallel processing! (if this works you will have a team of analysts from @DeadMeatGF desk who will be very grateful to you)

[Steve Giller]

The problem I have is our "Unassigned" board - this provides an at-a-glance check for the Service Desk of which calls are requiring their attention, but if the Process is not followed in order they "stick" because you're effectively running the second stage before the first stage, so the "Add to Board" happens after the "Remove from Board" and this quite quickly ends up with a board so cluttered as to no longer be of use.

I'll have a look at how Parallel Processing affects things, it would totally restructure our HUD though, which wouldn't be ideal as the Customers have just got used to that!

[Victor]

@DeadMeatGF so, just to make sure I understand fully, how exactly your process works? Can you detail the above steps to make sure I understand where you struggle?

 

[Tina.Lapere]

@Victor & @DeadMeatGF - is there any update on how you've managed to get round the issue of calls being able to be closed with out a priority?  We are having the same issue and it's breaking the rest of the BPM.

Thanks

Tina

[Steve Giller]

Sorry @Victor - I missed that reply.

Without dropping all 4 fairly complex stages onto the thread, the process is basically as follows:

1. Start Timers
2. Pin to "Unassigned" board
3. Assign to ServiceDesk
4. (Suspend) Assign Priority
5. Assign to Front Line
6. (Suspend) Assign to Owner
7. Remove from "Unassigned" board
8. Pin to the Board for the relevant Site in a list based on Priority
9. Resolve Request
10. Close Request
11. Remove from Boards

The issue arises because the call can be assigned to an owner without assigning a priority, the Owner then goes on to resolve and close the call without ever having a priority (which we don't want) and for some reason the call is stuck on the "Unassigned" board, even though assigning an owner should really remove it from there.

[Victor]

@DeadMeatGF hmm... I don't see why parallel processing of "suspend priority" and "suspend owner" would mess up with the HUD (probably I missing some details here). What is the name of ProCap, I can download it and upload it in my test instance then have a look in more detail if/how you can overcome this...

EDIT: I did not mean ProCap, I was referring to business process....

[Steve Giller]

I've not switched it to parallel processing yet, but it's "DC IT Incident v2"

[Victor]

Right so, two issues discussed here:

1. Action sequence

On 06/02/2017 at 2:34 PM, DeadMeatGF said:

stop the Owner being assigned before the Priority has, which is causing problems with our calls flowing across our boards

This should be achieved by doing it with parallel processing. Sorry @DeadMeatGF didn't have a chance to look at the process and see how parallel processing would affect the HUD, I'll try and do this Monday (it was a rather busy last week)

2. Calls closed without having a priority assigned

On 06/02/2017 at 2:34 PM, DeadMeatGF said:

having calls being closed having never been assigned a priority.

Now, on this, I can only think of having a human task which "enforces" the owner and priority. What I mean is currently a request can't be resolved if the request has (one or more) tasks and the BP progress depends of the task(s) outcome. So, my suggestion is that somewhere in the process create a decision loop which creates a task, let's say, "Request Triage". A simple task with a Complete button only. When the task is complete the decision looks at the values for owner and/or priority. If they exist, continue with the process. If they don't, loop back before the decision where the task is created. This way if an analyst tries to resolve the request it won't be able to, as there are "active" tasks. If the analyst tries to complete the task but there is no owner/priority on the request, the BP will loop back and recreate the task...it will do this as long as the criteria is not met. The downside is that it will be one more activity for the analysts to complete. However if is made very simple, it won't create to much additional workload (i hope ?!). It will also mean the analysts needs to be informed of how this works otherwise they will keep wondering why the task is recreated over an over.
 

@Tina.Lapere @DeadMeatGF would this be a suitable solution to overcome the issue with requests being resolved/closed without the required information/data?

[Victor]

FYI the issue with requests being resolved without having a priority is also discussed here:

 

[Steve Giller]

Picky, but I'd definitely call that a workaround, not a solution, but I can see how it would work. In my case, the hassle I'd get from owners about the extra task compared to the hassle I get from the Service Desk about occasional missing priorities means it's probably best left for now, but the ability to either have a "Cannot close without priority", or better the ability to control the available actions would be ideal.

[Tina.Lapere]

@Victor I totally agree with @DeadMeatGF as this is not a suitable solution for us for the same reasons.  We too really want to be able to control the call process better and restrict the ability to resolve a call without certain details - priority.  It's disappointing that you can control this as it breaks the rest of the BPM process and results in a bad customer experience.

I shall wait to hear further updates from James on the other post.

[Steve Giller]

I was tinkering with this again today, as we had some calls sneak through without priorities, and I thought it might help if I threw up an image.

As you can see in the attached workflow we prioritise and then assign to the Front Line team (the bit that's cut off just assigns a default category if there isn't one) but because suspending the call doesn't actually suspend it you can easily assign it to Second or Third Line before assigning a priority - this is the case no matter what loops or parallel procession tricks I've tried.
If you do that, apart from getting a rude email from me, this has the effect that when you eventually do assign a priority the call jumps to Front Line, no matter what stage of the process you're at, but also means you can get all the way to Resolving the call without ever assigning a priority.

The more I look at it the more I think having control of the Action Bar would be the best way forward - the first node would be to set the assign action to disabled, once a priority was assigned the Process would enable it. Some of this is in place behind the scenes - e.g. certain criteria have to be met for the Resolve action to appear - but I believe that giving some control to the BPM engine would solve this issue.