Tag Archives: BPM

Processes and Process Orientation: Definition (Part 2)

After an introduction on where process orientation comes from, we will now move on to the definition. This explains some key characteristics of a process. When I first looked into the subject in 1999/2000 no generally agreed-upon formal definition had emerged yet. I haven’t re-checked on this but suspect that it hasn’t changed much, given that the topic has broadened so much in recent years. In my view the main reason for this seemingly  lack of agreement is the sheer multitude of perspectives and backgrounds from which people look at the whole thing.

A very early definition comes from Michael Hammer and James Champy (1993) in their book “Reengineering the Corporation: A Manifesto for Business Revolution” where they define a process as

"a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer."

Another one is taken from Jörg Becker and Reinhard Schütte (1996) “Handelsinformationssysteme” (=information systems for trade).

"A process is a content-wise conclusive and time-wise ordered set of functions that are required to perform work on an object that is relevant to the business."

The second example underlines an interesting observation I had made at the time:  Folks coming from a computer science background tended to not have the word customer in their definition. Of course this changed quite a bit but I think it’s interesting to see where things have come from.

Instead of providing a formal definition I would like to mention a few important aspects that in my view touch upon the key aspects of a process.

  1. Within a business the creation of added value happens along the value chain (as first defined by Michael Porter in 1985) which is generally cross-functional. The value chain can be decomposed  into transactions which, in turn, can be assembled to processes. That is processes describe activities.
  2. Each process has an owner that is responsible and serves as a first contact.
  3. The interfaces between processes, process steps and involved parties are seen as customer-supplier relationships (“the next process is your customer”).
  4. Processes are related to objects. They can be material, i.e. physical goods, or informational.
  5. Target criteria of processes are time, costs and quality. That has two implications: Firstly that a process has to meet certain targets for all those criteria. And secondly that its current achievement of them is a key aspect to describe it.

Now, those are all fairly theoretical points but I think knowing them helps to participate in discussions on the subject. Also, given that all this was compiled about ten years ago, highlights how much the discipline as a whole has progressed. Bear in mind, that at the time the Internet as we know it today, had just started to emerge. Neither Google nor Wikipedia were around, so it was all down to classical research by going to the university library and read books. Not the worst thing, though!

I just read Wikipedia’s article on business process and recommend that you do so, too. It provides additional aspects but also lacks at least one of mine (the target criteria part).

And finally, here are a few links to relevant books. (If the years differ from references made in the text it is simply because I chose to go for the latest edition here.) I used a whole lot more books, but most of them are in German so I decided to not put them up here. However, if you are interested please indicate so in the comments and I will happily provide more references.

Part 3 of this series will compare the functional and process-oriented view and show how to classify processes.

[amtap amazon:asin=1857880978]

[amtap amazon:asin=0743260872]

[amtap amazon:asin=0471953520]

[amtap amazon:asin=3478255902]

[amtap amazon:asin=3540625461]

Processes and Process Orientation: Introduction (Part 1)

This post is the first of a series aimed to give a general overview on processes and how they have affected the way we look at how organizations achieve their goals. The text is somewhat academic in nature but I still encourage you to read it. Understanding the basics and (theoretical) concepts is always helpful when it comes to practically dealing with specific challenges.

The series is based on a paper I wrote during my time at university in 1999/2000. (For those who don’t know, I read business management and not computer science or some kind of engineering.) While the paper itself was done purely out of interest for the subject and not for any course, it was triggered by a seminar for which I had to look at processes in the context of the Balanced Scorecard (BSC). I then added a few more things and made it a separate text. So here we go …

Introduction

The process-oriented approach became mainstream in management theory in the 1990s. This was a move away from a mainly functional view that had been the predominant paradigm for many decades. A functional touch can largely still be found when you look at the orgchart: Purchasing, marketing, HR, etc. are all functions and will probably be around for quite some time. But instead of focusing on those functions, nowadays people realize that cooperation across the board is necessary to deliver something useful for the customer.

The old, functional approach with its clear separation of responsibilities was, in a way, a consequence of the work done by Frederic W. Taylor on scientific management. This mainly focused on  improving efficiency by splitting up work in many discrete steps. First steps towards a more process-oriented way of doing things came from these areas:

There were a few points that triggered this re-thinking which I would like to mention here.

  1. A functional approach severely limits the organization’s capabilities to be customer-driven (see above)
  2. A process-oriented organization increases flexibility
  3. Processes, or more precisely the thoughts required to define them, greatly improve the understanding of complex commercial activities
  4. Overhead costs need better distribution

As with so many things, this re-thinking was mostly triggered by difficult economic circumstances.

Part 2 will give a definition of what a process actually is.

Lifecycle Management with SOA and BPM: Part 2

One response I got for my post on Lifecycle Management was the following:

Are you saying that one idea is that an organisation can run its whole development lifecycle by modelling it inside of a BPM tool, using it like a workflow manager?

