Linkedin: Is BPMS Just the new name for Application Development?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=70120&discussionID=14249147&sik=1267196069489&trk=ug_qa_q&goback=.hom.anh_70120.ana_70120_1267196069489_3_1" />


Agree with Max that the goal is to be able to improve processes by the business without the existing burden of application development. To reach this goal it is required to architect the flexibility of enterprise BPM systems (BPM system is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio).

In many cases, an enterprise BPM system is a historical set of applications and each of them dilutes and mixes processes, events, rules, data, services, KPIs, etc. With the help of BPMS (software) and other modern tools we can externalize, make explicit and implement via DSLs those artefacts. This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts. So, BPM (as discipline/concept, software and system used together) is disruptive innovation vs. application development.

Thanks,
AS

...


Thanks Mark, I will try to be more explicit ….

An enterprise is a complex, dynamic and self-evolving socio-technical system which consists of many artefacts. Some of them: processes, services, events, data structures, documents, rules, roles, data, documents, activities, audit trails, KPIs. Those artefacts are interconnected and interdependent. Because of new policies, priorities, compliance, technology, etc. we have to change the enterprise. Implementation of such changes necessitates the evolution of some artefacts and the relationships between them. It must be easy to modify all artefacts and relationships without causing any negative effects.

With the traditional application development the majority of artefacts is implicit (because they are coded in, for example, Java) and cannot be modified by their owners thus making the whole enterprise difficult to evolve. Principles for creating creating flexible systems are:
- All artefacts must be evolved to become digital, external, virtual and components of clouds
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Business process is the best example of a relationship between other artefacts: who (roles) is doing what (business objects), when (coordination of activities), why (business rules), how (business activities) and with which results (KPIs). So, business processes should be explicit and executable and this is done by BPM suites (or BPMS). Other artefacts are handled by different technologies/tools, e.g. ECM for documents, BRM for rules, MDM for data, etc. Now, instead of developing applications, we can assemble (of course with the help of SOA) artefacts around business processes thus increasing flexibility.

As processes (and services) are the major artefacts of this architecture, the use of BPM (as a discipline for using processes to manage business), BPMS (as a tool) and BPM system should be aligned. Sure, those three concepts can be used in separation – good processes are implemented in a Java program or BPMS as the only tool which includes all other technologies. But this still limits the agility of the enterprise.

A few extra resources are in my blog http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html

Thanks,
AS

Linkedin: From a business management standpoint, which is more important: Business Capability (the WHAT) or Business Process (the HOW)?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1847467&discussionID=14428836&sik=1266999647752&trk=ug_qa_q&goback=.ana_1847467_1266999647752_3_1" />

Support Gaby about “focus on business performance”. In my books, capability is the possession of characteristics required to produce a particular outcome. The latter is a pair “right things” (assets) and “done well” (performance, reliability, etc.) as the result of work of a function (regardless how this function is implemented). So, a capability combines functional and non-functional characteristics (timeliness of outcome, data accuracy, quality of result, efficiency, effectiveness, impact on stakeholders, SLA, SLE, etc.) of a function. See http://improving-bpm-systems.blogspot.com/2009/11/linking-concepts-and-expressions-used.html

Sure, decision-makers should monitor the business performance. Such a monitoring may be reactive by measuring the outcome (function is a black-box), or it may be proactive by measuring the process of achieving the outcome (function is a white-box and its business processes are visible). My experience – business line managers like the proactive monitoring, because it helps them to prevent problems.

Actually, we speak about GRANULARITY of performance monitoring which may be different for different decision-makers and may change over the time. I would recommend asking decision-makers explicitly about their needs for performance monitoring. Then it will be clear where to measure – just at the level of some capabilities or add a few check-points within some business processes.

Thanks,
AS

BPM reference model - fragment 09 - Your flexible BPM system will become an enabler for business innovations

... continued from fragment 08

1.9   Your flexible BPM system will become an enabler for business innovations

