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.
The biggest thing I always wanted to steal from Carl’s presentations: his accent.
Ha! Too true.
What I find really, really interesting about Fujitsu and BPM is that they are in fact a customer of Metastorm and use Metastorm BPM. If they have their own BPM product, what on earth possessed them to buy a competitor’s product?
(The answer is NOT to steal the technology, BTW, I happen to know someone on the team there, and they are really using it.)
Fujitsu’s a huge company, I imagine that they have many products that they’ve bought and used internally in one line of business that might be considered competitive to other lines of business their own company.