There are different styles of processes, and the techniques to handle those will have to differ. And all will continue to exist.
When a business process culminates in a transaction that has the organization as the beneficiary, they will find a way or the other to keep track of it, and not let the ball drop. But, not so much otherwise. When you see a broken process, problem lies mostly with focus and priorities; not with their ability (technological or managerial) to manage processes.
IBM have published a new research topic and standard called BEDL (Business Entity Definition Lanuage), the theme is Data4BPM. But, this is Data modeling redux. And please do not call this as Data4BPM – right concepts that always existed but not applicable to current state of BPM! Read to know why…
With so many perspectives at play and with BPM community comprising multiple sub-communities with heterogeneous views, it is darn too difficult to define BPM that covers all the aspects and still satisfies everyone. When it comes to defining BPM, it will always be in a certain context and when a customer looks for the right definition the question that needs to be asked is – what’s your business’s objective, and what’s the problem you’re trying to solve. BPM, at the end of the day needs to make the business more agile &responsive and business processes more efficient and flexible.
My daughter knows very well she’s not actually a Doctor and is just playing with her Doctor’s kit. Can we stop playing with these investments in BPM(S) and actually practice BPM? When tools become everything – it’s not business, it’s child’s play.
If Incremental Improvement is so much loved by business stakeholders, it’s not because BPM cannot do otherwise, they just like it that way! As for Innovation in BPM, We are at a point of time which is most conducive in recent few years for big leap innovations in BPM – as discipline & as technology.
I have seen many a successful BPM solution that has been more so in hindsight. And a lot of hyped up solutions/initiatives that started off as BPM solutions ended up as duds. What’s important is to remain true to the BPM drivers and objectives. And that is, to make an impact on customer experience and measurable parameters that really matter. If you do that, you will end up doing what’s best for the objective, call it BPM then if you wish! Pre-qualification of a problem (as a BPM candidate) or solution (as BPM implementation) isn’t as important as it seems.
In the initial years of BPM, we thought we had few problems that would slowly disappear with maturity in the discipline / technology. Come 2010, and we are dealing with more variants of similar problems. Depending on where you look from and where your stakes lie, this could be a case of blurring boundaries or of significant convergence in BPM ecosystem as illustrated here. Can we all “converge” and leverage on our best opportunity in recent times to really take BPM to where it belongs?