Column 2 by Sandy Kemsley

I’m not sure that I understand all of the meaning in this graphic, but I love it! Posted by Marilyn Pratt of SAP’s BPX.

One of the things that Metastorm has released recently is a series of solution frameworks that they call “Process Pods“, which include prebuilt rules, dashboards, KPIs, and technical integrations in addition to prebuilt process models; however, they’re not truly productized in that they’re supported by the Professional Services group as if they were customized work.

The latest of these process pods is targeted at the financial services market, specifically new account opening: an area that often requires both electronic and paper-based data collection, background checks, new account creation, and updates to existing account and client records (Metastorm press release here). In addition to the process flows and rules of other process pods, this one also uses Metastorm Integration Manager product (which is, I believe, what the CommerceQuest acquisition turned into) to integrate the legacy applications (including CICS) that are typically used for client on-boarding tasks in financial services organizations. Although there will still need to be customization, the idea (as with most BPM frameworks) is that the time to deploy a productive, integrated solution will be greatly reduced.

I checked out their hour-long recorded demo of the New Account On-Boarding process pod (registration required, and didn’t seem to be Firefox-friendly). It’s pretty low-resolution and the audio is a bit sketchy, but you can get an idea of how a process would look as implemented with their NAO process pod, including the following features:

• CICS integration both for retrieving data and creating the new account on the legacy mainframe system.
• SharePoint portal integration, plus standard JSR168 portal integration into a Pluto portal; there are a number of portlets that can be embedded, such as a task to-do list, a watch list, a search form, and a form to create a new account (which presumably kicks off a new process instance).
• Email integration for alerting process participants.
• Data entry forms including links to data validation for things such as customer/account number, and enforcement of required fields.
• Checks for conditions such as specific countries of origin and amount of investment to trigger any anti-money laundering or other rules for further investigation.
• Identify verification to satisfy know-your-customer regulations, including checking against third-party blacklist checking services.
• Risk assessment checklist.
• Electronic signature and date-stamp at key points, such as completion of due diligence.
• Removing tabs from user interface at points in the process to limit access to information by certain user classes.
• Document attachments.
• After-the-fact batch reports.
• Dashboards with KPIs; these appear fairly rudimentary, but are actionable by allowing drill-down to the actual process instances.
• A third (!) separate business intelligence product that also produces reports and dashboards.
• Administrative functionality to allow control of many of the process parameters via table values, e.g., adding new questions to the risk questionnaire and indicating how each possible answer contributes to an overall score. There are some aspects of this with which I disagree, such as specifying parallel and serial process paths by creating table entries for each logical node in the process map, and assigning the order: this is the way that we used to do process maps before there were graphical process mapping tools.

One issue that I have with the demo is that it shows a finished product from a user point of view, without much of an indication (besides the administration table values) of how much effort is required to build this solution based on the NAO framework, or what is even customizable in the framework. For example, I suspect that some of the processes, rules and data fields in their standard process pod are US-specific, although they should be customizable with some additional help.

There are some things that they sell as features that look a bit clumsy, such as calling out to MS-Word for spell-checking within a note entered in a web form. Also, early in the demo, she shows the process model in ProVision, but not obvious that this maps directly to the Metastorm execution environment — I’ve seen some comments that indicate that it’s not so easy to pass models back and forth.

The demos a bit long, and an interactive demo is always better, but this does take you on a pretty thorough tour of what can be done with their process pod. And, I managed to get all the way through this blog post without a reference to pod people, invasion of the body snatchers, cocoon or many other great sci-fi usages of the word “pod”.

Fujitsu’s been in the BPM market for quite a while, but in the past has focused on OEM relationships with their BPM embedded within another vendor’s product. They’ve made more of a push lately on their North American marketing, and part of that is a series of seminars that they’re conducting in a few cities across Canada: Toronto and Ottawa this week, and some western locations likely to follow. I attended the Toronto seminar this week, which was given by Carl Hillier, a former colleague from my long-past days at FileNet. Carl’s been with Fujitsu for over a year, and is now part of Fujitsu’s push to market their name as a BPM vendor. What I like about attending a presentation with Carl (besides the obvious heckling) is that he always has some good material that I can borrow for my own future presentations.

