Social and cloud are nice buzzwords, but won't solve the core problem. If you're not already using tools like wikis to discuss and communicate process initiatives, then you're a long way behind the eight ball. Cloud-based integration/processes are also of dubious technical worth, but they do have the benefit of letting you cut IT out of the picture.
The real problem is that crafting a business process as currently defined by technologists is programming. It's the crafting of a set of imperative instructions for a computer to consume. This might work for distributed programming (and BPEL et al are handy distributed programming tools), but it has some sever limitations when is comes to capturing the sort of things that business folk do day-to-day.
As I said elsewhere:
A business process is not a programming challenge. Programming is the automation of the known. Business processes, however, are the management and anticipation of the unknown. Modelling business processes should be seen as a (realtime) planning problem.
r.
PEG
Business process management has always been looked at as a scientific, analytical approach to managing workflows and interactions across the business. But lately, there have been movements to bring BPM into the social sphere, as well as the cloud.
Front-line workers are rejecting processes pushed down by technologists.
As part of ebizQ’s recent BPM in Action conference, I had the opportunity to moderate a session with Clay Richardson, analyst with Forrester Research and highly regarded BPM expert, and Kieth Swenson, vice president of research and development for Fujitsu.
Richardson said many BPM efforts start out with the most optimistic intentions, but are eventually beset with disappointments, resulting from a lack of communication and coordination between various teams in the organization. In the process, such efforts end up taking months. “How do we eliminate these consensus logjams?” he asks. “The biggest challenge they face is they’re bring teams together from multiple functional areas. It could take months.”
BPM’s heritage goes back to the “legacy ‘[Michael] Hammer and [James] Champy‘ style business process re-engineering; focusing on idea of re-engineering opportunities being identified by management. So management is coming in and saying ‘this is the way we can improve those specific processes — and then having those processes changed and automated by technologists before pushing it down on front-line workers. We saw the results of that. The front-line workers did not accept the final process.”
Social BPM may change this short-circuited process, Richardson says. As a result, a revolution is underway. “What were seeing in the process world is this idea of process populism,” he explains. “Last year, when I would speak with process pros or business stakeholders, they almost sounded frustrated, almost sounded like they had pitchforks in their hands. They’re going to IT and saying ‘we want more control. We’re starting to see more demand from business, instead of relying on IT.”
Richardson cited the example of a financial services firm that has had extensive BPM efforts underway for a number of years. “They’re very sophisticated with BPM; they are pretty advanced, and have multiple BPM tools in-house.” However, he adds, they were having issues with employee acceptance of BPM-driven initiatives. “They were really trying to increase end-user involvement, to get the end users to provide feedback, so when they rolled out business processes, they didn’t have this slow or low adoption of business processes.”
The solution was a relatively low-tech one, Richardson explains. “They used wikis, combined with the BPM suite. It allows users to tag and also provide feedback. In this case, they were setting up an electronic watercooler, which is a very simple thing to do. But it definitely brings more voices in.” The company improved their adoption rate across processes.”
Another interesting development underway is the potential of delivering business processes via the cloud. However, there are still plenty of questions about the riskiness of doing so. Such issues were addressed at an informative and stimulating panel discussion led by David Linthicum as part of the conference. Dave’s panel consisted of of Rajiv Onat, senior product manager at Fujitsu America, and Phil Wainewright, cloud/SaaS expert in residence here at CBS interactive/ZDNet.
Phil sought to dispel many of the reservations business leaders have with cloud computing, especially in the areas of performance and security. Performance, for one, is a product of architecture, not of network bandwidth. “I think people overestimate the significance of bandwidth,” he explained. “It all depends on how the application and the infrastructure is architected. You need to avoid massive architectures, but cloud architectures normally are architected. They communicate in a much leaner way, that are more attuned to a wide are network network. Once people embrace the cloud, they find that’s a fear that goes away. In fact, the accessibility for all their user base because the cloud is better in reaching out to those remote users.”
Phil also observed that not every cloud application or process needs to be run at 99.99% availability. “People often talking about SLAs if they want only the best,” he illustrates. “If you insist on 99.99% availability, then its going to cost a lot more than if you go for 99.97%. You need to think about which of your processes need that availability. One of the benefits of the cloud is that you can choose different platforms.”
An effective on-premise-to-cloud migration of processes needs to start slowly and incrementally. “Start with a simple proof of concept with the cloud providers,” Rajiv said. I suggest developers build something simple and quick, then lobby it to their internal users and get user buy in, so they can see the immediate impact.”
Process development — be it in the cloud or on-premise — should not take more than 30 to 60 days, Rajiv added. Cloud resources may help speed up this process, while providing greater consistency.
“Identify the low-hanging fruit, those processes that you require high visibility on,” he advised. Take a business process that is not automated, and is in the IT backlog.”
