Skip to content

{ Category Archives } BPA

IBM FileNet P8 BPM V4.5

I’ve had a couple of briefings on the 4.5 release of IBM/FileNet P8 BPM, which was released in November but is likely just starting to hit customer sites so I thought that it would be good timing for a review post. As a point of disclosure, I worked for FileNet in 2000-1 and have worked with their BPM software extensively in two of my own companies including my current consulting practice, but I don’t do any work for IBM, only for their customers. That means that I am probably more familiar with their system than with any other BPMS, but they are not compensating me in any way for this post (they don’t even cover analyst/bloggers expenses to attend their user conferences, so I don’t) nor do they have any editorial control, which means that I will likely manage to say something to annoy IBM management here, as I usually do.

I’ve blogged in the past about the IBM-FileNet acquisition, specifically my comments at the time that the acquisition was announced, at an analyst briefing just after that, then a follow-up last June comparing it to the Oracle-BEA acquisition: in brief, I noted the transition in product positioning from that of a full BPMS product to document-centric BPMS so as not to compete with WebSphere Process Server. I still think that both IBM and its customers would have been better served by ripping BPM out of the P8 product line and adding it to WebSphere to round out the human-facing capabilities, producing a single BPMS product at IBM. Instead, if a customer wants both human-centric functionality and services orchestration, IBM will be in there selling them two products – each with their own modeling, execution and monitoring environments – rather than one, which is going to be a bit of a hard sell in this economy. They’re working to bring some of that together, but fundamentally it’s still two products to do what many other vendors do with one. There are a few point of integration now — the WebSphere modeler can export FileNet-compliant XPDL, and the WebSphere monitoring tools can monitor the FileNet process engine – and they’ll be doing a bit more cosmetic integration to make it more palatable, but there’s no plan for a unified execution engine. Strangely, the recent Gartner report on BPMS doesn’t both to distinguish them: it bases its analysis on the combination of WebSphere Dynamic Process Edition and FileNet Active Content Edition, which is a bit bogus (in my opinion).

That being said, the current positioning of FileNet P8 BPM is around “agile ECM”, with active content being a key differentiator. Active content, in the FileNet world, is the ability to capture content events (such as creation and versioning) and trigger activities in response, either launching new process instances in BPM, or making external calls. If you’re proficient with the FileNet BPM design tools, that means that you can create a new process, link it via a workflow subscription to the events occurring on a class of content, and have that process automatically trigger when that event occurs for a document in that class. In my world of back-office transaction processing, where there is still a lot of paper, this could be the creation of a process instance in response to a new scanned document being added to the content repository, all without writing a line of code.

IBM FileNet P8 BPM 4.5There’s more to their agile message than active content, however: IBM is also bundling in a new set of BPM widgets and the IBM (Lotus) Mashup Center to allow for the much easier creation of user interfaces. This has always been a problem in the past: although the Process Designer will auto-generate a user interface for each step that allows for view and update of the parameters exposed at that step, it’s not very pretty. The options were to use the FileNet e-forms product – which required some technical fiddling to integrate – or create custom interfaces using some other development tools. Although the widgets don’t provide a fully-customizable forms interface, they do provide a way to put together configurable user screens that work well for prototyping and for some lighter-weight/tactical production applications.

I liked what I saw with the widgets, despite the limitations, since I think that it’s a move in the right direction. They use the iWidget specification, which is an open standard created by IBM and used natively in the Mashup Center, and there’s also a wrapper to turn an iWidget widget into a JSR-168 compliant portlet, with the cross-widget wiring exposed, for use in other environments such as the WebSphere portal product. The BPM widgets are built using the new REST services that wrap around the process engine Java API; you can also call the REST services directly from other application development environments. Although the widgets are referred to as “ECM widgets” in the IBM documentation, they all (with the exception of a document viewer widget) provide BPM functionality. There’s a lot more that I saw about the widgets; I might do a separate post just on that for those who are evaluating this product.

Some partners are also creating widgets for the mashup framework; I can see this as a key way for partners to add value through providing interoperable components rather than monolithic applications, and I would hope to see some of these emerging for free as companies try out this new technology.

There’s no requirement for all-or-nothing with the mashups, either: each step in the process can invoke a different UI from a different source, so that one step might have a custom application, another an e-form and another a mashup. As far as the process is concerned, that’s just what is invoked at the step to manage the user interaction, not an integral part of the process.

One issue is that WebSphere Business Space will replace Mashup Center as the mashup environment included with P8 BPM, although it’s not clear what degree of functional overlap there is, or when to use one versus the other. The Mashup Center appears to be positioned as being for prototyping and tactical situational applications, whereas Business Space is more of an enterprise portal, but it’s not clear that you couldn’t build an enterprise-strength application using the Mashup Center (unless you’re afraid that IT will laugh at you for using the words “mashup” and “enterprise” in the same sentence). Business Space supports the ECM widgets, but would require a few “minor functional changes” (IBM’s words) to get things working.

