Column 2 : BPA

{ Category Archives } BPA

Applying Lean Six Sigma Methodology to Transactional Processes

Next up was a panel discussion with David Haigh of Johnson & Johnson, Sabrina Lemos of United Airlines, and Gary Kucera of Kaplan Higher Education, moderated by Charles Spina of e-Zsigma.

United Airlines has a unique project going on in one of their freight-related operations: they decided to outsource the operation in order to be able to completely remake the process and have it meet specific KPIs, but also decided to allow the existing people to bid on their own jobs. This would have the effect of shifting them out of their current ways of doing things and proposing the best possible way to do it, since they will be in a competitive bidding situation with outsiders. Lemos also spoke about the importance of getting to the real data. She did an exercise of tracing a particularly biweekly report –which took several hours to compile – up to the VP and what he reports on, then tracked what he actually reports on back down to the reports and metrics that are being gathered at the lower levels. Not surprisingly, she found that there was zero alignment: nothing in the biweekly reports were used by the VP in his report, or anywhere else in the chain of command. She spoke about using gauge R&R, walk the process, and value stream mapping techniques to analyze processes, and the necessity of coming to agreement on the meaning of things such as process start points.

Haigh spoke about accounts payable processes at J&J Canada, and how an in-depth review of those processes was triggered by someone actually forgetting to pay the electricity bill, and showing up at the office one day to find a notice that the power would be cut if the bill weren’t paid immediately: not that they didn’t have the money to pay the bill, just that the process to do so wasn’t working. Accounts payable is often one of those processes in companies that is ignored when looking at major process improvement because it’s not revenue generating, but it’s important to recognize that enormous cost savings can be found through taking advantage of early payment discount levels, and avoiding any late penalties or service disruptions. They have found that doing some amount of the work onsite where the business processes are being done is helpful, since the process participants can see what’s involved in their process overall. They use the same techniques as discussed by Lemos, plus Kaizen Blitz and some activity-based costing.

Kucera spoke about aligning the corporate and executive goals with efforts at all levels, and how Jack Welch suggested making your bonus be some percentage of your process improvement savings in order to incent people to align their behavior and metrics with the ultimate goals. He spoke about some of the modeling and display tools that they use, such as fishbone and Pareto diagrams, and how doing these early and engaging with the business management can greatly speed the process improvement efforts. In many cases, since they’re dealing with simple transactional processes, they can use fairly simple analysis tools, but have some of the more sophisticated tools and techniques available as required.

They all had examples of process improvement efforts that have had a direct customer impact. Lemos had a great example of processing freight insurance claims, where they had a metric of processing five claims per day, resulting in the claims people cherry-picking claims in order to meet their quota; enforcing first-in, first-out claims processing resulted in an immediate and dramatic improvement in customer satisfaction. Listening to her stories of their paper-based inefficiencies, where emails are printed, signed and passed around, reminds me so much of the processes in some of my financial services and insurance customers.

In all cases – and I think that this is a key criticism of Lean and Six Sigma – they’re looking for incremental process improvements, not completely disruptive reengineering that would discover new ways to do business. However, in many of today’s standard transactional processes, incremental improvement is the only alternative.

Tagged LSS&PI

Lean Six Sigma & Process Improvement: David Brown of Motorola

I missed the first morning of the IQPC Lean Six Sigma & Process Improvement conference in Toronto today, but with my usual impeccable timing, showed up just in time for lunch (where we had to explain the rules of curling to the American attendees). The first session this afternoon is with David Brown, a black belt at Motorola, where the term “Six Sigma” was first coined and is still used to make their processes more effective, efficient, productive, and transparent.

There has been a transformation for them in how they analyze their processes: ranging from just looking at transactions to high-level intelligence including complex simulations and forecasting. Since they run SAP for their ERP, they have a number of SAP business intelligence (Xcelsius and Business Objects) products, although their most complex analysis is done with Oracle Crystal Ball.

Brown’s presentation was short – less than 10 minutes – and the rest of the session was an interactive one-on-one interview with questions from Charles Spina of e-Zsigma, the conference chair. The Q&A explored much more about how Motorola uses business analytics tools, and opened it up to the (small) audience for their experience with analytics. Not surprisingly, there has been quite a bit of success through the introduction of analytics to process improvement teams: sometimes it’s the black belts themselves, sometimes it’s a separate analytics group that works closely to develop the reports, analysis, and more complex intelligence based on the large volumes of data collected as part of any process improvement project.

Reporting tools can be as simple as Excel – for simple needs – through more complex solutions that include ETL from multiple data sources and regularly scheduled reports, such as Crystal Reports and Xcelsius. Legacy systems can make that a bit of a challenge; often these end up as extracts to Excel or Access, which are then remixed with other sources. Extracts such as this can be really problematic, as I’ve seen first-hand with many of my customers, since there’s no way to keep the data completely in sync with the underlying systems, and typically any one legacy system doesn’t have all the relevant data, so there can be a real problem in matching up related data from multiple systems. Brown underlined that the key issue is to get all of your data into a central data warehouse in order to determine if your data is complete and clean, and to facilitate reporting and analytics. This is especially important for process engineers when trying to do time studies over long periods of time: if you don’t have some consistent representation of the processes over the time period in question, then your analysis will suffer.

Motorola is using their data analytics to improve operational processes, such as order shipping, but also what-if scenarios to inform salespeople on the impact of discount levels to the bottom line. In many cases, this is an issue of data integration: Sabrina Lemos from United Airlines (who will be on the panel following) shared what they were able to recover in late container fees just by integrating their container tracking system with a database (Access, alas) that generates their invoices. Interestingly, I wouldn’t have thought of this as a process improvement initiative – although it is – but rather just as an artifact of doing some clever system integration.

They also discussed the challenges with presenting the results of analytics to the less numerically inclined, which often entails rolling data up to some simpler charts that can be drilled into as required, or just presented in a PowerPoint or PDF file. The real ROI may come from more interactive tools, however, such as dashboards that show operational alerts, or real-time what-if analysis to support human and automated decisions. Since Lean and Six Sigma tools are inherently analytical, this isn’t a new problem for the people in this audience; this is a matter of building relationships early with the non-analytical business managers, getting some early successes in projects to encourage adoption, and using different presentation and learning styles to present the information.

Because of the nature of this audience, the analytics that they’re discussing are typically for human consumption; in the BPM world, this is more and more moving to using the analytics to generate events that feed back into processes, or to inform automated decisioning. Either way, it’s all about improving the business processes.

