WIPRO Ltd

Aashish Chhiller
2011ME20762
ONLINE RETAIL
Improvement in Inventory

1 CONTENTS
2 Abstract ................................................................................................................................................. 2
3 Introduction .......................................................................................................................................... 3
3.1 Wipro Limited ............................................................................................................................... 3
3.2 SAP SE ............................................................................................................................................ 3
3.3 SAP HANA ...................................................................................................................................... 4
3.4 Project Introduction ...................................................................................................................... 4
4 Objective ............................................................................................................................................... 5
5 Scope ..................................................................................................................................................... 5
6 Concepts Applied .................................................................................................................................. 6
6.1 EOQ Inventory System .................................................................................................................. 6
6.2 ABC Analysis .................................................................................................................................. 8
6.3 Decision Tree ................................................................................................................................. 9
7 Database Management Concepts ....................................................................................................... 10
7.1 Tables .......................................................................................................................................... 10
7.2 Selection Operation .................................................................................................................... 10
7.3 Projection Operation .................................................................................................................. 10
7.4 Join Operation ............................................................................................................................. 10
7.5 Views ........................................................................................................................................... 11
8 Online Retail Sales: A Deeper Look ..................................................................................................... 13
8.1 Common Practices ...................................................................................................................... 13
8.2 Customer Satisfaction ................................................................................................................. 13
8.3 Use Case ...................................................................................................................................... 14
8.4 Sales ............................................................................................................................................ 14
8.5 Social ........................................................................................................................................... 15
8.6 Integration .................................................................................................................................. 16
8.7 Inventory Levels .......................................................................................................................... 16
8.8 GPS Plotter .................................................................................................................................. 17
9 Final Implementation .......................................................................................................................... 18
10 Future Suggestions .......................................................................................................................... 20
11 Conclusion ....................................................................................................................................... 21

2 ABSTRACT
SAP is a trusted company in the field of data management and analysis software.
Recently a new product was launched, SAP HANA and Wipro as a leading IT firm
has made efforts to incorporate the same to meet its clients’ needs. This was my
goal as I worked for Wipro. Incorporating elements of knowledge learnt as part of
my studies as an Industrial Engineer, I strived towards incorporating Inventory
Management with the data gleaned off of social media sites. Packaging this model
using HANA and utilizing its real time analysis methods I have thus developed a
model through which profits can be increased by online retail companies.



















3 INTRODUCTION
3.1 WIPRO LIMITED
Wipro Limited (formerly Western India Products Limited) is a multinational IT
consulting and System Integration services company headquartered in Bangalore,
Karnataka, India. As of March 2014, the company has 146,000 employees servicing over 900
large enterprise corporations with a presence in 61 countries. On 31 March 2014, its market
capitalisation was approximately 1.27 trillion ($20.8 billion), making it one of India's largest
publicly traded company and seventh largest IT services firm globally. Azim Premji is a major
shareholder in Wipro with over 50% of shareholding.
Wipro entered into the technology business in 1981 and has over 140,000 employees and
clients across 54 countries today. IT revenues stood at $6.2 billion for the year ended 31 March
2013, with a repeat business ratio of over 95%.