FileNet BPM Process DesignerOn the process modeling side, the Process Designer now has two modes: diagram mode for business analysts, and design mode for technical analysts, with user access rights determining which that a specific user can access. In diagram mode, the user draws the process map, adds the description and instructions at each step, and a description for each route between steps. Design mode is the full “classic” view, with all parameters visible, where a developer can take the description entered by the business analyst and map that into parameters, rules, assignments, deadlines and web services calls. However, the Designer still is not BPMN compliant: if you want BPMN, you can do it in Visio with a BPMN template that they provide, then import the results into the Designer, but it’s a one-way trip. They do plan to leverage some of what’s been done with BPMN in the WebSphere process modeler to bring that into the P8 BPM designer, but there’s nothing concrete to talk about yet.

There’s also some new user roles functionality built in to the designer (and runtime, obviously) that is based on the Business Process Framework, an add-on product to BPM used for creating case management processes. I suspect that we’ll see more of the useful bits of BPF integrated into the core BPM product in the coming releases, to the point where it won’t exist as a separate product, although no one at IBM said that.

Simulation is now web-based and integrated within the process designer, rather than being a separate application: one of the tabs in the design view of a process is Simulation, which allows durations for steps and weights (%) for routes to be entered. Configuration and administration is also now done within the process designer rather than in a separate configuration console.

For business rules, ILOG (a recent IBM acquisition) is being integrated into the WebSphere suite; since it provides a web services interface, it can easily be called at a step in a BPM process for adding business rules more complex than can be handled by the built-in expression engine in BPM.

The BAM product integrated into the P8 BPM product line is also now IBM: originally it was Celequest, which was acquired by Cognos, which was in turn acquired by IBM; the branding on the last set of product slides that I saw is “Cognos Now”.

IBM is starting to push Lotus Forms with BPM, although it is not yet integrated to the same degree as FileNet eForms, which can replace the user interface at a step in a process. I can’t believe that IBM will maintain two e-forms products in the long run, but they can’t really cut off FileNet eForms until they complete that integration.

Overall, FileNet’s legacy of content and process together has grown into fully-featured document-centric BPM capability. Unfortunately, they positioned themselves as pure-play BPMS just long enough to get some customers on that bandwagon, leaving those customers with some uncomfortable migration decisions in their future.

2009 03 05 Sandy Kemsley BPM
ECM
mashups Comments (4)

Contextware for process documentation

I’ve had a look at Contextware previously, but yesterday had a chance to talk in depth with David Austin, the president and COO, and see a demo of their current product. Contextware can be described as a a process documentation tool, although it’s also being used as a process discovery tool, but it’s more than just a static document of your operational procedures: for each step in a process, it displays a narrative that might include context or instructions, plus links to various resources including content, applications, and people. You capture processes in Contextware for the purpose of communication and training, not automation; it doesn’t automate processes in any way, but might be combined with a BPMS in order to provide instructions for complex human steps in the process.

There a couple of key use cases for this sort of process documentation, whether you’re doing it for completely manual processes or for the human steps in a BPMS:

  1. You need to capture information from those aging boomer knowledge workers (who will be retiring as soon as the stock market comes back up), since many of the manual processes exist only in their heads.
  2. You want to standardize processes across the organization, and need to provide operational procedures documentation for those processes.

Contextware - Author Steps and NarrativeThere is no automated capture of information: you have to lay the process out step by step, but it’s done in a simple hierarchical list format where you create a list of the main steps, then can add sub-steps to any step as an indented sub-list, and so on. Then, for each step/sub-step, you add the narrative and link up the assets from the list of available resources. Assets linked to a step are inherited by its sub-steps, and can be kept, discarded or a subtype created during the authoring process.

Assets can be predefined — these are in a common repository that can be reused by any process — or defined and saved to the repository on the fly. Content such as documents are typically not stored in Contextware: the asset is actually metadata pointing to external content via a URL or URI, which allows the author to set a meaningful name for the asset that is shared wherever that asset is used within any process. Although it’s common for organizations to have samples and procedural documentation online somewhere on their intranet, this removes the process of hunting for the file or page since it’s linked directly to the step in the process where it’s required.

The resources are a sort of extended IDEF model with six dimensions, and the author can suppress the display of any of them:

  • Inputs (often suppressed), which may link to content or to a system depending on the context
  • Guidelines: additional procedural documentation
  • Content: typically samples
  • People, which allows for a mailto: link to directly create an email
  • Tools, providing links to invoke systems and executables, or describe offline resources or tools
  • Outputs (often suppressed)