Tagged LSS&PI

2010 02 23 Sandy Kemsley BAM
IQPC
Lean Six Sigma Comments (0)

BPM and Business Analysis Conferences, London: Call For Speakers

IRM is running both a BPM and business analysis conference in London on September 27-29, and the calls for speakers are open until March 8th.

The BPM conference is looking for presentations on:

Building BPM capabilities
Using BPM to change how businesses are managed
BPM governance and the centre of expertise
BPM success stories
Process modelling and improvement techniques and best practices
Business process design innovations
Process-centric approaches to business rules and business analysis
BPM implementation
BPM human change
BPM and emerging trends

The Business Analysis conference, in its second year and organized in conjunction with IIBA, had three proposed speaker tracks:

Techniques for business analysis
Shaping the future of business analysis
Business agility and business analysis

You can submit a proposal for a presentation at BPM Europe 2010 here, or at Business Analysis London 2010 here.

2010 02 16 Sandy Kemsley BPM Comments (1)

Lean Six Sigma and Process Improvement conference, Toronto

In a nice break from the past two years as a road warrior, I’ve only been on one trip since November. Even better, some conferences are coming to Toronto so that I don’t even need to travel (although not sure that February up here is a big draw if you don’t already live here).

This month, IQPC is hosting a Lean Six Sigma and process improvement conference on February 22-24 at the Westin Harbour Castle, with a focus on achieving a sustainable and transparent Lean Six Sigma and process improvement culture:

Increase Organizational Synergies by Applying LSS and Process Re-engineering to Consolidation and Organizational Restructuring
Maximize Benefits and Savings of Process Improvement Projects by Identifying and Implementing Low Cost Solutions
Bring the Quality of Your Products to a New Level of Efficiency by Applying Innovative Methodologies, such as Triz, to Your Transactional Processes and Engage Your Customers in Transactional Projects
Maximize the Efficiency of Internal and External Benchmarking by Expanding the Use of Dashboards

My readers can get 20% off the “All Access” price by using the code LSSCCol2 when you register here.

Disclosure: IQPC is providing me with a free pass to the show.

Tagged Lean, Six Sigma

2010 02 06 Sandy Kemsley IQPC Comments (1)

BPMN 2.0 Industry Update

It’s webinar day here at Column 2: this is my third in a row, this one an update on the BPMN 2.0 standard by Robert Shapiro, who participates in both the OMG BPMN 2.0 and WfMC XPDL 2.2 standards efforts. We’re already starting to see vendor support for BPMN 2.0, even though it’s not yet fully released, as well as books and training materials.

The concept of subclasses in process modeling has been included in this version, where there is a simple subset of eight elements used for process capture by non-technical process analysts/owners (start, end, sequence flow, task, subprocess, expanded subprocess, exclusive gateway, parallel gateway), then a larger subset for a “descriptive” persona, a larger-still subset for a “DODAF” persona, then the entire set of more than 100 elements:

You can download the accompanying PowerPoint deck for a more complete view of subclasses and their corresponding personas. I can certainly understand why many of the event variations were pushed out of the simple subclass, but I’m not sure that I agree with excluding pools and lanes, since these are pretty commonly used constructs. Also not sure why the US DoD’s enterprise architecture standard is impacting what is supposed to be an international standard.

These subclasses are important for vendors of modeling tools, but also for those looking to use BPMN as a standard for representing processes: this gives a good idea of how to split up the standard by the type of reader (persona) so that you don’t overwhelm the less technical audiences with too much detail, but also provide the greater levels of details for complete process specification.

Shapiro went on to discuss what most consider to be the most important (and likely the most controversial) part of BPMN 2.0: diagram interchange; BPMN 2.0 does not include an XSD schema, and there is ongoing work to create an XSD that is aligned with the metamodel. For those of you who follow BPM standards, you’ll know that XPDL is currently the de facto standard for process model interchange, supported by many vendors; these efforts are continuing in a separate organization (BPMN is managed by OMG, XPDL by WfMC) so it’s good that Shapiro and others are there to bridge the efforts across the two standards. We’re now seeing the emergence of XPDL 2.2, which will support the interchange of BPMN 2.0 process models. XPDL may eventually disappear in the face of a comprehensive BPMN 2.0 diagram interchange standard, but that will take years to happen, and a lot can happen in that time. In the meantime, XPDL will likely be used as an alternative diagram interchange format for BPMN 2.0 diagrams, with vendor support required for both standards.

The Business Process Incubator site has been created by several of the companies participating in both BPMN and XPDL standards efforts as a source for information as well as a variety of standard-related tools such as Visio templates. Shapiro also predicts that many tool vendors will release web-based BPMN 2.0 modelers, as well as BPMN and XPDL converters.

If you’re interested in where BPM standards are headed, it’s worth listening to the entire webinar, especially the Q&A at the end; I imagine that it will be available at the registration link on the WfMC site that I posted in the first paragraph.

Tagged BPMN, XPDL

2010 02 03 Sandy Kemsley BPM standards Comments (8)

ARIS Express Process Modeling Contest

The ARIS online community is running a contest until the end of November to get people started with process modeling: create a process model (using their free downloadable ARIS Express process modeler, of course) that falls into the category “BPM is useful” or “BPM is fun”, and submit it on their site. I’m not sure what you do if your process is both useful *and* fun. The winner in each category will receive an iPod Touch.

You can also vote for your favorite model in each category. You’ll need to register as an ARIS community member to submit a model and to vote, but you can browse through the models without registration.

2009 11 19 Sandy Kemsley Comments (1)

Fujitsu Interstage BPM V11

I had a briefing this week on Fujitsu’s just-released Interstage BPM version 11 as well as an update on their cloud platform. I’ll cover the cloud platform in another blog post, since this one is getting a bit long.

Version 11 has a lot of new features for handling ad hoc, collaborative, knowledge-intensive work; this isn’t surprising, since the analysts and many of the vendors have woken up to the fact that not all processes (or all parts of all processes) are structured, and sometimes people need to be able to create their own processes or just find the right person to which to send a task. In fact, Fujitsu, like many others, consider that the bulk of the processes done today are ad hoc, collaborative and knowledge intensive, with a much smaller portion structured people-centric work, and an even small portion purely automated system-centric processes.

