I have been working within the Salesforce.com ecosystem for more than 7 years. In that time, I have seen the technology grow from a CRM application targeted mostly at the SMB market to a technology platform that has gained serious credibility with some of the largest companies in the world. In my role, I have the opportunity to meet with all types of businesses about their strategy (or lack thereof) to gain efficiency by bringing solutions to “the Cloud.” I have recently been faced with a number of companies debating the question of whether it is appropriate to grow their footprint within a single instance of salesforce.com or whether to leverage multiple instances. Still other companies that have already acquired multiple instances look to consolidate into a single instance. The questions that they pose about which approach is superior presume that there is a one-size-fits-all answer. Although there is no single solution, this post will outline a set of decision criteria that should be considered.

Most CRM professionals agree that a single instance of a CRM system lowers total cost of ownership and creates efficiency in maintenance, support, and re-use. However, proponents of a multiple-instance strategy would argue that localization provides for more flexibility and more closely addresses the needs of end users. For them, the tradeoff to consolidating to a single instance is that the system becomes less useful and introduces more bureaucracy. Hmmm. Where do we go from here?

Reporting
Let’s begin with data visibility and reporting needs. If, at any point, it is going to be a requirement for senior management or someone else in the organization to do global reporting, a single instance should be considered. This type of reporting makes it easy to compare performance in various regions and evaluate variability in system adoption. By its nature, it also makes it easier to do analysis because data structures are common and the analyst can compare apples to apples. It’s true that there are alternatives to global reporting needs like an enterprise data warehouse where data is aggregated for holistic viewing, but the presents an additional challenge of marrying disparate data structures. The best approach is to establish a single source of truth that can be referenced without transformation or lag time.

Collaboration
Related to data reporting is data sharing. CRM, at its core, is about tracking and sharing information about customers. Silos between functional groups like sales, marketing, customer service and account management fundamentally kill the effectiveness of a sound CRM strategy. For this reason, if an organization has the need to share data between geographies, functional groups or process areas, then a single instance is appropriate. Collaboration is key, and if the organization is dealing with a common set of customers, they should consider leveraging a common system for sharing information. In cases where geographically segmented customer bases or business lines don’t share customers, they can autonomously operate in separate instances.
It should be noted that a Salesforce-to-Salesforce integration is an alternative to sharing information across orgs, but not a replacement for a full view of customer data.

Integration
If an organization is leveraging integration from back office or third party data sources, it will be a major factor in determining whether to go with a single or multiple instances. Integrations cost money. These costs can be attributed to the time spent developing, testing, deploying, and managing them, or in the case of third party data sources, there is a cost of obtaining connections to a metered service. In either case, it seems desirable to consolidate integrations wherever possible. Rationalization of these processes also tends to establish consistency in the output of the integrations (for example, if data as being transformed one way from the back office system to Salesforce.com instance A and transformed a different way to Salesfore.com instance B, a mismatch is created).
However, if an organization is obtaining common data elements from multiple data sources, it may be a good case to have multiple instances of Salesforce.com. To illustrate, consider a company with two divisions that operate in two different geographies. In one geography, SAP is used to manage customer financial data and in the other, a homegrown ERP system is used to manage the same information. With the back office systems separated, it is likely that there are going to be conflicts related to key customer information if we try and integrate both into the CRM tool. In this scenario, it would seem that the two geographies operate fairly independent from one another, so multiple instances of Salesforce.com might be the optimal way to go.

Process Rationalization
As mentioned earlier, proponents of the single system site operational efficiency and total cost of ownership as benefits. To dig a bit deeper into this, we need to do some detailed analysis of the process overlap between various business segments. Is there commonality? Is there synergy? Or are there direct conflicts?
With traditional CRM tools, process diversion would be a good reason to propose multiple instances, but with Salesforce.com a significant amount of localization can be accounted for within a single instance. Process reconciliation is potentially a complex and involved process because it has as much to do with managing change and changing old habits as it does evaluating real business drivers.
It is important to note the strong executive sponsorship is key to effectively prioritizing localized process support against other business drivers like globalization or cost management. Most regional business leaders are incented on the performance of their own business so conforming to a standard process (or system) for the common good is not a big motivator.

