May 13, 2019
What a wonderful invention spreadsheets were. For many things, I don't know how we even managed before them. Okay, I do know, because I am that old... we managed things poorly. Spreadsheets solved so many challenges, that they eventually created new ones.
The first spreadsheet software I actually used was called 1-2-3 from Lotus, back around 1985. I created all sorts of spreadsheets, Shortly after, I switched up to Lotus Symphony, which was basically spreadsheet software with a programming language. With Symphony, I built a complex job-costing system for my business at the time. It was really my first experience as a "Citizen Developer". Needless to say, Microsoft eventually launched Excel, and crushed all of the other spreadsheet applications out of existence. For good reason... it was better.
Microsoft launched another product in 1992 called "Access". It was a relational database product, and also was not the first. Some users of Excel started looking to Access as a way to build business applications. Access was "accessible", and many "normal" users built things on it. While the term "Citizen Developer" may seem recent, the concept has actually been around for a very long time. Although the tools may have changed quite a bit since then, the fundamental concepts are still pretty much the same today with the Power Platform's underlying Common Data Service (CDS)... a relational database.
Before I put you completely to sleep, let's jump ahead about 3 decades, to today. While the popularity of Access has waned, Excel is still very much alive. If I had to guess the percentage of businesses that use Excel.. I would put it at... 100%. It is simple-to-use, requiring almost no training at all for creating basics lists of information, and basic calculations of those items. Excel's use in organizations is ubiquitous and prolific. It is the "go-to" tool for many users, for almost anything. In fact, in enterprise organizations, I would not be surprised if the number of active spreadsheets in use is in the tens of thousands. Even small businesses often have hundreds of spreadsheets. Spreadsheets have become... an infestation.
It sneaks ups slowly. A business or department is formed, and there is an immediate need to capture some data. Who cares what it is, there is some shit we need to keep track of now, and the reflex is to whip up a quick spreadsheet to throw it on so it won't get lost. Makes total sense. Maybe we got a contact page on our website throwing off 5 leads a day, probably going to someone's email box. Let's put them on a spreadsheet and save it as "web site leads", and then we'll just add to it as they come in. Forget about web leads, it could be anything, but this is an easy example.
So having these leads on a spreadsheet is good... we won't lose them, but we need to act on them. Next step, send a copy to our two salespeople. Today, you could actually just share it with the two salespeople, but copies are still most often the default. So now have someone updating the spreadsheet daily with new leads, and sending it to both salespeople. The salespeople are getting a daily new copy of this spreadsheet, but they have been taking actions on the last one(s). So they create a spreadsheet of their own to track their activities, and just add to it when they get the daily update. The Sales Manager wants to keep track of what is going on, so she asks the two salespeople to send her their updates daily. She then creates a spreadsheet to consolidate the two she receives. So how many spreadsheets do he have now? To be fair, a lot of this could be simplified using a shared spreadsheet, but still a spreadsheet is being used as a database.
Excel was not designed to be a database, but rather a data analysis tool. The number of capabilities in Excel are staggering, yet 95% of users only use 5% of the capability. But Excel actually looks like a database table... columns for attributes and rows for records... sounds pretty similar. But used as a database, Excel gets unwieldy quickly. Imagine the scenario I described above growing over time to 50 leads a day coming in, and 20 salespeople. In enterprise businesses, I have seen similar scenarios with thousands of people trying to coordinate a business process with Excel. Excel was never intended to do that.
I often see spreadsheets that do not use any of the calculating functions. A tab is created for each thing, like a tab for each Customer for example. On each tab are areas for the customer name, description, etc. Maybe even a running list of Phone Calls or other activities. Basically using a Spreadsheet as a quasi-CRM. I can't say this is stupid; CRM systems have become quite complex and expensive, where spreadsheets are more or less free!
When are you torturing Excel too much? I don't need to tell you, if you have read this far your Excel-based system is already breaking down. Sally, looking at the wrong spreadsheet, calls a customer to introduce herself, only to find out that Bob called them yesterday. Bill added a note that someone needs to send Acme a price list, and nobody ever did. Joe adds a new Lead to his own copy, without realizing that Mary was already working on it. The fracture points are various and numerous. When did it start? Actually, when the second person was added to the process, the seeds were planted for it's eventual implosion. But CRM is so expensive!
It's funny some of the rationalizations customers come up with to avoid a cost. I often hear stories of massive inefficiencies costing customers thousands of dollars, followed by, "Is there a way 5 users could share a license"... to save $160! I get it... you are moving from a shit system, but it's free. But is it free? Have you taken into account anything other than a free system vs a system with a cost? SMBs really struggle with this one, focusing 100% on the possible additional cost. Easily able to ignore the costs they are currently incurring like wasted time and lost opportunities, and in a worst-case lost customers.
Microsoft gave you the tool to create this mess, and thankfully, they also created the tools to get you out of it. You need a "Business Application" to replace your spreadsheet(s), we both know that. If you are using Excel, you probably already have other Microsoft products, like Outlook etc, or maybe even Office 365, so it makes sense to look to the same company for a solution to your Excelplosion. The main thing is, that you don't want to find yourself down the road with the same problem. Microsoft has a couple of ways to avoid that happening, Dynamics 365 or PowerApps. Let's unpack them briefly.
This is Microsoft's world-class, enterprise-grade Business Application family. If you are an enterprise, it may already be in use elsewhere in your organization. It competes head-to-head with Salesforce.com, and is a very powerful platform for solving the most complex business processes. If you have sophisticated applications in place already and are looking to move to the next level, this is something to consider. But, moving from an Excel-based system, you could not possibly have been solving enterprise-grade problems, so it could feel like a pretty big hammer. It is a big hammer, and if you are reading this post, you should ignore it completely. Trying to go from 50 Miles per hour, straight to 500 Miles per hour, will snap everyone's neck, and you will be in an even worse place.
Now we're talking. This is exactly where you need to be going next. It is the most logical step forward from an Excel-based system. It is also significantly less expensive than Dynamics 365, and it's "Citizen Developer" friendly. My choice for moving customers off of spreadsheets is what are called "Model-Driven PowerApps", they are like Dynamics 365's little brother. They sit on the same relational database (Common Data Service) as the monster applications, but without all of the tentacles of complexity. If your needs eventually become really huge, you can easily activate the monster without having to move anything.
If you ever worked with Microsoft Access before, PowerApps is kind of like the new version of that, but at the same time, nothing like that. The similarities are that a person with some basic technical skills can build a usable application on top of a relational database. While Access was not specifically designed for non-developers, PowerApps has enabling "Citizen Developers" as a core goal. If you don't have a comfort with basic "techy" stuff, or you don't have the time to mess with it, a partner that specializes in PowerApps can help you get there. Shameless plug: my company, Forceworks is a PowerApps partner, but the army of PowerApps partners is growing fast.
As part of our mission to move Excel-based systems to PowerApps, we created an accelerator to help customers get there faster and save some money. We call it RapidStartCRM, and you can learn more about it at https://rapidstartcrm.com.
So I think that about covers it, or at least starts the conversation. It's time to stop torturing Excel, and torturing your team... you have officially run out of excuses.