Fujitsu is calling this “sense and respond”, where the “sense” part is about finding the right person for a task, and “respond” is about being able to dynamically create an ad hoc subtask. There’s a lot in the “sense” part that I haven’t seen in other products, such as making recommendations/selections of a person to perform a task based on their past performance at this task; this reminds me somewhat of the research that Ben Jennings is doing on establishing reputation within a social network by examining past behaviors, in addition to just doing assignments based on a predefined skills matrix or assigning tasks to people who you know. In addition to past performance, it also takes into account future tasks assigned to people in order to predict workload, and makes recommendations on due dates based on historical data.

The key functionality for what Fujitsu is calling “dynamic BPM” is the ability for process participant to add subtasks at a point in the process, or create any entirely new process by specifying the tasks involved. This allows a process participant to stretch the process to fit their needs by creating one or more subtasks from any task that is assigned to that user, specifying a task name and description, assigning it to one or more users, and specifying a priority and due date. Control is passed to the subtask(s), then returned to the calling task when all subtasks are completed, after which the process can continue on its previously defined structured path. The status for the subtask is shown along with the task status, which provides the necessary transparency and auditing: the big problem with the way that ad hoc tasks are done now is that users typically just send an email, or make a phone call, in order to involve another person, and that deviation from the structured process is never captured.

A user can also create an entirely new process dynamically, too: they just give it a name, description, priority and due date, then add subtasks to that process in the same manner as adding an ad hoc subtask to a structured process. There is no routing or flow management, however, in either dynamic task creation scenario: subtasks are independent from each other and run in parallel, and the calling task (or dynamic process) waits for all subtasks to complete before proceeding. The recipient of a subtask can further divide it into more subtasks, and assign them as they see fit. The expected use case for a completely dynamic process, then, is for one person to create subtasks for the high-level activities and assign them, then have the recipients of those subtasks create their own subtasks required to complete the block of work assigned to them. If you’re in an environment where the activities don’t have dependencies, this would work well; however, if there are dependencies between the subtasks, it would have to be manually coordinated.

If you need to have more flow control in the processes, you can step up to the Process Outline tool intended for non-technical process analysts and business users. This shows the tasks in a tabular representation with timelines, and allows the creation of dependencies between the tasks. It wasn’t clear, however, the degree of control offered here, and the interoperability with the simpler subtask creation method.

The really cool thing, however, is what happens behind the scenes with these dynamic processes during execution: the automated discovery engine, which is now part of the analytics, tracks all the ad hoc subtasks, and can make suggestions on improving the process based on how the process was actually executed including the user-created subtasks, rather than how it was originally designed. Just as with the desktop application, this bit of Flash allows you to view how many times each path was traversed in the process, and dial it back so that only the most common paths are shown. I think that Fujitsu has done some very interesting things with their process discovery tool – which they can use on the system logs of pretty much any system, not just a BPM system – and it’s a natural fit integrated into their BPM suite. Working together with the dynamic subtask creation, this allows you to see how a process really executes, rather than how your process analyst thinks that it works.

There are some other collaborative features that have been highlighted in this version: discussion threads on process instances (really just a nicely-formatted comment feature, and it would be nice to add tags here to allow for searching the history based on the text within process instance discussions), and wiki pages within the community to allow process documentation. The community portal pages can also link to external portals such as MyYahoo, and incorporate a feed such as a Twitter stream. Users can also get an RSS feed of their tasks, which allows them to consume them in a different interface, if they don’t want to use the Interstage BPM portal.

A few other vendors are starting to think about processes as projects, and Fujitsu has added some of this to Interstage as well, by allowing a process to be viewed as phases and milestones – although not, from what I saw, in a standard GANTT chart representation that allows easy visualization of the critical path – then see which milestones were met or missed.

They’ve added some new dashboard and analytics features, too, but the big win for Fujitsu in this version is the combination of ad hoc task creation and automated process discovery.

2009 11 12 Sandy Kemsley BPM Comments (8)

Collecting, Connecting and Correcting the BPM Dots #brf

Roger Burlton, who organized the BPM track here, gave a presentation this afternoon on process discovery techniques that fit well with Kathy Long’s previous presentation on process notations. He looked at different levels of BPM (and therefore of models): enterprise, business process, and implementation. Most of the BPM models done at the enterprise level are for the purposes of enterprise architecture and high-level strategy; those at the business process level may be for documentation and optimization whether or not the processes are ever automated; and those at the implementation level are primarily for automation purposes. Some of the collect-connect-correct techniques can be reused across these levels, allowing for easier alignment between the different levels:

Collect:

Agree on our intent – get the same motivation
Find out who cares
Discover the truth
Measure real performance

Connect:

Draw pictures and communicate
Question why

Correct:

Make it better
Check it out
Get to yes
Launch and learn
Deal with worries

He went through each of these in detail, pointing out what information that you need to gather at each point, and how this applies at each of the levels. Great presentation, tons of information, although I captured very little of it here due to end-of-day blogger burnout.

That’s it for the first day of Business Rules Forum; I’ll be here the next two days as well. Tomorrow, I can just sit in on presentations, but Thursday I’m back to work by facilitating a peer-to-peer workshop on BPM in the cloud over breakfast, and sit on a panel on emerging trends at the end of the day.

2009 11 03 Sandy Kemsley BusinessRulesForum Comments (0)

Process Notations #brf

The pool at the Bellagio was a big draw, but I’ve kept on track for this afternoon’s presentations, starting with Kathy Long on process notations. She spoke about the necessity of documenting processes, as well as the levels to which documents should be documented. Documenting the current process should only be done down to a certain level; below that, it’s more likely to be an indeterminate or changeable set of tasks that aren’t even correct.

She proposes a much simpler, higher-level process model that’s a lot like IDEF0, but she uses Input, Guides, Outputs and Enablers instead:

Input: something that is consumed by or transformed by an activity/process
Guide: something that determines why, how or when an activity/process occurs but is not consumed
Output: something that is produced by or results from an activity/process
Enabler: something (person, facility, system, tools, equipment, asset or other resource) utilized to perform the activity/process

She looked at some of the problems with other modeling formats; for example, BPMN is easy to learn and communicate and shows cross-functional processes and roles, but multiple process involvement is difficult to model, and it’s hard to follow decision threads: they end up more as system flows than actual business process models.

She touched on a lot of points for making process models accurate and relevant, such as levels of decomposition, and not modeling events and rules as activities; these are things that tend to happen in BPMN swimlane diagrams, but not in IGOE models. A lot of this, in fact, is about making the distinction between events and activities; there’s some confusion about this in the audience, too, although most often what is shown as an activity (box) on a swimlane diagram should actually just be a line between activities, e.g., instead of adding an activity called “send to Accounting”, you should just have a line from the previous activity to the new activity in the Accounting swimlane. Her BPMN is a bit rusty, perhaps, because an event would not be modeled as an activity, it would be modeled as an activity; instead, she shows a customer example where she used a stoplight icon to indicate an event, although there is an event icon available in BPMN.

Regardless of the notation, however, there are things that you need to consider:

Understand why you’re modeling processes: documentation, understanding, communication, process optimization.
Simplify the models by removing events and decisions
Understand the goals in order to set the focus – and determine the critical path – for the process

I’m not sure that I agree with all of what she states about modeling; much of the fault that she finds with BPMN is not about BPMN, but about bad instances of BPMN or bad tools. She has one really valid point, however: most process models created today are just wallpaper, not something that is actually useful for process documentation and optimization.

This is the third year that I’ve heard her speak at BRF, and the message hasn’t changed much from last year or the year before, including the core examples, so it could use a refresh. Also, I think that she needs to get a bit more updated on some of the technology that touches on process models: she sees the business doing process modeling, then handing it over to IT for implementation (which doesn’t really account for model-driven development), and speaks only fleetingly of “workflow” systems. I realize that many process models are never slated for automation, but more and more are, and the process modeling needs to account for that.

2009 11 03 Sandy Kemsley BusinessRulesForum Comments (0)

Process Design Slam 2009 – The Final Judgement #SAPTechEd09 #BPXslam09

To wrap up the proceedings from last night, I was asked to critique the efforts of the groups and pick a winner: as it turned out, I was the only judge. Each of the groups did great work, and I want to call out some of the specific efforts:

The Business Use Case group had a great written story, including a lot of cultural and social background for our fictional city in order to provide context for the implementation.
The BPM Methodologies group had excellent documentation on the wiki, including graphics and charts to make it clear how the methodologies fit with the other groups.
The Business Rules group were stars at collaboration with the other groups, in part because everyone quickly realized the importance of business rules to data, UI and process, and solicited their input.
The UI and Dashboards group created mockups of monitoring dashboards that provide a starting point for future design slam work.
The Collaborative Modeling group led at international collaboration, using Gravity (process modeling within Google Wave) interactively with team members in Europe during the session, and produced a business process model.
The Service Implementation group also kicked off implementation, creating a service orchestration process model as a starting point.

In general, everyone seemed to have a good understanding of the importance of data, rules and process, but there could have been better cross-pollination between the groups; in future design slams, that could be helped by requiring some group members to move partway through the evening in order to ensure that there is a better understanding on both sides, something that is fairly common in real-life businesses where people are seconded from one department to another for part of a project. Although a certain amount of collaboration did occur, that was one area that requires more work. I saw one tweet that referred to the design slam as crowdsourced rather than collaborative, although I’m not sure that I would say that: crowdsourcing usually has more of a flavor of individuals contributing in order to achieve their own goals, whereas this was a collaboration with common goals. However, those goals were a bit fragmented by group.

Another issue that I had was the lack of an architectural view of process design: although all of the groups are contributing to a common process (or set of processes), there is little thought around the transformations required to move the process list developed by the Business Use Case group to the process model developed by the Collaborative Modeling group to the process design developed by the Service Implementation group. In enterprise architecture terms, this is a case of transforming models from one layer to another within the process column of the architecture (column 2 if you’re a Zachman fan); understanding these transformations is key so that you don’t reinvent the process at each layer. One of the goals of model-driven design is that you don’t do a business-level process model, then redraw it in another tool; instead, the business-level process model can be augmented with service-level information to become an executable process without recreating the model in another tool. In reality, that often doesn’t happen, and the business analysts draws a process in one tool (such as Visio, or in the case of the design slam, Gravity), then IT redraws it in a tool that will create an executable process (NetWeaver in this case). I have a couple of suggestions here:

Combine the Business Use Case and Collaborative Modeling groups into a single group, since they are both doing high-level business analysis. This would allow the process list to be directly modeled in the same group without hand-off of information.
Reconsider the use of tools. Although I have a great deal of appreciation for Gravity (I am, after all, a geek), the fact that it does not share a model with the execution environment is problematic since the two groups creating process models were really off doing their own thing using different tools. Consider using NetWeaver 7.2, which has a business analyst perspective in the process composer, and having the business use case/collaborative modeling group create their initial non-technical models in that environment, then allow the service implementation team to add the technical underpinnings. The cool Wave collaboration won’t be there, or maybe only as an initial sketching tool, but the link will be made between the business process models and the executable models.

When it came down to a decision, my choice of the winner was more a product of the early state of the design slam rather than the efforts or skills of the group: I suspect that my view would change if I were judging in Vienna or Bangalore when the process is further along. I selected the Business Use Case group as the winner at this point based on the four judging criteria: although they failed to include alternative media, their story was clear and well-written, it fit well with the other groups’ efforts, and they used good social and collaborative methods within their group for driving out the initial solutions.

The winning team was made up of Greg Chase, Ulrich Scholl and Claus von Riegen, all of SAP, with input from a few others as subject-matter experts on public utilities and electricity production, and started the discussions on pricing plans that ended up driving much of the Business Rules group’s work. Ulrich also has solar cells on his house that connect to the grid, so he has in-depth knowledge of the issues involved with micro-generation, and was very helpful at determining the roles involved and how people could take on multiple roles. They leveraged a lot of the content that was already on the wiki, especially references to communities with experience in micro-generation and virtual power plants. Besides this initial leg up on their work, they were forced to work fast to produce the initial use cases and processes, since that provided necessary input to the other groups to get started with their work, which left them with more of the evening to write a great story around the use case (but, apparently, not enough time to add any graphics or multimedia).

There was a huge amount of effort put into the design slam, both in the preceding weeks through conference calls and content added to the wiki, and at the session last night in Phoenix. I believe that a huge amount of groundwork has been laid for the design slams upcoming in Vienna and Bangalore, including process model, service orchestration diagrams, business rules decision tables, and monitoring dashboard mockups.

I had a great time last night, and would happily participate in a future process design slam.

2009 10 15 Sandy Kemsley BPM
BRM
SAPevents
SOA Comments (0)

Process Design Slam 2009 #SAPTechEd09 #BPXslam09

8pm

