Can We Achieve BPMS Pricing Transparency?

I saw – and responded to – this question on Quora today:

What are the license fees / cost for the the top BPM solutions in the market ? ( Pegasystems, IBM ( Lombardi ) , Appian, Oracle , etc )

I am looking forward to do a benchmark of the top BPM ( Business Process Management ) sofware solutions on the market. Its well known that is always hard to have a clear knowledge on the licensing prices that top software vendors offer on their solutions.

My response:

Good luck with getting public information on that — like most enterprise software vendors, BPMS vendors are very reluctant to release this sort of information. Typically, they sell a package made up of software, services, maintenance and possibly even future growth, then apply discounts based on how close they are to the end of their sales quarter/year and other things that are unimportant to the customer but unfortunately used to drive sales.

You might have better luck finding prices for those who have a cloud version, since that tends to be based just on a per user/per month figure rather than a mysterious formula. However, I notice that many of them, stuck in their old ways of not disclosing any prices, don’t even publish those but make you request a quote.

The lack of transparency in pricing in enterprise software in general, and BPMS in particular, is not a good thing for customers.

I’ve helped a number of end-customer organizations with their BPMS purchasing decisions over the years, although I’m typically focused on how well the functionality fits their business requirements rather than how well the price fits their budget. At some point, however, the customer always asks “How much does it cost”, and my answer is almost always “I have no idea”. I might know how much it cost for some other customer, but the pricing calculations for a particular customer are usually so completely opaque that they can’t be generalized and – this is the killer – the vendor considers this confidential information that cannot be disclosed to other customers. Even cloud-based pricing, which should be publicly advertised on the vendors’ websites in easy-to-understand per-user-per-month terms, is sadly missing from some of the key cloud BPMS vendors.

Remember the bad old days of buying a car, when you had no idea how much it cost when you walked into the showroom, and had to go through some weird pseudo-negotiation between the salesperson and his manager, where they would throw in the free floor mats if you did your financing with them, give you an extra discount if it was within a week of the end of their sales quarter, or bait-and-switch you into a more expensive model? Enterprise software has always felt a bit like that to me, and BPMS pricing and sales tactics sadly fall into that same category, at least for many of the major vendors.

Now, remember what happened when people started sharing car prices online? Soon, everyone knew the dealer price on a car in advance, and were in a much better position to negotiate a fair price, rather than have the salesperson negotiate what they think you would pay. It would be good if the BPMS vendors could get ahead of that trend, and start being a bit more transparent about their pricing, starting with cloud pricing.

