Skip to main content

5 Pitfalls in Choosing Cloud Business Software Such as CRM


Choosing a business software package such as Microsoft Dynamics, Salesforce, SAP or Oracle is a daunting task, and the process can lead you astray in making the best decision for your organization.

There is no shortcut to finding the right product.  Choosing the best selling or fastest growing software product does not guarantee you will be successful in your company with that product.

Software categories are complex, and many products are geared toward specific industries or to companies of a certain size.  If a small company tried to implement a product such as SAP enterprise resource planning which is successful with large global companies, it could easily find itself overwhelmed and the implementation price could exceed annual company revenue.  On the other hand, a large company with global subsidiaries, complex tax rules, and high number of users and transactions would not likely be successful with QuickBooks.

One of the approaches to choosing software is to create a list of desired features and send solicitations to vendors in order to find the ones that best fit the business need.

My company InfoStrat participates in many product evaluations, and these are the top pitfalls that I have witnessed:

  1. Vendor feature lists are rigged to make that vendor look good. They are created by marketing staff, and no vendor will include features that they lack on a feature checklist.  As a bidder, if I see a solicitation that contains a feature list taken directly from vendor literature, I know that a product has already been selected.
  2. Asking vendors to rate themselves on features results in optimistic ratings.  Vendors know what customers want to see, and it is tempting to answer Yes to everything unless it is clearly not supported.  The more vague the requirement or feature, the easier it is to justify answering Yes. You could mitigate this problem by asking third parties such as resellers to answer as well.  This will not likely result in consistent results, but could point you to features that need further elaboration or examination. 
  3. Features are an arbitrary black hole.  Defining what is a feature is arbitrary, and you can come up with a large number of features for any product.  More features do not necessarily make products better.  I prefer to carry a Swiss army knife with only 5 features because it is lighter and more comfortable in my pocket than the largest model. Software can become bloated as well, to the detriment of usability. Some features are redundant or overlapping, and can lead you astray when you favor the sheer number of supported features.  For instance, for an automobile you could ask whether it contains cup holders (1 feature) or break this into driver cup holder, passenger cup holder, left rear seat, right rear, middle seat and third row cup holders.  Next thing you know, you end up driving a minivan.
  4. Counting features without weighting them distorts the evaluation.  This is closely related to the previous point but surprisingly common.  If you count positive and negative answers to a features list without applying weights to the more important criteria, you are weighting them equally.  This can lead to poor decisions.  Consider the hundreds of criteria you could apply to purchasing a vehicle and ask yourself whether you should equally weight criteria such as safety, affordability and capacity with side mirror defrosting or the interior mood lighting. 
  5. Favoring objective over subjective criteria.  It is tempting to reduce a decision to what seem to be objective criteria, removing subjective criteria or reducing their importance.  The problem is that for business software user adoption is key, and adoption is heavily influenced by criteria that resist being reduced to feature check boxes.   We see evaluation matrices with criteria such as "intuitive" or "seamlessly integrated".  These may be good aspirations, but they are impossible to evaluate objectively.  
If a feature list is arbitrary, rigged, and easily distorted, what is a better way to choose enterprise software? Our most successful customers have used requirements and features to narrow their choices, and then conducted a proof of concept or pilot to allow their users to get hands on experience with the products.  This approach allows you to factor in subjective criteria and determine the fit of software with your organization, from both a technical and a business perspective. 

Cloud software is much easier to experience in a pilot than on premises software because it doesn't require you to configure servers or your network to start using it. Many vendors offer free trials for 30, 60 or 90 days and they will usually extend a trial if you need more time to make a decision. 





Popular posts from this blog

Key Concepts for Microsoft Dynamics 365: Tenant, Instance, App and Solution

To understand Microsoft Dynamics 365 (formerly Dynamics CRM), you need to learn some new terms and concepts that may be a bit different from what you know from databases and solutions that are hosted on premises. This post introduces some of the key terms and how these concepts are important for planning your implementation. While Dynamics 365 is available on premises, it is most commonly deployed on the Microsoft cloud.  This blog post discusses only cloud implementations. Microsoft has multiple clouds such as commercial and government community clouds. We start with a Microsoft tenant .  A tenant is the account you create in the Microsoft Online Services environment (such as Office 365) when you sign up for a subscription. A tenant contains uniquely identified domains, users, security groups, and subscriptions.  Your tenant has a domain name of .onmicrosoft.com such as acme.onmicrosoft.com.  User accounts belong to a tenant, and subscriptions are assigned to user accoun

Understanding Dynamics 365 and Office 365 Admin Roles

Managing Dynamics 365 instances If you run Microsoft Dynamics 365 (formerly Dynamics CRM) in the Microsoft cloud, you need to understand how your Dynamics instances relate to Office 365 and choose which of your administrators receives which roles and permissions to manage Dynamics 365. In on premises deployments, your network administrator would create and delete user accounts.  The Dynamics 365 admin would then assign permissions to users in Dynamics 365. This post explains three administrator roles: Office 365 Global Administrator Dynamics 365 System Administrator Dynamics 365 Service Administrator You may think that the Dynamics 365 system administrator would have power to do all the actions needed to manage Dynamics 365, but this is not the case. What's different in Microsoft cloud deployments is that licenses and user accounts are managed in Office 365 by an Office 365 Global Administrator.  This role is analogous to a network administrator for an on premises

Replacing Microsoft InfoPath with Power Apps

Source:  https://powerapps.microsoft.com/en-us/infopath/ Microsoft has offered a number of forms automation products over the years, and the most long running was InfoPath which was released as part of Office 2003.  InfoPath is a powerful and flexible product that stores user data in XML while offering form features such as rules, data validation, scripting, and integration with SharePoint.  The popularity of SharePoint resulted in many organizations standardizing on InfoPath for forms, especially internal forms which are hosted on an intranet such as employee reviews, leave and payment requests, and human resources forms. Microsoft has discontinued InfoPath, with mainstream support ending July 13th, 2021, and extended support ending July 14th, 2026. Microsoft has named Power Apps as the successor to InfoPath .  Power Apps has much in common with InfoPath.  Both products include integration with SharePoint.  Both are geared toward the citizen developer and do not require advan