BPM implementation best practices – part V

No pain no gain. Yes, it is sometimes painful for BPM developers who generally come from programming background to use only the out of the box features. All the BPM platforms are open and provide some mechanism of customization of user interfaces or other features through programming in native languages they are built on. BPM platforms are still evolving and as a result, it is likely that support for such requirements may not be fully possible out of the box.

In such cases, it is advisable to restrict internal expectations to the extent of the available features. Any BPM Program success requires a very careful attention to design and architecture of the solution to ensure maximum use of out of the box feature that easily separates customization that can be easily replaced when a particular feature evolves.

Typically, designers or developers approach implementation with a “get over with it” mindset. Such casual approach has long term and serious implications in fulfilling promises of BPM platform, by rendering outcomes that are very difficult to maintain, with loss of agility and problematic future platform migrations.

One of the major issues that almost all BPM customers have is, difficulty and migrating from one version of BPMS to newer as well as ability to change processes. Both of these issues can be significantly addressed through effective use of out of the box features rather than taking easy customization route.