The Business Process Analytics Format

Business Process Analytics provides process participants and decision makers with insight about the efficiency and effectiveness of organizational processes.

There are three reasons why we might want to measure different aspects of business processes:

  1. To evaluate what has happened in the past,
  2. to understand what is happening currently, or
  3. to build an understanding of what might happen in the future.

The first area focuses on the ex-post analysis of completed business processes, i.e., on Process Controlling. You can find several papers (and an e-book) on this site that explain this approach in detail. Process Controlling may or may not involve a pre-existing formal representation of the business process in question. If no documented process model exists, or if the scope of the process extends across multiple systems and process domains such a model may be inductively generated through Process Mining. Leading research on this topic is being conducted by Wil van der Aalst’s research group at TU/Eindhoven – make sure to check out their ProM framework. The second area focuses on the real-time monitoring of currently active business processes, i.e., Business Activity Monitoring. The third area uses business process data to forecast the future behavior of the organization through techniques such as scenario planning and simulation and is known as Process Intelligence.

To date, the audit information produced by most Business Process Management systems is formatted in proprietary ways, and for historically good reasons – each system may implement the internal state model of a process instance and an activity instance differently. Most systems offer basic monitoring and reporting functionality out of the box, built on their own format. But what if you need to integrate the audit information of several BPMS? What if you need to correlate process instances that cross other applications in your IT infrastructure, such as imaging systems, messaging infrastructures, etc.? You will need some common format for these audit events.

In the mid-1990s the Workflow Management Coalition had attempted to standardize a format for these events, it was dubbed the Common Workflow Audit Format (CWAD), and it was utterly unsuccessful. First, it was developed just prior to the onset of XML. Second, it used variable headers and footers around a common body for different types of audit events (i.e. it was not very elegantly designed). Third, at the time most vendors treated audit information as a source of debugging information, but not as a source of business intelligence.

For quite a while now the WfMC has discussed a rework of this initial attempt and I am happy to announce that we have just released the first public review version of the Business Process Analytics Format (BPAF). BPAF is a tool-agnostic XML schema for events that occur over the lifecycle of a business process instance.

During the initialization and execution of a process instance, multiple events occur which may be of interest to a business, including events that relate to the instantiation and completion of process activities, internal process engine operations and other system and application functions. Using BPAF-based information, a business can determine what has occurred in the business operations managed by a business process management system. BPAF is designed as an implementation-independent data format that enables the aggregation and correlation of audit data across multiple platforms. While we anticipate that the major sources for BPAF data will be business process management systems, the use of the standard is not limited to these systems and other information systems may publish events following the BPAF data structure to allow for easier integration with other process-related audit data.

The schema is pretty straightforward, here is a graphical snapshot:

Business Process Audit Format XML Schema Snapshop
Business Process Audit Format XML Schema Snapshop

The key to BPAF is a classification of audit events that can occur over the life-cycle of a process instance. CWAD used three different state machines, resulting in three different event formats: One for processes, one for activities, and one for work items. We integrated everything into a single state model that incorporates what we learned from the Wf-XML state machine with the proposed activity states of BPEL4People and WS-HumanTask.

If you are interested in the details, here is the public review version of the specification: 2009-02-20-WfMC-TC-1015-Business-Process-Analytics-Format-R1

To learn more and to actively influence the standardization process, please, head over to the WfMC Wiki where you can download the BPAF XML schema and participate in the further development of this specification.

Stevens/QUT study explains how organizations document their business processes

Study finds that business process modelers use just 20% of standard business process modeling notation

HOBOKEN, N.J., June 8, 2008 — Researchers from Stevens Institute of Technology and Queensland University of Technology have published a study that explains how organizations document their business processes using a visual notation. The study found that although a standard process modeling language offers many symbols to construct detailed process descriptions, only 20% of them are regularly used in practice.

“Organizations need to document their business processes for various reasons: To document compliance to legal requirements, to assess the fit of new information technology, or to improve the flow of work in order to increase performance. The Business Process Modeling Notation (BPMN) is a rich and increasingly popular standard set of symbols for the visual representation of business processes. It offers over 50 different symbols to represent the details of business processes, but we know very little about how much of this notation is actually used in practice. Our study tries to illuminate this aspect,” said Dr. Michael zur Muehlen, Assistant Professor in the Wesley J. Howe School of Technology Management.