Governance
In any case where multiple business groups are operating within a single instance of CRM tool, a thorough governance strategy needs to be in place. Governance is the set of policies, roles, responsibilities, and processes that you establish in an enterprise to guide, direct, and control how the organization uses technologies to accomplish business goals. A governance steering committee should have representation from senior management, IT, Salesforce.com Administrators, and participating business units. The plan should include detailed processes for prioritizing and vetting issues that arise so that conflicts are resolved.
With a multiple-instance strategy, governance is still important, but not as critical as when competing interests are prevalent.

Administration
Administration is one of the areas often cited as being an opportunity to create efficiencies for companies considering going from multiple instances to a single instance. In most cases, each instance has one or more people responsible for administration and maintenance. When consolidation occurs, the job becomes larger because the resulting system can be more complex, but the redundancy is often eliminated. The breakeven point for what is optimal varies on a case-by-case basis.

Globalization Settings
Salesforce.com provides standard support of globalization features like multi-language and multi-currency. Consolidating multiple instances into a single instance will have an impact on users if doing so requires either of these features to be enabled. Who will be responsible for maintaining the Translation Workbench? How will currency conversions be managed?

Governor Limits
Some Salesforce.com governor limits are set based on the number licensed users in an instance (e.g. API calls per day). This can be a consideration in cases where multiple instances that are heavily customized or are running integrations that require API calls.

Edition Constraints
For organizations looking to consolidate orgs, the Salesforce.com Edition of each candidate org should be evaluated. In every case I have seen, it is advisable to consolidate into the highest-level edition of the candidate orgs. For example, if looking to consolidate a Professional Edition and an Enterprise Edition org, it should be done using the Enterprise level instance at a minimum. It may be required to move to Unlimited Edition if the joining of the two orgs would exceed certain limits imposed by Enterprise Edition.

In evaluating your organizations optimal endpoint, these are some of the factors that should be evaluated and prioritized. The analysis needs to be thorough and balanced to ensure that the opportunity cost for each decision is well understood and documented.

Unless you live in a technology cave you have probably noticed the discussion in the industry around Flash and HTML 5 that has been started by the Apple controversy.  My goal here isn’t to rehash what has been said around using Flash or HTML 5 in a browser or on a mobile device, but to share my thoughts around this debate as it applies to Enterprise Business applications.

There is valid debate occurring around the pro’s and con’s of using Flash to serve a banner ad, or a video, or if the <canvas> tag or <audio> tag are a viable alternative.  However this is a minor point when you are considering which platform to use to create a business application or a consumer facing RIA (Rich Internet Application).

First, let’s look at where the HTML 5 spec currently sits.  It is a much-needed refresh of the current HTML 4 spec and has some great features such as support for video, audio and offline data storage using SQL Lite.  The W3C HTML 5 specification is currently in “Working Draft” status and is not expected to be finalized until 2012 or later.  The other current issue with HTML 5 is that is only supported in varying degrees by the major Internet browsers and some of its features may never be supported by some browsers (such as an offline data store).

We do a lot of work for Fortune 500 clients and have used both Adobe Flex and HTML 5 on projects.  Currently HTML 5 is an option if you have full control over which browsers will be used to run an application (which is frequently not the case, even in the Enterprise).  In contrast, Adobe Flex is a great platform to build business applications and can run in virtually all desktop browsers. 

Flex is a rich platform that has complex UI elements (data grids, tabbed navigators, menus, etc.) built directly into the Flex SDK (now called Flashbuilder).  It allows you to take your application and easily run them in Adobe AIR (Adobe Integrated Runtime) on the desktop (outside of the browser) or on a mobile device*. 

As a company we are generally technology agnostic and try to bring the best options to the table to meet client needs.  Although our focus is around deploying Cloud based solutions we have found that user interface or taking the Cloud offline is important to our clients.  The question of Flex vs. HTML 5 for a business application is an easy one to answer today and will likely be so for the next couple of years.  The promise of HTML 5 is great, but until the specification is finalized and it is widely supported by all major browsers it can only be used in limited ways and it doesn’t have the developer productivity tools that are inherent in Flex. 

Here is a real world example.  One of our early iPhone products on the iTunes AppStore was Search2GO, a simple search tool for Salesforce.com.  This was built in Objective C and it took approximately 8 weeks to develop.  Yesterday I watched two developers create over half of this same functionality using Flex/AIR and had it running on an Android phone in a day.  Granted there are still things that could be added, but this was a great illustration of why Flex/AIR is a great toolset.

So while the debate rages on about HTML 5 vs Flash in the consumer market I’d recommend taking a hard look at Flex for business applications.

