2012-07-15

Practical process pattern: MIMO

Pattern Multiple Instances Multiple Objects (MIMO) is observed in some business process diagrams provided by the business as documentation for their business processes. I call such business processes “implied”. Typical case is the institutional (corporate) procurement process which is described as the following:

  1. Submit Purchase Requisition (PR)
  2. Choose Supplier 
  3. Issue Purchase Order (PO) 
  4. Receive Goods / Services
  5. Pay Invoice

It looks very straightforward. But a PR may contain many positions which can be sourced by different methods: 

  1. From the stock 
  2. From a known (preferred) supplier 
  3. From an unknown (via a bid) supplier 

And each of those methods requires its own process. So, multiple objects in the instance of “Submit PR” process may initiate multiple instances of sourcing processes (see the diagram below).  This effect of is implied in the user’s documentation. 


Events, generated by the “Submit PR” process, can be treated as describe in http://improving-bpm-systems.blogspot.com/2011/01/explicit-event-processing-agents-in.html 

Thanks,
AS
Posted by Alex at 12:50
Labels:

3 comments:

Anatoly Belychook said...

Alexander

The diagram confuses me.
1. If there are several items in the PR then why "Choose source" isn't inside the mult-instance loop?
2. The default flow coming from the inclusive OR gateway means that this option will be used only when two other sourcing options are not taken in a given process instance. Is it what you really had in mind?

I'd model it with a multi-instance loop at the top level applied to a subprocess with XOR gateway followed by three sourcing options.

16/07/2012, 16:00
Alex said...

Anatoly,

1. Sure, the BPMN allows to express the same diagram differently. Which is the best way? All depends. The choice for this diagram is to simplify the understanding by the business -- any combination of three options executed in parallel after the initial sorting.

2. The corporate procurement is planned in advance, so everything should be in stock (a local joke). Normally, an error event should be used as default, but see the item 1).

After revealing this complexity with the parallel execution, the business proposed to have only one position per PR. Even they agreed to limit the quantity to fit to one option per one PR. So, no loops no complex gateways.

Next step will be to look at the latest SAP and adapt the process to be implementable in the SRM and MM modules.

Thanks,
AS

16/07/2012, 19:27
Anonymous said...

bookmarked!!, I like your blog!Thanks so much!
Look into my homepage My Site

29/07/2012, 00:18

Post a Comment

Subscribe to: Post Comments (Atom)