The Accelerate HR Blog
Support for spreadsheets (Tue Nov 13 2007)
When clients start using our HR databases, we generally find that they've been keeping their old records on spreadsheets. Most of them are horrible. Data is unmatched, unmanaged and unvalidated - and strewn with inconsistency and human error. Just recently, for example, I found myself trying to migrate data from an Excel spreadsheet where users had sometimes entered dates as Month-Day-Year, sometimes as Day-Month-Year, and never in a format which was actually recognized as a date by Excel. Our clients know about these kinds of problems of course - that's why they move to a database.
And I guess it's because of this that we professionals tend to be sniffy about spreadsheets. At a Rails conference a couple of years back, for example, Nathaniel Talbott spoke about how his wife's small co-op group had struggled with order management using an Excel spreadsheet. Nathaniel foresaw a future in which frameworks like Rails would reduce the time and cost of professional software development so greatly that everyone would be able to commission, if not write, their own professional software. Excel isn't for the professionals then.
Not for database management, it's true. But let's take a look at why so many business professionals - finance controllers, HR managers, sales and marketing specialists - still use spreadsheets as their tool of choice.
It's all about ownership and flexibility. One of my most loyal clients, T, has been using our desktop HR database for several years - for employee records and payroll primarily. But although his team do all the work - and do it well - T still runs his old Excel version of the payoll. Why? Because he's developed his own set of management reports, which both he and his boss are comfortable with. Could we have given him the same reports? Absolutely. But he doesn't want to put himself into an outsider's hands, no matter how close we are. If he needs to develop a new report he knows he can do it himself (and even if he sometimes calls me in for help, he can pass it off as his own!)
We joke about it. I tell T he's like someone who's come to the beach but won't get into the water. I warn him of the dire consequences of errors - but both he and I know he never makes them. And deep down, wearing my HR instead of my IT hat, I think he's right. In HR, we talk a lot about empowerment - giving the employee the freedom, the tools and the authority to find and create personal solutions to improve the job and the business. And wasn't that what we were all excited about when the PC was first introduced into business? Wasn't it going to allow us to escape from the straitjacket of the mainframe? Unfortunately, in too many companies, that's not the way it's turned out: the IT specialists are busy disenfranchising users - partly for the very good reason that corporate security must be defended ... and partly just because they can.
So let's fight that. Let's keep spreadsheets. But not for data entry and management and manipulation. That's where we need the power and strength and security and speed of the database. For reporting and analysis though, that's where the spreadsheet comes into its own. That's why T wants his Excel spreadsheets. And if we make it easy to export from the database in a human-friendly format, that's exactly what he'll be able to keep. And that's exactly the approach we're going to take in ACCELERATE HR.
While preparing this post I scoured the Web for anything similar and came across a nice post from Chad Fowler. Seems he thinks much the same and he points in the direction of Dabble, which looks a great spreadsheet product, allowing for the easy creation of charts and reports I want. I'll certainly be checking Dabble out to see whether integration with ACCELERATE looks easy.
And just to look forward to my next post. There's another reason why non-IT specialists like using spreadsheets. They make it really easy to enter data - especially if you've got lots of it. (Not necessarily accurate, but easy!) Imagine, for example that you're entering all the data for this month's overtime. You've got 500 people in your construction business, and most of them have worked overtime most days this month. Now large-scale data-entry is an area that Web-based databases haven't coped with too well in the past. You know how it goes on the Web: enter your data, post to the server, refresh the page, enter the next data ... For thousands of records? Gulp! I'll tell you how we've tackled - and I think overcome - the problem using Rails RJS templates next time.