14 thoughts on “Can We Achieve BPMS Pricing Transparency?

  1. Pingback: Quora
  2. Hah! Six of my past seven clients had enterprise site licenses with the vendor. With all of those clients I was privy to the construction of their ESL’s license for # of seats, products, support, etc and “opaque” is a euphemism. Trying to infer ANY sort of pricing calculations out of those agreements is damn near impossible and the astounding thing was the wide range of numbers (licensing and associated dollar cost both) between what client ‘X’ got and what client ‘Y’ got. In a couple of instances I have to say that client ‘X’ got shafted and client ‘Y’ could get blood from a turnip. The only abstraction I can make is that at a given point in time the vendor’s going to get their numbers no matter what and the only lesson I can opine is shopping’s good at the end of the quarter, even better at the end of the year.

    “Opaque” indeed.

    Cheers, Pat

  3. Agree it is not a good thing, but software pricing is a big problem in general. Seems that there are three models:

    1. server based – this has the problem that people try to purchase as few servers as possible, forcing too many people on server, and possibly providing unacceptable user experience. Also, some servers are hundreds of times more capable than others, so it is not really an equitable measure.

    2. user based – organizations with large numbers of users reject this approach. They are encourages company to limit and control the number of users, and try to keep this at a minimum, excluding important occasional users from access. This is a problem in collaborative situations where it is hard to say ahead of time exactly who needs to be involved, and adding people at the last minute is a significant barrier to getting the work done.

    3. Transaction based is in my opinion the most equitable: you pay for what you use. If you don’t use it, you don’t pay, but if you do use it, you don’t mind paying because you are getting value. The problem is that customers don’t like usage based pricing because they can’t estimate it, and feel that they can’t control it.

    There are a couple more models: for example “application based” pricing where each distinct application costs something, but this encourages people to make a single “super” application that does everything — and isn’t that what we all really want in the end anyway?

    Pricing is complicated because sometimes a large number of users use the application very casually (e.g. a merit review process used once a year by team members) and other application are critical to moment-to-moment business (e.g. authorizing international bank funds transfers). It would be perfect if we could price based on the BENEFIT that the system brings to the organization, but such calculations are elusive at best.

    The only pricing that everyone agree on is “free” but the IT environment can be very complicated and you need to have experienced people retained to bring in at a moment’s notice.

    So, how you YOU recommend BPMS software be priced? If enough customers got together and insistent on a particular model, it would probably have an effect.

  4. Keith, my point is more about transparency than the actual models: pick the pricing model that works for you as a vendor, but give customers an idea of what that model is rather than just pulling a number out of a hat based on some hidden calculations.

  5. You can’t even compare it to buying a car, where you are haggling over the last 2-3% of the price. With BPMS the “deal” could be +/- 50%. As the others have said, the price is whatever the market (or this individual buyer) will bear.

  6. Opaque and widely varying indeed! :)

    However, there could be a rationale behind such huge variations, which might be preventing vendors to get completely transparent about it and depend on these twisted formulae. It is not common for customers (and many times not even recommended) to go full hog into buying an Enterprise license when all they’re trying to do is start small and iteratively build the platform and applications thereon. Depending on the “initial” ambition and vision, the ROI calculation for the target applications would change – and that would impact the price that the customer would be ready to pay. So, indirectly it turns out to be a CPU based licencing price to begin with (since that is the only direct way to measure the load/scale of the usage of the platform. The same platform could be used in a smaller company for say 15 processes, while for another bigger enterprise for hundreds of processes. And what makes it more difficult to gauge the Enterprise level evaluation of the license for the buyer is the fragmented manner in which many BPMS implementations start – some times at departmental processes level.

    Since these are platforms and not a direct business utility application, it is difficult to judge the value proposition v/s the pricing up front. Or in other words there could be huge variations in the way platform is built, used, and scaled up from Enterprise to enterprise. So, looks like ROI methodology, involved in purchase decisions, is to blame in part?

  7. One of the first questions every vendor asks the customer – is what kind of budget do they have. They then try to fit a package to suit the budget, usually in hope that there will be additional income later on down the line.

    Enterprise software prices are 6-7 digits, not exactly car prices.
    CFOs, CEOs, CTOs are all involved in the purchasing process. They are not as gullible as car buyers.

    Most BPMSs provide roughly the same functionality – so prices do matter and are used as a competitive advantage. Most customers use tenders as leverage.

    Should the customer’s first concern be how well the functionality fits their business requirements – absolutely.
    Should the customer verify that they are getting value for money – absolutely.
    Should the customer use independent BPM consultants to help with the vendor selection and advise on pricing – absolutely.
    Should vendor software prices be transparent? I’m not sure.

    Ballpark figures:
    Small deal (or foot in the door) 250K
    Government size deal > 500K

  8. Ballpark figures:
    Small deal (or foot in the door) – Less than 100K
    Medium deal 100K-250K
    Enterprise deal – Bigger than 250K
    Government size deal – Bigger than 500K

  9. Adam, I think that company execs can be quite naive about the expected costs for enterprise software, and as Pat mentioned in the first comment, an outside observer who can compare multiple deals can see that the prices can be quite different for essentially the same thing. And when the vendor’s first question is “how much is your budget”, I’m certain of what the final price will be.

  10. Sandy, to be fair, there is another set of pricing discussions – around consultants – that is very similar.

    The consultant would like to understand what the value of the project is, or what the budget is (either or ideally both). the customer just wants to know what the price per hour for the consultant is, in many cases. Why do they want to know that? So that they cant pretend all hours are created equal and do heavy price negotiation on that basis. But all hours are not created equal, as the input is a person, with skills/experience/etc.

    So, we can complain about how software vendors price – and ask for more transparency – but it isn’t as if anyone in the business ecosystem is without guilt (or more neutrally: responsibility) in these dynamics!

  11. Why does the price need to be ‘transparent’?

    If the package price represents a superb return on investment versus the value of having the problem fixed and the pain go away, what does it matter what the component parts are?

    If one of my clients asked me for a price breakdown, I couldn’t tell them. I couldn’t tell them because that’s not the way I create my prices.

    If the customer is that dissatisfied that they feel the need to ask for a price breakdown, it’s a very loud signal that they don’t see enough value yet. And that means you haven’t sold very well, so I guess that means you deserve what you’re getting.

    I agree, the comparison with buying a car is spurious, as is the notion of a value-based price being ‘what the market/customer will bear’. If you want to work in a commodity market, then that’s your choice, but be prepared to put up with the cut-throat environment you’ve chosen to enter. If you can’t stand the heat, as they say, get out of the kitchen!

  12. David, how can the customer possibly calculate whether they have an ROI if you don’t tell them what the price is? Or disallow them from creating their own ROI models to calculate a break-even point because they have no idea how your pricing changes with number of users, or servers, or other factors? Just asking a vendor for a quote for one specific configuration isn’t enough information for most organizations to tell whether or not there’s an ROI for them.

    Pulling prices out of a hat (or elsewhere) just doesn’t fly for intelligent customers.

  13. Sandy

    In my experience, reactions such as yours result from an inadequate or incomplete sales process. There seems to be a tendency amongst ‘professional knowledge workers’ of many flavours to sprint through the selling, and to stop selling before they should, in a headlong rush to start doing what they’re good at.

    Let me address the four points you raise one at a time.

    How can the customer calculate ROI if you don’t tell them what the price is?
    I never said you don’t tell the customer what the price is! What I said was there’s no need to itemise the price – to justify how you ‘calculated’ it if you will – if the price is value-based. In your sales conversation you first of all need to help the customer to understand the full value of removing their problem. This is the value, the return, on which your price, their investment, will be based.

    How can they create their own ROI models if you don’t tell them how the price changes with number of users?
    I don’t think I even addressed this point originally, but let me do so know.

    If during your sales conversation, during the course of establishing the full value of solving the problem, you realise that there are several ways of solving it, each involving a different number of users, then you need to probe with the customer the different value resulting from each configuration.

    It may be that with 100 users they can get twice as much value than with 50, but you have to help the customer understand this for themselves. When they have, and they’ve explained it to you, you can quote a package price for each configuration they’d like to consider.

    Just asking for one quote for one configuration isn’t enough to tell whether or not there’s ROI for them
    By conducting your sales conversation in a better way, the customer analyses their R and their I in your presence, with your assistance if necessary. I think my previous answer addresses this issue as well.

    Pulling prices out of a hat doesn’t fly for intelligent customers
    Of course your customers are highly intelligent, but your prices aren’t “pulled out of a hat”! Having helped the customer understand the full value of removing their problem, and having presented various ways of solving it, you price those solutions such that they present a highly compelling ROI for the customer. Naturally you will have made a cursory check to ensure these prices are also handsomely profitable for you too, otherwise you will have revised your costs to ensure they are.

    I hope this helps.

    I run mentoring groups on the subjects of making sales without really selling, value-based pricing and getting paid what you’re worth, so please contact me if you would like to know more.

    David

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>