* Except the iPhone or iPad of course…

Today, Marc Benioff, the ever-vocal CEO of salesforce.com made a blog post over at Fortune on the end of Microsoft. In his post he outlines Microsoft’s latest ad campaigns, the ones spouting off about Windows 7 being "my idea." He pokes fun at one in particular where Windows no longer crashing was somehow deemed a feature.

Is that how low our expectations are these days? Certainly not in general, and it is a sad state of affairs for Microsoft that crashing is one of the expected behaviors of a Windows device.

He goes on further to point out the explosive growth and success of sites like Facebook and YouTube. These consumer websites have absolutely changed people’s expectations of what a web experience should be like: engaging, easy to navigate and providing loads of value.

Here at Model Metrics those themes ring true for everything we build. We do nothing but cloud computing, which is really what Facebook and YouTube are all about. Computing in the workplace has historically lagged behind what’s available at home. That’s no longer true. With technology from salesforce.com, Google, Adobe and Apple getting things done at the office is as easy as using your favorite personal websites.

While Microsoft isn’t leaving any time soon, newer technologies are showing better promise than the failed paradigm of machines prone to crashing.

At long last, the oft-rumored VMForce has been officially announced.

Huh?

VMForce is a technology brought about by a partnership between salesforce.com and VMware,     the leader in virtualization technology. VMForce enables Java applications to run on Force.com infrastructure, the robust development platform built by the folks at salesforce.com.

What does all of that mean?

Java is one of the most widely used development languages in the world. It is a mature technology with millions of active developers, with more applications running than can likely be counted. With VMForce, many of those applications can now be migrated easily to run in the cloud.

These applications will then be available anywhere, on almost any device. They are instantly social, searchable, and scalable. And since they’re on Force.com, you get great security and visibility into uptime.

Whether you have been working with Salesforce.com for years or just considering a new implementation, this is some information you can really use.

Salesforce.com has helped to define cloud-based computing and has revolutionized the industry with an intuitive, secure, flexible, configurable, and scalable platform that has allowed businesses of all sizes to solve their business problems without all of the infrastructure headaches of traditional IT projects. Those of us that have a long history with the product know how dramatically different this technology is from the status quo and we believe in the benefits that can be realized.

With all of that said, the platform is evolving to support the needs of large, more complex organizations. What does this really mean? It means that there are more choices, more technology, and more capability that ever before. With all of these capabilities and choices comes some responsibility to get educated on how to manage change so that it is reliable and predictable.

I have used this forum to post a number of articles about the people-focused aspects of change. In this post, I want to address some of the more technical matters that are often overlooked within the context of salesforce.com implementations, and that is the topic of Environment Management.

Environment Management Defined
My high school history teacher used to parrot the phase “words mean things” when challenging abstract arguments. For this reason, I want to be clear about the context that I am using to define “Environment Management.” Simply put, Environment Management is the strategy, process and tools used to manage a Salesforce.com instance (metadata) so that it remains current. This includes the management of multiple environments (development, QA, staging, training, production, etc) such that the correct updates are deployed to the correct environment at the correct time.

A History Lesson
In the client server world, environment management and deployment were largely coordinated with the use of source control tools and defined release cycles between environments. With a combination of process and technology, new “builds” were deployed from one environment to another to protect the production environment while creating a rollback path. With compiled projects, we could be assured that the application in one environment would be identically synchronized with that in another environment because everything was packaged together.

For web applications, the same was generally true. Although the elements of a web application were a bit more dispersed, each component (web form, class, controller, etc) could be managed within source control and differences could be easily assessed.

The early days of salesforce.com removed this complexity by providing a single, real time environment for applications. Any updates made through declarative development (e.g. configuration of metadata) were immediately deployed so that all users could take advantage of the new updates in real time. No more complex IT processes, no more exorbitant lead times… just a world of fast-paced productivity.

As the platform evolved, so did the need to test. The feature set was enhanced such that there were legitimate reasons to leverage a test environment to QA new functionality before it went live in production. There were workflow rules, custom code, approval processes, options that once enabled could not be disabled…. The Sandbox environment was born. The sandbox could be used to try out new features before they were enabled in production, allow users to test or train in an environment separate from the production environment, and could even be refreshed to create an almost-exact replica of production. However, for a long time, it was not possible to promote configurations in the other direction (from Sandbox to Production).

