I like to take fuzzy-buzzy terms such as business intelligence and nail them down. BI is not just a smarter, faster way to extract statistics from databases and warehouses. It's a grab for that brass ring of business computing: solutions that don't just tell you what your data is, but also what it means. To take this beyond marketing speak, we must establish what "means" means.
What do I mean, you ask? At present, we think of the meaning of a piece of data in DBA details such as name, data type, table, and key. The thoroughly modern shop blends in XML elements, attributes, and name spaces. Most often, the data derives the other half of its identity from the machinations of developers. During design and development, data turns into objects, objects get encapsulated into other objects, and a pile of objects becomes a solution. Data objects get persisted as records on disk where they can be aggregated, massaged, and archived.
If you were that data, you'd be in a shrink's office right now bemoaning your meaningless existence. By the time a new project starts, the pure business goals that spawned the project become particles on a whiteboard eraser. That is, if such pure business goals were ever discussed. By the time the business side of the house comes to IT's table, business is probably talking about portals, CRM, and yes, business intelligence.
It's time someone pointed out that one can only extract from data the intelligence that went into it. The first stages of BI design attempt to reverse-engineer data structures to recover their original meaning and purpose. That's probably something like the discussion between an eyewitness and a police sketch artist.
I don't mean to wax hopeless about BI projects that pick up where typical application designs leave off. Presumably, your application works. So you can reattach meaning to sterile and efficiently packed data by examining the data's life instead of the anatomical snapshot of it that's laid out in diagrams. BI is as much about data's context as it is about data's shape. In other words, data recovers some meaning beyond its basic structure when observed in the context of its current use. This isn't easy; you can plant triggers in a database table and infer meaning from the patterns of updates. To the extent your design permits, you need to tag your data, like migratory birds, and track its movement through your enterprise. If you watch with sufficient patience, you'll not only learn about your data through its behavior, but also you'll see that your data and workflows aren't behaving as you expected.
As you begin to reassemble the meaning of your data through observation and other methods you find useful, consider two possible uses for the knowledge you acquire. First, team up with your organization's business analysts to create evolving documentation that overlays their business knowledge (what they need in business terms) with your take on what's really happening. Your goal is not a specification, and it's not a finger-pointing contest. Second, as you gain an understanding of what the data means to those who consume it, start attaching that meaning to your data. As you learn, teach your data what it means.
In the best case, everyone with a stake in the quality of business information will learn to mold its shape and course with less regard for technical efficiency and more regard for the business meaning and purpose it ought to convey.