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

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

Coordination techniques in BPM, Social, ACM, etc.

Considering the definition of a process as “explicitly-defined coordination of services to create a particular result” this post shows how some explicit coordination techniques (rows) are employed by different “methodologies”  (columns) for managing the business by processes.

	Classic WF	Classic BPM	ACM	Social NNN	EPN
template-based	++	++	--	--	-+
event-based	-+	+-	+-	-+	++
rule-based	++	++	+-	-+	+-
role-based	++	++	+-	-+	-+
information-based	-+	-+	+-	+-	-+
intelligence-based	-+	-+	-+	+-	--
community-based	--	--	-+	++	--
goal-based	--	--	+-	-+	--
instance-based	--	-+	--	--	--
interprocess (used instance-based)	--	--	--	--	--
managerial (tacit-knowledge-based)	--	-+	--	--	--
resource-based (follow the resource life-cycle)	--	-+	+-	--	--
inter-organisation	--	-+	--	--	--
state-based ??	??	??	??	??	??

A combination of some of them may provide "predictive analytics".

Ideally  – like in the chess game – use must the right combination of coordination techniques in a particular case at the particular moment. But, not all process-centric tools offers all coordination techniques. 

Also a related post about BPM and ACM - http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html.

Thanks,
AS