There’s no auto-login or single sign-on for any of the systems that are linked from resources (e.g., content management, email, line of business applications): these are just links to launch the appropriate application or content, and the user is responsible for doing the login themselves on the invoked application if they’re not already logged in.

I’m not sure that I completely understand the role of inputs and outputs in the resource list; it might be stretching the IDEF metaphor a bit too much (and for little purpose these days, when many people don’t know what IDEF is).

An author can clone an existing process to start a new design and there’s some lightweight versioning and roll-back capabilities for managing the processes. It’s also possible to call one process (or subprocess) from another by listing it as an asset in the resources.

Contextware - Step Narrative and ResourcesThe end users select their group/department from a list, then their process, then select the step that they’re working on (or expand the step hierarchy and click on a sub-step) to see the narrative and the list of resources available. Clicking on a resource for that step in the right-hand panel will invoke the URL or URI that’s specified for the resource: it could be a link to a web page or document, an executable desktop application, or a mailto: link for a person. The text in the center panel changes depending on which step or which resource that they’ve selected. Users can also add comments to a step via a context-sensitive “bulletin board” at each step, providing a bit of a wiki-like experience to capture the users’ feedback directly in the context of the process, although they can’t change the main narrative.

Users are not constrained to follow the steps in order; they can see the entire hierarchy and select any step that they need, since this is process documentation and doesn’t actually drive their work. In fact, this could be used as a contextual help system without regard to a process, organizing the help topics in the hierarchy on the left and attaching narrative and assets to each topic and subtopic.

Both authors and end users can search on processes and metadata to locate a specific process or resource.

An audit (management) function shows who has accessed which processes, which allows a manager to tell if someone has accessed a new process after it has been rolled out. Since this can be considered training material, the manager is basically checking to see if everyone did their homework and understands the new process.

Both the authoring and end-user environment are completely web-based with a rich AJAX interface, so no desktop installation. We didn’t talk about what’s lurking on the server side of this, but their website lists the operating systems, database, application servers and web servers supported. Their site also talks about delivering content to mobile devices, but we didn’t discuss that.

There’s an obvious play in the training space and for documentation of manual processes, but Contextware would also like to see how they can put this together with some of the BPMS products in order to provide additional documentation for human-facing steps in cases where it’s difficult to build that into the BPMS user interface itself. I also believe that they need to focus on importing from some of the BPA tools, such as ARIS and Mega: although the process model is only a starting point for Contextware, it would be helpful to have that starting point in the case of large complex processes with a lot of manual steps. Of course, this may start to conflict with what some of the BPA vendors are trying to do in terms of process documentation, but I think that most of them are really focused on showing the business processes rather than providing complete operational procedures. I also see potential for integration with a process discovery tool such as Process Master, although there might be too much overlap in functionality.

There needs to be much better management of screen real estate as well: this product smacks of developers with huge dual monitor setups who don’t realize that the average underwriter in an insurance company works on a single 800×600 15″ screen. I suggested that they be able to minimize to some sort of floating widget (which could be difficult considering that they’re web-based, but hey, that’s what Adobe AIR and Google Gadgets are for, right?) that the user could float their mouse over to pop up the narrative and resources, and click to the next step. Otherwise, you’d be trying to deploy this on a screen where the user has to constantly flip back and forth between Contextware as their procedural guide and their actual applications. Printing would ensue.

They also need to do a bit more with versioning of processes, where a process could be modified and tested by a specific group of people, then promoted to the production version. In the current system, you’d clone the process (and therefore have to use ad hoc naming conventions to indicate that this was a new version of the older process), make the changes, and release selectively by security groups in order to promote through test and production. Contextware - DollyOnce in production, the users of the old process would have to be notified to start using the new process documentation.

One final criticism about the cutesy interface icons: using a graphic of a sheep (think Dolly) to clone a process just doesn’t cut it for me.

2008 12 03 Sandy Kemsley BPM Comments (1)

Survey on business process modeling

Three universities with BPM programs — Humboldt University, Eindhoven University of Technology and the Queensland University of Technology — are running a survey on how business process models can be improved in terms of understandability. You can take the survey here, although it’s specifically for those who model using event-driven process chains (EPC). As a participant, you’ll have access to the results of the survey, plus the chance to win a recently-released book, Metrics for Process Models.

2008 11 23 Sandy Kemsley Comments (1)

Ultimus: Process optimization

Chris Adams is back to talk to us about process optimization, both as a concept and in the context of the Ultimus tools available to assist with this. I’m a bit surprised with the tone/content of this presentation, in which Chris is explaining why you need to optimize processes; I would have thought that anyone who has bought a BPMS probably gets the need for process optimization.