A typical task for a BPM system is to balance the final added-value of the product against the overheads associated with restructuring and/or tuning the enterprise business system to create this added-value. Today market success is often based on offering personalised products for less overhead. This book is not about how to make your products better, different or more attractive for the market -- this is for you to decide. What this book can offer is to help you reduce the overheads in doing so -- your flexible BPM system will become an enabler for your business innovations.

Imagine that each product is handled by a personalised and dedicated "virtual" business micro-system. The micro-system is optimised for a particular product and evolves together with the product lifecycle (see figure 1.10). As a result, any exception becomes the norm. Instead of reducing the number of variations and considering exceptions as a loss in productivity ("20 % of the work takes 80 % of the time") all products are treated equally. Of course, this is already the case for the manufacturing of expensive products such as aircrafts, cars and, to some extent, computers, but such an approach is also applicable to a wider range of commodities, especially those treated/handled with software-intensive systems.

Figure 1.10   The co-evolution of the enterprise business system and business micro-systems

... This is the end of the chapter 1. Maybe I will make also publicly available the chapter 13 "The BPM opportunity and challenge for enterprise architecture".

Thanks,
AS

BPM reference model - fragment 08 - The flexibility of your BPM system must be explicitly architected

... continued from fragment 07

1.8   The flexibility of your BPM system must be explicitly architected

1.8.1   The hidden cost

The flexibility of a BPM system is a characteristic which can be elusive and difficult to achieve. The main difficulty comes from the fact that, as already mentioned in 1.4, in a process-centric enterprise, the BPM system covers most of the enterprise business system. Hence it inherits most of the existing problems from different parts of the enterprise and adds new problems of collaboration between those parts. Of course, this brings new challenges in reaching the required level of flexibility, as well as new opportunities. Below, we make those challenges explicit and later explain how we address them via a proper architecture.

Our experience shows that the business usually wants separate requests for change in the IT environment to be implemented quickly. These changes are typically small (from the point of view of the business staff) but unpredictable (from the point of view of the IT staff). The current practices of software development have failed to provide a good solution to this challenge. The usual practice is that an IT application is released with a fixed set of business functions, and then it is maintained to accommodate new business and technological needs until the release of the new application at a later date.

It is thus not surprising that [10]

• "80 % of software lifecycle costs occur during the maintenance phase", and
• "80 % of maintenance is due to unmet or unforeseen user requirements; only 20 % is due to bugs or reliability problems".
  

These values were reported in 1992 as an average for the IT industry; the current situation for some enterprises is worse -- the development and deployment of an application can be only 5 % of the total cost of its ownership. What is also disturbing is that these values are not widely known to many people from the IT industry, and IT staff typically estimate these values completely differently (see figure 1.9).

Figure 1.9   Different estimations of the development/maintenance lifecycle cost ratio

Considering the critical role of the IT services in any modern enterprise, it is obvious that an inability of the existing IT environments to implement quickly unexpected requests for change reduces the speed at which the enterprise can carry out its performance improvement. Meanwhile, improving the speed and quality of software development although necessary is not sufficient by itself, because any IT application has to be tested and deployed, data have to be migrated for this new IT application, the users have to be trained to use it efficiently, etc.

1.8.2   Conceptual integrity

Our experience shows that the best way to address this problem is to architect all existing methodologies and IT technologies in such a way that they work together -- there is no magic wand, only the concerted use of different technologies, knowledge and practice around the BPM discipline.

The biggest difficulty is to have a clear understanding of which piece should be taken from which IT tool in a particular case. It is well known that modern IT tools have a lot of overlapping functionality. Also, many IT staff members naturally want to embed/insert/use their favourite IT tool in as many IT solutions as possible. Furthermore, many IT tools offer some customisation to adapt to business needs, and vendors offer to develop a special extension for your need. As a result, the rationale behind many architectural decisions is "we use this tool because we can". Such decisions should be avoided along the lines of the famous "spandex rule" -- "just because you can doesn't mean you should".

In some senses, this is similar to mastering a chess game, which requires an understanding of how to "play" all chess mates in the right direction and in the right sequence. And this is the essence of what this whole book is about.

