data warehousing & management - lecture no 10

7/29/2019 Data Warehousing & Management - Lecture No 10

1/34

School of Business Management, NMIMS University

MBA Pharma Tech & Healthcare Management

Course: July 2013- September 2013;

Year : IIIRd & Trimester : VII

Lecture No 10

Data Warehousing & Management


2/34

Introduction to Value Chain Inventory Management

Most organizations have an underlying value chain consisting of their key business processes.

The value chain identifies the natural, logical flow of an organizations primary activities. Forexample, in the case of a retailer, the company may issue a purchase order to a productmanufacturer.

The products are delivered to the retailers warehouse, where they are held in inventory.

A delivery is then made to an individual store, where again the products sit in inventory until aconsumer makes a purchase.


3/34

Inventory Management - Diagram


4/34

Inventory Periodic Snapshot

Lets return to our retail case study. Optimized inventory levels in the stores can have a majorimpact on chain profitability.

Making sure the right product is in the right store at the right time minimizes out-of-stocks(where the product isnt available on the shelf to be sold) and reduces overall inventory carryingcosts.

The retailer needs the ability to analyze daily quantity-on-hand inventory levels by product and

store.

It is time to put the four-step process for designing dimensional models to work again.

The business process were interested in analyzing is the retail store inventory.

In terms of granularity, we want to see daily inventory by product at each individual store, whichwe assume is the atomic level of detail provided by the operational inventory system.

The dimensions immediately fall out of this grain declaration: date, product, and store


5/34

Inventory Periodic Snapshot

The simplest view of inventory involves only a single fact; quantity on hand which leads to anexceptionally clean dimensional design


6/34

Dimensions Explanation

The date dimension table in this case study is identical to the table developed in the earlier casefor retail store sales. The product and store dimensions also may be identical.

Alternatively, we may want to further decorate these dimension tables with additional attributesthat would be useful for inventory analysis.

For example, the product dimension could be enhanced to include columns such as the minimumreorder quantity, assuming that they are constant and discrete descriptors of each product stockkeeping unit (SKU).

If we are analyzing inventory levels at the retailers warehouse rather than at the store location,the schema would look quite similar to Figure in the previous slide

Obviously, the store dimension would be replaced with a warehouse dimension.

When monitoring inventory levels at the warehouse, normally we do not retain the store

dimension fourth dimension unless the warehouse inventory has been allocated to a specificstore.


7/34

Semiadditive Facts

When we modeled the flow of product past a point at the checkout cash register, only theproducts that actually sold were measured.

Once a product was sold, it couldnt be counted again in a subsequent sale. This made most ofthe measures in the retail sales schema perfectly additive across all dimensions.

In the inventory snapshot schema, the quantity on hand can be summarized across products orstores and result in a valid total.

Inventory levels, however, are not additive across dates because they represent snapshots of alevel or balance at one point in time.

It is not possible to tell whether yesterdays inventory is the same or different from todaysinventory solely by looking at inventory levels.

Because inventory levels (and all forms of financial account balances) are additive across some

dimensions but not all, we refer to them as semiadditive facts.


8/34

Semiadditive Facts

When we modeled the flow of product past a point at the checkout cash register, only theproducts that actually sold were measured.

Once a product was sold, it couldnt be counted again in a subsequent sale. This made most ofthe measures in the retail sales schema perfectly additive across all dimensions.

In the inventory snapshot schema, the quantity on hand can be summarized across products orstores and result in a valid total.

Inventory levels, however, are not additive across dates because they represent snapshots of alevel or balance at one point in time.

It is not possible to tell whether yesterdays inventory is the same or different from todaysinventory solely by looking at inventory levels.

Because inventory levels (and all forms of financial account balances) are additive across some

dimensions but not all, we refer to them as semiadditive facts.


9/34

Enhanced Inventory Facts

The simplistic view of inventory we developed in our periodic snapshot fact table allows us to seea time series of inventory levels.

For most inventory analysis, quantity on hand isnt enough.

Quantity on hand needs to be used in conjunction with additional facts to measure the velocityof inventory movement and develop other interesting metrics such as the number of turns,number of days supply, and gross margin return on inventory