The strategies that they support:

  • Classic: updating your process and republishing it without changing work in progress
  • Iterative: focused and more specific changes updating live process instances
  • Situational/temporary: managers changing the runtime logic (really, the thresholds applied using rules) in live processes, such as changing an approval threshold during a month-end volume increase
  • Round-trip optimization: comparing live data against modeling result sets in simulation

There’s a number of tools for optimizing and updating processes:

  • Ultimus Director, allowing a business manager to change the rules in active processes
  • Studio Client, the main process design environment, which allows for versioning each artifact of a process; it also allows changes to be published back to update work in progress
  • iBAM, providing visibility into work in progress; it’s a generic dashboarding tool that can also be used for visualization of other data sets, not just Ultimus BPM instance data

He finished up with some best practices:

  • Make small optimizations to the process and update often, particularly because Ultimus allows for the easy upgrade of existing process instances
  • Use Ultimus Director to get notifications of
  • Use Ultimus iBAM interactive dials to allow executives to make temporary changes to rule thresholds that impact process flow

There was a great question from the audience about the use of engineering systems methodology in process optimization, such as theory of constraints; I don’t think that most of the vendors are addressing this explicitly, although the ideas are creeping into some of the more sophisticated simulation product.

2008 10 23 Sandy Kemsley BAM
BI
Ultimus Comments (1)

Appian Forum: MEGA Partnership

Terry Lee, MEGA’s VP of North American operations, gave us an overview of MEGA, both in terms of their business process analysis and enterprise architecture capabilities. He stated the real reason for using a BPA tool, rather than just the modeling environment within the BPMS, is the ability to analyze the processes within a larger context: relative to risk analysis, enterprise architecture, and corporate performance management.

A process is analyzed and some level of design is completed in MEGA, then the process is handed off to Appian through a manual export/import for further work in their process designer — no mention of round-tripping, although I happened to be sitting beside Dan Hebda (MEGA’s VP of technology) and passed him a note asking about this. He replied that round-tripping would be supported, but isn’t in the current prototype that they’re demonstrating here at the conference. I have a meeting with Dan tomorrow at Gartner, where I’m sure to get a lot more information on this, and Terry summed at the end of his presentation by mentioning that the future integration would include round-tripping.

Metrics for the executing process are captured using the MEGA Advisor and fed back to the models in MEGA to allow for process analysis and optimization.

I believe that there’s a lot of benefit for many organizations in using a BPA tool such as MEGA for modeling processes — especially the portions of processes that are not automated, hence may not be represented in the process models within a BPMS — and the larger enterprise architecture context. For success, however, this requires two key areas of integration: a seamless bidirectional exchange of process models, and the ability to load executing process logging data back into the BPA. It appears that Appian and MEGA are working hard to achieve both of these.

Tagged ,
2008 09 09 Sandy Kemsley AppianForum
EA Comments (2)

BPM Milan: Diagnosing Differences between Business Process Models

Remco Dijkman of the Technical of Technology of Eindhoven presented a paper on Diagnosing Differences between Business Process Models, focusing on behavioral differences rather than the structural differences that were examined in the previous paper by IBM. The problem is the same: there are two process models, likely two versions of the same model, and there is a need to detect and characterize the differences between them.

He developed a taxonomy of differences between processes, both from similar processes in practice and from completed trace inequivalences. This includes skipped functions, different conditions (gateway type with same number of paths traversed), additional conditions (gateway conditions with a potentially larger number of paths traversed), additional start condition, different dependencies, and iterative versus once-off.

You can tell it’s getting near the end of the day — my posts are getting shorter and shorter — and we have only a panel left to finish off.

2008 09 03 Sandy Kemsley IntlBPM Comments (2)

BPM Milan: Detecting and Resolving Process Model Differences

Jochen Kuester of IBM Zurich Research presented a paper on Detecting and Resolving Process Model Differences in the Absence of a Change Log, co-authored by Christian Gerth, Alexander Foerster and Gregor Engels. Detecting differences would be done in the case where a process model is changed, and there is a need to detect and resolve the differences between the models. They focus on detection, visualization and resolution of differences between the process models.

Detection of differences between process model, which involves reconstructing the change log that transforms one version to another. This is done by computing fragments for the process models similar to the process structure tree methods that we saw from other IBM researches yesterday, then identifying elements that are identical in both models (even if in a different part of the model), elements that are in the first model but not the second, and those that are in the second model but not the first. This allows correspondences to be derived for the fragments in the process structure tree. From there, they can detect differences in actions/fragments, whether an insertion, deletion or move of an action within or between fragments.

They have a grammar of compound operations describing these differences, which can now be used to create a change log by creating a joint process structure tree formed by combining the process structure tree of both models, tagging the nodes with the operations, and determining the position parameters of each of the operations.

