We had a short session just before the morning break with He-Who-Must-Not-Be-Named from a large US-based automotive company discussing their BPM projects. They’re implementing multiple BPM projects, including an engineering resource change management system, and are even using BPM to run the program of BPM projects.
Next up was a panel with Rod Favaron, Phil Gilbert and three customer executives. One of the panelists made a crack that this was either like the Dating Game or Oprah, so I’ll just refer to them as Bachelor #1 (from the afore-mentioned automotive company), Bachelor #2 (from a global, Fortune 500 logistics and relocation company) and Bachelor #3 (from a mid-western US travel company). Instead of prepared presentations, this was structured as an audience Q&A session.
Bachelor #3 responded to a question about the teams required for BPM by stating that you don’t need your “best” developers (by which I think that he means the hard-core Java developers) to do BPM development, since the development is lightweight compared to other development projects that you might have going on. Interestingly, I had a conversation with a customer at the break who has found that they have had to do a lot of custom UI work not because the Lombardi tool lacks functionality, but because their user community is accustomed to having a specific look and feel for certain applications, and is willing to pay more and wait longer to have custom interfaces developed that will eventually result in longer and more expensive maintenance cycles. I’m not at all surprised by this, since I see it all the time at my customers; although I always try to put forward the “take it out of the box and use it naked” philosophy, some companies don’t consider the trade off between the one-time hit of having employees learn a new system versus the ongoing costs of custom systems.
In response to a question about using a BPMS versus off-the-shelf software versus custom build, Bachelor #2 talked about how they use the BPMS to manage change and manage risk better, since there’s little off-the-shelf software that addresses their core business needs. They had 23 different processes across 3 legacy applications plus manual procedures, and are gradually replacing the processes in the legacy systems. #3 added that BPM also gives them connectivity across the enterprise, that is, connecting up the siloed packaged applications within different functional areas. #1 said that there are many areas where BPM should be a part of a complete solution that will combine custom-built services and packaged applications in more of a hybrid solution.
An audience member asked what to you do when the BPM projects start to move from being a business-led process improvement project to an IT development tool. This was interesting, because of Rod and Phil’s earlier statements that we’re in an era of IT-led BPM programs, and they seemed to think that this was a good thing. The customers, however, still think that business should be driving this: #3 feels that bringing together business and IT and eliminating the boundaries between them is the key to pushing this to a collaborative effort, and #2 concurred and stated that both the business and IT parts of the BPM projects report up to him, the CIO. Phil chimed in that there’s a need to break the usual application development mentality; the key thing is that if IT sees BPM as just another application development tool, it will fall into the domain of IT, but if business and IT both see BPM as a tool for collaborating on process implementation, then it will remain a cross-functional responsibility.
There was a question about failures and lessons learned during their Lombardi implementation. #2 said that they were too ambitious in terms of project scope, trying to take on too much in their first projects. #1 agreed with this, saying that the minor exceptions during those initial implementations slowed them down and forced them to reduce scope. #3 said (pointing out that this was more of a lesson learned than a failure) was that they should have started the process instrumentation earlier.
The final question was about using the BPMS as a system of record: #1 said that it’s their philosophy not to use the BPMS in that way, but to push all permanent data back to the core systems, although transient data may be persisted in the BPMS until a process instance completes. I agree completely with this, and am always uneasy when a lot of data is unnecessarily replicated into a BPMS and not synchronized back to the core operational systems.