1.8.3   Collaboration between the business and the IT

In addition to mastering the combination of methods and tools, the internal collaboration between the business and the IT is essential. It is not a secret that in many enterprises there is a lack of good collaboration. We think that our approach for improvement of BPM systems facilitates the step-by-step establishment of trust and helps to minimize (or ideally eliminate) this collaboration gap. In reality, both the business staff and the IT staff work with different views of the same enterprise business system. In a simplified way we can say that the business staff see the enterprise business system as a coherent set of processes which are under the control of the business. Typically these processes constitute the management model. The IT staff see the enterprise business system as a set of IT services which are under the control of the IT system. Typically, these services constitute the implementation.

Convergence of the business and IT views is within reach. The IT world recently "re-discovered" and accepted the notion of services, and so emerged SOA. But IT is still not very comfortable with processes. Also, how processes and services work together has not been clear, and typically both processes and services are "diluted" in existing monolithic applications. This makes the enterprise business system difficult to evolve as changes to program code are often necessary to effect even minor business changes.

The architectural framework presented in this book provides guidelines and patterns for structuring processes and services in such a way that they can be changed easily, without disproportionate efforts and destructive side-effects.

1.8.4   Common understanding among everyone involved

We have observed that improving a BPM system requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM system. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system. The different groups of stakeholders are generally the following:

• top managers
• enterprise architects
• business line managers
• process owners
• super-users
• normal users
• project managers
• business analysts
• IT managers
• IT solutions architects
• IT developers
• IT operators

It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better (see also 3.3 and 3.4). (This is a typical duty of the chief architect of the BPM system.) Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying "Yes" to all requests from the "more important" staff members; it is about building a common understanding and agreement between all stakeholders. This book is intended to help you achieve such success by giving some real examples of communication with the business staff (see chapters 3 and 7).

1.8.5   Coordination at the scale of the whole enterprise

Coordination between artefacts is also important because of the high level of complexity of modern enterprise business systems. There is not only static complexity at the design level, but there is a lot of dynamic complexity during the execution (in the same way that the assembly of a car engine from its parts represents a static complexity, but the car also needs to run with a reasonable performance).

Also the modification of enterprise business systems to accommodate typical changes in policies, priorities, technology, laws, etc. necessitates the evolution of some artefacts, and the relationships between them, simultaneously as a complete system. So, it must be easy to modify all artefacts and relationships without causing any negative effects.

The improvement of any BPM system is a difficult task. It is a transformation

from a system of systems that has grown over years under different influences
   to a coherent, smoothly evolving, enterprise business system which is easy to maintain and develop further
      subject to socio-technical aspects, because how you do something is sometimes more important than what you do; 3.3 covers some of the human-related concerns.

Industry experience has demonstrated that the strategic transformation of an enterprise is more effective and efficient if it is based on an agreed architecture, an "enterprise-wide architecture" [or an Enterprise Architecture (EA) as it has come to be known]. EA (14.3.4) is defined as a coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy. Thus it is basically the actionable master plan for the enterprise; a comprehensive plan for how to build, to use and to evolve all enterprise artefacts (including the data, business processes, business rules and IT assets).

The concept of using EA is old and has always been appealing for enterprises. But there is a wide-spread perception that a large (and useless) amount of paper work has to be prepared before any results can be obtained. We have experience that it does not have to be this way -- if done correctly, the use of EA can bring significant improvements faster, better and less expensively than the use of any other approach.
EA and a BPM system are both enterprise-wide initiatives, and the best results are achieved by using them together -- in chapter 13 we will discuss how to achieve synergy between them.

... to be continued in fragment 09 ...

Thanks,
AS

BPM reference model - fragment 07 - All attention at enterprise BPM systems

... continued from fragment 06

1.7   All attention at enterprise BPM systems

The situation with the second enabler is much more difficult. We have observed that some BPM systems are complex, a "problem" of their history, and chaotic and inefficient. In such systems, the control and operations parts of the enterprise business systems have been constructed separately under different management policies, and they have different speeds of evolution, are not well integrated, etc. Certainly, such BPM systems cannot implement changes at the required pace.