We’re just getting started with the Process Design Slam: one of the face-to-face sessions that make up the collaborative design process that started a couple of months ago on the Design Slam wiki. Marilyn Pratt has identified the six groups that will each work on their part of the design, collaborating between groups (a.k.a. poaching talent) as required, and even bringing in people from the Hacker Night and Business Objects events going on in the same area.

Business Use Case, led by Greg Chase
Collaborative Modeling, led by David Herrema
Business Rules, led by James Taylor
Service Implementation, led by John Harrikey
BPM Methodologies, led by Ann Rosenberg
UI and Dashboards, led by Michelle Crapo

Right now, everyone has formed into initial groups based on their interests, and is having some initial discussions before the food and beer arrives at 8:30. Since there was an initial story and process model developed by the online community, everyone is starting at something close to a common point. Participants within a group (and even the leaders) could change throughout the evening.

By the end of the night, each team will have created a story about their work, and give a 5-minute presentation on it. The story must include additional media such as video and images, and in addition to the presentation, it must be documented on the wiki. Each story must also be related to the output of the other teams – requiring some amount of collaboration throughout the evening – and include pointers on what worked and didn’t work about their process, and what they would do differently in the future.

At that point, the judging panel, which includes me plus Marc Rosson, Uli Scholl, Ann Rosenberg and Dick Hirsch, will render our judgment on the creations of the groups based on the following criteria:

Clarity and completeness of the story on the wiki, particularly if it could be understood without the presentation.
Creative use of media.
How well this story ties into the overall storyline of the night.
The social process that was used to create the story.

I’m floating around between groups to listen in on what they’re doing and some of their initial thoughts.

8:30pm

Beer o’clock. The Business Rules team is still deep in conversation, however, and Business Use Case comes over to them to ask for help in bringing the business rules and business use case together. Business Use Case outlines the actors that they have identified, and the high-level business processes that they have identified in addition to the initial business process of bringing new consumer-producers online.

9pm

BPM Methodologies has a much wider view than just this project: developing methodologies that can be used across (SAP) BPM projects, including assessing the business process maturity of an organization in order to determine where they need to start, and identifying the design roles. In the context of the design slam, they will be helping to coordinate movement of people between the teams in order to achieve the overall goals.

9:30pm

Service Implementation – viewed by groups such as Business Use Case as “the implementers” – have revised the original process map from a service standpoint; looking at the services that were required led to a process redesign. They are using the Composite Designer to model the service orchestration, including the interfaces to the services that they need and external services such as FirstLook, an wind assessment service based on location data. In their service orchestration process, they assume that the process is initiated with the data gathered from a user interface form, and they focus primarily on the automated process steps. Ginger Gatling doesn’t let me leave the table until I tell them what they have to do to win; I advise them to update the wiki with their story.

9:50pm

The Collaborative Modeling group is modeling the business process using Gravity, online with a couple of participants in Europe. This is a process model from a business standpoint, not an executable model; there is no concept of the linkage between this and what is being done by the Service Implementation team. I suggest that they should head over there to compare processes, since these should (at some level) just be different perspectives on the same process.

10pm

Business Use Case is identifying the necessary processes based on their earlier collaboration with Business Rules: this has given them a good understanding of business case, goals and incentives. They’re considering both human and automated usages, and have fed their results to the UI, Business Rules and Collaborative Modeling teams.

10:10pm

Business Rules states that they’ve had to gather information from numerous sources, and the challenge is to sequence it properly: data is captured by the UI, but is driven by the Business Use Case. They didn’t work with the Collaborative Modeling group directly, but there are links between what they do and what’s happening in the process. They’re also interested in using historical usage data to determine when to switch consumers between usage plans.

10:20pm

UI and Dashboards managed to recruit a developer who is actually coding some of their interfaces; they were visited by many of the other groups to discuss the UI aspects, since the data gathered by the UI drives the rest of the process and rules, and the data generated by the process drives the dashboard interfaces. They feel that they had the best job since they could just be consumers and visualize the solutions that they would like to have.

10:35pm

Presentations start. Marilyn Pratt is being the MC, and Greg Chase is wrangling the wiki to show what has been documented by each of the groups. Half of the Service Implementation team just bailed out. I have to start paying attention now. Checking out the wiki pages and summarizing the presentations:

Business Use Case worked with the UI, Collaborative Modeling and Business Rules teams, since those teams required the business use cases in order to start their work. They developed a good written story including cultural/social background about the fictional city where the power generation plan would go into effect. They defined the roles that would be involved (where one person could take on more than one role, such as a consumer that is also a producer), and the processes that are required in order to handle all of the use cases. They did not use any presentation/documentation media besides plain text.
BPM Methodologies had excellent documentation with the use of graphics and tables to illustrate their points, but this was a quite general methodology, not just specific to this evening’s activities. They worked briefly with the other groups and created a chart of the activities that each of these groups would do relative to the different phases in the methodology. I found the methodology a bit too waterfall-like, and not necessarily a good fit with the more agile collaborative methods needed in today’s BPM.
Business Rules focused on the rules related to signing up a new user with the correct pricing plan, documenting the data that must be collected and an initial decision table used to select a plan, although no graphics or other non-text media. They worked with the Business Use Case team and the UI team to drive the underlying business use cases and data collection.
UI and dashboards created the initial mockups that can be used as a starting point for the design slam in Vienna in a couple of weeks. They worked with Business Rules and Business Use Case in order to nail down the required user data inputs, and what is required for monitoring purposes, and included some great graphics of the monitoring dashboards (although not the data collection form).
Collaborative Modeling used Gravity (process modeling in Google Wave) not just for modeling with the group around the table, but also with participants in Germany and the Netherlands. They included photos of the team as well as screen snaps of the Gravity Wave that they created, although the text of the story documented on the wiki isn’t really understandable on its own. I’m not sure that they spent enough time with other groups, especially the Service Implementation group.
Service Implementation talked to the Business Rules and UI teams to discuss rules and data, but felt that they were running blind since there wasn’t enough of the up-front work done for them to do any substantial work. They used placeholders for a lot of the things that they didn’t know yet, and modeled the service orchestration. The documentation in the wiki is very rudimentary, although includes the process map that they developed; it’s not clear, however, how the process model developed in Collaborative Modeling relates to their map.

11:30pm

And now, on to the judging – I’ll write up the critique and results in a later post.

2009 10 15 Sandy Kemsley BPM
BRM
SAPevents
SOA Comments (1)

NetWeaver BPM update #SAPTechEd09