In collaboration with Dr. Jan Recker from Queensland University of Technology, zur Muehlen collected a large sample of process models and analyzed the use of modeling techniques. Their results show that only a fraction of the standard notation is commonly used, and the use of remaining symbols follows a long-tail distribution, very similar to how natural language is used:

  • Only five symbols (normal flow, task, end event, start event and pool) occurred in more than 50% of the models.
  • Seven additional elements occurred in at least 25% of the models – gateways (parallel and two variants of XOR), lanes, text annotations, message flow, and start messages.
  • Seventeen elements were identified in less than three models. Seven elements occurred in just two models, five in just one, and five elements were not used in any of the models analyzed in this study.

The core of BPMN constructs used is similar to traditional flowcharting notations, while the more advanced symbols, which allow for the specification of exceptions, time constraints and similar details went largely unused. The study also found that to date no universal subset of BPMN symbols has emerged, and that different modelers tend to construct their vocabulary based on the process they want to document. It also shows that many organizations are at a very early stage of documenting their processes.

Recker illustrates the implications of this study: “Organizations use BPMN in a manner similar to organizations that employed flowcharting 10 or 20 years ago – they want to describe their operations in simple, graphical terms. The process modeling efforts in most organizations at this stage are simply not advanced or mature enough to start specifying service-enable workflows with exception behavior, which would require the use of more specialized BPMN symbols.”

The first publication of their results sparked a wave of comments from analysts, software vendors, and standards makers in the BPM area. One analyst even dubbed it “The Great BPMN Debate.” While many commentators pointed out the need for a simple, lightweight process documentation technique, some pointed out that BPMN should be used more fully to realize its potential benefit.

“We welcome the fact that our findings have generated some discussion around the proper use of BPMN,” says zur Muehlen. “There is tremendous potential for better Business/IT alignment based on accurate process descriptions. However, people hold different positions on where the crossover point between the process documentation used by a business analyst and the process specification used by a systems analyst should be. This is the focus of our ongoing research.”

As part of the research project, “Modeling in the Large,” researchers from Queensland University of Technology, Stevens, the University of Queensland and University of Melbourne are studying the issues surrounding the identification, documentation and improvement of business processes in large-scale environments, such as multinational corporations, federated projects and enterprise-wide process improvement initiatives.

About Stevens Institute of Technology

Founded in 1870, Stevens Institute of Technology is one of the leading technological universities in the world dedicated to learning and research. Through its broad-based curricula, nurturing of creative inventiveness, and cross disciplinary research, the Institute is at the forefront of global challenges in engineering, science, and technology management. Partnerships and collaboration between, and among, business, industry, government and other universities contribute to the enriched environment of the Institute. A new model for technology commercialization in academe, known as Technogenesis®, involves external partners in launching business enterprises to create broad opportunities and shared value. Stevens offers baccalaureates, master’s and doctoral degrees in engineering, science, computer science and management, in addition to a baccalaureate degree in the humanities and liberal arts, and in business and technology. The university has a total enrollment of 2,040 undergraduate and 3,085 graduate students, and a worldwide online enrollment of 2,250, with about 400 full-time faculty. Stevens’ graduate programs have attracted international participation from China, India, Southeast Asia, Europe and Latin America.

Contact:
Stephanie Mannino
(201) 216-5602
[email protected]

Who is at fault – the language or the speaker?

As researchers, Jan Recker and I find it challenging to strike a balance between our efforts to meet the academic standards required by the wider research community and the demands regarding accessibility, relevance, timeliness and appropriateness instilled by the wider practitioner communities. We were happy to find that our blogging about research results inspires the BPM community to not only to take an interest in our research but also to critically assess this work and to post replies to it. We find this most welcome.

Our previous post on the frequency of BPMN construct usage has generated a passionate response by Bruce Silver who we know and respect as a very active contributor not only to BPM blogging in general but also to BPMN education and application specifically. Bruce makes many good points in his post and raises a number of interesting challenges. However, on some accounts we disagree with a number of the inferences he draws, so we want to clarify some aspects of our original post.