An example of inflexibility can be workflow-based solutions which are often very difficult to evolve. Workflow technology, as a general rule, makes the flow of human work explicit and executable. It also covers to some extent other artefacts such as roles, rules and data, but not explicitly. Everything that is not explicit is usually "spread" somewhere in the program code, and thereby becomes difficult to maintain.

The BPM discipline inherits a lot from workflow technology, but by extending it the BPM discipline handles explicitly more business artefacts (i.e. services, events, etc.). Also, the BPM discipline considers the whole cycle of continual process improvement. Thus, potentially, BPM systems can be more flexible than are workflow-based solutions.

Of course, high flexibility does not happen automatically simply by buying a modern BPM suite. The ability of a particular BPM system to evolve at the required pace must be properly architected -- i.e. designed, planned and supervised during its implementation.

This book constitutes practical guidance and help for transforming your existing enterprise environment into a BPM system which is easy to evolve. It provides many recommendations, principles, methods and examples.

... to be continued in fragment 08 ...

Thanks,
AS

BPM reference model - fragment 06 - BPM and some information technologies

... continued from fragment 05

1.6   BPM and some information technologies
The growing popularity and great potentials of the BPM discipline created the impetus for a new class of enterprise software -- the BPM suite or BPMS (14.3.9) -- a coherent set of software tools for facilitating the implementation of BPM systems. Typical components of BPM suites are the following.

• Process modelling tool, designer or modeller -- an ergonomic graphical environment for manipulating artefacts such as events, rules, processes, activities, and services.
• Process testing tool -- an environment for functional testing which allows a process to be "run" with different testing scenarios, e.g. various inputs, various rules, and various responses from the services.
• Process template repository -- a store of process templates comprising different versions of the templates.
• Process instance repository -- a store of executing and executed process instances.
• Work list or task list -- an interface between the BPMS and a human carrying out some activities within processes.
• Dashboard -- an interface between the BPMS and the humans controlling the execution of processes, e.g. a BPMS administrator (who should know that "everything is working") or a business process owner (who should know "how well everything is working").
• Process analytics tool -- an environment for analysing audit trails and KPIs to find out historical, current and predictive tendencies of business operations.
• Process simulation tool -- an environment for performance testing which allows a process to be "run" as for functional testing, but where the dominant considerations are the expenditure of time and other resources.

These components are spread across different parts of the enterprise business system as shown in figure 1.7.

Figure 1.7   Components of a BPM suite

Unfortunately, just managing processes using a BPM suite is still not sufficient because many additional artefacts are not considered. This has lead to the creation of another new class of enterprise software -- Business Process Platform (BPP) -- which attempts to cover more artefacts together. Typical technologies associated with BPP are the following.

• Business Event Management (BEM), which captures real-time business events and assigns them to their proper processing. Also, BEM is related to Complex Events Processing (CEP) and Event-Driven Architecture (EDA).
• Business Rules Management (BRM) and Business Decision Management (BDM), which allow the explicit, formal and, preferably, user-friendly handling of business rules. As business rules are often present in many business processes, a BRM can simplify considerably the maintenance of their business logic.
• Enterprise Content Management (ECM) system and collaboration facilities, which capture, manage, store, preserve and deliver content (documents as well as e-mails, blog posts, forms, etc.) in a collaborative manner. ECM is important since about 70 % of business information is stored in such a way, and many business processes need to handle such types of non-structured information.
• Master Data Management (MDM), to store, manage and preserve highly-structured data even if they are spread between many databases
• Configuration Management DataBase (CMDB), to store and manage different configuration information about artefacts.
• Role-Based Access Control (RBAC), which facilitates the secure management of resources and provides explicit, formal and, preferably, user-friendly handling of business roles.
• Business Activity Monitoring (BAM), which facilitates the operations control of an enterprise through the processing of audit trails which are produced during the execution of business processes. The BAM aggregates, analyses and presents real-time information about activities.
• Business Intelligence (BI), which facilitates the analysis of the functioning of an enterprise by processing audit trails. Some KPIs may be derived by BI tools. BI tools collect, integrate, analyse and present business information.
• Service-Oriented Architecture (SOA) (14.3.10), which provides guidance on a) how to construct complex software-intensive systems from a set of universally interconnected and interdependent services and b) how to govern the evolution of such systems.
• Enterprise Service Bus (ESB), to facilitate inter-service communication within SOA-based environments.

