Practical process patterns: LAAP

Law As A Process (LAAP) pattern: at the #BPMCM14 conference several people mentioned that it is difficult to implement various laws and regulations - logic is not clear, there are omissions, etc.

It seems, that laws should be formalised as process fragments (see below a diagramm from one of the cantonal laws) and business rules (e.g. in accordance with The Decision Model or DMN).

Thanks,
AS

Practical Process Patterns: PAACP

A blogpost to outlines a typical procurement process in a highly-regulated environment -Procurement As A Cluster of Process (PAACP) (about cluster of processes - see http://improving-bpm-systems.blogspot.com/2014/03/enterprise-as-system-of-processes.html )

The main process start from a submitted Purchase Requisition (PR).
In accordance with the procurement policy, any PR are check against the corporate Delegation of Authority Matrix (DAM - http://improving-bpm-systems.blogspot.com/2012/07/practical-process-pattern-dam.html ) if the submitter are allowed to request this purchase.
Any goods/services in the valid purchase requisition can be sourced in three complementary methods. As one PR may contain several purchase items then many combinations of the sourcing methods may be initiated.

Sourcing 1 is just delivery from the corporate stock. PR becomes Purchase Order (PO).

Sourcing 2 is just ordering from an approved supplier. Of course, a contract must be prepared.

Sourcing 3 is (the most complicated case) to choose a supplier via an open bid.

The open bid process can be as the following (several variations are possible to determine "potential suppliers").

A process for annual planning of the procurement (thus replenishing the corporate stock) is trivial and not mapped.

Thanks,
AS

Practical Process Patterns: RAAP

This practical processes pattern RACI As A Process (RAAP) shows the use of the well-known technique RACI (Responsible – Accountable – Consulted – Informed) http://en.wikipedia.org/wiki/Responsibility_assignment_matrix in processes.

• Responsible - to do the work
• Accountable - to control and approve
• Consulted - to be solicited to provide some input (two-way communication)
• Informed - to be kept up-to-date (one-way communication)

Let us consider that any business activity can be decomposed into four logical steps (similar to the PDCA cycle http://en.wikipedia.org/wiki/PDCA ) connected in a simple process:

1. PLAN: preparation for the work to be done;
2. DO: execution of an indivisible unit of work;
3. VALIDATE: checking the correctness and quality of the work carried out;
4. REFLECT (or “re-factor”): analysis of the work experience and results to see whether it is useful to propose/implement any improvements for future similar work.

The illustration below shows that different roles are involved in different extend in different steps:

• actually perform (depicted by double lines)
• involved as a core team member (depicted by solid lines)
• involved as an observer (depicted by dashed lines)

In addition, some exceptions (e.g. an escalation because of the too long execution time) should be addressed to Accountable.

Thanks,
AS

#entarch, #bizarch, #BPM, #SOA, #ECM and patterns are working together, example 1

Recently, I was involved in a few discussions about what should be a target enterprise architecture for a decentralised enterprise. For example,

1. “Bank decentralisation” - bank wants to build the international presence and thinks about decentralisation, 
2. “Rationalisation of acquired businesses” – company, which bought several hundred businesses wold-wide, would like to align them, 
3. “Legacy ECM modernisation” - already distributed company wants to modernise applications (mainly based on ECM) at its local branches. 

The main concern of the target enterprise architecture is the enterprise application architecture. How to build an inexpensive (no duplications) and flexible (easy to innovate) business-execution environment?

As the first case “Bank decentralisation” has more input, it will be used further as the base. Only additional considerations will be mentioned separately for two other cases.

The situation

Now Bank establishes branches at international locations and there is a need to customize products and services, as well as processes (Currency Management, Risk and Compliance, etc.), as per a given location, i.e. Local Office (LO).

At present, there is a BPM practice at the Bank, i.e. at the Global Office (GO). Processes for Front Office, Back Office and Middle Office are identified for four levels. Also known list of technologies, applications and databases which are supporting business functions. No Enterprise Architecture in place. Plan is to set up an EA practice with a complete Enterprise Architecture in place.

Questions

1. Set of processes for the GO may be customised to the needs of a LO. How? Shall the structure of processes be the same? Shall separate BPM practices be established at each location? If “yes” then how to exercise the centralised control?

2. How to manage data for Global Operations and how services will relate to information required from various Local Operations and how processes will support that (say a Centralized Reporting System)?

3. What would be Enterprise Architecture for the Bank (what capabilities, processes at a global level, how capabilities interoperate, what will governance mechanism, what will be centralized functions etc.). How various change activities will be managed?

4. Centralized BPM practice or separate BPM practice for individual locations?

Answers

Sure, it is mandatory to have a solid EA practice to carry out the change like decentralisation. Also it is mandatory to achieve the synergy between BPM and EA.

Platform

When an enterprise is going to operate from various locations (with potentially different capabilities) then a corporate platform for the business execution should be created and deployed at each location to avoid unjustified duplications among various locations.

The enterprise pattern PEAS outlines the design of such a platform ( http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS  ).

BPM (as a trio of discipline, practice/architecture and tools), should be the primary component of the platform to allow easily combining of common services/processes/patterns with location-unique services/processes. In some sense, BPM with executable processes is a tool for assembling business solutions from services.

De facto, this is a step towards SOA which is an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services. SOA re-shapes the enterprise application architecture from the provisioning of monolithic applications to the assembling solutions from a validated set of in-house, commercial, open-source and rented services. (Service is an explicitly-defined and operationally-independent unit of functionality).

The proper use of BPM/SOA affects all levels of enterprise architecture:

• business – identification of processes and services from the business context;
• application – implementation and assembling of processes and services;
• data – transportation of data between services, and
• technology – running and monitoring processes and services not applications which may increase the number of units of deployment by factor 50.

At the business level, the following should be considered:

• Enterprise pattern “Anisotropically Distributed Organisation” (ADO) - http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html - handle variations between GO and LOs;
• Modelling procedure - http://improving-bpm-systems.blogspot.ch/2013/07/bpm-for-business-analysist-modelling.html - to have a common way for finding processes and services ;
• Business Decision Management (or business rules at the business level) as different LOs may have different decisions, and
• Other process patterns ( http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ), 

At the application level the following should be considered:

• The pattern “Cloud-Aware Processes and Services” (CAPS) - http://improving-bpm-systems.blogspot.ch/2011/07/enterprise-patterns-caps.html - to have a common structure for process-centric applications ;
• Cloud-related patterns- http://improving-bpm-systems.blogspot.ch/search/label/cloud - to have common rules for putting services into clouds , and
• Other enterprise patterns - http://improving-bpm-systems.blogspot.ch/search/label/enterprise%20patterns

Two examples can be useful as well:

1. e-government - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-e-government-and-e-governance.html , and
2. healthcare - http://improving-bpm-systems.blogspot.ch/2013/10/entarch-to-help-heathcare.html .

Information collection

To collect all necessary data, processes should be enriched to proactively push business and execution data to required local and central repositories. Very similar to the http://improving-bpm-systems.blogspot.ch/2011/10/ea-view-on-enterprise-risk-management.html .

IMPACT on EA; governance and capabilities

Knowledge of “list of technologies, applications and database” is necessary but not sufficient for executable processes. Usually, more granular artefacts must be known: services, data structures (XSD), documents, KPIs, roles, rules, audit trails. EA will certainly is the right tool to find them and BPM is the right tool to link them together as executable processes. Again, the challenge is not only to add EA practice, but also to achieve the synergy between EA practice and BPM practice.

The GO provides a standard set processes, services and other artefacts; any LO may have (limits are explicitly defined) its own local set of customised processes / services and other artefacts (as a local copy of standard one). All processes, services and other artefacts are are under strict governance (versioning, life-cycle, etc.). Several version of the same artefacts may co-exist. If a LO uses a standard version of process/service then it can be executed centrally or locally or cloudly. See enterprise pattern #Cloud-Ready Estimation and Evaluation Procedure (CREEP) - http://improving-bpm-systems.blogspot.ch/2011/12/enterprise-pattern-cloud-ready.html to formalise the choice of the cloud.

It is important to establish good terminology (including relationships between capabilities and processes - http://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html ) and make explicit the relationships between business and technical capabilities - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

Platform Centre of Experience (COE) organisation

It is necessary to talk about platform COE not just BPM COE. The target topology is a combination of the central/global COE (reflection, global optimisation, standards) and local/regional COEs (client care, flexibility, assembling of solutions).

The central COE distributes new services, new version of old services, new processes and new version of old processes. Local COEs estimate the impact and update their customised processes if necessary.

Case “Rationalisation of acquired businesses”

Pattern “Eclipse” shows how the transition from applications to processes & services - http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html ,

Case “Legacy ECM modernisation”

The important requirement for the modernisation of legacy ECM is that current encoded-in-code business processes become explicit and executable (by BPMs) business processes. This will a) enable the future optimisation without big changes and b) avoid the repetition of the existing approach with new technology. So, such a modernisation is a transition from ECM to ECM+BPM.

Thanks,
AS

Practical process patterns: LifeCycle As A Process (LCAAP)

Practical process pattern LifeCycle As A Process (LCAAP) is a way to handle some Business Objects lifecycle with a BPM suite. It is considered that those BOs are passive, e.g. documents as licenses.

A lifecycle of an BO is a few phases and branches between those phases (see the diagram below).

Each phase is implemented in the same way (see the diagram below).

In addition, the lifecycle of all BOs is controlled by a DISPATCHER process (see the diagram below) which catches some external events, checks them and converts them into events to change the phase of an BO.

Please note, that one instance of DISPATCHER template serves many instances of LIFE-CYCLE template.

This pattern can be used as a basis for Product-As-A-Process (see http://improving-bpm-systems.blogspot.ch/2013/06/practical-process-patterns-cxaap.html).

Thanks,
AS

Practical process patterns: Decision As A Process (DAAP)

Any procedure to take a decision among several people must be discussed, agreed and formally expressed in advance.  This blogpost is aimed to demonstrate the use of BPM and BPMN for expressing decisions as actionable patterns.

Parts of decision process:

• owner - entity which defined the decision process)
• organiser(s) - entities who execute the process
• audience for action (may depend on the subject) - people who express their opinion(s)
• audience for observing - people who are controlling that decision is taken in a fair manner
• rule for casting  - once or multiple (i.e. last)
• ballot power - equal (one person = one vote), more for the chairperson (1,5 vote) or depending on share 
• legal power of comments
• subject: data and documents - questions and potential answers for choice and/or comments
• duration (time-boundedness)
• security  - who can consult what and when, e.g. can one see choices of others
• rule to count that a decision was taken, e.g. > 50%, majority, >75% yes & < 10% no, etc.
• statistics - demographic of choices, who vote against whom, etc.

Some known decision patterns

1.  discussion forum (to informally reach an informal decision)
2.  e-consultation (to send us your comments before a particular date)
3.  e-approval (do you agree with that? )
4.  e-vote (official request to ballot with/without comments)
5.  e-poll (unofficial or limited request to ballot without comments)
6.  e-panel (discussion by an expert group)
7.  e-coediting (reaching agreement by editing the text and ballot on each paragraph)
8.  fully automated decision (audience for action is empty) a.k.a. business rules

Some business practices are combinations of decision patterns:

•  discussion forum + e-consultation + e-vote
•  e-consultation + e-vote
•  multi-level approval (practical process pattern DAM - http://improving-bpm-systems.blogspot.ch/2012/07/practical-process-pattern-dam.html)

Example of e-vote in BPMN  is at http://improving-bpm-systems.blogspot.ch/2013/07/practical-process-patterns-avs.html

Thanks,

AS

Practical process patterns: Core Organisational Process (COP)

Formal consultations within an organisation is a very popular organisational process. And it looks very simple - just send a memo. This simplicity even confuses some technicians: in one organisation the IT Director has claimed that e-mail is enough to automate this process.

But, there are some complications.  Firstly, there are different consultations:

• Downstream – from a manager to subordinates (to prepare a reply to an incoming issue)
• Upstream – from a staff member to his/her manager (to obtain an official permission to do something)
• Peer – from a somebody to his/her peers (to inform your partners)

Secondly, it is a recursive process: the President sends a memo to Directors and each of them re-sends it to Divisional Managers who ask some of their specialists to prepare a reply.

Thirdly, some combinations of different consultations are possible. A staff member sends a memo to his/her manager with copies to colleagues concerned (upstream ) and the manager asks somebody to validate this memo (downstream).

Let us try to express all this complexity is the following diagram. There are four roles: Boss (who receives the issue), Reviewers (who are assigned to prepare a reply), CCs (who are just informed about the issues and final reply) and Workers (who, sometimes, must do something before sending the final reply).

Of course, there are a few tricks:

• Boss selects Reviewers, CCs and Workers dynamically.
• One of Reviewers may be a lead of a temporary group of Reviewers.
• There may be a decision process (should be another blogpost) among Reviewers.
• Coordination between Boss and Reviewers may be more complex than depicted in the diagram (e.g. Boss receives all replies by him/her-self).
• Reply (as a business object) life-cycle is not shown.

Thanks,
AS

Conference "BPM in Practice" Vinlius, Lithuania

A quick feedback from the conference "BPM in practice" in Vilnius, Lithuania. http://www.bpmpractice.lt/en/

I found very interesting the two following slides from the first keynote talk.

A nice linkage between the value and four types of improvements which are achievable because of the architecture works.

The transition from "structure maturity" (can be imposed) to "culture maturity" (can't be imposed)  is mandatory to consider if you target the highest levels of organisational maturity.

And my presentation is below (please note that some slides have animation).

Business Architecture Patterns (BPM in Practice conference) from Alexander Samarin

Thanks,
AS

Practical process patterns: AVS

This is the Advance Voting Solution (AVS) pattern from my book www.samarin.biz/book . The pattern uses the coordination of instances (many instances of pool “VOTERS” for each instance of pool “COOR”).

BPMN events work well for cases which require the coordination of many (an unknown number at the time of the design) participants with a similar behaviour. This case is typical for voting, bids and other dynamic situations. The logic “one pool implies one instance because there is one participant” is not sufficient for such cases. Instead it is necessary to use the logic “one pool implies many instances, one per participant” is required (this is rather implicit in BPMN).

For example, figure above shows a voting process with many voters each of whom behaves in accordance with the coordination logic presented in the pool VOTERS. The whole process is coordinated by the pool COOR and comprises three steps: preparation 1, ballot casting 2 and finalisation 3.

In the first step 1 , the repetition of process fragment PF01 in the pool COOR starts many instances of a process in the pool VOTERS.

In the second step 2 , each voter may cast a ballot (activity Vote from the pool VOTERS); this event is consumed by the intermediate message event E01 in the repeating process fragment PF02 in the pool COOR. If a voter hasn’t cast a ballot before the deadline, then process fragment PF01 in the pool VOTERS is terminated by a time-out exception which is consumed by the intermediate message event E02 in the repeating process fragment PF02 in the pool COOR.

In the third step 3, the process publishes the results of the vote.

The explicit separation of the behaviour of the voters from the voting procedure and the imposition that all voters are treated equally (i.e. the pool VOTERS acts as a voter’s proxy) considerably simplifies the validation, control, monitoring and certification of such a process-based solution.

Thanks,
AS

Practical Process Patterns: Customer eXperience As A Process (CXAAP)

Another practical process pattern - Customer eXperience As A Process (CXAAP)

This blogpost is inspired by the sentence "The reason customers use our products and services, is to get jobs done in their lives." from http://bridging-the-gap.me/2013/06/03/designing-the-business-around-the-experience/

This sentence made me thinking about a hierarchy of embedded (in some sense) processes: 
"person's life-as-a-process", 
"person's situation-as-a-process" (e.g. expecting a baby), and 
"person's job-as-a-process" (e.g. buying a bigger car for bigger family).  

Note that I define process (noun) as explicitly-defined coordination of services and/or activities to produce a particular result (see http://improving-bpm-systems.blogspot.com/2013/03/bizarch-artefacts-definition-again.html for more details). Thus the process is not only a predefined order of activities which is repeated many types. There are other variations of process as shown in see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html .

For example, buying any car requires some planning, visiting car dealers, taking a credit, etc.  - a normal process which is unique in each case, but is constructed from some, mainly decision, process patterns (I must write a blogpost about those decision patterns).

Customer-experience-as-a-process - a person who is buying a car acts as a customer for a car dealer. This is a normal selection, trying and negotiation process among two roles. Each role has its own process (or own BPMN pool) and both processes are working together as co-processes. An excellent example http://www.slideshare.net/Olbrich/process-experience-the-coffee-example-2103831 shows what is important to measure in such case.

If your products and services fit better into those processes (i.e. reduce the hassle for a customer) then they will be more attractive for customers.  Potentially, all four mentioned above processes should be taken into account to improve the customer experience.  Then the customer will consider your service again.

IMPORTANT: Ask right questions. For example, a civil architect will ask a customer "Do your parents visit?" "How many kids do you want?" "How long do you want to stay in this place?" and then the architect works with the customer to find the best design that meets the customer needs.

Product-as-a-process (it has the life-cycle) and service-as-a-process are designed, delivered and evolved to fit those four mentioned above processes.

Business-as-a-process or enterprise-as-a-process are taking care to organizing the that design, delivery and evolution.

Unit-of-work-as-a-process is a typical decomposition of "normal" business processes.

Resource-as-a-process - each resource has its own life-cycle; for example a document or business object (BO) as shown below (slide #15 from http://improving-bpm-systems.blogspot.com/2013/04/addressing-security-concerns-through-bpm.html).

Processes must be made explicit and executable to employ the power of processes. An enterprise can do this with its own processes. Person's and customer's processes are still implicit (although they may use some explicit process patterns). Nevertheless, an enterprise should anticipate and maybe model those implicit processes to see how enterprise internal processes fit those external processes (sounds like some variations from  http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html maybe useful).


A related post https://www.linkedin.com/pulse/understand-customer-lifecycle-create-impact-melvin-brand-flu

Thanks,
AS

Practical process anti-pattern: NAP

No Aggregated Participant (NAP)

It was noticed that the use of swimlines forces to put too much details in the diagram thus making it not easy to understand. With swimlines there is no place for a group of "tiny" activities which are carried out by several participants (each of them already has her/her own swimline), or "aggregated participant".

Without swimlines the use of  "aggregated participant" may simplify complex diagrams.

This simplified diagram is very close the pattern IPS (Initial Process Skeleton, see my book www.samarin.biz/book) and the "Approve proposal" activity is similar to the pattern DAM (Delegation Authority Matrix - see http://improving-bpm-systems.blogspot.com/2012/07/practical-process-pattern-dam.html).

Actually, we follow the pattern DIP (Decompose In Patterns - see http://improving-bpm-systems.blogspot.com/2011/06/practical-process-patterns-dip.html ).

Thanks,
AS

Practical process anti-pattern: RID

The anti-pattern Ruined in Details (RID) was detected while looking at business processes documented by the users.  Often, the sequence of activities (or tasks) is the following:
...
Role B: receive documents from role A
Role B: do your work
Role B: send documents to role C
Role C: receive documents from role B
Role C: do your work
Role C: send documents to role D
...

Sure that receiving and sending documents are important, but those activities don't add the value. Indicating only value-added-value activities (e.g. "do your work") will make diagrams more compact and easier to understand.

Maybe this anti-pattern is a sign that there are problems with integration?

Thanks,
AS

Practical process anti-pattern: DOUM

Avoid the "DOUble Master" (DOUM) anti-pattern (section 5.6 of my book "Improving enterprise BPM systems")

As coordination can be carried out by an application or by a process engine, we have to be very careful to avoid the “double master” anti-pattern. At any moment in time there must be only one master responsible for the coordination of a particular process instance. (Of course, the coordination role may be delegated if appropriate.) This is analogous to a well-organised meeting where the chairperson decides who talks next.
Also well-coordinated work improves the security and integrity of data. It can be a useful design pattern to consider that only the person who has accepted a particular human activity can modify the business objects associated with that human activity. This is a dynamic granting/revoking of permissions which is synchronised with the process. Something like in the diagram below (which is not a valid BPMN as there are no "claim" and "unclaim" events defined).

The non-recognition of this anti-pattern can be very costly. We have observed a BPM solution which allowed the modification of data by a process engine, by an interactive application (i.e. by a human) and by a batch at the same time. The coordination of activities was based on data and, if necessary, the application or the batch could “correct” the process. The process engine was used mainly for the handling of three human activities, and the implementation of this solution (for a relatively simple business process) took several man-years.

Thanks,
AS

Practical process pattern: DAM

Delegation of Authotirty Matrix (DAM) is a popular corporate tool which specifies what role is authorized for what functions in particular case. For example, a Director can approve purchasing of some services for less than 50’000 USD; more costly services must be approved by a Vice-President. Of course, the corporate approval logic must be a unique service and not “implemented” by a few gateways in each process.

The following diagram shows a possible usage of DAM.

Thanks, 
AS

Practical process pattern: SAAP

Servicing As A Process (SAAP) pattern was observed in “implied” business processes (http://improving-bpm-systems.blogspot.com/2012/07/practical-process-pattern-mimo.html). It is implied that an organisation-unit-oriented (or functional) process is invoked from a bigger (almost end-to-end) process. Actually, the former is invoked to serve client’s requests and servicing of different request may overlap in time. Thus, each service invocation should be a separate instance (see the diagram below).

So, there are elements of a mass service system – an input flow of requests for service has to be served in accordance with a potential SLA and by a limited number of servicing slots. (Like a barber shop.)

In the diagram above, the several coordination techniques (http://improving-bpm-systems.blogspot.com/2012/07/coordination-techniques-in-bpm-social.html) were used, namely: template-based, event-based, instance-based, and information-based (to manage the number of available slots – in an implicit way).

Thanks,
AS

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

Practical process patterns: DIP

Decompose Into Patterns (DIP)

A friend of mine asked me to have a look at his first try of business process modelling in BPMN. The modelled process is well-known – “gestion de sinistres” or “claim processing”.

An apartment owner/leaseholder, who got an accident, inform the property managing company (régie), they call a repair service and validate the repair cost with the insurance company. Then the managing company control the work by the repair service and ask the insurance company about to reimburse the cost. The latter transfer the money to the former to pay the invoice.

The following picture is an attempt to model this process.

This diagram does not show the structure of the process thus not easy to understand. Actually, there are four big steps in this process:

1. Submission a claim to the managing company
2. Selection of the acceptable repair service by the managing company
3. Repair and control of repair
4. Submission the invoice from the managing company to insurance company and further payment

For all of those steps there is a proper practical process pattern to follow on.

1. Submission interface (SI) – http://www.slideshare.net/samarin/process-practical-patterns-si
2. Proposal, Action, Reaction (PAR) – see my book
3. Initial Process Skeleton (IPS) – see my book
4. Submission interface (SI) – http://www.slideshare.net/samarin/process-practical-patterns-si

So, decompose your process and try to apply practical process patterns. Maybe not exactly – slightly modified to a particular use.

Thanks,
AS

Practical Process Patterns: FRAP

Functional roles are pools (FRAP)

BPMN pool is normally associated with a participant. Often such a participant is associated with an organisational role, e.g. CFO. Obviously, an organisational role may include more than one functional role. As the result, within the same business process an organisational role may participate with different functional roles to carry out different activities. This looks like a typical use of swimlines, but the question – are those activities from same process instance?

Consider the following process:

• periodically (e.g. monthly), a manager orders several service-engineers to visit several clients for carrying out some work
• a service-engineer contacts the assigned client, plans a visit and reports back to the manager the visit details
• the service-engineer pays a visit to the client
• after the visit, the service-engineer submits to the manager a report about the work done at client's site

How many pools and instances?

1. Manager as a work planner – 1 instance (as quick as possible)
2. Manager as a report validator – N instances (usual duration is a few days) 
3. Service-engineer (actually, per visit) – N instances (usual duration is a few weeks)

So, pools should be associated with functional roles.

Thanks,
AS

EBIZQ.net: What key methods do you use for applying design patterns in BPM?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2010/11/what-is-the-best-way-to-apply-workflow-patterns.php" />

I believe in tools that worked in practice. For this reason I like patterns. Unfortunately some of them e.g. some “workflow patterns” are a bit difficult for the users. So, I collected about 20 practical patterns (simple and advanced) in my book and in my blog http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns

I would like to be able to construct a business process (a template or an instance on on-a-fly) from small process fragments (similar to the chess game in which we have standard combinations). Some of them will be predefined in a library of process patterns, some of them have to be created on demand. (More about this in http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html).

For me, the closest match to patterns are macro-commands which we had in assemblers at run-time. Of course, now we need them at design time.

Thanks,
AS

Practical Process Patterns: CAAP

Cooking As A Process (CAAP) pattern illustrates "coordination by instances": as a typical culinary recipe comprises many "smaller" actions, they are modelled as instances of the sub-ordinated process. The main process is to follow the recipe.

Note that the same person can be in two roles: CHEF and sub-ordinate.

Obviously, monitoring of this process should be more "practical" than just following tokens within this diagram.

Thanks,
AS