Wolfgang Hilpert and Thomas Volmering gave us an update on NetWeaver BPM, since I was last updated at SAPPHIRE when they were releasing the product to full general availability. They’re readying the next wave of BPM – NetWeaver 7.2 – with beta customers now, for ramp-up near the beginning of the year and GA in spring of 2010.

There are a number of enhancements in this version, based on increasing productivity and incorporating feedback from customers:

Creating user interfaces: instead of just Web DynPro for manual creation of UI using code, they can auto-generate a UI for a human-facing task step.
New functions in notifications.
Handling intermediate events for asynchronous interfaces with other systems and services.
More complete coverage of BPMN in terms of looping, boundary events, exception handling and other constructs;
Allowing a process participant to invite other people on their team to participate in a task, even if not defined in the process model (ad hoc collaboration at a step).
The addition of a reporting activity to the process model in order to help merge the process instance data and the process flow data to make available for in-process analytics using a tool such as BusinessObjects – the reporting activity takes a snapshot of the process instance data to the reporting database at that point in the process without having to call APIs.
Deeper integration with other SAP business services, making it easier to discover and consume those services directly within the NetWeaver Process Composer even if the customer hasn’t upgraded to a version of SAP ERP that has SOA capabilities
Better integration of the rules management (the former Yasu product) to match the NetWeaver UI paradigms, expose more of the functionality in the Composer and allow better use of rules flow for defining rules as well as rules testing.
Business analyst perspective in process modeler so that the BA can sketch out a model, then allow a developer to do more of the technical underpinnings; this uses a shared model so that the BA can return to make modifications to the process model at a later time.

I’d like to see more about the ad hoc runtime collaboration at a task (being able to invite team members to participate in a task) as well as the BA perspective in the process modeler and the auto-generation of user interfaces; I’m sure that there’s a 7.2 demo in my future sometime soon.

They also talked briefly about plans for post-7.2:

Gravity and similar concepts for collaborative process modeling.
Common process model to allow for modeling of the touchpoints of ERP processes in BPM, in order to leverage their natural advantage of direct access to SAP business applications.
Push further into the business through more comprehensive business-focused modeling tools.
Goal-driven processes where the entire structure of the process model is not defined at design time, only the goals.

In the future, there will continue to be a focus on productivity with the BPM tools, greater evolution of the common process model, and better use of BI and analytics as the BusinessObjects assets are leveraged in the context of BPM.

2009 10 14 Sandy Kemsley BAM
BI
BPM
BRM
SAPevents Comments (0)

SAP research overview: Gravity #SAPTechEd09

We had a blogger roundtable today with Soeren Balko, VP in the SAP NetWeaver BPM architecture and design group, and Marek Kowalkiewicz from the Brisbane section of SAP Research with an overview of the research and special projects going on at SAP. Innovations tend to emerge from the research centers – in conjunction with the universities with whom they collaborate and customers – then the product development groups become involved in order to determine how to productize the ideas.

The hot thing in their research right now is Gravity: the collaborative process modeling environment that they created within Google Wave. The process modeling is done purely with tools created in Google Web Toolkit; this is not SAP NetWeaver BPM embedded within Google Wave, it’s a BPMN modeler created with GWT. The process models can be exported to the BPMN 2.0 format for import into a BPMS (or another modeling tool). The Wave playback capability is especially nice for seeing how the process model was built, and different colored shadows on the model objects to denote which participant created the object.

There are bots that can be added to processes in order to check the process integrity, export process models, and to detect portions of the process flow that could potentially be collapsed into a subprocess. It makes sense that there will be other bots created in order to perform other automated checks and actions on the process model.

They’re not supporting the full BPMN 2.0 object set, but have a subset that can at least be used for simple models and as a proof of concept around the idea of a modeler within Wave.

James Taylor was at the table too, and we got into a discussion of modeling rules in a similar manner: although this is a BPMN modeler, so there’s no opportunity to model rules here, there may be an opportunity to take the NetWeaver BRM rules modeling paradigm and create a similar sort of prototype that allows for rules modeling within Wave.

We’ll be seeing more of Gravity tonight at the Process Design Slam, and if I ever get my freaking Wave account (2 invitations already on their way, but not arrived yet), then I can actually try it out for myself.

We also had a brief overview of Yowie, a project that we saw at DemoJam last night, that uses SAP text analytics to act as an intelligent agent either as a bot in Wave or when receiving emails regarding enterprise applications and assets; and BirdsEye, which receives the GPS signal sent from an iPhone (or any geopositioning RSS feed) to do near-real-time positional tracking for applications such as delivery optimization.

2009 10 14 Sandy Kemsley BPM
SAPevents
cloud Comments (2)

Process Design Slam preparation #SAPTechEd09 #BPXslam09

I was sitting in the blogger room this morning at SAP TechEd in Phoenix, and heard Marilyn Pratt mention my name over at another table: usually something that makes me perk up my ears, since Marilyn is a primo community builder, and I had the feeling that I was about to be recruited for something. I’m already signed up as a judge/critic for the Process Design Slam event here tonight, which is the culmination (along with the TechEd events in Vienna and Bangalore) of a three-month virtual community collaboration for applying BPM tools and methodologies to solve a specific business challenge.

The selected process, from the design slam wiki:

Automating business processes related to forming virtual community-based power plant made up of resident’s personal solar wind generation.

The idea is to describe a process that allows a homeowner or business to come online as a micro generator within a township and the various steps (human and automated) that are required. Sustainability gets better over time, the more neighborhoods choose to generate power from green sources to supply the very power this neighborhood consumes – and in pretty much the same timeframe. This also reduces the losses of transporting power over longer distances. Thus, power companies will more and more become brokers, and less actual suppliers of power.

After a chat with Marilyn, we’ve decided that I’ll interview the winners (briefly, since it will be after midnight, which is 3am in my time zone) and write a short blog post about their winning contribution. This will definitely break my standard rule that everything is off the record once the bar opens.

The community has already done a lot of the work, including creating and agreeing upon a process map using NetWeaver BPM 7.1:

and rules in NetWeaver BRM 7.1:

Keep an eye on the #BPXslam09 hashtag on Twitter for up-to-date news as the day progresses.

2009 10 14 Sandy Kemsley BPM
SAPevents Comments (1)

Fujitsu process discovery case study #GartnerBPM

I first saw Fujitsu’s process discovery offering last year, and it looked pretty useful at the time, but it didn’t have much of a track record yet. Today’s session brought forward Greg Mueller of Electro Scientific Industries (ESI), a manufacturer of photonic and laser systems for microengineering applications, to talk about their successes with it.