First of all, the paper and post are the result of a joint research effort between Jan Recker (QUT Brisbane) and myself (Stevens Institute of Technology), which we have stated. Jan and I started working together due to the complementary nature of our interests – standards in BPM (myself) and practical usage of modeling methods (Jan). Our study has been motivated by the fact that we know so very little about how standards such as BPMN are actually used – as opposed to what vendors, consultants and trainers think how they should be (or might be) used. – and this is what we try to explore and understand. The post and the related study are but one snapshot of our combined research. Agree with our results or not, but please give credit where credit is due. Jan is one of the most prolific researchers on BPMN; and it would be unfair to ignore his substantial contribution to this research.

We have outlined our research method in great detail in the full version of the BPMN paper, the PDF of which has been linked to from the original post. If you missed it, click here. Of course, we could have written a great deal more about the mode of analysis, but let’s be frank: how many blog readers would want to see this information in the post? (let us know if you do!) And for those of you taking an interest in research methods – both Jan and myself are more than happy to discuss the ways in which academic research is conducted. More than welcome.

We started with a simple question: BPMN is divided into a core and an extended set of constructs – does this separation hold in practice, or are there other common subsets (dialects or creoles) that can be found in practice? If there is such a common subset, we would expect a sizable number of models to share it. We found no evidence of a larger common core. Only 6 model pairs out of the 126 models used similar BPMN subsets (i.e. there were 6 subsets shared by 2 models).

We looked at the similarity among all subsets by coding the occurrence of symbols as a 50-bit string and computing the pairwise Hamming distance. On average 7 symbols differed between the BPMN subsets, and since the average model used only 9 symbols that makes the true common core very very small.

We performed a hierarchical cluster analysis on the models, trying to find the constructs that were used in groups. Indeed, several well-defined clusters emerged from this analysis: Basic Modeling Constructs, Annotations and Explanations (which include the blank XOR Gateway – not something we expected), Organization Modeling Constructs, and Control Flow Refinements. Users that move beyond these clusters seem to add individual constructs as needed, but in a rather random fashion.

Whether the 126 models we gathered are representative to all BPMN uses is a good question. Of course, we don’t claim this to be the case and we are in fact expanding our collection of models (hey Bruce, want to send us some of your seminar models?). However, so far our results have proven stable. We spend a great deal of our time with organizations using BPMN and we can assure you upfront – this is indeed indicative of how people use BPMN.

Bruce likens a frequency count of BPMN symbols to a character count in a document. We disagree – BPMN symbols are more like words, since they have semantics and are governed by formation rules. There are no formation rules at the character level in most languages. One could liken the frequency count to the frequency with which words in the English language are used – and that provides a much more useful metric than a character count. Linguists talk about the difference between an active and a passive vocabulary – words that we use versus words that we understand. It is possible that the use of BPMN is emerging along the same lines – a modeler might understand many of the symbols, but will frequently restrict him or herself to a more limited subset. To illustrate this: You may understand many entries in Merriam-Webster’s dictionary of the English language, but you do not use them frequently (or at all).

Do the models we collected have errors? Absolutely. Some of them we find useful in modeling courses – to show the types of errors usually made in practice. Our intention was not to analyze perfect BPMN models – we find those in every training course and in tool documentations, etc. The BPM reality looks different. Our intention was to analyze the current practice of BPMN modeling, not the indended application of the language. English speakers abuse their language – I know I do – but that does not mean that their sentences are meaningless.

Turning to some of the conclusions we draw from our research, we would like to clarify some aspects: What we call ‘the real core set of BPMN’ is what our analysis showed to be the most frequently used BPMN symbols found in the models considered. This does not mean we imply this set to be the core set of BPMN to be used by everyone. Rather, this is the minimal set of BPMN constructs actually used in practice so far. Is this set little more than flowcharting? Absolutely true. Absolutely.

