It’s another episode of The Dating Game, with three customers who mostly don’t want to be named, although I’m sure that you already know about the detailed breakout session agenda. The topic here is how different companies structure their BPM teams.
Bachelor #1 (from a large US-based automotive company) discussed how their BPM team is a split of business and IT working collaboratively. Bachelor #2 (from a global, Fortune 500 heavy equipment manufacturer) is part of a process center of excellence, also made up of business and IT working together. In both cases, they stressed how having the business and IT people on the BPM team collocated is important in ensuring that there’s the right degree of collaboration: if you’re right beside each other, it’s much easier to take advantage of the casual interactions that can occur.
Bachelor #2’s company is starting to push the creation of processes further into the business side of the team; he said that they have some processes now that are not touched by IT at all until final review and deployment, which is the rarely-realized vision of every BPM vendor and customer.
Bachelorette #3 (from a global semi-conductor company) is using the playback session technique for working with their users in order to float new ideas and get early feedback, which they have found to be a key to success. This is similar to Agile methodologies where users are involved early and often in order to fine-tune the development to meet changing user needs and wants, set priorities on customizations, and avoid any huge surprises when the system deploys.
The issues that they have include insufficient internal resources, trying to standardize processes across business units (especially in different countries), and the division of labor between the different team members, although none of these appeared insurmountable. There was a discussion around the problem with upgrades and changes to the business process, and seem to have found that they have to flush out their process before upgrading the process; this is expected to be addressed better in future versions of Teamworks, but this is a difficult problem that not many BPM vendors do well.