Question on workflow administration

[Michael Pokraka]

Just another item to add to Tomasz's already excellent explanation:
Directing workitems to specific users will also skew or even invalidate
any statistical reporting.
Consider the post office analogy: Tellers get their people assigned
randomly, and the overall average time taken per transaction should be
fairly accurate for each person.
Now, if agent a has a percentage and agent b has a percentage, and those
percentages do not match the workload/capacity, agent a who may be
quicker will take his time becaus he doesn't have a lot of work to do.
This shows him up to be the slower agent...
Also, I generally try to keep forwarding to a minimum as a matter of
principle, for the same reasons. (Actually, I'm not too sure how these
statistical reports work in cases of forwarding).
 
Stats can be an invaluable tool to not only identify bottlenecks, but
also the odd user who doesn't know a simple shortcut and thus takes
double the time to process something..
 
Cheers
Mike
 
On Mon, Mar 03, 2003 at 12:13:08PM +0100, Zmudzin,Tomasz,VEVEY,GL-IS/IT wrote:
> Tony,
>
> there's no simple way to cover this kind of requirement (well, at least not
> until Basis 6.20, possibly 6.10, where you could use some mechanisms to
> deliver that). There's a good reason for that though. Please refer to my
> recent conversation with Robert Verlaat that I'm quoting below your request.
>
> Kind regards,
> Tomasz
>
> P.S. Robert -- it would be interesting to see the outcome of your
> discussions. Would it be possible for you to share that with us?
>
>
> -----Original Message-----
>> From: BELLINI, TONINO [mailto:tonino.bellini at sap.com]
> Sent: Monday,3. March 2003 11:35
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Question on workflow administration
>
>
> Hello
>
> I have the following requirement to cover using SAP workflow. Can anybody
> give me any suggestion?
>
> 1. At the end of the work shift all the WF items of an agent must be
> directed in the manager's inbox
> 2. The manager should be able to redirect them to other agents on a
> percentage basis (for example  20% to agent a, 30% to agent b, 50% to agent
> c).
>
> Thanks and regards
>
> Tony
>
>
> ----------------------------------------------------
> ----------------------------------------------------
> ----------------------------------------------------
>
> Robert,
>
> apart from some acrobatic tweaks I could not think of any standard
> functionality. And I believe that's for a reason, because your argument is
> not convincing me:
>
> 1. Workload distribution:
>
> The routing you describe is LESS effective than the standard routing to a
> number of recipients. Instead of queueing the requests in one single queue
> served by all the agents, you "distribute" them to individual queues. That
> means if someone is slower than the others /or simply on vacation/, his
> workload will NOT be distributed to those having spare capacity to process
> them.
>
> By the way: did you ever wonder why more and more service organizations
> (postal offices etc.) introduce these ticketing machines from which you need
> to get a ticket, then wait for your number to appear on a board indicating
> which counter will serve you? That's exactly the same mechanism -- joining
> individual queues into a single one, which shared by all the processors. In
> this way you'll never be in the slowest queue (or in the fastest one), so
> the undesired variability in processing time is reduced. And the pace of
> work is actually adjusted to each processor's capability. Now if any
> counters is shut or opened, using the single queue will smoothly adjust the
> workload of all the available processors.
>
> 2. Create variety for the users
>
> .. who are processing the tasks is nice, but it is usually highly undesired
> by those waiting for the results of the work. The process is simply less
> transparent, and you get a higher variability of processing times. If your
> agents need variability, you can get much better results by extending the
> display of work items to include some nifty GUI elements, animated GIFs or
> whatever you wish -- at no cost to the process.
>
> Workflow simply makes the process side of organizations more transparent.
> What's nice to one user is not necessarily best to all the others.
>
> 3. A lot of temporary employees involved.
>
> Utilizing workflow can surely contribute to ease of use. But the scheme we
> discuss would actually make the process less predictable = harder to
> explain. And of course: lot of temporary employees = lot of agent
> maintenance, lots of work items directed to users who no longer belong to
> the organization etc. Having a single queue will really work better for you.
>
> Kind regards,
> Tomasz
>
>
> -----Original Message-----
>> From: Verlaat, Robert [mailto:Robert.Verlaat at PWN.NL]
> Sent: Tuesday,18. February 2003 10:17
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Dynamic Work Item Delivery
>
>
> Hi Tomasz,
>
> Thanks for your replay. I had the same questions before.
>
> There are several reasons for this requirement:
>
> * Workload distribution
> * Create variety for the users
> * There are a lot of temporary employees involved
>
> I think the last reason is quit a strong one, because when you (almost)
> completely atomize this process, you can make it quit easy for the users
> to perform their Tasks.
> Using Workflow the users don't have to think about the process and what
> to do next. So the new employees don't need a 2 weeks course but they
> can sustain with a small introduction course....
> I know Workflow is not meant to be used as training material, but in
> this case I believe it can be very useful.
>
> I know everything can be coded, but I would like to know whether there
> are standard functionalities for this?
>
> Thanks,
>
> Robert Verlaat
>
>
> Robert,
>
> I may be too investigative again, but -- why do you need this? What
> organizational benefit would this bring?
>
> If the goal is to distribute workload, send all items to the same users
> --
> whenever one of them will complete an item, it will be gone from all the
> other inboxes. This also achieves a reduction in average lead times. The
> only requirement I could see as a background for your question would be
> "not
> annoying" the users. But then I guess the 'unpredictable' behavior would
> be
> even more annoying. And, by the way, why do you want to split based on
> daily
> buckets?
>
> If you really insist -- anything can be done with (some) programming,
> but
> why do it?
>
> Kind regards,
> Tomasz
>
> -----Original Message-----
>> From: Verlaat, Robert [mailto:Robert.Verlaat at PWN.NL]
> Sent: Tuesday,18. February 2003 08:19
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Dynamic Work Item Delivery
>
>
> Dear Workflowers,
>
>
>
> Is it possible to deliver WI's dynamically f.e. User X has 2 (of the
> same type) WI's in his Inbox so the next WI, of the same type, should be
> delivered to another user. Or when user X has already processed 2
> certain types of WI's, he should not receive a third on the same day.
>
>
>
> I'am afraid these kinds of functionality should be programmed completely
> (read tables for WI's in inbox/processed WI's etc..)? I haven't found
> any tips or tricks for this in the Book..
>
>
>
> Does anyone know if this is possible without programming?
>
>
>
> Thanks,
>
>
>
> Robert Verlaat
>
> Accenture Technology Solutions
>
> 0031 (0) 6 113 676 96