Tag: BPM2010

Professionalizing BPM: Towards a Common Body of Knowledge for BPM

First up was a paper from QUT and BPTrends on the status of BPM as a profession, and what is required from a body of knowledge (BoK) about process-related information to support process professionals. Although several valuable resources of BPM information exist, none of them provide the complete picture; this research evaluated existing BoKs and established the core list of essential features for developing a more comprehensive BoK for process knowledge.

Related BoKs include the American Society of Quality’s Black Belt BoK and Lean Six Sigma Certification, IIBA’s BABOK, and ABPMP’s BPM CBoK. The research looked in detail at the ABPMP work because it’s most directly targeted at BPM practitioners. However, it has a number of weaknesses that need to be addressed, as indicated by literature review of design science and conceptual modeling, as well as BPM community input. Fundamentally, a BoK should be evaluated on completeness, extendibility, understandability, application and utility; the research found that the ABPMP CBoK lacked critical capabilities in all of these areas.

The challenge, then, is how to create something that does work as a BPM BoK? They propose an empirically-validated, open source body of knowledge, and are welcoming feedback and interest in participation at an initial Process Knowledge BoK website. There are a lot of key skills in developing a BoK, and the paper presents a proposed ontology for what information should be in the BoK and how it could be organized.

I’m involved with the paper authors and a number of other participants in getting a Process Knowledge BoK started up; check the blog post immediately following for more information.

Service Learning and Teaching Foundry: Building a BPM and SOA Education Community

Next up, from the University of New South Wales, is a paper on a BPM and SOA education community for an industry-relevant curriculum. This was motivated by student feedback on what started as a web application engineering course, and now covers a range of service orientation topics including business process modeling. The plan is to develop a service learning and teaching foundry as a community spanning multiple skill levels and multiple learning institutions.

The core of the foundry includes an information model of the areas of study, with resources such as use cases, sample web services, tutorials, assignments and programming exercises built on that core. It also contains a sandbox and demo environment, plus an access layer with a browser interface and an API for building the content into other applications.

The services technologies module of the learning and teaching foundry was developed as the base for a specific course offered at UNSW, including all of the materials needed for lectures, labs and assignments. This includes not just the materials to be provided to the students, but supporting elements such as event processing services that they can use in the completion of their assignments. This environment allows them to easily have lab exercises that build on previous exercises.

They’re using an open forum for collecting feedback on the course on an ongoing basis, using a “wiki/blog style” (not sure which) rather than just course evaluations at the end of the semester. You can check out the website here.

I skipped the last paper because the session was running a bit late and I wanted to get over to Keith Swenson’s fireside chat – more from there.

The first research session this afternoon was on BPM in practice, looking at what people are actually doing with BPM.

How Novices Model Business Processes

I missed the first paper in this section, but arrived just in time for the presentation from Queensland University of Technology on how people who have no prior knowledge of formal process modeling techniques actually create process models.

Conveniently, they had a well-controlled group of research subjects: new students in the process modeling course. They looked at the students’ prior experience in modeling methodology, knowledge of the business domain and drawing skills, with the goal to correlate that with the diagram classification (i.e., what type of diagram that they drew) and semantic correctness of diagrams. Their diagram classification ranged across five basic types of design from pure textual descriptions to purely graphical representation; most commonly used was a classical flowchart design (type 2), with boxes annotated with text, connected by arrows, but there were also hybrid designs that added graphics to standard flowcharts, as well as storyboard styles (type 4). In some cases, they overlaid additional information, such as a flowchart of activities with a timeline plotted beneath it.

They did find some prior knowledge factors that could predict the most likely design type used by an individual: low levels of object-oriented model knowledge predicted a preference for storyboard-style design, whereas high levels of previous domain knowledge was more likely to result in a flowchart-style design. Design quality, that is, semantic correctness of the model, was correlated with design type and previous domain knowledge. Personally, I’d like to see the correlation with the students’ Myers-Briggs scores.

Considering the debates going on now about the need for flowcharting, and by extension, BPMN and other modeling notations, I find it interesting that the most common design style that students use without any prior process modeling experience is the flowchart. However, they see a more graphical and free-form representation as possibly also adding value, considering that a rigid notation such as BPMN might restrict creativity in process modeling.

IT Requirements of BPM in Practice – An Empirical Study

The last paper in this section, from the University of Bern, looked at the link between low BPM maturity rates within organizations and the inability of currently BPM tools to meet the key requirements of those organizations.