But what does that tell us? People, and organizations, use BPMN for purposes similar to those organizations ten, twenty years ago that employed flowcharting – they want to describe their operations in simple, graphical terms. The process modeling efforts in most organizations at this stage are simply not advanced or mature enough to start specifying service-enable workflows with exception behavior in BPMN. No, most people use it simply for flowcharting.

What we conclude from this observation is that the ecosystem of vendors, consultants and trainers should be aware of this and should plan, manage and employ their efforts (be it tool development, BPMN training or modeling workshops) accordingly. We present a number of conjectures based on these observations, some of which appear to be troubling to Bruce. This is worrisome to us, we hope we can clarify this a bit more:

First, we see a great deal of training programs introducing the full BPMN specification to large number of stakeholders. Our results show, however, that most of this training is in fact only applicable to a small number of BPMN application areas. So we have to ask: Are there any tailored BPMN training programs? What should the ‘BPMN beginner’ course look like and how this body of knowledge then be extended by specialist courses? One of the suggestions we raise is indeed to start with the set of BPMN symbols that in fact are widely used in practice. Why? Because this would allow the BPMN beginner to instantly be able grasp, understand and use the majority of models in practice. Sure, (s)he would not yet be an expert, sure (s)he would not yet have learned about the benefits and expressive power of advanced BPMN. But (s)he can go out and leverage the knowledge instantly and make contributions. Without having to digest the complexity of a full-blown course. We do not imply that business users do not understand the more refined BPMN symbols, we have just found little evidence that they use them frequently.
Second, we suggest to tool vendors to rely more on empirical information about BPMN use when having to make trade-off decisions in BPMN support. Let’s face it – many BPMS do not support the full set of BPMN constructs. This makes sense, because if the system does not have the capability to execute the semantics of a specific construct (say, a transaction around a set of activities) then if would not make sense to allow a system analyst to draw this symbol. So which constructs can a vendor neglect initially and which need to be supported? We would argue that it is of best interest to vendors to focus on those constructs heavily used in practice. Why? Because this would give them access to the widest share of the market. Simple as that. This does not mean, that our suggestion is of a static nature. Of course not. Over time, full support should be given – and (relating to our previous conclusion) also BPMN users should learn the advanced features of BPMN. But organizations and tool vendors alike often face a need to achieve results very very fast. Which also means that releases are built and deployed that are far from finished.
Third, we think that our last conclusion was misread. Our intention is not to discredit the sizable development effort that went into the BPMN specification. More than 120 people participated in more than 120 interactions, be they face to face or conference calls. That’s a lot of BPM expertise leading to the current specification. We do not discourage advancement. We actually like BPMN’s advanced vocabulary. But have you asked end users what they think? Well, we did. Not only in this study but also in Jan’s large-scale BPMN usability studies we did find that users are in fact very troubled by the sheer number of, for example, event constructs. Are they used at a large scale? No. Do users understand their full capacity? Typically not. Why is this not at all reflected in BPMN development? That is exactly our point. Sure, our argument is a somewhat provocative statement. But if it helps to channel some attention to end usage, that’s fair by our standards.
We know a great deal about what BPMN can do in theory, how it is implemented in tools, how training programs (like Bruce’s) look like and even how we generate code from the diagrams and how the semantics can be tested and vigorously verified. But what do we know about how organizations engaged in BPM initiatives use it? Very little. Again, we were motivated by exactly this dearth of knowledge about real-life BPMN practice. Why? Because our own experiences with BPMN and with those organizations using it gave us this hunch that the theoretical usage (what vendors and consultants and trainers tell us) often has little to do with what the end users think or do (the practical usage). And why is it important to know what the end users think and do? Because it can help the researchers, vendors, consultants and trainers of this world to channel their attention and efforts to those problems real users face. Instead of the problems we think exist in practice.

We try to feed our empirical research back to the BPMN community – in the form of blogs, practitioner papers, or even directly by knocking on the door of OMG. Whether we are heard, and whether our findings have the type of impact we hoped is a different story. But we are always open for debate.

How much BPMN do you need?

by Michael zur Muehlen ([email protected]) and Jan Recker ([email protected])