The business model at Wipro Technologies Ltd is an industry aligned customer facing
model which gives greater understanding of customers’ businesses to build industry specific
solutions.
3.2 SAP SE
SAP SE is a European multinational software corporation that makes enterprise software to
manage business operations and customer relations. Headquartered in Walldorf, Baden-
Württemberg, Germany, with regional offices around the world.
The company's best-known software products are its enterprise resource planning application
systems and management (SAP ERP), its enterprise data warehouse product – SAP Business
Warehouse (SAP BW), SAP Business Objects software, and most recently, Sybase mobile
products and the in-memory computing appliance SAP HANA.
As of 2007, SAP is the world's largest business software company and the third-biggest
independent software provider by revenue. The corporation operates in four geographic
regions: EMEA (Europe, Middle East, Africa), NA (United States and Canada), LAC (Latin
America and Caribbean), and APJ (Asia Pacific and Japan), which represents Japan,
Korea, Australia, New Zealand, India, Greater China and Southeast Asian countries. In addition,
SAP operates a network of 115 subsidiaries, as well as R&D (Research and Development)
facilities in Germany, India, the US, Canada, France, Brazil, Turkey,
China, Hungary, Israel, Ireland and Bulgaria.
SAP focuses upon 25 industries and six industry sectors: process industries, discrete industries,
consumer industries, service industries, financial services and public services. It offers
integrated product sets for large enterprises, mid-sized companies and small businesses.
3.3 SAP HANA
SAP HANA, short for "High-Performance Analytic Appliance" is an in-memory, column-
oriented, relational database management system developed and marketed by SAP AG. It runs
massively parallel, thus exploiting the maximum out of multicore processors and subsequently
enabling very fast query execution.
SAP HANA originates from developed or acquired technologies, including TREX search engine,
an in-memory column-oriented search engine, P*TIME, an in-memory OLTP database acquired
by SAP in 2005, and MaxDB with its in-memory liveCache engine. In 2008, teams from SAP
AG working with Hasso Plattner Institute and Stanford University demonstrated an application
architecture for real-time analytics and aggregation, mentioned as "Hasso's New Architecture"
in SAP executive Vishal Sikka's blog. Before the name HANA settled in, people referred to this
product as New Database.
The product was officially announced in May 2010. In November 2010, SAP AG announced the
release of SAP HANA 1.0, an in-memory appliance for business applications and business
Intelligence allowing real-time response. The first product shipped in late November 2010. By
mid-2011, the technology had attracted interest but the conservative business customers still
considered it "in early days". HANA support for SAP NetWeaver Business Warehouse was
announced in September 2011 for availability by November.
In 2012, SAP promoted aspects of cloud computing. In October 2012, SAP announced a variant
called HANA One that used a smaller amount of memory on Amazon Web Services for an hourly
fee.
In January 2013, SAP enterprise resource planning software from its Business Suite was
announced for HANA, and became available by May. In May 2013, a software as a
service offering called the HANA Enterprise Cloud service was announced.
3.4 PROJECT INTRODUCTION
Thus SAP HANA was a revolutionary product designed to produce real-time analysis of huge amounts of
data. As yet there is no viable competitor to this technology. While Oracle, SAP’s biggest competitor
introduced an in-memory capable product it flopped massively. Even so, SAP HANA is more expensive as
compared to its predecessors and has thus not yet been widely adopted.
The main aim thus of my project was to make use of the functionalities of SAP HANA and create a
method to generate profits for the clients of Wipro.
I chose to use my knowledge of inventory management methods to create a prototype system that
would somehow utilize real time social data of customers to increase revenue for companies. In the next
few pages I would be introducing the same.


4 OBJECTIVE
The project aims to incorporate social data of customers and utilize it to improve customer
satisfaction for online retail companies through proper inventory handling and delivery
completion. The central idea of the project relates to the fact that of the huge number of
customers of a company very few of them are really important and if retained help boost sales
by bringing in new potential customers. The project thus had three distinct phases:
 Inventory Management: Build an inventory management system somehow integrating
social data.
 Social Data: Acquire and analyse social data to feed to the inventory management
system.
 GPS Tracking: Track orders through a GPS system and report time to delivery to
