[tweetmeme source=”ashish_bhagwat” only_single=false]
On a tweet-chat today, Connie Moore from Forrester mentioned that the entry price from one of the vendors for BPM in cloud is around 3K/month for a single process. Well, it’s not BPM but BPMS infrastructure usage on cloud in this case, that’s my best guess. But, let’s keep that point aside for now.
The immediate question that popped in my head was how do you decide on the pricing unit in this case. And since it’s the entry level I’m assuming it’s for the simplest of the processes but how do you define that?
I have come across many scenarios where a customer wants to price the BPMS implementation against the outcome/output as against effort. What it means is that they’d want to pay you by the number of processes/applications/(or whatever unit) delivered and executed for a predefined warranty period of time. While that itself is challenging [to price against a piece of process to be delivered], we have been asked by customers to also include hardware and licenses. That’s where the situations get more tricky.
For any vendor it’s easiest to price for the delivery of a process (that’s purely effort based scenario) and as long as you estimate it right you’re Okay. In case of execution of a clouded process unit you’re dealing with Fixed as well as variable costs as well as the time and magnitude factors.
That’s not new, one may argue. In any business we deal with the Fixed Costs and the variable costs per unit of the product produced & sold. The business runs based on simple equations of breakeven point and profitability per unit, that’s where economies of scale and everything else comes in. But, there you talk about the unit as a concrete tangible piece of output. It is defined well to the level of every auxiliary sub-unit that accompanies the unit sold. The same needs to be applicable here for the equations to work well otherwise it’s going to be a situation of going back to drawing board every time a new prospect pops in.
How do we define a process unit in this case? Every process, no matter how standard, has its own thumb-print in the organization. The benchmark of a simple process will require agreement on the number of steps (human & system steps), number of business rules, the data elements, the integration needs, participant requirements (users/groups/roles), the exceptional conditions, and multitude of other factors – all of which cannot be listed here. I have versions of spreadsheets going into myriad details that make me jittery every time a request for a quote comes in. On top of that, the Process Execution or Operations are driven by the organizational culture and consumer behavior too – even if everything else remains same this one aspect can throw your execution costs out of the window.
And unless we have defined the benchmark for the process unit, the numbers will keep getting thrown everywhere on the price per unit without any analytical value attached to them. Vendors can come and throw numbers in public while in reality the deals are signed on specifics of the processes with prospects where the works starts from scratch again. No restaurant menu cards or catalog based pricing yet in this business?
#1 by amit on March 1, 2010 - 6:55 pm
my 2 cents. From a technical sales perspective. if it’s a serious bid, technical team should scientifically evaluate a solution and then leave it to business team to sell the solution. If they short sell it their call and they should own it
If it not a serious bid, u may get this too often where proposal, say lacks technical data. Use some template and add lot of standard fine prints.
If business team complains about losing bids, ask them to review reason for failure and make a constructive comment. If they do it seriously I am sure that it was lost due to poor communication or not knowing what client wants!
#2 by Ashish Bhagwat on March 1, 2010 - 10:10 pm
Amit,
Thanks for taking the time to comment. We could go over the sales cycle and the best practices therein. (May be over a LinkedIn discussion? :))
However, I didn’t intend to bring up the sales related aspects in “typical” proposals here. My point is that for a Process based pricing (that several vendors are attempting in the clouded BPMS areas) works fine for proving the concept & for very simplistic and silo’ed process but not for a significant process operations in a clouded BPMS environment.
#3 by Matthieu Hug on March 28, 2010 - 9:54 pm
Imho process based pricing is most of the time what the vendor marketing team understands, not what customers expect / understand. And usually an ISV doesn t sell its peodcu to itself, does it? Probably a pricing put together by an old timer (licence maintenance) alledly marketing itself as a cloud bpms. Beware of copies 😉
btw with RunMyProcess 30EUR / user / YEAR (about 40USD). Check it out!