Basically, the Automated Process Discovery (APD) uses log files and similar artifacts from any variety of systems in order to derive a process model, analyzing frequencies of process variations, and slicing and dicing the data based on any of the contributing parameters. I’ve written a lot about why you would want to do process discovery, including some of the new research that I saw at BPM 2009 in Germany last month.

ESI wanted to reduce inventory and improve manufacturing cycle time, and needed to understand their opportunity-to-order process better in order to do that. They used APD to determine the actual process flows based on about 15 months of data from SAP and other systems, then validated those flows with the team who worked with those flows. They wanted to look at variations based on business unit and other factors to figure out what was causing some of their cycle time and inventory problems.

They assumed a relatively simple four-step process of opportunity-quote-order-shipment, possibly with 3-4 additional steps to allow revisions at each of these steps; what they actually found when they looked at about 11,500 process instances is that they had over 1,300 unique process flows. Yikes. Some of this was cycling through steps such as order change: you would expect an order to be changed, but not 120 times as they found in some of their instances. There were also loopbacks from order to quote, each of these representing wasted employee time and increased cycle time. They found that one task took an average of 58 days to complete, with a standard deviation of 68 days – again, a sign of a process out of control. They realize that they’re never going to get it down to 25 unique process flows, but they are aiming for something far lower than 1,300.

They did a lot of data slicing and analysis: by product, by region, by sales manager and many other factors. APD allows for that sort of analysis pretty easily (from what I saw last year), much like any sort of dimensional modeling that you would do in a data warehouse.

They observed that less than 20% of their opportunities followed the happy path, and the rest were taking too long, duplicating efforts, having too many rework loopbacks, and sometimes not even shipping after a great deal of up-front work.

In their process improvement phase, they established 22 projects including a number of improvement features such as automating processes to reduce repeated steps, improving entry flow to reduce time intervals, require the entry of initial data early in the process in order to reduce loopbacks and rework. Since their business runs on SAP, a lot of this was implemented there (which begs the question of who did such a crappy SAP implementation for them in the first place such that they had problems like this – seriously, insufficient required data entry at the start of an process?), and they’re able to keep extracting and analyzing the logs from there in order to see what level of improvement that they are experiencing.

After a much too short presentation by ESI, Ivar Alexander from Fujitsu gave us a demo of APD with ESI’s basic process; I’ve seen a demo before, but it’s still fascinating so see how the system correlates data and extracts the process flows, then performs detailed dimensional analysis on the data. All of this is done without having to do a lot of interviews of knowledge workers, so is non-invasive both from a people and system standpoint.

It’s important to recognize that since APD is using the system logs to generate the process flows, only process steps that have some sort of system touch-point will be recorded: purely manual process steps will not. Ultimately, although they can make big improvements to their SAP-based processes based on the analysis through APD, they will probably need to combine this with some manual analysis of off-system process steps in order to fully optimize their operations.

2009 10 06 Sandy Kemsley Gartner BPM Comments (6)

Deciding on process modeling tools #GartnerBPM

Bill Rosser presented a decision framework for identifying when to use BPA (business process analysis), EA (enterprise architecture) and BPM modeling tools for modeling processes: all of them can model processes, but which should be used when?

It’s first necessary to understand why you’re modeling your processes, and the requirements for the model: these could be related to quality, project validation, process implementation, as part of a larger enterprise architecture modeling effort and many other reasons. In the land of BPM, we tend to focus on modeling for process implementation because of the heavy focus on model-driven development in BPMS, hence model within our BPMS, but many organizations have other process modeling needs that are not directly related to execution in a BPMS. Much of this goes back to EA modeling, where several levels of process modeling that occur in order to fulfill a number of different requirements: they’re all typically in one column of the EA framework (column 2 in Zachman, hence the name of this blog), but stretch across multiple rows of the framework such as conceptual, logical and implementation.

Different types and levels of process models are used for different purposes, and different tools may be used to create those models. He showed a very high-level business anchor model that shows business context, a conceptual process topology model, a logical process model showing tasks within swimlanes, and a process implementation model that looked very similar to the conceptual model but included more implementation details.

As I’ve said before, introspection breeds change, and Rosser pointed out that the act of process modeling reaps large benefits in process improvement since the process managers and participants can now see and understand the entire process (probably for the first time), and identify problem areas. This premise is what’s behind many process modeling initiatives within organizations: they don’t plan to build executable processes in a BPMS, but model their processes in order to understand and improve the manual processes.

Process modeling tools can come in a number of different guises: BPA tools, which are about process analysis; EA tools, which are about processes in the larger architectural context; BPM tools, which are about process execution; and process discovery tools, which are about process mining. They all model processes, but they provide very different functionality around that process model, and are used for different purposes. The key problem is that there’s a lot of overlap between BPA, EA and BPM process modeling tools, making it more difficult to pick the right kind of tool for the job. EA tools often have the widest scope of modeling and analysis capabilities, but don’t do execution and tend to be more complex to use.

He finished by matching up process modeling tools with BPM maturity levels:

Level 1, acknowledging operational inefficiencies: simple process drawing tools, such as Visio
Level 2, process aware: BPA, EA and process discovery tools for consistent process analysis and definition of process measurement
Levels 3 and 4, process control and automation: BPMS and BAM/BI tools for execution, control, monitoring and analysis of processes
Levels 5 and 6, agile business structure: simulation and integrated value analysis tools for closed-loop connectivity of process outcomes to operational and strategic outcomes

He advocates using the simplest tools possible at first, creating some models and learning from the experience, then evaluating more advanced tools that cover more of the enterprise’s process modeling requirements. He also points out that you don’t have to wait until you’re at maturity level 3 to start using a BPMS; you just don’t have to use all the functionality up front.

2009 10 05 Sandy Kemsley EA
Gartner BPM Comments (1)

Discovering Reference Models by Mining Process Variants Using a Heuristic Approach #BPM2009

Chen Li of University of Twente gave the last presentation of the conference on process variant mining. We heard yesterday in the tutorial on flexibility about process variants; one issue with process variants is that there needs to be some way to identify which of the variants are important enough to update the original process model. The paper describes a heuristic search algorithm for determining which of the variants are important, by considering both the similarity to the original process model and the most common changes amongst the variants, e.g., the same new step is added to almost all process variants.