customers.
5 SCOPE
As mentioned the core of the project is the fact that not all customers should be treated equally.
While all customers are potentially equal some customers are inherently more valuable than
others. Thus by treating customers as a resource, by cultivating them and identifying the best of
the lot, a company can greatly improve profits and thus sales.
A customer with a long history of buying from a particular company is not only more likely to
buy from the same company again but also more likely to encourage people in his social circle
to do the same.
Similarly a first time buyer with a huge social circle is again more likely to convert some of the
people in his social circle and drive sales for the company.
Thus we have two measures, a loyal customer is important; and a customer who has a huge
social presence is important. Using sample data, it was estimated that each such “valuable”
customer has the potential to bring on an average 3 more customers. If none of these 3
customers would fall in our definition of "valuable”, and the company only sells a single product,
sales would increase by 60% and this is only a conservative estimate. To be noted though is the
fact that this is just an estimate and would have to be tested in the real world before it can be
validated.
Also this would greatly increase if the ripple effect is taken into consideration. The ripple effect
is the idea that of the on an average three new customers gained by each “valuable” customer,
some might in fact be “valuable” themselves. This would lead to an exponential increase in our
estimate.

6 CONCEPTS APPLIED
Before we go into a discussion of the methodology developed, I describe here some of the
concepts used in the project.
6.1 EOQ INVENTORY SYSTEM
Let us assume we have a holding cost per item of H (cost to hold the items in inventory) and an
ordering cost per order of O (includes costs like transportation cost etc.). Now if our average
demand per year is D and we order Q units in each order.
So total money spent on ordering = (D/Q)*O
Estimated items held in inventory at any given time = Q/2 (Assuming demand rate is constant)
Cost of holding items in inventory = H*Q/2
Thus total cost = (D/Q)*O + H*Q/2 and this will be minimum for -(D/Q
2
)*O + H/2=0.
Thus Q
*
, most economic ordering quantity per order = √






This tells us how much we should order but not when we should order. For that we again
assume a constant demand rate and come up with a graph that looks like this.




If we order when our stock has finished we would not be able to fulfill the demand during the
time the order gets fulfilled. Let the time it takes to fulfill an order be L, lead time. Thus we
should order L time units before our stock is completely depleted. Let average demand per unit
time be d. Each time we are ordering Q
*
units, thus we should order when our supply hits, d*L.
This is known as the reorder point, R. Here though we have assumed that d and L are constants
but they might be random variables with some distribution. Assuming a normal distribution for
both of them,
Let the standard deviation of L be S
l
and the standard deviation of d be S
d
the standard
deviation for the reorder point is taken to be S
r
= (L* S
d
2
+ d* S
l
2
)
1/2

Now we have to assume a service level say z. This means that out of every 100 times z times we
won’t run out of stock if R = d*L + z*S
r

We also add some safety stock to further decrease the probability of a stock out. Let it be 10%
of R.
Now this model takes into account uncertainties in demand as well as lead time.
This is the EOQ model for inventory.
6.2 ABC ANALYSIS
ABC analysis has been used numerous times in my project, so it would be prudent to discuss it
beforehand. ABC analysis is a quick tool to categorize information into three categories.
An analysis of a range of items that have different levels of significance and should be handled
or controlled differently. It is a form of Pareto analysis in which the items (such
as activities, customers, documents, inventory items, sales and territories) are grouped into
three categories (A, B, and C) in order of their estimated importance. 'A' items are very
important, 'B' items are important, 'C' items are marginally important.
For example, the best customers who yield highest revenue are given the 'A' rating, are usually
serviced by the sales manager, and receive most attention. 'B' and 'C'
customers warrant progressively less attention and are serviced accordingly.
Thus ABC analysis is used to categorize based on value. Typically,
 ‘A’ items – 20% of the items accounts for 70% of the value of the items.
 ‘B’ items - 30% of the items accounts for 25% of the value of the items.
 ‘C’ items - 50% of the items accounts for 5% of the value of the items.


6.3 DECISION TREE
A decision tree is a flowchart-like structure in which internal node represents a "test" on an
attribute (e.g. whether a coin flip comes up heads or tails), each branch represents the outcome
of the test and each leaf node represents a class label (decision taken after computing all
attributes). The paths from root to leaf represents classification rules.
A decision tree consists of 3 types of nodes:
 Decision nodes - commonly represented by squares
 Chance nodes - represented by circles
 End nodes - represented by triangles