In addition to the quantity sold, we probably also can supply the extended value of the inventoryat cost, as well as the value at the latest selling price.

The difference between these two values is the gross profit, of course. The gross margin is equalto the gross profit divided by the value at the latest selling price.

Finally, we can multiply the number of turns by the gross margin to get the GMROI, as

expressed in the following formula: GMROI = total quantity sold x (value at latest selling price value at cost) /

daily average quantity on hand x value at the latest selling price


10/34

Enhanced Inventory Facts Contd..

A high GMROI means that we are moving the product through the store quickly (lots of turns)and are making good money on the sale of the product (high gross margin).

A low GMROI means that we are moving the product slowly (low turns) and arent making verymuch money on it (low gross margin). The GMROI is a standard metric used by inventoryanalysts to judge a companys quality of investment in its inventory.


11/34

Inventory Transactions

A second way to model an inventory business process is to record every transaction that affectsinventory.

Inventory transactions at the warehouse might include the following:

Receive product

Place product into inspection hold

Release product from inspection hold Return product to vendor due to inspection failure

Place product in bin

Authorize product for sale

Pick product from bin

Package product for shipment

Ship product to customer

Receive product from customer Return product to inventory from customer return

Remove product from inventory


12/34

Warehouse Inventory Transaction Model

Each inventory transaction identifies the date, product, warehouse, vendor, transaction type,and in most cases, a single amount representing the inventory quantity impact caused by thetransaction.

Assuming that the granularity of our fact table is one row per inventory transaction, theresulting schema is illustrated in below Figure


13/34

Warehouse Inventory Transaction Model Contd..

Even though the transaction-level fact table is again very simple, it contains the most detailedinformation available about inventory because it mirrors fine scale inventory manipulations.

The transaction-level fact table is useful for measuring the frequency and timing of specifictransaction types.

For instance, only a transaction-grained inventory fact table can answer the following

questions:

How many times have we placed a product into an inventory bin on the same day we pickedthe product from the same bin at a different time?

How many separate shipments did we receive from a given vendor, and when did we get them?

On which products have we had more than one round of inspection failures that caused return

of the product to the vendor?


14/34

Ware House Inventory Accumulating Snapshot

The final inventory model that well explore briefly is the accumulating snapshot.

In this model we place one row in the fact table for a shipment of a particular product to thewarehouse.

In a single fact table row we track the disposition of the product shipment until it has left thewarehouse.

The accumulating snapshot model is only possible if we can reliably distinguish productsdelivered in one shipment from those delivered at a later time.

This approach is also appropriate if we are tracking disposition at very detailed levels, such asby product serial number or lot number


15/34

Ware House Inventory Accumulating Snapshot Contd..

Lets assume that the inventory goes through a series of well-defined events or milestones as itmoves through the warehouse, such as receiving, inspection, bin placement, authorization tosell, picking, boxing, and shipping.

The philosophy behind the accumulating snapshot fact table is to provide an updated status ofthe product shipment as it moves through these milestones.

Each fact table row will be updated until the product leaves the warehouse. As illustrated inbelow Figure the inventory accumulating snapshot fact table with its multitude of dates andfacts looks quite different from the transaction or periodic snapshot schemas.


16/34

Value Chain Integration

Now that weve completed the design of three inventory model variations, lets revisit ourearlier discussion about the retailers value chain.

Both the business and IT organizations typically are very interested in value chain integration.

Low-level business analysts may not feel much urgency, but those in the higher ranks ofmanagement are very aware of the need to look across the business to better evaluateperformance.

Numerous data warehouse projects have focused recently on managements need to betterunderstand customer relationships from an end-to-end perspective.

Obviously, this requires the ability to look consistently at customer information acrossprocesses, such as quotes, orders, invoicing, payments, and customer service.

Even if your managements vision is not so lofty, business users certainly are tired of getting

reports that dont match from different systems or teams.


17/34

Value Chain Integration Contd..

IT managers know all too well that integration is needed to deliver on the promises of datawarehousing.

Many consider it their fiduciary responsibility to manage the organizations information assets.They know that theyre not fulfilling their responsibilities if they allow standalone, nonintegrateddatabases to proliferate.

In addition to better addressing the businesss needs, the IT organization also benefits fromintegration because it allows the organization to better leverage scarce resources and gainefficiencies through the use of reusable components


18/34

Share Dimensions between business processes


19/34

Data Warehouse Bus Architecture

Obviously, building the enterprises data warehouse in one step is too daunting, yet building itas isolated pieces defeats the overriding goal of consistency.

For long-term data warehouse success, we need to use an architect, incremental approach tobuild the enterprises warehouse. The approach we advocate is the data warehouse busarchitecture.

A bus is a common structure to which everything connects and from which everything derivespower.

If we think back to the value chain diagram we can envision many business processes plugginginto the data warehouse bus, as illustrated in Figure in the next slide


20/34

Sharing Dimensions across Value Chain


21/34

Data Warehouse Bus Architecture

The data warehouse bus architecture provides a rational approach to decomposing the enterprise

data warehouse planning task.

We then tackle the implementation of separate data marts in which each iteration closely adheres to

the architecture.

As the separate data marts come on line, they fit together like the pieces of a puzzle. At some point,enough data marts exist to make good on the promise of an integrated enterprise data warehouse

The bus architecture allows data warehouse managers to get the best of both worlds.

They have an architectural framework that guides the overall design, but the problem has beendivided into bite-sized data mart chunks that can be implemented in realistic time frames.

Separate data mart development teams follow the architecture guidelines while working fairlyindependently and asynchronously.

The bus architecture is independent of technology and the database platform.


22/34

Data Warehouse Bus Architecture Contd..

All flavors of relational and online analytical processing (OLAP)-based data marts can be full

participants in the data warehouse bus if they are designed around conformed dimensions and facts.

Data warehouses will inevitably consist of numerous separate machines with different operatingsystems and database management systems (DBMSs).

If designed coherently, they will share a uniform architecture of conformed dimensions and factsthat will allow them to be fused into an integrated whole.


23/34

Data Warehouse Bus Matrix

The tool we use to create, document, and communicate the bus architecture is the data warehouse

bus matrix.


24/34

Data Warehouse Bus Matrix Contd..

Working in a tabular fashion, we lay out the business processes of the organization as matrix rows.

It is important to remember that we are identifying the business processes closely identified withsources of data, not the organizations business departments.

The matrix rows translate into data marts based on the organizations primary activities.

We begin by listing the data marts that are derived from a single primary source system, commonly

known as first-level data marts. These data marts are recognizable complements to theiroperationalsource.

The rows of the bus matrix correspond to data marts.

You should create separate matrix rows if the sources are different, the processes are different, or ifthe matrix row represents more than what can reasonably be tackled in a single implementationiteration


25/34


Once it is time to begin a data mart development project, we recommend starting the actual

implementation with first-level data marts because they minimize the risk of signing up for animplementation that is too ambitious.

Most of the overall risk of failure comes from biting off too much of the extract transformation- load(ETL) data staging design and development effort.

In many cases, first-level data marts provide users with enough interesting data to keep themhappy and quiet while the data mart teams keep working on more difficult issues.

Once weve fully enumerated the list of first-level data marts, then we can identify more complexmultisource marts as a second step.

We refer to these data marts as consolidated data marts because they typically cross businessprocesses.

While consolidated data marts are immensely beneficial to the organization, they are more difficultto implement because the ETL effort grows alarmingly with each additional major source thatsintegrated into a single dimensional model.


26/34


It is prudent to focus on the first-level data marts as dimensional building blocks before tackling the

task of consolidating.

In some cases the consolidated data mart is actually more than a simple union of data sets from thefirst-level data marts.

The matrix allows us to communicate effectively within and across data mart teams, as well asupward and outward throughout the organization.

The matrix is a succinct deliverable that visually conveys the entire plan at once.

It is a tribute to its simplicity that the matrix can be used effectively to directly communicate withsenior IT and business management.

Creating the data warehouse bus matrix is one of the most important up-frontdeliverables of a data warehouse implementation. It is a hybrid resource that is part

technical design tool, part project management tool, and part communication tool.


27/34

Conformed Dimensions

Conformed dimensions are either identical or strict mathematical subsets of the most granular,

detailed dimension.

Conformed dimensions have consistent dimension keys, consistent attribute column names,consistent attribute definitions, and consistent attribute values (which translates into consistentreport labels and groupings)

Dimension tables are not conformed if the attributes are labeled differently or contain differentvalues.

If a customer or product dimension is deployed in a non conformed manner, then either the separatedata marts cannot be used together or, worse, attempts to use them together will produce invalidresults

Conformed dimensions come in several different flavors.

At the most basic level, conformed dimensions mean the exact same thing with every possible facttable to which they are joined


28/34

Conformed Dimensions

The date dimension table connected to the sales facts is identical to the date dimension table

connected to the inventory facts.

In fact, the conformed dimension may be the same physical table within the database.

However, given the typical complexity of our warehouses technical environment with multipledatabase platforms, it is more likely that the dimensions are duplicated synchronously in each datamart

In either case, the date dimensions in both data marts will have the same number of rows, samekey values, same attribute labels, same attribute definitions, and same attribute values

There is consistent data content, data interpretation, and user presentation.

Most conformed dimensions are defined naturally at the most granular level possible. The grain ofthe customer dimension naturally will be the individual customer.

The grain of the product dimension will be the lowest level at which products are tracked in thesource systems.

The grain of the date dimension will be the individual day.


29/34

Another Case Conformed Dimensions

Another case of conformed dimension subsetting occurs when two dimensions are at the same level

of detail but one represents only a subset of rows.

For example, we may have a corporate product dimension that contains data for our full portfolio ofproducts across multiple disparate lines of business, as illustrated in below Figure


30/34

Conformed Dimensions Contd..

Conformed dimensions will be replicated either logically or physically throughout the enterprise;

however, they should be built once in the staging area.

The responsibility for each conformed dimension is vested in a group we call the dimensionauthority.

The dimension authority has responsibility for defining, maintaining, and publishing a particulardimension or its subsets to all the data mart clients who need it.

They take responsibility for staging the gold-standard dimension data.

Ultimately, this may involve sourcing from multiple operational systems to publish a complete, high-quality dimension table.

Obviously, conformed dimensions require implementation coordination.

Modifications to existing attributes or the addition of new attributes must be reviewed with all thedata mart teams employing the conformed dimension.


31/34

Conformed Facts

Thus far we have talked about the central task of setting up conformed dimensions to tie our data

marts together.

This is 90 percent of the up-front data architecture effort. The remaining effort goes intoestablishing conformed fact definitions.

Revenue, profit, standard prices, standard costs, measures of quality, measures of customersatisfaction, and other key performance indicators (KPIs) are facts that must be conformed.

In general, fact table data is not duplicated explicitly in multiple data marts.

However, if facts do live in more than one location, such as in first-level and consolidated marts, theunderlying definitions and equations for these facts must be the same if they are to be called thesame thing.

If they are labeled identically, then they need to be defined in the same dimensional context and

with the same units of measure from data mart to data mart.


32/34

Summary

Inventory is an important process to measure and monitor in many industries.

In this chapter we developed dimensional models for the three complementary views of inventory.

Either the periodic or accumulating snapshot model will serve as a good stand-alone depiction ofinventory.

The periodic snapshot would be chosen for long-running, continuously replenished inventory

scenarios.

The accumulating snapshot would be used for one-time, finite inventory situations with a definitebeginning and end.

More in-depth inventory applications will want to augment one or both of these models with thetransaction model.


33/34

Summary Contd..

We introduced key concepts surrounding the data warehouse bus architecture and matrix.

Each business process of the value chain, supported by a primary source system, translates into adata mart, as well as a row in the bus matrix.

The data marts share a surprising number of standardized, conformed dimensions.

Developing and adhering to the bus architecture is an absolute must if you intend to build a data

warehouse composed of an integrated set of data marts.


34/34

Thank You

data warehousing & management - lecture no 10

Documents