They’ve prototyped this in IBM WebSphere Process Modeler.

2008 09 03 Sandy Kemsley IntlBPM Comments (0)

BPM Milan: Workflow Simulation for Operational Decision Support

The afternoon started with the section on Quantitative Analysis, beginning with a presentation by Anne Rozinat from the Technical University of Eindhoven on Workfow Simulation for Operational Decision Support Using Design, Historic and State Information, with the paper co-authored by Moe Wynn, Wil van der Aalst, Arthur ter Hofstede and Colin Fidge.

As she points out, few organizations are using simulation in a structured and organized way; I’ve definitely seen this in practice, where process simulation is used much more during the sales demo than in the customer implementations. She sees three issues with how simulation is done now: resources are modeled incorrectly, simulation models may have to be created from scratch, and there is more of a focus on design than on operational decisions through lack of integration of historical operational data back into the model. I am seeing these last two problems solved in many commercial systems already: rarely is it necessary to separately model the simulation from the process model, and some number of modeling systems allow for the reintegration of historical execution data to drive the simulation.

Their approach uses three types of information:

  • design information, from the original process model
  • historic information, from historical execution data
  • state information, from currently executed workflows, primarily for setting the initial state of the simulation

They have created a prototype of this using YAWL and ProM, and she walked through the specifics of how this information is extracted from the systems, how the simulation model is generated, and how the current state is loaded without changing the simulation model: this latter step can happen often in order to create a new starting point for the simulation that corresponds to the current state in the operational system.

This last factor has the potential to turn simulation into a much more interactive and frequently-used capability, if you consider the capability of being able to run a simulation forward from the current state in the operational system in order to predict behavior over the upcoming period of time: consider, for example, being able to use the current state as the initial properties of the simulation, then adding resources to predict how long it will take to clear the actual backlog of work in order to determine the optimal number of people to add to a process at this point in time. This turns short-term simulation into a operational decision-making tool, rather than just a design tool.

2008 09 03 Sandy Kemsley BPM
IntlBPM Comments (1)

BPM Milan: Setting Temporal Constraints in Scientific Workflows

Xiao Liu from Swinburne University of Technology presented his paper on A Probabilistic Strategy for Setting Temporal Constraints in Scientific Workflows, co-authored by Jinjun Chen and Yun Yang. This is motivated by the problem of using only a few overall user-specified temporal constraints on a process without considering system performance and issues of local fine-grained control: this can result in frequent temporal variations and huge exception-handling costs.

They established two basic requirements temporal constraints must allow for both coarse-grained and fine-grained control, and they must consider both user requirements and system performance. They used some probabilistic assumptions, such as normal distributions of activity durations. They determined the weighted joint normal distribution that estimated the overall completion time of the entire workflow based on the time required for each activity, the probability of iterations and the probability of different choice paths: assuming the normal distributes of events as earlier stated, this allows for the calculation of maximum and minimum duration from the mean by assuming that almost all process instance durations will be bounded by +/- 3 sigma (sorry, can’t find the sigma symbol right now). After aggregating to set the coarse-grained temporal constraints, they can propagate to set the fine-grained temporal constraints on each activity. There are modifications to the models if, for example, it’s known that there is not a normal distribution of activity durations.

This becomes relevant in practice when you consider setting service level agreements (SLAs) for processes: if you don’t have a good idea of how long a process is going to take and the variability from the mean, then you can’t set a reasonable SLA for that process. In cases where a violation of an SLA impacts a company financially, either immediately through compliance penalties or in the longer term through loss of revenue, this is particularly important.

2008 09 03 Sandy Kemsley IntlBPM
compliance Comments (0)

BPM Milan: Instantiation Semantics for Process Models

Jan Mendling of Queensland University of Technology presented a paper on Instantiation Semantics for Process Models, co-authored with Gero Decker of HPI Potsdam. Their main focus was on determining the soundness of process models, particularly based on the entry points to processes.

They considered six different process notations and syntax: open workflow nets, YAWL, event-driven process chains, BPEL (the code, not a graphical representation), UML activity diagrams, and BPMN. They determined how an entry point is represented in each of these notations, with three different types of entry points: a start place (such as in open workflow nets), a start event (such as in BPMN), and a start condition (such as in event-driven process chains). He walked through a generic process execution environment, showing the entry points to process execution.

They created a framework called CASU: Creation (what triggers a new process instance), Activation (which of the multiple entry points are activated on creation), Subscription (which other start events are waited for upon the triggering of one start event), and Unsubscription (how long are the other start events waited for). Each of these four activities has several possible patterns, e.g., Creation can be based on a single condition, multiple events, or other patterns of events.