Decision trees are used to learn from historic data and to make predictions about the future.
Prediction involves establishing rules using historic data and applying these rules to new data.
These rules are displayed graphically as a hierarchy.
As an example let us take the case of predicting whether or not a customer is satisfied. The
customer data typically contains attributes such as gender, age, income, region, and occupation
as well as information about whether a customer is a satisfied customer or not (possibly drawn
from a survey). Such historic data can be used to train a decision tree. As a result it can be
found that customers exhibiting certain attributes are generally satisfied customers while
customers exhibiting other attributes tend to be dissatisfied customers. Rules can be
determined in this way to assess the satisfaction of other customers in cases where this
information is not available.


7 DATABASE MANAGEMENT CONCEPTS
7.1 TABLES
A table is a collection of related data held in a structured format within a database. It consists
of fields (columns), and rows.
In relational databases and flat file databases, a table is a set of data elements (values) using a
model of vertical columns (which are identified by their name) and horizontal rows,
the cell being the unit where a row and column intersect. A table has a specified number of
columns, but can have any number of rows. Each row is identified by the values appearing in a
particular column subset which has been identified as a unique key index.
Table is another term for relation; although there is the difference in that a table is usually
a multiset (bag) of rows where a relation is a set and does not allow duplicates. Besides the
actual data rows, tables generally have associated with them some metadata, such
as constraints on the table or on the values within particular columns.
The data in a table does not have to be physically stored in the database. Views are also
relational tables, but their data are calculated at query time. Another example are nicknames,
which represent a pointer to a table in another database.
7.2 SELECTION OPERATION
The selection operation selects rows that satisfy a certain condition from a table. As an example
in a table of cities and their population a selection can be made to view cities which have a
population of above say N.
7.3 PROJECTION OPERATION
The projection operation is used to project out columns from a table. As an example in a table
with cities, their population and the average crime rate, a projection can be made to view only
the cities versus the crime rates.
7.4 JOIN OPERATION
The join operation is used to join two tables such that one of the columns in one table is equal
to the other in the other table. So if we have two tables one with city name versus population
and the other with city name versus crime rate and we can join them with the condition that
city name in table 1 is equal to city name in table 2. This would give us a table where city name,
population and crime rate are all given.


7.5 VIEWS
In database theory, a view is the result set of a stored query on the data, which
the database users can query just as they would in a persistent database collection object. This
pre-established query command is kept in the database dictionary. Unlike ordinary base
tables in a relational database, a view does not form part of the physical schema: as a result set,
it is a virtual table computed or collated dynamically from data in the database when access to
that view is requested. Changes applied to the data in a relevant underlying table are reflected
in the data shown in subsequent invocations of the view.
Views can provide advantages over tables:
 Views can represent a subset of the data contained in a table. Consequently, a view can
limit the degree of exposure of the underlying tables to the outer world: a given user
may have permission to query the view, while denied access to the rest of the base
table.
 Views can join and simplify multiple tables into a single virtual table.
 Views can act as aggregated tables, where the database engine aggregates data
(sum, average, etc.) and presents the calculated results as part of the data.
 Views can hide the complexity of data. For example, a view could appear as Sales2000
or Sales2001, transparently partitioning the actual underlying table.
 Views take very little space to store; the database contains only the definition of a view,
not a copy of all the data that it presents.
 Depending on the SQL engine used, views can provide extra security.
There are three types of information views in HANA: attribute view, analytic view, and
calculation view. All three types of information views are non-materialized views. This creates
agility through the rapid deployment of changes as there is no latency when the underlying
data changes.
 Attribute Views
o Model an entity that is based on relationships between attribute data contained
in multiple source tables.
o For example, customer ID is the attribute data that describes measures (that is,
who purchased a product). However, customer ID has much more depth to it
when joined with other attribute data that further describes the customer
(customer address, customer relationship, customer status, customer hierarchy,
and so on).
 Analytic Views