They conducted a survey of 130 companies across various industry sectors within the Forbes Global 2000 list, asking questions about their business processes, the related applications used for managing processes, and the process scope and duration. They also asked how (e.g., text versus graphical modeling notation) and why (e.g., compliance) they documented their processes; interestingly, more than a third were documented as text, 20% as tables, and about 30% combined for all process-specific modeling languages.

The use of BPM tools is a prerequisite for reaching the highest level of BPM maturity, so the survey also contained questions on the importance of specific capabilities of a BPM tool; the most important factor was supporting (manual) task execution, with automation of tasks coming in at #4. Most companies are still using Visio and Word [and based on my experience, probably PowerPoint as well] to document their processes; the first BPM tool (ARIS) doesn’t appear until #4 on the list.

Relating this back to the BPMM maturity levels, process documentation is critical in moving from level 2 to level 3, with textual descriptions indicating a lower maturity level than graphical models; most of the companies surveyed are still at level 2, but are in a position to transition to level 3. Using some sort of BPM execution software – whether a dedicated BPM system, an ERP system or something else – is critical to reaching level 4.

Getting back to the capabilities of the BPM tools and how this impacts maturity levels, they found that both usability of the tools and software integration requirements were not satisfied by the current crop of BPM tools. At the point that this paper was written, the details of those unsatisfied requirements were not fully established; this can be expected in their future research.

The afternoon session of research papers focused on people and processes.

From People to Services to UI: Distributed Orchestration of User Interfaces

The first paper, from University of Trento and Huawei Technologies, focused on a model for distributed user interfaces, bringing together people, web services and UIs in a single tool, rather than developing process models and UIs independently. They consider UI components (effectively a widget) as objects representing process state; changes in the UI will cause underlying process services to be invoked, and changes in the underlying process/data will change the UI representation.

The goal is to bring together the needs of UI synchronization and service orchestration into a single language, even though UIs are event-based and services are invoked as part of control flows, and the don’t typically speak the same language. To do this, they extended BPEL to create BPEL4UI, which is the standard business process execution language with UI-specific modeling constructs. This manifests as a three new basic object types: pages, actors and UI components. They extended a BPEL Eclipse plug-in to included these new object types, allowing the UI to modeled as part of the BPEL process model, and added hooks so that the BPEL engine calls a UI engine server rather than the UI directly.

Other solutions tend to focus on either one or two of services, UI support and people; the tool that they have built, MarcoFlow, supports all three in a unified environment.

A Collaborative Approach to Maturing Process-Related Knowledge

The second paper, from SAP Research and University of Applied Sciences Northwestern Switzerland, introduced an approach for supporting knowledge workers in sharing process-related knowledge using a hybrid between a top-down process model and a bottom-up “wisdom of the crowds” for capturing work practices in process models.

A predefined process model provides a context for experience sharing, allowing people to collaborate around tasks in the process by creating “task patterns” that include descriptions of shared experiences in executing that task, and the related resources such as documents or links. Others executing that same task can access the associated task pattern to see what other people did in the same situation in the past, including problem and solution scenarios. The task pattern content is stored in MediaWiki, and linked directly to the execution environment for a task (although it doesn’t go as far as one of the social software workshop participants recommended yesterday in integrating the collaborative feedback directly into the execution environment).

Currently, all of the information in the task pattern is entered manually, but in response to an audience question, he said that they are looking at adding process analysis that can include more automated process intelligence and mining data as well.

Self-adjusting Recommendations for People-driven Ad-hoc Processes

The last paper of the session, from Vienna University of Technology and German Research Center for Artificial Intelligence, looked at providing guidance to a user in ad hoc workflows, allowing for the exploitation of best practices while still allowing individual flexibility. By flexibility, they specifically mean the ability to adapt a process flow on the fly by adding, skipping or re-ordering process steps. As in the previous presentation, they noted that processes may be based on pre-defined process models or crowdsourced best practices, but rarely both. In some cases, personalized recommendations can be beneficial to a specific user at a relatively high skill level, representing their personal best practices and high degree of flexibility that may not be suited for the general population of users. Crowd-based recommendations, however, may be more useful for less skilled users doing more general work who need to follow overall best practices in order to ensure process quality and efficiency.

Comparing the actual actions of a user relative to the recommendation establishes and reinforces their classification as either Eagle (expert user with personalized recommendations and work methods) or Flock (follows crowd-based recommendations for best practices); an Eagle will be reset to the middle of the classification if there is a repeatedly high error rate, and from there will migrate either back to Eagle or to Flock, depending on their behavior. A Flock user may migrate to Eagle over time as they become more skilled, or may stay as Flock based on their performance.