The CASU framework allows for the classification of the instantiation semantics of different modeling languages; he showed a classification table that evaluated each of the six process notations against the 5 Creation patterns, 5 Activation patterns, 3 Subscription patterns and 5 Unsubscription patterns, showing how well each notation supports each pattern. One important note is that BPEL and BPMN do not support the same patterns, meaning that there is not a 100% mapping between BPMN and BPEL: we all knew that, but it’s nice to see more research backing it up. :)

Having multiple start events in a process causes all sorts of problems in terms of understandability and soundness, and he doesn’t recommend this in general; however, since the notations support it and therefore it can be done in practice, analysis of multi-start point instantiation semantics is important to understand how the different modeling languages handle these situations.

2008 09 03 Sandy Kemsley BPM standards
IntlBPM Comments (1)

BPM Milan: Predicting Coupling of Object-Centric Business Process Implementations

Ksenia Wahler of the IBM Zurich Research lab presented the first paper in the Modelling Paradigms & Issues section, on Predicting Coupling of Object-Centric Business Process Implementations, co-authored by Jochen Kuester.

Although activity-centric approaches are in the mainstream — e.g., BPMN for modeling and BPEL for implementation — object-centric approaches are emerging. The main principles of object-centric approaches are that process logic is distributed among concurrently running components, each component represents a life cycle of a particular object, component interaction ensures that overall logic is correctly implemented.

They are using Business State Machines (BSM) in IBM WebSphere Integration Developer to model this: object-centric modeling is offered as an alternative to BPEL for service orchestration. It uses finite state automation, tailored for execution in a service-oriented environment, with event-condition-action transitions. The advantages of this approach is that it is distributable, adaptable, and maintainable. However, this works when objects are independent, but this is rarely the case; hence the research into the management of coupling of objects. What they found is that rather than using a unidirectional mapping from the activity-centric view to the object-centric implementation, wherein the models can get out of sync, their approach is to feed back from any changes in the object-centric implementation to the process model. They needed to establish a coupling metric in order to asses the coupling density of the object model, as well as develop the mapping from activity-centric process models to object life cycle components, which they have based on workflow patterns.

She showed examples of translation from activity-centric to object-centric models: starting with a BPMN process model, consider the objects for which each activity is changing the state, and re-model to show the state changes for each object and the interactions between the objects based on their state changes. Each state-changing object becomes a component, and interactions between objects in terms of control handovers and decision notifications become wires (connections) between components in the assembly model. The degree of coupling is calculated from the interactions between the components, and a threshold can be set for the maximum acceptable degree of coupling. Objects with a high degree of coupling may be candidates for merging into a single life cycle, or may be targeted for refactoring (actually not true refactoring since it doesn’t preserve behavior; more like simplifying) the process model in order to reduce control handovers and decision notifications.

This type of object-centric approach is new to me, and although it is starting to make sense, I’m not sure that these notes will make sense to anyone else. It’s not clear (and the speaker couldn’t really clarify) the benefit of using this approach over an activity-centric approach.

2008 09 03 Sandy Kemsley IntlBPM Comments (0)

BPM Milan: Refined Process Structure Tree

Jussi Vanhatalo of the IBM Zurich Research Lab presented a paper on the Refined Process Structure Tree, co-authored by Hagen Voelzer and Jana Koehler. We’re in the last section of the day, on formal methods.

The research looks at the issues of parsing a business process model, and they offer a new parsing technique called the refined process structure tree that provides a more fine-grained model. Applications for parsing include:

  • translating a graph-based process model (e.g., BPMN) into a block-based process model (e.g., BPEL)
  • speeding up control-flow analysis
  • pattern-based editing
  • processing merging
  • understanding large process models
  • subprocess detection

He showed us an example of the last use case, subprocess detection, where sections of a process are detected and replaced by subprocesses, making the process more understandable (as we saw in the earlier paper on modularity).

There are a few requirements for parsing:

  • uniqueness: e.g., the same BPMN model is always translated to the same BPEL process
  • modularity: e.g., a local change in BPMN translates to a local change in BPEL
  • fast computation of parse tree, e.g., for process version merging, pattern-based editing, or control-flow analysis
  • granularity

The Normal Process Structure Tree, which they have presented in earlier research, is both unique and modular, and represents a hierarchy of canonical (non-overlapping) fragments. Its computing time is linear.

The Refined Process Structure Tree uses a relaxed notion of a fragment through specific definitions of boundary (entry and exit) nodes, and allows only for non-overlapping fragments that can be assembled into a hierarchy. Like the NPST, it is unique and modular, but is more fine-grained than the NPST (presumably because of the relaxed definition of a fragment). It can also be computed in linear time, and he walked through a linear time algorithm for computing the RPST.

