I found some issues concerning salesforce.com (sforce) that are worth talking about. Strangely enough, a close friend of my wife who was not at the conference discussed the nature of sforce at the nonprofit she worked at. It turns out that there are numerous workarounds associated with the template but the workarounds are pretty odious. For instance, donors have to be associated with organizations and as a result dummy organizations have to be created in order to enter the donors. There are new releases that fix this but her org hasn’t implemented those changes.
On the other hand, I went to a session on sforce at the NTC. Steven Wright of the Salesforce.com Foundation acknowledges and is ready act on fixing the problems. They seem a heck of a lot more responsive than other vendors I have worked with but the proof will arrive when the Nonprofitforce template has its bugs ironed out and there’s real documentation about it. It turns out that there was only one developer assigned to create the template.
A day later, I ran into Steve Andersen (who is even more smart in person than he is on his blog) at the Omni Shoreham and he presented what I think is a capital idea. He suggested that a bevy of sforce consultants, business managers and users be assembled in one place for a few days and that a code sprint of sforce consultants be applied to Nonprofitforce. How interesting that open-source methodologies can be applied to sforce! This is why sforce works — they’ve got fiendishly bright developers who are committed to the platform because they believe in its potential and sforce’s platform is actually amenable to collaborative development efforts in the style of open source projects. AppExchange tries hard to be a kind of audited SourceForge but it was with little surprise that a little search on SourceForge turned up sforce source code.
What is interesting is the issue that other non-sforce vendors are raising about sforce. They’re saying that the much-vaunted sforce “ecosystem” is really just another ploy to have more consultants circling around nonprofits in the sense that instead of a one-stop shop for CRM, you end up contracting with multiple vendors in order to get say, e-mail marketing properly done. In essence, the “ecosystem” is difficult to work with and set up and will need consultants to get nonprofits to migrate to sforce. As a result, sforce can be crudely characterized as a consultant’s dream and that the user’s needs are never met.
There’s always a tension between the one-stop shop concept and the model employed in sforce. If you’re a nonprofit that likes a lot of handholding and likes to stay in one silo and don’t happen to mind paying extra for that “privilege”, then by all means try the one-stop shop. However, sforce is all about competitive advantage for a nonprofit. The idea that you can easily reflect your internal data for purposes related to fundraising is a clear advantage over other nonprofits that may be in the same issue area. Better fundraising by drawing connections between your various data sources is the potential behind sforce. Any nonprofit that doesn’t see the technical promise behind that strategy is going to be rendered irrelevant as other nonprofits figure this technology out and use it precisely the way the private sector uses it — to raise money and strengthen their ties to their clients.
Loading ...
I wonder how expensive or cheap it is and will be to develop needed functionality on the SF platform vs. other similar products. It still appears uncertain and perhaps highly variable how much SF functionality will be used out of the box vs require customization.
These other currently common scenarios tend to have pretty high costs: a) having to pay a vendor to customize their product for you, b) a consultant who hires a vendor to customize the product, c) in house talent modifying a homegrown product or 3rd party app.
I posted a few of my impressions re SF at: http://cknowledgeworks.com/blog/?p=13 .
The thing about Salesforce is that it really is becoming a “platform”, rather than just a “sales process tracking” application. The vision is SF is just a database “cloud” and various apps ride on top of the platform, using the open API.
I see the real key to mass nonprofit adoption is in creating easy-to-use, well-documented (and free/low cost/Foundation supported) AppExchange applications for specific NPO sectors.
For example, if I’m a Social Services nonprofit, I download the “Client Tracking/Case Management” app. I don’t want to pay someone tons of cash to customize SF, I want something that gives me 80% of what I need, and if I need to tweak it, then I’ll either learn how to tweak by taking my free 40 hour admin class from SF, or pay someone else to do it (most decidedly not free).
I find myself really frustrated by the one-size-fits-most mentality. Why should I pay for that? If I’m in the market for a mule, then sell me the best mule you got. Don’t waste my time telling me how great the cow is and selling it to me at twice the price along with a run-of-the-mill mule.
I really don’t mind working with multiple vendors in the Salesforce universe. Sure, you can work with consultants (and we did at first) but you don’t have to. You can do just fine working directly with vendors and plugging their technology into what you already have.
Even “Nonprofitforce” is so customizable that you can take what you like and what works and ignore/configure the rest. Unless something has changed in the last year, nothing is locked down. Our implementation is a mix between Nonprofitforce and bits and pieces I’ve picked up from other applications through the AppExchange and the default sforce installation.
In the first paragraph you talk about a limitation that was quietly lifted in a recent release. Now we only go out of our way to associate organizations with donations coming from businesses. Individual donations do not have to have an organization/account attached to them, instead linking to the donor through contact roles. It was just a simple matter of toggling off “Required” for the “Organization” field on the donation page layout we use for individual donations (which we changed from the default “Account” a long time ago). Took 30 seconds.
Sure, we had to change some habits at first…but I think that happens with anything new. Now a year later working in Salesforce on a daily basis (as a user/admin, not a developer) is second nature. I’m just waiting and hoping that there is some advanced integration between Convio and Salesforce and we’ll be home free.
It just seems odd to me that they wouldn’t go out of their way to build not only templates for nonprofits, but work on foolproof porting from RE, Convio, GetActive, Kintera, etc.
Make it easy for me to switch, and I’m there. Make me have to wite my own app from scratch, and I lose the incentive to change.
That’s asking a lot for what is essentially an early release of the application. What is interesting is that we can ask salesforce.com. I think people see the potential of the platform and that has captured the imagination of the smartest developers. Smart developers hate lock-in — why develop ONLY for RE or Convio thus limiting your marketability. With sforce, it’s clear that work in the nonprofit sector does not limit your ability to switch over to the private sector if need be. It’s a win-win for everyone around. I’d like to point out Peter that you CAN’T write an app from scratch with RE in its current configuration and that hurts the FUD argument you’re bringing up. The incentive to change is just there when you start seeing nonprofits integrate with their CRM in meaningful and visible ways. It just takes time for this information to percolate through the sector.
The one size fits most is really one size fits some. Nonprofits are pretty different – even ones that have similar missions can do things differently.
What’s also often true (and I’ve heard this numerous times from nonprofits) is that the integrated tools don’t do everything as well. They might be great at one thing, and not so great at another – so a nonprofit is not really getting the best deal.
Big vendors want nonprofits to go all-in-one, instead of providing open APIs so that people can integrate what they need, and pick the tools that are best for them. Sure, the integration takes support and help – but so do using the big tools – and very often the users needs aren’t met there, either.
Michelle,
I hear what you’re saying, but I think that nonprofits have this “we do things waaaay different than everyone else” mentality which, when you go to many nonprofits who do similar things, is just not true. Often there are small difference in nomenclature or business process which can be easily changed in Salesforce, or Salesforce can be plugged into something else using the API. Even when there are big changes, usually they can be accomodated fairly easily if you have a solid platform to start from. Just my .02….
One proposition that is amenable to the utility of salesforce is that the business processes of nonprofits are a subset of the business processes of for-profits, bearing a substantial resemblance to them. Where this is true, it makes sense to use tools built for for-profits and to bend them for nonprofit use.
Now one issue not addressed here that is germaine, is what happens if/when salesforce is acquired by a for-profit that isn’t so non-profit friendly. A one year promise of service isn’t very long. Nonprofits aren’t served when a service offered temporarilly for free at steeply discounted prices but then becomes too expensive to afford. When a rise in cost is reasonable, nonprofits can deal, but when it’s not, they often can’t and are then stuck with the costs migration. Anyone concerned about this?
I don’t know Phil. I think that argument is primarily a FUD argument. Until there’s more news about a possible salesforce.com takeover or buyout I simply think that possibility is fairly remote. That said, salesforce.com profits were flat last year despite a strong rise in sales revenue. That seems to fuel all the talk about a buyout.