BPM Milan: Modularity in Process Models

The second paper in this section on modeling guidelines was a review of modularity in process models, by Hajo Reijers and Jan Mendling. This was focused on factors related to modeling, including methodology, language and tools, and how they affect model quality; the goal being to provide guidance to process modelers for creating better models.

He first showed a general definition of model quality, but pointed out that they focused on error occurrence and understandability as measures of quality. Both errors and understandability are impacted by model size — bigger models have more errors and are less understandable — but density, average connector degree, cross-connectivity, and modeler education (but not education in a specific modeling technique) also impact these factors.

Looking specifically at modularity — the design principle of breaking down a process model into independently managed subprocesses — they hypothesized that use of modularization does not impact understandability. They created an experiment that showed participants one of two versions of two large process models (more than 100 tasks): one with subprocesses, the other flattened into a single process model. They then tested the subject’s understanding of the processes by asking 12 questions for each of the models; these were consultants experienced in process modeling, hence are accustomed to working with process models and would understand the visual syntax. What they found is that the average % of correct answers to the questions is higher for the modular than the flattened version, but for one of the models the difference was not statistically significant, whereas with the other, it was statistically significant.

This disproved their hypothesis, since modularity was important in model understandability one of the two complex models, but raised the question of why it was important for one of the models but not the other. The process with improved understandability on modularization had more subprocesses (hence was more modularized) than the one that didn’t, presenting a new hypothesis for future testing. They also found some correlation between success at answering “local” questions (those related to portions of the process rather than the overall process) and the degree of modularization.

Their conclusions:

  • Modularity in a process model appears to have a positive connection with its understandability
  • The effect manifests itself in large models if modularity is applied to a sufficiently high extent
  • Modularity seems to support comprehension that requires insight into local parts of the model

In the future, they will be relating this work to semi-automatic modularization of work.

BPM Milan: Applying Patterns During Business Process Modeling

Thomas Gschwind of IBM Research Zurich presented a paper on applying patterns during process modeling, co-authored by Jana Koehler and Janette Wong. This research was motivated by their customer’s concern for the quality of process models, and their first prototype using IBM WebSphere Business Modeler shows that 10% of the modeling time can be saved, which corresponds to about 70% of the pure editing time.

There are well-known basic workflow patterns, such as splitting and merging, but these are too fine-grained in many cases, and they were looking for pattern compounds that could be easily reused. He walked us through three pattern application scenarios, showing both the process flow and the process structure tree:

  • Compound patterns, including sequence (a set of steps in a fixed order), alternative compound (split and merge several alternative paths), parallel compound (split and merge several paths in parallel), and cyclic compound (loop). This represents the four most common of the basic workflow patterns, which is obviously just a starting point.
  • Gateway-guarded branches, which support the creation of unstructured models such as routing across the branches in a parallel split, including an alternative branch model pattern and parallel branch pattern. This can cause problems with the process if not used properly, although there are some constraints such as not allowing the parallel branch to flow backwards.
  • Closing a set of edges with a gateway, which is not always possible and is only implemented for some special cases.

He gave a live demo of creating a mortgage approval process using these patterns: he dragged a number of pre-defined tasks onto the workspace, then used a auto-linking functionality to create a basic process flow based on (I assume) the spatial orientation of the tasks. Changing a split gateway using the transformations also changed the merge gateway to the matching type. A wizard-type dialog prompts for some parameters about a set of activities, then generated the process map to match. He applied compound patterns and gateway-guarded patterns at points in the process.

This definitely reduced some of the effort in the process map drawing, and allowed users to create unstructured as well as structured processes. It’s available as a plugin for WebSphere Business Modeler, and is part of a comprehensive library of patterns, transformations and refactoring operations.

BPM Milan: Paul Harmon keynote

After a few brief introductions from the various conference organizers (in which we learned that next year’s conference is in Ulm, Germany), we had a keynote from Paul Harmon on the current state and future of BPM. It covered a lot of the past, too: from the origins of quality management and process improvement through every technique used in the past 100 years to the current methods and best practices. A reasonable summary of how we got to where we are.

His “future promise”, however, isn’t all that future: he talks about orchestrating ERP processes with a BPMS, something that’s already a well-understood functionality, if not widely implemented. He points out (and I agree) that many uses of BPMS today are not that innovative: they’re being used the same way as the workflow and EAI systems of 5 years ago, namely, as better programming tools to automate a process. He sees the value of today’s BPMS as helping managers to manage processes, both in terms of visibility and agility; of course, it’s hard to do that unless you have the first part in place, it’s just that a lot of companies spend too much effort on the first level of just automating the processes, and never get to the management part of BPM.

