When people manage data, there are three fundamentally different ways they can add value:
- Computing
- Storage and Retrieval
- Forwarding and Sharing.
For computing at the level of simple arithmetic, you can't beat Excel. Even if you are an experienced programmer, you can build a spreadsheet in a fraction of the time you'll take to write and debug a computer program. You can even group data into tables and use lookup functions to gain some of the advantages you get with queries. The pivot table and the graphing features make summarizing data simple and easy.
For storage and retrieval at the file/document level Excel is about as useful as MS Word or MS Access. For retrieval at the level of SQL queries, MS Access works a lot better than Excel, although Access is severely limited as you will know if you've ever compared Access with an industrial strength DBMS.
For data sharing, Excel is extremely primitive. Most shops that adopt Excel by contagion run into trouble at this point. Your question suggests that this is the case at your shop.
There are several problems in introducing databases in a place that is not ready for databases. One is political. The people who jockey their spreadsheets may recognize the system wide problem, but they are extremely pleased with the control they have over their own little piece of the data. You can expect resistance if you try to substitute central management and control for the decentralized solution you have now. Some of that resistance is justified.
Another is the cost of databases. As has already been stated in another response, the disadvantages of database may outweigh the advantages.
Another is the credibility of databases. People who put data into databases usually do so because it's their job or maybe to gain something for themselves, like placing an order on a website. They don't do it out of community spirit. At least, not much. Without good inputs, the database never gains credibility.
A solution I am working on now at a site where spreadsheets are just catching on is building a prototype database in MS Access. There is a distinct downside to this: people may learn the wrong thing about databases, something they will have to unlearn at a later stage of evolution. I also think that the reporting features of Access are sorely lacking. and if you are thinking of concurrent users, you have to think beyond Access although Access is making progress inthat regard.
I like three things about Access: it's simple, quick, and cheap to produce primitive prototypes. There is almost no learning curve, especially if you already understand data analysis and table composition.
Second, it's less intimidating than a big centralized DBMS. When users are shown how to open an Access table in table view, by just clicking on it, they lose their fear of tables. And the fact that a single file stores the data, the data definitions, and the application keeps things simple for people who don't think in terms of systems.
Third, it plays well with Excel and Word. copying a table or query into an Excel spreadsheet is as simple as clicking on a button.
Before I could get to this point, I had to overcome a somewhat snobby attitude I had about Access. It's not SQL Server or Oracle. But it does have it's uses, as long as you understand the limitations
Having said all this, you will still be faced with a monumental task when it comes time to move your shop from a lot of little Access databases into a single large scale integrated database, with professional management and shared resources.
