June 22, 2009 01:44 PM ET

CIO - By now, most organizations have used some sort of a SaaS application, so there's familiarity with the basics of hosted software. But CRM applications are by their nature much more likely to be integrated with other business-critical applications, either behind your firewall or in hosted data centers, so they present some new challenges. Furthermore, applications with really rich web-services APIs (such as Salesforce CRM) can surface operational, policy, and process issues in your IT organization.

Given all this change, where should you as CIO concentrate after rollout? Here's some practical advice. While much of this article applies to any SaaS CRM system, we've focused here on the specifics of Salesforce.com.

1. IT Team's Level of Engagement

In many early parts of a Salesforce CRM project, there isn't that much for many parts of the IT team to actually do. Typically, configuration and rollout is done by consultants or staff within the user departments, and over time they become fairly self-supporting. Even though your team won't deploy much in the first year, there are important roles for them to fill, including: oversight for security, policy enforcement, and asset protection; guidance on architectural issues and ramifications of decisions; and access to data in other systems, for migration or integration.

After the first year, however, your team is likely to become more involved, particularly if the system is a big success. There will be demands to extend the application's footprint (particularly towards your web site) and internal integration (generally in the direction of engineering's support system and finance's order management and accounting packages). This is natural as the users start working with the system as a full fledged CRM system, rather than just an SFA tool.

2. Integration and Extension

The biggest effort related to a new SaaS CRM system won't be implementation or customization: it'll be data and integration. The basics of integration, or hooking up the "pipes," is often straightforward. Available integration connectors and a rich set of web services APIs make Salesforce.com very easy to integrate with other applications.

But getting the data semantics and transactional context right will involve serious thinking and some amount of data rework. As with any complex system, integration exposes data problems that were hidden or tolerable in siloed operation. Don't be surprised if cleaning up data and integrating with your existing systems costs more than your first-year license fees.

3. Performance and Business Continuity

In many respects, with a SaaS CRM system, the vendor is ultimately responsible for delivering on the SLA. Salesforce.com has a very good record indeed of operational continuity, and the company provides several weeks' notice for planned downtime. Most of the time, their servers respond to user interactions within 250 milliseconds, and they publish real time performance and continuity statistics on their web site.

In most cases, however, the perceived performance of SFDC in your headquarters buildings will likely be somewhat slower than with an on-premises application; conversely, it will be perceived as much faster in remote offices (particularly those located outside the United States). This is because any SaaS or Web 2.0 application tends to have fairly large page sizes, so any packet drops or other latency makes the page refreshes look very slow. These problems are particularly noticeable on marginal WiFi links. SFDC may give you a good excuse to do those base station upgrades you wanted anyway.

4. Access Control and Security

Of course, your team needs to configure the access control and security model, but it's the vendor that is ultimately responsible for enforcement. Salesforce.com has a pretty thorough role and profile-based security model, and it can be configured for access hours, network address, and other access controls. If a good measure of "sufficient security" is "the user's complain about too many access controls," Salesforce supports sufficient security and then some.

One area you'll need to investigate is information leak protection: I know of no SaaS system that includes features in this area. Make sure that your company's ILP software is configured to recognize Salesforce's .csv and .xls files, so that your policies are fully enforced for CRM data.

5. Data Quality

As with any large system, data pollution is an inevitability. Business analysts and others will discover corrupted or duplicate data creeping into the system over time. Reports run for executives will start to show contradictory or confusing results. This is poisonous to a CRM system's credibility.

Whether you use temporary coders, data-entry clerks, or overtime hours of internal people, set aside some budget for a health check and cleanup cycle at least once a year. You'll almost certainly want a deduping or data cleansing tool, which at $3,000 per year or more is still money well spent.

You'll also want to devote quality time (from your team or specialized consultants) to identify the source of the data pollution problems, rectify them, and programmatically clean up the data. Data quality issues become dramatically more noticeable when the CRM system is integrated with other production systems. One company I know of had hundreds of duplicate accounts spuriously created every day due to integration problems with business partners' systems.

6. IT Team Skills

Some of your staff will take System Administrator or Developer classes to become proficient with the details of the CRM package, of course. However, your team may also need some new lessons at a project management level, especially IT staffers dealing directly with business users who don't know or care much about technology. As more IT pros play roles akin to business analysts, listening and counseling skills will be important.

Second, SFDC lends itself to agile project management techniques. An agile deployment style focuses on investing just enough in the technology to make a business impact quickly. Deployments of new SFDC features to users are almost always done iteratively, and may happen on a monthly basis. If your project or program managers don't "get" Agile techniques, they will need to get some training. If they view agile as chaotic, unmanageable, and/or anti-architecture, then they're going to need some attitude adjustment, because nearly all new CRM systems evolve this way.
David Taber http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9134644