Posted by Szymon Drejewicz on Saturday, March 5, 2011 - 11:14
What BPM tool is the best for full BPM cycle (analysis, simulation, deployment, publishing, monitoring, optimization)? Please drop a line about your opinion.
A BPMS should always be 'compatible' with other analysis and design tools and version control/configuration management tools. By this, I mean that the lowest level business processes should be exportable to the requirements management system and be linkable to system/project requirements (Use Cases/User Stories) This does not have to be in an Agile environment! I'm a little unsure as to what the Technical reference architecture brings to the decision other than maybe to the ease of access to models.
I would also agree that the BPMS tool selection should be at the Enterprise Level, yet I can not help but wonder about the larger question, should not this selection be made in regards to the enterprise tool set. Moreover, it seems that a tool selected in the context of a project, opens door for somewhat of a fragmented approach to BPM, which seems self-defeating, to the whole idea of BPM. Another though regarding the long term capital investment, this for me begs the question! Can one be confident in the selection of a tool, with out a reasonable Technical reference architecture?
Imho a "real" BPMS is intended to manage the lifecycle of Business Processes as assets. As this lifecycle lasts multiple years a BPMS is a capital investment for the longer term, that requires -apart from the tooling itself- for an investment in the governance organisation and alignment with the strategy of the enterprise. This goes also for smaller companies and departments. Even though some BPMS vendors offer low-scale license policies, the question should be asked if a BPMS is the right (sized) solution for a small scale short term solution. What are the characteristics of the solution, what are the drivers (e.g. flexibility, adaptability/extendability, time-to-market, process-insight, process control etc) to make it a BPM solution instead of a conventional application or simple workflow solution. [Updated on 3/15/2011 1:11 PM]
I agree with that Harald, but how would that work for smaller companies and organizations that have a specific need that isn't organization-wide and budget only allows for a finite amount of resources and tools? Having a strategy applies when there is a vision to improve how the enterprise functions utilizing BPMS as a way to realize certain goals. Not all companies have this ability and would be satisified with smaller scale solutions that would suit their needs for a few years. In both cases, selecting a tool, approach, and solution needs to be carefully analyzed keeping into consideration the end goal that the client needs to achieve in order for them to improve.
The selection of a BPMS should be done by enterprise architecture. I think a BPMS should never not just satisfy a single project, but a complete on strategy based program.
To find the best BPM tool, the size and complexity of the project would is an important determining factor. How robust is the application? How many users will be using it? What are the requirements for portability and interfacing with other applications, databases, etc... With that in mind, the best tool based on it's capabilities to satisfy the project needs could be selected.
|
||
|