In this paper, they assumed that there is only one start and one end node in a process, and that loops have separate entry and exit node; since the publication of this paper, their research has progressed and they have lifted both of these restrictions.

2008 09 02 Sandy Kemsley IntlBPM Comments (1)

BPM Milan: From Personal Task Management to End User Driven Business Process Modeling

Todor Stoitsev of SAP Research presented the last of the flexibility and user interaction papers, From Personal Task Management to End User Driven Business Process Modeling. This is based on research about end-user development, but posits that BPMN is not appropriate for end users to work with directly for ad hoc process modeling.

There is quite a bit of related research to this: workflow patterns, ad hoc workflow, email-based workflow, instance-based task research, process mining, and other methods that provide better collaboration with the end users during process modeling. In this case, they’ve based their research on programming by example, where processes are inferred by capturing the activities of process participants. This involves not just the process participants (business users), but also a domain expert who uses the captured ad hoc activities to work towards a process model, which is eventually formalized in concert with a programmer, and turned into formal workflow models. In formalizing ad hoc processes, it’s critical to consider issues such as pattern reuse, and they have built tools for exploring task patterns as well as moving through to process definition, the latter of which is prototyped using jBPM.

As with most of the other papers today, I can’t do justice to the level of technical detail presented here; I’m sure that the proceedings are available in some form, or you can track down the authors for more information on their papers.

2008 09 02 Sandy Kemsley IntlBPM Comments (0)

BPM Milan: Supporting Flexible Processes Through Log-Based Recommendations

For the first of the paper in the session on Flexibility and User Interaction, Helen Schonenberg of Eindhoven University of Technology presented a paper on Supporting Flexible Processes Through Log-Based Recommendations, co-authored by Barbara Weber, Boudewijn van Dongen and Wil van der Aalst.

This is related to the research on automated process mining (or process discovery) based on system logs, which is similar to the type of work being done by Fujitsu with their process discovery product/service

She started by discussing recommender systems, such as we are all familiar with from sites like Amazon: the user provides some input, and based on their past behavior and that of users who are similar in some way, the system recommends items. Recommendation algorithms are based on filtering of user/item matrices and aggregation of the results.

In the case of a process recommender, there is a key goal such as minimizing throughput time; from this and a filtered view of the history log of this and other users’ past performance, a next step can be recommended. Their current work is focused on fine-tuning the filtering algorithms by which the possible paths in the log are filtered for use as recommendations, and the weighted aggregation algorithms.

She walked us through their experimental setup and results, and showed that it is possible to improve processes by the use of runtime recommendations, in the case where users have the choice of which activity to execute next. This can be used in any system that has a logging system and uses a worklist for task presentation.

2008 09 02 Sandy Kemsley IntlBPM Comments (0)

BPM Milan: Model Driven Business Transformation

The last paper in this session, a case study on Model-Driven Business Transformation, was an industry paper presented by Juliane Siegeris of gematik GmbH, co-authored by Oliver Grasl. gematik provides IT services related to the implementation of German health cards and other healthcare applications, but the case study is their own internal business reorganization into a matrix structure.

Each department modeled their own processes, which were then assembled into enterprise-wide process models: there were some issues related to different levels of experience between modelers in different departments. They used the Enterprise Architect tool (which they already used within their organization for IT specifications), and BPMN 1.0. They had some major challenges along the way, such as the need for large-scale modeling guidelines, support for organizational modeling, and methods for documenting processes beyond the BPMN diagrams; this resulted in the use of UML notation for some modeling and the creation of an online repository of process documentation.

She went through a number of the techniques that they used to ensure consistency, completeness and correctness in process models: guidelines, shared methods and templates, and a management and control structure around the modeling process. They are in the middle of this process modeling exercise, with a target date of the end of this month: considering that only 12% of their process models are complete and approved, this seems like a bit of an ambitious schedule.

2008 09 02 Sandy Kemsley IntlBPM Comments (0)

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.

2008 09 02 Sandy Kemsley IntlBPM Comments (3)

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.

2008 09 02 Sandy Kemsley IntlBPM Comments (0)

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.

2008 09 01 Sandy Kemsley BPM
IntlBPM Comments (0)

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. :)

2008 09 01 Sandy Kemsley BPM
Enterprise 2.0
IntlBPM Comments (0)

Fujitsu Process Discovery

A few weeks ago, I had the chance to see Fujitsu’s new process discovery product/service in action. Unlike the usual sort of process discovery, which involves business analysts running around and documenting what people are doing, this automates the discovery of business processes by examining logs of existing applications.

