Spreadsheets are BAD....

  • (1) True

    (2) False, you can share the workbook and have multiple users view the data without any problem.

    (3) False, data validation can be implemented

    (4) False, Excel 2007 has 1 million rows

  • (2) View the data? What if you want to modify it?

    (3) That's interesting - I've never used it. Does it include foreign key constraints?

    (4) So the numbers are different, but the point is still valid. Databases don't have a limit at all (at least SQL Server doesn't).

    John

  • Validation and calculations looking from one XLS to the other can cause problems as you scale it. It works, but it isn't designed for lots of users.

    Excel can do a lot, and it's a fantastic tool, but it shouldn't replace a database. It should be used to enhance it.

  • (2) Excel can be set up to allow multiple users to edit the data in a workbook, those changes can be tracked, and ultimately accepted or rejected by one person, so change management can be implemented

    (3) Similar yes, as slick as FKS no. You can set up your validation such that your options change by whichever validated fields you select first.

    (4) If you are worried that a million rows might not be enough suggests that a spreadsheet is not the right tool. Especially if people are creating the data to be held within it. That's an awful lot of people to create an maintain a million rows of useful new data.

  • Well that went pretty well, all told, thanks guys...

    But the one gobsmacking revelation was that top management time farting around in spreadsheets counts as managing the business. At no point did it seem to be understood that saving a highly paid exec 1 hour equates to an ROI. So the problem was never so much "spreadsheets are a bad idea" as "why do we need to save time on that?".

    Funny, that. They've managed to apply the same argument to buying robots for the shop floor successfully.

  • Can you share any more details about how the argument went? I think it could help some others get XLS use reduced for some things.

  • There are two sides to the argument. Management needs to manage themselves with the objective of finding solutions. First, fooling around with well understood existing solutions on a spreadsheet is the equivalent of screen sucking and they do need a RDBMS to do this for them just as they need robots on the assembly line. When their creative spark starts to create a low ROI for their time they should either drop the project or put worthy ones into the RDBMS.

    Second, if they are doing creative or experimental analysis by spreadsheet, this is legitimate. Finding and understanding data is what management is supposed to do. As management I would want to ask what are the prospective about costs and returns on any management project to ensure projects were worthy of time spent and ask how much time was going into each current project to ensure avoiding high hanging fruit in favor of low hanging fruit. Low hanging fruit: They only need to hand you a couple complete product analysis spreadsheets for this to be put into a RDBMS.

    Aggressive RDBMS people may want to ask if management is looking at new and disruptive data analysis. You might be able to find a nice publication of a problem and solution including possible solutions and possible traps to what management is trying to accomplish.

    >But the one gobsmacking revelation was that top management time farting around in spreadsheets >counts as managing the business. At no point did it seem to be understood that saving a highly paid >exec 1 hour equates to an ROI. So the problem was never so much "spreadsheets are a bad idea" as >"why do we need to save time on that?".

  • Very true Dave, and this was the crux of my argument.

    The problem is quite complex, as it has to account for differing levels of technical maturity around our global concerns, and until I had managed to demonstrate that I'd accounted for that most of my arguments were dismissed in terms of a global solution, afterwards greeted with cautious approval with reservations.

    However, it wasn't the fact of replacing spreadsheets that was ever a compelling argument, rather it was the fact that by defining (effectively) a data dictionary you are offering leadership in terms of demonstrating to affiliates what is important in terms of tactical management. On top of this the arguments for centralised information control went down well.

    Actually this was a more compelling argument overall (as far as the main man was concerned) than the time saving argument, but I suspect that this was more to do with my failure to demonstrate just how much time would be saved as a lack of imagination on his part. This was largely down to time, I didn't feel confident reeling out figures until I had a product to back it up (and I've only got half of one at present).

    I think I've done enough to justify a small spend getting the data dictionary together (I think I'm going to get someone smarter than me to put it into OLAP cubes) and a few reports together, then I think it is time to demonstrate the time savings and go for a more aggressive tactic of nailing the ROI down.

Viewing 8 posts - 31 through 37 (of 37 total)

You must be logged in to reply to this topic. Login to reply