Gartner BPM always includes sessions for the vendor sponsors, and most of them are smart enough to put one of their customers on stage for those presentations. This afternoon, I listened to Manoj Kumar of AmerisourceBergen, a Metastorm (OpenText) customer discuss how they used BPM as an alternative to customizing their SAP system, as well as to streamline and improve their processes, and enforce compliance. He went through how they built their business case: demonstrating the BPM tool, surveying departments on their business processes and how they might benefit from BPM, and some analysis to wrap it all up. He also covered the business and IT drivers for creating a BPM center of excellence, with a focus on alignment, shared resources and reusability.
Building the execution team was key; with a model-driven tool, he didn’t really want “hard-core developers”, or even people who had used the tool before, but rather those who could adapt quickly to new environments and use model-driven concepts to drive agile development. Having a focus on quick wins was important, rather than getting bogged down in a long development cycle when it’s not necessary.
They also had considerations about their server infrastructure, and since they were using BPM across a wide variety of decentralized and non-integrated groups decided on separate virtual machines that could be taken down without impacting anything beyond the specific departmental process. This seems to indicate that they didn’t do much end-to-end work, but focused on departmental solutions; otherwise, I would have expected more integration and the requirement for shared process engines. When he showed his process stats – 200 different processes across 3000 users – it seemed to reinforce my assumption, although they are doing some end-to-end processes such as Procure To Pay.
He strongly encourages taking advantage of the BPM tool for what it does best, including change management for processes. They’ve obviously done a good job of that, since they’re managing their entire BPM program with 4 people on the implementation team. He recommends not allowing developers to write any code until you’ve prototyped what you can in the BPM tool, or else their tendency will be just to rewrite the BPMS functionality themselves; I am 100% behind this, since I see this happening on many BPM implementation projects and it’s a constant battle.
With an SAP/BPM integration like they’ve done at AmerisourceBergen, you need to be careful that you don’t get too carried away in the BPM tool and rebuild functionality that’s already in SAP (or whatever your ERP system is), but using BPM as a tool for orchestrating atomic ERP functions makes a lot of sense in terms of agility and visibility, and also provides the opportunity to build processes that just don’t exist in the ERP system.