Let's talk about transactions. Eventually, you wite reports from your data warehouse that the company relies on to make decisions that effect the business. If a basic transaction is our lowest grain of information, we should really make sure that the transactional systems are working properly before we think about building decisions on top of them. In my experience, a good decision support system is built by people who question the transactional systems and find any flaws in the data lineage.

Let's think about a report that talks about net profit. One aspect of net profit is cost. Cost means a lot of different things to a lot of different people. If you are buying a finished good from a vendor, your cost is the price they charged you. However, does your transactional system capture cost differently if for some special occasion you bought a bulk amount of product at a volume discount? Does your cost include the space on the rent in your warehouse because you kept it there for a year without selling it? Did your transactional system capture all of the purchase orders for that product in one place? Are some of the purchase orders paper orders or vendor direct orders (not housed in your warehouse inventory system) and therefore the data is not captured in the system? What do you do then? Do you take the average cost of the item when you sold it? If so, you start to make assumptions that lead you down a very slippery slope. Better to keep things simple.

Eli Goldratt says in his book The Goal that there are three measurements that tell you whether or not the company is making money: Throughput, Inventory, and Operational Expense. I feel his attention to definitions and the process of on-going improvement are very important first steps for your first time decision support system builder. Every aspect of a company tallies up into these three buckets which are well defined in his book and later works. These definitions must be supported by information systems that capture each piece of data correctly or at least consistently in the ball park. You should not have a information system that combines any of these categories in one number that can't be broken out.

In summary, be skeptical of the transactional systems. I've started building DSS applications and as I learned more about the data I was getting, I found that things were not being recorded properly or definitions that the business people were giving me were imposibble to replicate from the data warehouse or transactional systems. You would either have numbers mashed together that needed to be reported separately or you would have transactional systems that were dropping transaction detail on the floor.Your corporate culture should be one where all people who have a stake in the process review the data trails to make sure their needs can be met without making assumptions or averaging numbers instead of using actuals. Transactions are your basic DSS building block and for your DSS foundation to be strong, you must know how your transactional systems work and don't let them go into production if they don't support  DSS needs. Also, if you do let them go, make sure you have a culture where someone in the organization will catch the error right away and have his issues taken seriously and addressed...a tough order to fill in the real world where people have so many priorities.... idealistic but... just build it right the first time. If you have to, have many people building it if it is complex enough up front rather than paying for inaccuracies and not being able to trust your information systems downstream.