The world has changed again. The use of a sandbox is a requirement for Apex and Visual Force development, and the meta-data API makes it possible to package metadata components through Eclipse, the Force.com migration tool, salesforce.com deployment utility, or through a third party solution like Snapshot.

The Issue
Seemingly, the development of all of this new capability would provide salesforce.com even more validity in the enterprise space, and we could refer back to what we have learned about packaging solutions, deployment, change control and release schedules. This is all true to some extent, but there are nuances of operating in this metadata driven environment that are unique, and without paying close attention to the details there is significant risk in oversimplifying the process.

There is no single silver-bullet solution to perform comprehensive environment deployment in force.com. All of the automation utilities and packages leverage the Metadata API that handles some, but not all, of the components that make up a full environment configuration. This means that no matter which strategy you choose, there will be some manual configuration required in the production environment. The complete list of what is covered and what is not covered through the metadata API is beyond the scope of this article, but examples of those thing include are:
- Apex classes
- Apex triggers
- Analytic snapshots
- Custom applications
- Custom objects
- Custom fields
- Reports/Dashboards
- Custom page Web links
- Custom sites
- Custom tabs
- Etc.

This list of items not covered is extensive, but notable examples include
- Role Hierarchies
- Public Groups
- Approval Processes
- Assignment Rules
- Org Wide Defaults
- Escalation Rules
- Assignment Rules
- Etc.

Solution
The first big step to solving this issue of lacking a comprehensive deployment capability is being aware of the issue. To take you the rest of the way, I recommend a combination of planning and best practice guidelines to ensure success.

Have a Strategy
When it comes to setting up your Salesforce.com environment, it is important to do so with deliberate planning. If your environment requires one or more sandbox environments, be clear about the purpose of each and the promotion path between them. Do you need a separate environment for development, QA, Training, Staging, etc? If so, who will be responsible for maintaining each? What will be the path between them? How often will they be refreshed from production?

Once the environment is established, it will be necessary to determine what means will be used to promote new releases between environments. Will this be an entirely manual process or will a utility be used? If automation is part of the equation, which tool will you select?

Change Control
The need to coordinate manual changes along side automated deployments requires that a strict change control process be implemented. As part of the process, a few guiding principles are helpful:
- Define all dependencies between packaged components or your deployments will fail.
- Make all changes in the development environment (or whichever environment defines the “beginning” of the process). Do not make changes at intermittent stages as they will be much more difficult to track
- Follow a regular cadence of release “trains” for predictable, packaged releases. Do not introduce “hot fixes” as they will also create synchronization issues with other environments.
- Create a backup of the metadata configuration before pushing to production
- Document all changes made to the production environment
- Establish a central point for creating new production changes. This should not be a distributed responsibility.

Select a Tool
If automation is part of the strategy, select a tool that best meetings the needs of your developers/administrators. There are a number of options including the deployment utilities that are packaged into the salesforce.com application, but be selective and understand the feature sets and use model of each.

For more information on environment management, please contact me at bkalma@modelmetrics.com.

On the heels of my Top Cloud Computing Stories of 2009 comes (appropriately enough) my Top 5 Cloud Computing Predictions for 2010. Let’s jump right into it.

1) There Will be Another Outage, and No One Will Panic
In 2009 there were two significant outages of Google’s Gmail service, which rendered it unavailable temporarily. The most interesting part of the story is that the outages are so rare that they were deemed newsworthy by the mainstream media. In 2010 there will likely be an outage of another major Cloud Computing vendor, and the reactions in the media will be the same. It will be covered broadly for 2 reasons:

• Outages are very rare
• Critics and IT luddites are looking for a story to keep the business side off of their backs

Either way, vendors have their best and brightest working to ensure that they don’t happen, and if they do happen they will be short-lived and you won’t even have to think about it. The problem fixes itself.

2) Google Enterprise Applications Will Gain Large Acceptance
In 2009 Google gained significant traction in the market with its Enterprise Apps (Gmail, Docs, Calendar) and in 2010 that trend will only accelerate. Enterprises spend approximately $17b annually on Microsoft Office, and Google’s pricing model combined with its flexibility mean Microsoft could be in trouble. Organizations are always looking for ways to save money, and this is an easy one.

3) Consolidation of Cloud Computing Vendors The big players in cloud computing (Salesforce, Google, Amazon Web Services) have all built good products with basic functionality, and rely on external players to augment them. They focus on what they do best, and outsource the rest.