He discussed the importance of BPMN in moving BPMS into the hands of managers and business analysts, in that a basic — but still standards-compliant — BPMN diagram can be created without adornment by someone on the business side without having to consider many of the exception flows or technical implementation details: this “happy path” process will execute as it is, but won’t handle all situations. The exceptions and technical details can be added at a second modeling/design phase while still maintaining the core process as originally designed by the business person.

He also showed a different view of a business process: instead of modeling the internal processes, model the customer processes — what the customer goes through in order to achieve their goals — and align that with what goes on internally and what could be done to improve the customer experience. Since the focus is on the customer process and not the internal process, the need for change to internal process can become more evident: a variation on walking a mile in their shoes.

His definition of BPM is very broad, encompassing not just the core processes, but performance management, people, technology, facilities, management and suppliers/partners: an integration of quality, management and IT. Because of the broad involvement of people across an organization, it’s key to find a common language about process that spans IT and business management.

Although they’re not there yet, you can find a copy of his slides later this week by searching for BPM2008HarmonKeynote at BPtrends.com.

BPM Milan: Workshop wrap-up

This workshop is intended to be the starting point for collaborating on research in BPM and social software, and we wrapped up the day with a discussion of how the authors in the room can collaborate on a single paper to submit for journal publication, based on their existing research and the discussions that we had here today. This, of course, devolved into a discussion of the social tools that would be used in order to do this, and the game theory that applies to the collaborative authoring of papers.

I’m sure that the remainder of the conference will be quite different in nature than this highly interactive workshop, although equally valuable, but I can’t help but wondering why there’s not more BPM vendors (or more advanced customers) taking advantage of the opportunity to attend this conference. Although a great deal of innovation goes on within some vendor organizations already, even more could undoubtedly result from exposure to the research going on in the academic world.

That’s it for today: time for a quick nap, then off to the evening reception.

BPM Milan: Workflow Enactment in a Social Software Environment

Davide Rossi of Universita di Bologna presented a paper on Workflow Enactment in a Social Software Environment, co-authored with Fabio Vitali. Davide took me to task earlier today for not responding to his comment on post from last month: at least I know that someone here reads my blog. 🙂

He started out discussing why enterprises like social software — ease of use, flexibility — but also some of the problems with acceptance in enterprises, such as traceability and enactment. Furthermore, when you look at a comparison between enterprise software such as BPM, there are some distinct differences in their structure, governance and user interaction. To bring these together, you need to consider the current methods of structured coordination as compared to emergent coordination, where there is no pre-defined process, but the users create their own processes in order to achieve the stated goal. Although there will need to be a few iterations before the process takes shape, eventually this “tools-first”approach can achieve results. There is a problem, however: the BPMS tools themselves, which are not really suited to being put in the hands of end users. Yes, I know that the vendor told you that would work, but you’ve probably already discovered that it doesn’t (usually).

The approach described is not to create a new tool, however, but to create a social layer on top of existing tools: a mashup of data and functions from a number of sources using X-Folders, which handles feed aggregation and filtering, storage management, and a reaction engine for interacting with external web services. This is not intended for transactional structured workflow, of course, but for evolving lightweight workflow processes between peers. The example shown in the paper used Google Calendar to set up events that represent time-based milestones in a business process, then used a feed from the calendar to an X-Folder so that reactions would be fired when the events occur to call web services to update activities in a discussion forum.

BPM Milan: From a social wiki to a social workflow system

Selim Erol of the Vienna University of Economics and Business Administration presented the first paper of the afternoon, co-authored with Gustaf Neumann, on using wikis in an organizational context, in terms of which aspects may have influence on the success of the implementation. They have also developed a prototype of wiki-based editor for workflow definitions, including enacting a web-based workflow based on the workflow definitions.

He gave a summary of wikis — again, likely unnecessary to an audience of academics who are all presenting papers on BPM and social software — and used Wikipedia as an example of how placing content authoring in an open space (public) ensures critical mass of community, which in turn ensures critical mass of content and artifacts; and how mutual control enables content negotiation and self-healing.

He summarized the characteristics of BPM, then looked at applying wiki characteristics to BPM, particularly in process (and rules) design. He sees a number of aspects that determine the degree to which collective intelligence can be used in a wiki environment:

  • Size of crowd/community participating
  • Level of crowd/community organization
  • Degree of objects’ structuredness/specificity
  • Degree of objects’ completeness

The risks of wiki application are much different in public and enterprise applications, however: in a public domain such as Wikipedia, there are issues such as edit wars and vandalism, whereas in an enterprise environment, the issues are more of lack of subjectivity, domination based on corporate rank, and desertion by the community due to smaller size and more politicized environment.

