We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Why Hasn't BPM Taken Off Like ERP or CRM?

Vote 0 Votes
Taken from a very active discussion at LinkedIn titled, Why do you think BPM could not take off like ERP or CRM? Your thoughts?

23 Replies

| Add a Reply
  • BPM cannot generate large enough projects (multiple $ m) for the big consultancies. And it is they who generate demand in clients. Look at the growth of Siebel.

    The only company that has broken through without BIG4 consulting support is Salesforce.com

    Selling into a known space (CRM), with a compelling proposition (Cloud) which enabled a "below the radar" / "land and expand" approach, but fuelled by collosal amounts of VC.

  • ERP is believed to be a necessary evil; CRM is easy; While BPM is disruptive. BPM crosses departments making agreement difficult. And, people hate change...

  • I think its a simple answer. CRM is an easy sell. Why? Well a vendor can demonstrate very quickly operational efficiency and the benefits to your customers in a way the busines quickly and easily understands.

    With BPM it is far tougher to do this, it is hard to show business users just what the benefits are to them and their customers. Also, to some extent, other software solutions, such as CRM, claim to have BPM or workFlow within them, helping show process efficiency. This means companies then do not choose to look at BPM because they believe they have it, or what they have isnt great so why invest in BPM...

    BPM is more abstract and because of this harder to communicate. If its harder to communicate then its harder to sell...

  • Because BPM is not about a product. You can't buy BPM, or have it done to your organization [though that's not stopped the usual suspects from selling it].

    Organizations are commonly managed by function, or by region, or by product line. BPM is about developing organizational capability to be able to manage in a fourth dimension: end-to-end process.

    The endpoint for BPM is sustainable operational excellence.

    It has essential enablers - a process repository, a common language, a governance framework, a means to synchronise the two complementary views of the business: the business ops view and the EA view. And it enables higher levels of business-led automation. But ultimately BPM is more about a new way of thinking, a new discipline, than about shoehorning an application into the business.

    Because it's more complicated, and not financed solely from IT budgets, it was never going to 'take off' like ERP or CRM. But its long term impact will be greater than both.

  • Mike has hit it on the head.
    I'd say that BPM is taking off - but every "market" is different. EAI took off and flamed out. CRM has had more than one wave of "taking off". BPM has been more of a slow burn than a tidal wave, but the momentum seems to keep building, as people realize the benefits outweigh the difficulty of addressing organizational challenges, challenges to our way of thinking, and our way of approaching the business.

    I actually think that the fact that budgets often come from the business side is a good thing. Keeps all of us in the ecosystem focused on business value, keeps the BPM projects accountable to the business. The business needs to drive the process improvement, and IT needs to be consulting with them on how to adjust systems and software to support the changes.

  • ERP and CRM are implementing key functions of the Enterprise as applications suites. Ready-made processes are implemented in applications. Some customization is possible. T

    BPM is the discipline of process modeling, improvement, management etc. It does not make much sense to model processes that come reliably embedded in many Off-The-Shelves applications, at an affordable price tag, since you would have then to design own software to automate them. That may mean high costs and long delays.
    As such BPM is mainly applied to document high level flows for comprehension rather than automation reasons. These models often end as shelvesware.
    A BPM analysis would be done though to integrate your ERP and CRM.

    Of course, there is the BPMS (BPM Systems) side which is about the end to end process/flow orchestration and applications and services integration (SOA, ESB, EAI); BPMS is quite necessary and successful.

  • The difference between ERP, CRM and BPM is that ERP and CRM have natural owners who have a major stake in the system and associated output. In the case of ERP, it was the IT department that was confronted with disparate systems that they were directly responsible for managing and the task of delivering information to the business owners. Even though each of the individual systems was owned by a specific department (financial systems owned by the finance department, personnel records and systems owned by HR, etc.), CRM systems were clearly owned and driven by sales. The growth of Salesforce.com is a great example; Salesforce allowed salespeople to independently sign up and use the service without having to involve IT or any other organization. The early adopters knew it was a significant advantage for them to have robust accessible CRM to help them manage their sales process.

    In the case of BPM, IT tries to own it but they don't understand the business side's processes. Therefore, they force business users to endure long meetings to extract business process definitions only to deliver an estimated solution.

    What the business needs is access to BPM solutions that will allow them to design, build, modify and report on the processes themselves, much like how Salesforce.com made CRM available to everyone in every department.

  • There are a lot of good reasons given above I agree with. Rather than reiterate here, let me focus on one aspect.

    BPM suffers because it "seems like it should be so easy", in the same way that "Artificial Intelligence" and the "Semantic Web" suffers. Performing tasks in an organization is something that comes natural to us humans, because we are very much hard-wired to be able to do this. We are largely unaware of what we do in order to accomplish coordination of simple tasks. More importantly, we unaware of how our model of the organization is continually shifting and adapting as reality changes. One person resigning can redefine the roles of dozens or hundreds of people, and we make this adjustment automatically without conscious thought. AI suffers similarly because it seems like it should be so easy to make up a bunch of rules that would drive an expert system.

    Since BPM "seems like it should be easy" the systems designers naively make simplifying assumptions about what is needed. It is a common maxim of human organizations that "rules were meant to be broken" but most systems are designed around a simplifying assumption that rules are meant to be inflexibly enforced.

    Because BPM "seems like it should be so easy" the advances in BPM don't ever look like much, while gadgets like "3D TV" seem in contrast like huge fundamental advances. Because we are largely unaware of what really is happening in a human organization, this domain will always be a special challenge.

    • Hi Keith

      "It is a common maxim of human organizations that "rules were meant to be broken" but most systems are designed around a simplifying assumption that rules are meant to be inflexibly enforced."

      Conclusion: Business-IT alignment requires systems that allow rules to be broken. The evolving WSM-paradigm (see my website www.mastering-it.com) leaves room for people to adapt to unexpected situation by breaking rules. Which seems superior to allowing systems to adapt to such situations.

      "Because we are largely unaware of what really is happening in a human organization, this domain will always be a special challenge."

      Another truth to keep in mind! Though there seems to be some deeper insight, recently, into the difference between the strata of mechanical, functional and organizational automation, based on a deep rooted philosophy of automation. For details, please, visit the Portal 'What to Know' on my website.

      Best regards

    • Hi Keith

      "It is a common maxim of human organizations that "rules were meant to be broken" but most systems are designed around a simplifying assumption that rules are meant to be inflexibly enforced."

      Conclusion: Business-IT alignment requires systems that allow rules to be broken. The evolving WSM-paradigm (see my website www.mastering-it.com) leaves room for people to adapt to unexpected situation by breaking rules. Which seems superior to allowing systems to adapt to such situations.

      "Because we are largely unaware of what really is happening in a human organization, this domain will always be a special challenge."

      Another truth to keep in mind! Though there seems to be some deeper insight, recently, into the difference between the strata of mechanical, functional and organizational automation, based on a deep rooted philosophy of automation. For details, please, visit the Portal 'What to Know' on my website.


  • I think the slower growth of BPM comes down to 3 areas.

    1)Organizational issues. There is a combination of a lack of internal leadership for BPM projects, lack of clearly defined process improvement goals and a lack of user adoption due to fear of change. Considering that BPM crosses multiple departments and groups within an organization and success requires consensus among those involved, the past couple years of job uncertainty and hierarchy change has not helped with adopting new technology to identify and implement BPM.

    2)Software issues. Traditional BPM software is more complex than CRM. Possibly too complex for average users to adopt due to their lack of process analysis and knowledge of the processes themselves. Unlike CRM, most traditional BPM suites require Process Analysts that are armed with extensive knowledge about BPM methodologies in order to successfully implement BPM solutions and companies just don’t have those skills (yet).

    3)Implementation issues. Getting multiple users to agree on a process best practice is difficult. Too many try to replicate an existing manual process without taking the time to think about how a process can be improved with BPM software. Many fail by trying to implement the “mother of all processes? when they need to step back and look at simplifying a process by breaking it up into multiple processes. Many BPM projects are started with the most complex process when they should be started with the larger number of simple processes in order to get an immediate ROI on their BPM investment. CRM does not face these challenges, along with the continual decisions required by BPM.

  • Here are some of my thoughts around the slow adoption on BPMS and its challenges:

    Some of the top tier organizations (Fortune 500) - "being the Early Adopters" did take on initiatives in the Business Process Management space but they faced several challenges in executing their end goals i.e. value to the business. They ended up attending BPM conferences, got training on change management, training on process analysis & process modeling and some even went on to acquiring BPMS Platforms. In the last couple of years, organizations that did have a BPM budget went on spending most of it on enabling themselves, acquiring platforms, paying for training and attending conferences - which was all very good. But the struggle has been mostly due to the lack of BPM leadership, willingness to take on risk, having the right internal team / implementation partner and roadmap towards reaching their end goals.

    Some BPM pure play vendors focused on being acquired by a large technology vendor (which did happen for some of these companies) and their main goal was to enhance their valuation by selling licenses & enhanced features of their platform. On the other hand, large IT Vendors have been busy cross-selling and up-selling additional technology components from their product stack along with the BPM Platforms, to their existing and net-new customers. This slowed down the adoption rate to some extent as the message got diluted amongst several technologies and concepts. At the same time, due to the competitive forces amongst the vendors, the complexity of the BPMS Platforms increased (new standards were evolved - XPDL, BPMN, BPEL and discussions on the support & training for standards increased), hence the training requirements increased, the promise of being simple/easy and that the end-users could actually use it to deliver value diminished and the license cost increased due to heavy R&D investments.

    - Another reason is that most of the BPMS acquisition decisions were made by the IT. Most of these organizations never had BPM COEs, so it was more or less a technology decision by IT (a bottom-up approach!). And of course, IT has its own agenda and focus i.e. to buy the best of breed technology and get enabled on it for a couple of years at least before starting any major initiative..!! The little success that we have seen is also due to the fact that IT did drive some success for this, but at the same time it slowed down the adoption rate for BPM at an enterprise-level.

    - Another hurdle that has been seen is the lack of methodologies. The IT and most of the service providers thought of delivering BPMS solution by using a conventional SDLC. That does not work with BPMS, as it requires a very different set of skills. You can't expect the developers to take up on the real promise of BPM and BPMS - agility, flexibility and visibility. And to further add to this challenge, organizations tried delivering such solutions with conventional methodologies for requirements gathering, QA, sending java/.NET developers to a 5 day training boot camps and expecting them to deliver end-to-end solutions in a 90 day period. Some even tried building these solutions in an onshore-offshore model with the basic skill set and offshore delivery model. This created even more challenges for the stakeholders. Organizations started blaming the platform companies, their own employees along with their trusted implementation partners.

    All of this lead to further risks and challenges in delivering the promise. Some of the initiatives even failed due to this reason and halted their adoption progress and belief in BPM.

    With organizations that did take the initiative, the foot print for BPMS is still very small. They couldn't scale up as they didn't have specialized methodologies to master their execution process.

    Another reason is that due to the economic uncertainty, very little funds have been allocated for such initiatives and very few individuals have taken the leap forward due to the job insecurity!

    I agree, looking at CRM & ERPs, BPMS adoption has been very slow. With BPM, we're solving an enterprise-wide, cross functionally problem, rather then a specific finance / sales related problem for an organization.

    BPM delivers dynamic results for performance management, eliminating organization silos and providing real-time visibility.

    I'm still very hopeful to see this adoption rate increase in the coming days and the real promise of BPM & BPMS delivered in the true sense.

  • ERP/CRM is a bare necessity, BPM is a luxury.

  • user-pic

    My observation is some of the ERP vendors have inbuilt BPM tools (like Dynamic Enterprise Modeler - DEM in Baan) which were aimed at purely setting up end-end business process at the enterprise level encompassing entities under it with the flexibility of BP Re-engineering. ERP / CRM are holistic process oriented systems and need tight coupling of functionality with technical components decoupled. BPM always served this purpose providing seamless integration across the processes spanning enterprise, companies, departments, roles and end users.

    Some of the Non ERP BPM implementations I have seen were executed for specific process or module and not at enterprise level with end to end coverage.One of the challenges in going for end to end BPM implementation for non ERP systems is the proprietary & small silo applications built in various technologies for specific purposes without process compatibility with the enterprise process strategy.Integrating these isolated processes is functionally and technically a big challenge and is like opening pandoras box.

    This problem doesn't exist to a large extent in ERP / CRM implementation as the products are implemented with top down approach from enterprise level to end user by mapping processes of each unit to the strategic process of enterprise. Technically too it is less challenging as we are integrating the processes using standard APIs

  • I'd like to pick up on Keith's point that "BPM should be easy". That is reinforced by the notion of a graphical model that depicts the process. Modeling at a very high level is relatively simple - a few symbols, some connectors, a lot of ambiguity - and anyone can do it. On the other hand, creating a rigorous model that actually describes all the detail relevant to a process is very, very hard - most people can't do it. I'll call that the "BPM divide" - the distance between a model that a knowledable human can understand and improvise around, versus a model that can be used to automate a process.

    Because of this divide many (most?) BPM suites have evolved (devolved?) into tools for IT - a sort of rapid application development environment for automating business processes - and that is why it hasn't taken off like CRM or ERP. CRM and ERP are tools for the business that are managed by IT, BPM is a tool for IT to create tools for the business. An IT tool will never have the impact of generalized business application.

    Jacob Ukelson - CTO ActionBase

  • When we work we actually execute one (or more) of the "business processes" of our company. I think that "business processes" are, actually, part of the plumbing of each enterprise. At a point that, sometimes, it is "hard" to describe it because we sort of "live it".
    So, in that matter, BPM should be the obvious fit.

    The fact that it is has been "hard" to introduce it in the enterprises makes me thinking to the following:

    1. A business process which is not documented gives the possibility to be "adapted" more rapidly.

    2. A significant business process often spans several domains. Formally describing it may introduce negotiation issues

    3. Once a process is described and ready to be deployed, an owner will likely be required. The owner may not be clearly identified yet and this may require some further negotiation

    4. As Nicholas Carr was saying, it is easier today for companies to adapt themselves to the business processes embedded in the CRM and ERP tools they buy instead of investing time to describe and negotiate company specific business processes

    This said, I think that the maturity of the market and the maturity of the products are now helping a lot in the adoption.

  • BPM is very fragmented. It's like saying why hasn't "making money" taken off?

    All companies must make money. They must all do "bpm"... but it takes so many different forms that it's hardly reasonable to lump them together.

    IDC is projecting over 100% CAGR for BPMS going from under 1B in 2009 to over 2B in 2010 to over 4B in 2011... All I can say is, wow you really have to put a broad scope on it if you want to take in those numbers.

  • In one line, I would say it's all about perception of Opportunity Cost.

    Here is why I think ERP & CRM successes have been different - because their promise is clear and standard - and, by and large, that's regardless of who you are, what your business is and what your unique challenges are.

    Both ERP and CRM investments can be shown to be a must-have as they have direct impacts on the bottom-line and if done right CRM can also have an impact on the top-line. Which is also true about BPM, but the opportunity cost of not doing BPM apparently is not considered as compelling as the opportunity cost of not doing CRM or ERP.

    The way BPM has evolved, has still kept it in the 'nice-to-have' zone. Perception of BPM seems often to be about how much better things like agility, control, visibility etc can be. And that makes its basic value proposition rather weak and vague because if it aint broke, why fix it?

  • We try to understand the difference between ERP/CRM and how they help a business to survive.

    For More Info about Difference between ERP and CRM

  • Experience with Sage X3.

    Dear Sage Users,

    I would like to ask you if you have experienced similar problems with Sage X3 that I have mentioned below. If yes, please advise me how can I fix them.
    I am the first customer of Sage X3 in Poland. Since September 2014 there has been an extensive implementation of Sage X3 software in my 120-person company for 60 software licenses. My company has been using Sage X3 since August, 1st 2015. The overall cost of our investment so far amounts to 280.000 EUR.
    After one year of my experience with Sage X3 I can say that each day is marked with new defects emerging in Accounting and Finance and Inventory and Warehouse modules.
    Unfortunately, the Sales and Inventory Management Modules of Sage X3 possess very serious flaws that have been discovered in August of last year and have not been remediated so far. The most important flaw of Sage X3 concerns the phenomenon of uncontrolled change of prices of goods in different warehouse locations. This defect results in our inability to accurately account the result of the company and provide reliable financial data to tax offices, external financial auditors, banks, and to calculate sales commissions. For example, during transfer of one product of 100 EUR value from warehouse A to warehouse B, Sage X3 unexpectedly and randomly changes its value into 103 EUR or 95 EUR or other value. The values of goods can be decreased or increased without any logical reason. Over the course of last 9 months, there have been numerous attempts of repair. There have been many announcements from Sage Poland that the problem has been eliminated. In reality, the problem continues to exist and is deepening. The issue concerns both old and new deliveries, also two large recent deliveries, each of them encompassing few containers of goods.
    Problems with X3 implementation are causing significant financial losses to my 120-personnel company.

    Beside malfunction of purchasing prices mentioned above, there are also other problems in Polish version of X3:

    Accounting and Finance
    • no module fixed assets
    • Inconsistent data provided by the various modules of Sage, eg. different statements of the same warehouse in Accounting and Sales modules. Three different statements of the same warehouse, show three different inventory amount.
    • In PL version no proper reports of profit and loss account, balance sheet, etc.
    • no automatic posting clearing counterparties in this settlement with cash reports

    Purchasing Management/Material Requirements Planning
    • no automatic integration of data
    • values of minimum stock have been entered into Sage X3, but optimal replenishment recommendations not working

    Manufacturing Management
    • no production module of the working properly and thus no possibility to connect production to accounting system

    Sales Management
    • incorrect prices of goods accepted for sale
    • Sage X3 changes prices of goods transferred from one location of warehouse to another
    • customers’ balances mistakes, also incorrect information of debts of the customer 'total balance' and even a few minutes of disappearing balances in SAGE. The program then gives the debt of "0". Bizarre is that the issued invoice can be seen in the Cashier and Sales module only after posting, so it is after 1-3 days.

    It is possible to see scanned examples mentioned above at www.sage-reviews.com,

    Pozdrawiam, Best regards

    Maciej Juchkiewicz

  • It's easy to be confused since people working in both the areas talk about how BPM/ERP is not just software, but a "holistic management approach" or a "business strategy". Just remember these keywords: BPM - process, ERP - integration.

    BPM is focused on workflows - it is aimed at optimizing, improving and automating business processes. ERP is focused on integration (of internal and external information across business functions).
    Some BPMS are developing their products to achieve most ERP functionality and capabilities; they are not far away from offering in the same system both tools

  • If your business growth has become stagnant or you feel that your resources aren’t being used as efficiently as they could be, an ERP system may be the best solution. With eHopper free pos you can learn more about how ERP can help you!

  • Because CRM is an easy sell. the vendors can demonstrate very quickly operational efficiency and the benefits to your customers in a way the business quickly and easily understands. While BPM is disruptive. BPM departments making an agreement is difficult.
    If you are looking for more information about Cloud-based Erp check here

Add a Reply

Recently Commented On

Monthly Archives