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

Should a company buy or build a BPM solution?

Vote 0 Votes
A question from this blog, What's Better - Building a BPM Solution or Buying One? and an important question for companies looking to take the BPM leap. And what metrics should they use to make the decision?

10 Replies

| Add a Reply
  • The simple answer is, Buy one...But you need to make sure you purchase a highly adpatable BPM platform, otherwise you are probably building parts of it in anycase...

    In the real world most vendors provide great demos and case studies - showing out of the box functionality. However, in real implementations this is backed up with a hell of a lot of config (which is often code for a team of developers building modules and components).In this case, are most BPM solutions actually built for the process, let alone the client?

    There is no argument for building your own BPM platform in house. The investment required to get to something that could be used effectively across multiple processes, departments etc is simply too high, and why re-invent the wheel...

    The best option is to purchase a platform that you target for a small part of your business. However, always keep in mind the goal of using BPM practices across every type of process you can think of within the organisation. To do this you need something that is highly adaptive, and that allows processes to be detected and created by end users (this will mean a move away from BPM flowchart / maps / solutions that use these rigid designers). A highly adaptive platform will allow an organisation to pull in more processes quickly and easily and therefore allow the BPM platform to deliver benefits quiker to a business.

    Measuring success is hard to illustrate, and its probably one of the reasons why organisations dont jump into BPM and Case Management quickly. The best way to measure BPM success is by taking a more holistic approach. That means trying to place value on speed of customer satisfaction and servicing, as well as measuring efficiency of process throughput. ROI is a tough thing to calculate with simpler solutions, and with BPM that return can be found in hard places to measure

  • If there's a strong, cross-system, technical competence in house, than it's much easier building the code you need to orchestrate your system, and not one line more than needed.

    If not, the only solution is to embark in a project with one of the existing players, but it will likely be more painful than the other case.

  • Build or buy will be driven ultimately by the preferences of the organization.

    BPM software is really a set of repeatable building blocks, made general enough to match common requirements for many business processes, not just those of one business. Therefore it seems hard to envisage building a BPM internally. It seems easier to just building custom solutions for individual business problems.

    Really what a business should be doing if it is looking at building software is using BPM methodologies alongside other requirements analysis approaches, and building just what is needed to make the solutions work in practice and make them maintainable in the future.

    Whichever approach is taken, the full costs should be considered to understand the ROI up front, although sometimes we all know that there are soft-benefits that just outweigh the costs we can easily measure (my thoughts at: http://blog.consected.com/2010/12/you-cant-build-bpm.html )

    Build or buy of BPM is not the question. Companies should be asking themselves where their problems are and the fastest and best ROI for fixing them.


  • A company should first understand the process(es) and if necessary get a tool to help. Once they understand the problem they should find a suitable tool to assist the design, the solution and monitor to progress and plan/drive the continuous improvements.

  • Agree with Tom that you need first to understand the situation. Then -- all depends, as usual. For your support business processes, you may even rent a BPM solution. For core business processes, you will you need to invent (or find and adopt) a good architecture for your BPM solution, acquire a proper BPM tool, and, ideally, assemble your BPM solution (of course, just an initial version of it) with a few specific fragments to be built.

    Core business processes BPM solution is similar to company’s health -- impossible to buy.


  • user-pic

    Interesting question. I think your answer to this depends primarily upon how you plan to use a BPM platform, and your confidence in it's maturity to support your future unknown requirements.

    Some people view a BPM platform as a toolset that gives them the means to rapidly build, change and maintain process based applications. So let's ask the same question of other toolsets. Should a company buy or build a Relationship Database Management System (RDBMS)? Should a company buy or build a programming language? Should a company buy or build an Integration Development Environment (IDE) like Eclipse or Visual Studio?

    Other people view a BPM platform as a solution and an end unto itself. You buy it, it's got some process solutions that came with it and you use them. In this case let's ask the question of other solutions? Should a company buy or build an Asset Management Solution? Should a company buy or build an IT Ticketing System? Should a company buy or build an Underwriting Solution?

  • Not sure anyone should consider building a BPM platform unless that is the business they want to go into- building and selling/supporting BPM platforms. The offerings out there are too good to justify in-house build.

  • Andrew and Scott have it exactly right. With the breadth and depth of tools available today there is no possible justification for allocating resources to design and build a BPM platform.

    Two powerful tools in the space are Saviion (and its siblings) from Progress Software and ActiveVOS from Active Endpoints. Having just finished the first round of discovery work, I found the ActiveVOS product to be very compelling because it is based on BPEL and will interface in real-time to just about anything. I've described it others as process-oriented middle-ware on steroids.

  • Socrates said "the beginning of wisdom is a definition of terms" and I borrow the quote because the problem with this debate lies more in the lack of definition of the question than in the attempts to provide an answer.

    Build - A product from scratch? A solution based on an existing tool?
    Buy - An existing tool? A SaaS service? A BPM company?

    The same answer is possible in both directions which can only lead to confusion. BPM is about removing confusion and so debates ought to have a better foundation so we actually appear to be on a consistent mission to make business easier and more effective.

    Christopher has credited Andrew and Scott in saying there is no justification in building well that is right for the buyer community but if I were planning to build a great new alternative to the stuff already available then I might beg to disagree.

    I think Phil has a better question for the buyer, what is the best way to ROI? The answer will almost never be to build something new. It lies in developing n understanding of what can be achieved by the available products in the market and this may mean buying one single answer or a combination of products that can cover the full range of business needs for BPM which is more than just about building IT as so often becomes the debate here.

    If you are in the game of building a new BPM system then there are plenty of products to look at to see whether you have something original to add or can do a better job of what's out there at a lower cost and so on. Good luck if you are, competition is stiff!

  • BPM is a lifeline and competitive differentiator for organizations. A bought BPM will most likely not provide that advantage, it may help automate and reduce time to market, but will not help to differentiate.

    The promise of BPM is continuous and iterative process improvement - to be able to change and adapt to dynamic market conditions. My take is that if organizations want their processes to be competitive differenentiators, to continuously adapt and adhere to a dynamic market, they should be looking for buying a BPM platform and not building one. Organizations should stick to their core competencies and avoid building or "reinventing the wheels," especially with respect to matured technologies, such as BPM.

Add a Reply

Recently Commented On

Monthly Archives