|
As with others, I think the author is missing some things. With most of the SaaS 'enterprise' systems out there, you're often not replacing anything up front, but early adopters are free to try some parts of a service, demonstrate ROI, then angle for a wider rollout. This is the opposite of most traditional "enterprise" software evaluation/deployment cycles. The ability for individuals or departments at companies to use bits and pieces of services (imagine one dept at 'bigco' using box.net, for example) is what gives these SaaS players any chance at all of getting their foot in the door, and it's a good strategy. It's far less about 'sucking' from a 'checkbox feature list' standpoint, and more about grassroots adoption. Years ago I was on a team that developed an LMS for a distance learning institution. It checked off quite a lot of feature-list checkboxes - had far more features than most other open source packages out there at the time - but... it was a top-down system, designed solely to be used by all levels at a school org. It fit that institution just fine, but for anyone else to try to adopt it at their school, was just too difficult. We could have tried to do long sales cycles to other institutions, but didn't (for a lot of reasons). Moodle was being released around the same time, and while we had far more features that teachers wanted, Moodle was something any teacher could install and use just for their own classroom, without any external dependencies. History has shown that Moodle's really taken off - it got a lot of early adopter support from people who wanted/needed it, but didn't have the ability to affect change in their whole enterprise. |