Elbonian Bureau of Investigations

[jemmerling]

Elbonian Bureau of Investigations

The Elbonian Bureau of Investigations has several district offices "serving" all parts of the homeland. Each office is associated with a specific set of coterminous postal codes i.e. given a postal code one can determine which office has local authority.

An office is organized by "desks" to which cases are assigned. For the most part, each desk corresponds to a staff member e.g. by assigning a case to desk JB001 you effectively assign the case to staff member John Bravo. However, some "desks" correspond to a team e.g. the CNTRFT desk corresponds to the Counterfeiting team furthermore each district office has a CNTRFT desk made up of different staff members.

What I want to know is, can jBPM5 (or BPM in general) be applied to this problem? So here are some requirements:

Part 1.)

The users of the system are registered in an IAM system which grants them privileges at different levels, however the correspondence between users and desks is not rigorously maintained. When a user signs in, they are asked to enter the desk they represent. Apparently they can enter anything and it won't be verified. They can enter a fictitious desk id should they choose to.

When the user signs in, they see all cases assigned to their office plus all cases assigned to their desk i.e. the one they just entered. Some privileged users have the ability to assign cases to desks. Some of these cases are not assigned at the time, others are reassigned.

A privileged user can also request a case be transferred to another office (perhaps because the subject of the investigation has moved to a different postal code). When this transfer is requested, then the other office can either accept or reject the transfer. If the office accepts the transfer, it then "belongs" to the "new" office and if a desk had been assigned to it (at the "old" office) then the case is no longer assigned to that desk.

Regarding desks -- it would appear the system knows nothing about most desks (except possibly well-known ones such as CNTRFT) except to the extent that users enter the codes when signing in and cases are assigned to them. So it might be possible to create fictitious desks.

Part 2.)

New cases are created as a consequence of action items. An action item is like, somebody calls the bureau to report suspicious activity. When an action item is opened, one of two things happens a.) it is associated to an existing case or b.) no such case is found and an new case is created. So the life cycle of a case begins when its creation is triggered by opening an action item. Once created, the case can have additional action items associated with it. Action items stay open until resolved. When the last open action item associated to a case is closed, the associated case is also closed. So the life cycle of a case is driven by the life cycle of its action items.

It should be somewhat clear that resolution of action items is the responsibility of the desk to which their associated case is assigned. If the case is reassigned or transferred, then all its action items become the responsibility of the next desk to which the case is assigned.

Note also that cases are not created or closed directly, only as a consequence of action items being created or closed. However cases are assigned and transferred, not action items.

Can these processes be modeled in BPM?

[swiderski.maciej]

in my opinion, this looks like a nice fit for both processes and rules. Where processes are covering the overall flow of the work and rules are responsible for finding the right assignments. Like when given person logins into the system and specifies desk number such info is then inserted into rule engine and by that becomes available for assignments of tasks. Rule engine might be smart enough to cover the load and tasks list for given groups and desks to not overload them based on various criteria.

So yes, BPM is for such cases.

HTH

[jemmerling]

Hi Maciej, thanks for your response!

Some follow-up questions. First, a working assumption -- the business model I described in my OP can be divided into 2 processes, an Action Item process and a Case process.

So I can see how this could be automated using BPM but the type of processes I imagine are mostly event-driven, in fact, jBPM didn't even introduce event-based gateways until v5.4.

To try to identify human tasks in this process, the closest I can come is "Close Action Item". However, the assignee for this task is not determined by action item, rather it is the desk to which the associated case is assigned. Whereas the case process is simply driven by external events -- a case is assigned to desk A (which means that desk A is responsible for resolving ALL Action Items associated with it) until somebody reassigns it to desk B or transfers it to office X -- or until the last remaining open action item is resolved at which point the case is closed and the process's life cycle ends. There are a couple of rules that address assignment of cases -- for example, if somebody (i.e. a desk) to whom the case is not assigned updates the status of one of its action items, presumably the case gets automatically reassigned to that desk (which means all associated action items now become the responsibility of the new desk). Also some action item categories cause automatic case assignment on creation, for example counterfeiting action items cause a case to be automatically assigned to the CNTRFT desk. But for the most part assignment and transfer are triggered as a consequence of human decision-making and are "manually" performed via a UI in which the (privileged) user simply ticks the box(es) next to one or more cases then clicks "Reassign" (that will pop up a dialog into which they type in the code for the "new" desk).

So to me it seems awkward to describe this process with what I would think of as a "classic" BPM modelling.

Am I missing something here?

Thanks!

[swiderski.maciej]

not sure what is wrong with describing it in BPM way. For me it's classical case that shall be solved with business processes and rules. All the assignment logic should be handled by rules or be explicit reassign on human task level. The "user simply ticks the boxes" is actually working with user task list that are directly connected to process instances. Let's take for example first process that creates action item, that will in turn create some user tasks so actual users can claim them to work on them or reassign to other desk or office. All these operations should be backed by processes. So you have full control over their life cycle and can track their progress.

If you see that the process cannot be described as regular flow chart you can use ad hoc processes where you can define number "independent" process fragments that can be signaled.

I would recommend to make use of rule to decide who should get what etc, all rules describing logic to assign action items, etc can be rely efficient when defined as business rules, even more when used with processes.

HTH