Dan Carmel from SpringCM gave the second keynote today, focused on his premise that SaaS = Lean. Although I would agree that many SaaS applications are Lean from a customer’s standpoint, that’s not true with all of them. Yes, using SaaS applications potentially has a much leaner footprint for a customer since there is no hardware or software on their own site, but you also need to consider the efforts to integrate with other systems, including on-premise systems. If the SaaS app (or any on-premise app, for that matter) can be reconfigured and integrated with a minimal effort, then things continue to look Lean; if it’s closed and requires custom kludges to integrate, then not so much.
He went through some good examples of Lean and extensible SaaS environments, such as Salesforce.com and Webex Connect, then pointed out some areas where on-premise systems can be a big challenge, but SaaS can provide sufficient business value even at lower volumes: ECM, for example (no surprise, since that’s what SpringCM sells), where high initial costs tend to keep all but large companies from deploying internally.
He then introduced Joe Graves of Stratus Technologies (a SpringCM customer) about their journey with SaaS. They started using Salesforce.com about five years ago, deploying to 170 users worldwide in a matter of weeks from the start of the project. They use a number of applications integrated with Salesforce.com, and when they needed ECM for contract management, they selected SpringCM because it’s tightly integrated and because they were already sold on the value of SaaS. He outlined their benefits: lower upfront costs with no capital outlay, quicker implementation time, reduced operational issues such as storage management and disaster recovery, and allows IT to focus higher up in the value chain rather that fussing with operational issues that don’t improve competitive differentiation. Although many people have concerns about customization and integration, security, and uptime of SaaS apps, Graves pointed out that there are ways to deal with all of these when you’re working with a properly built app, and that as long as it meets your functional and operational requirements, there isn’t a problem. [As I like to point out to people who use the highly publicized downtime of SaaS apps such as Salesforce.com and Gmail as justification for not using SaaS: your internal systems go down too, it’s just not publicized across the internet; in fact, the level of transparency that a SaaS provider has around their failures can increase customer commitment.]
Honestly, I don’t care if “SalesForce” (insert favorite SaaS product) is Lean. I care if my “Sales Process” is Lean. And even more than that, I care if it produces reliable revenue streams at reliable cost outlays.
I may care if the deployment of said applications is “Lean” but that isn’t the only factor in deciding what application (or architecture) I want to use.
There are good reasons to use SaaS applications, but a Lean argument is a bit of a stretch for me. Or at the very least, it isn’t high on the list. I’ve used QuickArrow, for example. A SAAS product. But I assure you that entering time and expenses and the approvals that are all implemented in this product are NOT lean. So… cart before the horse?
If it wasn’t clear from my post, I don’t equate Lean and SaaS. I agree with you that it’s about internal processes and the impact that the systems have on them, not whether it’s SaaS or not, or even if the SaaS product is developed in a Lean fashion.