As many of these augmentations become more mature and become more native to the platforms, look to see the smaller companies to get swallowed up. This creates more value for the big vendors while limiting their exposure to development risk, and increases their internal talent pools.

Combine the business reasons for acquisitions with the ongoing improvements capital markets, and consolidations should make a big comeback this year.

4) "Young" Vendors Will See Explosive Growth
As more parts of the various cloud computing platforms are further opened up for development, expect to see fresh young startups blossoming to fill business requirements. I also fully expect to see our company’s offerings around sales, service, and call centers to grow for these exact reasons.

5) Cloud Computing’s Growth Accelerates
The economic turmoil has been going for over 2 years now, and it appears we are in a new normal. This environment has forced companies to cut costs and run leaner than in previous years. With IT budgets either shrinking or headcount being reduced, it is no longer optional to optimize staff’s time. Organizations do not want to waste resources on maintaining email servers or other on-premise applications when on-demand applications in the cloud make more sense financially.

Did you know the federal government spends over $75B annually on IT? With that number in mind, you can imagine the enormous amount of manpower it takes to choose, customize, build, deploy, and maintain separate instances of applications to run the government’s operations. I cannot imagine a more perfect environment to deploy cloud computing, and it is apparent that the President “gets it” too.

In keeping with his initiative for lowering the costs of running government, the White House this year launched apps.gov, an online repository for federal agencies to explore and purchase cloud-based IT services. So instead of having to individually seek out vendors, government agencies now have a one-stop shop to get most of what they’re looking for. And guess what – salesforce.com and Google are featured vendors.  

In a year of giant bailouts, it’s about time the taxpayer got a break from politicians, except this time it’s technology that’s doing all the heavy lifting.

The fastest growing social media site in 2009 was without question Twitter. The notoriety seemed to explode with the Iranian election and ensuing chaos, where reporters were unable to provide accurate, timely information. With the government lockdown, the citizenry got information out to the world through Twitter on their mobile phones. A new dawn of media became legit overnight.

Twitter users rely on the service for more than just timely information, it has become a platform for open conversations around any topic. Company’s products and services have become fair game for both interested prospects and disappointed customers. Instead of calling a sales or customer service line, people are turning to other users for answers on Twitter – leaving companies in the dark. Anyone who has tried to navigate a customer service "dial 1 for X" menu understands why so many are reticent to use them.

Salesforce.com recognized this growing trend and created a truly elegant application that’s easy to use. Salesforce for Twitter allows companies to participate in conversations actively, and track those conversations within salesforce.com, providing a more complete view of their prospects and customers. This added information gives companies an opportunity to better serve these people, and in the channel of their constituent’s choosing.

With this application, if someone expresses interest in your company, you can respond to them on Twitter through salesforce.com. Likewise for customer service situations. I don’t believe there’s such a thing as a 360˚ view of a customer, but having more information on hand certainly allows companies to provide more relevant service.

Check the video demo out below:

Yes, seriously, Sales Chatter from salesforce.com. If you were at the Dreamforce user’s conference this year, then you already know what this is about. If not, picture an application that combines functionality of Facebook, Twitter, and salesforce.com apps. You can update your status for co-workers to see, and you get a news feed of not only what others are up to, but what’s new in your favorite apps such as Content library updates.

You might think it’s too early to call this one of the biggest stories of 2009, but it is big news from the biggest player in enterprise cloud computing. Just as no one knew just how quickly Twitter would grow, I have a feeling we’re at the same point with Chatter. This could be truly huge.

For a quick video on what’s included and how it works, check out the video below.

I recently had a conversation with the VP of Sales at a large manufacturing company.  For the purposes of this discussion, I will call him John.  John and his sales organization have never had a centralized, collaborative CRM system before and they are about to begin a salesforce.com implementation.  Among the goals of the project is the need to consolidate the many point solutions they have used for managing their customers over the company’s 40-year history.   They recognize the need to establish consistent processes for the sales team and want to leverage workflow capabilities to improve communication.  After a series of fruitful meetings, John mentioned that he is working with IT to purchase mobile devices for the sales team because he has received a lot of demand from the team, and wants them to be as productive as possible with the new CRM tool.