He gave a brief demonstration of the XoWiki-based workflow system that they have created, providing a wiki environment for specifying process flow collaboratively. It’s still a bit of a code-like interface, although also provides a graphical representation, but it’s great to be seeing process modeling done in a more generalized wiki context. I think that there needs to be more crossover between academia and the vendor world, however: he stated one key differentiator as being that it’s web-based, but a number of BPMS vendors have web-based process modelers now.

BPM Milan: Automating Knowledge Transfer

Michael Granitzer of Know-Centre Graz presented a paper on Automating Knowledge Transfer and Creation in Knowledge Intensive Business Processes, co-authored by Gisela Granitzer, Stefanie Lindstaedt, Andreas Rath also of Know-Center, Klaus Tochtermann of Graz Univeristy of Tecnology, and Wolfgang Groiss of m2n consulting (I know that I’m committing a big faux pas by rearranging the order of the authors, but it seems more logical for me to group them by organization).

The key issue is that the wealth of information about processes and best practices amongst users of systems is often never captured and used to feed back into process documentation or process improvement. Although it’s possible to use wikis and other social software to attempt to collect this information, the authors have devised automated mechanisms for gathering this information through detecting and documenting user interactions and tasks in a knowledge base, which can then be mined and analyzed by a process designer in order to feed back into the global process and its documentation.

The system captures the end-user’s activities (content and context) automatically by detecting events, grouping them into blocks, then into tasks. The task recognition itself is important, since it uses automated predictive classification techniques for recognizing tasks based on the events (now I’m in 1983 in a pattern recognition course 😉 ), and they’re achieving around 75% accuracy in their recognition rates. Note that these are not events and tasks executed in the context of a structured business process in a BPMS, but rather the use of any application available to the user in order to do their work: the web, MS-Office tools, etc. The classification methods were trained, in part, by a period of the users manually tagging their events as specific tasks.

On the mining and analysis side, they looked at process mining techniques such as the ProM framework, and explorative analysis techniques, but I have the sense that they haven’t been quite as successful in automating that side of things.

There are a number of concepts derived from this research, including that of tagging resources with tags, that is, being able to capture knowledge of which users perform which tasks.

They plan to continue on with the research, which will include fine tuning of task detection, and enhancing the classification methods to allow grouping of task groups into processes.

BPM Milan: Social Software for Modeling Business Processes

Agnes Koschmider of the Institute of Applied Informatics and Formal Description Methods (Universitat Karlsruhe) presented the next paper on Social Software for Modeling Business Processes, co-authored by Minseok Song and Hajo Reijers of Eindhoven University.

I’m transported back to 1981, sitting in a graph theory lecture in university: this is a graph theory approach to social networks in order to provide recommendations during process modeling. The technique is for recommending process fragments from a process repository to someone during modeling (where the differences between the process fragments are the people who perform them, not the structure of the process itself): suggesting the performers to assign to a specific process fragment based on the past interactions between those people and the ones already assigned to tasks in the model.

In order to do this, it’s first necessary to derive the social network (graph) between users: how they’re connected based on their past history in process instances, through transfer of work as part of a structure process flow, subcontracting (delegation) of work, and cooperation (how often two performers do the same activity in a process). It’s also possible to derive the social network based on recommendation history. Once the metrics of the social network connectivity are gathered, the distance between each set of performers can be measured using a measurement such as Hamming or Minkowski distance.

Although the underlying mathematics are complex, the idea is to reduce the complexity for the process modeler by providing recommendations on which process fragment in a repository would help to create the most effective process.

Aside from the setting and content, the humor at academic conferences is much different as well: when the use of Petri Nets as a modeling paradigm at one particular university was described as a “political issue”, it got the biggest laugh of the day. 🙂

BPM Milan: BPM with Social Software Systems

The first paper of the day was presented by Petia Wohed of the Department of Computer and Systems Sciences in Stockholm (a joint department between the University of Stockholm and the Royal Institute of Technology), also authored by Paul Johannesson and Birger Andersson, entitled “Business Process Management with Social Software Systems – a New Paradigm for Work Organisation”.

She covered some concepts of social software, and pointed out that a lot of social software allows for interaction and information gathering without specific goals, but that there’s also social software targeted at social production through voluntary contributions by peers in networks, where there are specific goals and artifacts. Although she uses the example of Wikipedia, I think that we need a different example for discussing social production in business: although it’s an accurate model of what we want to create within enterprises, many people don’t consider it a credible resource precisely because it is crowdsourced. Of course, we also need to get many organizations past the concept that knowledge creation has to be dictated from an authority rather than voluntary grass-roots participation; both management and front-line workers are complicit in maintaining this culture. I’m off on a tangent here — something that I probably shouldn’t do extemporaneously while I’m live-blogging a session — but I still see a major issue between capability and culture: social software tools exist to make all this possible, but corporate culture often hinders it.

