Activities vs linked tickets - New Starter Requests

[George Warren]

I don't think we will be the only ones having this issue/concern so I wanted to see how other people were handling tickets that involve multiple teams and the process isn't linear with some steps being dependent on each other.

For example we get a new starter request in, they start in 2 weeks, they want a laptop, mobile, dock, monitor, licensed software, and accounts for various applications. 
This will need our service desk to create the account, our procurement team to check stock of hardware and software and purchase some or all items as needed, and our app support team to create accounts. 
Currently we have the original logged ticket stay with the service desk, and we have auto generated tickets logged to the procurement team and app support. When procurement receive items or find stock then linked tickets are logged to our desktop team to setup/deploy the hardware/software. Its not as simple as wait until all items have arrived and then pass the procurement team ticket to desktop, as if 1 item is delayed then this can cause the desktop team to have no time to setup/deploy any of the items.

I know we could keep a single ticket and the various actions for the different teams be logged as activities so its easy to see in a single place the status of all the concurrent processes all in one ticket, however I have concerns about the visibility of these, as the ticket can only be assigned to one team and staff would then have to be checking both their request list for work (where they are the ticket owner) and also the activity list (where they are not the ticket owner).

Does anyone have experience using a single ticket setup and how have you found it using the activity list and the request list? Or am I overlooking something?


 

[Sam P]

Most of our Joiners/Movers/Leavers processes use the single ticket principle - my analogy being like a Swan on the surface (the request) and the feet under the water doing the work (the Human Tasks/Activities).  My main reason for doing this is so that the customer has all the information in one place and is not checking multiple tickets.  The tasks are largely generated under one Stage with the use of parallel processing to make sure that work can happen concurrently where needed.  The Request itself gets assigned to an Admin 'team' (not a separate team as such, but a separate queue to store the tickets separately from BAU incidents) and the Tasks assigned to the team responsible for completing the work.

Pro's:

• customer only needs to look in one place for their updates
• you can monitor the complete end-to-end SLA time for the entire request

Cons:

• The timeline can get very long if you have lots of Human Tasks
• its tricky (but not impossible or maybe I haven't tried hard enough) to monitor the SLA performance of Human Tasks 
• Some teams may feel they are not credited for closing Human Tasks in the same way as closing a whole request
• the size and complexity of the workflow can be significant and workflows over a certain number of nodes can have performance issues

It looks like my cons outweigh the pro's however this works for us.  Our New Starter Request as an example, which does not currently include hardware, has input from up to 7 teams depending on customer selection.

[Steve Giller]

Just adding to the pros and cons,

In a parallel process, if any Human Task fails (e.g. should you assign a Task to "Owner" when the Request does not have an owner) every Task within the Parallel Process will be cancelled immediately.
Tasks halt the Process completely (or their branch of a Parallel Process) where linked Requests have their own independent lifecycle and you can choose whether to monitor them once raised. e.g. a New Starter request may raise an Allocate Hardware linked request that it needs to track and potentially not pass a certain stage until it's completed, but it may generate a "Provide Uniform" request that is untracked, the New Starter wears civvies until the uniform arrives.

It's really a case of matching your requirements to the functionality.

[Berto2002]

We have a mix along these lines

• We have a core new starter request and try to get Service Desk to be able to do as much of it as possible; setting-up accounts, calendars, dist lists, groups, teams, software, etc
• If Service Desk cannot do a task because it's another team's job, we spawn a request. Example: any application access requests are spawned separately since they all have their own 'entry' criteria including mandated training or forms for data protection, etc
• If Service Desk get blocked in their usual tasks then we spawn another request for each of those. Example, if we run out of licences for particular software we normally have in stock
• If anything requires additional approvals it is spawned-out also. Example, we ask for senior management approval for al mobile phones so they are separate requests
• We always make sure Service Desk have the primary device available; laptops so we never have a user waiting for that. This way, we can always provision an account and a core device within a day if we need to
• On the other hand, we ask for 10 days notice so if the line managers are organised enough, all these spawned items will be done in time
• This approach does mean the line manager gets multiple requests but that is a benefit when things arrive at different times or even get declined because each can be reliably tracked and referenced separarately
• We do the same for leavers; service desk can always disable accounts but the work to collect returned kit or delete certain apps or reclaim software is other requests.

Rob