Usare strumenti "pure BPM", come Teamworks, permette di utilizzare un nuovo approccio allo sviluppo applicativo: coinvolgere gli utenti nello sviluppo.
Leggete a questo proposito cosa scrive Phil Gilbert nel suo blog.
"" In his recent post, Neil Ward-Dutton talks about how WebMethods customers are doing traditional application development under the guise of Business Process Management. Folks, automating a business process is NOT business process management! Sandy Kemsley says "these customers are coming from the traditional EAI-type usage of webMethods." Yep. And, in summary, Neil says:
"Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work—is it business people, IT people or both?
"Unfortunately, getting to the bottom of things is not as simple as saying 'I need a human-centric BPMS" or "I need an integration-centric BPMS'."
Neil, you've hit the nail on the head! And, indirectly, you raised the key difference between what used to be called "the pure-play vendors" (like my company, Lombardi) and the "stack vendors" (IBM, BEA, Tibco, WebMethods). I prefer to use the terms "new-BPM" and "old-AppDev" to describe the vendors, but however you slice it, the new-BPM tooling is directly targeted at enabling new levels of participation of business people alongside IT people in the solution scoping and development processes.
As you point out, that difference has nothing to do with "human-centric," "document-centric," or "integration-centric" but whether the user is approaching use of the BPMS as a new developer tool (with, for example, the semantics of BPEL), or as a way to change the way business and IT interact during solution development. This developer-centric vs. business-centric approach is the key difference in deciding what tools you will be successful with.
Our experience is that if a company uses a BPM tool in the same old way (IT application development owning all aspects of the project and the business expected to deliver a set of detailed requirements at the outset of the project) then the project will fail exactly as often as any traditional waterfall application development effort. Which is fairly often.
But if the customer wants to move to a new model for those processes owned by the business, with the business contributing people full-time to the solution development effort, then the new BPMS tools are effective at increasing success rates, lowering costs, and delivering better solutions. The new BPMS tooling by the focused BPM vendors is better at this, far better, than any of the tooling the stack vendors provide. The old-AppDev vendors provide tools for their target market... and that is not business people with moderate technical skills. In contrast, the new-BPM vendors are focused on providing tools for a new solution development model, one that promises increased participation by the business, while retaining full-control for IT. ""
Nessun commento:
Posta un commento