She discussed the nature of management, and the activities involved in it, then how the mechanism of both BPMS and social software can be used to support management activities. She had a very interesting table showing this alignment, as a lead-in to discussing how social software can be used to complement BPMS (which include new design paradigms for BPM):

  • Design processes with a minimum of control flow: process flow becomes ad hoc, decided on by the knowledge worker responsible for a process instance
  • Embed processes in a social context: show the larger context of the process in terms of other participants and historical process instances
  • Design for low activity threshold: make process tasks fine-grained so that individuals are encouraged to complete them [this seems somewhat counter to the first point, however]
  • Use honor points for rewards: encourage voluntary participation

The whole point of this is moving from an assembly line view of BPM to a work station view, where a knowledge worker takes responsibility for a particular process instance, and decides if and when they need to bring someone else into the process in order to complete it. I believe that the key issues are identifying which processes — or tasks within processes — can most benefit from this new paradigm (some processes, especially those with many automated steps or specific compliance requirements, may be more suited to a more structured process flow), and whether many organizations are ready to adopt these methods.

BPM Milan: Workshop on BPM and Social Software

It’s a holiday weekend back home, and my birthday tomorrow, so some may consider it a bit weird that I’m spending this week away from my family in Milan at a BPM conference. However, I’ve been excited about attending this conference for months since it’s focused on the research that’s happening in the field of BPM, rather than the usual vendor and analyst conferences that I attend. As a prelude to the conference, today is a day of full-day workshops on various BPM topics, and I’m attending the session on BPM and Social Software. I’m still a bit jet-lagged so may not make it through the entire day, but I’ll do my best.

The workshop is chaired by Selmin Nurcan of the University of Paris and Rainer Schmidt of Aalen University, and will consist of discussion of the various research papers contributed by the attendees — in fact, I seem to be one of the few people in the (small) audience who has not contributed a paper.

Before we got into the individual papers, Rainer Schmidt gave an overview of the issues in BPM and social software. I gave a presentation two years ago at the BPMG conference in London on BPM and Web 2.0 (the terms Enterprise 2.0 and social software were just starting to be used back then) that covers some of the same subject matter.

One main concern in BPM today — which I definitely see in practical applications — is the divide between the abstract process models and lifecycles, and the actual executed processes and procedures: in many cases, the process participants ignore some or all of the process model and best practices, and do things as they have in the past. Another concern is that of process improvements not bubbling up from the process participants to the process designers, since there’s a barrier between those who do the work and those who design the work.

Many BPM implementations have been based on strong ties within the enterprise — command-and-control structures with pre-defined methods and channels of communication — and it is these that are hindering the communication between the abstract and the execution in BPM implementations. Weak ties, greatly supported by social software, create alternative methods and channels for these communications, allowing people to more easily exchange ideas; this promotes the “wisdom of the crowd” wherein ideas can come from anywhere in the organization, and small contributions from many people can provide significant value. The concepts of weak ties and the wisdom of the crowd are those upon which social software are built: in the consumer space, think of the weak ties created with your social graph on LinkedIn or Facebook, and the wisdom of the crowd that contributes to efforts such as Wikipedia.

Lots of Tapscott and McAfee references flying around; this is a bit of an intro to social software that’s likely not required for this particular audience, but serves to provide a standard set of definitions of social software. He covered the basic principles, which will be important for seeing how BPM and social software interact: egalitarian; bottom-up; self-organizing; the value of context via tags and links as well as content; continual information improvement and publication for review; the importance of output and practice over abstract models; and transparency regarding the relationship of the participants.

He then moved into how social software supports (or could support) BPM: first, collaboration in the design, implement, evaluation and improvement phases; and second, the extension of functionality for the operational BPM system. Collaboration in the non-operational phases could be through wikis for capturing requirements, planning projects, and so on; in my opinion, this can also be through the use of more collaborative process modeling tools that allow non-experts to be involved in process discovery, modeling and design. During the operational phase, this could be a wiki to capture new requirements and potential process innovation, as well as collaborative tools for managing and documenting the project. Personally, I think that there’s other potential applications: in my presentation two years ago, I suggested the concept of process tagging and folksonomies to allow process participants to tag instances of processes; user-created process-based mashups (although there’s some argument as to whether mashups are considered part of social software) also deserve some discussion here, which are now much more possible since many of the vendors have introduced end-user RSS feeds to their products.

A great introduction to the day, and I’m looking forward to the research papers and discussions.