o Used to model data that includes measures.
o For example, an operational data mart representing sales order history would
include measures for quantity, price, and so on.
o The data foundation of an analytic view can contain multiple tables. However,
measures that are selected for inclusion in an analytic view must originate from
only one of these tables.
 Calculation Views
o Used to define more advanced slices on the data in the SAP HANA database.
o Can be simple and mirror the functionality found in both attribute views and
analytic views.
o Typically used when the business use case requires advanced logic that is not
covered in the previous types of information views.
o For example, calculation views can have layers of calculation logic, can include
measures sourced from multiple source tables, can include advanced SQL logic,
and so on.
o The data foundation of the calculation view can include any combination of
tables, column views, attribute views and analytic views. You can create joins,
unions, projections, and aggregation levels on the sources.
Only calculation views have been used throughout the project because of their flexibility and
complexity.












8 ONLINE RETAIL SALES: A DEEPER LOOK
8.1 COMMON PRACTICES
Companies segregate customers according to their brand loyalty and use loyalty schemes to
encourage them to buy from the same company repeatedly. A common practice is thus to
divide customers into three categories gold, platinum and diamond each tier with its own
benefits and requirements. So say a customer with that has been with the company for a long
time might enjoy some discounts and services that a new customer might not.
The theory is that this would encourage customers to buy from the same company repeatedly
to gain access to the services and discounts of better tiers. This is a conscious form of
encouragement and it utilizes methods to make existing customers buy more.
Instead if we look at making existing customers bring in new customers we enter into the realm
occupied till now by advertising. If we surreptitiously increase satisfaction of customers who are
more likely to influence people in their social circle to buy from our company, we are also
increasing sales and thereby revenue. We will now look as to how this can be done.
8.2 CUSTOMER SATISFACTION
Retail sales revolves around customer satisfaction. A satisfied customer will have no reason to
buy products from a rival company and would thus be easily retained. Thus increasing overall
customer satisfaction should increase company sales and revenue. And this has also been
observed and validated in the real world. Companies have been making efforts to increase
customer satisfaction and after sales services like warranty etc. are steps to achieve the same.
The two most important metrics to measure customer satisfaction are lead time and the cost to
the customer. The lower the cost the customer has to pay, the more satisfied he’ll be. The
earlier his product is received by him, again the more satisfied he’ll be.
But the efforts of most companies tend to be wide sweeping changes applying to all of the
customers. If a company uses a better forecasting model and thus reduces lead time for a
customer, the lead time is reduced for all of its customers. If a company provides discounts,
more often than not, they are provided to all of the customers.
If we view discounts and lead time as resources, the company invests them into customers and
gets returns in the form of satisfaction. Satisfaction translates to real sales and real revenue and
thus this model has been working well for a long time.
But as with any resource, spending them equally on all customers leads to waste. These
resources are wasted on some customers who could have been more easily satisfied.
Equivalently, customers who have a higher standard are left unsatisfied even after spending the
resources of discounts and lead time reduction.
Now companies also realize this and thus the loyalty programs etc. which benefit different
customers differently. But this is done only in the field of cost to the customer i.e. discounts
and that too very rarely. My suggestion thus consists of two things:
 Identify customers who are “valuable” to the company
 Provide better lead times and discounts to such customers
This would ensure that these “valuable” customers are satisfied and thus not only retained but
act as sources for new customers to the company.
8.3 USE CASE
The use case I have assumed is an online retail sales environment in a local region with one
warehouse and only one product. It can be easily extended to more than one products and
more than one warehouses.
Inventory is maintained in the warehouse from where it is delivered locally. Orders are placed
back to the factory from the warehouse and inventory is managed using an EOQ system.