The problem with the manual process discovery — based on observation, interview and operations/procedures manuals — is that it’s very labor-intensive, and can produce inaccurate results. The inaccuracies can be due to the level of experience of the business analysts, as well as what Michael zur Muehlen refers to as “process confabulation”: when you ask someone about what they do and they don’t have a good answer, they’re just as likely to make something up as they are to admit that they don’t know. I’ve seen this a lot, and tend to base most of what I do in process discovery on observation rather than interviews so that I can see the actual process; my ears perk up when I hear “well, we’re supposed to do it this way, but this is what we actually do”.

In a lot of cases, information about the business processes that are actually executed is embodied within existing enterprise applications, and saved to databases and log files. These could be supply chain, ERP, databases, legacy transactional systems or any other system that records events in some fashion. It is possible to install measurement tools on these systems to track what’s happening, or modify these systems to emit events, but Fujitsu’s new process discovery product/service extracts events from existing database and logs without modifications to existing systems. The real magic, however, comes in the software that Fujitsu has created to visualize those events in the context of a business process, and separate the “happy path” from the exceptions. Once that’s done, it’s possible to look at the ways to reduce exceptions, since the events that cause those exceptions are well understood.

I use the term “product/service” since all this manipulation and analysis requires some amount of training, and Fujitsu currently offers it as a consulting service, although there are standard software portions involved as part of that service. They have three levels of service, ranging from a basic extraction and visualization, to a more comprehensive analysis, to a customized offering. They’ve been using this with customers in Japan for some time — hence the Japanese case studies — and have recently launched their North American trial. Furthermore, it’s not specific to Fujitsu Interstage customers: this is really an independent effort of looking at your existing systems and optimizing your business processes. If that led to you buying Interstage, they’d be thrilled, but it’s not a prerequisite.

Looking at the new toys is the fun part of my job, so Keith Swenson took me for a test drive of the visualization tool. We were looking at a map of the events extracted from database logs for about 5,000 process instances, which were read into the process viewer using a standard CSV import. The straight-through path is detected and shown — in this case, it came from 632 process instances — but a slider control allowed us to change the threshold and add in more of the instances, up to 100% (which showed a pretty complex mess of a process).

Process flow, straight-through path Process flow, straight-through + 15% exceptions Process flow, straight-through + 40% exceptions Process flow, all paths

That’s a pretty cool visualization, since the exception paths appear dynamically as the slider moves, but you really want to pick a simple baseline version of the process using the slider control — not the trimmed-down straight-through path, but one that includes the most common routes — then select one or more exception paths to overlay on it. Exception paths can be sorted and filtered for selection, using criteria including frequency, deviation, repetition, backtracks, and specific transitions.

Exception paths overlaid on base process mapVisually, the straight-through path shows as a thick black line, the alternative routes as gray lines, and the selected exception paths are in red. Although the number beside the black lines indicate the number of process instances that traveled that path, we figured out that the number beside the red (exception) lines indicated the step in the process sequence, since that’s more relevant when you’re tracking exceptions. Other information about transition times can also be shown, indicating bottlenecks in the process.

 

Latency on paths indicating bottlenecksThe tool is intended to be used interactively by a knowledgeable analyst in order to guide the views that will highlight the trouble spots: sort of like using simulation with real data. This isn’t an automated tool that takes data in one end and spits out the answers at the other; it’s meant to drive discussion and analysis, not replace it.

Keith showed me the results of three other case studies, and a couple of interesting effects of the data visualization and analysis that would make a quality manager’s heart sing:

  • In a hard drive manufacturing plant, the assembly portion of the process was simple, but the pre-process and test lines were much more complex. Eliminating the exception routes to improve the process actually had the effect of improving the quality of the drives being manufactured on the line.
  • In the second case, the processes of two different branch offices were compared, and it was identified that in one, half of the orders that their customers placed were for items that were not in stock, whereas the other office shipped most of their orders from their existing stock. There was no judgement about which was better, but it’s useful to be able to identify that one is using a just-in-time approach to reduce inventory costs, whereas the other is focused on reducing time to ship.
  • The third case showed some time analysis of processes to see the degree of deviation in the transition time between two steps. This is a classic statistical analysis, where a larger deviation (usually) indicates a higher potential for process improvement.

Typical benefits that their customers have seen so far are to identify and optimize inefficient processes, identify exceptions and infrequent paths, visualize the gap between the expected and actual processes, identify location-specific differences, and locate process bottlenecks.

This doesn’t, of course, consider all of the purely manual processes that are not captured in system logs, but would greatly reduce the amount of work required to map out the processes that do touch these systems in some way. Furthermore, it happens with little or no time investment from business people and analysts, hence has less impact on the customer than other discovery and analysis techniques. The reality is that this would work great in combination with some skilled manual discovery; maybe Lombardi should use this as part of their process discovery service offerings :)

Tagged , ,
2008 06 04 Sandy Kemsley Comments (12)