BPMN is the de facto standard for graphical process modeling. While there are other graphical languages to represent processes (EPCs, IDEF, Flowcharts, Petri Nets, among others), no other notation has seen such an uptake in such a short time as BPMN has. It is widely supported by both free and commercial process modeling tools, the WfMC has made XPDL 2.0 and 2.1 a de-facto persistency format for BPMN diagrams, and a large number of courses on modeling processes with BPMN are being offered.

Now, BPMN is a complex language. The current incarnation (BPMN 1.1) consists of 52 distinct graphical elements: 41 flow objects, 6 connecting objects, 2 grouping objects, and 3 artifacts. That’s a lot of vocabulary to learn, given that each graphical elements has meaning and rules associated with it. So what is the minimum subset of BPMN that a process modeler should know? The answer: Less than you think.

To answer this question we collected a large number of BPMN 1.0 diagrams (126 in total), from consultants, seminar participants, and online sources. We analyzed which BPMN symbols were actually used in these diagrams. The full version of our research, which we will present at the Conference on Advanced Information Systems Engineering in June, can be found here. But since this is an academic paper, here are the practical highlights of our study.

None of the diagrams we looked at used more than 15 different BPMN constructs, and none used less than 3. The models themselves contained considerably more elements, but a model with, e.g., 5 tasks connected by sequence flow was recorded as using the task symbol and the sequence flow symbol. The average subset of BPMN used in these models consisted of just 9 different symbols. That means that the average BPMN model uses less than 20% of the available vocabulary.

Figure 1 shows which construct we found across which percentage of the diagrams we collected.

Usage of BPMN Constructs in Practice

Figure 1: Frequency distribution of BPMN construct usage

The results of our study are:

  • Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed. These, plus the data-based XOR gateway form what we call the common core of BPMN (marked in yellow in fig. 1).
  • Six additional elements were found in at least 25% of the models – gateways (parallel and unmarked XOR), lanes, text annotations, message flow, and start messages, we call these the extended core of BPMN (marked in green in fig. 1).
  • 17 elements were used in less than 3 models – seven elements occurred in just two models, five in just one, and five elements were not used in any of the models we studied.

We then looked at the co-occurrence of BPMN symbols – i.e., are certain constructs used in combination, and how frequently? The combination of certain elements is mandated by the BPMN specification – you cannot use lanes without pools, or data objects without associations. But if there is a common subset used by many models, this would constitute a true “common core”. A detailed analysis revealed that BPMN elements fall into several well-defined groups. Figure 2 shows these groups as frames around the respective BPMN elements. The numbers within each frame represent the number of models (out of 126) that contain all elements within the frame.

BPMN Symbol Groupings

Figure 2: Grouping of BPMN elements

Our findings are:

  • The common core of BPMN is very small. The subset of BPMN across the different models varied considerably. While nearly all models contain tasks and sequence flow, adding symbols to this set leads to a near exponential drop in models that share the (bigger) set of symbols. For example, while 65 models contain tasks, sequence flow, start and end events, only 25 also contain parallel gateways, and just 10 contain parallel gateways and data-based XOR gateways.
  • There are two types of BPMN modelers. While our sample is too small to explore this proposition in detail, we found anecdotal evidence that two groups of modelers use BPMN: Those who use pools and lanes to represent organizational responsibility for tasks, and those who use gateways to represent the control-flow rules of the process in detail. In other words, one group uses BPMN to specify inter-organizational settings (process choreography). Mostly, these users will be consultants or process analysts working on organizational (re-) engineering and process improvement. The other BPMN user group is leaning more towards workflow engineering (process orchestration). These users will likely be designers and analysts seeking to articulate precise flow conditions, for instance, in the context of workflow engineering or process simulation.

Implications

Our findings have implications for practitioners, software vendors, and standards makers alike.

  • Practitioners can begin studying the use of BPMN by focusing on the most commonly used symbols first, leaving more specialized and lesser-used constructs for those who need more specialized BPMN training (e.g. systems analysts).
  • Software vendors that are not supporting the entire BPMN vocabulary can assess what percentage of BPMN diagrams can be represented in their tool, and where enhancements should be made.
  • Finally, Standards-makers should review whether a more complete, but also more complex language is a desirable result of the standardization process. Creating BPMN took six years. How much time was spent on defining those seventeen symbols that we found are hardly used? And will the extensions of BPMN 1.1 entice users to expand their commonly used vocabulary, or will they go unused?