8.4 SALES
This deals with customer retention. A customer with a past history of buying from our company
is much more likely to continue doing so in the future so investing resources like discounts in
such customers would lead to ensured returns in the form of greater retention.
The method followed to do the same has been described below.
The past sales data is analysed and customers are divided into three categories using ABC
analysis. Value associated with each customer is the amount spent by each customer buying
the company’s products. The items are the customers themselves. They are thus ranked A or B
or C according to the category assigned.
This is done by SAP itself. Starting off with a huge amount of sales data we divide it into
categories. We then make a decision tree to decide any further sales and this decision tree is
then used to label all new sales based on the customers.
As an example, we have successfully completed our ABC analysis and have developed a decision
tree. Suppose the criteria for class A is that money spent by customer should be above x and so
on. A customer comes in say, customer R. Now the system will check for customer R and review
his past sales history. It will calculate the total amount spent and then place him accordingly
into a category. These categories will be used to decide the service level associated with the
customer.
Further because we are working in an online retail atmosphere, no customer physically comes
in and categories are associated and reviewed periodically after the customer makes an
account. As an example Ram opens flipkart.com on his laptop and makes an account on the
website. Now as Ram shops online his total money spent increases and thus he gradually might
increase his label of A, B or C.
In addition to this, periodically the decision tree is renewed to take into account the growth of a
company. For a new company, a customer who has spent Rs 10000 might be an A class
customer, but as it grows, and more people start spending more amount of money, the
definition needs to be upgraded. Thus ABC analysis needs to be carried out repeatedly
depending on the growth of the company and thus the decision tree criteria also needs to be
updated.

8.5 SOCIAL
This deals with making existing customers as sources which bring in more customers to the
company, thus increasing sales and revenue. Here we assume that a satisfied customer would
influence and encourage people in his social circle to buy from the company. The method has
been described below.
In the modern world more and more of our social life is being digitized. Now we have reached a
stage wherein in most developed countries we can estimate a person’s personality through his
online interactions. Thus it would be fair to assume as a heuristic the number of online
followers of a person as a measure of the people in his social circle in the real world. Next we
also assume that there are no overlaps among the online followers of different customers. This
assumption is a false assumption and would need to be corrected. Luckily a correction factor
can be applied but that was outside the scope of the project.
Now we again do an ABC analysis wherein again the items are the customers and value is the
number of potential customers i.e. the number of online followers of the customer. And we
again make a decision tree which due to reasons mentioned in the previous section we update
periodically.
Important to note is the fact that the only metric used is the number of followers of a person.
There are numerous other metrics that can be used and in fact should be used to extend the
project. Again we get three categories of customers.




8.6 INTEGRATION
Now we integrate the sales data with the social data. We had three categories of customers
from each thus we have 9 categories. Depending on the company and its marketing
department, different rules can be created to apply varying service levels for each category.
For e.g. a customer belongs to category A in the sales data and category C in the social data, i.e.
the customer has a long history with the company but he does not have a significant social
presence. So the customer can be provided with some discount but might also be made to wait
slightly longer than someone who has an enormous social presence.
This was implemented by making two inventory categories, A and B. Thus for each of the nine
categories we assign a discount and an inventory category which helps in providing faster
delivery for important customers. This is again implemented through a custom made decision
tree. The decision tree in a table form would look like this,


Sales Category Social Category Discount Inventory Level
A A 0.25 A
A B 0.15 A
A C 0.20 B
B A 0.10 A
B B 0.00 B
B C 0.00 B
C A 0.10 B
C B 0.05 B
C C 0.00 B

8.7 INVENTORY LEVELS
The inventory levels exist only in the virtual system and not in the physical world so that
physically no change to the system need be made.
Virtually, the service levels for the three inventory levels are decided the highest being for the A
category products and lowest for the B category. The reorder point for each inventory class is
calculated separately as well as the optimal order quantity. This is done by differentiating and
forecasting demand for each of the categories separately though the lead time would be the
same for the three categories. The B category is maintained as normal. In the A category only a
certain level of safety stock is kept which is calculated by estimating increased sales and
equating it with higher cost of safety stock. The A category safety stock ensures that at all times
sufficient stock is available to deliver to “valuable” customers.
8.8 GPS PLOTTER
GPS tracking of order delivery and reporting of time left was completed by a fellow intern using
google SDK.








