Stages vs Tasks vs. States

[adamrauh]

Hi all,

Wondering some best practices here.   I'm working on implementing our service catalog request items, and I'm finding that a lot of the default workflows involve creating tasks to pass along stages, etc.   For us right now, during this first iteration, I think this is too much overhead to get down to the task level (REQ and RITM are enough)

We have previously implemented Incident, so have some set states in there that I would like to replicate in service request (assigned, in progress, awaiting vendor, etc.).  

Since I think Task level is too much overhead, wondering best practices and/or ways to either:

Option 1

1) "Just" create requests (no workflows, except maybe a few custom approval ones), and (for right now), just use states - so the requests gets opened and that's it, and we use states as statuses from there on out and

2) Ref the same state table from incidents for these states

3) Hide the stages for requests or, w/ whatever workflow we create above to do #1 & #2 (if we need to create one), tie them directly to the Status, so each time the status changes so will the state.   I understand that may make it not completely linear (it could go from 'In Progress' to 'Awaiting Vendor', back to 'In Progress')

Or,

Option 2

1) Create a very (very) generic Stage Set, but one which does not create tasks and,

2) Making the stage set selectable from within the RITM, so just the RITM can drive it and not tasks

I can see the case for either (or both, given various scenarios), so any input is helpful.

Thx,
Adam

[Uncle Rob]

Overhead or no, I think having the workflow generate tasks (sc_tasks) is what I'd do.   It doesn't take long to come up with use cases where workflows contain more than one assignable/trackable task.   The sc_tasks aren't just there for stage presentation, but they're there to quantify work.

My primary reason for doing it this way is that multiple teams within one workflow will understand and appreciate sc_task.   If we started with a world that was only request/req.item, we have to retrain everyone in what the difference between the record types is, and when you should work on one vs. the other.

But I almost always go with Option2.1 anyway - Make your stages as simple as possible.   Besides the Completed Stage, the only thing I find it useful for is abstracting the life cycle of the ticket for the consumer.

[adamrauh]

I understand the concern, however we don't run a huge enough shop to warrant truly task level work, at least right now.   We're also very agile, so at this point would prefer not using task level stuff.   As we mature and automate sure, but then that's just a workflow change and some training that would need to happen.

Is there a way to basically point the state to the status (at least for right now) as a reference/driver?  

Later one as processes become more automated and we want to track failures/stage-gates I can create separate workflows and associate as needed.