Another question about Human Tasks

[Frank Millman]

Hi all

I posted a question here a couple of months ago about the relationship
between human tasks and processes. I got some useful replies which helped me
to proceed with the application I am developing.

I now have another issue that I would appreciate feedback on. I have been
giving a lot of thought to the question 'What exactly is a task?' and
following on from this, 'What distinguishes a Service Task from a Human
Task?'.

Before continuing, I need to clarify something. There is a difference
between a Service Task that is invoked by a Process, and a Process that is
callable as a Service Task by a third party. I am only talking about the
second scenario, where the Service Task is actually the first task in a
larger process, and is used to instantiate the process.

My tentative answer to the first question is that, in most cases, a task is
a piece of functionality that requires certain input data, then does
something with the data, often including applying some business logic and
updating a database, and then usually returning a result.

If this sounds reasonable, then my tentative answer to the second question
is that a Service Task has the input entered offline by a third party and
submitted via a message, and a Human Task has the input entered online by an
operator, who may be receiving the information telephonically.

Otherwise the two tasks are identical. The only difference is the source of
the input data. I would then prefer to have only one 'task definition',
which can be invoked in more than one way, rather than two task definitions
which would start out identical in functionality but would inevitably start
to move apart over time.

Taking the example of a Sales Order Process, I would see the first task as
Enter Sales Order, with two possible start events, a Message StartEvent and
a None StartEvent, both invoking the same task, with a parameter to indicate
how the task was invoked. Unfortunately BPMN 2.0 does not seem to offer this
option.

So I guess my question is, is my opening premise reasonable, and if so, what
is the best way to express this in BPMN 2.0?

Any insights will be appreciated.

Frank Millman

[Neal McWhorter]

Wow... this is a complex question. Let me do my best to try to answer it...

First let me try to clarify some terminology. From BPMN's standpoint a Task is simply an Activity that cannot be decomposed into any lower-level flow. Since this is a BPMN group I'll stick to using that meaning of Task here.

On the question "what distinguishes a service task from a human task" the answer has a couple of different aspects. First a human task is really a special kind of task in BPMN which is all about automated routing of work to a pool of individuals based upon some characteristics passed to an implementation that is up to the various vendors to fill-in. In practice that means that a human task is any task that is enabled by a vendor's BPMS. The manual task is for the case where a person does some work that isn't supported by an automated BPMN system. By comparison a Service Task is a task where which is performed by invoking an automated interface that is external to the BPMS. Notice that none of these definitions are based upon whether or not data is passed. This is a good thing because a Service Task could be invoke w/o needing any parameters.

You wrote: "If this sounds reasonable, then my tentative answer to the second question

is that a Service Task has the input entered offline by a third party and
submitted via a message, and a Human Task has the input entered online by an
operator, who may be receiving the information telephonically."

Here it's important to keep in mind that a Service Task is a way of invoking an external interface. The service task itself doesn't do the work it merely gathers the data (if any), invokes the service,  (optionally) waits for a response and (again optionally) transfers the results to the process. 

I think for your situation you probably want to consider a shared Task that can be invoked from a flow that has a Human Task (where what the human task means is something you'll have to define or will be dictated by the vendor implementation you are using) as well as from a flow that is triggered via a message. A Global Task is designed to be reused like this and a Call Activity is how a process invokes a Global Task. So each of the processes would have a Call Activity inserted that invokes the common Global Task.

You also wrote: "Taking the example of a Sales Order Process, I would see the first task as

Enter Sales Order, with two possible start events, a Message StartEvent and
a None StartEvent, both invoking the same task, with a parameter to indicate
how the task was invoked. Unfortunately BPMN 2.0 does not seem to offer this
option."

It sounds like you're looking for BPMN to allow multiple start events. And it does! So you could have a process that can be started by either a None Event or a Message Received Event. Having said that I wouldn't recommend modeling it that way. I'd model these as two separate process that shared a Global Task. I think that that approach will allow the separate process flows to evolve to reflect what is unique to each of them.

I hope this helps... 

	Experience + Leadership
Neal McWhorter | Connect with me on Linkedin Business Architecture Guild Board Member neal.mc...@strategicvaluepartners.com www.strategicvaluepartners.com	Strategic Value Partners, Inc. Chicago, Illinois Tel:   773-570-0020

 

 

Frank Millman

--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

[Frank Millman]

Many thanks for the thoughtful response, Neal.

Apologies for the complex question. This is getting a bit off-topic for this
forum, but I will explain what I am trying to accomplish.

I am writing a business/accounting application, intended for general use but
with a bias towards the SME market. It is written in Python and will be
released as Open Source.

I want to embed a Business Process Management feature, and as there is not a
suitable one written in Python I am writing my own. It is not that
difficult, but I know from past experience that I am not good at keeping
application components separate - they start out stand-alone, but
dependencies creep in and eventually they end up intertwined. I am trying to
avoid that problem this time, but that requires a clear understanding of
what each component is, what its functionality is, and how it interacts with
other components.

I am using a Sales Order as an example, partly because it is a common
requirement, but also because it illustrates two concepts which have been
missing from my previous efforts at writing business software, but which I
want to incorporate at a fundamental level in this version -

1. Sales Order processing is a classic Business Process - enter the order,
verify customer credit, verify goods available, raise invoice, receive
payment, ship goods, etc (possibly in a different sequence). I want to use
this as a proof of concept for my BPM module.

2. Many SME's are still at the stage of using an operator to enter data into
a computer system, but there is a trend towards offering an electronic B2B
facility, and I want to ensure that my software offers this, and makes it
easy to use both approaches concurrently.

You may recall that I asked a question a couple of months ago about whether
'verify customer credit' should be part of the process definition or the
task definition. There is not one right answer to this, but eventually I
decided to keep things simple and treat it as part of the task definition.
Therefore from a process viewpoint, there is a single task, 'Enter Sales
Order', which either succeeds (and the process continues) or fails (and the
process terminates).

Now I am trying to figure out the best way to achieve my second objective -
allow the order to be entered online or offline. You suggested using
separate processes for the two scenarios. My difficulty with that is that
the rest of the process is identical - in fact there should only be one
'Sales Order Process', and whether the sales order was entered online by an
operator or offline and submitted electronically should not make a
difference.

You gave me a clue when you explained that a Service Task is not the task
itself, but a means of invoking the service that executes the task. As you
pointed out, terminology is important. I realise that what I think of as a
task is not the same as what BPMN2.0 defines as a task, and therefore I
should think of a different term - maybe something like Application
Component. The functionality that it performs should be identical however it
is invoked. Therefore I am now thinking along the lines of treating a Human
Task in a similar fashion to a Service Task. It is not the task itself, but
a form which allows the user to enter data, which is then passed to the
Application Component to execute the functionality required. This is beyond
the scope of BPMN2.0, and therefore off-topic, but I am pretty sure I can
come up with a structure like this that will give me what I am looking for.

If I go with this, I would have a single process with two start events - a
Message StartEvent which leads to a Service Task, and a None StartEvent
which leads to a Human Task. I would then join the two paths and the rest of
the process would be common to both. Internally the Service Task and the
Human Task would reference the same Application Component.

By the way, I have read the spec for WS-Human Task, and have got a lot of
good ideas from it. I do not intend to follow it too closely, as it is
overkill for my purposes, but I found it a useful document.

I don't expect you to comment on all this in much detail, as this is all
very subjective. But any general comments (especially of the "no, don't do
that" variety) will be much appreciated.

Thanks again

Frank