Coordination techniques in #BPM

In the context of BPM (see http://improving-bpm-systems.blogspot.fr/2014/01/definition-of-bpm-and-related-terms.html) I use the following definition of business processes. A business process is an explicitly-defined coordination for guiding the enactment of business activity flows.

Considering that there are different techniques to coordinate the work to be done (e.g. the discipline in the army and an agreement on positions in a football team of amateurs), this blogpost lists the several coordination techniques which are applicable in business processes.

This blogpost is the continuation of http://improving-bpm-systems.blogspot.fr/2012/07/coordination-techniques-in-bpm-social.html

flow-chat-based – a typical workflow which is the formal token logic (multiple tokens are possible) which controls the order of activities to be executed. Note: flow of control vs flow of data.

state-based – a typical state-machine which is the simplified formal token logic (only one token is possible which is located at a particular state); for example, a life-cycle diagram for an object type because each object instance can be only in one state.

event-based – as a simplified EPN (Event Processing Network) – see http://improving-bpm-systems.blogspot.fr/2011/01/explicit-event-processing-agents-in.htmll

role-based – use of a role-dependent function the further routing of tokens; e.g. distribution of load.

rule-based or decision-based or intelligence-based – use of a calculation-intensive function to guide the execution.

data-based – use of predominantly data in rule-based or decision-based techniques.

information-based – use of predominantly information in the intelligence-based technique.

knowledge-based – use of predominantly knowledge in the intelligence-based technique.

community-based or social intelligence or social knowledge – asking a community for an advice to guide the execution.

goal-based – a variant of the intelligence-based with the use of goal-dependent function to guide the execution, e.g. stop the process if its goal is reached (consider a shopping list or a check list). Milestone is a kind of goal.

instance-based – exchange of events between process instances, e.g. co-processes

inter-process – a simple variant of instance-based when the end of one process instance is the start of another process instance.

managerial – a variant of the knowledge-based with the use predominantly of tacit knowledge.

instinct-based – a variant of "very" tacit knowledge, e.g. flock of birds shows complex behaviour because all birds have the same "internal" program which interprets some signal between them.

inter-organisation – a variant of the inter-process when processes are in different organisations.

resource-based – the execution depends on the availability of a resources, e.g. a system of mass-servicing like a hair-dress shop. (also known as demand-supply balance)

decomposition cascade – a variant of goal-based in which something complex should be disassembled into smaller components in several steps (of a component is also complex that it should be decomposed as well), e.g. architecture of an IT system, cascade of secondary particles, lightening.



assembling cascade – as the opposite to the decomposition cascade, assembling something complex from smaller parts; e.g. building construction, implementation of an IT system/application. Typically, a Gantt diagram is used to manage the complexity of assembling cascade.


combined cascade – doing decomposition and assembling together as in agile development, by architecting some components and then implementing them as mini-cascades (in waterfall development, the decomposition cascade and assembling cascade for the whole system are clearly separated in time).

life-cycle-based - necessary to add as a "high-level" coordination - http://improving-bpm-systems.blogspot.com/2013/11/practical-process-patterns-lifecycle-as.html 

Scheduling 3-tier from karl walter keirstead - see https://kwkeirstead.wordpress.com/2014/11/16/three-tier-scheduling-and-why-you-need-it-for-acmbpm/

1

Thanks,
AS

#bpm for developers: improve #agility of implementations

A small presentation for developers about BPM with different tricks to improve the agility and robustness of implementations is available on SlideShare http://fr.slideshare.net/samarin/bpm-for-developers

BPM for developers from Alexander Samarin

and its extended version

BPM for developers, extended from Alexander Samarin

Thanks,
AS

Quick delivery of solutions via a PEAS-architected platform - mini-projects

This is a continuation of the post Quick delivery of solutions via a PEAS-architected platform" to describe functioning of mini-projects.

Roles within mini-projects (are taken from the DAD book)

A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end user.

The team lead (TL) is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful.

The product owner (PO) is the one individual on the team who speaks as the “one voice of the customer.” She represents the needs and desires of the stakeholder community to the delivery team.

The architecture owner (AO) is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.

The role of team member (TM) focuses on producing the actual solution for stakeholders.

Solution elaboration

The preferable way for implementing solutions is assembling them from standard components available in the platform. Components are of the following types: Off-the-shelf functional extensions, e.g.

• plug-ins 
• Data structures and reports
• Documents and their metadata 
• Filing plans 
• Collaboration utilities (calendar, news, issues, etc.) 
• Business rules Roles and permissions 
• Processes (or workflows) 
• Tasks 
• Forms 
• Events and notifications 
• Layouts and presentations 
• KPIs 
• Audit trails 
• etc. 

The whole decomposition of a solution into components is also approved by the AO.

All components are versioned through their life-cycle. Component’s life-cycle is as usual: design v1, design v2, implementation v3, implementation v4, design v5, and so on. Versions of components can be produced by TMs with the help of secondary roles.

The last design version (i.e. before implementation) of a component must be approved by the AO.

The last implementation version (i.e. production) of a component must be validated by the PO with the help of stakeholders. TM proactively consults the PO about all components.

Thus the solution evolves as all its components are elaborated and a version of a solution is a snapshot of current versions of all its components. The PO with the help of stakeholders approves a production version of a solution. Each solution may have several production versions; in some case they may co-exist (i.e. overlap in time).

Some intermediate versions of the solution are actually prototypes which are throwable (« jetable » in French) by definition.

Time-boxing delivery

Mini-projects operate in a typical agile and goal-based iterative (like PDCA) way:

• Plan deliverables (a deliverable is a particular version of a component) for the current iteration. 
• Implement (do) selected deliverables. 
• Validate (check) completed deliverables with the product owner. 
• Act upon the feedback from the team. 

Thanks,
AS

Quick delivery of solutions via a PEAS-architected platform

The aim of this post is to outline how to organise the quick delivery of solutions via a platform architected in accordance with the PEAS enterprise pattern.

The business need

Users’ demands are typically numerous, have many overlapping features and will be implemented with different pace (because different users’ units work with different speed). The challenge is to achieve the synergy between different demands and capabilities of the platform. It can be addressed by a proper combination of architecture (PEAS enterprise pattern), governance structure and implementation practices.

Decomposition into several basic functionalities

Vast majority of users’ demands correspond to several basic functionalities or combinations of them. For example, in an ECM-platform such typical functionalities are:

• Information site 
• Collaboration site 
• Workflow 
• Data collection 
• Common storage 
• Business manual (a la wiki)
• Public site 
• Extranet site 
• Integration with Outlook 
• Securing documents 
• Access from iPad 
• Integration with archive 
• Integration with SAP 

Readiness review

Potential projects are in rows and functionalities are in columns. Each project requires some functionalities for its 1st and 2nd parts (phases). Each functionality is at the different level of readiness: green, yellow and red. This allows estimating the readiness for 1st and 2nd parts of each project. The popularity of each functionality can be estimated also.

Governance structure

There are two primary types of activities:

1. On-going and centralised platform governance: evolution of architecture, evolution of features, evolution of solutions, evolution of practices.
2. Rapid implementation of solution as a mini-project – light specifications, quick prototyping, consistent configuration, fast procurement, agile development, and re-use of existing tools and habits.

The platform governance is carried out by an inter-organisational-units coordination committee (Platform Coordination Committee – PLACOCO).

Mini-projects are carried-out by solution architects (business analysts, technical staff, super-users from the business units, etc. - depending on their complexity).

Platform implementation resources (programmers and configurators) are provided by the IT department and by a set of authorised service providers (platform vendor and its authorised partners).

Operational team provides integration and release of solutions into production.

Implementation practices

Implementation practices should be as light as possible without any internal barriers. In any case, we will work with the speed of the users.

1. Users’ demand is understood by the business analyst (BIZAN).
2. If the BIZAN finds that this demand is too complex then it is escalated to the PLACOCO to assign another solution architect (SA) otherwise the BIZAN acts as the SA.
3. The solution dossier is prepared by the SA with the help of other staff members. A prototype is prepared if necessary.
4. If the solution dossier shows that a proposed solution is NOT straightforward (a set of rules to be defined and it can evolve over the time) then the PLACOCO evaluates it and approves any new features/extensions (if necessary).
5. The solution dossier is transferred to the internal pool of platform implementation resources to come up with the resource allocation.
6. If internal resources are not adequate (too busy or/and lack of expertise) then the solutions dossier is escalated to the external pool of platform implementation resources.
7. Mini-project team (including super-users) is formed and it iterates with the users to finalise the solution.
8. Solution is operationalized following the change management process.

Thanks,
AS