If you would like to learn more about this research, we encourage you to read the full version of our paper:

  • Michael zur Muehlen, Jan Recker. (Jun 16, 2008). “How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation”, 20th International Conference on Advanced Information Systems Engineering (CAiSE 2008), Montpellier, France, June 16-20, 2008., Springer LNCS. Download

You can find additional research on process modeling and process management in the publications section of this site, and in Jan’s QUT eprints directory.

As always, your questions or comments are much appreciated.

Jyväskylä? Or: Why default values matter…

I am no stranger to nordic countries. I taught in Estonia for a while and visited Finland a couple of times. And if Germans are known for their efficient ways, well, we can learn a thing or two from the people up north. In the course of my research on standards I came across the dissertation of Vladislav V. Fomin, who wrote on the Process of Standard Making using two case studies from the mobile phone industry. His dissertation is available from his alma mater, the University of Jyväskylä (more properly: Jyväskylän yliopiston kirjasto/Julkaisuyksikkö…). After some prodding and testing I found the link to order the book here. Filled out the form – off we go. But wait: No payment information was requested?!

A couple of days went by and I pretty much forgot the whole thing until an envelope arrived in my mailbox with the requested book inside, and a polite invoice for 10 Euros and 33 cents – the book cost 2 Euros, shipping 8 Euros and 33 cents. “Please instruct your bank to forward payment orders to …” Somewhat different from the usual Amazon.com experience.

Apparently, the default expectation of our Finnish friends is that people will pay, if you provide good service to them, as opposed to the typical US default, which is pay first, we’ll provide service later (maybe). This reminds me of a paper I read a while ago Continue reading “Jyväskylä? Or: Why default values matter…”

Bigger is better? A look at the complexity of BPM standards

I am attending the BPM Think Tank in Burlingame this week, and there are many insightful presentations around emerging standards in the BPM space, such as BPDM, BPMM, BMM, BPMN 2.0 and OSRM. But one thing makes me wonder – with every revision, every iteration, the standard specifications grow in size. The new BPMM specification has a whopping 505 pages in draft version. A participant asked what the effect would be if the BPMN 2.0 specification, which combines BPMN and BPDM, would be a 1,000 page document. Nobody knows… I had a look at some older and newer specifications, and this is what I came up with:

Organization Standard

Original Version

Update

Year Version Pages Year Version Pages
IETF FTP

1980

1.0

70

 

 

 

IETF HTML

1995

1.0

60

 

 

 

IETF HTTP

1996

1.0

60

1999

1.1

176

W3C XML

2000

1.0

59

 

 

 

OMG UML

2000

1.3

1034

2005

2.0

710

OASIS BPSS

2001

1.01

136

 

 

 

W3C WSCL

2002

1.0

22

 

 

 

W3C WSDL

2002

1.2

30

 

 

 

OASIS BPEL

2003

1.1

136

2007

2.0 (draft)

276

W3C SOAP

2003

1.2

128

 

 

 

WfMC XPDL

2003

1.0

87

2005

2.0

164

There are some interesting observations to make:

  • Standard specifications seem to double between versions. The only exception is UML, which actually shrank 300 pages between versions 1.3 and 2.0
  • Some organizations produce shorter specifications than others. For example, IETF specifications seem to be rather concise, compared to OMG or OASIS specifications.

Now, counting pages is not a very exact metric to gauge the complexity of a specification, but it is safe to assume that a 300 page specification is significantly more complex than a 60 page specification. I brought this up at the Think Tank, and it was suggested that specs grow because the working groups add clarifications and explanations. But it is also possible that as the standard specs grow, the effort to implement them and to prove conformance with all aspects of a specification increases significantly. If that is the case, do bigger standards keep the industry from advancing?

Stevens named Center of Excellence in Business Process Innovation

