Frank Michael Kraft's Blog

The question how to add more intelligence to Business Processes provokes me to share a my opinion on this.

Yes, of course we can discuss about business rules and automated decisions. But in the end, the most intelligent entity on earth is still the user. Yes, we can discuss about AI and Deep Blue being Chess Champion. But my statement still holds.

Yes, it is all about decisions. But that does not imply, that the decisions need to be automated. Some can. But often the business process should push the necessary decision to the user.

And to allow for intelligent decisions, it is crucial to allow for enough decision alternatives. This may sound simplistic in the beginning. But it is not. Bare with me for a moment.

So what is as simple as an approval? Approve or Reject. The simplest decision in the world. But not so simple. Of course, if only Approve or Reject is modeled / implemented, then what should the user do, if he wants to do something else? What else could a user do other than Approve or Reject? He might want to send it back to revision for example. Another user might want to change the underlying approval object – what influence does this have on the process? A realignment of the process is necessary. What, if an approver wants to merge several approvals into one or if he wants to split one into several. Partly Approve. Partly Reject. Partly Edit. Define new Followup – Approval. Change the Approval Type. Merge unterlying objects. Split them.  And Realing the Process. Or substitute the Business Process by an equivalent different one. If you only begin to think about it, then you can hardly stop. And if you think, what that means for a process model, then I would say this is a real challenge. Certainly far more than giving only two branches: Approve and Reject.

So in my opinion adding intelligence to business process means also adding flexibility to the business process, that allows for more than simple alternatives for the user and to push decisions to the user. And to allow for automated decisions to be overruled by the user in many cases.

What is a Process? This discussion seems to be still ongoing, and I have my own take on this.

In Procedure vs. Process it is discussed from the angle of if it is a sequence or order of action or not sequence or order. Also Merriam-Webster dictionary is cited to say that a process is

a series of actions or operations conducing to an end ; especially : a continuous operation or treatment especially in manufacture

I fundamentally disagree with this definition. In my opinion the series of action is only one half of a process. The state is the other half. A process must always have a defined state. Either it is not started, it is finished or in the middle – in process. If it is in process, it needs to be further defined, what the detailed state is. So if a process is modeled in terms of actions, then the question is, which state do the individual actions have.

In the Blog Column 2 – links for 2009-02-02 we see the statement that refutes the difference between process and procedure as claimed by Procedure vs. Process . For my taste this is a little bit a too technical discussion.

I rather approach it from a little bit different angle. For me a busines process is the sum of all business objects and process objects that are needed to achieve a common busines goal, their state, their actions and the constraints between the actions and the state.

You might argue, that I define process by process – i.e. business process by process object. But they are different. Process objects are like workflows and have a rather small business goal , but a business process has a much broader scope. All process objects are small business processes, but not vice versa.

By such a definition I exclude such things like interactions with the system, because they do not have a state. So adding a sales order, saving it, adding another sales order and saving it is no business process by this definition, because it has not state and it does not achieve a common business goal. A business process would be to deliver goods which have been ordered by customer orders and bill them, and collect payments for them. This is a common business goal and the whole process has a state which is reflected in the state of it’s business objects, namely the customer order, the delivery, the invoice and the payment.

What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance [...] Kiran Garimella

from http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
That is an concise list of what is important within BPM, although I to not share the view of the author, that BPM is a kind of proces operating system. ImhO it is a design principle and a management paradigm. It must be supported by system design, to become effective, but it is not an operating system, upon which higher level solutions will be developed. Yes, it is an architecture – and the Business Process Platform architecture that I already mentioned is one important part of it. But it is not merely a separate software layer.
Now let us look a little more into detail of these elements:

Ad 1) Business Semantics.
It is obvious, that it is inevitable to take into accound the process, that is realized by Business Objects (Ordering, Selling, Payment, Stockkeeping, Billing, …) if the process semantics is important. Each of the Business Object types have a business semantics. Each of their states has and the actions, that can be performed with them (like release). It is not possible to ignore them, if an holistic view on the process semantics is necessary. The other way round said: It is often necessary to realize the process semantics by means of implementing Business Objects, because it is so sophisticated business semantics – if I mention prices calcuation for example.
Ad 2) It is impossible to do process design and not take into account the process, that has been implemented in Business Objects already – if it is not a very simple case like a very simple workflow. But even with a simple worflow, there often is a Business Object (Invoice, Project, Order, …) behind it. So the process can not be designed completely free, but within the limitations of the Business Objects, that are going to be used. Or the other was round: if the Process is Designed completely free, then Business Objects need to be implemented or extended to realize such a behavior.
Ad 3) Process Metrics.
Is it possible to think of process metrics and not take into account the state of Business Objects? Plainly said: No. It is relevant, if orderes are Released or not, if Invoices are posted or not and how long it takes from ordering an Order (i.e. reaching the state ordered of the Order) and posting an invoice (i.e. reaching the state posted of the Invoice). So process metrics need a tighter integration with Applications – in the form of a Business Process Platform BPP.
Ad 4) Process Goverance
Process governance can only be realized, if the necessary process metrics is provided. As a result of process governance, the process needs to be adapted. This can – in certain limits – be done by changing some modeled workflows. But often it is needed to utilize different functionality which is implemented in Business Objects or to adapt Business Object functionality. This can only be done, if the application has been built in a way, which makes this possible cost effectively – i.e. by conforming to a BPP architecture.
So the different elements of BPM can better be reached, if BPM is tighter integrated into applications – i.e. if applications are BPM enabled – and if a Business Process Platform (BPP) programming model is followed.