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

BPM reference model - fragment 04 - The essence of the BPM discipline...

... continued from fragment 03

1.4   The essence of the BPM discipline -- what you model is what you execute

By combining all ideas mentioned so far, a process-centric enterprise can be represented in more detail as illustrated in figure 1.4. Processes are used everywhere: in the execution to drive the work, in the decision making to identify improvements and in the implementation to realise these improvements.

Figure 1.4   Feedback pattern for a process-centric enterprise

What is the major barrier to enterprise optimisation in this figure? It is that different parts of the enterprise business system use different descriptions of the same process. Usually, these descriptions are constructed separately by different people and do not exchange the necessary information, and some of them may not even exist explicitly in a particular enterprise.

The use of software-intensive systems to automate the operations part of process-centric enterprise business systems allows the elimination of this barrier by creating a single formal description of the business processes. This description should be explicitly and formally defined to be good as both a simulation model and an executable program.

Such a description is the main concern of the BPM discipline, which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise's systems, employees, customers and partners within and beyond the enterprise boundaries.

Different functions of the BPM discipline are spread throughout the enterprise business system as shown in figure 1.5.

Figure 1.5   BPM discipline in the enterprise business system

All these functions use a formal description of business processes. At the moment of writing of this book, within the BPM industry there is no appropriate system of standard formats for the formal description of business processes. The three most popular formats (BPMN, BPEL and XPDL) were created by different groups and for different purposes:

• BPMN -- Business Process Modeling Notation, was created by the OMG (www.omg.org) to provide a graphic representation of models of business processes [7];
• BPEL -- Business Process Execution Language, was created by OASIS (www.open-oasis.org) to provide a formal execution of the interaction between web services [8];
• XPDL -- XML Process Description Language, was created by WfMC (www.wfmc.org) to provide the exchange of models of business processes between various BPM tools [9].

Unfortunately, these standards are not sufficiently complementary despite the standardisation efforts expended to date. The situation is aggravated by the fact that behind each format, there are various software vendors, and each of them is trying to "push" its format on the market. As has been seen many times in similar struggles, the interests of the customers are insufficiently taken into consideration (and at present there is not a sufficiently powerful organisation lobbying for the interests of the BPM customers).

Ideally, there should be a single master format which can be transformed into different formats suitable for different needs. [This is similar to the case of electronic documents which may be available at the same time in XML, PDF and PostScript but, in the majority of cases, only the master format (i.e. XML) is truly editable.]



... to be continued in fragment 05 ...

Thanks,
AS

BPM reference model from a book about BPM, SOA and EA; fragment 03

... continued from fragment 02

1.3   Some existing disciplines for continual performance improvement

At present, there are several proven disciplines for continual performance improvement which are used in process-centric enterprises. Three of them ISO 9001 Quality Management System, Six Sigma and Lean production are described briefly below. These disciplines impact different areas of a process-centric enterprise business system as illustrated in figure 1.3.

The ISO 9001 Quality Management System [4] requires a formal description of processes and services, and the collection of evidence (in a form of audit trails and records) that business processes have been applied correctly. It provides some help in the creation and maintenance of a system for an enterprise to manage its business processes.

Unfortunately, many implementations of the ISO 9001 Quality Management System consist only of a written documentation of business operations (comprising possibly tens of complex interrelated documents). Any change in business operations necessitates also an update of some of this written documentation thus multiplying the effort to implement changes. As a result of this approach, the ISO 9001 Quality Management System is often not perceived as a useful tool, and nor is it if it is only documentation based.

Figure 1.3   Different continual performance improvement disciplines

Six Sigma [5] concentrates on describing processes and services as models suitable for applying statistical data-analysis methods to eliminate defects (defects which cause dissatisfaction of a customer). The approach is systematic and works well for reducing flaws in established processes, but the end result depends on the ability of people to create a "good" model which matches reality, and usually Six Sigma initiatives are limited to business units and not to the enterprise as a whole (i.e. there is no view of the big picture).

Lean production, which originated in the Toyota production system [6], provides a comprehensive set of heuristics (e.g. "eliminate waste", "see the big picture", "avoid sub-optimisation", etc.) for process improvement and a long-term philosophy in developing employees and partners. The success of Toyota has proven the usefulness of Lean, but the lack of some formalism in the "lean thinking" makes this discipline dependent on the skills of the people applying it.

All these disciplines use one or more of the following approaches:

1. collection of performance data about the actual work done;
2. use of a simulation model (although sometimes this is only in someone's head!).

At the same time, they offer different and complementary techniques for determining changes for improving the functioning of the enterprise business system.

Obviously, good simulation models (which are comprehensive, exact and formal) and accurate performance data enable substantial improvements in enterprise performance. Conversely, poor simulation models and non-accurate performance data may prevent enterprises from addressing simultaneously improvements in performance in the ways that enterprises need to:

• operational performance -- do the things right and carry out corrective actions, on the basis of real-time information;
• tactical performance -- implement continual improvement, and carry out predictive analysis to avoid wasting resources;
• strategic performance -- predict how to do things differently, implement the necessary changes, carry out systematic creation and realisation of innovations in the core business;
• competitivity -- quick and appropriate reactions to regulatory, market and technology changes.

To achieve the best possible improvements under the particular circumstances, an enterprise has to carry out optimisation of the enterprise as a whole.


... to be continued in fragment 04 ...

Thanks,
AS

BPM reference model from a book about BPM, SOA and EA; fragment 02

... continued from fragment 01

1.2   Process-centric approach  -- processes and services shall be made explicit

The business world understood a long time ago (see, for example, the numerous articles on Business Process Re-engineering, and Quality Management Systems that services (14.4.1) and processes (14.4.4) are the backbones of most enterprise business systems. W. Edwards Deming said "If you can't describe what you are doing as a process, you don't know what you're doing". At present, many enterprises use the process-centric approach as a critical tool to organise their operations as a set of business processes and practices for their management, as well as their improvement.

A service is defined as "an explicitly-defined and operationally-independent unit of functionality". In this context, explicit definition means that a description of the service (i.e. the input, the output and other contractual information such as the duration of the contract) exists. This explicit definition should be the subject of agreement between the service provider and the consumer. Operational independence means that problems in one service do not affect the functioning of another service if the latter does not use the former, i.e. some services are autonomous with respect to other services. For example, a garage may provide both a repair and a sales service. Even if the repair shop is on vacation the sales shop can still function; the services are thus operationally independent.

The implementation of services is not visible and does not need to be. In other words, for a consumer to decide whether he or she wishes to benefit from a particular service, he/she only needs to know the formal description of the service; how the service is implemented by the service provider is irrelevant provided that the service description is fulfilled. For example, banks provide financial services to their customers (who are consumers of those services). Provided that the service descriptions of the financial services are accurate, consumers can select and compare the services offered on the basis of the service description alone, without knowing the banks' internal procedures.

A process is defined as "an explicitly-defined coordination of services to create a particular result". Here explicit definition means that there is a formal description of how services work together. Ideally, such a description should be interpretable not only by a human being, but also by a computer. Coordination means that processes serve as a conductor to manage bigger services which are constituted from smaller services. The bigger services will have a more complex functionality than the smaller simpler services (see figure 1.2), in the same way that an orchestra has a more complex functionality than that of the individual musicians constituting that orchestra.

Figure 1.2   Relationship between processes and services

So, at a process-centric enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

Although the relationships between processes and services are unique and rather complex in each enterprise, the use of explicit definitions allows the formalisation of dependencies between them. As a result, different formal methods (such as simulation, automated validation and automated execution) can be used for enriching the business knowledge (enabling better decisions) and improving the speed of evolution of the enterprise business systems (enabling faster implementation of changes).

... to be continued in fragment 03 ...
Thanks,
AS

BPM reference model from a book about BPM, SOA and EA; fragment 01

I would like to make publicly available a BPM reference model which is the first chapter of my book "Improving enterprise business process management systems" (www.samarin.biz/book). This book looks at the following three concepts of BPM:

[the theory]

BPM as a management discipline, i.e. managing business by processes, (BPM discipline) ;

[the tools]

BPM as a software (BPM suite);

[the practice]

BPM as a portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio (BPM system).

In particular this book concentrates on the last concept which is often neglected although all enterprises need it. This book will help you to industrialise enterprise BPM systems. It describes a holistic approach to the application of BPM and Service-Oriented Architecture (SOA) for improving enterprise business performance, including

• how to use architecture to reduce complexity,
• how to use a BPM reference model and BPM artefacts,
• tips on mastering the most difficult aspect – people,
• guidelines on the modelling in BPMN,
• recommendations for designing flexible systems, and
• in-depth discussion about the link with enterprise architecture (EA).

1   A holistic approach to business process management

1.1   The issue is about improving the business performance of your enterprise

Improving the business performance of an enterprise (14.3.2) is a permanent imperative and a daunting task these days. Enterprises improve their performance by changing their business operations to perform more effectively and more efficiently. Owing to the internal complexity and dynamic nature of enterprises and the non-predictable nature of the modern business environment, most enterprises follow the feedback pattern illustrated in figure 1.1 to manage their enterprise performance. They do so in an adaptive way by

1. measuring how the work is done in the operations part of the enterprise business system (14.3.5) (such measurement is often in the form of some metrics or indicators, e.g. the rate of returning customers),
2. observing the business environment (in the form of some external information and events, e.g. new regulations, new market needs, new technologies),
3. deciding within the control part of the enterprise business system in what areas the enterprise should advance (such decisions are often made using some formal and/or informal models), and
4. implementing (in the form of some changes)the decisions taken.

Note that with such a feedback pattern, the enterprise business system is itself measured and improved; this is much more complicated than measuring the output and adjusting the input without changing the controlled system per se (see [2]).
Figure 1.1   Feedback pattern for an enterprise

Because of the enterprise complexity, it is necessary that improvements be achieved incrementally, continuously and with some verification, in accordance with the classic Deming wheel [3] Plan, Do, Check, Act:

• [Plan] measure how the work is done,
• [Plan] observe the business environment,
• [Plan] decide in what areas the enterprise should advance,
• [Do] implement the decisions taken,
• [Check] validate the effect of those decisions, and
• [Act] refactor both the control and the operations parts of the enterprise business system to adopt internally the improvements.

The extent and frequency of these improvements depend on the particular situation. Also, different improvements
may have different scopes. So, how can enterprises achieve the best possible performance under any particular set of circumstances? We think that there are two major enablers for carrying out the optimisation of the enterprise as a whole:

1. tools and pertinent information to help people in better decision making, and
2. a guarantee that the enterprise is capable of implementing the necessary changes at the required pace.

To realize these two enablers, it is necessary to organise properly both the operations part and the control part of the enterprise. The most widely accepted modern approach for such enterprise organisation is a process-centric approach.

... to be continued in fragment 02 ....
Thanks,
AS

Practical Process Patterns: GAAP

Game As A Process (GAAP) pattern illustrates the use of an independent coordination (a formal expression of the game rules) between two players in the chess game.

Thanks,
AS

Linkedin: This is what is killing Enterprise Architecture…

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1523&discussionID=13538757&goback=.anh_1523" />

If I look at an enterprise as a complex, dynamic and self-evolving socio-technical system of systems then I can say that “the set of descriptive representations that are required in order to create” an enterprise is necessary, but not sufficient.

I consider the following list of “missing” parts of EA

1. In addition to explicit “descriptive representations” is it necessary to have explicit “prescriptions” how to improve and evolve a particular enterprise – some kind of a set of architectural principles. Rationale – high level of changes, many people are involved.
2. Relationships between enterprise artefacts have to be explicitly expressed. For example, a process is a complex relationship between data, documents, roles, rules, services, processes, KPIs, etc. Rationale – systems thinking.
3. All descriptions have to be actionable – the same description should be used to a) coordinate the daily work, b) take a management decision, c) implement a new improvement. Rationale – support cost for a few duplicating descriptions (first thing to kill in case of lack of resources).
4. EA is about the whole enterprise, so everyone in the enterprise is a stakeholder of EA and everyone in the enterprise is the customer for an enterprise architect. So, if many our customers are “killers” of our work then may be something wrong with us? Rationale – a lesson from developing socio-technical systems: “how you do something is sometimes more important than what you do”.
5. Understanding that a system for a person is a module for another. Rationale – nested/recursive/fractal character of enterprises.
6. And all those parts should be aligned to work together for a particular enterprise.

Please feel free to extend this list.

Thanks,
AS

Book review from Steve Towers (Founder & Chair, BP Group)

This is a book for those interested in developing an understanding of BPM from a technology viewpoint.

Well presented, logical and a useful tool for those involved in delivering effective technical solutions.

Steve Towers, Founder & Chair, BP Group.

Linkedin: Why Process Approach?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=61365&discussionID=13160866&sik=1265359418661&trk=ug_qa_q&goback=.ana_61365_1265359418661_3_1" />

I am with Scott – processes can be a company’s most valuable asset. To realize potentials of this asset I used the following “techniques” in implementing enterprise business process management (BPM) systems (see the difference between BPM discipline, BPM system and BPM suite - http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html):

1.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. (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.

2. It is not enough to capture processes – they have to work or “be actionable”. The aim is to have a single description of business processes which is used by different people in different parts of an enterprise:
• model in design
• input for project planning and implementation
• executable program for coordination of work
• documentation for all staff members
• base for taking management decisions

Sure that a good architecture which combines BPM, SOA, EA and other technologies and methods is very desirable to realize potentials of processes.

Thanks,
AS