How To Replace Excel For Collecting Master Data For Your SAAS

by

In Why Overcoming The Tyranny Of Excel Is A Lousy Positioning Theme, we’d cautioned software companies from pitching their software as a replacement for Excel.

Since then, we’re happy to see more innovative positioning around Excel by technology providers.

For example, BI vendor Domo pitches its suite of data visualization products as complementary to – not substitute for – Excel.

Kudos to Domo, even if we say so ourselves!

In this blog post, we’ll cover another disturbing trend in SAAS: Use of Excel to collect master data.

In the mid 1990s, it was a common practice for ERP vendors used to circulate “Master Data Collection Sheets” in Excel for collecting bulk data like customer master, item master, vendor master, and so on.

Despite the availability of more advanced technology 20 years later, we’re dismayed to find that many SAAS providers still use Excel sheets for this purpose.

There are at least two reasons why collecting master data via Excel is a bad idea:

#1. COGNITIVE DISSONANCE

dilbert-cognitive-dissonancePut yourselves in the customer’s shoes.

You’ve just bought a software after listening to a vendor tell you how it’s better than Excel (among other things).

You’re eagerly looking forward to use it.

Then the vendor tells you to use Excel.

If you’re like most customers, you’d feel badly let down and go through what’s called “cognitive dissonance” in Consumer Behavior.

In the days of onprem software, enterprises were committed to the success of the implementation because they had paid the license fee for the software upfront, so software companies could afford to be blasé about cognitive dissonance.

However, in the SAAS world, every customer that suffers from cognitive dissonance is a customer that might cancel their subscription by the end of the month. Ergo, SAAS vendors must take cognitive dissonance seriously, or risk seeing their churn rate go through the roof.

#2. ONBOARDING FAILURE

Excel is error-prone.

In almost every onboarding we’ve seen, Excel uploads have led to poor data quality, incorrect classification of hierarchical entities and additional efforts for reconciling Excel-inputted data with “true” data.

In some cases, errors in Excel have caused catastrophes, as highlighted by GTNews in “The Perils of Excel”:

Elementary spreadsheet errors have in this case potentially impacted the economic well-being of perhaps billions of people, who have been exposed to austerity policies based upon false data.

Therefore, use of Excel to collect master data causes serious onboarding risk and stymies revenues of a SAAS company.

It should be obvious by now why SAAS providers must eschew the use of Excel for collecting master data.

But actually doing so is easier said than done, given the widespread usage of the practice.

This poses a conundrum.

Before we propose a solution for this headscratcher, let’s understand why Excel is so popular in the first place.

From personal experience and discussions with several companies, Excel is used widely for collecting master data for the following reasons:

  1. In Excel, you can enter data at high speed from the keyboard. In software frontend, you need to look at the screen and use the mouse. This slows you down.
  2. After entering a row in Excel, it’s easy to hit the Enter key to go to the next row immediately. On a software frontend, you need to hit the Submit button at the end of a screen and wait for the screen to be refreshed and the next blank screen to come up.
  3. Excel accepts anything. Software throws out errors when its validation logic spots a discrepancy between the data entered and the field definition. For some fields, software allows you to only select entries from a drop-down box. If you can’t find your data on the list, you’re stuck.

In short, Excel is faster for bulk data entry and does not ground you with fatal errors.

Any alternative to Excel for master data collection must address these fundamental issues.

mde01The key to doing so is to grasp that screens in software are designed for entering small amounts of transaction data over a long period of time rather than for entering huge amounts of master data over a short duration.

Using the same screen during onboarding causes most of the problems that have established Excel’s predominant position in the process of collecting master data.

To address this, we recommend developing separate functionality in the software for gathering master data. “Onboarding UI”, as we’ll call this module, will comprise the following building blocks:

  1. Separate set of screens for collecting data in bulk.
  2. Each screen should allow entry of data without validation, which should be run on a batch of data instead of when each screen is saved, as most software products do today. In other words, validation should happen “offline” instead of “online” as in the current design.
  3. The same error queues and messages used for validating Excel-inputted data should be reused for validating data entered via frontend screens. This will ensure that master data can be inputted using the software as easily and with equal – if not better – quality as via Excel.

We admit that Onboarding UI will add to development efforts.

But we’re also sure that it will eliminate cognitive dissonance and minimize onboarding failures.

Going by the experience of a customer that has followed through with our guidance, the incremental costs for developing a separate onboarding UI for collecting master data will pay back many times over by reducing churn and enhancing usage over the lifetime of the SAAS software.