SAAS Vendors Capitalizing on an Accessible from Anywhere Misconception

I think that there is a misunderstanding in the marketplace, a perception by Software as a Service (SAAS) prospects and customers, that the only way they can have a solution that is available from "anywhere" is if they choose a cloud solution. This is a ridiculous assumption and one that cloud vendors seem to be capitalizing on. World Wide Web accessibility should not be considered a discriminator for on-premises versus cloud debate, and it certainly shouldn't be considered an advantage for an SAAS solution option. If anything, level of flexibility in accessibility should be considered a disadvantage to SAAS offerings, since SAAS offerings by definition, require some form of WAN or Internet connection.

For on-premises deployments of Web-based software products, accessibility from the World Wide Web is a matter of corporate policy and network configuration. In many highly secure environments governed by extensive policies, procedures, and directives; it may seem "impossible" for a business group to receive permission to have their Web portal published externally, to the World Wide Web. This is not a technical matter. This is a policy matter. In that regard, SAAS does make the "impossible" possible, by allowing business groups to bypass rules that they would otherwise need to follow if they went the on-premises route. So, is enabling a customer to circumvent a procedure truly a competive technical advantage to SAAS? I don't think so, and I don't think marketing should communicate it as such.

I think an underlying problem that this situation highlights is that many businesses still lack the ability to effectively prioritize their Information Technology initiatives and align those initiatives with the demands of the business. It is easier and more beneficial/less costly for a business unit to go rogue with an SAAS solution than it is for them to work with IT. This situation also points to a flawed management practice of allowing business units to dictate their own technology solutions as opposed to following a single Enterprise Architecture strategy. Whatever the case, "accessible from the Web" isn't a technology discriminator for SAAS, and vendors shouldn't confuse people into believing that it is.

References

LeClaire, J. (March, 2012). Should CRM Apps Be in the Cloud? Retrieved March 12, 2012 from http://www.crm-daily.com/story.xhtml?story_id=030001S1KJNI&nl=1&full_skip=1.

A CRM Vendor Pricing Whitepaper and Its Proper Place in the Overall CRM Procurement Process

SugarCRM recently published a whitepaper titled, "CRM Vendor Pricing: A Comparative Analysis."  The whitepaper explains pricing models for the CRM industry as a whole, and then provides detailed pricing information for a short list of CRM vendors.  The whitepaper also provides a Total Cost of Ownership (TCO) analysis of the vendors (SugarCRM, 2011). 

The reason I am posting is because this whitepaper reminded me of a common pitfull organizations fall into with CRM projects and I thought I would write about it.  The pitfall I am referring to is beginning or leading a CRM project discovery with vendors and products, instead of through a more analytical process focused around business requirements.  While the information in the whitepaper is certainly useful, I believe it is most relevant to project teams who have already gotten to the point where they are evaluating a short list of CRM vendors to compare capabilities, pricing, and other aspects of the overall investment and just need some help collecting and understanding pricing models and numbers. 

Based on my observations in the field, I believe that too many organizations initiate a CRM project based on superficial vendor or product information, such as advertisements or pricing.  I think this is a huge mistake and very common.  Instead of a reactive approach, I believe that the best possible CRM vendor/product selection decision is one that spawns from due process.  The project management processes that I've found to be very supportive, leading up to a CRM vendor/product selection, include the following:

1.  Project Charter - Purpose, business case, initial scope statement, team, affected organizations, order of magnitude
2.  Requirements Analysis - Surveys, interviews, general business requirements, technical requirements, solution requirements
3.  Scope Management Plan - Project scope baseline, requirements traceability matrix, boundaries, constraints, etc.
4.   Request for Proposal (RFP) - Template with detailed questions to be issued to vendors
5.  Vendor Evaluation Round 1 - Identify all possible candidates
6.  Vendor Evaluation Round 2 - Use requirements to eliminate and reduce list to a "short list", try to narrow down to less than 5
7.  Vendor Evaluation Round 3 - Issue RFP to short list, conduct demonstrations, narrow down to 3
8.  Final Comparison - Present full comparison of final 3 vendors with advantages/disadvantages, cost comparisons, etc.
9.  Vendor/Software selection

Based on the steps listed above, the whitepaper and the type of information it contains, really comes into play around step 6.


Reference

Blytheco (2011). Blytheco Sets its Own Competitive Prices for Sage CRM. Retrieved June 8, 2011 from http://www.blytheco.com/sagecrm/price.asp

Blytheco (2011). Sage SalesLogix Price List. Retrieved June 8, 2011 from http://www.blytheco.com/saleslogix/price.asp

Sage (2011). Sage ACT! Pro 2011. Retrieved June 8, 2011 from http://www.act.com/products/2010/act/

Salesforce.com (2011). Sales Cloud. Retrieved June 8, 2011 from http://www.salesforce.com/crm/editions-pricing.jsp

SugarCRM (2011). CRM Vendor Pricing: A Comparative Analysis. Retrieved June 8, 2011 from http://media.sugarcrm.com/white_papers/CRM_Total_Cost_of_Ownership_Analysis.pdf

Sonoma Partners (2011). Microsoft Dynamics CRM Online (SaaS / Hosted). Retrieved June 8, 2011 from http://www.sonomapartners.com/microsoft-crm-pricing.aspx

SugarCRM (2011). Sugar Subscriptions & Pricing. Retrieved June 8, 2011 from http://www.sugarcrm.com/crm/products/editions.html