As well as this book, available through SAS Publishing:
SAS Information Map Studio 3.1: Tips And Techniques by SAS Publishing
In brief, however, let me outline a possible usage situation. You have a set of files that are always used for reporting:
In the most simple form, having an Information Map would allow you to simplify the names of the columns used for reporting (like getting rid of the long file prefix in the column names). You could also "disappear" away the underscores in the column names. Moving up to the next level, you could build an Information Map that would automatically do a join of the 2 tables and would only show the end-user the columns that were needed for reporting. You could make a calculated data item. You could build pre-defined filters (such as filters by state or country or Purchase Order type).
Information Maps are extremely useful in masking the complexity of the physical data layout or table relationships from the end-user. In addition, if you have business rules that are ALWAYS applied to data access (only people in the Purchasing Department see the VMF_Vendor_Purchase_Order_Type_Preferred field) or some such logic, then you can implement that in an information map, too.
The bottom line is that you have to analyze your current data tables and figure out what kind of joins/transformations need to be done in order to produce your reports. You need to figure out whether you will build Web Report Studio reports ahead of time using your Information Maps or whether you will design the Information Maps and allow users to do ad-hoc reporting from the Information Maps. Then, you need to build and test the Information Maps from all the client applications that will use the Information Maps.
The resources listed at the top of this posting should get you pointed in the right direction.