Stevens Institute of Technology has joined the IDS Scheer Innovation and Education (I&E) Network. IDS Scheer is a leading provider of Business Process Management (BPM) and officially launched its I&E Network at ARIS ProcessWorld 2007 held in Berlin.

“We are excited to be part of IDS Scheer’s Innovation and Education Network. It will help us in applying our academic research to industry and proves once more that Stevens has become a thought leader in BPM,” said Dr. Michael zur Muehlen, Director of Stevens’ SAP/IDS Scheer Center of Excellence in Business Process Innovation. “The innovation and education network allows us to look into cutting-edge developments and direction in the field of BPM and related areas,” he said. Stevens was named a Center of Excellence in BPM by SAP/IDS Scheer in 2004.

“The vision for this Brain Trust is to develop a network that generates a constant stream of ideas for innovations and to support education initiatives in the field of BPM. This Innovation and Education Network bridges the gap between the academic and corporate worlds, offering a win-win situation for all members. We have been collaborating with Stevens in the field of BPM for several years. The great combination of academic excellence and practical application of their research will provide a great input in our Innovation and Eduction Network,” said Dr. Mathias Kirchmer, chief innovation and marketing officer, IDS Scheer Group. IDS Scheer is offering the universities the opportunity to access the newest BPM solutions and practices and to be part of the innovation activities that will lead to future solutions for business excellence and related fields. IDS Scheer will benefit from ideas developed within the network and the extensive BPM education of post-graduate, graduate and undergraduate students.

The following academic institutions have accepted IDS Scheer’s invitation to join the I&E Network:

  • Aoyama Gaukin University, Tokyo, Japan
  • DFKI / University of Kaiserslautern, Saarbruecken, Germany
  • Ecole Polytechnique, Montreal, Canada
  • Eindhoven University of Technology, Eindhoven, The Netherlands
  • Queensland University of Technology, Brisbane, Australia
  • Stevens Institute of Technology, Hoboken, N.J., USA
  • Tongji University, Shanghai, China
  • Widener University, Philadelphia, Pa., USA

Through their involvement with the network, the aforementioned universities will take part in an intense communication and knowledge exchange regarding BPM and innovation. “IDS Scheer’s Innovation and Education Network is another step forward in strengthening our market and thought leadership in the field of BPM,” said Kirchmer. “Moreover, it is an example of a best practice in how to promote sustainable innovation processes by bundling academic and industry knowledge. These processes are crucial for the economies in every country.”

CEBPI and QUT win Best Paper Award

Manly Beach, December 2nd, 2005. A research paper by Dr. Michael zur Muehlen (Stevens Institute of Technology) and Prof. Michael Rosemann (Queensland University of Technology) on the integration of operational and technical risk into business process models won the Best Paper Award at the 16th Australasian Conference on Information Systems (ACIS 2005). The paper entitled “Integrating Risk in Business Process Models”was chosen from 262 papers accepted at the annual conference held in Sydney, Australia, between November 30th and December 2nd, 2005.

Michael zur Muehlen and Michael Rosemann

“The consideration of risk factors in the design of enterprise processes is more relevant today than it has ever been” said Dr. zur Muehlen, who heads the Center for Business Process Innovation at the Howe School of Technology Management. “Public companies are required to document their compliance with legislature such as the Sarbanes-Oxley Act, HIPAA, OSHA, or FDA and EPA regulations. While a lot of money is being spent on documenting current risk management and control practices, organizations will soon have to rethink their process structures and control procedures. Our approach can help them focus on the cost efficiency of their risk response activities, and help them choose the most efficient and effective process design.”

Prof. Rosemann and Dr. zur Muehlen are longstanding collaborators in the areas of Business Process Management and Information Modeling. They participate in joint research projects sponsored by the Australian Research Council and SAP Research, R&D subsidiary of German software manufacturer SAP. Both the Center of Excellence in Business Process Innovation at Stevens and the Centre for Information Technology Innovation at Queensland University of Technology conduct research exchange programs and participate in joint case studies. As part of this collaboration, Prof. Rosemann will visit Stevens Institute of Technology in February 2006, when both he and Dr. zur Muehlen will present current results of their joint projects.