The 2-hour presentation had 3 sections: BPM 101, quantifying BPM ROI, and a quick look at Fujitsu’s Interstage BPM product. The product part at the end was really brief, about 15 minutes, and the rest was pretty generic and could apply to any BPM product. Except for one in-the-weeds section about the specific technology of Interstage, this was appropriate for both business and technology attendees, and the audience was split about 50:50.

He started with some interesting messaging about BPM: BPM is not necessarily visible, it may be customized to look like other applications, or may be implemented “below the waterline” within other environments. Although this has definitely been the case for Fujitsu in the past with their OEM tendencies, I’m not sure that this is true for most other BPM vendors, many of whom prefer to have at least some degree of out-of-the-box implementations where their product is highly visible. That being said, I am starting to see a lot of BPM tucked into portal interfaces, where it is less visible.

He had the usual high-level definition of BPM — automation + integration + optimization — and went on to list drivers for BPM:

• Dynamic business environment
• Lack of process visibility
• Regulatory compliance issues
• Inter-corporate collaboration
• Cost reduction
• Inability to sustain growth
• Complex process logic (i.e., you can’t freeze a complex process once created, it still needs to remain agile)
• Re-use best practices in processes

As he points out, the first deployment of a BPM project is just the beginning of the lifecycle: if your process will never change, then you may as well just code it in Java, but we use BPMS exactly because the process will change and we need greater agility. He also recommends (and I concur) against spending too much time analyzing the as-is business processes; remember that if those processes were so good, then you wouldn’t be looking to automate or replace them. The idea of any BPM project is to liberate the process from the application code, separating the process from the services and underlying enterprise applications. It’s not all about automating process steps; automation can be used effectively to reduce process latency and improve route determination between manual steps, as well as automate some steps.

He also discussed business rules, and showed a changeability spectrum with coded applications being the least changeable, processes more changeable, and rules the most agile of all — a view that I’ve been discussing in the crossover between BPM and business rules lately. He added an interesting distinction between auditing and logging when it comes to BPM: process auditing includes the data upon which decisions were made in order to later justify that decision for compliance purposes, whereas logging may just be recording the decision that was made.

He finished the BPM 101 section with a great slide on how to tell when you don’t need BPM: it starts with “your processes are really simple” and “your processes never change” (okay, I’ve heard these reasons before), then goes on to “you don’t care what your customers think” and through a series of other giggle-inducing reasons, ending with “you want a clumsy, complicated architecture”.

Keeping the light tone, Carl opened the section on quantifying BPM ROI by stating that “ROI is king…and not just in French”, a bilingual pun that I’m sure went over better when he presented in Ottawa later in the week. He did present an interesting list of the five E’s of BPM ROI (paraphrased here as I was jotting down notes as he spoke):

• Elevate business logic: reduce change management overhead, and minimize the requirement for users to know everything about a process by having the system enforce the business logic where possible.
• Eliminate process latency: reduce cycle time, increase productivity, and meet SLA/compliance targets.
• Enforce process integrity: disallow rule bending, ensure and demonstrate compliance, and allow rapid deployment of changes
• Enhance process execution: parallel processing, workload balancing, and location independence.
• Ease task execution: eliminate process errors, and eliminate what can be automated.

This is definitely a good starting list when you’re looking for the ROI in your BPM initiatives. He also explicitly talked about the ROI of integration between BPM and other applications: eliminating redundant data entry and increasing accuracy are the two big ones, but there’s also value in having the staff focus on adding value rather than re-entering data between systems.

He finished the seminar with a brief demo of Interstage: mostly a few screen snapshots and some slides about functionality, then a brief view of the simulation screens. Like several other BPM vendors, Fujitsu has a free download of their BPM Studio modeller (not sure if there are restrictions on the free version) as well as having a Process Designer applet that runs in a browser. Interstage, likely because it’s been used as an OEM product, seems to have a good balance of built-in functionality as well as the ability to easily integrate with third-party products that provide more robust functionality, whether it’s for content management or business rules. I haven’t looked at Interstage for almost a year (which I belatedly reviewed in June), but I’m sure that I’ll have a chance to see them next week in Las Vegas at the Gartner BPM show — an event where what happens in Vegas does not stay in Vegas.

Carl mentioned an Interstage case study at the end, and although it’s great when US companies try to show their support of the Canadian market, an Edmonton power utility company is a long way from the financial district of Toronto, both geographically and culturally. Even Google Maps knows that the shortest distance between the two is through the US.