I recently wrote about a survey that shows that more than half of companies do not designate a specific group to lead business process management (BPM) initiatives, instead spreading the responsibility among IT, finance and operations, and other business areas.
In that post, I wondered whether the longstanding debate over whether the business or IT is best positioned to lead process improvement efforts contributes to the apparent difficulty in tapping a BPM leader. What I didn't say, but should have, is that the lack of a clear-cut BPM leader can also create conflict between the business and IT.
In a November interview, onStrategies principal Tony Baer told IT Business Edge's Lora Bentley that while most folks agree that the business should be responsible for process definition, it gets more contentious when activity shifts from definition and modeling to implementation. He said:
For IT and the business, BPM is just another venue for playing "he said, she said." The business has always believed that IT does not understand the semantics of business processes, while IT believes that the business has no conception on what it takes for automated business processes to execute successfully.
A service-oriented architecture may help bring the two sides closer together, said Baer, because it "facilitates abstracting the process from the underlying application silos that contain the piecemeal business logic." Since services are self-contained in a SOA, developers or process designers can dynamically build composite services that implement business processes, which lends a welcome layer of agility to BPM. He said:
Obviously, you don't need SOA to implement BPM, as BPM, the discipline and technology, predated today's SOA-based technology products. But the architecture of SOA makes it an excellent deployment approach to BPM.
SOA makes it not only faster, but cheaper, to automate or otherwise modify processes, contends Dan Woods, CTO of Evolved Media. Writing in Forbes, Woods notes that it won't do much good to redesign processes if costly IT infrastructure changes are required to implement them. He also offers several tips on BPM and SOA. Among them:
- Both manual and automated processes should be described. "Too often," writes Woods, "BPM programs become about drawing lines with fancy visual tools that are focused only on automation."
- Focus on modeling and optimizing the processes most likely to yield transformative results. While a generic box is OK for models of processes like "payroll system," you'll want to see lots of lines, boxes and more specific details for more strategic processes.
- Don't try to use SOA everywhere, just in areas where added flexibility will provide the biggest business benefit. Writes Woods: "If your long-term plan is to service-enable all of your applications, you may be delusional. This is way too much work."
- Appoint a business process expert to facilitate communication between the business and IT. (Woods calls this role a BPX, which makes me crazy, but that's OK.) He writes: "BPXers advocate for the business process perspective -- keep BPM in charge and then use their sophisticated empathy for both business processes and technology to keep the flow of communication going between business and IT."