The scenario described above is very common.  The benefits of leveraging mobile technology for a sales rep include increased productivity, more timely information, access to real-time data at the point of contact, and access to information without the overhead of lugging a clunky laptop.  All of this is theoretically sound, but don’t let your mobile strategy define itself without thoughtful consideration of questions that are sure to be raised as part of your implementation.  Addressing these issues proactively will allow you to separate fact from fiction and apply a mobile strategy that fits your organization and your users so that you can realize success.

Who are your users?
The diversity of the user base is a great place to start in defining a strategy.  It is common to have a mix of technologist and technophobes within the same sales team.  The technologists tend to demand all of the latest and greatest tools and technology as a means of making themselves more productive.  Without it, they claim that their efforts are diluted and they are bogged down with administrative overhead required to access information or log calls.  On the other hand, the technophobes will resist any sort of change, especially when it comes to technology, by claiming that the time spent to manage all of these new tools and gadgets will negatively impact the time they spend in front of the customer.

When it comes to mobile, you are wise to know your audience.  If your team is not accustom to using mobile technology for email and basic calendar management, you may want to take steps to introduce the device before you make it a critical component of your CRM strategy.  Users who have leveraged these tools in their personal lives or at a past job will be much more comfortable in adopting this technology as part of their work.

When it comes to people, it is also important to note that strong demand for a Blackberry, iPhone or other device from users who do not currently have these products, may be a red flag.  The grass may seem greener on the other side of the fence for those who have bought into the idea that these tools will make them more effective.  I recently worked with a sales group that insisted that they needed offline capabilities because they weren’t always “connected.”  Once we provided the offline functionality, they demanded mobile devices because they found it cumbersome to “lug around heavy laptops.”  Once they received the mobile device, they complained about the small screen and the difficulty of entering data with a small keyboard.  This is exactly the type of situation we want to control by proactively managing a mobile strategy.

How mature are your processes?
As the saying goes “Process before technology.”  Change management is a key component to any CRM implementation.  The introduction to new systems represents a disruption, and optimizing or changing processes will require that users have a clear understanding of their role and expectations.  The process of change must be managed deliberately to ensure that users are not left behind as they adjust to their new way of working. 

If process change is part of your implementation, it is common (and a good idea) for the mobile implementation is postponed to a second phase.  It is important that users are familiar with the goals they are trying to achieve before they take on learning how to manage multiple entry points. 

What do users need to do to get their job done?
It may seem obvious, but it is critical to give objective consideration to what your users need to accomplish using their mobile device.  A clear definition of use cases serves as the basis for streamlining key processes and maximizing efficiency for end users.  When defining mobile needs, many companies make the mistake of setting an expectation that anything that can be done with a laptop should be possible with a handheld, and this is simply not realistic.  Use case definition should help to separate fact from fiction when it comes to defining what functionality needs to be available.

The reality of a handheld is that the physical size, speed and ergonomics are significant challenges for some users.  These factors make processes that require consuming or reading data better candidates than those that require entering data.  This is especially true of complex data entry processes where there are many fields or pages to navigate.  This is not to say that call logging or data entry are not candidates, but scrutiny should be applied to processes that required extensive typing or scrolling as users will become easily frustrated. 

A failure to keep it simple when it comes to mobile will also likely equate to poor or incomplete data.  Typing on a small keyboard can be time consuming.  Moreover, navigating multiple screens can make a simple task daunting.  The resulting behavior for end-users is to cut corners, enter the minimum amount of data required, or neglect to enter anything at all.

What device suits your needs?
Mobile devices are not all created equal and there is no one answer to which is the best.  The strategy established must be consistent with the goals of the organization and the tools must be right for the job.  A thorough analysis of the right device should include alignment with the mobile use cases, feature functionality of the device, device-specific feature support offered by your CRM software, customization capabilities, and the service network.

How will security be maintained?
Finally, the need to secure your data and protect the intellectual property of the organization must be considered.  Users may demand access to ALL data through their mobile device, but the strategy must consider the risk of a lost or stolen device.  For ease of use, most systems do not require that users enter a password each time they are accessing their CRM application on the mobile device.  For this reason, it is important that data is evaluated by sensitivity so judgments can be made about what will and what will not be accessible.  Furthermore, a password policy on the device itself should be mandatory if there is risk of a breach.

This is not an exhaustive list of mobile strategy components, but does represent some key points of consideration.  The cost of implementing a mobile solution is not insignificant, so these basic questions will help to proactively plan rather than having to backtrack and repeat.