9 FINAL IMPLEMENTATION
Finally the project has been implemented through SAP HANA and made to work in real time.
Data is entered from the websites into the server. The servers are connected to HANA and
HANA issues all order triggers back to the factory from the warehouse.
The input tables are the two basic sales data i.e. what was sold, when and to whom and, the
social data table. The social data table is composed of data taken from a customer’s social
network account with the customer’s permission. The permission is awarded when the
customer signs in and makes an account on any online retail seller’s website. The signing in
process is usually done through Facebook or Twitter and users then grant permission to the
retailer to access certain information. This information is compiled and put into the social data
table.
The past sales data is grouped according to the customers and the total revenue generated
from each customer is totaled. This value is then used to do an ABC analysis and thereby a
decision tree is made. All future sales are routed through the decision tree and a category is
assigned.
The social data on the other hand can be used directly and similar to sales data an ABC analysis
followed by a decision tree is done.
A custom made decision tree is also made using calculation views provided in HANA.
Calculation views are basic operations on a table. They are like functions which take in input
raw data and the output is final, refined data. Only the final refined data is not stored
independently. Every time a calculation view is accessed, the final data is recomputed.
Effectively this means every time the basic tables are modified, the calculation views will
instantaneously reflect the change.
Now having determined the discount level and the inventory level assigned to each customers’
product we place incoming orders and apply the appropriate discount and tag the appropriate
item to the customer after which the delivery process is started. Tagged item is removed from
the appropriate inventory category.
Simultaneously, sales data is analysed and the future sales is forecasted based on the
assumption that demand per unit time is normally distributed. Similarly lead time is also
analysed. Future sales per inventory category is also determined again assuming a normal
distribution.
Whenever conditions set to trigger order to the factory are met, an order is relayed to the
factory. It appears in a table called Orders in the server. As and when the factory delivers the
order, the order delivery date is updated.
The implementation looks like this,







•Customer signs up on say onlineretail.com
•Website asks to link social network account to the
website
•Website asks for permission to access customer data
Customer
Signs Up
•More the customer buys, greater his sales category
•More the followers of the customer online, more his
social category
Customer
Buys
•Discount determined based on pre decided rules
•Inventory category determined based on pre decided
rules
Service Level
determined
•Order is placed and item removed from appropriate
inventory category
Order Placed
•When pre decided conditions are met, order is
generated from warehouse to factory
Order to
factory placed
10 FUTURE SUGGESTIONS
Currently we have used only two metrics namely:
 Amount spent
 Number of online followers
But many many more metrics can be defined for both sales as well as social data.
For sales data metrics like:
 How quickly was the money spent? Person who spends same amount of money in less
time is more important.
 How distributed is the money? Person who makes large purchases might be more
important or person making numerous small purchases.
For social data metrics like:
 The quality of followers. Person with more number of “valuable” followers is more
important.
 Frequency of posts: Person who posts more i.e. actually interacts more is more
important.
 Quality of posts: People mentioning brand names in their posts are more important.
Other metrics:
 Age
 Location
 Other demographic categories like gender etc.
The project also should be extended by applying to more than one product in inventory, more
than one warehouses and a whole supply chain not just a single factory to warehouse model.
As we increase the number of metrics used the rules defining discounts and inventory levels
should be determined by the system by analyzing historic data.






11 CONCLUSION
In conclusion, this was only a prototype model. A relatively simple model, this is not fit for
applying in real world scenarios. But building up on this would yield a beautiful, complex yet
elegant model which can be applied in real world scenarios increasing sales and thus revenue
by customer retention as well as customer acquisition. In today’s world improvements in
revenue of even 5% are enormous and this system provides an opportunity to increase much
much more than that.