Q: Should the size of a company affect the need for a decision support system (DDS), a data warehouse, and an expert system to improve its sales figures and profitability?

Clay Rehm's Answer:

Theoretically no, but economically yes.

Small companies, and the owners of those small companies will not justify the expenditure of tools for decision support and business intelligence.

However, just because a company is very small and with a small budget does not mean they cannot do some kind of DSS. There are many inexpensive tools, and there are tools that can be developed inexpensively that may not have all the bells and whistles, but the purpose is to report data in some way. As long as the system has data integrity and ease of use, that is what is important.

Anne Marie Smith's Answer:

The size of a company should not affect its need for these business intelligence tools, but the size would play a large role in the products chosen and the size of the resulting business intelligence environment. For example, a major auto manufacturer may choose decision support system products that can address terabytes of data from its very large data warehouse and an expert system that can incorporate dozens of factors for analyzing sales and profitability. A smaller organization, however, still needs these tools and techniques, but the smaller organization will have smaller data warehouse databases and can use DSS and expert systems that are scaled to meet the needs of smaller volumes of data and fewer parameters for analysis. Any organization, regardless of its type (profit or non-profit or government) or its size can benefit from the proper use of decision support systems, data warehousing and expert systems.

Adrienne Tannenbaum's Answer:

My favorite answer is "It depends." In theory, nothing should affect the need for a data warehouse or all of its predecessors such as a decision support system. However, since the "decisions" are based almost exclusively on existing company data, the data must be stored in identifiable, understandable, and organized locations. And the updates should be time-frame consistent (every month, every day, every hour, whatever).

For example, if a small company stores all sales data in a defined MS Access database, getting to it is a piece of cake (you know where it is and how it is organized so building an extract file or accessing it directly can be standardized). If updates to this data are done consistently, for example at the close of each billing cycle, or daily, then the continued access of this data will be equivalently easy and can be mechanized. However, if the data is all over the place - spreadsheet, spreadsheet, spreadsheet - and not consistent (the same data and various versions are kept in multiple spreadsheets as the result of extremely variant calculates), you can almost forget the idea ... unless you want to spend the time standardizing spreadsheet based information.

Ironically, this prerequisite situation is also a condition of decision support in a large organization. Usually, even though the data is all over the place and inconsistent, some of these data stores are usually identified as decision support players, and the decision support system's implementation is based upon the design and content of each of these identified data stores.

Tom Haughey's Answer:

Generally speaking, it will not affect the need for decision support systems but it may affect the architecture and technology of the solution. Under some special circumstances, however, it might actually reduce the need for a separate DSS solution, such as a data warehouse. I will go over some thoughts on both.

DW Topology. Because of probably lower data volumes and less complexity of data and queries, your environment might easily enable a more centralized solution from the start. I don't see the benefit in creating distributed data solutions when the volumes, concurrency and complexity are not that great. The remaining comments will focus on the three major components of a data warehouse, Gather, Store and Deliver.

Gather. In smaller DSS solutions, which I consider this question to imply, RYO ETL (Roll Your Own) can be a very viable choice. RYO ETL is a term I use to describe hand-coded ETL, such as the use of COBOL and Syncsort rather than a formal ETL product. This form of custom-coded ETL is performed using off the shelf or readily available programming tools. It will reduce costs because the programming language or tool will usually be already available in the organization and there will be little or no learning curve. One main drawback of this is that these solutions do not inherently save metadata, whereas robust ETL tools do.

Store. It is very viable in smaller DSS solutions to install a database using open source tools and generally available tools such as SQL Server. For larger DW applications, such products can pose limitations in scalability, concurrency and performance.

Deliver. Business Intelligence (BI) tools can be expensive though they are full-function and easy to use. In some smaller DSS cases, what I call "poor people's BI" can be used instead. These are exemplified by products like MS Access or similar tools to provide business intelligence capability. The overall capabilities of Access and its pivot tables might be sufficient for less complex business environments.

Virtual DW. The architecture that provides analysis and reporting capabilities without the implementation of a separate DW is called a virtual DW. DSS querying and reporting are run right off the operational data. Perhaps, this is essentially what your question is referring to. This architecture might be viable in smaller DSS implementations where the organization has an integrated set of databases. For example, supposing a company is running its operational processes exclusively off of an integrated package. It takes orders, bills, accepts payments, processes inventory and processes financial transactions using a single package, or few very well integrated packages. Under these circumstances, it might be possible to do DSS straight off the operational data. Even in this case it is not without problems. Yet, while some consultants propose the virtual DW is a generally viable solution, it has some serious limitations, as identified next.

  1. It contains only detailed data.
  2. The data is not usually in end user format (but this can be solved by views). Smaller installations such as yours often are implemented using some integrated application packages. If this is the case, and the data within them is integrated and non-redundant (or at least having controlled redundancy), the virtual DW is a possibility, at least in this regard.
  3. Ad hoc queries are more difficult. Not only is it more difficult to form the queries, but it is more difficult to ensure that different people can get the same answer to (apparently) the same question. A DW solves this by providing snapshots of the data that are integrated and synthesized.
  4. External data is missing (e.g., purchased demographic data). Most analytics require a substantial amount of external data. Some data warehouses have more external than internal data. The operational external data may have to be supplemented with the necessary external data.
  5. Rollup data, such as reporting hierarchies, is missing. Reporting systems require hierarchies of reference data, such as product, customer, calendar and geography hierarchies. These are not present in operational data.
  6. Finally, there will be a performance impact on operational systems, and a corresponding impact on the analytics. This impact can be very significant.
  7. Virtual data warehouse has the same issues with integration of diverse data that appear in data warehouse systems, except that the queries will have to deal with them. In the data warehouse, robust ETL processes deal with it. Either the data has to be integrated in advance, as in done in ETL, or the query front end must integrate the data during execution of the query. There are tools, such as federated DBMSs, that can do this form of integration, but the result is only as good as the original data.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access