The prototype was not in a standard BPM system, but an overlay on email exchanges, intercepting and analyzing message traffic to detect process steps. An initial simple sequential process is modeled – and later refined by the user actions – and when the system recognizes that these steps are occurring in the email traffic, it pops up the process recommendations and tracks the user’s actual actions.

The research sessions have started here at BPM 2010, and I’m in the session of research papers on business process design. There are three 30-minute presentations (including Q&A) based on the presenter’s research paper; although I have the full text of the research papers, it’s always useful to hear the author’s take on it.

I haven’t listed all the author names on the presentations, but you can find the full list on the conference site’s research program section.

From Informal Process Diagrams To Formal Process Models

This paper from IBM Research (in India and the US) presents an approach for automatically converting informal process diagrams – such as are done in Visio – to formal process models that can be managed in a BPMS. This requires two main tasks: inference of the structure, that is, identifying the nodes and edges, and semantic interpretation to associate process modeling semantics.

Information process diagrams contain a lot of structural and semantic ambiguities that have to be resolved. Most of the existing process modeling tools use shape names to interpret the semantics when importing Visio diagrams, but often untrained process modelers will use a variety of shapes to mean a single element type, or use the same shape for multiple element types.

The authors use standard pattern classification techniques to interpret the process semantics, mimicking human reasoning and testing with both supervised and unsupervised clustering. They’ve created a tool, iDiscover, and compared it to a popular modeling tool’s Visio import capability to see which did a better job of inferring the formal process model from 185 process diagrams found in practice. Overall, their supervised classification method achieved rates over 90%, whereas the other modeling tool was in the 60% range.

Given that a lot of people will continue to use Visio to do their original process diagrams, no matter how many nice process discovery tools we give them, this can have a clear benefit in reducing translation errors and reducing the time required to manually correct the formal process models after translation.

Machine-Assisted Design of Business Process Models Using Descriptor Space Analysis

The next paper, from Technion and Ort Braude College in Israel, presented a method for assisting a process analyst to design new processes based on an analysis of existing process models within an organization. Linguistic analysis of relationships within processes allows several models to be developed based on the objects and actions within existing processes: an object hierarchy model, an object lifecycle model, an action hierarchy model and action lifecycle model. Insert some fancy mathematics on the resulting quad-dimensional descriptor space, and you end up with a system that can either refine an existing activity (e.g., a more or less specific form of an object or action) or suggest a next process step (e.g., an action-object pair), depending on the context. This allows a process designer to be led through the design of a completely new process using a wizard-like interface where the designer can specify the goal of the process, then be presented with suggested objects and actions as they step through refinements to the process.

Assuming that the existing process models cover a broad range of an organization’s typical objects and activities, and that new processes are typically similar in some way to existing processes, it makes sense that you’d be able to present a designer with something close to what they want; the key is in minimizing the number of refinements they would have to apply to the suggestions. Their experiments showed that this method required stepping through a number of refinement steps in order to achieve accurate models; their conclusion is that this is a useful starting point, but needs further research and experimentation for real-world business usage.

Impact of Granularity on Adjustment Behavior in Adaptive Reuse of Business Process Models

The last paper of this session, from Technische Universität Berlin, looked at the reuse of process models. Cognitive biases tend to limit our ability to adjust processes if that involves certain anchoring activities; the granularity of process models will have an impact on how many of those anchors are present. Completely logical: if you have a very high-level process model, it’s more likely to be able to be applied to a number of different real-world processes (although it may be of questionable value), whereas a more detailed process model will contain activities that tie it to a smaller number of real-world processes.

Their experiments showed that the granularity of a model has a significant impact on the percentage of correct adjustments when reusing a model, with more granular models resulting in more extraneous tasks being left in even though they may not apply to the target real-world process. In other words, if a designer takes a detailed process model as the starting point for a new process model, they are more likely to leave in a lot of unnecessary crap, which makes it harder to read the model as well as making it potentially inaccurate.

Good first session; over in the industry case studies track, there was a session on BPM in practice, featuring Nick Malik of Microsoft (which I was sorry to miss since I am an avid reader of his blog on enterprise architecture), Adelle Elia and Sandra Lyons of GTSI, and Paul Tazbaz of Wells Fargo.

I’m on my way to Hoboken, New Jersey for what has become my favorite BPM conference of the year: BPM 2010, which is a conference on what’s happening in BPM research, both in academia and private research labs. If you want a view of what’s coming in BPM in the next five years, this is the place for you; BPM vendors should definitely be sending their product designers and architects to hear (or present) ideas, and maybe even find a bright young Ph.D. student for cooperative research.

Hope to see you there.