Since the process can be varied at runtime, the new process model doesn’t have to be perfect, it just has to be better than the original one. In general, the more activities contained in a candidate model and the more that its structure matches that of the variants, the better it is: they have created a fitness function that combines these two parameters and calculates how good a specific candidate model is. The search tree used to find the optimal candidate process model generates all potential candidates by changing one activity at a time, calculating the best fit, then replacing the original with the candidate if it is better than the original. This continues until no better candidate model can be calculated, or until you reach your maximum search distance (which would be set in order to bound computations).

The algorithm was evaluated with simulations, indicating that the most important changes tend to be performed at the beginning of the search.

2009 09 10 Sandy Kemsley BAM
BPM2009 Comments (2)

Divide-and-Conquer Strategies for Process Mining #BPM2009

In the first of two papers in the final session of the conference, Josep Carmona of Universitat Politecnica de Catalunya presented on process mining calculation strategies. The theory of regions shows how to derive a Petri net representation of a process model from the process log, which shows the transition between states, but it’s very computationally expensive. This paper deals with ways of making that computation less expensive in order to deal effectively with large logs.

First is a decompositional strategy, which partitions the regions in a way that allows the identification of a set of state machines that cover all the events, then uses parallel composition to assemble the state machines into a Petri net.

The second approach is a higher-level divide-and-conquer strategy, where the event log is recursively partitioned by event class until the log sections are small enough to use other techniques. The clustering of the events is the key thing here: first, compute the causal dependency graph, then use spectral graph theory to find clusters of highly related events that will be partitioned off into their own section of the event log.

What they’ve seen in experiments using this technique is that there is a significant computational improvement (from minutes to seconds) from the decompositional approach, and that the divide-and-conquer approach allows for the processing of event logs that are just too large for other techniques.

You can get Genet, the tool that they developed to do this, here.

2009 09 10 Sandy Kemsley BAM
BPM
BPM2009 Comments (1)

Discovering process models from unlabelled event logs #BPM2009

Diogo Ferriera of Universidade Tecnica de Lisboa presented a paper on process discovery based on unlabelled event logs: where the events in the log are only identified by the specific task, not by the process instance. Consider that a process instance may be executed via multiple paths through the process model, resulting in a different sequence of events logged: although you might know all possible paths through the model, you don’t know which one that any given instance followed. Also consider that processes will be executing simultaneously, so their events are intermingled.

Taking a probabilistic approach, you can take the event sequence and the source sequence (i.e., you know both the events and the instances that created them) and generate a matrix of probabilities that any given event will follow another within the same source instance: that’s some fairly standard math. He then took the event sequence and the matrix (which now represents a priori knowledge about how events interrelated), and did a fairly magic-looking calculation that calculated the source sequence based on that information.

The problem, of course, is that you don’t have the magic matrix, you only have the event sequence: initialize the matrix to something, then use the event sequence and the matrix to estimate the source sequence, then use the event sequence and the estimated source sequence to estimate the matrix. Wash, rinse, repeat until the matrix converges. You could initialize the matrix randomly, but that would take a while to converge (or would converge to a local maximum); instead, Ferreira pulled a rabbit out of his hat by stating that the matrix can be initialized with the transition probabilities present in the event sequence, that is, as if the event sequence were generated from a single source. As the paper states:

Even if x [event sequence] is the result of interleaving a number of sources, their underlying behaviour will be present in M+ [probability matrix] since consistent behaviour will stand out with stronger transition probabilities than the spurious effects of random interleaving. Therefore, M+ is a good initial guess for the estimation of M.

Amazingly, this works. Or maybe not so amazing, because I suppose there would be no research paper if this didn’t work. As the number of sources (instances) increases, the accuracy approaches that of when both the event and source sequence are known; as the number of overlapping sources increases, the accuracy drops to about 60% (by the time that you reach 10 overlapping instances), then flattens out.

There are a number of use cases for this: preprocessing for other process mining algorithms, or as a labeling mechanism to find the source instance when it is unknown. Or just if you want to show off some cool math at parties.

2009 09 09 Sandy Kemsley BAM
BPM
BPM2009 Comments (1)

Tutorial: enabling flexibility in process-aware information systems #BPM2009

Manfred Reichert of Ulm University and Barbara Weber of University of Innsbruck presented a tutorial on the challenges, paradigms and technologies involved in enabling flexibility in process-aware information systems (PAIS). Process flexibility is important, but you have to consider both build time flexibility (how to quickly implement and configure new processes) and run time flexibility (how to deal with uncertainty and exceptional cases during execution), as well as their impact on process optimization.

We started by looking at the flexibility issues inherent in the imperative approach to BPM, where pre-defined process models are deployed and executed, and the execution logs monitored (in other words, the way that almost all BPMS work today). As John Hoogland discussed this morning, there are a number of flexibility issues at build time due to regional process variations or the lack of a sufficient information about decisions to build them into the process model. There’s also flexibility issues in the run time, mostly around exception handling and the need for ad hoc changes to the process. As all this rolls back in to the process analyst through the execution monitoring, it can be used to optimize the process model, which requires flexibility in evolving the process model and impacting work in progress. The key problem is that there are way too many variants in most real-life processes to realistically model all of them: there needs to be a way to model a standard process, then allow user-driven configuration (either explicitly or based on the instance parameters) at run time. The Provop approach presented in the tutorial allows for selective enabling and disabling of process steps in a master model based on the instance conditions, with a lot of the research based on the interaction between the parameters and the soundness of the resultant models.

Late binding and late modeling approaches use a pre-specified business process with one or more placeholder activities, then the placeholder activities are replaced with a process fragment at run time either from a pre-determined set of process fragments or a process fragment assembled by the user from existing activity templates (the latter is called the “pockets of flexibility” approach, a name that I find particularly descriptive).

Up to this point, the focus has been on changes to the process model to handle variability that are part of normal business, but possibly not considered exceptions. Next, we looked at runtime exception handling, such as the failure or unavailability of a web service that causes the normal process to halt. Exceptions that are expected (anticipated) can be handled with compensation, with the compensation events and handler built into the process model; unexpected exceptions may be managed with ad hoc process changes to that executing instance. Ad hoc process changes can be a bit tricky: they need to be done at a high level of abstraction in order to make it understandable to the user making the change, yet the correctness of the changes must be validated before continuing. This ability needs to be constrained to a subset of the users, and the users who can make the changes may require some assistance to do this correctly.

This was a good tutorial, but I wanted to catch the process mining session so skipped out at the break and missed the last half.

2009 09 09 Sandy Kemsley BPM
BPM2009
SOA Comments (2)

Column 2