At work, I constantly see people use Excel for things other than spreadsheets. In fact, it’s main use at my job is as a database program; there’s lists of students, lists of grades, group lists, staff addresses, and even tables of standard e-mail responses. One annual task of the committee I chair is that we formally appoint staff members as examiners (giving them the legal right to issue grades to students), and—I kid you not—the standard format for that is a Word .docx file. A list in Word of over 150 colleagues, listing a limited and standardized set of data.
This habit, in my opinion, is a typical example of the saying “to a person with a hammer, every problem looks like a nail.” In this case, people know Excel, and have used it before, so that’s what they use to keep these lists. Now, in the previous academies I’ve worked for, this approach was serviceable. Don’t get me wrong: you can absolutely make Excel do this for you. You can adjust formats, and with a little coding or clever use of Excel validation and HLOOKUP/VLOOKUP functions you can get quite a bit done. However, I see many of my colleagues who have limited knowledge of Excel (and why should they? Often, they don’t need anything beyond a table), so without using this workarounds to have Excel function as a database, I frequently see lots of copy-pasting, manual re-entry of data, or manual formatting to reach the desired result. I can’t tell you how often I’ve seen people copy pasting Excel data from one workbook to another, so that they can manually reformat the data to fit something that they wanted to print.
I myself have worked like this as well. When I just started working as an English lecturer during my MA degree, I saw that my fellow lecturers were all sending grades in a different way to the coordinator. One was making an Excel list using
period a comma for the decimal marker (the correct way in Dutch number formatting), while others used commas periods. Yet another just mailed a little list to the coordinator, based on the grades they’d scribbled down on a piece of paper. You can imagine how many mistakes would be made transcribing one to the other, not to mention the work the coordinator had manually reformatting this. So, I made a simple spreadsheet that everybody could access, which had some basic data validation to ensure everybody filled in their grades in the same way. It also solved another issue, because it required everybody to fill in the points students scored, so we weren’t having the usual issue where people rounded grades differently, or changed the way they applied guess corrections for multiple choice, and so on.
Swiftly, this spreadsheet started being used for more things. Random colors started appearing as people marked status changes for students, and comments would start appearing after columns. Also, the spreadsheat kept breaking—colleagues would want to manually adjust this or that, because “it wasn’t calculating the average correctly”, or they would insert columns or new students (despite the groups being generated from those students registered correctly). In short, I learned through experience what people trained in software development already know: your design works until its first encounter with a user. So, I learned about locking cells and password protecting sheets. The last important lesson I learned from that sheet, was that I couldn’t assume people were willing to learn. I’d set it up with the intention that this was a relatively simple sheet, that with around thirty minutes of looking it through could be used and maintained by anybody; after all, it was just a little Excel sheet—not so difficult, right? That’s when I learned that making the sheet had made me into the admin of it, year after year. My colleagues weren’t particularly interested in learning how to better use the programs they were using, because they could already get the output they needed from it. Plus, the urgent matters of the day were so distracting, that they didn’t feel like they could spend the time to learn a new skill, despite that new skill potentially saving them hours and hours down the line.
Now, in some of my old positions, using Excel in ways it was not designed to be used didn’t cause that many issues (nor does it do to this day). A person typing up a quick list in Excel still reaches their end goal. An administrative support worker copy-pasting things from one list to another to edit something doesn’t spend too much time if the whole program has only around 500 students. My new academy, however, has over 3000 students, and when I review the Excel files that people use as databases, it’s just slow. Scrolling down it takes time, and with that number of students, it’s also not handy trying to filter out certain things.
So, fortunately, being the Chair of my committee (and a stubborn one at that), I’m moving us over to an actual database for registration. Much like Excel, when I was a starting lecturer, I don’t actually know how to use Access right now. To me, that’s a good thing—I just love learning, and this is a good opportunity to learn a new thing that will have a practical and positive effect on work. I’m also excited to implement this change, and to help my colleagues save time. I’m convinced this will make processes move more quickly, and I can’t wait to measure the improvement.
2 thoughts on “Excel is not a database”
My previous job made a distinction between “systems of engagement” (the applications people use to share information) and “systems of record” (the applications where information is stored and kept). Excel can never be a ‘system of record’, since it’s designed as a ‘system of engagement’.
Also, the comma very much is the Dutch decimal separator!
Whoops! I edited that section so often I ended up switching those around! Yes, I absolutely meant that the comma is the decimal separator, of course.
And yeah, I can see the use as a “system of engagement”. I see a similar trend at my work where they try to abstract away the term “database” from systems that are clearly databases (the word, apparently, scares people off), and then provide options to export data to Excel formats.
To me, that seems like a decent middle ground: the data gets stored safely, and can be out into a format that a lot of colleagues are comfortable with.