In my last article (www.ariscommunity.com/users/frank-weyand/2009-08-14-bpm-tool-future-how-should-it-look) I discussed the extension of a BPM tool with functionality for "daily work", so the frontiers between BPM tools for documentation and tools providing ERP functionality vanish.
So, furthermore, I name it "BPM platform".
If we've got a BPM platform providing the possibility not only to document processes but also to execute them (by programming or modelling executable processes), the next logical question is: who will provide new processes for the platform?
Rising of a new market?
At this point, there could be a whole new market for the BPM platform. Logically, the "owner" of the running instance is able to do the implementation of new processes concerning his/her own needs. In addition, there will be a market for BPM experts and consultants to help the customer to do so.
But, equivalently to software development, this would be individual "development" (well, not software, but processes). But also, equivalently, since there exist "standard software", why couldn't be there also "standard processes"
Standard processes - best practices, executable on your BPM platform
Let's say, BPM experts develop a whole business scenario using the BPM platform. Using the features of the platform for testing and analyzing, these processes can be simulated, calculated, tested and quality approved.
And then - sold. So it is not standard software, but standard processes developed by BPM experts and - by continuous improvement - be best practices.
Why "plugins"?
In the headline, I wrote "Process plugins". I liked to use the term "plugins" because that describes it IMHO perfectly: you've got a system running, and you can add additional business scenarios like plugins. You buy them, you import/install/deploy them and you can run them. That's it.
So, like it is quite usual in the ERP market, it can also be possible to have such a market growing for a BPM platform. I think, we can be quite curious what future will bring for the BPM market.
IMHO. The main target of BPM among other is to get competitive strength by developing and implementing unique technology (processes) and methods (that competitor has not).The referent model (plugin, any other term) is so to say the best practice (but who has said that it the best?), that on the moment of implementation is out of date for some future years! It means that the companies modelled for this “best practice” already leave behind for some years their competitors ;)
Yours faithfully!
Hi,
yes, I agree. The only thing is, what you describe is the individual "development" of processes, or did I get it wrong?
The idea of the market described is that "collections" of processes to be used for complete business scenarios could be developed once, tested (simulated and there costs and efficiency could be calculated) and implemented multiple times.
This would allow BPM experts to sell there business solutions (implemented as executable processes) to multiple customers, like software developing companies sell there software to multiple customers also.
Bye,
Frank
Hi,
Alexander has picked up an important point. The main objective of BPM is to get the competitive edge over the competitiors, but Frank your idea of marketing "Collections" of processes is also has its own business vision. If we can club best of both point, can't be work on defining some base processes or frameworks which can be common to the domain or industry. This base package will give an intial kickstart to development and obviously later on you can add custom "Plugins" to get some edge in the market.
This model is in product industry from quite long, probably we can think of something in BPM now.