CRm and Process management are complementary, especially as CRM mostly employs encoded processes which is worse than definable flow diagrams. So the answer is a yes, but in principle CRM needs user-definable and adaptive processes because CRM is more like case work than like orthodox business process. Given the current state of affairs Salesforce won't know the difference ... and users use what they get.
I completely agree with Max in terms of SFDC, but I think the more interesting evolution will be BPM platforms encroaching on the turf that Salesforce 1 wants to occupy, namely "helping IT lead innovation with tools and services to build mobile and social business apps faster than ever before." BPM is much better-positioned to do this than SF 1.
Exactly! Every technology is a way to automate a process so SFDC is a Business Process Management solution already. If they make the workflow more customizable and adaptable they'll move closer to the BPM space and away from the CRM space. SaaS solutions are notoriously difficult to customize on a per customer and per user basis other than by offering a number of optional looks, feels and options. So it might be harder than they think to crossover to be a full blown BPM solution.
As far as I know, any process-centric solutions comprises several artefacts, such as events, roles, screens (or forms), rules, goals, data, documents, coordination techniques (flow-chats, case folder, check-lists, etc.), audit trails, KPIs, reports, services, processes and automation scripts. Ideally, all of these artefacts are explicit, versionable and externalisable to quickly assemble a business solution. Modern BPM-suites are trying to be (at least) good with all mentioned artefacts.
I think that force.com is very good with data, screens and automation scripting; maybe also with some ad-hoc coordination. What’s about other artefacts?
In addition to agreeing with Max, I'd like to say that unfortunately (or fortunately for the up-and-comers?) Salesforce doesn't have a business process DNA (the passage from Benioff's book where he recalls the epiphany he had when he realized how much potential laid in the fact that his customers should be able to rename the frigging tabs in his app... man, this still hurts my brain) and it occupies some BPM space out of sheer logic: CRM is a business process.
Salesforce is a weird company - it combines a high-touch enterprise sales process with an SaaS delivery model. I think this is the main reason they keep bleeding cash from an operating standpoint. They can still get away with it as they bully other enterprise spaces with their stock exchange cash, but this is not sustainable.
I would bet my money on a BPM player that does CRM too, rather than on a CRM player that reinvents itself as BPM.
And while I'm at it, I'd actually bet my money on a Case Management player that does BPM too. Where are they? :)
This is a deeper question than it seems. Trouble with SaaS and in particular the big players such as SFDC and Workday is that they are not making profits! So the model has a fundamental flaw and something needs to change? Would you allow your mission critical front end process to be “owned” by an unprofitable thus inherently unstable company?
SaaS should be seen as a payment method without a “lock-in” so once “lease” payment reach end of contract there needs to be an option is to ”move” hosting which includes of course bring back in-house?
Looking at “BPM” supporting software this requires customisation and in built easy change which for most hardcoded vendors will be a challenge and expensive to support. Will SFDC be able to support? I doubt it. Sure their marketing department will make claims but buyers better understand just “how” it works and make sure you can get you processes back not just your data!
Some great comments here. Having been involved with BPM for 16 yrs and been a Salesforce.com reference customer for 10 yrs, there a couple of comments/corrections I would like to suggest.
- Salesforce is only unprofitable due to its insane marketing and M&A spend driven by a goal of $20bn rev
- Salesforce does not have BPM in its DNA. Marc certainly doesnt. They have BPM tools but they get little or no marketing.
- BPM is becoming irrelevant because it is too generic, is a platform and not an "outcome". CX, increased sales, better service, compliance achieved and analytical insights are results that business buyers will pay for. BPM is/was bought by IT and they are no longer in the driving seat.
I get the impression that we don’t really want to answer the question of whether Salesforce occupy the BPM market, perhaps because we don’t see Salesforce as a potential BPM platform or, as Bogdan puts it, a company with ‘a business process DNA’. But perhaps they will make progress anyway.
Meanwhile, the questions of whether Salesforce should occupy part of the BPM market is interesting too. After all, from the point of view of Salesforce users and BPM specialists, it probably doesn't have to.
Max notes that CRM and BPM are complementary, and that CRM needs adaptable processes. If you're thinking about integration, which is where I'm coming from, then this sounds like an integration problem: it's better to integrate complementary tools than try to make one big tool that does everything. It’s may well be easier to integrate Salesforce with a BPM solution than it is for Salesforce to add process management without making the whole product less usable.
Note that the fact that Salesforce is SaaS doesn't really change anything, compared to more traditional integration scenarios. If anything, integration is easier with cloud-based services whose APIs are more public and better-documented than in-house solutions’.
Finally, Ben speculates about BPM platforms getting involved. From my point of view, this means integrating with Salesforce so that it can participate in processes managed by an external process engine. This shouldn't be a surprise, because Salesforce offers APIs that make various interesting things possible. Also, for what it’s worth, Effektif has just got started with Salesforce integration.
So to return to the original question: although anything’s possible, there are three good reasons to believe that the answer is no:
As my little experience stretches; SFDC doesn't support my processes at all. It made them only worse. Maybe it was the implementation, but man, I think throughput times are 10 times higher now. So BPM? Maybe, but not so exciting.
But to be honest; since SFDC I have more data entered than I have ever dreamt of.