Start a Discussion
BPM
user-pic

Is BPM now just business process automation?

Vote 0 Votes
Suggested by Scott Menter: Is BPM now just business process automation?

14 Replies

| Add a Reply
  • I'm sure the Vendors would like to sell us this.
    I'm sure the Analysts would like to tell us this.
    I think we all know otherwise.

    BPM has become synonymous with automation and integration. It's an unfortunate legacy that it's currently finding hard to shake. Even the CEO of Salesforce thinks this is the case, he sees no real value in BPM in the CRM world because of the picture it's painted itself over the years.

    Now BPM seems to be moving from being automation and workflow into application platforms and application builders, with a process layer to control it all from the inside. Gone are the days of flowcharting, they are consigned to BPA mostly now, the bread and butter of BPM practitioners who are always the last voice to be heard in all of this.

    BPM was grounded in practice, you cannot ignore these roots. Something analysts and vendors seem to have forgotten entirely. They've failed to bring the practice of BPM in the evolutionary journey. Look at Six Sigma, Lean, and countless other pseudo-methods, they're based in the past when the world has moved on.

    But back to the point and question in hand.

    No, it's not just business process automation. If you think it is, then that's all you'll ever get from it. More fool you for believing the direction you let the analysts talk you into.

  • Why "now"? It always was and still is for a great portion of vendors and prospective users. For the majority I'm afraid.

  • I find your statement very limiting while I see BPM having few limits.

    BPM combines tools and methodologies to create web and mobile-based apps resulting in process automation, compliance, and rich data for reporting and business analytics. BPM not only covers transactional processes. It is used to streamline dynamic, adaptive, ad-hoc, case-based, goal-driven, and task-oriented workflows. It is for creating visbility into your entire organization so as to make better, faster decisions.

    There is no just anything about BPM. It continues to grow in scope and capabilities.

  • As I lately read some articles (by people who speak on bpm seminars) saying that BPM is a technical layer between the user and all applications, I am afraid most would answer this question by yes.

    Truly believing BPM = BPMS, would make my life so much easie ;-)

    But I don't believe that and I hope we can get rid of this assumption as soon as possible.

    BPM has been done for ages; even when there was no electricity. How can it be automation by software then?

  • Lets turn this on it's head. What's the opposite of Automation? The answer is; using PEOPLE (our highest cost), to do the work that computers are perfectly capable of doing IF we get the integration (and automation) right.

    So how do we take the manual human effort OUT of the equation? Because if we do, the ROI and significant other benefits (faster, fewer (if any) errors, consistency).

    The fastest and most agile way of doing this is to use Human Interaction Optimization technologies - Where people and technology meet. Enter Desktop Automation.

    Let me give you an example. Desktop Automation being used at large bank doing back office work. In this case, 50 desktop workers are now doing the same amount of work in a day as 300 desktop workers would have taken to do it. We just identified the low hanging fruit of the key manual steps and automated them.

    Look around you. How many call center or back office or front office workers do you have, doing the work the computer should be doing? Eliminate that problem first.

  • No it is not! but yes it is still very hard for those with other views to get their voice heard over the vendor noise. For example are you aware that over 50% of organisations involved in process improvement are not doing anything with automation?

    The fact that BPM is so closely wedded to technology is actually one of the barriers stopping wider adoption. There are many who do process work and would benefit from the discipline of BPM and certainly from better managing their processes. However, instead of seeing BPM as an option, they continue to walk their own path. Why? because they keep hearing that BPM = automation and therefore are not interested in it.

    I prefer to ask, why is it that the solutions available today fail to address the definite needs over over 50% of the community. Technology is supposed to support people not the other way round, so change the technology and make it more acceptable.

    As an aside if we simply work on the assumption that the purpose of technology is to replace people and put them out of work then we will encounter more resistance than ever. Why would any of us want to cooperate with anyone who wants t pout us out of work? Be careful what we wish for.

    I spoke at length some years ago in India on the lack of traction for BPM technology in that country. One of the reasons given was that in order for their country to move forward they needed to create jobs, so that people could earn wages and lift the standard of living for as many as possible. Several CEO's commented that if BPM equalled automation it would be flying in the face of what they saw as their social responsibilities.

    • That's disappointing, because I see BPM as being entirely consistent with one's duties as a CEO. BPM isn't about eliminating jobs, it's about improving the one you have by enabling you to stop running errands for your computer.

    • Oh yes, automation can absolutely support Managing by Process, but it is not the same and absolutely not the whole story.

      You can see process automation like workflow. But a performing process does not only need a flow of work.

      You can see it as desktop automation. That only makes you efficient in doing a little parts of the process.

      You can see it as BI, tools that (should) show you process performance (on operational and tactical level). But that's only seeing, not adapting.


      So on several parts automation can really leverage MbP, but it is not the same, it is just one of the enablers.

      Like buying the most expensive soccer shoes doesn't make you a match winner automatically.

      As long as organizations are not aware what real MbP means and what it needs, automation indeed seems the simplest step to start with it. Clicking setup.exe and we do BPM.

      And as most of these projects probably will not deliver what was expected, that's bad for the name of MbP.

  • Far be it from me to interrupt all the vendor bashing going on here, but... :)

    I work for a BPM vendor, and yet I for one would like customers to think of our product as far more than an automation tool. We've put a pretty substantial investment behind making it much more than that, and the more customers realize the value of what we've created, the better we think we'll do in the long run.

    But let's face it: simple automation provides an impressive return on investment. It's pretty hard for customers to get past the wow, I just reduced this process from 2 weeks to 2 hours and start to look at how BPM can actually give them insight into their business.

    BPM is exactly what its practitioners make of it. If that's pure automation, great: there's plenty of gold in them thar hills. It's up to the people who read and comment on this page to help organizations understand that there's more yet to be discovered.

  • People have always used many different meanings for the term BPM. I think originally the idea was grander, but in recent years the predominant meaning of BPM has become nothing more than automation of routine processes, something I describe as "Process Driven Server Integration". There are still vendors and analysts pushing for "Human Process Integration" and for "Management of Business Processes" the fact is that these categories have lost out in the public discussion groups, particularly the SOA folks who insist that BPM is just PDSI. It should be much more.

    I found people using seven different meanings for BPM, and documented this in the following blog post.

    http://social-biz.org/2012/04/25/not-to-praise-bpm-but-to-bury-it/

    For the time being, I am avoiding use of the term "BPM" because it simply is too poorly defined to be useful. When someone mentions BPM, I always ask them to clarify which kind of BPM they are referring to. If they represent a vendor, and respond with "we support all kinds of BPM", then I politely change the subject.

  • BPM is a” discipline" a "mind set" that focuses on putting people and their processes as priority. Garth sums up where it can be used indeed it will extend as described in this interesting blog http://confusedofcalcutta.com/2012/06/17/continuing-with-the-social-enterprise-and-flows/ which puts forward the idea of “collaborative flows” as organisations move to the social enterprise.
    The old Enterprise Software model is well broken and has left organisations in a real mess. By adopting the BPM thinking we can start to tackle delivering simplicity and agility. The removal of coding to build custom solutions as described here http://infullbloom.us/?p=3222. should in theory make BPM supporting technologies dominant in next generation solutions but there are huge vested interests that will resist!

  • Another example of why this statement unfortunately seems to be true:

    http://bit.ly/NYF3zF

  • user-pic

    Dear Scott, Francis,
    I am a techncial architect and I work for a service integrator and I understand where you are coming from and agree with your statements. The issue is client's are trugger happy 'they are satisfied with simple process automation'. The don;t want us to spend time in analysis phase where we can understand the business and bring better value then do process automation of low hanging fruits. The other issue is also that we do not have enouoght trained people who understand the capability of the BPM tools (our fault and to some limit vendors fault of not educating the masses and not providing enough samples). With each new version of the product their is a mad rush to implement something and show the value add. I wish we get client who had time to analyse the problem, understand the tool capability, spend more time on process decomposition and then implement a really cool solution. I sometimes use vendor videos to demonstrate the true capability of the BON suit and then start discussing the proposed solution and it helps us propose better solution.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT