August 14, 2009 at 11:39 am
I've not read all the replies, but "Spreadsheets are bad..." is probably not going to clinch it. Perhaps, something along the lines:
Spreadsheets are good for some things (list), but not as efficient for (list).
Spreadsheets are very inexpensive for (list), but very expensive for business use (list).
So for some kinds of uses we currently employ spreadsheets (list), databases are the real solution (reasons). Then walk through a 60-second application creation, real time, live on a database.
(list) and (reasons) should come from your internal examples.
Punch line: spreadsheets have their place, but databases can help us the most at this time.
Then hope for the best as Excel Services and other arguments are thrown around.
August 15, 2009 at 8:50 am
It's Cliche but what Management and the business needs is a single version of the truth and you cannot get there if mulitple people are doing things in a different manner.
Another argument is accessibility. it is highly probable, someone will create a report in a spreadsheet that is due on a particular day. They are sick the day it is needed and no one knows where it is except the employee. A centralized reporting system (IE Reporting Services or something like it) will ensure the data is accessible by those who need to know, when they need to know it.
August 15, 2009 at 9:51 pm
While you're making lists of arguments for DB's and against Excel, seeing as you have an incumbent technology (MIS Alea) I would also quickly review their website and note their selling points and how/where/why these aren't working for your company. Interestingly, the first few things that you listed as problems internally, are the very same items listed as the key points of that product :-S If the original product purchase sponsor is still in-house, you may want to determine their involvement in your upcoming meeting/s, and also whether they're likely to push for getting the MIS ALea guys back in to 'fix' your problems, or whether they're open to looking at alternatives.
Steve.
August 15, 2009 at 11:52 pm
Here is a quick estimate of the problem. Spreadsheets seem efficient and they are for each individual solution. The problem is that large numbers of spreadsheets quickly become unmanageable because of their variations and future changes. Imagine figuring out if a thousand spreadsheets are all the same in concept and execution. Next imagine making a consistent change to each of the thousand spreadsheets due to policy or data changes. Large numbers of spreadsheets are not scalable. This should make the efficiency of a RDBMS more obvious.
In addition spreadsheets have weak data dictionary controls which allows more trash data input and they hide and make data difficult to control as well. This reduces the quality of the data and makes it less available. If your profit is a few percent then a couple percent of trash data can make inventory and profit reporting a headache. A strong data dictionary can reduce the amount of errant data entry by a factor of 50.
I would allow that users who know the product could prototype their data in a spreadsheet form for a quick product data definition. The prototype spreadsheet would be handed to DBMS staff for conversion to a database form. I would not allow large amounts of data to be kept in prototypes unless it was a very valuable exception.
Dave
August 17, 2009 at 8:04 am
I have a prime example with one requirement where a spreadsheet is required for each of our products, but each product has subproducts, and they're expecting to see upwards of 300 spreadsheets (one for each subproduct in effect). The bulk of information is inherited from the main product, so a simple relationship with two tables would reduce the workload by 50%.
This sounds like they may be 'linking' things together.
A few things that immediately come to mind:
Time to maintain the links and add 'new' products / subproducts. This can sometimes be much more than the 'it only takes a minute' that is implied. Along with this, these things usually grow, and variation occurs. So something that actually starts out simple, can become much larger, even more spread out, so the real cost is usually not known.
But in my mind, bad links can be the biggest risk to the business. I was once asked to help 'fix' a linked set of workbooks several power users had created and built over time. I couldn't tell how long some of the links were broken, but one portion had been broken for 5 or 6 months. The end result was the their initial problem was only the tip of the iceberg. It is very easy for a link to pull in the wrong numbers, and there is no warning.
When some of the creators leave, there can easily be gaps in what is passed on. The documentation on these systems is many times minimal, if anything.
As mentioned by others, Excel can be a valuable presentation layer that the users are familiar with. But just because you can 'do it in Excel' doesn't mean it is the best solution. Simple edits, changing numbers of data rows, security, etc. all need to be considered. Some of these can be easily done across the board in a database, where several hundred spreadsheets will be much harder to manage.
Greg E
August 17, 2009 at 8:35 am
All excellent arguments in the "Excel versus RDBMS" conundrum. And yes, we too have Excel spreadsheets being used to drive business decisions (our accounting department uses them quite a bit - shudder).
The other thing to lookat is WHY the Excel is working better for the managers than some other solution. Is it difficult for them to access the information in other ways, or keep it up to date? Timeliness, accessibility, and ease of use are the reasons we hear most often when we ask why someone used Excel instead of the RDBMS. Or they simply don't know the data already exists!
If those issues are not addressed, I fear you are fighting a losing battle.
Steph Brown
August 17, 2009 at 9:10 am
The argument that has worked at my company is that spreadsheet use means we store the same information in many places, which means we do not use standard names and we duplicate effort. We fail to update changes everywhere so we end up with many different versions of the same information. By doing more work than we need to, we deliver a lower quality product to our customers.
August 17, 2009 at 2:49 pm
The easy argument will be that Excel is simpler so why are you making things more difficult.
Your argument is that 300 spreadsheets will have hidden problems that were already solved years ago in RDBMS history. The RDBMS is already built to be the easiest solution for additions, changes, accurate data, and data dictionary management. Explain how this eliminates data duplication which is a problem that multiplies the work of data maintenance staff. Mention that Referential Integrity rules are an example of controlling deletions logically if they would understand that.
Also check out the idea that maybe they see getting an RDBMS as expensive or difficult to program. It may be that they prefer managing their own design process because the database people have been scarce or not been treating them well.
lemsip (8/17/2009)
The argument that has worked at my company is that spreadsheet use means we store the same information in many places, which means we do not use standard names and we duplicate effort. We fail to update changes everywhere so we end up with many different versions of the same information. By doing more work than we need to, we deliver a lower quality product to our customers.
August 18, 2009 at 7:41 am
No one has mentioned how they intend to control the data going into the true Database. If the people putting the data in don't truly understand it, I fail to see how Database is anymore accurate/useful than a spreadsheet run by a poweruser. The Who might be just as important as How.
August 19, 2009 at 1:35 am
The data dictionary would be designed to prevent many errors. The DBMS designer could limit input to certain individuals too. Spreadsheets typically don't have such complex controls for managing data entry and data errors.
soggie_old_soul (8/18/2009)
No one has mentioned how they intend to control the data going into the true Database. If the people putting the data in don't truly understand it, I fail to see how Database is anymore accurate/useful than a spreadsheet run by a poweruser. The Who might be just as important as How.
August 19, 2009 at 2:30 am
Well one of the main arguments I am putting forward is that a reporting database would allow us to cross reference the data we are using for costing with our chart of accounts, so essentially feedback on data accuracy is instantaneous. Actually the inputs would be automated based on an exsiting reporting structure. This is kind of the whole point, not so much about accuracy as transparency.
August 19, 2009 at 12:05 pm
My condolences. Excel can be a great tool for analysis, but not for storage.
I had the "it's not a database" discussion with my Mom, with unfortunate results.
August 19, 2009 at 12:10 pm
EdVassie (8/14/2009)
When Excel is used to prettify information held centrally, it is a very useful tool. When Excel is used to present information stored only within that spreadsheet, it can be an agent of corporate destruction.
This here nugget is an excellent quote. 🙂 Sums it up perfectly for me.
Thanks, Ed!
August 20, 2009 at 1:19 am
Spreadsheets are GOOD, if used correctly (as pointed out above). by the sounds of the compamy is using Excel to capture and retain data rather than report on it. Thats what's BAD.
Ask your boss how long it would take him to get a summary of (and then come up with a rather complex business question) and then ask once you have that summary how long would it take to get a break down of that. Then tell him it would take considerably less time with a properly designed database and OLAP cube, mention how robust it could be, not to mention scalable and how many fewer people would be involved in the process and that those people could be doing much more important work. Go on to mention that everyone who would have access to the data would see the same result (you know the rest).
August 24, 2009 at 3:00 am
(1) Security. You can only have one password per spreadsheet, instead of one per user. And Excel passwords are very easy to crack.
(2) Concurrency. It's much easier in an RDBMS for multiple users to consume the same data at the same time without causing any damage.
(3) Data integrity. In a spreadsheet, you can't stop someone entering data for a customer that doesn't exist, or typing a character value in a number column.
(4) Scalability. An Excel spreadsheet can only have 65000 rows, whereas there is no limit on the size of a database table.
John
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply