Retail Business Intelligence: Using Data for Better Decision Making

In retail like any other industry there are multitude of interacting business processes. Every business process has input and output data. Output data of one business process can be input data for another and vice versa. Hence theres a multitude of data and making sense of these data becomes a "haystack" problem. Most retailers analyze few of the important data of few important business processes to help them make better business decisions. However it might just happen that some key data might be ignored just due to the absence of arranged and prioritized data. Also it might just happen that the retailer is tracking a wrong KPI altogether due to an myopic approach of selection of data. To add to the problem retailers have disparate systems for different business processes. Collecting data from all these disparate systems and making sense out it is a difficult job.
The idea is that retailers should be focused on a very select data and select KPIs; but the most critical and correct ones. Hence the question to be asked is how does one know what are the correct and critical KPIs and data?
Retail business intelligence is a process of defining data and KPIs to enable retailers better streamline their decision making using data.
Retail business intelligence has two components the metadata and the KPI. Metadata gives definition and logical meaning to the data while KPI gives business meaning to the data. Data from all the disparate systems are pooled in a central location such as a data warehouse. Here the data is associated to metadata to arrange logically segregate and arrange them.
Next KPIs across business processes are defined. For example KPIs for distribution, logistic, category management etc are all defined in a centralized location. These KPIs then use the pooled data to derive a value of business importance.
The KPIs are also arranged based on the viewing authority. For example a Inventory Planning Head would be interested in KPIs such as DC inventory vs Sales, Target Inventory vs Actual Inventory etc while a Store Manager will be viewing KPIs such as Store Floor Space Utilization, Employee Utilization etc. Hence restricting user/ viewer based viewing of data helps the users to focus on their respective KPIs.
Centrally managing data and KPI helps retailers better maintain data and quickly derive sense out of it and hence in turn drive agility in better decision making.

Indian Retail Formats: Strategy to Capture Market Share

Organized retail in India is a new but rapidly growing concept. The top businesses of India are now trying to get a share of the highly lucrative business of organized retailing. Competition is fierce and is between the small retail chains vs the big business houses as new entrants to the retail industry and that between the whole of organized retailers vs the independent traders/ retail shop owners. The competition at this stage (start of life cycle) for organized retailing in India is for Market Share. Each retailer wants to maximize its market share.
In order to grow market share retailers are looking at different strategies to do so. The strategy for the store format is one of the most crucial strategy decision.
Before we try to understand the store format strategy let us first note the few of the uniqueness of India around organized retailing:
1. India has stark differences between cities, towns and villages. The retail needs of cities , towns and villages in India are very different and has unique characteristics.
2. India is a multi cultural country. Each culture has its own retail needs.
3. As with the rest of the world in India too there is a growing market for niche retail needs.

Retailers need to consider the above three factors while defining the store format strategy. The retailer can choose the format for a store depending on the market(demography, age group etc) the store will cater to. The retailer may focus on one specific "niche" market or may want to cater to diverse "general" and "niche" market. Hence different formats of store is required to cater to different target market. The known formats are Supermarket, Hypermarket, Cash n Carry, Speciality, Malls etc. The question to be asked for an Indian retailer is What store format will help the retailer maximize market share? Given the nascent stage of Indian retailing no one format looks like a clear winner. And hence that's the reason that most retailers are trying different store formats to capture market share. For example , Future Group is trying to increase market share by trying various store formats such as Hypermarket (BigBazaar), Supermarket (FoodBazaar), Malls (Central), Fashion (Pantaloons). Similarly , Subhiksha group has Subhiksha General Stores (General Stores) and Sukhiksha Mobile Stores (Speciality). Hence every retailer is trying and studying the various formats of stores to capture market share. No one format is clearly evolving as a clear winner.

Though it might be too early to predict the winner format let us first consider the following factors such as;
1. Indians are cost conscious
2. Indians would prefer a one stop shop for eatables; vegetables, fruits, fish and meat etc.
3. Indians prefer speciality retail outlets for fashion shopping such as furnitures, apparels and electronics
goods

Based on these facts one can predict the need for general store like a neighbourhood food store for daily needs such as vegetables, cereals etc. The stores can have a sq footage area of approx 2500-3000. Theses stores are convenient stores for being easily accessibility and discounts.
For fashion merchandise the stores can be speciality stores. These stores will be speciality retailers for a single kind of merchandise such as apparels or furniture etc. Existing speciality retail outlets such as Mobile Store might not succeed and rather the mobile section in a electronics speciality stores such as E Zone etc.

Integrated Product Development:The Need for Wholistic Picture for Successful Product Development

For a software vendor that has multiple software products up for sale one of the key challenges it faces is the development of new products and enhancement of existing products keeping in view the fitment of the new development or enhancement in the existing portfolio of products.
Say for example a software vendor has each software products for merchandising system, price management system (PMS) ,forecasting, replenishment and merchandise financial planning(MFP). It aims now to develop new products for promotions optimization(PO) , markdown optimization(MDO) and buying and assortment planning(BAM). Each of the three new products can be developed parallelly and separately. However one of the key points to consider before doing a development of the new products would be to consider the integration development that might be required to ensure that the new products intergate perfectly with the exisitng products. For example in the case mentioned above the MFP tool should integrate perfectly with the BAM tool and simillarly the PMS should integrate well with the new MDO and PO tool.

The basic fact is that most software products dont work independently, software products need to interact with and most of the time highly dependent on other software products for complete functioning of the end to end solution comprising many software products.
For the case above replenishment tool is dependent of the forecasting tool to get the forecast based on which it can generate demand driven replenishment stock quantities. Similarly the BAM tool will depend on the MFP tool for a class level sale speed factor to calculate the assortment quantities.
Now lets understand the development or enhancement of an exisiting product to add additional/new functionalities in it. Say for example the PMS tool mentioned above is not suited for an Indian retailer as the product doesnt support the functionality of maximum retail price (MRP) of Indian retailing. This calls for enhancing the PMS tool around the MRP requirement. However the point to consider here is that the alone enhancing the PMS tool will not be sufficient; as other tools such as the PO and MDO tool might require the MRP fucntionality and might require the MRP related data from the PMS tool. In this case the impact of introducing the MRP fucntionality in PMS tool on MDO and PO and maybe other tools need to be analyzed.
In either case; that of new product development or that of enhancement of exisitng products; the impact of integration touch points across the products needs to be anaylzed very clearly.

In the traditional approach of developing software products; the products are developed standalone while keeping in view only the basic intergation touch point with other software products. Not much investment is done in trying to analyze the impact of the integration development being done for the new or exisitng products to the other product. Say for example the integration method chosen by the PO tool development team to integrate the PO tool to PMS for a particular data flow from PO to PMS is a method that might not be supported by PMS and might require lot many modifications in PMS to accomodate it to this integration method. The effort to now modify PMS to integrate it with PO might be lot and this effort estimation might come as a sudden suprise for the PMS team. Also it might just happen that the integration of PO and PMS could have been done using a simpler and a cheaper and more stable method. The reason that this scenario might happen is that proper and indepth analysis of exisitng integration architecture of PMS and the analysis of effort and quality estimation between the integration modifications that might be required in PO to integrate it with PMS vs integration modifications that might be required in PMS to integrate it with PO was not done. Each of the development teams of PMS and PO missed out the wholistic picture and were focussed in developing/enhancing their individual products. This calls for an integrated product development approach.

Integrated product development methodology calls for individual develpoment teams to work in close cohesion and interaction with each other to have a bigger view of an intergrated product suite and then understand the impact of a development/ enhancement of one product on the other products. In doing so the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period than if each of the development teams works seperately and then the finer details of intergation are thrased out. Say for example for the case given above the PMS development team will work closely with the PO and MDO development teams to understand the complete integrated solution of PMS-MDO-PO. The entire team comprising the MDO , PO and PMS developemnt teams would analyze the best approach for developing/enahancing the three products based on the integration touch points between the products to have a stable and effcient intergated solution rather than efficient stand alone products but inefficent when integrated.


Summary:

Software products dont run independently. They need to interact with each other for complete functioning of the solution comprising the software products. Hence integration of the products become a very cruical aspect of the proper and efficient working of the products.

In Traditional Product Development the development teams work separately. There is a limited interaction among the development teams. The individual teams miss the bigger integrated picture. Hence the chances of additional developments that might be required for a complete integrated solution and hence the chances of additional developements and chances of an inefficient integration run high. This in turns leads to longer lead time to deliver an integrated solution.

In integrated product development methodologhy the individual development teams in close interaction with each other to have a bigger view of an intergrated product suite. Hence they understand the impact of a development/ enhancement of one product on the other products better and thus the best approach of development/enhancement method and clearer effort estimation is available. This leads to a far more robust integration in a shorter time period.

Key Decision Points : Implementing Software as a Service (SaaS )

Software as a Service or SaaS is a flavor for On Demand Business. However beneficial SaaS might seem it has its own challenges. Hence one must carefully evaluate the challenges along with the benefits before deciding to implement SaaS for some or all of the business processes. Key decision points to consider on implementing SaaS are
1. Security:
Data Security: For successful SaaS; the software vendor hosting the solution and the cilent need to execute business as a common entity. The client may have to share critical data with the software vendor and hence clear and secured guidelines and proccesses should be defined to ensure the security of data.
Data Flow: Data transfer method and protocols between the client and the software vendor should be secured.

2. Infrastructure: The software vendor should have a strong IT infrastructure. IT human resource, support structure, faliover policy, calamity policy etc should be defined clearly.

3. Knowledge: The software vendor should have a strong customer base of the clients industry. The client should consider the knowledge base (best practices, business analysts etc.) the software vendor possesses around the clients industry. Having a strong knowledge base on the clients industry ensures that the software vendor could make best practice recommendations to help the client runs its business better.

4. Service agreements:
Support:The client should ensure that the software vendor has infrastructure in place to provide virtually a 24 x 7 service and support. This client should consider the leverages gained out of an expectation of 100% customer service.
Contract termination: The client should ensure a smooth termination of contract agreements if necessary.
Protecting IP: The client should ensure proper and secure guidelines to ensure proper protection of its IP shared with the software vendor.