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.

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.

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.

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.

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.

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.

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.

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.

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.

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.