Despite the success of the companies mentioned above, many people are still skeptical about the long-term success of SaaS. Data sensitivity, privacy and security (outside the user's firewall), the system's flexibility, and concerns about recent, highly publicized outages (which translate into general system performance concerns) represent only some of the issues that will give on-premise applications a longer lease on life. In addition to such concerns, the question of whether on demand hosted offerings can be properly integrated with existing on-premise applications as well as skepticism over the usefulness of adapting SaaS or on demand solutions to unique business processes and practices top the list of doubts.
Salesforce.com and other SaaS-evangelist companies typically offer workable solutions for such standard business operations as capturing sales opportunities and leads. However, by using true multi-tenant architecture, which allows volumes of numerous customers' data to be stored on a single instance of the database on the vendor's premises (a heck of a lot of metadata to be maintained by the vendor), such applications often cannot offer companies (especially large and demanding ones) the kinds of differentiators they need to increase sales and profits or gain market share. Indeed, SFA processes are quite cut-and-dried (routine) and are not exactly revenue generators as long as their functionality is merely about capturing sales personnel's opinions on opportunities and making sure that they abide by the sales process rules.
Sales forces are quite successful at leveraging this "one-size-fits-all" delivery model, as they are still to this day the least regulated of all business process functions. This delivery model enables each sales person to quickly deploy a solution because, in their opinion (and consequent attitude), the tools they use do not impact the other parts of the organization. That is to say that in such environments, there is no point in extensively customizing the SFA system since it is not the details of the sales process that matter much. For instance, since planning implies some ability to proactively influence the outcome, those user organizations that have attempted to integrate the disconnected SFA function with the forecasting, fulfillment, and accounting aspects have uncovered additional challenges when these are attempted in a SaaS manner.
In other words, resembling the well-known "80-20 rule" somewhat, that final 20 or so percent that sets any company apart from its competitors often cannot be provided by SaaS solutions. The need for differentiation will require the enterprise to still seek out more traditional vendors who have industry-specific expertise and broader functional footprints to accommodate evolving, interdepartmental business processes. At the very least, coexistence of SaaS and on-premise applications will be the reality for many enterprises (Microsoft cites the existence of dual models, where a PC-installed application can be enhanced by online functionality, as seen with media players like Windows Media Player), so SaaS will be able to move beyond providing operational efficiency toward helping businesses become more effective. Giving users the ability to customize screen field names, as one is able to do in a Salesforce.com service, is not going to cater to true differentiation. Neither will enabling users to write JavaScript (or similar) and put the universal resource locator (URL) for the script in a custom field, nor will the use of tab access and the style sheets, which is what Salesforce.com refers to as "customization".
This resembles the "a-ha" notion of the "iPod user experience" that lets users listen and arrange music to their (distinguished) hearts' content in a new, simple, clear, and appealing way. Companies need to conduct their business processes differently from what they have done in the past if they want to set themselves apart, and this includes creating new features and interdepartmental/inter-enterprise flows. Thus, it remains to be seen how much Salesforce.com's Apex, the vendor's most recently unveiled multi-tenant interpretative language, will help in that regard. Apex, a runtime engine with Java-like syntax and the functionality of procedural language structured query language PLSQL (since the underlying database at Salesforce.com is Oracle), was designed to work with the Salesforce.com application programming interface (API). Apex has limited functionality that can only do what it was designed to do (special database triggers and stored procedures, for example), and it is not really the general-purpose programming language needed to accommodate significant custom programming. Again, the benefit of a controlled environment comes with the downside of limited tailoring. Enterprises also want more control of their applications, as they need to constantly change configurations in order to add new products, develop closer integration between their systems, and introduce best-in-class business processes.
Salesforce.com and other SaaS-evangelist companies typically offer workable solutions for such standard business operations as capturing sales opportunities and leads. However, by using true multi-tenant architecture, which allows volumes of numerous customers' data to be stored on a single instance of the database on the vendor's premises (a heck of a lot of metadata to be maintained by the vendor), such applications often cannot offer companies (especially large and demanding ones) the kinds of differentiators they need to increase sales and profits or gain market share. Indeed, SFA processes are quite cut-and-dried (routine) and are not exactly revenue generators as long as their functionality is merely about capturing sales personnel's opinions on opportunities and making sure that they abide by the sales process rules.
Sales forces are quite successful at leveraging this "one-size-fits-all" delivery model, as they are still to this day the least regulated of all business process functions. This delivery model enables each sales person to quickly deploy a solution because, in their opinion (and consequent attitude), the tools they use do not impact the other parts of the organization. That is to say that in such environments, there is no point in extensively customizing the SFA system since it is not the details of the sales process that matter much. For instance, since planning implies some ability to proactively influence the outcome, those user organizations that have attempted to integrate the disconnected SFA function with the forecasting, fulfillment, and accounting aspects have uncovered additional challenges when these are attempted in a SaaS manner.
In other words, resembling the well-known "80-20 rule" somewhat, that final 20 or so percent that sets any company apart from its competitors often cannot be provided by SaaS solutions. The need for differentiation will require the enterprise to still seek out more traditional vendors who have industry-specific expertise and broader functional footprints to accommodate evolving, interdepartmental business processes. At the very least, coexistence of SaaS and on-premise applications will be the reality for many enterprises (Microsoft cites the existence of dual models, where a PC-installed application can be enhanced by online functionality, as seen with media players like Windows Media Player), so SaaS will be able to move beyond providing operational efficiency toward helping businesses become more effective. Giving users the ability to customize screen field names, as one is able to do in a Salesforce.com service, is not going to cater to true differentiation. Neither will enabling users to write JavaScript (or similar) and put the universal resource locator (URL) for the script in a custom field, nor will the use of tab access and the style sheets, which is what Salesforce.com refers to as "customization".
This resembles the "a-ha" notion of the "iPod user experience" that lets users listen and arrange music to their (distinguished) hearts' content in a new, simple, clear, and appealing way. Companies need to conduct their business processes differently from what they have done in the past if they want to set themselves apart, and this includes creating new features and interdepartmental/inter-enterprise flows. Thus, it remains to be seen how much Salesforce.com's Apex, the vendor's most recently unveiled multi-tenant interpretative language, will help in that regard. Apex, a runtime engine with Java-like syntax and the functionality of procedural language structured query language PLSQL (since the underlying database at Salesforce.com is Oracle), was designed to work with the Salesforce.com application programming interface (API). Apex has limited functionality that can only do what it was designed to do (special database triggers and stored procedures, for example), and it is not really the general-purpose programming language needed to accommodate significant custom programming. Again, the benefit of a controlled environment comes with the downside of limited tailoring. Enterprises also want more control of their applications, as they need to constantly change configurations in order to add new products, develop closer integration between their systems, and introduce best-in-class business processes.
No comments:
Post a Comment