Yes, exactly. Many people are currently thinking about how they can streamline the approval chains they have around their software development processes. The challenge here is in many cases that the tools (project management, spreadsheets, …) are disconnected from the layer where the actual work happens. And we all know what happens in such a case sooner rather than later…

So the idea is to connect the various layers that have a role here. The top-level of such a process is usually about the “stage” of a software asset (e.g. new application, enhancement, bug fix etc.). What you can then do is manage the transition from one stage to another (e.g. from development to testing) by means of a BPM system. This is the first level of visibility.

To take things a step further would then mean to also connect the stuff that gets you a deeper insight. Those would typically be the technical systems like issue tracking (these have a broader scope than just bug tracking), built systems, results from automated testing etc.

So at the end it all comes back to the idea of end-to-end visibility. And here, once more, the advantage of a universal BPM system (as opposed to something that comes together with a specific application like CRM or ERP) kicks in: You can connect pretty much everything quickly and then model the process you want.

And for management the whole thing comes with reporting and business activity monitoring (BAM) out-of-the-box. So you not only know what’s going on an individual level but also get the complete picture in real-time whenever you want. I would think that this is what many managers are longing for.

Business Activity Monitoring (BAM) and Related Areas

When you work in the software industry you are probably used to seeing things change rapidly. One of the disadvantages that come with this is a “heterogeneous” use of terms. It is often due to the fact that we do not want to bother ourselves with precise definitions. A very sloppy use of language is the natural consequence.

As some people have noticed in the past I tend to speak rather neatly. I can attribute this to my parents who were very much concerned with a correct usage of language (my father used to work as a German teacher after all). So I may be a bit more aware of the implications of an imprecise use of language. Therefore, today I want to look at some terms that are often used either without much differentiation or without a precise notion of the relationships between them. They are

  • Monitoring,
  • Business Activity Monitoring (BAM) and
  • Reporting

Monitoring is mostly used to describe an operational activity that looks after currently ongoing things at an individual level. It typically deals with questions like “What activities in my organization are currently causing problems?”. In a Business Process Management (BPM) context this means checking that all process instances are running fine. An operator will query the BPM system and ask for process instances that failed entirely, exceeded timeout limits for single process steps etc. Also automated activities fall into this category. So if you have set up an alert that alarms a human being or another system if some threshold has been exceeded, I would also consider this as monitoring.

However, we are gradually moving into a grey area here. Depending on the type of the rule that is associated with this alert, the focus moves more towards the Business Activity Monitoring (BAM) area. So imagine a threshold that is not concerned about a single incident any more. Rather it can be of a “composite” nature and look at an average for a certain time frame (e.g. average order amount per day of the week). Such figures are usually called Key Performance Indicators (KPIs). Managers tend to be much more interested in KPIs than in the characteristics of a single, although very important, activity in the organization. So instead of asking “How are we doing with order 5297523?” they would like to know “How is our on-time order fulfillment rate today?” You can think of this as monitoring for operations management. If you want to know how you are doing NOW from an overall perspective, BAM is what you probably need.

Take away the “now” attribute from this and you pretty much end up with Reporting. This answers question like “How was our on-time order fulfillment rate this month?”. In many cases this will be closely linked to Business Intelligence (BI) and Data Warehousing (DWH) topics. Some of the BI/DWH providers have also realized that their customers do not only want to know how they did in the last month but how things are going at the moment. The simple reason is that looking into the past is good to identify structural issues that can then be tackled. However, it does not help to identify a current or upcoming problem and avoid its worst consequences by taking instant counter measures.

Being able to react in almost real-time to what’s going on, is the real value of BAM. The later you realize that something is going wrong the fewer options you have and the more likely it becomes that you can only try to repair damage already done. Although implicitly mentioned in the above paragraph, I want to highlight that BAM is not only concerned with existing but also with upcoming problems. You should expect a BAM solution to be able to identify trends and alert you based on that.

So there are distinct, yet related use-cases for all these functions and you definitely want to combine them to get most from them. I can well imagine that over time these things will, at least to a degree, merge into broader solutions. One last word here: The statements given here can not reflect all possible variations and in your particular case things may seem to be different. Don’t be disturbed by that feeling. Rather analyze the situation and you will probably discover that the general lines are still the same, although the details may vary.

Nicolai M. Josuttis “SOA in Practice”

[amtap amazon:asin=0596529554]

A colleague recommended this book (link to amazon.com and amazon.de) to me and I was not disappointed. On the contrary, this was one of the most interesting IT books I have come across so far. The author is pretty well known in the SOA space and a regular speaker on conferences. He has a lot of real world experience and this shines through. What made the book particularly valuable to me, was that Josuttis points out when something is not black or white but gray and discusses the relevant aspects.

This book is probably not so easy to read for a beginner, but certainly of great value to the more experienced reader. It does not provide checklists or vendor recommendations but focuses on patterns and a good conceptual understanding. It will therefore not become outdated as quickly as many other publications but probably be relevant for a number of years to come.