These technologies are spread across different parts of the enterprise business system as shown in figure 1.8. Only the highlights of BPP systems are illustrated. IT governance is not mentioned because it is everywhere.

Now that we have all necessary elements in a BPM-centric "melting pot", let us come back to the two major enablers (discussed in 1.1) for carrying out the optimisation of the enterprise as a whole: 1) better decision making and 2) the ability to implement the necessary changes at the required pace.

The BPM discipline can help with better decision making by providing

1. a formal and executable description of the business processes, which can be used in different specialised tools such as process modelling tools, process simulation tools and
   process executions tools, and
2. real data collected during the execution of business processes (audit trails, KPIs), which can be reused for simulation and performance evaluation (using BAM and, mainly, BI).

Figure 1.8   Different technologies associated with BPP

... to be continued in fragment 07 ...

Thanks,
AS

BPM reference model - fragment 05 - Artefacts important for BPM

... continued from fragment 04

1.5   Artefacts important for BPM

As already mentioned in 1.2, processes and services are the principal artefacts (14.2.6) of enterprise business systems. But enterprise business systems operate in addition with the following artefacts which are important for the BPM discipline:

• events (14.4.7) -- incidents of importance to the business; they occur within and beyond the enterprise boundaries and may give adequate reason for some action from the business (for example, receiving a customer's order, detecting a performance bottleneck, etc.);
• rules (14.4.8) -- constraints and conditions under which the enterprise operates (for example, a claim for more than 10 000 CHF must be endorsed by a group leader, the working week is 40 hours long, etc.);
• activities (14.4.9) -- elementary or indivisible units of work which constitute processes;
• roles (14.4.10) -- sets of responsibilities (for example only a manager is authorised to approve a particular document);
• objects (14.4.11) -- formal descriptions of real things and people which constitute the business [there are two big groups of objects: data structures (14.4.12), e.g. partners, products, etc., and documents (14.4.13), e.g. forms, reports, etc.];
• audit trails (14.4.14) -- factual information about process instances (for example, when a particular activity has been completed);
• KPIs (14.4.15) -- quantifiable measurements that express how well something or somebody is achieving its or his/her objectives.

Figure 1.6 provides an overview of how these artefacts are spread across different parts of the enterprise business system. The various artefacts are used to a different extent at different places within the enterprise; but taking into consideration that the implementation part owns the shared description part, figure 1.6 shows them only in the owner (or master) parts. These artefacts will be discussed in more detail in chapter 7.

In figure 1.6, the expression "processes (as templates)" means abstract descriptions (or models or plans) of processes; the expression "processes (as instances)"  means the results of execution of the corresponding templates. Usually, a process template may be used to produce many instances (similar to a blank form which can be copied to be filled in by different people, or similar to a document template from which documents can be derived).

The expression "services (as interfaces)" means formal descriptions of services which are available for their consumers, whereas the expression "services (as programs)" means implementations of services.

Figure 1.6   Some artefacts in the enterprise business system

To handle the complexity illustrated in figure 1.6, any process-centric enterprise needs to have its own BPM system (14.3.8): a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system. In other words, the BPM system is responsible for ensuring that the functioning of the different parts of the enterprise business system occurs in synergy.

For any process-centric enterprise, the BPM system may not be perfect (e.g. some processes may be only documented on paper, some details may be "located" only in the minds of certain individuals, etc.), but it does exist. Any implementation of the ISO 9001 Quality Management System can be considered as an example of a BPM system.

... to be continued in fragment 06 ...

Thanks,
AS