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.
Hi Sandy,
Just wanted to clarify something you said in this post and the last one. The point about IT-led process implementations being the normal state today isn’t something we advocate as being a “good thing” but, rather, it simply is a fact. The vast majority of real BPM projects today are led by people in IT, and further, IT is the part of most companies that currently holds the reigns on BPM proliferation. This isn’t [necessarily] good or bad… it simply is.
Now as you wrote in your previous post, we see this as a transitional phase. First – some 6 years ago – BPM tools were used to solve single, business-led solutions. In many of these cases, the BPM vendor was _perceived_ as simply delivering a custom solution. The enterprise wasn’t “buying BPM”, they were “buying a solution, based on this new type of tool.”
Now we’re seeing companies “buy a BPMS” or “adopt BPM” and disproportionally today it’s IT that’s leading the charge. And, yes, we see many more IT organizations today that have the cross-functional visibility and maturity than we see in business departments. This obviously is _not_ good. In order for the “next level” of BPM to take hold, the maturity to implement structured change inside the business _by_the_business_ must get a lot better, so that cross-functional dependencies and efficiencies are better understood, and then improved. The closer business can get to implementation of the project and the program the more latency we can take out of the “improvement machine.”
In the future – when we reach BPM nirvana – we will have common competencies and maturities _throughout_the_organization_ as relates to the management of the core, differentiating business processes. But we’re not there today and that’s the core message of Driven: what tools exist to facilitate the cultural shift from IT-led efforts to, in Rod’s words, “one team.”
We’re in a period of transition and the question isn’t whether BPM moves more intimately into the business, but when. We’re out to help that happen as quickly as possible.
Thanks,
Phil
Phil, thanks for the clarification. I agree that we’re in a transitional time; the challenge will be wresting control of the BPMS from the hands of IT.