1st law of BPM
Each BPM vendor, each BPM consultant, each BPM “body-of-knowledge” and each BPM client (i.e. enterprise) understands BPM differently.
Note: Thanks to Emiel Kelly ( https://nl.linkedin.com/pub/emiel-kelly/11/464/824 )
Corollary 1 All BPM quotes must be taken critically.
2nd law of BPM
BPM covers three different concepts:
- a management discipline (a discipline for the better management of the enterprise functioning in support of the enterprise goals - managing business by processes);
- tools (also known as BPM-suite software products to manage business processes per se), and
- practices (usage of BPM to solve unique problems of a particular enterprise).
3rd law of BPM
As any enterprise-wide undertaking, the usage of BPM within an enterprise must be systemically architected: designed, governed and optimised.
Corollary 1 Architecting BPM for an enterprise must comprise BPM as a discipline, BPM tools and BPM practices.
4th law of BPM
At present BPM is a vendor-driven market.
Corollary 1 A vendor-independent understanding of BPM is mandatory for successful using BPM in an enterprise.
Corollary 2 A vendor-independent understanding of BPM is mandatory for successful acquiring an BPM-suite software product.
Corollary 3 Current BPM standards are optimised to vendors not customers thus to be reviewed.
5th law of BPM
The vast majority of unique business processes can be constructed from a limited set of business-centric patterns.
Corollary 1 BPM achieves synergy between diversity and uniformity.
6th law of BPM
Corollary 1 There are many coordination techniques which are used by BPM, e.g. flow-chart, intrinsic knowledge, social knowledge, business rules, etc.
Corollary 2 BPM is mandatory in a digital enterprise.
7th law of BPM
Done correctly BPM is 50 % of Enterprise Architecture (EA).
Corollary 1 Consider BPM and EA concerns (business, application, information, technology and security) together.
Corollary 2 Some enterprise architects do not understand BPM. (They consider that business processes exist only in EA repositories.)
8th law of BPM
Corollary 1 BPM-related theory is a combination of math, ontology and systems theory. And on top of that then, engineering.
Thanks to John Morris ( https://ca.linkedin.com/in/johnhwmorris )
9th law of BPM
BPM establishes and maintains the explicit, machine-executable and measurable (qualitative and quantitative) linkage between various enterprise artefacts.
Corollary 1 BPM is an enabler for sound risk management at the enterprise scale.
Thanks to Venkatesh Thiruvarul ( https://www.linkedin.com/in/venkyt ) and
Hadi El-Khoury ( https://fr.linkedin.com/in/helkhoury )
10th law of BPM
BPM delivers digital business solutions as explicit and machine-executable assemblies of artefacts.
Corollary 1 BPM delivers digital business solutions in an agile and incremental way.
Corollary 2 BPM delivers digital business solutions considerably faster than the traditional software development.
Thanks to Sergei Penkov ( https://au.linkedin.com/in/sergeipenkov )
11th law of BPM
Because the value is created in interactions between a customer's process and enterprise processes, BPM makes explicit the creation of value.
Thanks to Kai Laamanen ( https://fi.linkedin.com/pub/kai-laamanen/6/384/913 )
12th law of BPM
BPM induces significant technological, organisational and work-related-cultural changes.
Corollary 1 Management of technological, organisational and cultural changes is a must in process-centric transformation.
13th law of BPM
Thanks to Scott Francis ( https://www.linkedin.com/in/sfrancisatx )
14th law of BPM
15th law of BPM
16th law of BPM
Successful BPM implementation is an enterprise-wide digital transformation.
Corollary 1 It is mandatory to keep the big picture and implement it in several small projects. ( see http://improving-bpm-systems.blogspot.it/2015/06/incremental-transformation-to-digital.html )
Corollary 2 All the enterprise-wide functions must be aligned to optimised the use of BPM.
Corollary 3, ICT, as the most common enterprise-wide function, must have all its functionality “in tune” to optimise the delivery of process-centric solutions. Namely: Governance, Security, Software development practices, Operations, Monitoring, Support, Maintenance & Small enhancement, User Experience, Data Architecture, Use of the selected BPM-suite tool, Overall continual improvement.
Corollary 4 An enterprise needs a small group of agreed minds to architect and guide others to execute this digital transformation.
17th law of BPM
Thou shalt consider business process model as a description of WHY this process is as it is depicted in its diagrams.
Note: Such a description is:
- computer-executable (i.e. formalised)
- multi-viewpoints (process diagrams are some of those viewpoints)
- understandable by all the stakeholders of the process
18th law of BPM
Thanks to John Morris ( https://ca.linkedin.com/in/johnhwmorris )
19th law of BPM
The following BPM-specific aspects must be present in any successful use of BPM:
- BPM good practices (they are software-independent and enterprise-independent)
- enterprise BPM architecture (how a particular enterprise is using processes to manage better its work)
- target enterprise application and information architectures to integrate a BPM-suite tool into the existing enterprise computing environment
- BPM-suite tool suitable for the job to be done at a particular enterprise
- process-centric project management (which is agile-like because each process, being a composite artefact, defines all its component and their implementation follows agile practices)
- organisational and/or operational changes for optimising working practices for the best use of BPM potentials
- availability of leadership resource(s) to achieve synergy between all other items
20th law of BPM
Thanks to www.bpmtips.com
21st law of BPM
The BPM industry is ready for a next 'round' of standardization.
22nd law of BPM
Level of automation of your processes = c1 * "Level of modelling"**2 + c2 * "Level of coding" + c3
Corollary 1 Formalise your work before even thinking about automating it.
23rd law of BPM
Do not mix up coordination with subordination.
Note 1: If the task B is planned to be executed after the task A then it does not mean that the performer of the task B is working for the performer of the task A.
Note 2: If the task B is planned to be executed after the task A and the performer of the task B may reject the work done by the performer of the task A then it does not mean that the performer of the task B must have the higher corporate power than the performer of the task A.
Example: A doctor works after a nurse but not for a nurse.